組織目標に合った測定フレームワークの選択

発表: 2025年8月 · 著者: Sarah D'Angelo, Ambar Murillo, Sarah Inman, Kevin M. Storer · 原文: https://dora.dev/insights/measurement-frameworks/

核心命題

測定の核心は測定を通じて組織に変化を起こすことです。フレームワークは広いテーマ（例: 開発者体験）を測定可能な概念（速度、満足度）に分解します。SPACE・DevEx・H.E.A.R.T・DORA指標のどれを選ぶかは目標が決めます。

主要フレームワークの比較

以下の表は、DORA原文が言及した4つのフレームワークを、それぞれの原出典の定義に沿って整理したものです。原文本文はH.E.A.R.Tをプロダクトの卓越性のフレームワークの例として明示しています。DORA指標・SPACE・DevExがどの目標タイプに属するかは原文の図にのみ示されており、この要約では本文で確認できていませんが、SPACEとDevExの原出典の論文は開発者の生産性・体験を測定対象としています。

フレームワーク	答えようとする問い	代表的な測定対象	活用例
SPACE (Forsgrenほか, 2021)	開発者の生産性を単一の指標ではなく複数の次元で見ると、どのような姿か？	満足度・ウェルビーイング(Satisfaction)、成果(Performance)、活動(Activity)、コミュニケーション・協働(Communication)、効率・フロー(Efficiency and flow)	AIツール導入後、活動量だけでなく満足度・協働・フローの変化もあわせて確認
DevEx (Nodaほか, 2023)	開発者が日々の業務で感じる摩擦はどこにあるか？	フィードバックループ(ビルド・レビュー待ちなど)、認知負荷、フロー状態 — 認識(サーベイ)とワークフロー(システムデータ)の両面で測定	社内プラットフォーム・ツール改善の優先順位を決めるための開発者サーベイ
H.E.A.R.T (Roddenほか, 2010)	プロダクト(ツール)のユーザー体験は目標を達成しているか？	幸福度(Happiness)、エンゲージメント(Engagement)、採用(Adoption)、継続(Retention)、タスク成功(Task success)	社内のAIコーディングツールを1つのプロダクトとみなし、採用率・継続利用・満足度を追跡
DORA指標	ソフトウェアデリバリーはどれだけ速く安定しているか？	処理量: 変更リードタイム(コミットから本番デプロイまで)、デプロイ頻度、失敗デプロイの復旧時間 / 不安定さ: 変更障害率(即時の介入が必要になったデプロイの割合)、デプロイ再作業率(本番インシデントによる計画外デプロイの割合)	AI導入の前後でデリバリーの速度と安定性がともに変化したかを比較

表の「活用例」は、各フレームワークの定義に照らしてこのサイトが加えた例であり、DORA原文が示した事例ではありません。

どのフレームワークを選ぶかは、まず何を改善したいかによって決まります。開発者個人とチームの体験・生産性を改善したいならSPACEかDevExが適しています。SPACEは生産性を複数の次元で広く捉えたいとき、DevExは具体的な摩擦点(待ち時間、認知負荷、中断)を見つけて改善したいときにより適しています。社内ツールやプラットフォームをプロダクトのように運営しユーザーの反応を見たいならH.E.A.R.Tが、組織のソフトウェアデリバリー成果を見たいならDORA指標が適しています。これらのフレームワークは互いに排他的ではないため、下記のAI時代の適用例のようにDORA指標(デリバリーの結果)とH.E.A.R.T(ツールのユーザー体験)を併用する組み合わせも可能です。

ステップ1: なぜ測るかを決める

フレームワークは測定の 「なぜ」 です。以下を検討します。

なぜ今か？ 測定の動機となる変化があったか？
洞察をどう行動に移すか？
測定で可能にする決定・改善はあるか？

一般的なフレームワークは開発者体験、製品の卓越性、組織の効果性という異なる目標に焦点を当てます。

ステップ2: 何をどう測るかを決める

メトリクスはフレームワークに寄与する概念です。データ収集法は大きく2つです。

自己申告データ(Self-reported) — サーベイ・インタビュー・フォーカスグループ・日記研究

長所: 満足度・ウェルビーイング・知覚された効果性など、自動化で定量化しにくい主観的体験を捉える。ツールチェーンの計測負担が少ない
短所: 標準化・チーム間比較・大規模拡張が難しく、想起バイアス・社会的望ましさバイアスに弱い

ログ基盤の測定(Logs-based) — ツール・システムから自動収集

種類: 数量（コミット・ユーザー数）、時間基盤（コーディング・レビュー時間）、頻度（月次デプロイ、週次PR）
長所: 継続的・標準化された大規模データ、活動・アウトプットの詳細なビュー
短所: 十分な可観測性（統合・収集の仕組み）が必要で参入障壁が高い。ログ基盤が客観的というのは誤解 — 計測方法・誤差・解釈バイアスが存在

メトリクスは材料、フレームワークはレシピ。 一部の材料は複数のレシピに使われ、一部は特定レシピ専用です。すべての材料がなくても美味しい料理は作れます。

AI時代にフレームワークを適用する

技術的激動期でも実際に何を変えるべきかを慎重に検討すべきです。

AIが開発者体験に与える影響を理解するにはいくつかの指標を追加すれば足りる場合が多い。既存の測定を基準線として維持しましょう。
例: AI提案の受容率、モデル品質、信頼の指標を追加しつつ、知覚された生産性・コードレビュー時間といった既存指標は維持。
目標が同じならフレームワークを変える必要はない。 測定を拡張すればよい。
よくある問い: AIがコード品質に与える影響。 速度のために品質を犠牲にしているのではと懸念されます。短期的な速度向上が長期的にはネガティブになりえます。
- この目標は既存指標（コード品質、ツール採用、知覚された速度）を再利用して達成可能です。
- 例: DORAデリバリー指標 + H.E.A.R.T の組み合わせが効果的です。

PDCA実行フレーム

Plan: 目標設定、フレームワーク選択、リーダーシップの後援確保
Do: 基準線を測定、違うやり方を試す
Check: 再測定で進捗確認
Adjust: 発見に基づきアプローチを変更

結論

特定のフレームワークを推薦しません。組織に響き行動を促すなら、それが今の正しいフレームワークです。目標が同じなら既存の測定を適応・活用できます。

出典

組織目標に合った測定フレームワークの選択 ​

核心命題 ​

主要フレームワークの比較 ​

ステップ1: なぜ測るかを決める ​

ステップ2: 何をどう測るかを決める ​

AI時代にフレームワークを適用する ​

PDCA実行フレーム ​

結論 ​