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
34
24k
30分でわかるFour Keysの基礎と重要性
ソフトウェアデリバリーのパフォーマンスを示す4つの指標であるFour Keysについて、指標の成り立ち、改善する意義、各指標への向き合い方、近年の動向などを網羅的に解説しました。
Yuu Igarashi
October 28, 2022
Tweet
Share
More Decks by Yuu Igarashi
See All by Yuu Igarashi
EM、会計を学ぶ
yigarashi
0
260
自己組織化の真価を引き出す EM of EMsのしごと
yigarashi
2
560
プロダクトマネージャーがアジャイルに習熟して生まれた強いチームの話
yigarashi
0
1.3k
はてなEMキャリアパス 最速攻略RTA 新卒部門
yigarashi
3
2.4k
スクラムで作る頼もしく生き生きとしたチーム / The lively trustworthy team by scrum
yigarashi
4
7.9k
Hatena Engineer Seminar #14 GraphQL編
yigarashi
1
1.7k
GraphQL API を悪意あるクエリから守る手法
yigarashi
0
200
Other Decks in Technology
See All in Technology
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
1
16k
【令和最新版】ロボットシミュレータ Genesis x ROS 2で始める快適AIロボット開発
hakuturu583
2
1.5k
LangGraphとFlaskを用いた社内資料検索ボットの実装②Retriever構築編
aoikumadaki
0
100
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
1
5k
能動的ドメイン名ライフサイクル管理のすゝめ / Practice on Active Domain Name Lifecycle Management
nttcom
0
330
実践! ソフトウェアエンジニアリングの価値の計測 ── Effort、Output、Outcome、Impact
nomuson
0
1.7k
Storage Browser for Amazon S3を触ってみた + α
miura55
0
110
知っててうれしい HTTP Cookie を使ったセッション管理について
greendrop
1
110
Fabric 移行時の躓きポイントと対応策
ohata_ds
1
140
深層学習と3Dキャプチャ・3Dモデル生成(土木学会応用力学委員会 応用数理・AIセミナー)
pfn
PRO
0
420
20240513 - 框裡框外_文學院學生如何在AI世代安身立命 @ 淡江大學
dpys
0
630
Unlearn Product Development - Unleashed Edition
lemiorhan
PRO
2
170
Featured
See All Featured
Making Projects Easy
brettharned
116
6k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
28
2.2k
Testing 201, or: Great Expectations
jmmastey
41
7.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
Building Applications with DynamoDB
mza
92
6.1k
The Cult of Friendly URLs
andyhume
78
6.1k
Making the Leap to Tech Lead
cromwellryan
133
9k
Visualization
eitanlees
146
15k
Code Reviewing Like a Champion
maltzj
521
39k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
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にトレードオフはない: スループットと安定性の両方を建設的に 改善していく枠組みとして機能する