はじめに
この記事では、Four Keys を改めて整理し、
あわせて DORAの最新レポート を踏まえて、
「いまFour Keysをどう捉えるとよさそうか」をまとめます。
対象読者は、次のような方を想定しています。
- Four Keysという言葉は聞いたことがあるが、あまり使ったことはない
- スクラムチームで、ベロシティ以外の指標に悩んでいる
- DORAレポートの話題は気になっているが、全部は追えていない
Four Keysの詳細な測定方法やツール導入の話ではなく、
スクラムチームでどう向き合うかという視点で書いています。
ベロシティ以外の指標が欲しくなった
私は、6人（PO・SM含む）のスクラムチームでスクラムマスターをしています。
私たちのチームはスプリントを1日単位で回しており、
ベロシティだけでチームの状況を測ることに限界を感じています。
現状はこんな状態です。
- ベロシティは参考程度に見て、うまくいかなかった場合にチケット単位での振り返りはできている（「このチケットはここで詰まった」「ここはスムーズに進んだ」など）
- チケットの粒度などでベロシティは変わってしまい、全体としてチームの開発フローや問題の傾向を把握することは難しい
- 「作業量」は分かるが、「なぜうまくいった／いかなかったのか」は説明しづらい
ベロシティは「作業量」の目安にはなります。
一方で、チケットの粒度や分割の仕方によって数値が変わってしまうため、
それだけではチーム全体の開発の流れや、作業が滞った原因を把握することは難しいです。
そこで、ベロシティ以外の指標として有名な Four Keys を、
スクラムマスターの立場で改めて調べ直してみることにしました。
Four Keysを、できるだけ噛み砕いて整理する
Four Keysは、DORA（DevOps Research and Assessment）の提唱する、
ソフトウェアデリバリーのパフォーマンスを4つの観点から見る指標です。
DORA 2024レポートでは、Four Keysについて次のように定義されています：
“DORA’s Four Keys have been used to measure the throughput and stability of software changes...”
— Accelerate State of DevOps Report 2024
(dora.dev)
具体的には、
- Change lead time: the time it takes for a code commit or change to be successfully deployed to production
- Deployment frequency: how often application changes are deployed to production
- Change fail rate: the percentage of deployments that cause failures in production
- Failed deployment recovery time: the time it takes to recover from a failed deployment
といった4つの指標が、ソフトウェアデリバリーのスループットと安定性を見るために用いられています。
| 指標 | 何を見るか |
|---|---|
| 変更のリードタイム | コードのコミットから本番環境へのデプロイまでにかかる時間 |
| デプロイ頻度 | 変更を本番環境にデプロイする頻度 |
| 変更失敗率 | 本番で障害やロールバックが発生したデプロイの割合 |
| 平均復旧時間（MTTR） | デプロイ失敗や障害が発生してから復旧するまでの時間 |
ベロシティが「どれだけ作れたか（量）」を見る指標だとすると、
Four Keysは、
- 開発がどんな流れで進んでいるか
- どれくらい安心して変更できているか
を見るための指標だと理解しました。
ベロシティでは見えなかった問い
改めてFour Keysを調べて気づいたのは、
ベロシティのように作業量を見るだけではなく、
チームの開発の流れや、問題が起きやすい箇所を捉えるための指標だ ということです。
例えば、
- なぜ今スプリントはリリースできなかったのか
- どこで待ちや手戻りが発生しやすいのか
- 安全に変更できていると言えるのか
こうした問いは、ベロシティだけを見ていても自然には出てきません。
Four Keysを知ったことで、
量ではなく“流れ”を言語化する視点が不足していたのかもしれないと思いました。
DORA最新レポートから見た、いまのFour Keys
2025年のDORA最新レポートでは、
AIを利用した開発が大きなテーマとして扱われています。
さらに、AI活用そのものよりも、
「どうすれば価値を引き出せるか」が重要な問いになっていると述べられています。
ここで強調されているのは、
AIそのものではなく、組織や開発プロセスの土台です。
- ワークフローは明確か
- チーム間の連携は取れているか
- 変更がどのような流れで本番まで届いているか
こうした土台が整っていなければ、AIによって一時的に生産性が上がっても、
その効果は後工程の混乱の中で失われてしまう、とDORAは指摘しています。
この話は、Four Keysの位置づけを考えるうえでも非常に示唆的だと感じました。
Four Keysは、
「AIを使えば速くなるか」を測る指標ではありません。
そもそもチームの開発フローが健全に流れているか、安定しているかを捉えるための指標です。
つまり最新のDORAレポートを踏まえると、Four Keysは
評価のためのKPIというよりも、
- ワークフローは本当に明確か
- 変更はスムーズに流れているか
- 問題が起きたときに立て直せる状態か
といった、開発組織の土台を確認するための観測手段として捉えるのが自然だと感じました。
まとめ
DORAの最新レポートが示しているように、
指標やツールは、それ自体が成果を生むものではありません。
まずはチームの前提や開発の流れを整理し、
「自分たちは今どんな状態にあるのか」を考えられるようになることが重要だと整理できました。
現時点で、私たちのチームはまだFour Keysを厳密に計測できていません。
それでも、開発の「流れ」や「安全性」を、
今後どう扱っていくかを考え始めるきっかけにはなったと感じています。