数字を上げることが目的になっていませんか？/engineer festival 2023 Link and Motivation

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 © Link and Motivation 自己紹介川津雄介株式会社リンクアンドモチベーション SRE ● 前職は某複写機メーカーでエンジニアしてた ● OSレイヤーからWeb/モバイルまで何でもやる ● 中途の採用活動もします ● リンクアンドモチベーションではSREとして開発室全体の生産性向上に注力！ https://github.com/megmogmog1965 https://qiita.com/megmogmog1965

Slide 3

Slide 3 text

3 © Link and Motivation リンクアンドモチベーションについて

Slide 4

Slide 4 text

4 © Link and Motivation プロダクト紹介働きがいあふれる社会へ

Slide 5

Slide 5 text

5 © Link and Motivation モチベーションクラウド診断変革 ※ 2021年度実績 8,740 社 237 万人

Slide 6

Slide 6 text

6 © Link and Motivation 導入企業様 ※2023年1月時点実績（https://www.motivation-cloud.com/）

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 © Link and Motivation 弊社開発組織の歴史 2016 2018 2019 2022 2022 末モチベーションクラウドのリリース開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウドのリリースストレッチクラウドのリリース Four Keys メトリクス High レベルに到達 2020 SRE チームの誕生弊社の開発組織は誕生して５年目です！

Slide 9

Slide 9 text

9 © Link and Motivation SRE チームの遷移 (Team Topologies 風に言うと...) 4つのチームタイプ ※ 出典：「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」より

Slide 10

Slide 10 text

10 © Link and Motivation SRE チームの遷移 (Team Topologies 風に言うと...) インタラクションモード (チーム間の関わり方を示す) ※ 出典：「チームトポロジー価値あるソフトウェアをすばやく届ける適応型組織設計」より

Slide 11

Slide 11 text

11 © Link and Motivation １年前 → Medium レベルインフラや CI/CD (仕組み) を一方的に提供していた。

Slide 12

Slide 12 text

12 © Link and Motivation 現在 → High レベル開発者と協働し、課題解決に取り組む。

Slide 13

Slide 13 text

Slide 14

Slide 14 text

14 © Link and Motivation Four Keys メトリクス出典: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out?hl=en Four Key メトリクスは Google Cloud の DevOps Research and Assessment（DORA）チームが実施した研究が出典のソフトウェア開発チームのパフォーマンスを示す 4 つの指標です。

Slide 15

Slide 15 text

15 © Link and Motivation Four Keys メトリクス出典: https://cloud.google.com/blog/products/devops-sre/dora-2022-accelerate-state-of-devops-report-now- out?hl=en 「速度」と「安定性」の指標。お互いが密接な関係にありバランスが重要です。デプロイ頻度リードタイム MTTR 変更障害率デプロイが原因で本番環境で障害が発生する割合（%）組織が本番環境での障害から回復するのにかかる平均時間 First commit から本番環境稼働までの所要時間本番環境へのリリースの頻度速度安定性

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 © Link and Motivation SRE で課題解決し一方的に押し付けてきたデプロイの自動化コンテナ化 IaC (Terraform) Four Keys : Low 〜 Medium 時代

Slide 18

Slide 18 text

18 © Link and Motivation 遠い (苦手) 近い (得意) インフラの仕組みだけで解決できる限界 SRE アプリ開発者インフラ CI / CD メトリクス SRE (インフラエンジニア発) は、どうしてもインフラ側から改善しがち。ブランチングモデルテストコード E2E テストアプリコード

Slide 19

Slide 19 text

19 © Link and Motivation … 開発者間の「協働」

Slide 20

Slide 20 text

20 © Link and Motivation どうやって「協働」できるか？一緒にメトリクス改善をしようよ！自分の仕事で忙しい SRE 開発者今のままで困ってない

Slide 21

Slide 21 text

21 © Link and Motivation 本日話したいこと

Slide 22

Slide 22 text

22 © Link and Motivation SRE と開発者が協働して進めるには？ 1 2 3 開発生産性・メトリクスの基準を統一する改善活動をみんなの目標にする数値を上げる意味・目的を共有する

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 © Link and Motivation 生産性の議論を始める為に SRE 開発者共通の指標コミュニケーション議論をする為の共通のネタ「指標」が必要。

Slide 25

Slide 25 text

25 © Link and Motivation SRE が手動でメトリクス集計をしてました長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に１度だけ更新する！あ、先週更新するの忘れてた...

Slide 26

Slide 26 text

26 © Link and Motivation SRE が手動でメトリクス集計をしてました長らく、SRE が手動でメトリクス集計&可視化をしていました。 SRE 週に１度だけ更新する！あ、先週更新するの忘れてた... 改善に繋がらない！

Slide 27

Slide 27 text

27 © Link and Motivation 生産性課題を特定する為に必要な情報量・頻度・正確さの掛け算。量頻度正確さ課題の分析をする為に、様々な面の情報が取得できている事最新の情報が毎日更新・記録できている事情報が正確で信頼できる事

Slide 28

Slide 28 text

28 © Link and Motivation ① 情報の量今月の PR は 100 件でした 25 th% は「0〜3日」 XXX さんの PR は７日超えが多い今月のリードタイムは「７日」もっと細かく・視点を変えて見ると...

Slide 29

Slide 29 text

29 © Link and Motivation ② 情報の更新頻度振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月第2週 12月第3週第4週今日過去２週間 (相対) １週目２週目月で振り返りたい

Slide 30

Slide 30 text

30 © Link and Motivation ② 情報の更新頻度振り返りの期間は多種多様。 (相対・絶対 / 日・週・月) 11月第2週 12月第3週第4週今日過去２週間 (相対) １週目２週目月で振り返りたい毎日メトリクス集計できているとベスト

Slide 31

Slide 31 text

31 © Link and Motivation ③ 情報の正確さ情報 (ミス 0%) 機械人間情報 (ミス 5%) 開発者 (頻度低くても) ミスの可能性があると見る気を無くす自動手作業 ❌

Slide 32

Slide 32 text

32 © Link and Motivation 自動化が必要

Slide 33

Slide 33 text

33 © Link and Motivation メトリクス・ダッシュボード自動化に求められる要件全自動リアルタイム性変更容易性ダッシュボード要件見たい時に見たい情報が得られないと、開発者は見る気を無くすメトリクスを計測する事自体が SRE の負担 (トイル) になってはならないメトリクスの具体的な計測方法は、利用しているツールだけでなく、開発組織の状況によって常に変わる

Slide 34

Slide 34 text

34 © Link and Motivation 変更に強いメトリクス集計ツールだけでなく、開発組織や事業のフェーズによって、集計方法は都度変わる。ブランチングモデルが変わったり... インシデント対応プロセスが変わる等

Slide 35

Slide 35 text

35 © Link and Motivation 最近はメトリクス集計をしてくれる良い外部サービスもある SRE 始めたての若い組織は、実績が足りないので外部サービス (※お金掛かる) をうまく活用できるか、判断がつかない。初めはタダで出来る範囲で経験値を積んでからかなぁ...

Slide 36

Slide 36 text

36 © Link and Motivation Dashboard アーキテクチャ収集データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio

Slide 37

Slide 37 text

37 © Link and Motivation Dashboard アーキテクチャ収集データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio リードタイムデプロイ頻度 MTTR 変更障害率毎日同期 (SQL みたいに) 1行 = 1レコード

Slide 38

Slide 38 text

38 © Link and Motivation Dashboard アーキテクチャ収集データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio データの加工 (Excel芸) は不要毎日同期

Slide 39

Slide 39 text

39 © Link and Motivation Dashboard アーキテクチャ収集データ加工 → 可視化 GitHub スプシ Google Sheets Google Looker Studio ノーコードでダッシュボード化毎日同期

Slide 40

Slide 40 text

40 © Link and Motivation データの収集について Looker Studio は Google Sheets の１行を１レコードとして扱える。 ※ RDB の SQL みたいな感じ. タイトル作成者 URL First commit Merged バグ修正 B さん https://… 2022-10- 23T02:00:00Z 2022-10-27T04:00:00Z リファクタ B さん https://… 2022-10- 26T04:00:00Z 2022-10-28T05:00:00Z Typo C さん https://… 2022-10- 28T05:00:00Z 2022-10-28T06:00:00Z １行 = １レコード複数レコードから一つの統計値を算出する MEDIAN(4日, 2日, 1日) リードタイム = 2日

Slide 41

Slide 41 text

41 © Link and Motivation データの閲覧について「X軸=日 / Y軸=リードタイム」のグラフ

Slide 42

Slide 42 text

42 © Link and Motivation 実際に作成したダッシュボード

Slide 43

Slide 43 text

43 © Link and Motivation 参考リンク宜しければこちらもご覧下さい。 ● https://speakerdeck.com/lmi/sre-lounge-2023?slide=35 ● https://link-and-motivation.hatenablog.com/entry/four-keys-metrics- dashboard

Slide 44

Slide 44 text

Slide 45

Slide 45 text

45 © Link and Motivation アプリ開発者の仕事 SRE 開発者当然ですが、アプリ開発者は毎日すごく忙しい。リファクタリング顧客要求の機能開発日々の顧客対応インシデント対応生産性の改善活動

Slide 46

Slide 46 text

46 © Link and Motivation 遠い (苦手) 近い (得意) アプリケーション領域の改善 SRE アプリ開発者インフラ CI / CD ブランチングモデルテストコード E2E テストアプリコードメトリクスアプリケーション領域の改善には、開発者の協力が必須！

Slide 47

Slide 47 text

47 © Link and Motivation チーム間の断絶開発チーム ⇔ SRE チーム間の断絶！コミュニケーションパスが希薄チームそれぞれの仕事・目標の達成が最優先 SRE だけでは生産性向上できない

Slide 48

Slide 48 text

48 © Link and Motivation チーム間の断絶開発チーム ⇔ SRE チーム間の断絶！コミュニケーションパスが希薄チームそれぞれの仕事・目標の達成が最優先 SRE だけでは生産性向上できない改善の為の明確なチーム・役割・責務を決める

Slide 49

Slide 49 text

49 © Link and Motivation 新しいチームを結成する

Slide 50

Slide 50 text

50 © Link and Motivation 各チームから協力者を選出横断チームを結成する！開発チーム A 開発チーム B 開発チーム C 各ストリームアラインドチームから活動に興味高そうな人を選出各ストリームアラインドチームから活動に興味高そうな人を選出各ストリームアラインドチームから活動に興味高そうな人を選出

Slide 51

Slide 51 text

51 © Link and Motivation 開発者のミッション・目標と結節開発チーム A 開発チーム B 開発チーム C 事業部目標個人目標弊社の 2022/4Q の事業部全体の目標に生産性向上が入っていたボランティアではなく正式に個人の仕事にする

Slide 52

Slide 52 text

52 © Link and Motivation 改善チームを結成する改善プロジェクトに即した、実際の活動体 (チーム・会議体) を設計する。 SRE と開発者の混合チーム新しい横断チーム会議体共通の目標

Slide 53

Slide 53 text

53 © Link and Motivation Embedded SRE としてチームに埋め込む

Slide 54

Slide 54 text

54 © Link and Motivation 障害が多発！当時、プロダクトの障害が多発しており「変更障害率」が非常に高い状態にあった... デプロイ頻度リードタイム MTTR 変更障害率

Slide 55

Slide 55 text

55 © Link and Motivation 障害が多発！頑張ってヒアリングをするも、外からでは分からない事は多い！それぞれのチームで何が原因で障害が増えているんだろう？ヒアリングしてみたけど、いまいちはっきりしないぞ

Slide 56

Slide 56 text

56 © Link and Motivation 障害が多発！頑張ってヒアリングをするも、外からでは分からない事は多い！それぞれのチームで何が原因で障害が増えているんだろう？ヒアリングしてみたけど、いまいちはっきりしないぞチームの一員になって活動すると分かりそう！

Slide 57

Slide 57 text

Slide 58

Slide 58 text

58 © Link and Motivation 改善チームを結成する SRE 個人を、ストリームアラインドチームの一員として「埋め込み」中から直接改善をする！コミュニケーションパスが希薄 ① 課題・原因の特定がしやすい ② 改善活動をチームと直接できる

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

61 © Link and Motivation 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！実装開始１ヶ月前 PR を作り直す１週前リリース放置期間 (※別件で忙しかった) 実装再開３日前当日リードタイム = ３日！？ (リードタイムの為に) PR を作りなおそう！

Slide 62

Slide 62 text

62 © Link and Motivation 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！実装開始１ヶ月前 PR を作り直す１週前リリース放置期間 (※別件で忙しかった) 実装再開３日前当日リードタイム = ３日！？ (リードタイムの為に) PR を作りなおそう！「リードタイムを３日にする」が目的になっている

Slide 63

Slide 63 text

Slide 64

Slide 64 text

64 © Link and Motivation リードタイム (値) が表す意味リードタイムの定義は「First Commit → リリース」までの日数。 First Commit ５日前１日前リリース一つの PR・Feature をリリースするのに掛かった日数 master マージ当日機能？プロジェクト？

Slide 65

Slide 65 text

65 © Link and Motivation リードタイム (値) が表す意味実装機能 A 実装リリースリリース実装リリース実装リリース最近は、スモールリリース・Feature toggle という手があるよね。リードタイム → 大機能 B リードタイム → 小リードタイム → 小リードタイム → 小

Slide 66

Slide 66 text

66 © Link and Motivation リードタイム (値) が表す意味実装機能 A 実装リリースリリース実装リリース実装リリース最近は、スモールリリース・Feature toggle という手があるよね。リードタイム → 大機能 B リードタイム → 小リードタイム → 小リードタイム → 小リードタイムの単位は「機能」ではなく「PR」である！

Slide 67

Slide 67 text

67 © Link and Motivation 1 PR PR 大 vs 小 PR を小さくすると、レビュー＆テスト品質が上がる。 1 PR 1 PR 1 PR 実装とその影響範囲を見きれず設計観点のチェックになるコードの１行までレビューできる変更影響の特定が難しく、全件リグレッションテストが多発変更に対し最小のテストを実施 ✅ ✅ ❌ ❌

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

71 © Link and Motivation リードタイム短縮の目的障害を減らしたいリリースの複雑性を減らしたいスモールリリース・Feature toggle をするリードタイム ≦ ３日目的手段目標 ※ 弊社の開発組織のケースでの一例です。全ての開発組織で一概にそうとは限りません。 ① ②

Slide 72

Slide 72 text

Slide 73

Slide 73 text

73 © Link and Motivation e.g. Rails アップデートビッグバンリリース ※ リリースめちゃ怖〜スモールリリース PR 数変更ファイル / PR 1〜2 PR(s) 100 files PR 数変更ファイル / PR 80 PR(s) 1〜2 files 弊社 Rails アップデートの今と昔。

Slide 74

Slide 74 text

74 © Link and Motivation e.g. Rails アップデート小さな互換性のあるリリースを繰り返す。互換リリース 1回目 80回目最終リリース新・旧どちらの Rails Version でも動く互換コードを先行リリースする互換リリース最後の１回最後にやっと Rails の Version を上げる + 一部の非互換コード・・・ (スモールリリース) ・・・ x8 0 ・・・

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

77 © Link and Motivation 開発者みんなで「協働」して改善を進める為に 1 2 3 メトリクス集計は自動化＆ダッシュボード化しよう！改善活動の横断チームを作り、ちゃんと仕事化 (目標) する！数値を追うのではなく、目的・目指す姿を明確にしよう！

Slide 78

Slide 78 text

78 © Link and Motivation 開発者体験 = 幸せが高い組織「理想の姿」を証明する為の「数値」であれスピード・気軽さリリースのシンプルさ品質の高さ ● リリース調整「〜はいつ出す？」は大変 ● 一つ遅れると、全部再調整！ ● 小さな改善をすぐにリリースできる ● リリース承認等のプロセスで時間が掛かる ● 障害が発生すれば、対応にコストを払う ● 気軽なリリースができなくなる

Slide 79

Slide 79 text

79 © Link and Motivation 開発者体験 = 幸せが高い組織「理想の姿」を証明する為の「数値」であれスピード・気軽さリリースのシンプルさ品質の高さ ● リリース調整「〜はいつ出す？」は大変 ● 一つ遅れると、全部再調整！ ● 小さな改善をすぐにリリースできる ● リリース承認等のプロセスで時間が掛かる ● 障害が発生すれば、対応にコストを払う ● 気軽なリリースができなくなる速度安定性表裏一体開発メトリクス

Slide 80

Slide 80 text

80 © Link and Motivation 開発者体験 = 幸せが高い組織「理想の姿」を証明する為の「数値」であれスピード・気軽さリリースの複雑さ品質の高さ ● リリース調整「〜はいつ出す？」は大変 ● 一つ遅れると、全部再調整！ ● 小さな改善をすぐにリリースできる ● リリース承認等のプロセスで時間が掛かる ● 障害が発生すれば、対応にコストを払う ● 気軽なリリースができなくなる速度安定性表裏一体開発メトリクス理想の姿へどの位到達したかメトリクス = 達成指標

Slide 81

Slide 81 text

Slide 82

Slide 82 text

82 © Link and Motivation お知らせ ● エンジニアリングマネージャー ● プロダクトマネージャー ● テックリード ● サーバーサイドエンジニア ● フロントエンドエンジニア ● SRE ● QAエンジニア ● データエンジニア ● CRM ● UXデザイナー週１でテックブログを更新中！まずはカジュアルにお話しましょう！積極採用中です！