Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
30分でわかるFour Keysの基礎と重要性
Search
Yuu Igarashi
October 28, 2022
Technology
33
22k
30分でわかるFour Keysの基礎と重要性
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
Yuu Igarashi
October 28, 2022
Tweet
Share
More Decks by Yuu Igarashi
See All by Yuu Igarashi
自己組織化の真価を引き出す EM of EMsのしごと
yigarashi
2
360
プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
yigarashi
0
1.1k
はてなEMキャリアパス 最速攻略RTA 新卒部門
yigarashi
2
2.1k
スクラムで作る頼もしく生き生きとしたチーム / The lively trustworthy team by scrum
yigarashi
4
7.8k
Hatena Engineer Seminar #14 GraphQL編
yigarashi
1
1.6k
GraphQL API を悪意あるクエリから守る手法
yigarashi
0
170
Other Decks in Technology
See All in Technology
JEP 480: Structured Concurrency
aya_ebata
0
130
ナレッジグラフとLLMの相互利用
koujikozaki
0
340
四国クラウドお遍路 2024 in 高知 オープニング
yukataoka
0
190
スタッフエンジニアの道: The Staff Engineer’s Path
snoozer05
PRO
41
13k
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
6
1.3k
なぜクラウドサービスで Web コンソールを提供するのか
shuta13
4
2k
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
15
40k
「自動テストのプラクティスを効果的に学ぶためのカードゲーム」 ( #sqip2024 )
teyamagu
PRO
1
160
The XZ Backdoor Story
fr0gger
0
3.5k
ビジネスとエンジニアリングを繋ぐプロダクトを中心とした組織づくりの実践
sansantech
PRO
1
170
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
110
contenteditableと向き合う
kikuchikakeru
2
290
Featured
See All Featured
Building Adaptive Systems
keathley
36
2.1k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
166
48k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
KATA
mclloyd
27
13k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
227
52k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Build your cross-platform service in a week with App Engine
jlugia
228
18k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Statistics for Hackers
jakevdp
793
220k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
Transcript
30分でわかる Four Keysの基礎と重要性 2022/10/27 Four Keysで進める改善サイクル - Techmee vol.4 株式会社はてな
Webアプリケーションエンジニア yigarashi
自己紹介 • 五十嵐 雄(いがらし ゆう)/ id:yigarashi / @yigarashi_9 • 株式会社はてな
Webアプリケーションエンジニア • yigarashiのブログ で学びを発信しています ◦ エンジニアリングマネージャーを目指す若者の戦略 ◦ Four Keysがなぜ重要なのか - 開発チームのパフォーマンスを改善 する方法について ▪ このエントリーがきっかけでお声がけいただくことに!
イントロダクション 「もっと成果を出したい」 「ハイパフォーマンスな開発をやっていくぞ」 「生産性の高いチームを目指しましょう」 🤔いったい何をどうすれば……?
ソフトウェア開発を取り巻く複雑な環境 • 生産性としてどの指標を見たらよい? ◦ 変更行数 ベロシティ コミット数 プルリクエスト数 リリース回数 プロ
ジェクト完了までの期間 事業のKPI 売上 etc… • どんなプラクティスにどんな効果がある? ◦ リファクタリング テスト CI/CD モブプロ レビュー QA スクラム カンバ ン タスク分割 チームトポロジー etc…
DORA - DevOps Research and Assesment • 学術的な手法を用いてソフトウェア開発やデリバリーの状況を改善するこ とを目指す研究プロジェクト •
2013年から毎年「State of DevOps Report」を報告 • 「LeanとDevOpsの科学」は2014〜2017のレポートをまとめたもの • 2018年にGoogleが買収しGoogle Cloudから継続して情報発信 ◦ DevOps とは: 研究とソリューション | Google Cloud ◦ DORA research program
Four Keys DORAが提唱するデリバリーパフォーマンスを示す4つの指標 指標 定義 変更のリードタイム 変更のコミットから本番環境へのデプロイまでの時間 デプロイ頻度 本番環境へのリリース頻度 変更失敗率
意図通り動かないコードをリリースした割合(※要約) 平均修復時間 障害から復旧するまでの平均時間
アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
Four Keysがなぜこの定義なのか 職能横断のアウトカムを意図してトップダウンに注意深く選定された • バリューストリームのスループットが高いか ◦ 変更のリードタイム ◦ デプロイ頻度 •
安定してデリバリーを続けているか ◦ 変更失敗率 ◦ 平均修復時間
Four Keysと組織のパフォーマンス • 単に「注意深く選定した」では説得力がない • DORAはFour Keysの尤もらしさを学術的な手法で明らかにした ◦ Four Keysに関する回答をクラスタリング分析
◦ 浮かび上がった3クラスタでFour Keysのスコアに有意な差 ◦ ハイ/ミドル/ロー パフォーマーの発見 • ハイパフォーマーほど組織のパフォーマンス(収益性や市場占有率、目標 の達成度合いなど)も高いとわかった
Four Keysにトレードオフはない • Four Keysは直感的にはトレードオフが見出せる ◦ スループット: 変更のリードタイム デプロイ頻度 ◦
安定性: 変更失敗率 平均修復時間 • しかし発見されたハイパフォーマーは4指標全てで抜きん出ていた • スループットと安定性の両方を改善する優れたプラクティスを採用すること が重要
特に有効性が示されたプラクティス・能力 • DORAはFour Keysや組織パフォーマンスの改善に有効なプラクティス・ 能力を統計的に特定してきた • LeanとDevOpsの科学では「24のケイパビリティ」 • DevOps の能力
| Google Cloud ◦ 2022/10/16現在は27の能力が示されている ◦ 技術・プロセス・測定・文化の4軸 • Four Keysを土台にすることで、選りすぐりのプラクティスに後ろ盾がある 状態から始められる
手法の効果を説明する枠組みとして 例題: リファクタリングはどんな効果があるのか • 変更のリードタイム: 変更を加えやすくなり短縮 • デプロイ頻度: 疎結合になることでより小さくリリースが可能 •
変更失敗率: コードを理解しやすくなりミスが減少 • 平均修復時間: コードを理解しやすくなり原因の特定が容易に 適切なリファクタリングがデリバリーパフォーマンスの向上につながることを分 解して体系的に説明できた
まとめ: Four Keysを計測し改善する意義 • 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパ フォーマンスと関係があるとわかった指標である • Four Keysにトレードオフはない: スループットと安定性の両方を改善する
優れたプラクティスの実践を促す • 様々なプラクティスを定性・定量の両側面で評価しやすくなり建設的に議 論を進められる
アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
変更のリードタイム 変更がコミットされてから本番環境で稼働するまでの所要時間 ハイ(11%) ミディアム(69%) ロー(19%) 変更のリードタイム 1日〜1週間 1週間〜1ヶ月 1ヶ月〜6ヶ月 ※
2022 State of DevOps Report より コミット CI レビュー … デプロイ … CI コミット …
変更のリードタイム 改善の例 • バリューストリームマップを書いてボトルネックを発見 • よくあるボトルネックへの対処 ◦ CIの高速化 ◦ 即レビュー文化などでレビューリードタイムの短縮
◦ 計画によって作業単位とリリース単位を小さくする ◦ フィーチャートグルなどで本番反映と提供を分離 ◦ QA作業の軽量化 ◦ リリースフローの最適化
デプロイ頻度 本番環境へのリリースの頻度 • 小さいバッチサイズで数を打てているか • 変更のリードタイムだけだと「月に1件だが超早い」があり得る ◦ 逆にデプロイ頻度だけでも歪んだ状況は想定できる ハイ(11%) ミディアム(69%)
ロー(19%) デプロイ頻度 オンデマンドに 1日複数回 1週間〜1ヶ月に1回 1ヶ月〜6ヶ月に1回 ※ 2022 State of DevOps Report より
デプロイ頻度 改善の例 • 変更のリードタイムを改善することで同時に改善する • プロダクトマネジメント領域の改善も重要 ◦ 数を打つにはもとになる企画が潤沢に必要 ◦ MVPから始める文化や段階的なリリースの計画
結果としてプロダクトのフィードバックループが改善する。Four Keysがアウトカ ムへの接続を意識している点が表れている
変更失敗率 主要なアプリケーションやサービスに施した変更のうち、サービス低下を招い たケースや修正作業が必要となったケース(サービス機能の障害や稼働停止 を招いてしまったケースや、ホットフィックス、ロールバック、フィックスフォワード [事態改善のために通常の手順を踏んだ修正])、パッチが必要となったケース の発生率 LeanとDevOpsの科学 p24より抜粋 ※強調と下線は登壇者によるもの
変更失敗率、要は 意図通り動かないコードをリリースした割合 • 「変更障害率」とする文献もあるが、デリバリーの安定性を示す指標として は障害を伴わない失敗も含めた方が妥当 • 障害の方が計測しやすいのでそちらから始める手もある ハイ(11%) ミディアム(69%) ロー(19%)
変更失敗率 0%〜15% 16%〜30% 46%〜60% ※ 2022 State of DevOps Report より
変更失敗率、侮るなかれ 変更の リードタイム 次の開発へ 変更の リードタイム 変更の リードタイム 変更の リードタイム
次の開発へ • N回失敗すれば実質的な変更のリードタイムはN+1倍 • 全体のアウトカムの観点で見れば、デリバリーの安定性もまたスループッ トを大きく改善する 成功 失敗 失敗 成功
変更失敗率 改善の例 • 変更を簡単にする ◦ 作業単位とリリース単位を小さくする ◦ 高凝集で疎結合なアーキテクチャ、モジュール • 失敗を未然に防ぐ
◦ 継続的なテスト ◦ コードレビュー ◦ 変更を適切に加えるための能力獲得を支援する ▪ ドキュメント、トレーニング
平均修復時間(MTTR) 障害から復旧するまでにかかる平均の時間 • サービス低下や機能的な障害が対象 • 障害を完全に無くすのではなく、いかに早く復旧するか ハイ(11%) ミディアム(69%) ロー(19%) 平均修復時間
1日以内 1日〜1週間 1週間〜1ヶ月 ※ 2022 State of DevOps Report より
平均修復時間(MTTR) 改善の例 • Observabilityの向上 ◦ 監視によって障害の予兆や障害状態を通知 ◦ ログ、メトリック、トレーシングで原因を特定 • ロールバックの仕組みの整備
◦ 変更起因の障害を安定して修復可能になる • 障害対応訓練や障害対応テンプレートの整備
アジェンダ • Four Keysを計測し改善する意義 • 各指標と改善効果の高い取り組みの例 • 近年の動向
信頼性 - 5番目のキーメトリック • 運用パフォーマンスを表す「信頼性」が近年追加された ◦ Site Reliability Engineeringの”Reliablity” ◦
「信頼性の目標を達成している度合い」で計測 • 運用パフォーマンスが低い場合は、Four Keys(デリバリーパフォーマン ス)が組織パフォーマンスに繋がりづらいとわかった ◦ 直感的には「いくら素早く機能を出しても使えなかったりパフォーマン スが悪かったりしたら意味がない」 ◦ デリバリー改善とSREは両輪
その他フォーカスされているトピック • DevOpsの能力がこれまで見た側面以外にも好影響を与える可能性 ◦ 燃え尽き症候群の軽減 ◦ 他人にチームを勧める割合の向上 • 改善効果の高い能力 ◦
ドキュメンテーション ◦ サプライチェーンのセキュリティへの投資 ◦ クラウドの活用 ※詳細は近年のState of DevOps Reportを参照ください
有力な計測方法 • https://github.com/GoogleCloudPlatform/fourkeys ◦ Google Cloudが提供するETLパイプライン • Findy Teams ◦
GitHubやGitLab、Jiraなどエンジニア向けツールを解析すること で、エンジニアリング組織の生産性を可視化するサービス • その他、様々な企業で独自の事例 ◦ 「Four Keys」などで検索ください
まとめ - Four Keysの基礎と重要性 • Four Keysとはソフトウェアデリバリーのパフォーマンスを示す以下の4つ の指標である ◦ スループット:
変更のリードタイム デプロイ頻度 ◦ 安定性: 変更失敗率 平均修復時間 • 職能横断のアウトカムを示すように注意深く選定され、実際に組織のパ フォーマンスと関係があるとわかった指標である • Four Keysにトレードオフはない: スループットと安定性の両方を建設的に 改善していく枠組みとして機能する