はじめに
「うちのチーム、開発が遅いんだよね」
「品質を上げたいけど、リリース頻度は落としたくない」
こういった会話、エンジニアリングの現場ではよく聞きます。
でも、「遅い」「品質が低い」をどう数字で表すかは、意外と議論されていないことが多いです。
そこで登場するのが DORA の4指標 です。
DORAとは
DORA（DevOps Research and Assessment） は、Googleが支援する研究チームが行っている、ソフトウェアデリバリーのパフォーマンスに関する大規模調査です。
2014年から毎年「State of DevOps Report」を発表しており、数万チームのデータをもとに「高パフォーマンスなチームが共通して持つ特性」を明らかにしています。
その中で特定されたのが、以下の4つの指標です。
4つの指標
1. デプロイ頻度（Deployment Frequency）
本番環境へのデプロイを、どのくらいの頻度で行っているか
| レベル | 頻度 |
|---|---|
| Elite | 1日に複数回 |
| High | 1日〜週1回 |
| Medium | 週1〜月1回 |
| Low | 月1回以下 |
何を測っているか： チームがどれだけ「小さく・安全に・速く」リリースできているか。
デプロイ頻度が高いチームは、1回あたりの変更量が小さいため、問題が起きても影響範囲が限定的です。
2. 変更リードタイム（Lead Time for Changes）
コードのコミットから本番環境への反映まで、どのくらいの時間がかかるか
| レベル | リードタイム |
|---|---|
| Elite | 1時間未満 |
| High | 1日〜1週間 |
| Medium | 1週間〜1ヶ月 |
| Low | 1ヶ月以上 |
何を測っているか： アイデアや修正が「価値」として届くまでの速さ。
リードタイムが短いチームは、レビュー・テスト・デプロイの自動化・標準化が進んでいます。
3. 変更失敗率（Change Failure Rate）
デプロイした変更のうち、本番障害・ロールバックが必要になった割合
| レベル | 失敗率 |
|---|---|
| Elite | 0〜5% |
| High | 5〜10% |
| Medium | 10〜15% |
| Low | 15〜30%以上 |
何を測っているか： リリースの「品質」と「安全性」。
失敗率が低いチームは、自動テスト・コードレビュー・機能フラグなどの仕組みが整っています。
4. サービス復旧時間（Time to Restore Service / MTTR）
本番障害が発生してから、サービスが復旧するまでの時間
| レベル | 復旧時間 |
|---|---|
| Elite | 1時間未満 |
| High | 1日未満 |
| Medium | 1日〜1週間 |
| Low | 1週間以上 |
何を測っているか： 障害への対応力と、組織の「回復力（Resilience）」。
復旧が速いチームは、可観測性（ログ・監視）とインシデント対応フローが整備されています。
2軸で整理する
4指標は「スピード」と「安定性」の2軸に分けられます。
スピード系
├─ デプロイ頻度（どれだけ頻繁に出せるか）
└─ 変更リードタイム（どれだけ速く届けられるか）
安定性系
├─ 変更失敗率（どれだけ安全に出せるか）
└─ サービス復旧時間（壊れたときどれだけ速く直せるか）
よくある誤解：「速さ」と「安定性」はトレードオフではない
「速くリリースすると品質が下がる」という直感がありますが、DORAの研究は逆のことを示しています。
Elite チームはスピードも安定性も両方高い
小さく・頻繁にリリースするチームは、1回あたりのリスクが小さく、問題があってもすぐに検出・修正できます。大きな変更を数ヶ月に1回リリースするチームの方が、リスクが高いのです。
エンジニアリングマネージャー視点での活用
チームの現状把握に使う
4指標を計測するだけで、チームのどこに課題があるかが見えてきます。
- デプロイ頻度が低い → リリースプロセスに手作業・承認フローが多すぎる
- リードタイムが長い → レビュー待ち時間・テスト自動化の不足
- 変更失敗率が高い → テストカバレッジ不足・コードレビューの質の問題
- 復旧時間が長い → 可観測性の不足・インシデント対応フローの未整備
経営層との対話に使う
「品質を上げたい」「速くしたい」という抽象的な議論を、数字ベースの会話に変えられます。
「現在のデプロイ頻度は週1回（Highレベル）です。
変更失敗率を下げるために自動テストを整備し、
来期中にEliteレベルを目指します。」
計測の始め方
完璧なツールがなくても、スプレッドシートから始められます。
| 指標 | 最初の計測方法 |
|---|---|
| デプロイ頻度 | GitHubのデプロイ履歴を週次で数える |
| 変更リードタイム | PRの作成日時〜マージ日時をログで確認 |
| 変更失敗率 | リリース後の緊急修正・ロールバック件数を記録 |
| 復旧時間 | インシデント報告書から発生〜復旧の時刻を集計 |
ツールとしては Four Keys（Google製OSS） や LinearB などもありますが、まずは手計測でもOKです。
まとめ
| 指標 | 何を測るか |
|---|---|
| デプロイ頻度 | どれだけ頻繁にリリースできるか |
| 変更リードタイム | コードが本番に届くまでの速さ |
| 変更失敗率 | リリースの安全性 |
| サービス復旧時間 | 障害からの回復力 |
DORA の4指標は、エンジニアチームの「健康状態」を測るための共通言語です。
数字で現状を把握し、改善施策の効果を測定する ── それがチームを継続的に強くする第一歩です。