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

by Yuu Igarashi

Slide 1

Slide 1 text

30分でわかる Four Keysの基礎と重要性 2022/10/27 Four Keysで進める改善サイクル - Techmee vol.4 株式会社はてな Webアプリケーションエンジニア yigarashi

Slide 2

Slide 2 text

自己紹介 ● 五十嵐雄（いがらしゆう）/ id:yigarashi / @yigarashi_9 ● 株式会社はてな Webアプリケーションエンジニア ● yigarashiのブログで学びを発信しています ○ エンジニアリングマネージャーを目指す若者の戦略 ○ Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善する方法について ■ このエントリーがきっかけでお声がけいただくことに！

Slide 3

Slide 3 text

イントロダクション「もっと成果を出したい」「ハイパフォーマンスな開発をやっていくぞ」「生産性の高いチームを目指しましょう」 🤔いったい何をどうすれば……？

Slide 4

Slide 4 text

ソフトウェア開発を取り巻く複雑な環境 ● 生産性としてどの指標を見たらよい？ ○ 変更行数ベロシティコミット数プルリクエスト数リリース回数プロジェクト完了までの期間事業のKPI 売上 etc… ● どんなプラクティスにどんな効果がある？ ○ リファクタリングテスト CI/CD モブプロレビュー QA スクラムカンバンタスク分割チームトポロジー etc…

Slide 5

Slide 5 text

DORA - DevOps Research and Assesment ● 学術的な手法を用いてソフトウェア開発やデリバリーの状況を改善することを目指す研究プロジェクト ● 2013年から毎年「State of DevOps Report」を報告 ● 「LeanとDevOpsの科学」は2014〜2017のレポートをまとめたもの ● 2018年にGoogleが買収しGoogle Cloudから継続して情報発信 ○ DevOps とは: 研究とソリューション | Google Cloud ○ DORA research program

Slide 6

Slide 6 text

Four Keys DORAが提唱するデリバリーパフォーマンスを示す4つの指標指標定義変更のリードタイム変更のコミットから本番環境へのデプロイまでの時間デプロイ頻度本番環境へのリリース頻度変更失敗率意図通り動かないコードをリリースした割合（※要約）平均修復時間障害から復旧するまでの平均時間

Slide 7

Slide 7 text

アジェンダ ● Four Keysを計測し改善する意義 ● 各指標と改善効果の高い取り組みの例 ● 近年の動向

Slide 8

Slide 8 text

Four Keysがなぜこの定義なのか職能横断のアウトカムを意図してトップダウンに注意深く選定された ● バリューストリームのスループットが高いか ○ 変更のリードタイム ○ デプロイ頻度 ● 安定してデリバリーを続けているか ○ 変更失敗率 ○ 平均修復時間

Slide 9

Slide 9 text

Four Keysと組織のパフォーマンス ● 単に「注意深く選定した」では説得力がない ● DORAはFour Keysの尤もらしさを学術的な手法で明らかにした ○ Four Keysに関する回答をクラスタリング分析 ○ 浮かび上がった3クラスタでFour Keysのスコアに有意な差 ○ ハイ/ミドル/ローパフォーマーの発見 ● ハイパフォーマーほど組織のパフォーマンス（収益性や市場占有率、目標の達成度合いなど）も高いとわかった

Slide 10

Slide 10 text

Four Keysにトレードオフはない ● Four Keysは直感的にはトレードオフが見出せる ○ スループット: 変更のリードタイムデプロイ頻度 ○ 安定性: 変更失敗率平均修復時間 ● しかし発見されたハイパフォーマーは4指標全てで抜きん出ていた ● スループットと安定性の両方を改善する優れたプラクティスを採用することが重要

Slide 11

Slide 11 text

特に有効性が示されたプラクティス・能力 ● DORAはFour Keysや組織パフォーマンスの改善に有効なプラクティス・能力を統計的に特定してきた ● LeanとDevOpsの科学では「24のケイパビリティ」 ● DevOps の能力 | Google Cloud ○ 2022/10/16現在は27の能力が示されている ○ 技術・プロセス・測定・文化の4軸 ● Four Keysを土台にすることで、選りすぐりのプラクティスに後ろ盾がある状態から始められる

Slide 12

Slide 12 text

手法の効果を説明する枠組みとして例題: リファクタリングはどんな効果があるのか ● 変更のリードタイム: 変更を加えやすくなり短縮 ● デプロイ頻度: 疎結合になることでより小さくリリースが可能 ● 変更失敗率: コードを理解しやすくなりミスが減少 ● 平均修復時間: コードを理解しやすくなり原因の特定が容易に適切なリファクタリングがデリバリーパフォーマンスの向上につながることを分解して体系的に説明できた

Slide 13

Slide 13 text

まとめ: Four Keysを計測し改善する意義 ● 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパフォーマンスと関係があるとわかった指標である ● Four Keysにトレードオフはない: スループットと安定性の両方を改善する優れたプラクティスの実践を促す ● 様々なプラクティスを定性・定量の両側面で評価しやすくなり建設的に議論を進められる

Slide 14

Slide 14 text

アジェンダ ● Four Keysを計測し改善する意義 ● 各指標と改善効果の高い取り組みの例 ● 近年の動向

Slide 15

Slide 15 text

変更のリードタイム変更がコミットされてから本番環境で稼働するまでの所要時間ハイ（11%）ミディアム（69%）ロー（19％）変更のリードタイム 1日〜1週間 1週間〜1ヶ月 1ヶ月〜6ヶ月 ※ 2022 State of DevOps Report よりコミット CI レビュー … デプロイ … CI コミット …

Slide 16

Slide 16 text

変更のリードタイム改善の例 ● バリューストリームマップを書いてボトルネックを発見 ● よくあるボトルネックへの対処 ○ CIの高速化 ○ 即レビュー文化などでレビューリードタイムの短縮 ○ 計画によって作業単位とリリース単位を小さくする ○ フィーチャートグルなどで本番反映と提供を分離 ○ QA作業の軽量化 ○ リリースフローの最適化

Slide 17

Slide 17 text

デプロイ頻度本番環境へのリリースの頻度 ● 小さいバッチサイズで数を打てているか ● 変更のリードタイムだけだと「月に1件だが超早い」があり得る ○ 逆にデプロイ頻度だけでも歪んだ状況は想定できるハイ（11%）ミディアム（69%）ロー（19％）デプロイ頻度オンデマンドに 1日複数回 1週間〜1ヶ月に1回 1ヶ月〜6ヶ月に1回 ※ 2022 State of DevOps Report より

Slide 18

Slide 18 text

デプロイ頻度改善の例 ● 変更のリードタイムを改善することで同時に改善する ● プロダクトマネジメント領域の改善も重要 ○ 数を打つにはもとになる企画が潤沢に必要 ○ MVPから始める文化や段階的なリリースの計画結果としてプロダクトのフィードバックループが改善する。Four Keysがアウトカムへの接続を意識している点が表れている

Slide 19

Slide 19 text

変更失敗率主要なアプリケーションやサービスに施した変更のうち、サービス低下を招いたケースや修正作業が必要となったケース（サービス機能の障害や稼働停止を招いてしまったケースや、ホットフィックス、ロールバック、フィックスフォワード [事態改善のために通常の手順を踏んだ修正]）、パッチが必要となったケースの発生率 LeanとDevOpsの科学 p24より抜粋 ※強調と下線は登壇者によるもの

Slide 20

Slide 20 text

変更失敗率、要は意図通り動かないコードをリリースした割合 ● 「変更障害率」とする文献もあるが、デリバリーの安定性を示す指標としては障害を伴わない失敗も含めた方が妥当 ● 障害の方が計測しやすいのでそちらから始める手もあるハイ（11%）ミディアム（69%）ロー（19％）変更失敗率 0%〜15% 16%〜30% 46%〜60% ※ 2022 State of DevOps Report より

Slide 21

Slide 21 text

変更失敗率、侮るなかれ変更のリードタイム次の開発へ変更のリードタイム変更のリードタイム変更のリードタイム次の開発へ ● N回失敗すれば実質的な変更のリードタイムはN+1倍 ● 全体のアウトカムの観点で見れば、デリバリーの安定性もまたスループットを大きく改善する成功失敗失敗成功

Slide 22

Slide 22 text

変更失敗率改善の例 ● 変更を簡単にする ○ 作業単位とリリース単位を小さくする ○ 高凝集で疎結合なアーキテクチャ、モジュール ● 失敗を未然に防ぐ ○ 継続的なテスト ○ コードレビュー ○ 変更を適切に加えるための能力獲得を支援する ■ ドキュメント、トレーニング

Slide 23

Slide 23 text

平均修復時間（MTTR）障害から復旧するまでにかかる平均の時間 ● サービス低下や機能的な障害が対象 ● 障害を完全に無くすのではなく、いかに早く復旧するかハイ（11%）ミディアム（69%）ロー（19％）平均修復時間 1日以内 1日〜1週間 1週間〜1ヶ月 ※ 2022 State of DevOps Report より

Slide 24

Slide 24 text

平均修復時間（MTTR）改善の例 ● Observabilityの向上 ○ 監視によって障害の予兆や障害状態を通知 ○ ログ、メトリック、トレーシングで原因を特定 ● ロールバックの仕組みの整備 ○ 変更起因の障害を安定して修復可能になる ● 障害対応訓練や障害対応テンプレートの整備

Slide 25

Slide 25 text

アジェンダ ● Four Keysを計測し改善する意義 ● 各指標と改善効果の高い取り組みの例 ● 近年の動向

Slide 26

Slide 26 text

信頼性 - 5番目のキーメトリック ● 運用パフォーマンスを表す「信頼性」が近年追加された ○ Site Reliability Engineeringの”Reliablity” ○ 「信頼性の目標を達成している度合い」で計測 ● 運用パフォーマンスが低い場合は、Four Keys（デリバリーパフォーマンス）が組織パフォーマンスに繋がりづらいとわかった ○ 直感的には「いくら素早く機能を出しても使えなかったりパフォーマンスが悪かったりしたら意味がない」 ○ デリバリー改善とSREは両輪

Slide 27

Slide 27 text

その他フォーカスされているトピック ● DevOpsの能力がこれまで見た側面以外にも好影響を与える可能性 ○ 燃え尽き症候群の軽減 ○ 他人にチームを勧める割合の向上 ● 改善効果の高い能力 ○ ドキュメンテーション ○ サプライチェーンのセキュリティへの投資 ○ クラウドの活用 ※詳細は近年のState of DevOps Reportを参照ください

Slide 28

Slide 28 text

有力な計測方法 ● https://github.com/GoogleCloudPlatform/fourkeys ○ Google Cloudが提供するETLパイプライン ● Findy Teams ○ GitHubやGitLab、Jiraなどエンジニア向けツールを解析することで、エンジニアリング組織の生産性を可視化するサービス ● その他、様々な企業で独自の事例 ○ 「Four Keys」などで検索ください

Slide 29

Slide 29 text

まとめ - Four Keysの基礎と重要性 ● Four Keysとはソフトウェアデリバリーのパフォーマンスを示す以下の4つの指標である ○ スループット: 変更のリードタイムデプロイ頻度 ○ 安定性: 変更失敗率平均修復時間 ● 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパフォーマンスと関係があるとわかった指標である ● Four Keysにトレードオフはない: スループットと安定性の両方を建設的に改善していく枠組みとして機能する