# DORA ## 定義 DORA (DevOps Research and Assessment) は、ソフトウェアデリバリーとオペレーション能力のパフォーマンスを計測するための研究プログラムおよびフレームワークである。[[Nicole Forsgren]] らが 2014 年に創設し、毎年の「State of DevOps Report」でソフトウェアデリバリーのパフォーマンスと組織成果の相関を定量的に研究してきた。 ### 4 つのコアメトリクス 1. **Deployment Frequency(デプロイ頻度)**: どれだけ頻繁に本番へリリースするか。 2. **Lead Time for Changes(変更のリードタイム)**: コードのコミットから本番稼働・安定化までの時間。 3. **Change Failure Rate(変更失敗率)**: 本番に適用された変更のうちインシデントを引き起こす割合。 4. **Mean Time to Restore(MTTR)**: サービス障害からの回復時間。 ### SRE 文脈での適用(Forsgren 2026) [[Nicole Forsgren]] は SREcon26 で DORA を「SRE 自身のパイプラインの計測」として内側向きに適用することを提案した: - **Deployment Frequency**: SRE チームが変更イベントに対応する頻度——オペレーションテンポのベースライン。 - **Lead Time for Changes**: 変更マージから安定稼働まで——パイプライン速度はリスク入力となる。 - **Change Failure Rate**: 変更の何%がインシデントを引き起こすか——摩擦誘発エラーのシグナル。 - **MTTR**: ヘッドラインの出力指標だが、**摩擦はその上流の入力**である。 ### 原典における指標選定の理由とクラスター分析(Accelerate 2018, 第2章) DORAの4指標を最初に体系立てて提示した原典が『LeanとDevOpsの科学［Accelerate］』第2章である。指標選定の条件は「グローバルな成果に焦点を当てチーム同士の対立を防ぐこと」と「生産量ではなく成果に焦点を当てること」の2つで、これを満たさない従来の生産性測定(コード行数・ベロシティ・利用率)はいずれも難点があるとして退けられた。デプロイの頻度は本来測定したいバッチサイズの代理指標として採用され、変更のリードタイムは「コードのコミットから本番稼働までの所要時間」と定義される(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 p.20-23)。 回答の分析にはクラスター分析(各測定基準を別次元に置き、同クラスター内の距離を最小化・クラスター間の差異を最大化するデータ駆動の分類手法)を用い、「良い」「悪い」の解釈を持ち込まずにハイ/ミディアム/ローパフォーマーの3集団を特定した。2016年調査ではデプロイ頻度・変更のリードタイム・MTTR・変更失敗率のいずれもハイパフォーマーが最良で、2017年調査でも同様の順序が確認された(具体的な数値は source ページ「主要主張」節を参照)。中心的な発見は「パフォーマンスの改善と安定性・品質の向上との間にトレードオフはない」という点で、ハイパフォーマーは4指標すべてで抜きん出ていた(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 p.25-27)。 ### 調査設計の骨子と2017年ヘッドライン数値(Accelerate 2018, 第1章) 第1章は、指標の詳細な定義に先立って調査の骨子を予告する。調査は4年間にわたり、あらゆる規模・あらゆる業種の世界中の組織(新旧さまざまなテクノロジーを利用)を対象とした。この調査から、ソフトウェアデリバリのパフォーマンスと組織パフォーマンスの双方を高める効果が高い、24のキーとなるケイパビリティ(24KC)が特定された(一覧は付録A)(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] ch.1 §1.2-§1.3)。 2017年時点のヘッドライン数値として、パフォーマンスが良好な組織はそうでない組織と比較して、デプロイ頻度46倍・リードタイム1/440・MTTR 1/170・変更失敗率1/5という差があったと報告される。2016年との比較では、速度(デプロイ頻度とリードタイム)の差は狭まった一方、安定性(MTTRと変更失敗率)の差は広がっており、本書はこれをパフォーマンスの振るわない組織が速度向上に努めつつプロセスの質への投資が追いつかないためと解釈する(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] ch.1 §1.3)。 ## 横断的知見 - **第1章の比率表現(デプロイ頻度46倍等)と第2章の絶対値レンジ(表2.3)は、同じ2017年調査結果を異なる粒度で提示する**: 第1章は「パフォーマンスが良好な組織とそうでない組織」の差を比率(デプロイ頻度46倍・リードタイム1/440・MTTR 1/170・変更失敗率1/5)という要約統計で先取りして示すのに対し、第2章はハイ/ミディアム/ローパフォーマーそれぞれの絶対値レンジ(ハイパフォーマーはオンデマンドで1日複数回のデプロイ・リードタイム1時間未満、ローパフォーマーは週1回から月1回のデプロイ・リードタイム1週間から1ヵ月)を表2.3として示す。前者は本編に先立つ骨子紹介、後者はクラスター分析による性能グループ定義の内訳であり、同一データセットに対する要約と詳細の関係にある。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] ch.1 §1.3, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 表2.3) - **DORA は 2021 年に初めて SRE を正面から調査対象とし、「信頼性は力積数（force multiplier）」という知見を導出した**: [[Dave Stanke]] は SREcon22 Americas で、DORA の 2021 年調査結果として「回答者の 52% が SRE プラクティスを何らかの形で実践」「SRE はバーンアウトを緩和し、共有責任は信頼性成果を予測し、信頼性はソフトウェアデリバリーパフォーマンスのビジネス成果への影響を乗算的に増幅する」と報告した。DORA の従来4指標（デプロイ頻度・変更リードタイム・復旧時間・変更失敗率）に Reliability が "Four + 1" の形で追加された。(Source: [[@2022__SREcon22Americas__DO RE Me - Measuring the Effectiveness of Site Reliability Engineering]]) - **DORA は開発者向けだけでなく SRE 自身にも適用できる**: Forsgren 2026 は、DORA が「SRE が支援する開発チームだけでなく SRE チーム自身の計測フレームワーク」であると主張する。SRE のツール・プロセスは DORA の変更失敗率と MTTR を直接悪化させる上流因子として捉えられる。(Source: [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]]) - **DORA は 2025 年に年次レポート名から「DevOps」を外し、組織名も頭字語ではなくなった**: 毎年発行してきた「Accelerate State of DevOps Report」を「State of AI-assisted Software Development」へ改称し、DORA 自体も DevOps Research and Assessment という頭字語ではなく単独の名前になった。mizzy(2026)はこれを、[[DevOps]] が包含していた計測(Measurement)という要素が DORA という独立領域に分解しきった到達点として位置づけている——DevOps という語がレポート名からも組織名からも消えた、という意味で。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **「速度と品質はトレードオフでない」という Accelerate(Forsgren, Humble, Kim, 2018)の中心的知見が、DORA 自身の計測フレームワークと、それを引用する別分野の書籍の両方から独立に参照される**: 『Observability Engineering』第2版9章は Accelerate の知見(エリートパフォーマーでは速度と品質が相乗的に向上する)を根拠に「本番稼働までのリードタイム」を実践の North Star メトリクスとして提案し、変更のバッチ化削減とデプロイパイプラインへの投資を改善手段に挙げる(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]])。これは DORA の 4 指標のうち Lead Time for Changes(変更のリードタイム)と Change Failure Rate(変更失敗率)が独立指標ではなく相乗的に動くという DORA 自身の実証知見と一致し、オブザーバビリティ駆動開発([[オブザーバビリティ駆動開発]])が DORA のメトリクス改善に資する実践として接続できることを示唆する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]], [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]]) - **CI/CDのビルドSLI/SLOは、DORAのLead Time for Changesの「実測可能な上流部分」を先取りする局所的な計測実践として位置づけられる**: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] は、CI/CDの成功率とend-to-endユーザー時間(コミットから変更が検証されるまでの時間)を「最初の暗黙的なSLI/SLO」と呼び、Honeycombの事例ではビルド時間の中央値変化(7分→14分→7分未満)を長期的に追跡してSLO運用(5%超過でアラート)まで組み込んでいる。これはDORAのLead Time for Changes(コミットから本番稼働・安定化までの時間)の一部区間(コミットからCI検証完了まで)を、DORA自体が指定しない粒度で計測・アラート化する具体的な実践例であり、DORAのマクロな4指標(四半期単位の集計が一般的)と、CI/CDオブザーバビリティ([[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]])のミクロな継続計測(ジョブ単位・分単位)が、同じ「リードタイム短縮」という目的の異なる時間解像度で補完し合うことを示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]], [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) - **DORAの2025年調査は「AIは組織の卓越性を新たに作らず、既存の行動パターンを増幅するだけ」と結論づけ、AI導入によるデプロイ頻度増加が変更失敗率をどう左右するかという本ページの未解決の問いに部分的な答えを与える**: 『Observability Engineering』第2版第23章(CTO Darragh Curranの公開書簡)は、DORAの2025年知見を引用し、強いフィードバックループと規律ある実践を持つ組織ではAIが優位性を増幅し、遅延シグナルと運用のヒロイズムに頼る組織ではAIが混沌を増幅すると述べる。これは「AIがデプロイ頻度を上げれば変更失敗率が指数的に増えるか、それとも品質向上で相殺されるか」という問いに対し、「どちらか一方に決まるのではなく、既存の組織のフィードバックループの強さに依存して分岐する」という条件付き回答を与える。第23章はこの現象をソシオテクニカル負債([[ソシオテクニカル負債]])という概念で説明しており、DORAが定量的に観測する「増幅」を組織論的に裏付ける関係にある。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]]) - **2025年のDORAレポートは「AI導入の成功はツールの問題ではなくシステムの問題である」と明言し、この主張が改称の実質的な理由として第24章から裏付けられる**: [[@2026__mizzy.org__DevOpsとは何だったのか]] は DORA が2025年に年次レポート名から「DevOps」を外し「State of AI-assisted Software Development」へ改称したという事実を記録するが、その改称の背景にある問題意識までは踏み込まない。一方 [[@2026__OReilly__Observability Engineering 2E - Chapter 24 Systems Thinking for Software Delivery]] は同じ2025年のDORAレポートから「successful AI adoption is a systems problem, not a tools problem」(p.4)、および「AIがソフトウェア開発を劇的に加速させるとき、制御システム——それは私たち自身だ——も同様に高速化しなければならない」(p.9)という一次的な主張を引用する。両ソースを突き合わせると、DORA の2025年改称は単なるレポート名の刷新ではなく、「AI時代の課題はツール選定ではなく組織というシステム全体のフィードバックループの速度にある」という理論的立場の表明だったと解釈できる。(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]], [[@2026__OReilly__Observability Engineering 2E - Chapter 24 Systems Thinking for Software Delivery]]) - **State of DevOps Report 2023の「J字カーブ」は、2025年の「AIは既存の行動パターンを増幅するだけ」という知見が成立する時間的前提を補う**: 『SREをはじめよう』第11章は、DORAのSteve McGheeがメールで語った「能力(今どんな新しいことができるか)が本当に蓄積されるまで、結果(実際の信頼性)は本当には築かれない」という2023年報告の趣旨を紹介し、これを「累積(cumulative)」と呼ぶ。信頼性投資の効果曲線はJ字型で、能力の蓄積が先行し結果は遅れて現れる。この「遅延」構造は、第23章が引用する2025年知見「AIは既存の行動パターンを増幅するだけ」(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]])と組み合わせると、AI導入の効果が組織のフィードバックループの強さに応じて分岐する背景に、そもそも信頼性投資の成果自体が短期では観測されにくいJ字カーブ構造があることを示唆する——AIによる増幅を測定しようとする組織は、増幅対象となる基礎的な能力蓄積がまだJ字カーブの上り坂に達していない可能性を考慮する必要がある。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 11 成功のための組織的要因]], [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]]) - **DORA 2018 State of DevOps Report の「変革の J カーブ」は、『SREをはじめよう』第11章が引く2023年の「累積的能力→結果の遅延構造」の、より早期かつ一次的な図解である**: 『SREエンタープライズロードマップ』第3章(図3-1)は、DORA 2018 State of DevOps Report の変革の J カーブを、チームが変革に着手してクイックウィンで低パフォーマーから中パフォーマーへ進んだ後、自動化がテスト要件を増やし手作業の対処が技術的負債と複雑性を増大させ、手動統制とプロセス層を招いて一時的に作業が遅くなる谷を経て、絶え間ない改善によって高・エリートパフォーマーへ至る S 字状の軌跡として図示する。これは既出の「State of DevOps Report 2023 の『J字カーブ』は、能力(今どんな新しいことができるか)が本当に蓄積されるまで、結果(実際の信頼性)は本当には築かれない」という Steve McGhee のメール引用(『SREをはじめよう』第11章)の 5 年前の一次資料にあたり、2023 年の言及が定性的な比喩(「累積」)にとどまっていたのに対し、2018 年のレポート自体は谷の内部構造(自動化によるテスト要件増加→手作業の対処→技術的負債と複雑性の増大→手動統制とプロセス層の付加→作業の遅延)を具体的な因果連鎖として示している点で、より詳細な一次情報を与える (Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]], [[@2024__OReillyJapan__SREをはじめよう - Chapter 11 成功のための組織的要因]])。 - **ルーフショットとムーンショットという二段構えは、J カーブの谷を渡り切るための実務的な処方箋であり、本ページ既出の「速度と品質はトレードオフでない」というエリートパフォーマーの到達点との間に「谷を渡る過程」という抜けていた段階を埋める**: 第3章は、変化の J カーブを認識したうえで、最初はある程度簡単に成功した後にインパクトのある変化を実現するためのカーブが難しくなり、新しい自動化システムを導入しても大きな成果の前に一歩後退したように感じられることがあると述べ、対処としてルーフショット(屋根、控えめな目標)とムーンショット(月着陸、劇的な目標)の両方を用意し、最初は控えめにしつつ成功への準備をすることを勧める。Accelerate(Forsgren, Humble, Kim, 2018)の「エリートパフォーマーでは速度と品質が相乗的に向上する」という知見(『Observability Engineering』第2版第9章が引用)は J カーブの右端(谷を渡り切った後の定常状態)を描写するが、谷そのものをどう渡るかという実務的な処方は Accelerate 単体からは読み取れず、本章のルーフショット/ムーンショットの二段構えがその欠落を埋める (Source: [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]], [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]])。 - **「速度と品質はトレードオフでない」という2次引用(Observability Engineering 2E第9章)の主張は、原典(Accelerate第2章)のクラスター分析結果によって具体的な数値の裏付けを持つ**: 本ページ既出の知見は『Observability Engineering』第2版9章が「Accelerate(Forsgren, Humble, Kim, 2018)の知見」としてトレードオフ神話の否定を要約引用していることを記録するが、その要約は2次資料からの言及にとどまっていた(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]])。原典である『LeanとDevOpsの科学［Accelerate］』第2章を直接確認すると、この主張は抽象的な言明ではなく、2016年・2017年の実際の調査で4指標(デプロイ頻度・変更のリードタイム・MTTR・変更失敗率)すべてにおいてハイパフォーマーが最良の値を記録したという具体的なクラスター分析結果に基づく。特に2017年調査では変更失敗率が0-15%(ハイパフォーマー)対31-45%(ローパフォーマー)という3倍近い差がありながら、同時にデプロイ頻度・リードタイムでもハイパフォーマーが優位という「速度と品質が同時に高い」実測データが、抽象的な「トレードオフ神話」という要約の後ろにあることがわかる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 表2.2・表2.3, [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]]) - **DORAの4指標は2018年のAccelerate出版時点で既に確立していたが、その内実は「デプロイ頻度」を通じてバッチサイズという別のリーン概念の代理指標であり、mizzy(2026)が描く「DevOpsからDORAへの分解」プロセスより前から独自の理論的系譜(リーン生産方式)を持っていた**: 本ページ既出の知見は、mizzy(2026)がDevOpsの「Measurement」要素がDORAという独立領域に分解していった到達点として2025年の改称を位置づけることを記録する(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。Accelerate第2章を直接確認すると、4指標のうちデプロイ頻度は元来「バッチサイズ削減」というリーン手法由来の目標(トヨタ自動車の生産方式を典拠に挙げる)の代理指標として選ばれたものであり、DevOpsという運動の計測要素として後から派生したのではなく、リーン生産方式という独立した理論的基盤から指標が導出されている。これは、DORAの4指標が「DevOpsの分解物」という単純な系譜だけでなく、リーン生産方式という別の系譜も持つことを示す。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 p.22-23, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **第5章は Deployment Frequency(デプロイ頻度)を「開発者1人当たりの1日のデプロイ件数」という個人単位の粒度に分解し、これが組織規模の拡大によってどう変化するかを示すことで、第2章のチーム単位のデプロイ頻度指標に「スケール依存性」という新しい軸を加える**: 本ページ既出の知見(第2章)は、デプロイ頻度がハイ/ミディアム/ローパフォーマーで有意差を示すという横断的な(ある時点での)比較を記録する。第5章は同じデプロイ頻度という指標を開発者数という別の変数と掛け合わせ、開発者数が増えるにつれてローパフォーマーではデプロイ頻度が落ち、ミディアムパフォーマーでは変わらず、ハイパフォーマーでは有意に上がるという結果を示す(図5.1)。これは「デプロイ頻度が高いか低いか」という静的な分類(第2章)を、「組織が成長するときデプロイ頻度がどう動くか」という動的な予測(第5章)へ拡張するものであり、第5章はこの現象の要因を[[疎結合のアーキテクチャ]](テスト容易性・デプロイ容易性)に帰す。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 表2.2・表2.3, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] ch.5 p.77-79) - **第7章の変更承認プロセス調査は、第2章が定義する4指標のうち3つ(リードタイム・デプロイ頻度・MTTR)と変更失敗率とで、非対称な相関パターンを示す**: 本ページ既出の知見(第2章)は、ハイパフォーマーが4指標すべてで最良の値を記録し「速度と品質はトレードオフでない」ことを示した。第7章は、これとは別の調査軸として「本番環境への変更にチーム外の人や組織(管理者やCAB)の承認を必須とするプラクティス」の効果を測定し、このプラクティスがリードタイム・デプロイ頻度・サービス復旧までの所要時間(MTTR)の3指標とは負の相関を示す一方、変更失敗率とは相関しないという結果を得た。つまりチーム外承認は「速度」側の3指標を悪化させるが「品質」側の指標(変更失敗率)は改善しない——チーム外承認は品質を犠牲にせず速度だけを犠牲にする、純粋なコストにとどまることを示す。ハイリスクな変更のみ承認必須とするプラクティス(シナリオ2)は4指標いずれとも相関せず、ピアレビューのみ・変更承認プロセスなしのチームの方が高いパフォーマンスを示した。第2章の「4指標間にトレードオフはない」という知見と、第7章の「変更承認プロセスの重さは変更失敗率を改善しないまま速度だけを下げる」という知見を合わせると、4指標の相関構造は一様ではなく、扱う独立変数(継続的デリバリのケイパビリティか、変更承認プロセスの重さか)によって指標間の結びつき方が変わることが分かる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] ch.2 表2.2・表2.3, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] ch.7 §7.2) - **DORAの起源(2012-2013年、Puppet社とGene Kim・Jez Humble・Nicole Forsgrenの草の根的な合流)と、2025年の改称(DevOps色の除去)は、同じ組織の20年弱にわたる軌跡の始点と終点にあたる**: 本ページ既出の知見は、DORAが2025年に年次レポート名から「DevOps」を外し組織名も頭字語ではなくなった到達点を記録する(Source: [[@2026__mizzy.org__DevOpsとは何だったのか]])。『LeanとDevOpsの科学［Accelerate］』「はじめに」を直接確認すると、この研究の出発点は2012年に[[Puppet]]社のチームがDevOpsという(当時まだ広く知られていなかった)概念の理解と採用状況の把握を目的に始めた調査であり、同年[[Gene Kim]]に参画を求め、Gene Kimがその後[[Jez Humble]]を誘い、さらに[[Nicole Forsgren]]が加わって2013年末に3人共同の研究体制が固まった。初回(2014年版)の回答数は4,000件でこの種の調査では当時最大規模だったが、2017年版までの4年間で累計23,000件超・2,000社超まで拡大している。DevOpsという概念がまだ輪郭を持たなかった時期の草の根的な協業から出発した調査が、10年余りを経てDevOpsという語を自ら手放すところまで到達した、という組織の連続性が両ソースを突き合わせて初めて見える。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Introduction はじめに]] p.xxiv-xxvi, [[@2026__mizzy.org__DevOpsとは何だったのか]]) - **Accelerate 自身の結びの言葉は、Jカーブが図示する谷の存在を定性的に認めてはいるが、渡り方の具体的な処方は示さない**: 本ページは、DORA 2018 State of DevOps Report の J カーブ(谷)構造と、谷を渡る実務的処方(ルーフショット/ムーンショット)が『SREエンタープライズロードマップ』第3章にのみ記録され、Accelerate 単体からは読み取れないと既に記している。Accelerate 第17章「おわりに」は本編の結びで、「『ハイパフォーマンス』とは購入したり真似したりできるものではない」「自身のケイパビリティを高めつつ自チーム・自組織の現況や目標にしっくりくる道を模索する必要がある」「これには絶え間ない努力、投資、集中、時間を要する」と述べる。これは J カーブが図示する谷(自動化によるテスト要件増加から手動統制の付加までの遅延区間)の存在を、著者ら自身が定性的な言葉で先取りして認めていることを示す一方、その谷をどう渡るかという具体的な技術的処方(ルーフショット/ムーンショットに相当するもの)は第17章にも見当たらない。両章を突き合わせると、「Accelerate は谷の存在は認めるが渡り方は示さない」という構造が、本編の結びの言葉自体によっても裏づけられることが分かる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 17 おわりに]] ch.17 p.233, [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]]) - **第1章が「一覧は付録A」と先取りして予告した24のキーとなるケイパビリティ(24KC)は、付録Aで初めて5つのカテゴリー(継続的デリバリ・アーキテクチャ・製品とプロセス・リーン思考に基づく管理と監視・組織文化)への分類と各章への対応づけを与えられる**: 本ページ既出の知見は、第1章が調査の骨子紹介の中で「24のキーとなるケイパビリティ(24KC)が特定された(一覧は付録A)」と述べるにとどまり、その内訳やカテゴリー構造までは示さないことを記録する(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] ch.1 §1.2-§1.3)。付録Aを直接確認すると、24のケイパビリティは実際には5つのカテゴリー(継続的デリバリ8件・アーキテクチャ2件・製品とプロセス4件・リーン思考に基づく管理と監視5件・組織文化5件)に分類され、各ケイパビリティには詳説している章(主に第3〜8章・第10〜11章・第13章)が個別に対応づけられている。第1章の「予告」と付録Aの「内訳」を突き合わせることで、24KCが単なる列挙ではなく、本書全体の章構成(継続的デリバリ=第4・6章、アーキテクチャ=第5章、製品とプロセス=第8章、リーン思考の管理・監視=第7・13章、組織文化=第3・10・11章)と1対1に対応する分類体系であることが分かる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] ch.1 §1.2-§1.3, [[@2018__Impress__LeanとDevOpsの科学 - Appendix A 改善促進効果の高いケイパビリティ]] 付録A §A.1-§A.5) ## 未解決の問い - 「はじめに」が述べる4年間累計23,000件超・2,000社超という標本規模のうち、2014年単年の4,000件から2017年版までどのように増加したか、年度ごとの内訳は第15章(データの収集方法)で確認できるか。 - 第1章のヘッドライン比率(デプロイ頻度46倍・リードタイム1/440・MTTR 1/170・変更失敗率1/5)は、第2章のカテゴリ別レンジ(表2.3)からどう算出されたか。代表値(中央値・平均値)のどちらを用いた比率なのか、原典に明示的な計算式の記載があるかは本 concept の現ソース群では未確認。 - 2016年にミディアムパフォーマーの変更失敗率(31-45%)がローパフォーマーのそれ(16-30%)を上回るという逆転が生じた。Accelerate第2章はレガシーコードベースの大規模リアーキテクチャによる未解消の技術的負債を有力な解釈として挙げるが「最終的な結論はまだ出ていない」と留保している。この現象は後年のDORA調査(2019年以降のState of DevOps Report等)で再検証・確定されたか、本concept の現ソース群では未確認。 - デプロイ頻度はバッチサイズの代理指標として採用され、両者には逆相関があるとAccelerate第2章の脚注は述べる(デプロイ頻度を上げるとバッチサイズが小さくなる)。この逆相関は後年のDORAレポートで定量的に検証されているか。 - State of DevOps Report 2023の「J字カーブ」に、能力蓄積から結果(信頼性向上)が現れるまでの典型的な期間についての定量的な記述はあるか。『SREをはじめよう』第11章は定性的な言及(McGheeのメール引用)にとどまり、レポート原典(33ページ)の確認が必要。 - CI/CDのビルドSLI/SLO(ジョブ単位・分単位の粒度)とDORAのLead Time for Changes(四半期集計が一般的なマクロ指標)を接続する標準的な集計方法は何か。両者を接続する具体的な変換式や運用例は、現時点で ingest したソースには見当たらない。 - SRE チームが DORA を内側向きに適用するとき、「変更(change)」の定義は何か——コードリリースか、設定変更か、ランブック更新か。 - 「AIは既存の行動を増幅するだけ」という2025年知見の具体的な調査方法・回答者属性・数値は、State of AI-assisted Software Developmentレポート原典でどう記述されているか。第23章はこの知見を要約引用するのみで、一次データは未確認。 - DORA のエリート/高/中/低の 4 段階分類は SRE チームのオペレーション能力の分類にどう翻案できるか。 - DORA 2021 の "Finding 4: There's room for growth" は SRE 実践にまだ大きな改善余地があるという論点と考えられるが、具体的な数値・インサイトは transcript なしでは不明。2021 年の State of DevOps Report で確認が必要。 ## 関連 - フレームワーク: [[SPACE]] / [[MTWTF]] - 提案者: [[Nicole Forsgren]] - SRE 概念: [[SRE]] / [[インシデント管理]] / [[エラーバジェット]] - 関連概念: [[オブザーバビリティ駆動開発]](リードタイム改善を支える開発プラクティス) / [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]](リードタイムの上流区間をミクロに計測する実践) / [[ソシオテクニカル負債]](AIによる増幅を組織論的に説明する概念) / [[レバレッジポイント]](「システムの問題」という2025年DORAの主張の理論的背景) / [[疎結合のアーキテクチャ]](デプロイ頻度のスケール依存性を説明するアーキテクチャ要因) - ソース: [[@2024__OReillyJapan__SREをはじめよう - Chapter 11 成功のための組織的要因]] — State of DevOps Report 2023のJ字カーブ(累積的な能力→結果の遅延構造) / [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]] — DORA 2018 State of DevOps ReportのJカーブの一次的な図解(図3-1)とルーフショット/ムーンショットの処方 - 原典: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] — 調査設計の骨子(4年間・あらゆる規模と業種)と24KC、2017年ヘッドライン数値(比率)を先取りして提示する導入章 / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] — DORA 4指標を最初に体系立てて提示した書籍原典。指標選定の理由・クラスター分析・2016/2017年の実測値 / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] — デプロイ頻度を開発者1人当たりの粒度に分解し、組織規模拡大時のスケール依存性を示す / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] — 変更承認プロセスの重さと4指標の非対称な相関(速度側3指標は悪化、変更失敗率は不変) / [[@2018__Impress__LeanとDevOpsの科学 - Appendix A 改善促進効果の高いケイパビリティ]] — 24KCの5カテゴリー分類と各章への対応づけ / [[Jez Humble]] / [[Gene Kim]] / [[wiki/entities/LeanとDevOpsの科学［Accelerate］|LeanとDevOpsの科学［Accelerate］]] / [[リーンマネジメント]](第7章のWIP制限・可視化・変更承認プロセスの構成要素をハブとして集約するconcept) - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2026__SREcon26 Americas__The WTF Problem - Developer Experience as a Reliability Property]] — p.18 で DORA 4 指標を SRE 文脈で再解釈 - [[@2026__mizzy.org__DevOpsとは何だったのか]] — DORA の 2025 年改称(DevOps 色の除去) - [[@2026__OReilly__Observability Engineering 2E - Chapter 9 Observability-Driven Development]] — Accelerate の「速度と品質のトレードオフは神話」という知見を引用し、リードタイムを North Star メトリクスとして提案 - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] — ビルドSLI/SLOをリードタイムの上流区間の実測実践として提示 - [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]] — DORA 2025年調査「AIは既存の行動パターンを増幅するだけ」を引用 - [[@2026__OReilly__Observability Engineering 2E - Chapter 24 Systems Thinking for Software Delivery]] — DORA 2025年レポート「successful AI adoption is a systems problem, not a tools problem」(p.4)を引用 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 11 成功のための組織的要因]] — State of DevOps Report 2023のJ字カーブをSteve McGheeのメール引用として紹介 - [[@2022__OReillyJapan__SREエンタープライズロードマップ - Chapter 3 SREの原則]] — DORA 2018 State of DevOps Reportの変革のJカーブ(図3-1)、谷の内部構造(自動化によるテスト要件増加→技術的負債と複雑性の増大→手動統制)、ルーフショット/ムーンショット - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 2 開発組織のパフォーマンスを計測]] — DORA 4指標(デプロイの頻度・変更のリードタイム・MTTR・変更失敗率)を最初に体系立てて提示した書籍原典。指標選定の理由、クラスター分析によるハイ/ミディアム/ローパフォーマー分類、2016・2017年の実測値、組織パフォーマンスとの相関(2倍超) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 5 アーキテクチャのキーポイント]] — デプロイ頻度を「開発者1人当たりの1日のデプロイ件数」という個人単位の粒度に分解し、組織規模拡大時にパフォーマンス群ごとに異なる挙動(ハイパフォーマーは増加・ローパフォーマーは減少)を示す(図5.1) - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 7 ソフトウェア管理のプラクティス]] — 変更承認プロセス(CAB等)の重さを4シナリオで調査し、チーム外承認必須がリードタイム・デプロイ頻度・MTTRと負の相関を示す一方、変更失敗率とは相関しないことを示す - [[@2018__Impress__LeanとDevOpsの科学 - Chapter 1 業務を加速させるということ]] — 調査設計の骨子(4年間・あらゆる規模と業種の世界中の組織)、24のキーとなるケイパビリティ(24KC)、2017年ヘッドライン数値(デプロイ頻度46倍・リードタイム1/440・MTTR 1/170・変更失敗率1/5)と2016年比の速度/安定性ギャップの動き - [[@2018__Impress__LeanとDevOpsの科学 - Introduction はじめに]] — 本調査研究の起源(2012年Puppet社の調査、2013年末の3著者合流)、標本規模(4年間累計23,000件超・2,000社超、初年度4,000件)、クロスセクション分析・スノーボールサンプリングという分析手法、年度ごとの調査推進疑問点(2014-2017年) - [[@2018__Impress__LeanとDevOpsの科学 - Appendix A 改善促進効果の高いケイパビリティ]] — 24のケイパビリティ(24KC)を継続的デリバリ・アーキテクチャ・製品とプロセス・リーン思考に基づく管理と監視・組織文化の5カテゴリーに分類し、各ケイパビリティを詳説する章(第3〜8章・第10〜11章・第13章)を対応づける一覧