フレームワーク活用ガイドひとことで言うと#
デプロイ頻度・リードタイム・変更失敗率・復旧時間の4つの指標で、ソフトウェアデリバリーの能力を定量的に測るフレームワーク。GoogleのDORA（DevOps Research and Assessment）チームが数万チームの調査から導き出した。
押さえておきたい用語#
- デプロイ頻度（Deployment Frequency）
- 本番環境にコードをデプロイする頻度。Eliteチームはオンデマンド（1日複数回）でデプロイする。
- リードタイム（Lead Time for Changes）
- コードをコミットしてから本番稼働するまでの時間のこと。短いほどフィードバックループが速い。
- 変更失敗率（Change Failure Rate）
- デプロイのうち、障害やロールバックを引き起こした割合。品質の指標として機能する。
- 復旧時間（Time to Restore Service）
- 障害が発生してからサービスが復旧するまでの時間を指す。レジリエンスの指標である。
- Elite / High / Medium / Low
- DORAが定義する4段階のパフォーマンスレベル。年次レポート「State of DevOps」で基準値が公表されている。
DORA指標の全体像#
こんな悩みに効く#
- 開発チームの生産性を測りたいが「コード行数」や「チケット数」では不十分
- DevOpsを導入したが、本当に改善されているのか数値で示せない
- 経営層に「開発チームに投資すべき理由」をデータで説明したい
基本の使い方#
まず現状を知る。データソースは以下。
- デプロイ頻度: CI/CDパイプラインのデプロイ履歴（GitHub Actions, CircleCI等）
- リードタイム: PRのマージからデプロイまでのタイムスタンプ差分
- 変更失敗率: デプロイ総数のうちホットフィックスやロールバックが発生した割合
- 復旧時間: インシデント管理ツール（PagerDuty, Opsgenie等）のMTTR
自動計測が理想だが、最初はスプレッドシートで手動集計でも十分。まず「見える化」することが最優先。
4つ同時に改善しようとしない。DORAの調査で明らかになった因果関係を参考に優先順位をつける。
- デプロイ頻度が低い場合: バッチサイズを小さくする→リードタイムも改善→連鎖的に他の指標も向上
- 変更失敗率が高い場合: テスト自動化とコードレビューの強化が先決
- 復旧時間が長い場合: 監視・アラートの整備とインシデント対応プロセスの改善
多くのチームにとって「デプロイ頻度を上げる」が最も他の指標へのレバレッジが大きい。
改善施策を打ったら四半期ごとに再計測する。
- ダッシュボードに4指標を常時表示する（Grafana, Datadog等）
- チームのレトロスペクティブでDORA指標の変化を共有する
- 1つのレベルが上がったら、次のボトルネック指標に焦点を移す
注意: DORA指標を個人の評価に使わない。あくまでチームやシステムのケイパビリティ指標として扱う。
具体例#
Google Cloud Platformの開発チーム（約80名）が、DORA指標でMediumからEliteに1年半で到達した事例。
初期計測時の状態:
| 指標 | 初期値 | レベル |
|---|---|---|
| デプロイ頻度 | 週1回 | Medium |
| リードタイム | 4日 | Medium |
| 変更失敗率 | 12% | Medium |
| 復旧時間 | 6時間 | High |
まずデプロイ頻度を上げることに集中した。PRのサイズを「変更行数200行以下」に制限し、フィーチャーフラグでリリースとデプロイを分離。6ヶ月でデプロイ頻度が 週1回 → 1日2〜3回 に改善。リードタイムも連動して 4日 → 3時間 に短縮された。
1年半後にはすべての指標でEliteレベルに。変更失敗率は 12% → 3% に低下し、「速くリリースするほど品質も上がる」というDORAの知見を実証した。
従業員50名のFintech企業。金融サービスのため規制が厳しく、デプロイは月1回の「ビッグバンリリース」方式だった。
DORA指標の初期計測結果:
| 指標 | 値 | レベル |
|---|---|---|
| デプロイ頻度 | 月1回 | Low |
| リードタイム | 3週間 | Low |
| 変更失敗率 | 22% | Low |
| 復旧時間 | 18時間 | Medium |
変更失敗率 22% が最大の課題。月1回のビッグバンリリースに大量の変更が含まれるため、どの変更が障害を起こしたか特定に時間がかかっていた。
改善のアプローチ:
- テスト自動化率を 35% → 80% に引き上げ
- カナリアリリースの導入（本番の5%のトラフィックで先行検証）
- PRサイズの上限を300行に設定
9ヶ月後:
| 指標 | Before | After |
|---|---|---|
| デプロイ頻度 | 月1回 | 週2回 |
| リードタイム | 3週間 | 2日 |
| 変更失敗率 | 22% | 6% |
| 復旧時間 | 18時間 | 2時間 |
規制業界でも小さく頻繁にリリースする方がむしろ安全だということを数字で証明できた。
従業員300名の受託開発会社。20以上のプロジェクトが並行稼働しており、チームごとの開発力にバラつきがある。経営層は「どのチームに投資すべきか」の判断材料を求めていた。
全20チームのDORA指標を3ヶ月間計測した結果:
| レベル | チーム数 | 割合 |
|---|---|---|
| Elite | 1 | 5% |
| High | 4 | 20% |
| Medium | 9 | 45% |
| Low | 6 | 30% |
Lowチームに共通する特徴は「テスト自動化率が20%以下」「CI/CDパイプラインが未整備」。一方Eliteの1チームは、テスト自動化率 92%、トランクベース開発を採用していた。
Eliteチームのプラクティスを社内ドキュメントとしてまとめ、Low/Mediumチームに段階的に導入。1年後にはLowチームが 6 → 1 に減少し、受注案件の品質クレームも 年38件 → 年12件 に改善された。
やりがちな失敗パターン#
- 個人の評価指標にしてしまう ── DORA指標はシステムとチームのケイパビリティを測るもの。個人のパフォーマンス評価に使うと、数字を操作するインセンティブが生まれる
- 4指標を同時に改善しようとする ── 最もレバレッジの大きい1指標に集中するほうが、連鎖的に他の指標も改善されやすい
- 速度と品質のトレードオフだと思い込む ── DORAの調査結果は「速いチームほど品質も高い」。デプロイ頻度を上げると変更失敗率は下がる傾向にある
- 計測自体が目的になる ── ダッシュボードを作って満足し、計測結果に基づく改善アクションを打たないケースが多い
よくある質問#
Q: DORA指標の4つはどうやって計測しますか？ A: デプロイ頻度はCI/CDパイプラインのログから、リードタイムはコミットからデプロイ完了のタイムスタンプ差で計測します。変更失敗率はインシデント/ロールバック件数÷デプロイ件数、サービス復元時間はインシデント検知〜解決のタイムスタンプから算出します。DatadogやLinearなどのツールが自動集計機能を提供しています。
Q: Eliteレベルの基準値はどのくらいですか？ A: GoogleのState of DevOps調査によると、Eliteチームの目安は「デプロイ頻度：1日複数回」「リードタイム：1時間以内」「変更失敗率：5%未満」「サービス復元時間：1時間以内」です。ただし自チームの前期比での改善に集中することが、他社比較より重要です。
Q: DORA指標を個人の評価に使ってもよいですか？ A: 避けるべきです。DORA指標はチームとシステム全体のケイパビリティを測るもので、個人に紐付けると数字を操作するインセンティブが生まれます。例えばデプロイ頻度を個人評価に使うと、不必要な細分化デプロイが増えます。チームの集合的な改善指標として使ってください。
Q: デプロイ頻度を上げるには何から始めればよいですか？ A: 最初の一歩はCI/CDパイプラインの整備（自動テスト→自動デプロイ）です。週次リリースのチームは、まず「機能フラグ（Feature Flag）」を導入して本番への影響なしにコードをマージする環境を整えると、デプロイ頻度と品質を両立しながら頻度を上げられます。
まとめ#
DORA指標は、ソフトウェアデリバリーの能力を4つの数値で客観的に測れる稀有なフレームワーク。Googleが支援する大規模調査に裏打ちされており、「速さと安定性は両立する」 という反直感的な事実を示した。まずは現状の4指標を計測し、最もインパクトの大きい1つから改善を始めよう。