なぜ Four Keys を改善するのか？/productivity-con-link-and-motivation

【開発生産性Conference】
リンクアンドモチベーション登壇資料（2023/07/13）

『なぜ Four Keys を改善するのか？
〜How ではなく Why を重視したメトリクス改善活動〜』

#開発生産性con_findy #リンクアンドモチベーション #リンモチ
=============================================
【イベント情報】
■イベントページ
　https://findy.connpass.com/event/283417/

■特設サイト
　https://dev-productivity-con.findy-code.io/

【株式会社リンクアンドモチベーション】
■お問い合わせ
　engineer_pr@lmi.ne.jp
■Entrancebook
　https://note.com/lmi/n/n179505e048f4
■テックブログ
　https://link-and-motivation.hatenablog.com/
=============================================

Transcript

1. © Link and Motivation Group なぜ Four Keys を改善するのか？ Developer Productivity ユニット / SRE グループ 川津雄介 〜How ではなく Why を重視したメトリクス改善活動〜
2. 2 © Link and Motivation Group 自己紹介 川津 雄介 株式会社リンクアンドモチベーション SRE • 前職は某複写機メーカーでエンジニアしてた • OSレイヤーからWeb/モバイルまで何でもやる • 中途の採用活動もします • リンクアンドモチベーションではSREとして開発 室全体の生産性向上に注力！ https://github.com/megmogmog1965 https://qiita.com/megmogmog1965
3. 3 © Link and Motivation Group リンクアンドモチベーションについて 327億円（2022年12月時点） （2022年12月時点） 11社
4. プロダクト紹介 働きがい あふれる社会へ
5. モチベーションクラウド 診断 変革 ※ 2022年度 実績 10,060 社 312 万人
6. 導入企業様 ※2023年1月時点実績（https://www.motivation-cloud.com/）
7. © Link and Motivation Group 7 リンクアンドモチベーションの SRE と開発組織
8. 8 © Link and Motivation Group 弊社開発組織の歴史 2016 2018 2019 2022 2023 モチベーションクラウド のリリース 開発組織内製化のスタート (Four Keys = Low レベル) コミュニケーションクラウド のリリース ストレッチクラウド のリリース Four Keys メトリクス High〜Elite レベルに到達 2020 SRE チームの誕生 弊社の開発組織は誕生して５年目です！ デプロイ頻度: 120 回/月 リードタイム: 1日 ※モチベーションクラウド 5月実績
9. 9 © Link and Motivation Group SRE チームの遷移 (Team Topologies 風に言うと...) 4つのチームタイプ ※ 出典：『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』より
10. 10 © Link and Motivation Group SRE チームの遷移 (Team Topologies 風に言うと...) インタラクションモード (チーム間の関わり方を示す) ※ 出典：『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』より
11. 11 © Link and Motivation Group ３つのプロダクトから成る、複数のチーム 社員 約80名 ＋ パートナーさん
12. © Link and Motivation Group 12 本日お話したいこと
13. 13 © Link and Motivation Group 弊社では SRE が生産性改善を推進してきました デプロイの自動化 コンテナ化 IaC (Terraform) Four Keys : Low 〜 Medium 時代
14. 14 © Link and Motivation Group 遠い (苦手) 近い (得意) インフラの仕組みだけで解決できる限界 SRE アプリ開発者 インフラ CI / CD メトリクス SRE (インフラエンジニア発) は、どうしてもインフラ側から改善しがち。 ブランチング モデル テストコード E2E テスト アプリコード オーナーシップ
15. 15 © Link and Motivation Group … 開発者全員で 改善活動をしたい！
16. 16 © Link and Motivation Group チームを横断した中央集権的な改善 改善活動の推進者 (SRE 等) チーム B チーム A チーム C 課題の 調査・ヒアリング サービス X サービス Y
17. 17 © Link and Motivation Group チームを横断した中央集権的な改善 チーム B チーム A チーム C 対策立案 サービス X サービス Y 改善活動の推進者 (SRE 等)
18. 18 © Link and Motivation Group チームを横断した中央集権的な改善 チーム B チーム A チーム C サービス X サービス Y 具体的な アクションの指示 改善活動の推進者 (SRE 等)
19. 19 © Link and Motivation Group どうやって全員で活動できるか？ 一緒にメトリクス改善 をしようよ！ 自分の仕事で忙しい 開発者 今のままで困ってない 改善活動の推進者 (SRE 等)
20. 20 © Link and Motivation Group チーム B チーム A チーム C サービス X サービス Y 【課題】お互いの主体性の偏り 生産性改善は自身の「ミッション」 しかし、サービス (コード) へのオーナーシップは持っていない 改善活動の推進者 (SRE 等)
21. 21 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏り チーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの 「ミッション」ではない サービス (コード) のオーナーシップ を持っており改善活動しやすい
22. 22 © Link and Motivation Group チームを横断した中央集権的な改善 SRE チーム B チーム A チーム C サービス X サービス Y 具体的な アクションの指示 どうすれば全員が主体性を持って 改善活動に取り組めるか？
23. 23 © Link and Motivation Group 本日話したいこと
24. 24 © Link and Motivation Group 開発者全員で主体性を持って改善活動するには？ 1 2 3 改善の「Why (目的)」を言語化する チームの壁を超えて一丸となって改善する 改善のオーナーシップをチームに！
25. © Link and Motivation Group 25 ① 改善の「Why (目的)」を言語化する
26. 26 © Link and Motivation Group 実際にあった怖い話 (リードタイム) とある PR を１ヶ月放置していた。 実装開始 １ヶ月前 １週前 放置期間 (※別件で忙しかった) 実装再開 (１ヶ月経って) やっと再開できるぞ！
27. 27 © Link and Motivation Group 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！ 実装開始 １ヶ月前 PR を 作り直す １週前 リリース 放置期間 (※別件で忙しかった) 実装再開 ３日前 当日 リードタイム = ３日 ！？ (リードタイムの為に) PR を作りなおそう！
28. 28 © Link and Motivation Group 実際にあった怖い話 (リードタイム) 再開する際に気を効かせてくれて、PR (ブランチ) を作りなおす！ 実装開始 １ヶ月前 PR を 作り直す １週前 リリース 放置期間 (※別件で忙しかった) 実装再開 ３日前 当日 リードタイム = ３日 ！？ (リードタイムの為に) PR を作りなおそう！ 「リードタイムを３日にする」 が目的になっている
29. 29 © Link and Motivation Group Why / How / What リードタイム < ３日 How (どうやって？) What (何を？) リードタイム ３日以内を目指そう！ 改善活動の推進者 (SRE 等) アプリ開発者 ３日か〜。 どうやってやろうかな
30. 30 © Link and Motivation Group How (どうやって？) What (何を？) アプリ開発者 ３日か〜。 どうやってやろうかな Why / How / What リードタイム < ３日 リードタイム ３日以内を目指そう！ 改善活動の推進者 (SRE 等) 何で３日をめざすの？ (何に困ってるの？)
31. 31 © Link and Motivation Group Why / How / What リードタイム < ３日 How (どうやって？) What (何を？) Why (なぜ？) 推進者 (リーダー) がメンバーを効果的に動かすには 「Why」が肝心！
32. 32 © Link and Motivation Group みんなが能動的に活動できる！ 人は「何を」ではなく 「なぜ」に動かされるのです What How ゴールデンサークル理論 Why Why から始めよ 目的を見失わない為に 効果の無い How に 傾倒することが無い様に
33. 33 © Link and Motivation Group 実際にあった例
34. 34 © Link and Motivation Group ８名体制の新規プロジェクト 社員: ４名 パートナー: ４名
35. 35 © Link and Motivation Group このチームの目標に「デプロイ頻度 = High」が入る デプロイ頻度の「High」 を目指すぞ〜！！ 改善活動の推進者
36. 36 © Link and Motivation Group 当時「デプロイ頻度」を改善しようとしていた ０〜１回 / 週 ５回 / 週 ０〜１回 / 週 ５回 / 週 (当時)
37. 37 © Link and Motivation Group 改善の甲斐あって？ 目標値に近づいてきたが... ３〜４回 / 週
38. 38 © Link and Motivation Group 数値上は達成しつつあるが... 最近、生産性 (デプロイ頻度) あがってきたよね！ いや、実は... 開発者 改善活動の推進者 (SRE 等)
39. 39 © Link and Motivation Group 辛みが増している...！ 一度のリリース作業に ３時間も拘束されて辛い！ リリースする人が偏ってて なんか毎日リリース作業 してる！
40. 40 © Link and Motivation Group 辛みが増している...！ あれ？ 俺たち「何で」こんな辛い思いして 「週５回」もリリースしなきゃいけないんだっけ？
41. 41 © Link and Motivation Group 辛みが増している...！ あれ？ 俺たち「何で」こんな辛い思いして 「５回」もリリースしなきゃいけないんだっけ？ むしろ、生産性下がってない？ 後日、２回/週 がベスト という結論に...
42. 42 © Link and Motivation Group 数値を「上げる」事が目的になってしまった... デプロイ頻度 「High」達成！ How (どうやって？) What (何を？) Why (なぜ？) なぜ、デプロイ頻度を 上げないといけないのか？ (どんな良いことがあるか） ❌ ⭕ どうやって デプロイ頻度を上げよう？
43. 43 © Link and Motivation Group ２つの Why - 課題と目指す姿 デプロイ頻度 「High」達成！ How (どうやって？) なぜ？ 低いのか？ なぜ？ 低いとダメか？ 原因 本当の課題と 目指す姿
44. 44 © Link and Motivation Group How (どうやって？) なぜ？ 低いのか？ 原因 ２つの Why - 課題と目指す姿 デプロイ頻度 「High」達成！ なぜ？ 低いとダメか？ 本当の課題と 目指す姿 これはみんな するけど... こっちが無いと間違った ゴールの HOW になる
45. 45 © Link and Motivation Group 低いメトリクス値が示す意味は？ 低いメトリクス 潜在した 課題 潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか？ 様々な要因が複合して このメトリクスである (要考：数値の意味)
46. 46 © Link and Motivation Group 何をあるべき姿として 目指していたのか？
47. 47 © Link and Motivation Group そもそも... デプロイ頻度 リードタイム …って、改善すると何が嬉しいの ？？？
48. 48 © Link and Motivation Group デプロイ頻度...？ デプロイ頻度 デプロイ回数が多い 生産量が多い？
49. 49 © Link and Motivation Group デプロイ頻度...？ デプロイ頻度 デプロイ回数が多い 生産量が多い？ 小さいリリースの回数が多いだけかも...
50. 50 © Link and Motivation Group デプロイ頻度が少ないと １度のデプロイに 複数の Feature が混在している
51. 51 © Link and Motivation Group デプロイ頻度が少ないと もしこれがバグってたら...
52. 52 © Link and Motivation Group デプロイ頻度が少ないと 全部まとめて切り戻し
53. 53 © Link and Motivation Group デプロイ頻度が少ないと マイグレ等が混ざってると 切り戻しに時間が掛かる MTTR コミュニケーション コミュニケーション 単純に切り戻して いいんだっけ？ マイグレあるから 待って！
54. 54 © Link and Motivation Group デプロイ頻度が高い！
55. 55 © Link and Motivation Group デプロイ頻度が高い！ バグる
56. 56 © Link and Motivation Group デプロイ頻度が高い！ 切り戻して、終わり
57. 57 © Link and Motivation Group つまりデプロイ頻度とは...？ デプロイ頻度 デプロイ回数が多い ？？？ ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。
58. 58 © Link and Motivation Group つまりデプロイ頻度とは...？ デプロイ頻度 デプロイ回数が多い 安全な切り戻し 切り戻しや再リリースに掛かる工数減 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 MTTR の向上
59. 59 © Link and Motivation Group リードタイム リードタイム...? マージまでの時間が短い 機能がリリースされるまでが速い？
60. 60 © Link and Motivation Group リードタイム リードタイム...? マージまでの時間が短い 機能がリリースされるまでが速い？ 単に分割してマージしただけかも...
61. 61 © Link and Motivation Group リードタイム (値) が表す意味 リードタイムの定義は「First Commit → リリース」までの日数。 First Commit ５日前 １日前 リリース 一つの PR・Feature を リリースするのに掛かった日数 master マージ 当日 機能？ プロジェクト？
62. 62 © Link and Motivation Group リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小
63. 63 © Link and Motivation Group リードタイム (値) が表す意味 実装 機能 A 実装 リリース リリース 実装 リリース 実装 リリース 最近は、スモールリリース・Feature toggle という手があるよね。 リードタイム → 大 機能 B リードタイム → 小 リードタイム → 小 リードタイム → 小 リードタイムの単位は 「機能」ではなく「PR」である！
64. 64 © Link and Motivation Group 1 PR PR 大 vs 小 PR を小さくすると、レビュー＆テスト品質が上がる。 1 PR 1 PR 1 PR 実装とその影響範囲を見きれず 設計観点のチェックになる コードの１行までレビューできる 変更影響の特定が難しく、 全件リグレッションテストが多発 変更に対し最小のテストを実施 ✅ ✅ ❌ ❌
65. 65 © Link and Motivation Group PR 大 vs 小 巨大な PR あるある コードがコンフリクトして大変 A がマージされないと B がテスト開始できない リリース日程調整でコミュニケーションコスト高
66. 66 © Link and Motivation Group PR 大 vs 小 PR が十分に小さいと... コンフリクトしない / しても簡単に直すだけ 自分の Feature のテストだけしたらいい リリース日程調整は不要
67. 67 © Link and Motivation Group リードタイム つまりリードタイムとは...? マージまでの時間が短い ？？？
68. 68 © Link and Motivation Group リードタイム短縮の目的 障害を減らしたい リリースの複雑性 を減らしたい スモールリリース・Feature toggle をする リードタイム ≦ ３日 目的 手段 目標 ※ 弊社の開発組織のケースでの一例です。 全ての開発組織で一概にそうとは限りません。 ① ②
69. 69 © Link and Motivation Group e.g. Rails アップデート ビッグバンリリース ※ リリースめちゃ怖〜 スモールリリース PR 数 変更ファイル / PR 1〜2 PR(s) 100 files PR 数 変更ファイル / PR 80 PR(s) 1〜2 files 弊社 Rails アップデートの今と昔。
70. 70 © Link and Motivation Group e.g. Rails アップデート 小さな互換性のあるリリースを繰り返す。 互換 リリース 1回目 80回目 最終 リリース 新・旧 どちらの Rails Version でも動く 互換コードを先行リリースする 互換 リリース 最後の１回 最後にやっと Rails の Version を上げる + 一部の非互換コード ・・・ (スモールリリース) ・・・ x8 0 ・・・
71. 71 © Link and Motivation Group 各メトリクスは繋がっている... デプロイ頻度 リードタイム 変更障害率 MTTR
72. 72 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける 低いメトリクス 潜在した 課題 潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか？ 様々な要因が複合して このメトリクスである (要考：数値の意味)
73. © Link and Motivation Group 74 ② チームの壁を超えて一丸となって改善する
74. 75 © Link and Motivation Group アプリ開発者の仕事 開発者 当然ですが、アプリ開発者は毎日すごく忙しい。 リファクタリング 顧客要求の機能開発 日々の顧客対応 インシデント対応 生産性の改善活動 改善活動の推進者 (SRE 等)
75. 76 © Link and Motivation Group チーム B チーム A チーム C サービス X サービス Y 【課題】お互いの主体性の偏り 生産性改善は自身の「ミッション」 しかし、サービス (コード) へのオーナーシップは持っていない 改善活動の推進者 (SRE 等)
76. 77 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏り チーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの 「ミッション」ではない サービス (コード) のオーナーシップ を持っており改善活動しやすい
77. 78 © Link and Motivation Group 改善活動の推進者 (SRE 等) 【課題】お互いの主体性の偏り チーム B チーム A チーム C サービス X サービス Y 生産性改善は彼らの 「ミッション」ではない サービス (コード) のオーナーシップ を持っており改善活動しやすい 改善の為の明確な チーム・役割・責務を決めるべき
78. 79 © Link and Motivation Group 新しいチームを結成する
79. 80 © Link and Motivation Group 各チームから協力者を選出 横断チームを結成する！ 開発チーム A 開発チーム B 開発チーム C 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出 各ストリームアラインドチーム から活動に興味高そうな人を選出
80. 81 © Link and Motivation Group 開発者のミッション・目標と結節 開発チーム A 開発チーム B 開発チーム C 事業部目標 個人目標 弊社の 2022/4Q の 事業部全体の目標に 生産性向上が入っていた ボランティアではなく 正式に個人の仕事にする
81. 82 © Link and Motivation Group チーム B 開発者のミッション・目標と結節 チーム A チーム C 各所属チームへの結節点となる 各所属チームへの結節点となる
82. 83 © Link and Motivation Group 逆に、チームに埋め込む
83. 84 © Link and Motivation Group 障害が多発！ 当時、プロダクトの障害が多発しており「変更障害率」が非常に高い状態にあった... デプロイ頻度 リードタイム MTTR 変更障害率
84. 85 © Link and Motivation Group 障害が多発！ 頑張ってヒアリングをするも、外からでは分からない事は多い！ チームの何が原因で障害が 増えているんだろう？ ヒアリングしてみたけど、 いまいちはっきりしないぞ
85. 86 © Link and Motivation Group 障害が多発！ 頑張ってヒアリングをするも、外からでは分からない事は多い！ チームの何が原因で障害が 増えているんだろう？ ヒアリングしてみたけど、 いまいちはっきりしないぞ チームの一員になって 活動すると分かりそう！
86. 87 © Link and Motivation Group 改善チームを結成する 一定期間だけ チームを異動します！ 改善の推進者をストリームアラインドチームの 一員として「埋め込み」中から直接改善をする！ 生産性改善チーム
87. 88 © Link and Motivation Group 改善チームを結成する 一定期間だけ チームを異動します！ 改善の推進者をストリームアラインドチームの 一員として「埋め込み」中から直接改善をする！ ① 課題・原因の特定がしやすい ② 改善活動をチームと直接できる
88. © Link and Motivation Group 89 ③ 改善のオーナーシップをチームに！
89. 90 © Link and Motivation Group 改善推進者が主体の指示型 チーム B チーム A チーム C サービス X サービス Y 具体的な アクションの指示 改善活動の推進者 (SRE 等)
90. 91 © Link and Motivation Group 組織の規模が拡大すると現実的ではなくなる チーム B チーム A チーム C サ | ビ ス X Y チーム B チーム A チーム C サ | ビ ス Z … 中央集権的にやる限界 改善活動の推進者 (SRE 等)
91. 92 © Link and Motivation Group 組織の規模が拡大すると現実的ではなくなる SRE チーム B チーム A チーム C サ | ビ ス X Y チーム B チーム A チーム C サ | ビ ス Z … SRE も一緒にスケール するのは微妙 どうすべき？
92. 93 © Link and Motivation Group 改善活動の推進者 (SRE 等) 改善のオーナーシップを「チーム」に チーム B チーム A チーム C サービス X サービス Y チーム内に 「改善係」を置く？ チーム内に 「改善係」を置く？ チーム内に 「改善係」を置く？
93. 94 © Link and Motivation Group ※ Team Topologies より抜粋
94. 95 © Link and Motivation Group チームに計測＆改善のプロセスをインストールする チーム B チーム A 改善活動の推進者 (SRE 等)
95. 96 © Link and Motivation Group チームに計測＆改善のプロセスをインストールする チーム B チーム A 改善活動の推進者 (SRE 等) + + イネーブリング 改善活動はみんなの責務 あくまで 一時的にJOIN
96. 97 © Link and Motivation Group 何をチームにインストールするのか？ メトリクス計測 の自動化 改善運用 / プロセス What How Why Why から 始める思想
97. 98 © Link and Motivation Group 何をチームにインストールするのか？ メトリクス計測 の自動化 改善運用 / プロセス What How Why Why から 始める思想 Github 等から計測 ダッシュボード化
98. 99 © Link and Motivation Group 何をチームにインストールするのか？ メトリクス計測 の自動化 改善運用 / プロセス What How Why Why から 始める思想 まずはチームの 会議体から 必要に応じて、チーム の目標に組み込む
99. 100 © Link and Motivation Group 何をチームにインストールするのか？ メトリクス計測 の自動化 改善運用 / プロセス What How Why Why から 始める思想 推進者が並走して 指導する必要がある
100. © Link and Motivation Group 101 さいごに
101. 102 © Link and Motivation Group 開発生産性の活動に銀の弾丸はない
102. 103 © Link and Motivation Group 開発生産性の活動に銀の弾丸はない HOW の話だから
103. 104 © Link and Motivation Group 組織の規模・形態が違う チーム A チーム A チーム B チーム C チーム 横断して A 事業部 チーム内の B 事業部 C 事業部 横断して 組織・全社で
104. 105 © Link and Motivation Group プロダクトの開発特性が違う 例えば、master 一本ではなく 特注リリースがあるとか B to B / B to C とかで メトリクスの意味も異なる
105. 106 © Link and Motivation Group メトリクスが低い原因は一つではない 例えばデプロイ頻度が低い原因も、それぞれの現場で様々ある... リリースする物はあ るが CI・CD、自動 化が出来ていないと か... そもそも、一日あた りにマージされる Feature が少ないと か... インシデントが多発し ており、その対応やリ リース時のテスト工数 とか...
106. 107 © Link and Motivation Group メトリクス値から、生産性課題 → あるべき理想の姿を見つける 低いメトリクス 潜在した 課題 潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか？ 様々な要因が複合して このメトリクスである (要考：数値の意味)
107. 108 © Link and Motivation Group メトリクス値が示す真の意味を考えたい 低いメトリクス 潜在した 課題 潜在した 課題 潜在した 課題 その時点の最大の ボトルネック課題 あるべき理想 課題が解決した先の 理想の開発環境像をイメージ できているか？ 様々な要因が複合して このメトリクスである (要考：数値の意味) 「Why」を考えよう！
108. © Link and Motivation Group 109 #devキャリ2022 さいごに
109. 110 © Link and Motivation Group お知らせ • エンジニアリングマネージャー • プロダクトマネージャー • テックリード • サーバーサイドエンジニア • フロントエンドエンジニア • SRE • データエンジニア • CRM • UXデザイナー 週１でテックブログを更新中！ まずはカジュアルにお話しましょう！ 積極採用中です！