2.10 DORA指標フレームワーク

概要と動機

DORA指標は、DevOps Research and Assessmentプログラムから来ています。これは数万人のエンジニアリング専門家を調査し、どの提供の慣行が組織の業績と相関するかを見つけ出した、後にニコール・フォーグレン、ジェズ・ハンブル、ジーン・キムによって『Accelerate』として出版された、数年にわたる研究の取り組みです。その結果は、二つずつ対になった四つの指標でした。デプロイ頻度と変更のリードタイムは速度を測定し、変更失敗率と失敗したデプロイの復旧時間(しばしば平均復旧時間(MTTR)と略されます)は安定性を測定します。このフレームワークを重要なものにした研究の発見は、エリートパフォーマーが同時に速く安定していたということであり、速度と安全性が互いにトレードオフの関係にあるという想定を覆しました。そして、その発見は今も、本書におけるトピック1.2のガードレール対化の原則の最も明確な実例です。インセンティブ化された速度指標と、安定性のガードレールを対にすることこそ、最高の業績を上げる組織が実際に行っていることなのです。

本書はこのパートでDORAを意図的に最後に扱い、このパートを組織化するフレームワークとしてではありません。この配置は、今も本物に厳密で使う価値のあるこの研究を拒絶するものではありません。それは特定の本物の限界を反映しています。DORAはパイプラインがどれだけ速く、どれだけ安全に動くかを測定しますが、そのパイプラインを通じて何が動いているのかについては沈黙しています。あるチームは、その実際のアウトプットが欠陥の手戻りへと静かにずれていくか、技術的負債やセキュリティの仕事から容量を奪っている間に、優れたDORAの数字を発表することができます。これは、トピック2.1からトピック2.4のFlow Frameworkが特にこれを表面化させるために作られたパターンであり、DORAには見えないものです。本トピックが提示するとおりにDORAを使ってください。パイプラインの仕組みのよく検証された、しかしより狭い参考測定であり、提供の健全性の全体像ではないものとしてです。

大規模なチームにとって、DORAの残る本物の価値は比較可能性です。パイプラインとインシデントのデータから一貫して計算された指標は、組織が、ほとんどのチーム間比較を悩ませるリンゴとオレンジの問題なしに、異なる領域で働く多くのチームにわたって提供能力を比較することを可能にします。企業組織は今もそれをプラットフォーム投資の優先順位づけに使っています。政府組織は今もそれを使って、近代化プログラムが提供の仕組みを測定可能に改善したことを証拠とともに示しています。それをDORAの適切で境界づけられた仕事として扱い、そもそも正しいものが届けられているかどうかというより広い問いには、このパートの前の方にあるFlow Frameworkのトピックを使ってください。

重要な原則

DORAはパイプラインを測定するのであり、その中を流れる価値を測定するのではない。 トピック2.1はこの隙間を直接名指ししています。DORAには見えないものを見るために、フロー分布(トピック2.3)を使ってください。
速度と安定性は一緒に測定されるのであり、別々にではない。 両方の半分を伴わないDORAに情報を与えられたダッシュボードは、実際にはこのフレームワークを使っていません。
定義の一貫性は、素の数字よりも重要である。 一貫して定義された指標について「中」から「高」の業績に移るチームは本物の信号です。異なる方法で計算された二つのチームを比較することはそうではありません。
DORAはシステムを測定するのであり、個人を測定するのではない。 これらの指標を個々のエンジニアに適用することは、このフレームワークの統計的基盤を壊し、まさにトピック1.2が警告する操作を招きます。
4つの指標すべては目標ではなく代理である。 それらは組織の業績と相関します。本物の提供改善から切り離されたその数字自体を追いかけることは、このフレームワークの目的を打ち負かします。

推奨事項

パイプラインからデプロイ頻度を計装し、本番リリースだけを数える

デプロイ頻度は、あるチームがどれだけの頻度で本番へ成功裏にリリースするかを測定します。成功した本番デプロイだけを、CI/CDパイプラインのデータから自動的に計装して数え、決して自己申告にしないでください。特に代替操作、つまり件数を水増しするためだけに一つの意味のある変更をいくつかの些細なデプロイに分割することに注意し、頻度と並んでデプロイのサイズを追跡してください。上昇する件数の隣で縮小する平均サイズは、これが起きている最も明確な兆候です。

最初のコミットから本番までの変更のリードタイムを計装する

変更のリードタイムは、あるコード変更の最初のコミットから、本番での成功裏のデプロイまでの時間を測定します。歪んだ時間ベースのデータについてのトピック1.6の指針に従って、平均だけでなく中央値と高いパーセンタイルの両方を報告し、どちらかの端点での定義のずれに注意してください。これは本物の改善なしに数字をより良く見せます。

チーム間で比較する前に変更失敗率を書面で定義する

変更失敗率は、修復(ロールバック、ホットフィックス、あるいはインシデント)を必要とする失敗を引き起こすデプロイの割合を測定します。これは四つの中で一貫して定義するのが最も難しいものです。なぜなら、「失敗」は自明に客観的ではないからです。チームを比較する前に書面での定義に合意してください。それなしでは、一見公平に見える比較がひどい誤解を招くことがあります。その背後に根底にあるプロセスの変更なしの疑わしく速い改善に注意してください。これは、本物の進歩ではなく定義の操作の最も明確な兆候です。

デプロイイベントからではなく検知から復旧時間を測定する

失敗したデプロイの復旧時間は、あるデプロイが失敗を引き起こしたときにサービスを復旧するのにどれだけかかるかを測定します。デプロイイベント自体ではなく検知の時点で時計を開始し、その数字が監視の隙間ではなく本物の復旧の遅延を反映するようにしてください。特に自動化されたロールバック能力に投資してください。これは、インシデントを早まって解決済みと宣言することによってではなく、本物にこの指標を改善するための唯一最も一般的なレバーです。

数字が動いた理由を診断するためにDORAではなくフロー指標を使う

あるDORAの指標が変化したとき、四つの数字だけではその理由をめったに説明できません。サイクルタイムの分解(トピック2.6)、フロー負荷(トピック2.4)、フロー分布(トピック2.3)を、DORAの要約の数字の下にある診断の層として使い、個人の業績評価にDORAの指標を決して使わないでください。これは、このフレームワークがさらされている唯一最も有害な誤用です。

トレードオフ:長所と短所

アプローチ	長所	短所
完全なDORAフレームワーク、四つの指標すべてが対になっている	研究によって検証され、対化を通じて操作に強く、公平なチーム間比較を可能にする	どんな種類の価値が届けられているかについて沈黙している。その全体像のためにはFlow Frameworkがそれと並んで必要
このパートの唯一の組織化指標群としてのDORA	単純で、ほとんどのエンジニアリングリーダーになじみがある	価値の組み合わせの問いを完全に見逃す。これが本書がここでそれを優先度下げる理由
DORAとFlow Frameworkを一緒に	パイプラインの仕組みと価値の組み合わせの両方が見える	一つではなく二つの指標語彙を維持する必要がある
個人レベルで適用されたDORA	一部のマネージャーにとって直接行動可能に感じられる	このフレームワークの統計的妥当性を壊す。強いグッドハートの法則への露出

中心にある緊張関係は機械的な厳密さとビジネスの可読性です。DORAの四つの指標は正確に定義され研究によって検証されており、これはチーム間でパイプラインの業績を比較するのに優れたものにしますが、その同じ精密さはパイプラインそのものに狭く限定されており、正しい仕事がそれを通じて流れているかについては何も語りません。この緊張を解消するには、DORAをパイプラインの健全性のための参考の層として保ち(これが本書の構造におけるトピック2.10の適切な位置です)、DORAに設計されたことのない問いに答えさせようとするのではなく、価値の組み合わせについてのビジネス向けの問いには、このパートの前の方にあるFlow Frameworkのトピックを使ってください。

チームで話し合うべき問い

私たちは四つのDORA指標すべてをパイプラインから計装しているでしょうか。それとも一部は自己申告の見積もりでしょうか。 客観的で研究によって検証された測定の上に構築されたフレームワークは、ある数字が最良の推測になった瞬間、その価値の多くを失います。各指標の実際のデータソース(トピック1.5)を監査してください。
私たちがDORA指標を使って比較するすべてのチームは、デプロイ、変更、失敗の同じ定義を共有しているでしょうか。 異なる定義を使うチーム間の比較は本当の比較ではなく、相対的な業績についての不公平な判断を生み出すことがあります。
私たちの組織の誰かが、正式あるいは非公式に、個人の業績評価でDORA指標を使ったことがあるでしょうか。 これはこのフレームワークの唯一最も有害な誤用であり、しばしば静かに起こります。直接尋ね、不快だが必要な答えに備えてください。
私たちのフロー分布(トピック2.3)が手戻りへと静かにずれていく、あるいは機能から離れていく間に、私たちのDORAの数字は優れて見えることがあるでしょうか。これはまさにDORAだけでは見えない隙間です。両方の数字の集合を一緒に持ち出し、それらが一貫した物語を語っているかを確認してください。
私たちのDORA指標の一つが動いたとき、私たちはその理由を説明するフロー指標の診断を持っているでしょうか。 DORAの数字だけでは何かが変わったことがわかるだけで、何が変わったかはわかりません。あなたのチームが「なぜ今月リードタイムが増えたのか」にデータで答えられるか、それとも推測でしか答えられないかを確認してください。
もし私たちが意図的にそれぞれを操作しようとしたら、私たちの四つのDORAの数字はどう変わるでしょうか。そして私たちはそれに気づくでしょうか。デプロイ頻度、リードタイム、変更失敗率、復旧時間を一つずつたどってみてください。これは、この特定のフレームワークへのトピック1.2の核心的な規律の実践的な適用です。

業種別の視点

スタートアップ。 DORAの速度指標は、すでに頻繁にデプロイしている小さなチームには通常自然に備わっています。より難しい規律は、まだ大きく壊れていないという理由で安定性を想定するのではなく、変更失敗率と復旧時間を正直に計装することです。早期に非公式なフローアイテムの分割(トピック2.2)とDORAを対にすることは、パイプラインの速度だけを中心とした提供の健全性についての誤った感覚を構築することを避けます。

中小企業。 ほとんどの現代的なCI/CDとバージョン管理のプラットフォームは、最小限の設定でデプロイ頻度とリードタイムのデータをエクスポートします。変更失敗率のためにデプロイをインシデントに結びつけることは、典型的にはより多くの手動の労力を必要とします。二つの速度指標から始め、照らし合わせる非公式なインシデントログが存在するようになったらすぐに安定性の追跡を追加してください。

企業。 この規模でのDORAの最大の残る価値は、プラットフォーム投資の決定のための公平で一貫したチーム間比較です。組織全体で定義を標準化し(トピック1.4)、計測基盤を中央で自動化し、指導層がパイプラインの速度と価値の組み合わせの両方を一緒に見られるように、あらゆるDORAの報告をフロー分布のビューと対にしてください。

政府。 DORA指標は、近代化プログラムに、監督機関に提供の仕組みの改善を示すための擁護可能で研究に裏づけられた方法を今も与えてくれます。四つの指標すべてを一緒に報告し、好都合な半分だけを選び取ることは決してせず、報告が、より速くなったパイプラインが実際に何を届けているかというより難しく重要な問いにも答えるように、それらをフロー分布と対にしてください。

事例

企業。 ある大手電気通信企業のプラットフォーム近代化プログラムは、40の製品チームにわたって四つのDORA指標すべてを一貫して計装し、18か月にわたって低業績から高業績の階層への本物の移行を示しました。デプロイ頻度は約10倍に上昇し、リードタイムは数週間から数日に減少し、変更失敗率は横ばいを保ちました。この発表をレビューしたある取締役会のメンバーは、DORAの数字だけでは答えられない問いをしました。その速くなった提供のうち、どれだけが新しい顧客価値で、どれだけが手戻りだったのか。このエンジニアリング組織は、翌四半期にフローアイテムの分類を採用するまで答えを持っていませんでした。それは、DORAの速度の数字が改善する中でさえ、機能の仕事が総アウトプットの割合として実際には低下していたことを示し、この発見がプログラムの翌年の優先事項を作り変えました。

政府。 ある州政府のIT近代化事務局は、複数の競合するベンダーチームの提供能力を比較するための契約条件としてDORA指標を採用しました。これはこのフレームワークの比較可能性の効果的な使い方です。あるベンダーの高いデプロイ頻度は、変更失敗率がそれと一緒に要求されると、同業他社の約3倍高い失敗率と相関していることが明らかになりました。この情報は、事務局の契約更新の決定に直接情報を与えました。この事務局は後に、最良のDORAの数字を持つベンダーが、契約が特に要求したセキュリティ対応の仕事に容量の最も少ない割合しか費やしていなかったベンダーでもあったことを発見した後、同じ契約にフロー分布の要件を追加しました。

ビジネスケース:動機、ROI、総所有コスト

DORAをその適切な範囲の中でうまく採用することからの見返りは、「私たちの提供パイプラインはより速く、より安全になっているか」という、今もエンジニアリングにおいて自信を持って答えるのが比較的扱いやすい問いの一つへの、擁護可能で証拠に基づく答えです。その答えは、本物の数字でプラットフォームとツールへの投資を正当化し、指導層が、常にそうであったように、競合する投資を公平で一貫した基盤で比較することを可能にします。

総所有コストは、変更失敗率と復旧時間のためにデプロイイベントをインシデントの記録に結びつける統合作業であり、大規模で異種混交のツールの風景にわたってはささいなことではありません。このパートの前の方にあるFlow FrameworkのトピックとDORAを対にすることの追加コストは比較的小さなものです。なぜなら、フローアイテムの分類は並行した測定システムではなく既存の仕事に重ねられた報告の慣習であり、その見返り、つまり上記の電気通信の例が示す、まさに価値組み合わせの死角を捉えることは、その控えめな追加投資に十分見合うものだからです。

アンチパターンと落とし穴

DORAを提供の健全性の全体像として扱う。 本トピックの配置が対抗するように設計されている操作のベクトルです。ある組織は、その実際に届けられた価値が手戻りへと静かにずれていくか、機能から離れていく間に、本物に優れたDORAの数字(速く、頻繁で、安定したデプロイ)を提示することができ、DORAの四つの指標だけでは、それを測定するように設計されたことがないため、その変化を決して明らかにしません。ガードレールは、あらゆるDORAの報告をフロー分布(トピック2.3)と対にすることです。そうすれば、間違った仕事の組み合わせを届けている速く安定したパイプラインが、本物の提供の健全性と取り違えられるのではなく、見えるようになります。
DORAの速度の半分だけを報告する。 高業績者において速度と安定性が一緒に動くという、このフレームワークの中心的な発見を打ち負かします。
個人の業績評価でDORA指標を使う。 このフレームワークの統計的妥当性を壊し、強い操作を招きます。
一貫性のない定義を持つチームを比較する。 公平に見えるが実際にはそうではない比較を生み出します。
パイプラインに計装された数字ではなく自己申告のDORA数字。 まさにこのフレームワークが排除するために設計された偏りを持ち込みます。
DORAを要約としてではなく診断として扱う。 下にあるフロー指標の層なしに、チームが数字が動いた理由を説明できないままにします。

成熟度モデル

レベル1、開始: DORA指標は、そもそも追跡されているとしても、自己申告で、一貫性なく定義されており、フローデータと一度も対になっていません。
レベル2、発展: 一部のチームはパイプラインからDORAを計装していますが、定義はさまざまで、照らし合わせるフロー分布の対応物がありません。
レベル3、標準化: 四つのDORA指標すべてが、共有された定義で、パイプラインとインシデントのデータから一貫して計装され、日常的にフロー分布と並んで示されています。
レベル4、管理: DORAとフロー指標は、組織のあらゆるレベルで標準的な対として一緒にレビューされ、DORAは個人評価に決して使われません。
レベル5、最適化: 組織は、優れたDORAの数字だけでは隠されていた価値組み合わせの問題をフロー分布が捉えた具体的な事例を指し示すことができ、両方のフレームワークを、それぞれが答える異なる問いのために意図的に使っています。

議論のためのアイデア

私たちの四つのDORA指標は現在、業績階層のスペクトラム上で正直に私たちをどこに位置づけているでしょうか。
私たちのフロー分布が静かにずれている間でも、私たちのDORAの数字は優れて見えることがあるでしょうか。私たちはこれまでに確認したことがあるでしょうか。
誰かがDORAの数字を使って、非公式にであっても個人を判断したことがあるでしょうか。
もし競合他社がDORAの数字を公開したら、私たちの数字は有利に比較されるでしょうか。そして、その比較は実際にどちらがより多くの本物の価値を届けているかを教えてくれるでしょうか。

主な要点

DORAの四つの指標、デプロイ頻度、リードタイム、変更失敗率、復旧時間は、設計上速度と安定性を対にしており、今も本物に研究によって検証されています。
本書がDORAをこのパートで最後に配置するのは、それがパイプラインを測定し、その中を流れる価値を測定しないからです。より完全な全体像のために、フロー分布(トピック2.3)と対にしてください。
本トピックの中心的な操作のベクトルは優れたDORAの数字を完全な提供の健全性と取り違えることです。ガードレールは、常にDORAをフロー分布と並んで報告することです。
個人の業績評価でDORA指標を決して使わないでください。 このフレームワークの妥当性は、個人ではなくシステムレベルの測定に依存しています。
DORAの要約の数字のどれかが動いたとき、フロー指標を下にある診断の層として使ってください。

参考文献とさらなる読書

Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018。
Google Cloud. DevOps Research and Assessment プログラム。dora.dev。
Kim, Gene, Kevin Behr, and George Spafford. The Phoenix Project. IT Revolution Press, 2013。
Kim, Gene, Jez Humble, Patrick Debois, and John Willis. The DevOps Handbook. IT Revolution Press, 2016。
Kersten, Mik. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. IT Revolution Press, 2018。