DevOps効果測定とDORA 4指標
DevOps の効果をどう測るか — Four Keys（DORA 4指標）でカイゼンを回す
DevOps 推進で難しいのは、「良くなっている気がする」を組織の意思決定に使える形へ変えることです。リリースは速くなったのか、障害は減ったのか、復旧は早くなったのか。これらを印象で語ると、議論は部門間の主張合戦になりがちです。
そこで役立つのが Four Keys、つまり DORA 4指標です。この記事では、DevOps の成果を測る代表的な指標を整理し、推進担当がどこから計測を始めるべきかを考えます。
なぜ DevOps で「測定」が重要なのか
DevOps の考え方を整理する CALMS には、Culture / Automation / Lean / Measurement / Sharing の 5要素があります。このうち Measurement は、改善を「感覚」ではなく「データ」で扱うための軸です。
現場への影響は大きく、測定があると次の会話ができます。
- リリース承認がボトルネックなのか
- レビュー待ちが長いのか
- デプロイ後の障害が多いのか
- 復旧の初動が遅いのか
筆者の見方では、測定は現場を監視するための道具ではなく、改善の会話をそろえるための共通言語です。特にリーダー層にとっては、施策の優先順位や投資対効果を説明する材料になります。
背景として、近年は可観測性、SRE、プラットフォームエンジニアリングの取り組みと DevOps 指標が接続されつつあります。単に「パイプラインを作る」段階から、「デリバリ全体を継続的に改善する」段階へ関心が移っているためです。
Four Keys / DORA 4指標の全体像
DORA 4指標は、ソフトウェアデリバリの能力を次の 4つで見る考え方です。
| 指標 | 見ているもの | 主なデータ源 |
|---|---|---|
| デプロイ頻度 | どれだけ頻繁に本番へ出せるか | CDツール、デプロイ履歴 |
| 変更のリードタイム | 変更が本番に届くまでの速さ | Git、PR、デプロイ履歴 |
| 変更失敗率 | デプロイが障害や修正対応につながる割合 | インシデント管理、ロールバック履歴 |
| 平均復旧時間 | 障害からどれだけ早く回復できるか | 監視、インシデント管理 |
この 4つは、スループット系と安定性系の 2軸に分けると理解しやすくなります。
重要なのは、速さと安定性をトレードオフとして扱いすぎないことです。小さく頻繁に変更できる組織は、問題が起きたときの切り戻しや影響範囲の特定もしやすくなります。つまり、速く出すことが安定性を下げるとは限りません。
なお、DORA の指標体系は更新され続けており、近年は 5メトリクスモデルとして説明される場面もあります。ただし Four Keys は今も現場で通じやすい入口であり、基本編として押さえる価値があります。
1. デプロイ頻度
デプロイ頻度は、一定期間に本番へ何回デプロイしたかを見る指標です。測る際は「本番環境への成功デプロイ」を数えるのが扱いやすいでしょう。
デプロイ頻度が低い組織では、リリースが大きなイベントになりやすく、関係者調整、手順確認、深夜対応などの負荷が増えます。結果として、さらにリリースしづらくなる悪循環が生まれます。
筆者としては、デプロイ頻度は単独の目標にするより、改善の結果として見るのが健全だと考えます。無意味な変更で回数を増やしても顧客価値は増えません。背景にあるバッチサイズ、承認フロー、自動化の度合いを見るための入口として使うのがよいでしょう。
2. 変更のリードタイム
変更のリードタイムは、コード変更が本番に届くまでの時間です。よくある測り方は、merge to main → production、または first commit → production です。
実務では開始点で議論が起きます。first commit から測ると開発全体の実態に近づきますが、ブランチ戦略や作業の粒度に影響されます。一方、merge から測ると CI/CD やリリースプロセスの滞留が見えやすくなります。
推進担当としては、最初は merge から本番デプロイまでなど、定義しやすい範囲で始めるのが現実的です。リードタイムが長い箇所は、レビュー待ち、QA待ち、環境準備、承認待ちなど、改善対象の発見器になります。
3. 変更失敗率
変更失敗率は、デプロイのうち、ロールバック、ホットフィックス、障害対応などの介入を引き起こした割合です。速度偏重を防ぐためのブレーキ指標といえます。
測定で難しいのは、デプロイとインシデントを紐付けることです。リリースID、ビルド番号、デプロイIDをインシデントチケットに記録する運用があると、集計の信頼性が上がります。
この指標の価値は、品質投資の説明にあります。自動テスト、段階的リリース、ロールバック整備などは、短期的には手間に見えます。しかし変更失敗率が高い状況では、オンコール負荷や手戻りコストを下げる有力な施策になります。
一方で、障害登録を避けて数値をよく見せる運用になると、指標はすぐに壊れます。失敗を責める文化ではなく、失敗から学ぶ文化とセットで扱うべきです。
4. 平均復旧時間（MTTR / 障害復旧時間）
平均復旧時間は、障害が起きてからサービスが回復するまでの時間です。DORA では近年、デプロイ起因の失敗からの回復時間に寄せた定義も使われています。現場では従来の MTTR、つまりサービス復旧時間として運用されることも多いでしょう。
実務上は、どの時刻を使うかを明確にすることが大切です。
- 障害開始
- 検知
- 影響範囲の把握
- 緩和
- 復旧
- 恒久対応
たとえば「検知から復旧」だけを見ると、監視改善で検知が早くなった結果、数値が悪化して見えることがあります。筆者の意見では、MTTR は単一の数字よりも、検知・判断・緩和・復旧のどこに時間がかかっているかを見るほうが実務に効きます。
Elite / High / Medium / Low の使い方
DORA レポートでは、組織のデリバリ性能を Elite / High / Medium / Low といったレベルで分類してきました。推進担当は、自組織がどの層に近いかを見立てることで、最初の改善テーマを選びやすくなります。
| レベル | 状態の読み方 | 改善の着眼点 |
|---|---|---|
| Elite | 小さく高頻度に出せ、復旧も速い | 維持と横展開 |
| High | 日次〜週次で安定して出せる | 自動化と品質ゲート強化 |
| Medium | 手作業や待ち時間が残る | バッチサイズ削減 |
| Low | リリースが大型化し復旧も重い | デプロイ手順と責任分界の整理 |
ただし、ベンチマークは固定的に扱いすぎないほうがよいです。DORA の定義や分類は更新されますし、業界特性や規制要件によって目標値も変わります。他社比較よりも、自社が同じ定義で改善しているかを見るほうが価値があります。
指標の集め方と可視化
DORA 指標を集めるには、イベントを集約し、結合し、継続的に見る仕組みが要ります。Google の Four Keys ダッシュボードは参考実装として知られていますが、GitHub リポジトリは 2024年にアーカイブされています。現在は、既存の CI/CD、ITSM、可観測性基盤、BI ツールを組み合わせる現実解も多いです。
図のポイントは、見栄えのよいダッシュボードよりも、イベント定義と結合キーが先にあることです。デプロイ、マージ、障害の定義がチームごとに違うと、数値の信頼性が落ちます。
アンチパターン
DORA 指標は強力ですが、使い方を誤ると現場を傷つけます。
1つ目は指標ハックです。デプロイ頻度を増やすために意味の薄い変更を増やす、変更失敗率を下げるために障害登録を避ける、といった行動です。
2つ目はベロシティ偏重です。スループットだけを追うと、安定性やオンコール負荷が置き去りになります。短期的には速く見えても、疲弊によって長期の生産性は下がります。
3つ目は個人評価への悪用です。DORA 指標はチームやシステムの結果指標です。個人査定に直結させると、協力、正直な報告、学習の文化が壊れます。改善のための指標として扱う設計が重要です。
推進担当が最初に測り始める一歩
最初から全社で完璧なダッシュボードを作ろうとすると、定義調整だけで止まりがちです。まずは次の順で小さく始めるのがよいでしょう。
- 対象を 1サービス、1チームに絞る
- 本番、デプロイ、障害、復旧の定義を文章化する
- デプロイ履歴、Git、インシデント管理のデータ源を決める
- 手集計でもよいので週次で同じ方法で見る
- 最初の改善テーマを 1つ選ぶ
最初のテーマとしては、バッチサイズ削減が取り組みやすいです。変更を小さくすると、レビューしやすく、テストしやすく、障害時の切り戻しもしやすくなります。
今後は、生成AIによる変更量の増加、プラットフォームエンジニアリングの普及、セキュリティ要求の高まりにより、DORA 指標だけでなく SLO/SLI、脆弱性対応時間、開発者体験指標を組み合わせたスコアカード運用が広がるでしょう。DORA 4指標は、その土台となる「データで改善を回す」習慣を作るための、扱いやすい第一歩です。