2025 DORA Reportから読み解く！AIが映し出す、成果を出し続ける組織の共通点 #開発生産性_findy

Findy Inc. 2025 DORA Reportから読み解く！ AIが映し出す、成果を出し続ける組織の共通点 [2025/11/26 水曜日] ファインディ株式会社
CTO室高橋裕之

※記載の商標・登録商標は各権利者に帰属します ◆ 1989年株式会社ジェーシーイ ◆ 1993年フリーランス ◆ 1995年株式会社メイテック
◆ 1996年日立通信システム株式会社（現・株式会社日立情報通信エンジニアリング） ◆ 2002年ソニーデジタルネットワークアプリケーションズ株式会社コンシューマ向けカメラ開発、組織横断型プロセス改善（SEPG）に従事 ◆ 2013年ウイングアーク１ｓｔ株式会社プロセス改善コーチ兼アジャイルコーチとして活動。2018年よりソフトウェアプロセス＆品質改善部部長、製品品質管理責任者、オープンソース管理責任者を務める。 ◆ 2021年株式会社ビズリーチプロセス改善コーチ兼アジャイルコーチとして活動。QAとプロセス改善部門のマネジャーとして、DevOpsアプローチによる開発透明性向上とDORA(Four Keys)メトリクスを用いた開発生産性による改善活動を実施。SODA（Software Outcome Delivery Architecture）構想を立案し、プロダクトの事業影響を定量化・可視化する組織変革をリード。 ◆ 2024年ファインディ株式会社ソフトウェアプロセス改善コーチ兼アジャイルコーチとして活動。エンジニア組織への新技術・方法論導入支援のイネーブルメントを担当。 1989年より組込みエンジニアとして、電話網の交換機開発携わり国産OS CTRONをスクラッチで開発。また、 BSD UNIXベースのTCP/IPプロトコル開発に従事。その後、メーカーでRTOSや組込みLinuxを基盤としたテレビ、デジタルカメラ、ビデオカメラなどの開発に16年携わる。 2005年からソフトウェア開発で起きるさまざまな問題に向き合うことを決意しSPI（ソフトウェアプロセス改善）の専門家へ転身。問題を抱える開発チームに向き合いながら、計測エビデンスをもとにしたケイパビリティモデルに基づくプロセス改善活動を得意とする。 Findy Tech Blog 編集長。高橋裕之/ Hiroyuki Takahashi ファインディ株式会社 CTO室 Staff Engineer (Engineering Excellence), SPI Coach, Agile Coach @Taka_bow takabow hiroyukitakah

イントロダクション

※記載の商標・登録商標は各権利者に帰属します 4

※記載の商標・登録商標は各権利者に帰属します LeanとDevOpsの科学: テクノロジーの戦略的活用が組織変革を加速する ⚫ この書籍がきっかけで有名になったり、その重要性が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2.
速度（スループット）と安定性はトレードオフではない 3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適用 6. Westrum（ウェストラム）の組織文化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織文化・ツールの関係 ⚫ 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 ⚫ 2018年3月出版、日本語版は2018年11月に出版。 ⚫ 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果を DORAがまとめている。 5

※記載の商標・登録商標は各権利者に帰属します 6 Four Keys（4つの主要指標） ⚫ ソフトウェアデリバリーのパフォーマンスを客観的に測定するために定義された、以下の4つの指標群です。これらは DORA（DevOps Research and
Assessment）の研究の中核であり、「DORA メトリクス」とも呼ばれます。 ⚫ DevOps の成果や組織のソフトウェアデリバリー能力を測定・比較するためのデファクトスタンダードとなりました。指標内容 Deployment frequency (デプロイ頻度) 変更を本番環境に push する頻度。 Lead time for changes (変更のリードタイム) コードの変更を commit してからデプロイするまでの時間。 Change failure rate (変更失敗率) デプロイにより障害が発生し、すぐに対処する必要が生じる頻度。 Failed deployment recovery time (失敗デプロイの復旧時間) デプロイの失敗時に復旧にかかる時間。

※記載の商標・登録商標は各権利者に帰属します DevOps指標 7 変更のリードタイムデプロイの頻度デプロイ失敗時の復旧までの時間変更時の障害率 Four Keys
DORA Model 統計的相関（参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)

※記載の商標・登録商標は各権利者に帰属します LeanとDevOpsの科学: テクノロジーの戦略的活用が組織変革を加速する ⚫ この書籍がきっかけで有名になったり、その重要性が広く認識されるようになったりした法則、概念 1. Four Keys（4つの主要指標） 2.
速度（スループット）と安定性はトレードオフではない 3. 継続的デリバリー (Continuous Delivery / CD) の効果の証明 4. 疎結合アーキテクチャの重要性 5. リーン（Lean）の原則の適用 6. Westrum（ウェストラム）の組織文化類型 7. ケイパビリティモデル (Capability Model) 8. バーンアウト（燃え尽き症候群）と組織文化・ツールの関係 ⚫ 原書タイトルは「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 ⚫ 2018年3月出版、日本語版は2018年11月に出版。 ⚫ 迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する研究結果を DORAがまとめている。 8

※記載の商標・登録商標は各権利者に帰属します「科学的リサーチ」方法とは 9 ⚫ 科学的リサーチとは、現象を体系的に調査し、新しい発見や理論を導き出す手法です。観察から始まり、概念化、測定可能な変数への置き換え、モデル化という段階を経て、客観的なデータに基づいた結論を導きます。向後, 千春. (2016). 18歳からの「大人の学び」基礎講座:
学ぶ, 書く, リサーチする, 生きる. 北大路書房. 図3-3に筆者が加筆

※記載の商標・登録商標は各権利者に帰属します【2024 DORA Report】 4つのソフトウェアデリバリーのパフォーマンスレベル ⚫ ソフトウェアデリバリーパフォーマンス 1. ソフトウェアデリバリースループット（Software
delivery throughput） 2. ソフトウェアデリバリーの不安定性（Software delivery instability） 1. ソフトウェアデリバリースループット a. 変更のリードタイム (Change lead time) b. デプロイ頻度 (Deployment frequency) c. 失敗したデプロイメントの復旧時間(Failed deployment recovery time) 2. ソフトウェアデリバリーの不安定性 a. 変更失敗率 (Change failure rate) b. リワーク率 (Rework rate) DevOpsによるソフトウェア開発の現状観察測るクラスター分析

※記載の商標・登録商標は各権利者に帰属します The state of AI in 2025 Agents, innovation, and
transformation（McKinsey） ⚫ 生成AIツールの導入が人工知能の新時代を引き起こしてから3年が経過し、調査回答者の 10人中9人近くが、自社が定期的にAIを使用していると答えている。しかし、進歩のペースは依然として不均一である。 ⚫ AIツールは今や一般的になっているものの、ほとんどの組織は、重要な企業レベルの利益を実現するために、ワークフローやプロセスに十分深く組み込んでいない。 ⚫ 最新のMcKinseyグローバル調査は、エージェント型AIの普及を含む広範な使用と、パイロットからスケールした影響への移行がほとんどの組織で進行中である頑固な成長痛の両方によって定義される状況を明らかにしている。

※記載の商標・登録商標は各権利者に帰属します

※記載の商標・登録商標は各権利者に帰属します Manufactur ing Industry in Japan The New New Product
Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999）アジャイルソフトウェア開発宣言 (2001) The Scrum Guide （2010〜） Agile DevOps (2009〜) GenAI (2021〜)

※記載の商標・登録商標は各権利者に帰属します

※記載の商標・登録商標は各権利者に帰属します 16

※記載の商標・登録商標は各権利者に帰属します DORA Metrics (Four Keys) 〜2023 19

※記載の商標・登録商標は各権利者に帰属します DORA Metrics (Four Keys) 2024〜2025 20

※記載の商標・登録商標は各権利者に帰属します【2025 DORA Report】7つのチームアーキタイプのパフォーマンスレベル 1. ソフトウェアデリバリースループット（Software delivery throughput） a.
変更のリードタイム (Change lead time) b. デプロイ頻度 (Deployment frequency) c. 失敗したデプロイメントの復旧時間 (Failed deployment recovery time) 2. ソフトウェアデリバリーの不安定性（Software delivery instability） a. 変更失敗率 (Change failure rate) b. リワーク率 (Rework rate) 3. チームパフォーマンス（Team performance） 4. プロダクトパフォーマンス（Product performance） 5. 個人の有効性（Individual effectiveness） 6. 価値ある仕事（Valuable work） 7. 摩擦（Friction） 8. 燃え尽き症候群（Burnout）クラスタ1: 基本的な課題クラスタ2: レガシーのボトルネッククラスタ3: プロセスによる制約クラスタ4: 高い影響、低いケイデンスクラスタ5: 安定して計画的クラスタ6: 実用的なパフォーマークラスタ7: 調和のとれた高パフォーマンス観察測る AI支援によるソフトウェア開発の現状 ⚫ ソフトウェアデリバリーパフォーマンス 1. ソフトウェアデリバリースループット（Software delivery throughput） 2. ソフトウェアデリバリーの不安定性（Software delivery instability） ⚫ AIの導入（AI adoption） ⚫ プロセスと実践（Processes and practices） ⚫ 個人の特性（Individual traits） ⚫ 環境および組織の特性（Environmental and organizational traits） ⚫ サービスの特性（Service traits） ⚫ 組織のパフォーマンス（Organizational performance） ⚫ チームのパフォーマンス（Team performance） ⚫ プロダクトのパフォーマンス（Product performance） ⚫ 個人の成果（Individual outcomes）クラスター分析

“State of AI-assisted Software Development” by Google LLC is licensed
under CC BY-NC-SA 4.0. DORA Report - 名称が変わった DORA Reportの名称変更 2013-2024年: 「Accelerate State of DevOps Report」 └ DevOpsの実践と成果 2025年: 「State of AI-assisted Software Development」 └ AI支援による開発の現状何が変わった？焦点が「DevOps」から「AI-assisted Development」へ調査概要調査期間: 2025年6月13日〜7月21日回答者: 約5,000人の技術専門家定性データ: 100時間超のインタビューグローバルな視点

※記載の商標・登録商標は各権利者に帰属しますジーン・キムが帰ってきた（コラムで） 2010年代中盤、DevOpsムーブメントの中心人物として台頭したのがジーン・キム（Gene Kim）です。それまで現場レベルの実践知として広がっていた DevOpsの考え方を、組織全体で取り組むべき体系的な方法論として確立した功績は計り知れません。彼の著作は技術書の枠を超え、多くの組織でDevOps変革の指南書となっています。
Gene Kim 氏（開発生産性Conference 2025） 23

under CC BY-NC-SA 4.0. 24 今日のアジェンダ本日の流れ：AIという「鏡」が映し出す、成果を出し続ける組織の姿 1️⃣ AIは「増幅器」 → 良いことも悪いことも拡大する 2️⃣ 7つのチームプロファイル → どんな組織が存在するか？ 3️⃣ AIの導入と利用状況 → 90%が使用、1日2時間 4️⃣ DORA AI機能モデル → AIの効果を最大化する7つの組織能力 5️⃣ DORAからの提言 → テクノロジーリーダーへの5つのアドバイス

重要なポイント - AIは増幅器 25

under CC BY-NC-SA 4.0. 26 AIの影響の全体像個人の有効性ソフトウェアデリバリーの不安定（）組織パフォーマンス価値ある仕事への時間配分コード品質プロダクトパフォーマンスソフトウェアデリバリーのスループットチームパフォーマンス燃え尽き（）開発の摩擦（）

under CC BY-NC-SA 4.0. 27 AIは「増幅器」（amplifier）レポートのキーメッセージ（p.4） "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones." AIの主な役割は増幅器である。高パフォーマンス組織の強みを拡大し、苦戦する組織の機能不全も拡大する成果を出し続ける組織優れた基盤 → AI → さらなる成果苦戦する組織問題のある基盤 → AI → 問題の拡大

under CC BY-NC-SA 4.0. 28 成功のカギは「組織の仕組み」「AIの導入の成功は、ツールの問題ではなくシステムの問題」 "Successful AI adoption is a systems problem, not a tools problem" ここで言う「システム」= ITシステムではないつまり「組織の仕組み」のこと ├ 内部プラットフォームの品質 │ （CI/CD、インフラ自動化、監視基盤など開発チームが共通で使う社内開発基盤） ├ ワークフローの明確さ └ チームの連携これらが整っていないと... AIは「局所的な生産性のポケット」を作るだけその成果は「下流の混乱」の中で失われる

主な調査結果

under CC BY-NC-SA 4.0. AI導入状況 ⚫ DORA 2024調査: 81%が組織レベルでAI導入を優先（コード作成では74.9%が使用） ⚫ DORA 2025調査: 90%が使用

under CC BY-NC-SA 4.0. 31 7つのチームプロファイル概要 DORAが発見した7つのチームタイプ苦戦している組織（38%） ├ Cluster 1: 基本的な課題（10%） ├ Cluster 2: レガシーのボトルネック（11%） └ Cluster 3: プロセスによる制約（17%）中間層（22%） ├ Cluster 4: 高い影響、低いケイデンス（7%） └ Cluster 5: 安定して計画的（15%）成果を出し続ける組織（40%） ├ Cluster 6: 実用的なパフォーマー（20%） └ Cluster 7: 調和のとれた高パフォーマンス（20%）

under CC BY-NC-SA 4.0. 32 2024年からの変化 - 改善と課題 2024年 → 2025年の変化【改善】 Software delivery throughput: +0.06 （ソフトウェアデリバリースループット） └ 昨年はマイナスだったが、プラスに転じた！【依然として課題】 Software delivery instability: +0.10 （ソフトウェアデリバリーの不安定性） └ 不安定性は依然として増加解釈: チームはスピードへの適応は進んでいるが、組織の仕組みが追いついていない

under CC BY-NC-SA 4.0. 33 DORA AI機能(ケイパビリティ)モデル概要

under CC BY-NC-SA 4.0. 34 プラットフォームエンジニアリングプラットフォームエンジニアリング 90%の組織が採用（ほぼ普遍的）高品質なプラットフォームがAIの価値を引き出す └ プラットフォーム品質 × AI → 組織パフォーマンス向上

under CC BY-NC-SA 4.0. 35 バリューストリームマネジメント ⚫ レポートではバリューストリームマネジメント（VSM）がAIの効果を高める手法として紹介されています ⚫ VSMはアイデアから顧客までの作業の流れを可視化・分析する手法です。この図はその例を示しています

※記載の商標・登録商標は各権利者に帰属します ECRS（イクルス）の原則 36 A C A A B1 C B2
A B C C A B1 B2 Before After Eliminate（排除） Combine（結合） Rearrange（入れ替え） Simplify（簡素化）

7つのチームプロファイル

under CC BY-NC-SA 4.0. プロファイル分析の背景クラスタ分析に使用した8つの測定要因（共通のパターン）【増やしたい指標】 Team performance（チームパフォーマンス）この要因は、ユーザーが重要なタスクを達成するのを支援し、情報を安全に保つなどの特性、およびレイテンシーなどのパフォーマンス指標に基づいて、チームが構築しているプロダクトまたはサービスの成功と品質を測定します。 Product performance（プロダクトパフォーマンス）この要因は、個人の直属のチームの認識された有効性と協力的な強さを測定します。 Software delivery throughput（デリバリースループット）これは、ソフトウェアデリバリープロセスの速度と効率を表します。 Individual effectiveness（個人の有効性）これは、ソフトウェアデリバリープロセスの品質と信頼性を捉えます。 Valuable work（価値ある仕事）この要因は、個人の自己評価による有効性と仕事での達成感を捉えます。【減らしたい指標】 Software delivery instability（デリバリーの不安定性）これは、個人が価値があり、価値があると感じる仕事をすることに費やす時間の自己評価量を測定します。 Friction（摩擦）これは、摩擦が個人の仕事を妨げる程度を測定します。摩擦の量が少ないことは、一般的にプラスの成果と見なされます。 Burnout（燃え尽き症候群）これは、自分の仕事に関連する疲労感とシニシズムの感情を測定します。燃え尽き症候群の量が少ないことは、一般的にプラスの成果と見なされます。

under CC BY-NC-SA 4.0. 39 7つのプロファイル全体像

※記載の商標・登録商標は各権利者に帰属します 40 7つのチームプロファイル概要 DORAが発見した7つのチームタイプ苦戦している組織（38%） ├ Cluster 1: 基本的な課題（10%） ├
Cluster 2: レガシーのボトルネック（11%） └ Cluster 3: プロセスによる制約（17%）中間層（22%） ├ Cluster 4: 高い影響、低いケイデンス（7%） └ Cluster 5: 安定して計画的（15%）成果を出し続ける組織（40%） ├ Cluster 6: 実用的なパフォーマー（20%） └ Cluster 7: 調和のとれた高パフォーマンス（20%）

under CC BY-NC-SA 4.0. 41 Cluster 1 - 基本的な課題（10%） ⚫ これらのチームはサバイバルモードに陥っており、プロセス、環境、成果における基本的なギャップによって重大な課題に直面しています。 ⚫ 回答者の割合: アンケート回答者の 10%がクラスタ1に属しています。 ⚫ パフォーマンス指標: チームアウトプット、プロダクトデリバリー、価値創出に関連する主要なパフォーマンス指標は一貫して低いです。 ⚫ チームのウェルビーイング: データは、高レベルの燃え尽き症候群と重大な摩擦が報告されていることを示しています。 ⚫ システムの安定性: ソフトウェアおよび運用環境の安定性に関して注目すべき課題があります。

under CC BY-NC-SA 4.0. 42 Cluster 2 - レガシーのボトルネック（11%） ⚫ このクラスタのチームは、不安定なシステムが彼らの仕事を決定し、士気を損なう、絶え間ない反応の状態にあります。 ⚫ 回答者の割合: アンケート回答者の 11%がクラスタ2に属しています。 ⚫ パフォーマンス指標: プロダクトパフォーマンスの主要な指標は低いです。チームは定期的なアップデートを提供していますが、実現される価値は継続的な品質の問題によって減少しています。 ⚫ チームのウェルビーイング: データは、厳しい作業環境を示しています。チームメンバーは、摩擦と燃え尽き症候群のレベルの上昇を報告しています。 ⚫ システムの安定性: ソフトウェアとその運用環境の安定性に関して重大かつ頻繁な課題があり、大量の計画外の反応的な作業につながっています。

under CC BY-NC-SA 4.0. 43 Cluster 3 - プロセスによる制約（17%） ⚫ これらのチームはトレッドミルの上を走っています。安定したシステムで作業しているにもかかわらず、彼らの努力は非効率的なプロセスによって消費され、高い燃え尽き症候群と低い影響につながっています。 ⚫ 回答者の割合: アンケート回答者の 17%がクラスタ3に属しています。 ⚫ パフォーマンス指標: 主要なパフォーマンス指標は、低い有効性と限られた顧客またはビジネス価値の創出を示しています。 ⚫ チームのウェルビーイング: データは、燃え尽き症候群と摩擦の両方の高レベルが報告されていることを示しています。これは、現在のワークフローとプロセスがチームにとって困難で持続不可能な作業環境を作り出していることを示唆しています。 ⚫ システムの安定性: チームのソフトウェアおよび運用環境は安定していて信頼性があります。これは、技術的な不安定性がパフォーマンスとウェルビーイングの課題の主な原因ではないことを示しています。

under CC BY-NC-SA 4.0. 44 Cluster 4 - 高い影響、低いケイデンス（7%） ⚫ これらのチームは、プロダクトパフォーマンスと高い個人の有効性の高さに反映された、影響力の高い仕事を生み出します。しかし、これは、低いソフトウェアデリバリースループットと高い不安定性を特徴とする低いケイデンスのデリバリーモデルと組み合わされています。 ⚫ 回答者の割合: アンケート回答者の 7%がクラスタ4に属しています。 ⚫ パフォーマンス指標: チームは一貫してトップレベルの生産性を達成しています。有効性とプロダクトパフォーマンス指標の両方が強いです。 ⚫ チームのウェルビーイング: データは、低摩擦環境を示しており、チームのプロセスが効率的で協力的であることを示唆しています。 ⚫ システムの安定性: 運用環境は、高度な不安定性を特徴としています。このレベルの変動性は、サービスの信頼性と長期的な持続可能性に対する重大なリスクを表しています。

under CC BY-NC-SA 4.0. 45 Cluster 5 - 安定して計画的（15%） ⚫ これらのチームは、ソフトウェアの世界の着実な職人であり、慎重で持続可能なペースで高品質で価値のある仕事を提供しています。 ⚫ 回答者の割合: アンケート回答者の 15%がクラスタ5に属しています。 ⚫ パフォーマンス指標: プロダクトの品質と価値創出の主要なパフォーマンス指標は一貫してプラスです。ただし、チームのソフトウェアデリバリースループットは低いパーセンタイルにあり、より慎重な作業ペースを示しています。 ⚫ チームのウェルビーイング: データは、燃え尽き症候群と摩擦の低レベルが報告されていることを示しており、健全で持続可能なチーム環境を指しています。 ⚫ システムの安定性: チームのソフトウェアおよび運用環境は、高い安定性と信頼性を特徴としています。

under CC BY-NC-SA 4.0. 46 Cluster 6 - 実用的なパフォーマー（20%） ⚫ これらのチームは、作業環境がピークのエンゲージメントの状態に達していない場合でも、印象的なスピードと安定性で一貫して仕事を提供します。 ⚫ 回答者の割合: アンケート回答者の 20%がクラスタ6に属しています。 ⚫ パフォーマンス指標: ソフトウェアデリバリーの主要なパフォーマンス指標は強く、平均以上のスループットと低い不安定性を示しています。チームは、価値あるアウトプットの安定したケイデンスを維持し、期待に確実に応えています。 ⚫ チームのウェルビーイング: このクラスタが絶対的なトップティアとは異なるのは、チームのウェルビーイングの測定です。データは、燃え尽き症候群と摩擦の平均レベルが報告されていることを示しています。これは、機能的で持続可能な作業環境を示していますが、強力なエンゲージメントドライバーが欠けている可能性があります。 ⚫ システムの安定性: チームのソフトウェアおよび運用環境は安定し

under CC BY-NC-SA 4.0. 47 Cluster 7 - 調和のとれた高パフォーマンス（20%） ⚫ これが卓越性の姿です。安定した低摩擦の環境がチームに高品質の仕事を持続可能に、燃え尽きることなく提供する力を与える好循環です。 ⚫ 回答者の割合: アンケート回答者の 20%がクラスタ7に属しています。 ⚫ チームのウェルビーイング: 作業環境は、燃え尽き症候群と摩擦の低レベルが報告されていることを特徴としています。 ⚫ パフォーマンス指標: チームは、チームのウェルビーイング、プロダクトの成果、ソフトウェアデリバリーを含む複数の領域でプラスの指標を示しています。 ⚫ システムの安定性: チームは、仕事のスピードと品質の両方をサポートする安定した技術的基盤で運用されています。

under CC BY-NC-SA 4.0. 48 成果を出し続ける組織の共通点① 成果を出し続ける組織（Cluster 6, 7）の特徴: 1️⃣ スピードと安定性の両立 └ トレードオフではない 2️⃣ 低い摩擦と燃え尽き └ 持続可能な働き方 3️⃣ 高いチーム・プロダクトパフォーマンス └ 全体最適の実現調査が示すこと: これらの特徴は、次に説明する 7つの組織能力と強く相関している

※記載の商標・登録商標は各権利者に帰属します継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション技術的発展の階層構造 49
DevOps文化

※記載の商標・登録商標は各権利者に帰属します技術的発展の階層構造 ⚫ foundation 1: WFのリスク軽減手法（1990年代〜） ⚫ インクリメンタル、スパイラル、RUP ⚫ 継続的インテグレーション(CI)
⚫ 短いイテレーション、継続的フィードバック 50 継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション１ DevOps文化

※記載の商標・登録商標は各権利者に帰属します技術的発展の階層構造 ⚫ foundation 2: アジャイル（2000年代〜） ⚫ クリスタル、Extreme Programming、Scrum ⚫
アジャイルソフトウェア開発宣言（Agile Manifesto） ⚫ foundation 1: WFのリスク軽減手法（1990年代〜） ⚫ インクリメンタル、スパイラル、RUP ⚫ 継続的インテグレーション(CI) ⚫ 短いイテレーション、継続的フィードバック 51 継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション１ 2 DevOps文化

※記載の商標・登録商標は各権利者に帰属します技術的発展の階層構造 ⚫ foundation 3: DevOps文化（2010年代〜） ⚫ アジャイルを土台に、開発(Dev)と運用(Ops)の協力 ⚫ 自動化を中心とした継続的デリバリー(CD)
⚫ フロー、フィードバック、継続的学習と実験 ⚫ foundation 2: アジャイル（2000年代〜） ⚫ クリスタル、Extreme Programming、Scrum ⚫ アジャイルソフトウェア開発宣言（Agile Manifesto） ⚫ foundation 1: WFのリスク軽減手法（1990年代〜） ⚫ インクリメンタル、スパイラル、RUP ⚫ 継続的インテグレーション(CI) ⚫ 短いイテレーション、継続的フィードバック 52 継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション１ 2 3 DevOps文化

※記載の商標・登録商標は各権利者に帰属します継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション技術的発展の階層構造 ⚫
foundation 4: AI駆動開発（2020年代〜） ⚫ 人間とAIの協働で、ソフトウェアを効率的に創る ⚫ DevOpsの土台があって初めて効果を発揮 ⚫ foundation 3: DevOps文化（2010年代〜） ⚫ アジャイルを土台に、開発(Dev)と運用(Ops)の協力 ⚫ 自動化を中心とした継続的デリバリー(CD) ⚫ フロー、フィードバック、継続的学習と実験 ⚫ foundation 2: アジャイル（2000年代〜） ⚫ クリスタル、Extreme Programming、Scrum ⚫ アジャイルソフトウェア開発宣言（Agile Manifesto） ⚫ foundation 1: WFのリスク軽減手法（1990年代〜） ⚫ インクリメンタル、スパイラル、RUP ⚫ 継続的インテグレーション(CI) ⚫ 短いイテレーション、継続的フィードバック１ 2 3 4 53 DevOps文化

※記載の商標・登録商標は各権利者に帰属します継続的フィードバック継続的インテグレーション自動化継続的デリバリー AI駆動開発アジャイル短いイテレーション技術的発展の階層構造 ⚫
foundation 4: AI駆動開発（2020年代〜） ⚫ 人間とAIの協働で、ソフトウェアを効率的に創る ⚫ DevOpsの土台があって初めて効果を発揮 ⚫ foundation 3: DevOps文化（2010年代〜） ⚫ アジャイルを土台に、開発(Dev)と運用(Ops)の協力 ⚫ 自動化を中心とした継続的デリバリー(CD) ⚫ フロー、フィードバック、継続的学習と実験 ⚫ foundation 2: アジャイル（2000年代〜） ⚫ クリスタル、Extreme Programming、Scrum ⚫ アジャイルソフトウェア開発宣言（Agile Manifesto） ⚫ foundation 1: WFのリスク軽減手法（1990年代〜） ⚫ インクリメンタル、スパイラル、RUP ⚫ 継続的インテグレーション(CI) ⚫ 短いイテレーション、継続的フィードバック１ 2 3 4 54 DevOps文化技術というより、文化や作法これらは積み重ね一足飛びには手に入らない

※記載の商標・登録商標は各権利者に帰属します Manufactur ing Industry in Japan The New New Product
Developm ent Game (1986) SCRUM Development Process （1995） XP Explained : Embrace Change （1999）アジャイルソフトウェア開発宣言 (2001) The Scrum Guide （2010〜） Agile DevOps (2009〜) GenAI (2021〜)

※記載の商標・登録商標は各権利者に帰属します GenAI Waterfall（1976〜）

※記載の商標・登録商標は各権利者に帰属しますウォーターフォール考える人vsつくる人（多重下請け構造）

※記載の商標・登録商標は各権利者に帰属しますウォーターフォール考える人vsつくる人（多重下請け構造）継続的フィードバック継続的インテグレーション自動化 DevOps文化継続的デリバリー AI駆動開発
アジャイル短いイテレーション

AIの導入と利用状況

under CC BY-NC-SA 4.0. AI導入の数字

under CC BY-NC-SA 4.0. 61 タスク別AI利用率 ⚫ 今年の DORAレポートと同様に、今年のアンケート回答者の間で AIツールの第 1 位の使用は新しいコードを書くことであり、コードを書く回答者の 71%が AIを使用してそれを支援しています。 ⚫ 大多数の回答者は、文献レビュー(68%)、既存のコードの変更(66%)、校正(66%)、画像の作成または編集 (66%)にも AIを使用しています。 ⚫ 回答者の仕事がそれらの責任を含む場合、AIの使用がそれほど一般的ではないものには、要件の分析(49%)、内部コミュニケーション(48%)、カレンダー管理(25%)が含まれます。

under CC BY-NC-SA 4.0. 62 インタラクション形態 ⚫ 会話型AIチャットボットは、AIとインタラクションするための最も一般的な手段であり、その次に IDE 内に埋め込まれた AIが続きます。 ⚫ 回答者は、自動化されたツールチェーンや他の開発ツールおよびプラットフォームの一部として AIとあまり頻繁にインタラクションしていないと報告していますが、これはそれらの AIツールがユーザーにとってあまり見えないことの特徴である可能性があります。 ⚫ 最も頻繁に使われているのは「予測テキスト（コード補完）」と「チャットベース支援」。どちらも「1日数回」利用するユーザーが20〜25%にのぼります。 ⚫ 一方、「協働モード」や「エージェントモード」のような高度なAI活用形態は、まだ多くのユーザーが「使っていない（Never）」と回答（38〜61%）。

under CC BY-NC-SA 4.0. 63 生産性とコード品質への影響 ⚫ 個人の生産性：今年のアンケート回答者の 80% 以上が、AIが生産性を向上させたという認識を報告しています。40% 以上が生産性が「わずかに」しか向上していないと報告していますが、回答者の 10% 未満が、AIが生産性の低下に寄与していると認識しています。 ⚫ コード品質：生産性へのプラスの影響を認識することに加えて、アンケート回答者の大多数(59%)も、AIがコード品質にプラスの影響を与えたことを観察しています。31%はこの増加が「わずか」であると認識しており、さらに 30%はプラスでもマイナスでもない影響を観察しています。しかし、AIの使用の結果としてコード品質にマイナスの影響を認識しているのは、回答者のわずか10%です。

under CC BY-NC-SA 4.0. 64 信頼のパラドックス ⚫ 2024年 DORAレポートと同様に、今年の調査結果は、AIが生成した出力に対するユーザーの信頼の微妙な状況を明らかにしており、回答者の明確な大多数(70%)が、その品質に対してある程度の信頼を表明しています。これには、「非常に多い」または「多い」信頼を持っていると報告している回答者のほぼ 4分の 1(24%)が含まれます。アンケート対象者の 30% は、より慎重な姿勢を示しており、AIが生成した出力の品質に「少し」(23%)または「まったく信頼していない」(7%)と報告しています。 ⚫ このデータは重要な洞察を強調しています: AIの高レベルの導入と認識されたメリットは、信頼に対する測定された微妙なアプローチと共存できます。私たちの調査結果は、絶対的な信頼が AIが生成した出力が有用であるための前提条件ではないことを示唆しています。このパターンは、確立された行動と一致しています。インタビュー中、開発者はこれを、Stack Overflow で見つかるソリューションなど、他の広く使用されているリソースに適用する健全な懐疑的見方と比較しました。そこでは、情報は使用されますが、必ずしも暗黙的に信頼されるわけではありません。

under CC BY-NC-SA 4.0. 65 事例 - Sabre社事例: Sabre社（旅行テクノロジー企業）導入状況: ├ 74%の開発者がGitHub Copilotを採用 ├ 86%が生産性向上を実感 └ しかし新機能の利用は25%のみ学び: 「導入」と「効果的な使用」は別物 └ トレーニング強化が効果を最大化する鍵成功のポイント: ├ 機能認知のためのトレーニング ├ ベストプラクティスの共有 └ 継続的なスキルアップ支援

DORA AI機能(ケーパビリティ)モデル

under CC BY-NC-SA 4.0. 67 DORA AI機能(ケーパビリティ)モデル全体像 DORA AI機能モデル - 7つの能力 AIの効果を最大化する7つの組織能力: 1. 明確で周知されたAIスタンス (Clear and communicated AI stance) 2. 健全なデータエコシステム (Healthy data ecosystems) 3. 小さなバッチでの作業 (Working in small batches) 4. ユーザー中心的な重点 (User-centric focus) 5. AI-アクセシブルな内部データ (AI-accessible internal data) 6. 高品質な内部プラットフォーム (Quality internal platforms) 7. 強力なバージョン管理プラクティス (Strong version control practices) ポイント: 「AIの導入の成功は、ツールの問題ではなくシステムの問題」

under CC BY-NC-SA 4.0. DORA AI機能(ケーパビリティ)モデル全体像

under CC BY-NC-SA 4.0. 69 能力① - 明確で周知されたAIスタンス (Clear and communicated AI stance) 明確で周知されたAIスタンスとは（4つの指標で測定） 1. AI使用への期待感 - 職場でAIを使用することが期待されていると感じるか 2. 実験の支援 - 組織がAIの試行・実験をどの程度支援しているか 3. 許可ツールの明確さ - どのAIツールが使用許可されているか明確か 4. ポリシーの適用 - 組織のAIポリシーが自分に直接適用されていると感じるか ※「AIポリシー」は4番目の一部にすぎない。「AIスタンス」= ポリシー＋期待感＋支援体制＋明確さ効果（高い確度）個人の有効性への好影響が増幅（大きな向上まで到達）組織パフォーマンスへの好影響が増幅摩擦が減少スループットへの好影響が増幅

under CC BY-NC-SA 4.0. 70 能力② - 健全なデータエコシステム (Healthy data ecosystems) 健全なデータエコシステムとは（3つの指標で測定） 1. 社内データソースの全体的な品質 2. 社内データソースへのアクセス性 3. 社内データソースが互いにどの程度分断・サイロ化していないか ※つまり「社内データが高品質で、容易にアクセスでき、統合されている環境」効果（高い確度）組織パフォーマンスへの好影響が増幅（大きな向上まで到達）

under CC BY-NC-SA 4.0. 71 能力③ - 小さなバッチでの作業 (Working in small batches) 小さなバッチでの作業とは（3つの指標で測定）: 1. 直近の変更でコミットしたコードの行数 2. 1回のリリース/デプロイにまとめられる変更の数 3. 1つのタスクを完了するまでに必要な時間 ※スコアが高いチーム = コミット行数が少なく、リリースあたりの変更が少なく、短時間で完了できる作業単位効果（高い確度）: - プロダクトパフォーマンスへの好影響が増幅 - 摩擦が減少（中立→好転） - 個人の有効性への効果はやや低下なぜ個人の有効性が下がるのか: AIは主に「大量のコードを素早く生成する」ことで個人の効果を高める。小さなバッチを重視するチームでは、そもそも大量のコード生成を目指していないため、効果が小さく見える。レポートの結論: 「個人の業務効果そのものを目的として追求するべきではない。それは組織・チーム・プロダクトのパフォーマンス向上を実現するための手段にすぎない」

under CC BY-NC-SA 4.0. 72 能力④ - ユーザー中心的な重点 (User-centric focus) ユーザー中心的な重点とは（3つの指標で測定）: 1. ユーザーに価値を提供することが自分たちの焦点である 2. ユーザー体験が最優先事項である 3. ユーザーに焦点を当てることがビジネス成功の鍵である ※つまり「ユーザー体験を優先し、それがビジネス成果と結びついていると理解しているチーム」効果（高い確度）- 最も劇的な結果: ユーザー中心のチーム → AIのチームパフォーマンスへの好影響が増幅ユーザー中心でないチーム → AI導入でパフォーマンスが低下（悪影響）重要な警告: 「ユーザー中心のフォーカスが欠けている場合、AI導入はチームのパフォーマンスを損なう可能性があります」なぜユーザー中心が重要か: ユーザー中心のフォーカスは、チームが目標を明確にし、ユーザー体験を「北極星」として共有戦略に向かう助けになる。 AIは方向性を示してくれない。方向性がないままAIで加速すると、間違った方向に速く進むだけ。

under CC BY-NC-SA 4.0. 73 能力⑤ - AI-アクセシブルな内部データ (AI-accessible internal data) AIがアクセス可能な内部データとは（4つの指標で測定） 1. AIツールが社内情報にアクセスできている 2. AIの回答に社内情報が反映されている 3. 社内情報をAIに入力している 4. AIを使って社内情報を検索・取得している ※つまり「AIが社内データにアクセスでき、それを活用している状態」効果（高い確度）個人の有効性への好影響が増幅コード品質への好影響が増幅

under CC BY-NC-SA 4.0. 74 能力⑥ - 高品質な内部プラットフォーム (Quality internal platforms) 高品質な内部プラットフォームとは: 組織内の複数のアプリケーションやサービスで共有され、それらの機能を組織全体に広く提供するための能力群。品質は12 の特性の有無で測定。（※90%の組織がプラットフォームエンジニアリングを採用）効果（高い確度）- トレードオフあり組織パフォーマンスへの好影響が増幅摩擦（Friction）がやや増加なぜ摩擦が増えるのか高品質なプラットフォームは2つの役割を果たす： 1. 必要な能力へのアクセスを広げる 2. 不適切な能力へのアクセスを制限する AI支援開発のベストプラクティスがまだ確立されていない現状では、プラットフォームは「不適切な利用の防止」として作用 → これが摩擦の原因。ただし、組織にとっては必ずしも悪いことではない。レポートの結論: 「品質の高い内部プラットフォームを設計し維持することは、AI支援環境で成功裏にソフトウェアを開発するための重要な能力である」

under CC BY-NC-SA 4.0. 75 能力⑦ - 強力なバージョン管理プラクティス (Strong version control practices) 強固なバージョン管理プラクティスとは • 頻繁なコミット • ロールバック（変更を元に戻す）機能の活用なぜAI時代に重要か生成AIによりコード生成の量とスピードが劇的に増加。バージョン管理の重要性はさらに高まっている。効果（高い確度）コミット頻度が高い → AIの個人への好影響が増幅ロールバック利用頻度が高い → AIのチームパフォーマンスへの好影響が増幅「心理的セーフティネット」としてのバージョン管理何か問題が起きても安定した状態に戻せる安心感があるからこそ、チームは自信を持って実験・革新できる

under CC BY-NC-SA 4.0. 76 DORA AI機能(ケーパビリティ)モデル（まとめ）レポートp.79の章タイトル "The AI mirror: How AI reflects and amplifies your organization's true capabilities" 「AIの鏡: AIが組織の真の能力をどのように反映し増幅するか」 AIは増幅器であり、鏡でもある └ 組織の真の能力を映し出し、拡大する成果を出し続ける組織の共通点（7つの能力） 1. 明確で周知されたAIスタンス (Clear and communicated AI stance) 2. 健全なデータエコシステム (Healthy data ecosystems) 3. 小さなバッチでの作業 (Working in small batches) 4. ユーザー中心的な重点 (User-centric focus) 5. AI-アクセシブルな内部データ (AI-accessible internal data) 6. 高品質な内部プラットフォーム (Quality internal platforms) 7. 強力なバージョン管理プラクティス (Strong version control practices)

DORAからの提言

under CC BY-NC-SA 4.0. 5つの提言（概要） DORAからの5つの提言 "Analysis and advice for technology leaders" 1️⃣ AIの導入の成功は、ツールの問題ではなくシステムの問題 (Successful AI adoption is a systems problem, not a tools problem) 2️⃣ 健全な懐疑的見方を伴う広範なAIの導入 (Broad AI adoption with healthy skepticism) 3️⃣ 7つのチームパフォーマンスプロファイル (Seven profiles of team performance) 4️⃣ 高品質なプラットフォームがAIの価値を引き出す (Quality platforms unlock AI's value) 5️⃣ システム的視点がAIの可能性を方向付ける (A systems view directs AI's potential)

under CC BY-NC-SA 4.0. 79 提言① - AIの導入の成功は、ツールの問題ではなくシステムの問題 DORA AI Capabilities Modelが明らかにしたこと「AIの価値は、ツールそのものではなく、周囲の技術的・文化的環境によって引き出される」最大の成果を生む投資先 1. 内部プラットフォーム 2. データエコシステム 3. チームの中核的なエンジニアリング規律 AIツールを導入するだけ AIの導入を「組織変革」として扱う └ AIの可能性を測定可能な組織パフォーマンスに変える

under CC BY-NC-SA 4.0. 80 提言② - 健全な懐疑的見方を伴う広範なAIの導入現状 ├ ほとんどの開発者がAIで生産性向上を実感 └ しかし出力品質には健全な懐疑的見方がある「信頼するが検証する」= 成熟した導入の兆候 └ 70%が「ある程度信頼」（完全信頼は少数派）会話を「導入」から「効果的な使用」へ移すトレーニングの焦点を変える AIの使用を奨励する AIが生成した作業を批判的にガイド・評価・検証する方法を教える

under CC BY-NC-SA 4.0. 81 提言③ - 7つのチームパフォーマンスプロファイル単純な指標だけでは不十分「パフォーマンス、安定性、ウェルビーイングの独自の組み合わせを持つ7つのプロファイルを特定」単純な指標だけでは見えないこと ├ 高パフォーマンスだが燃え尽きている ├ 安定しているがレガシーに縛られている └ 速いがデリバリーが不安定アクションソフトウェアデリバリー指標を超えてチームの健全性を診断チームの特定の課題に合わせた介入を適用改善のためのカスタマイズされた経路を作成

under CC BY-NC-SA 4.0. 82 提言④ - 高品質なプラットフォームがAIの価値を引き出す現状 ├ プラットフォームエンジニアリングは90%が採用（ほぼ普遍的） └ 高品質なプラットフォームとAI価値の引き出しに直接相関成功する組織の特徴「プラットフォームを、開発者体験を向上させるための内部プロダクトとして扱う」アクションプラットフォームエンジニアリングへの投資を優先・資金提供低い開発者体験と断片化したツール └ AI戦略の効果を阻害する

under CC BY-NC-SA 4.0. 83 提言⑤ - システム的視点がAIの可能性を方向付ける今年の調査で確認されたこと: 「VSM（バリューストリームマネジメント）は焦点を絞った改善を生み出し、チームとプロダクトのパフォーマンスを向上させる」 VSMはAI投資の「力の増幅器」として機能: ├ システムレベルの視点を提供 ├ AIを正しい問題に適用することを保証 └ 局所的な生産性向上を組織的な優位性に変換局所的な生産性向上 → 下流の混乱を増やすだけ全体の流れを最適化 → 組織的な優位性へ

まとめ

under CC BY-NC-SA 4.0. まとめ - AIが映し出したもの今日お伝えしたこと 1️⃣ AIは鏡であり増幅器 └ 組織の真の姿を映し、拡大する 2️⃣ 成果を出し続ける組織は40%存在 └ 卓越性は達成可能 3️⃣ 7つの共通する組織能力 └ ツールではなくシステムが鍵 4️⃣ 各組織に適した改善経路がある └ 現在地を知り、段階的に進む 5️⃣ 健全な懐疑主義を持つ └ 信頼するが検証する "The greatest returns will come from investing in the foundational systems" 最大の成果は、基盤となるシステムへの投資から生まれる p.5

under CC BY-NC-SA 4.0. 86 DORAからの5つのアクション 1️⃣ AIの導入を「組織変革」として扱う └ 内部プラットフォーム、データエコシステム、エンジニアリング規律に投資 2️⃣ 「導入」から「効果的な使用」へ会話を移す └ AIが生成した作業を批判的にガイド・評価・検証する方法を教える 3️⃣ 7つのプロファイルでチームの健全性を診断する └ ソフトウェアデリバリー指標だけでなく、ウェルビーイングも評価 4️⃣ プラットフォームエンジニアリングへの投資を優先・資金提供する └ 開発者体験を向上させる内部プロダクトとして扱う 5️⃣ VSMでシステム全体を見る └ 局所最適ではなく、全体最適を目指す

2025 DORA Reportから読み解く！AIが映し出す、成果を出し続ける組織の共通点 #...

2025 DORA Reportから読み解く！AIが映し出す、成果を出し続ける組織の共通点 #開発生産性_findy

More Decks by Hiroyuki TAKAHASHI

Other Decks in Technology

Featured

Transcript