TL;DR
- DORA と SPACE は「どちらが優れているか」を比べる指標ではなく、測っているレイヤーが違う（DORA = デリバリーの結果、SPACE = チームの状態）
- 「DORA か SPACE か」で議論が空転するチームは、まず観測したい問題が結果側か原因側かを 1 行で言語化する
- 軸が「速度・安定性の現在地」なら DORA、「疲弊・コラボの兆候」なら SPACE、「個人の摩擦」なら DevEx を選ぶ
- 併用は可能だが、最初は 1 フレームワーク・最大 3 指標から始める。最初から 10 指標を並べると運用が崩壊する（経験則）
- 自チームでは DORA から始め、Cycle Time が改善した後で SPACE の Satisfaction を足した。順番が逆だと Goodhart の法則に飲まれる
「DORA か SPACE か」で議論が空転する理由
こんにちは、みねです。
「うちも開発生産性を測ろう」となったとき、最初の会議でほぼ確実に発生するのが「DORA がいいのか、SPACE がいいのか問題」だ。EM は「Four Keys を取りたい」と言い、テックリードは「いや SPACE のほうが多面的だ」と返し、CTO は「DevEx って最近聞くけどそれは？」と質問する。1 時間後、結論は出ない。
私自身、この会議を 3 回やった。3 回目で気づいたのは、両者は競合していないということだ。比較対象として並べた瞬間に議論が空転する。理由はシンプルで、DORA と SPACE は測っているレイヤーが違う。
- DORA は「デリバリーの結果が、世間と比べて速いか・壊れていないか」を測る[公式値]ベンチマーク指標
- SPACE は「チームの状態（満足度・コラボ・効率）が、健康に保たれているか」を測る多次元指標
血液検査の結果（DORA）と、生活習慣の問診票（SPACE）を並べて「どっちが正しいか」と議論しているのと同じだ。両方必要だが、目的が違うので最初から両方やると破綻する。
本記事では、EM・CTO・スクラムマスター向けに、自チームがいま採るべき 1 つを決めるための判断軸を整理する。読み終わったあと、フレームワーク 1 つと指標 1〜3 個に絞れている状態がゴールだ。
なお、開発生産性指標全体の入門は開発生産性指標の歩き方：チームに合った定規の選び方で扱っている。本記事は「選定の判断軸」に絞って深掘りする。
DORA と SPACE は別レイヤーの指標
最初に、両者の位置づけを揃えておく。ここで誤解を残すと、後段の判断軸が刺さらない。
DORA：デリバリーの「結果」を測る
DORA（DevOps Research and Assessment）は、Google Cloud 配下の研究チームが発表しているフレームワークで、ソフトウェアデリバリーパフォーマンスを 5 指標 で集約する[公式値]。長らく「Four Keys」として 4 指標で普及してきたが、2024 年に Deployment rework rate が追加され、現行の DORA 公式ガイドでは 5 指標モデルとして整理されている。
Throughput（速度）
- Deployment Frequency：本番デプロイ頻度
- Change Lead Time：コミットから本番反映までの時間
- Failed Deployment Recovery Time（旧 MTTR）：障害復旧時間
Instability（安定性）
- Change Fail Rate：変更による障害率
- Deployment Rework Rate（2024 年追加）：再デプロイの発生率
補足: 2021 年に「fifth metric」として言及された Reliability は運用パフォーマンス側の概念で、現行のソフトウェアデリバリー 5 指標の 5 番目ではない（DORA 公式履歴）。
DORA の年次レポートは、世界中の開発組織を Elite / High / Medium / Low の 4 ティアに分けたベンチマークを提示する。なお年次レポートは 2025 年に State of AI-assisted Software Development へ改称されており、2024 年版の Accelerate State of DevOps Report は「2024 年版」として参照されることが多い。ここが DORA の最大の特徴で、「自チームは世界基準のどこにいるか」が数値 1 つで言える。
ただし、DORA が見ているのは結果側だ。デプロイ頻度が下がった理由が「テスト不足」なのか「レビュー遅延」なのか「メンバーの疲弊」なのかは、Four Keys からは分からない。
SPACE：チームの「状態」を測る
SPACE（Forsgren, Storey, Maddila, Zimmermann, Houck, Butler / ACM Queue 2021）は、生産性を 1 つの軸ではなく 5 次元で見るフレームワークだ[公式値]。
- Satisfaction and well-being（満足度・ウェルビーイング）
- Performance（成果物の品質）
- Activity（活動量。コミット・PR 数等）
- Communication and collaboration（コミュニケーション・コラボレーション）
- Efficiency and flow（効率・フロー）
論文の中核主張は「生産性は 1 つの指標で測れない。3 次元以上を組み合わせろ」というものだ。Activity だけで評価すると、コミット数を稼ぐためのノイズコミットが増える（Goodhart の法則 = 「指標が目標になると、その指標は良い指標ではなくなる」）。Performance だけだと、品質を上げるために速度が犠牲になる。多次元で見ることで、片側を最適化したときに別の側が悪化していないかを検知する。
SPACE は原因側を見る指標で、Satisfaction が下がっていれば「数字には出ていないが疲弊が始まっている」ことが先に分かる。
DevEx：個人の「摩擦」を測る
DevEx framework（Noda, Storey, Forsgren, Greiler / ACM Queue 2023） は SPACE と並ぶ補完的フレームワークで、開発者個人の摩擦を扱いやすくするために 3 軸で構成される[公式値]。
- Feedback Loops：ビルド時間・テスト時間・レビュー反応の速さ
- Cognitive Load：理解・運用に必要な認知負荷
- Flow State：集中を阻害される頻度
DevEx in Action（2024） で「DevEx を改善した組織は DORA 指標も改善する」という相関も報告された[公式値]。SPACE と DevEx は競合ではなく、SPACE が「単一指標を避けて 3 次元以上を組み合わせる」原則であるのに対し、DevEx は Feedback Loops / Cognitive Load / Flow State に測定対象を絞った prescriptive な姉妹フレームワーク、と整理するのが原典に沿った扱いである（DORA 公式 Measurement Frameworks）。
:::message 3 つのフレームワークの関係を 1 行で：DORA は「結果のベンチマーク」、SPACE は「チーム状態の地図」、DevEx は「個人の摩擦の温度計」。レイヤーが違うので、最初から 3 つ全部やる必要はない。 :::
早見表：5 つの判断軸で DORA / SPACE / DevEx を比べる
レイヤーが違うことを押さえた上で、自チームがどれを採るかを決める判断軸を 5 つに絞った早見表で示す。
| 判断軸 | DORA | SPACE | DevEx |
|---|---|---|---|
| 見ているもの | デリバリー結果 | チーム状態（多次元） | 個人の開発体験 |
| 計測コスト | 低（ツールから自動取得可） | 中〜高（アンケート要） | 中（アンケート＋ログ） |
| ベンチマーク有無 | あり（Elite/High/Medium/Low） | なし | なし（自社推移で見る） |
| 数値の客観性 | 高（ログベース） | 中（主観入る） | 中（主観＋客観の混合） |
| 改善打ち手の特定しやすさ | 中（結果から原因を辿る） | 高（多次元で異常検知） | 高（摩擦点を直接特定） |
| 想定リードタイム（成果まで） | 3〜6 ヶ月（経験則・10〜30 名規模） | 6〜12 ヶ月（経験則・同規模） | 3〜6 ヶ月（経験則・同規模） |
ポイントは 2 つ。
- DORA は他社比較が可能、SPACE と DevEx は自社推移のみ。経営層に「業界比でどうか」を出す必要があるなら DORA がほぼ唯一の選択肢になる。
- 改善打ち手の特定しやすさは SPACE / DevEx のほうが高い。DORA で「Lead Time が長い」と分かっても、原因が「レビュー遅延」「ビルド遅延」「テスト不足」のどれかは分からない。SPACE / DevEx は最初から原因軸で測っている。
決定木：あなたのチームはどちらを採るか
早見表をそのまま意思決定には使えない。実務では「自チームが今どの状態か」で答えが変わる。決定木の形で示す。
Q1: 経営層／株主／顧客に「業界比の生産性」を報告する義務がある？
Yes → DORA を採る（ベンチマーク付き指標が必要）
No → Q2 へ
Q2: 直近 3 ヶ月、デリバリー（リリース・デプロイ）に明確な詰まりを感じる？
Yes → DORA を採る（結果側の指標で詰まりを可視化）
No → Q3 へ
Q3: 直近 3 ヶ月、メンバーの疲弊・離脱・退職兆候を感じる？
Yes → SPACE を採る（Satisfaction and well-being の早期検知）
No → Q4 へ
Q4: 開発者個人から「ビルド遅い／レビュー待ち長い／環境が辛い」の声が上がっている？
Yes → DevEx を採る（摩擦点の特定が最速）
No → 何も採らない（測定の前に解くべき問題がない）
最後の Q4 がポイントだ。「測ることが目的化」している組織が一定数ある。指標は問題があるから測るのであって、測るために問題を作るのではない。Q1〜Q4 すべて No なら、いったん指標導入は見送って 3 ヶ月後に再評価するのが筋がいい（経験則）。
:::message 「ぜんぶ Yes」のチームへ：その場合も、最初に採るのは 1 つだけにする。3 つ並列で始めると、各フレームワークの計測ツールが 3 つ必要で、運用工数が破裂する。優先順位は DORA → DevEx → SPACE（採用コストの低い順）。 :::
トレードオフ：採用したときに失うもの
どの指標も「採用すれば全部わかる」ものではない。それぞれ採用したときに見えなくなるものがある。これを把握しないと、後で「なぜ気づかなかったのか」になる。
DORA を採るときに失うもの
- 疲弊の兆候：Four Keys が良好でも、メンバーが疲弊している組織は普通にある。Lead Time の改善が「個人の超過稼働」で達成されていても、DORA からは見えない
- 個人差：チーム平均で評価するため、特定メンバーへの依存（バス係数 1）が起きていても顕在化しない
- Goodhart の罠：Deployment Frequency を上げるために「分割しなくていい PR を分割する」「中身のないデプロイを回す」が始まる組織を見たことがある（経験則）
対策は SPACE の Satisfaction を半年ごとに併走させることと、DORA を個人評価には使わない運用ルールを最初に明文化することだ。
SPACE を採るときに失うもの
- 客観性の一部：Satisfaction や Communication はアンケートに依存するため、回答バイアス・忖度が混じる
- 業界比のベンチマーク：論文には「3 次元組み合わせろ」とは書かれているが、Elite ティアのような他社比較は提示されていない。経営層に「業界比でどうか」を聞かれたときに答えられない
- 計測の重さ：5 次元×複数指標で組むと、ダッシュボードが重くなり、「結局誰も見ない」状態になる組織を見た（経験則）
対策は、5 次元すべてを最初から取らないことだ。SPACE 論文自体が「3 次元以上」と言っており、5 次元全部やれとは書いていない[公式値]。
DevEx を採るときに失うもの
- デリバリーの結果側の見落とし：DevEx が改善しても、デプロイ頻度や障害率が悪化していないかは別途見る必要がある
- 「個人の不満」と「組織の課題」の混同：DevEx は個人の摩擦に近いため、組織として優先すべき課題と個人の趣味の境界が曖昧になる
対策は、DevEx の改善が DORA Four Keys にも反映されるかを 6 ヶ月後にチェックすることだ。DevEx in Action（2024） では相関が報告されているが、自チームでも追従するかは実測しないと分からない。
アンチパターン：選定でやりがちな失敗
3 回ほど「うちも開発生産性を測る」プロジェクトに関わったが、選定段階で同じ失敗を見た。先に共有しておく。
アンチパターン 1：3 つ全部いっぺんに導入する
「DORA + SPACE + DevEx で完全に網羅しよう」と意気込むパターン。確実に運用が崩壊する。理由は単純で、ダッシュボードが 3 枚に分裂するためだ。誰も全部見ない。各指標の計測ツールも別々で、Slack 通知も別々で、半年後にどれかが止まっていることに誰も気づかない。
最初は 1 フレームワーク・最大 3 指標。これで運用が回ったら次を追加する。
アンチパターン 2：個人評価に使う
DORA を個人の評価に使い始めた瞬間、Deployment Frequency を上げるためのノイズコミット・分割 PR・空デプロイが発生する。SPACE も同じで、Satisfaction が低い人が「評価に響く」と感じれば、アンケートで本音を書かなくなる。
DORA はチーム単位、SPACE / DevEx は改善トリガーとして使う。個人評価には絶対に使わない。これは導入前に明文化する必要がある。
アンチパターン 3：ベンチマーク追従だけを目的にする
「DORA Elite を目指す」と宣言したチームを何度か見たが、ほぼ全部 1 年以内に頓挫した。理由は、Elite ティアの数値は結果であって、目指すべき目標ではないからだ。Elite 組織は組織構造・テスト自動化・デプロイ基盤がそこに到達するように設計されている。数値だけを真似ると、土台のないままベンチマークだけが先行する。
DORA は「現在地」を知る道具で、「目標」を決める道具ではない。目標は自チームの Δ（前月比改善幅）で立てる。Cycle Time の改善ループの組み方はCycle Time の定義と改善：境界を引く改善ループで扱っている。
アンチパターン 4：ツール導入が先行する
ベンダーの営業を受けて「LinearB / Jellyfish / Swarmia 入れてみた」から始まるパターン。ツールは指標の選定が終わった後で選ぶ。先にツールを入れると、ツールが提供する指標に思考が引っ張られて、自チームの問題と無関係な数字を追いかける羽目になる。
ThoughtWorks Technology Radar では DORA metrics を Adopt としつつ、複雑なダッシュボード構築よりチームのレトロスペクティブで使うことを推奨している。ツールではなく指標とフレームワークから入る順番を守る。
併用するときの設計指針
「最初は 1 つ」と書いたが、半年〜1 年運用したあとは併用する場面が出てくる。そのときの設計指針を 3 つだけ残す。
- 層を分ける：DORA は「経営層レポート用」、SPACE/DevEx は「チーム改善用」と用途を明確に分ける。同じダッシュボードに混ぜない
- 指標の総数を絞る：併用しても全指標数は 5 を超えない。DORA から 2 つ（例：Lead Time と Change Failure Rate）、DevEx から 2 つ（例：Feedback Loops の Build Time、Cognitive Load の Onboarding 時間）程度
- 更新周期を揃えない：DORA は週次/月次、SPACE は四半期、DevEx は月次、のように周期をずらすと運用負荷が分散する
自チームでは DORA で半年運用したあと、Lead Time が頭打ちになったタイミングで SPACE の Satisfaction を足した。順番として、結果指標で改善幅が止まってから状態指標を追加するのが筋がいい。最初から両方並べると、どちらの数値変化が原因かが切り分けられない。
なお、AI コーディングツール導入後の生産性パラドックスは別軸の論点で、AI生産性のパラドックス：なぜ「速くなった」のにチケットが消えないのかで扱っている。本記事の選定基準と併せて、AI 導入時には DevEx の Feedback Loops を先に見るのが勧められる（経験則）。
レビュー運用の設計が指標改善のボトルネックになっているケースも多いので、AI時代のレビュー運用設計も併せて参照してほしい。仕様駆動開発の落とし穴は仕様駆動開発の落とし穴と対策で別途整理している。
:::message 3 ヶ月後の自分への申し送り：指標を増やしたくなったら、増やす前に既存指標で止まっていないかを必ず確認する。止まっていない指標を放置して新指標を増やすと、運用が崩壊する。 :::
FAQ
Q1: DORA と SPACE、結局どちらが「優れた」フレームワークなのか？
優劣はない。測っているレイヤーが違う。DORA はデリバリー結果のベンチマーク指標、SPACE はチーム状態の多次元指標で、目的が違うので比較できない。経営層への業界比報告が必要なら DORA、チームの疲弊兆候を早期検知したいなら SPACE が選ばれる。両方やる場合も、最初は 1 つから始めるのが現実的。
Q2: Four Keys は古い・遅いという話を聞いたが、まだ使えるのか？
使える。DORA は 2024 年に Deployment Rework Rate を加えて 5 指標モデルへ整理し直し、年次レポートも 2025 年に State of AI-assisted Software Development へ改称したうえで研究を継続している[公式値]。「古い」と言われる文脈は、Four Keys だけで生産性を語るのは不十分という意味で、Throughput（旧 Four Keys のうち 3 指標）と Instability（Change Fail Rate / Deployment Rework Rate）に分けて読む現行モデルが陳腐化しているわけではない。SPACE / DevEx を併用するか、SPACE の Activity 軸として DORA 指標を取り込む構成が最近の実務寄り。
Q3: SPACE は 5 次元全部測らないと意味がないのか？
ない。SPACE 論文自体が「3 次元以上を組み合わせろ」としており、5 次元全部とは書いていない[公式値]。最初は Performance + Satisfaction + Efficiency の 3 次元から始めるのが運用しやすい。5 次元全部一度に取ると、ダッシュボードが破綻するので推奨しない。
Q4: DevEx は SPACE の置き換えになるのか？
置き換えではない。DevEx は SPACE と同じく単一指標を避ける思想を共有しつつ、Feedback Loops / Cognitive Load / Flow State に測定対象を絞った独立フレームワークで、DevEx in Action（2024） で「DORA とも相関する」ことが示されている[公式値]。SPACE が「組織の状態地図」、DevEx が「個人の摩擦の温度計」と捉えると役割が分かれる。
Q5: 指標導入を経営層にどう説得すればいいか？
「業界比の現在地が言えるか」という問いから始めるのが効きやすい（経験則）。DORA Four Keys は唯一公式ベンチマークがあるフレームワークで、Elite / High / Medium / Low のティア言語で経営層と会話できる。SPACE / DevEx は「自社の Δ（改善幅）を見るための指標」なので、経営層への単独報告には向かない。最初の 6 ヶ月は DORA で現在地を可視化し、改善打ち手のために SPACE / DevEx を後から足す順番が説得しやすい。
References
- DORA Metrics 公式ガイド — 2024 年に整理された 5 指標モデルの公式定義
- DORA / State of AI-assisted Software Development 2025 — DORA の年次レポート最新版（2025 年に Accelerate State of DevOps から改称）
- DORA / Accelerate State of DevOps Report 2024 — 2024 年版ベンチマーク
- DORA Quick Check — 自チームの DORA ティアを 5 設問で推定するセルフ診断
- SPACE 原論文（Forsgren, Storey, Maddila, Zimmermann, Houck, Butler / ACM Queue 2021） — 5 次元の定義と「3 次元以上組み合わせろ」の原典
- DevEx framework（Noda, Storey, Forsgren, Greiler / ACM Queue 2023） — Feedback Loops / Cognitive Load / Flow State の 3 軸の定義
- DevEx in Action（ACM Queue 2024） — DevEx 改善が DORA Four Keys にも波及する観測報告
- ThoughtWorks Technology Radar — DORA / SPACE / DevEx 系プラクティスの Adopt / Trial / Assess 推移を追える業界レーダー
まとめ
DORA と SPACE は競合する指標ではなく、レイヤーが違う。比較で議論を空転させる前に、自チームがいま観測したいのが結果側（DORA）か、状態側（SPACE）か、個人の摩擦側（DevEx）かを 1 行で決める。最初は 1 フレームワーク・最大 3 指標。半年運用して止まったら次を足す。
最後に、本記事で示した選定の道具を 3 つだけ残す。
- 早見表：判断軸 5 つで DORA / SPACE / DevEx を比較
- 決定木：4 つの Yes/No で 1 つに絞る
- アンチパターン：個人評価に使わない・3 つ全部やらない・ツール先行しない
今日の最小アクションは、自チームの「観測したい問題」を 1 行で書き出すことだ。書けないなら、まだ指標導入のフェーズではない。書けたら、決定木に当てて 1 つだけ選ぶ。1 ヶ月後に最初の Δ を見られる状態がスタートラインになる。
選定軸テンプレについて、自チームの状況をヒアリングして使い方を一緒に整理する記事診断を受け付けています。X（@mine_take）まで気軽に声をかけてください。
DORA の Failed Deployment Recovery Time や SPACE の Satisfaction が悪化しているチームでは、オンコール運用の見直しが先に効くケースがあります。具体的な打ち手は オンコール疲弊を防ぐ運用設計の手順 を参照してください。
