30分でわかるFour Keysの基礎と重要性

ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。

Transcript

1. 30分でわかる Four Keysの基礎と重要性 2022/10/27 Four Keysで進める改善サイクル - Techmee vol.4 株式会社はてな Webアプリケーションエンジニア yigarashi
2. 自己紹介 • 五十嵐 雄（いがらし ゆう）/ id:yigarashi / @yigarashi_9 • 株式会社はてな Webアプリケーションエンジニア • yigarashiのブログ で学びを発信しています ◦ エンジニアリングマネージャーを目指す若者の戦略 ◦ Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善 する方法について ▪ このエントリーがきっかけでお声がけいただくことに！
3. イントロダクション 「もっと成果を出したい」 「ハイパフォーマンスな開発をやっていくぞ」 「生産性の高いチームを目指しましょう」 🤔いったい何をどうすれば……？
4. ソフトウェア開発を取り巻く複雑な環境 • 生産性としてどの指標を見たらよい？ ◦ 変更行数 ベロシティ コミット数 プルリクエスト数 リリース回数 プロ ジェクト完了までの期間 事業のKPI 売上 etc… • どんなプラクティスにどんな効果がある？ ◦ リファクタリング テスト CI/CD モブプロ レビュー QA スクラム カンバ ン タスク分割 チームトポロジー etc…
5. DORA - DevOps Research and Assesment • 学術的な手法を用いてソフトウェア開発やデリバリーの状況を改善するこ とを目指す研究プロジェクト • 2013年から毎年「State of DevOps Report」を報告 • 「LeanとDevOpsの科学」は2014〜2017のレポートをまとめたもの • 2018年にGoogleが買収しGoogle Cloudから継続して情報発信 ◦ DevOps とは: 研究とソリューション | Google Cloud ◦ DORA research program
6. Four Keys DORAが提唱するデリバリーパフォーマンスを示す4つの指標 指標 定義 変更のリードタイム 変更のコミットから本番環境へのデプロイまでの時間 デプロイ頻度 本番環境へのリリース頻度 変更失敗率 意図通り動かないコードをリリースした割合（※要約） 平均修復時間 障害から復旧するまでの平均時間
7. アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
8. Four Keysがなぜこの定義なのか 職能横断のアウトカムを意図してトップダウンに注意深く選定された • バリューストリームのスループットが高いか ◦ 変更のリードタイム ◦ デプロイ頻度 • 安定してデリバリーを続けているか ◦ 変更失敗率 ◦ 平均修復時間
9. Four Keysと組織のパフォーマンス • 単に「注意深く選定した」では説得力がない • DORAはFour Keysの尤もらしさを学術的な手法で明らかにした ◦ Four Keysに関する回答をクラスタリング分析 ◦ 浮かび上がった3クラスタでFour Keysのスコアに有意な差 ◦ ハイ/ミドル/ロー パフォーマーの発見 • ハイパフォーマーほど組織のパフォーマンス（収益性や市場占有率、目標 の達成度合いなど）も高いとわかった
10. Four Keysにトレードオフはない • Four Keysは直感的にはトレードオフが見出せる ◦ スループット: 変更のリードタイム デプロイ頻度 ◦ 安定性: 変更失敗率 平均修復時間 • しかし発見されたハイパフォーマーは4指標全てで抜きん出ていた • スループットと安定性の両方を改善する優れたプラクティスを採用すること が重要
11. 特に有効性が示されたプラクティス・能力 • DORAはFour Keysや組織パフォーマンスの改善に有効なプラクティス・ 能力を統計的に特定してきた • LeanとDevOpsの科学では「24のケイパビリティ」 • DevOps の能力 | Google Cloud ◦ 2022/10/16現在は27の能力が示されている ◦ 技術・プロセス・測定・文化の4軸 • Four Keysを土台にすることで、選りすぐりのプラクティスに後ろ盾がある 状態から始められる
12. 手法の効果を説明する枠組みとして 例題: リファクタリングはどんな効果があるのか • 変更のリードタイム: 変更を加えやすくなり短縮 • デプロイ頻度: 疎結合になることでより小さくリリースが可能 • 変更失敗率: コードを理解しやすくなりミスが減少 • 平均修復時間: コードを理解しやすくなり原因の特定が容易に 適切なリファクタリングがデリバリーパフォーマンスの向上につながることを分 解して体系的に説明できた
13. まとめ: Four Keysを計測し改善する意義 • 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパ フォーマンスと関係があるとわかった指標である • Four Keysにトレードオフはない: スループットと安定性の両方を改善する 優れたプラクティスの実践を促す • 様々なプラクティスを定性・定量の両側面で評価しやすくなり建設的に議 論を進められる
14. アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
15. 変更のリードタイム 変更がコミットされてから本番環境で稼働するまでの所要時間 ハイ（11%） ミディアム（69%） ロー（19％） 変更のリードタイム 1日〜1週間 1週間〜1ヶ月 1ヶ月〜6ヶ月 ※ 2022 State of DevOps Report より コミット CI レビュー … デプロイ … CI コミット …
16. 変更のリードタイム 改善の例 • バリューストリームマップを書いてボトルネックを発見 • よくあるボトルネックへの対処 ◦ CIの高速化 ◦ 即レビュー文化などでレビューリードタイムの短縮 ◦ 計画によって作業単位とリリース単位を小さくする ◦ フィーチャートグルなどで本番反映と提供を分離 ◦ QA作業の軽量化 ◦ リリースフローの最適化
17. デプロイ頻度 本番環境へのリリースの頻度 • 小さいバッチサイズで数を打てているか • 変更のリードタイムだけだと「月に1件だが超早い」があり得る ◦ 逆にデプロイ頻度だけでも歪んだ状況は想定できる ハイ（11%） ミディアム（69%） ロー（19％） デプロイ頻度 オンデマンドに 1日複数回 1週間〜1ヶ月に1回 1ヶ月〜6ヶ月に1回 ※ 2022 State of DevOps Report より
18. デプロイ頻度 改善の例 • 変更のリードタイムを改善することで同時に改善する • プロダクトマネジメント領域の改善も重要 ◦ 数を打つにはもとになる企画が潤沢に必要 ◦ MVPから始める文化や段階的なリリースの計画 結果としてプロダクトのフィードバックループが改善する。Four Keysがアウトカ ムへの接続を意識している点が表れている
19. 変更失敗率 主要なアプリケーションやサービスに施した変更のうち、サービス低下を招い たケースや修正作業が必要となったケース（サービス機能の障害や稼働停止 を招いてしまったケースや、ホットフィックス、ロールバック、フィックスフォワード [事態改善のために通常の手順を踏んだ修正]）、パッチが必要となったケース の発生率 LeanとDevOpsの科学 p24より抜粋 ※強調と下線は登壇者によるもの
20. 変更失敗率、要は 意図通り動かないコードをリリースした割合 • 「変更障害率」とする文献もあるが、デリバリーの安定性を示す指標として は障害を伴わない失敗も含めた方が妥当 • 障害の方が計測しやすいのでそちらから始める手もある ハイ（11%） ミディアム（69%） ロー（19％） 変更失敗率 0%〜15% 16%〜30% 46%〜60% ※ 2022 State of DevOps Report より
21. 変更失敗率、侮るなかれ 変更の リードタイム 次の開発へ 変更の リードタイム 変更の リードタイム 変更の リードタイム 次の開発へ • N回失敗すれば実質的な変更のリードタイムはN+1倍 • 全体のアウトカムの観点で見れば、デリバリーの安定性もまたスループッ トを大きく改善する 成功 失敗 失敗 成功
22. 変更失敗率 改善の例 • 変更を簡単にする ◦ 作業単位とリリース単位を小さくする ◦ 高凝集で疎結合なアーキテクチャ、モジュール • 失敗を未然に防ぐ ◦ 継続的なテスト ◦ コードレビュー ◦ 変更を適切に加えるための能力獲得を支援する ▪ ドキュメント、トレーニング
23. 平均修復時間（MTTR） 障害から復旧するまでにかかる平均の時間 • サービス低下や機能的な障害が対象 • 障害を完全に無くすのではなく、いかに早く復旧するか ハイ（11%） ミディアム（69%） ロー（19％） 平均修復時間 1日以内 1日〜1週間 1週間〜1ヶ月 ※ 2022 State of DevOps Report より
24. 平均修復時間（MTTR） 改善の例 • Observabilityの向上 ◦ 監視によって障害の予兆や障害状態を通知 ◦ ログ、メトリック、トレーシングで原因を特定 • ロールバックの仕組みの整備 ◦ 変更起因の障害を安定して修復可能になる • 障害対応訓練や障害対応テンプレートの整備
25. アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
26. 信頼性 - 5番目のキーメトリック • 運用パフォーマンスを表す「信頼性」が近年追加された ◦ Site Reliability Engineeringの”Reliablity” ◦ 「信頼性の目標を達成している度合い」で計測 • 運用パフォーマンスが低い場合は、Four Keys（デリバリーパフォーマン ス）が組織パフォーマンスに繋がりづらいとわかった ◦ 直感的には「いくら素早く機能を出しても使えなかったりパフォーマン スが悪かったりしたら意味がない」 ◦ デリバリー改善とSREは両輪
27. その他フォーカスされているトピック • DevOpsの能力がこれまで見た側面以外にも好影響を与える可能性 ◦ 燃え尽き症候群の軽減 ◦ 他人にチームを勧める割合の向上 • 改善効果の高い能力 ◦ ドキュメンテーション ◦ サプライチェーンのセキュリティへの投資 ◦ クラウドの活用 ※詳細は近年のState of DevOps Reportを参照ください
28. 有力な計測方法 • https://github.com/GoogleCloudPlatform/fourkeys ◦ Google Cloudが提供するETLパイプライン • Findy Teams ◦ GitHubやGitLab、Jiraなどエンジニア向けツールを解析すること で、エンジニアリング組織の生産性を可視化するサービス • その他、様々な企業で独自の事例 ◦ 「Four Keys」などで検索ください
29. まとめ - Four Keysの基礎と重要性 • Four Keysとはソフトウェアデリバリーのパフォーマンスを示す以下の4つ の指標である ◦ スループット: 変更のリードタイム デプロイ頻度 ◦ 安定性: 変更失敗率 平均修復時間 • 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパ フォーマンスと関係があるとわかった指標である • Four Keysにトレードオフはない: スループットと安定性の両方を建設的に 改善していく枠組みとして機能する