変革を測る指標が見落とすもの

DORA の4指標は、2018年の『Accelerate』出版以降、デジタル変革の測定基準としてほぼ標準になった。標準化が議論を前進させたのは確かだが、同時に誤用のパターンも定着している。指標が組織能力を反映しなくなる典型を三つ取り上げ、補完のアプローチと突き合わせる。

頻度が目標になるとき

1日に複数回デプロイする組織はエリートパフォーマー、という DORA の分類は、頻度そのものを目標にする組織を生んだ。頻度を目標にすると達成は簡単で、コミットを細分化してデプロイ数を数えればいい。分割は多くの場合、機能デリバリの単位ではなくコミットの技術的な単位で行われる。

結果として「1日20回デプロイしているが機能リリースは月1回」という組織ができる。DORA の元の設計意図は変更単位を小さくして失敗リスクを分散させることだったが、指標だけが独り歩きすると目的から離れていく。指標が目標になるとそれは良い指標ではなくなる、という Goodhart の法則の典型例になっている。

どこから測り始めているのか

DORA が定義する変更のリードタイムは、コードコミットから本番稼働までの時間である。定義は明確だが、実務では「コミット」の解釈が割れる。個別開発者のローカルコミット、プルリクエスト作成、レビュー承認、マージ、CI 通過。どれを開始点にするかで、数値は数時間から数日の単位で変わる。

組織間比較で「エリートパフォーマーは1時間以内」といった数字を見るとき、その組織がどの時点を開始点にしているかは公表情報から判定できない。クラウド撤退の経費比較と同じく、測定境界の透明性が数値そのものより支配的になる。この認識を欠いたまま DORA 数値を比較すると、比較不能な数字を並べて意思決定することになる。

何を失敗と数えるか

変更失敗率は「本番反映後に修正が必要になった変更の割合」と定義される。どの規模の問題を失敗として計上するかについて、明示的な基準はない。1分間の性能低下を数えるか。5xx エラーが1件出たら数えるか。顧客通報があったときだけか。組織文化によって判定が変わる。

曖昧さは復旧時間にも波及する。復旧の定義は症状の消滅か根本原因の解消か。開始時刻は検知時点か影響発生時点か。終了時刻はサービス回復か事後レポート完了か。これらを明示している組織は多くない。SRE 文化が定着していない環境では定義が事後的に決まりがちで、報告バイアスが数値に混入する。

補完するか、置き換えるか

Microsoft Research の Forsgren らが2021年に発表した SPACE フレームワークは、DORA の限界を補う試みだった。Satisfaction、Performance、Activity、Communication、Efficiency の5次元で測ることで、単一指標への依存を避ける。測定コストは高く、DORA ほどには普及していない。

実務的には全次元を測るより、DORA 指標に開発者満足度と顧客影響の2次元を足す妥協案のほうが現実的だろう。この追加によって、デプロイ頻度は高いが開発者は疲弊している、変更失敗率は低いが顧客影響は大きい、といった DORA 単独では見えないパターンを拾える。

欠陥があっても測定しないよりましだ、という反論には一理ある。何も測っていない組織が DORA を導入すれば、少なくともデリバリ性能への注目は生まれる。ただし誤った測定が生む負のループも実在する。デプロイ頻度を最適化した結果コミットが細切れになり、レビュー品質が落ち、変更失敗率が上がるが、1コミットあたりで計測されるため見かけの数値は改善する。このループに入ると、指標を修正すること自体が組織的に難しくなる。副作用を理解して導入するのと、しないで導入するのとでは、5年後の状態が違ってくる。意思決定遅延の議論と同じく、測定対象の選択がそのまま組織行動を規定する。