はじめに
DORAは、開発組織の改善を考えるうえでよく参照される指標群ですが、現場で使うときには期待と限界の両方を理解しておく必要があります。この記事では、DORAの基本的な位置づけを整理したうえで、メリットとデメリット、そして誤用を避けるための実務的な見方をまとめます。
DORA（DevOps Research and Assessment）は、ソフトウェアデリバリの成果を測るための指標群を提案してきた研究・実務コミュニティです。DORAの指標は、速度と安定性の両面を同時に見て改善につなげる枠組みとして整理されています。
DORA指標の現在地
DORAは長らく「Four Keys（4つの指標）」として知られてきました。Google Cloudの解説では、四つの指標を次のように定義しています。
- デプロイ頻度: 本番へのリリース頻度
- 変更のリードタイム: コミットから本番反映までの時間
- 変更失敗率: 変更が本番障害を引き起こす割合
- 復旧時間: 障害からの回復に要する時間
一方で、DORAの最新ガイドでは指標が5つに拡張され、スループット（Throughput）と不安定性（Instability）の2軸で捉える構成になっています。具体的には、スループットは「変更リードタイム」「デプロイ頻度」「失敗デプロイからの回復時間」、不安定性は「変更失敗率」「デプロイの手戻り率」で構成されます。
DORAが想定するチームの前提
DORAは個人評価のための指標ではなく、チームのデリバリープロセスを改善するための指標として設計されています。複数人で開発し、継続的にリリースするチームを想定しているため、デプロイ頻度やリードタイム、復旧時間といったチームの流れを見て、改善の対話につなげる用途が中心です。
小規模チームや開発スタイルが特殊な場合でも使えますが、そのときは比較ではなく、自分たちの改善の鏡として使うのが安全です。DORAはチーム内のフィードバックループを回すための指標であって、外部評価のための指標ではないという位置づけです。
リリースが単発寄りの組織での捉え方
継続的改善や頻繁なリリースを前提とするDORAは、機能単位の大きなリリースが中心の組織では、指標の見え方が変わります。リリース頻度が低いと、デプロイ頻度やリードタイムの数値はどうしても鈍く見え、改善のサイクルも短く回しづらくなります。
この場合、DORAは無理に全指標を追うよりも、活動の実態に合わせて使いどころを絞るほうが現実的です。たとえば、リリースが少ないなら復旧時間や変更失敗率の学びを重視し、少数のリリースからの学びを丁寧に回す。あるいは、リードタイムを「調査やリファクタリングを含めた前提の時間」として捉え、改善の焦点を計測そのものではなくボトルネックの解消に置くと納得感が出ます。
要するに、DORAは頻繁なリリースを前提にした万能指標ではなく、現実の開発リズムに合わせて意味のある指標だけを選び、改善の対話に使う道具として扱うのがよいです。
DORAのメリット
-
速度と安定性を同時に見る枠組みがある
DORAは「速さか安定か」という二項対立ではなく、両方が両立し得るという研究結果を示しています。実務では、速度向上が障害増につながるという直感が根強いですが、DORAはそれが必ずしもトレードオフではないことを示唆しています。 -
指標が工程に対応しており、改善の起点を作りやすい
デプロイ頻度や変更リードタイムはパイプラインの詰まりを可視化し、変更失敗率や復旧時間は運用・品質プロセスの弱点を示します。指標が工程に対応しているため、改善策の議論を始めやすいのが利点です。 -
アプリやサービスの文脈を前提とした議論ができる
DORAのガイドは、指標はアプリケーションやサービス単位で測ることが適しており、文脈の違う対象を単純比較すると誤解を招くと述べています。コンテキストを前提にした議論を促す枠組みになります。 -
指標は改善のための入口として機能する
DORAは、指標を目標にするのではなく、強みや弱みを理解して学習と改善を回すことを重視しています。指標は改善を始めるための入口だと位置づけられています。
DORAのデメリットと注意点
-
指標が目的化しやすい
DORAは、指標が目的になってしまうと本来の改善が歪むリスクがあることを示しています。数字の達成が先行すると、実態を伴わない改善や局所最適が起きる可能性があります。 -
文脈の違いを無視した比較が起きやすい
指標はアプリやサービス単位で適用すべきで、異なる性質のシステムを比較すると誤解を招くとされています。組織横断のランキング目的で使うと副作用が出やすい点に注意が必要です。 -
データ収集コストが発生する
DORA指標の算出には、デプロイ、変更、インシデントなどのデータを複数システムから集める必要があります。Four Keysの解説でも、データが分散していることが課題として挙げられています。 -
計測の精度を追い過ぎると改善が遅れる
DORAは、測定のための測定にならないよう注意を促しています。精密化に投資し過ぎると、改善そのものが遅れる可能性があります。
異なるチームで使う場合の考え方
同じ会社でも、チームごとに扱うサービスの性質、リスク、リリース手段、依存関係が異なるため、指標の見え方が大きく変わります。たとえば、基盤系チームは変更頻度が低くても安定性の重みが高いし、顧客機能チームは小さな変更を頻繁に出せる仕組みが重要になります。
そのため、DORAは「全社共通の評価指標」というより「各チームの改善の鏡」として運用するのが現実的です。
異なるチームの比較についての見解
結論として、異なる文脈のチームをランキングする用途には向きません。比較するなら「似た前提を持つチームの間で、改善の傾向を見る」くらいに留めるのが安全です。
- 対象は同種サービス、同じリスク特性のチームに限定する
- 絶対値ではなく、期間内の改善幅やトレンドを重視する
- 指標の背景を質的情報とセットで共有する
- 数字が低い場合でも、制約や事情を言語化して議論する
DORAは比較の道具というより、改善の対話を始めるための共通言語として使うと効果が高いです。社内向けの注意書きや運用ルール（例: ランキング禁止、比較は同カテゴリ内のみ）も書いておくと、誤用を抑えられます。
同じチーム内で業務内容が大きく違う場合
同じチーム内でも、扱っている仕事の性質が違うとDORAの数値の見え方は大きく変わります。新機能の開発は設計から実装までを一気通貫で進めやすく、変更リードタイムも短く見えがちです。一方で、既存コードの理解やリファクタリングを前提にした作業は、最初のコミットからリリースまでが長くなりやすいという構造的な理由があります。
たとえば、既存の品質が十分でない領域では、まずロジックの読み解きや品質の是正が必要になります。設計段階や調査段階での見えにくい作業が多く、初期コミットが遅れたり、コミット後のリードタイムが長くなったりしやすいです。これはサボっているからではなく、対象領域のリスクや既存品質が原因で起こる自然な遅延です。
このような違いがある場合、DORAを個人や担当領域の比較に使うと誤解を招きやすくなります。実務上の対策としては、次のような運用が現実的です。
- 指標はチーム全体で見る。個人や担当領域の単純比較はしない
- 仕事の種類ごとに「基準の違い」をあらかじめ共有する
- 変更リードタイムの長さは、前提となる調査やリファクタリングの必要性を含めて解釈する
- 定量指標と並行して、リスク低減や品質改善などの質的成果を言語化する
同じチーム内でも業務の性質が違う以上、数値の差は自然に生じます。DORAはあくまで改善の対話の入口として使い、背景となる作業内容を一緒に説明することが大切です。
測りすぎが示す落とし穴
ジェリー・Z・ミュラーの『測りすぎ――なぜパフォーマンス評価は失敗するのか？』は、測定が目的化すると文脈や判断の微妙さが失われ、測定に適した行為が優先される問題を指摘しています。
この観点はDORAにも当てはまります。DORAは指標を改善の入口として使うことを推奨しますが、数値を目標化してしまうと、変更を小さく分割して見かけのリードタイムを短くする、検証不足のままデプロイ頻度を上げる、といった行動に誘導される可能性があります。指標を「判断材料」として扱い、現場の文脈や質的情報と併せて使う必要があります。
本書は、測定コストがメリットを上回る可能性にも触れています。DORAの計測基盤を作る際も、統合や運用のコストが過剰になっていないかを定期的に見直す視点が重要です。
なぜ数値的な評価をしたくなるのか
本書は、数値評価そのものを単純に悪として扱ってはいません。むしろ、なぜ人や組織が数値評価に惹かれるのかを丁寧に掘り下げています。ここを理解しておくと、DORAを含む指標の使い方も冷静に設計しやすくなります。
まず、数値はわかりやすいからです。複雑な現実を一つの数字に置き換えられれば、説明が容易になり、意思決定も速くなります。組織が大きくなるほど、この誘惑は強まります。
次に、説明責任への対応があります。上位層や外部ステークホルダーに対して、状況を短時間で説明する必要があるとき、数値は便利です。言葉の説明よりも、指標の推移を示すほうが説得力があるように見えます。
さらに、管理のコストを下げたいという動機もあります。数値があれば、現場に深く入り込まなくても状況を把握できると期待されます。これは忙しい管理者にとって魅力的です。
ただし本書は、こうした合理性がそのまま「正しさ」を意味しないと指摘します。数値は比較や説明に強い一方で、文脈の違いや目に見えない価値を切り捨てやすい。だからこそ、数値評価に惹かれる理由を理解したうえで、数値の限界と副作用を意識的に受け止める必要がある、というのが本書の立場です。
本書の立場とDORAの関係
本書は、数値でパフォーマンスを評価することを手放しで肯定する立場ではありません。むしろ、数値化した瞬間に行動が歪むことや、指標が目的化してしまう危険を繰り返し指摘しています。その一方で、数値化そのものを全面否定するわけでもなく、補助的に使い、質的な情報と組み合わせるべきだというスタンスです。数値は参考指標であり、評価そのものになってはいけないという考え方です。
この観点から見ると、DORAは「良い数値化の例」ではあるが、使い方次第で危険にもなる指標群だと言えます。チームのデリバリー能力を測るという点で本質に近い一方、個人評価に転用すると本書が批判する典型的な失敗パターンに入りやすいからです。
数値評価の是非とエンジニア評価の考え方
知識労働では、最も価値の大きい仕事ほど数値化が難しいという前提があります。設計の穴を塞ぐ、仕様の抜けを未然に見つける、レビューで品質を押し上げる、といった成果は数字になりづらいからです。数値評価を強く押し出すほど、見える成果だけに最適化され、見えない貢献が切り捨てられるリスクが高まります。
そのため、エンジニア評価は数値ではなく、行動と成果の質を軸に考えるほうが実務的です。実務で使える観点としては、次のような軸が現実的です。
- 技術的成果の質。読みやすさ、保守性、設計の一貫性、バグを生みにくい構造など
- 問題発見力。仕様の穴や将来の不具合を未然に見つける力
- チーム貢献と協働。レビュー、ドキュメント、共通化による全体最適
- 自律性と再現性。任せた領域を安定運用できるか、調査や原因特定の強さ
こうした評価は「行動基準」や「期待される振る舞い」を明文化して運用するのが効果的です。レベルごとに、どのような判断や貢献が求められるかを言語化することで、数字に頼らない評価の透明性を担保できます。
本書基準で見たDORAの評価
本書の観点から見たDORAの評価は、次のように整理できます。
- 良い点。見せかけの生産性ではなく、継続的に安全に届ける能力を測っている
- 良い点。チーム単位の指標であり、個人を直接叩く構造になりにくい
- 注意点。個人評価に使うと、指標の目的化や恐怖政治を生みやすい
- 注意点。過剰適応すると、計測のための開発になりやすい
- 注意点。チーム特性を無視した比較は誤解を生む
結論として、DORAはプロセス改善の対話を始めるためには有効だが、個人評価に使うと危険である、という位置づけになります。
まとめ
DORAの指標は、開発の速度と安定性を同時に捉え、改善の議論を始めやすくする強力な道具です。一方で、指標の目的化や文脈を無視した比較、計測コストの増大といった落とし穴もあります。『測りすぎ』が示す通り、測定は価値ある活動ですが万能ではありません。数値達成ではなく学習と改善を主目的に据え、チームやプロダクトの状況に合わせて使うことが重要です。
参考リンク
-
DORA Metrics Overview – 公式ガイド
DORAメトリクスの定義と5指標の最新構成についての公式解説
-
The Evolution of DORA Metrics
Four Keysから5指標への拡張を含む、DORA指標の歴史と背景
-
Using the Four Keys to Measure Your DevOps Performance (Google Cloud Blog)
Google CloudによるFour Keysの実装・計測方法の実践解説
-
New Relic: DORA Metrics Guide
実務でのDORA指標の活用法やツール連携についての解説
-
Accelerate – The Science of Lean Software and DevOps (書籍紹介ページ)
DORA研究の基盤となった書籍『LeanとDevOpsの科学［Accelerate］』の紹介ページ（日本語版）
-
『測りすぎ――なぜパフォーマンス評価は失敗するのか？』書籍情報（Amazon）
数値化評価の限界と副作用を扱った書籍