mtx2s’s blog

エンジニアリングをエンジニアリングする。

AIで加速する個人、伸びないデリバリー──2025 DORAレポートが示すフローと摩擦の真実

AIツールを導入した結果、コーディングなど個人の作業スピードは上がった。けれど、チームや組織レベルのパフォーマンスはほとんど変わらない。むしろ、問題や混乱を招いている──そんな経験はないだろうか。

このギャップこそ、AI導入を進めた多くの組織が直面しているミステリーだ。

AI導入に関する2025年版のDORAレポートは、その原因が個人のスキルではなく、組織全体を動かす「システム」にあると指摘している。AIの真価を引き出せるかどうかは、ツールの性能や個人のスキル以上に、それらを組み込む組織構造やプロセスに左右される。

本稿では、ソフトウェアデリバリーにおけるAIの力を最大限に引き出すための二つの鍵、「フロー」と「摩擦」に焦点を当てる。組織の流れをどう整え、どのように摩擦を取り除くべきか。その核心を探っていこう。

🎧 本記事のAI音声解説版をポッドキャストで公開中

open.spotify.com

【ご視聴時の注意点】AI生成解説のため、内容には一部、原文から逸脱した軽微な誤りや、不自然な表現が含まれる可能性があります。大筋の理解には役立ちますが、詳細や正確な情報については、引き続き本ブログ記事をご確認ください。

主な参考文献

今回取り上げる文献は、2025年9月24日に公開された「2025 DORA State of AI-assisted Software Development Report」である。Google CloudのDORA（ドーラ）チームが、AI支援がソフトウェアデリバリーにもたらす影響を体系的に調査した最新レポートだ。

cloud.google.com

特徴的なのは、調査の焦点が「AIを導入すべきか」ではなく、「導入後に組織がどう変化したのか」に置かれている点である。約5,000名の開発実務者の回答と100時間超の定性調査から、生産性や品質、チームパフォーマンスへの影響が多面的に整理されている。

本稿では、このレポートが示す実態を入り口に、AI導入後の組織で生じている問題の構造を明らかにしていく。その第一歩となるのが、冒頭で触れた “ミステリー”──すなわち昨年の「2024 DORAアノマリー」である。

前回2024年度の調査で発覚した「DORAアノマリー」という現象

まず押さえておきたいのは、昨年の調査で発生した “異変” である。

DORAによる2024年の調査では、AIを積極的に導入した組織ほど、ソフトウェアデリバリーの「スループット（throughput）」が落ち、「不安定性（instability）」が増した*1。

AIを入れたのにパフォーマンスが悪化する──これが「2024 DORAアノマリー（異常事態）」と呼ばれる現象だ*2。本来の目的である生産性向上とは逆の結果を招いた。

なぜそんなことが起きたのか。そして、2025年度の結果はどう変化したのか──。

2025年度の調査の核心は、AIによる “増幅” とシステムによる “相乗効果”

2025年度のレポートが強調する核心は、次の2点である。

  • AIは、鏡であり力を増幅する存在（amplifier）である*3
  • システムは、その力の相乗効果を生み出す存在（force multiplier）である*4

ここで言う「システム」とは、ソフトウェアデリバリーを支える組織構造・プロセス・技術・文化といった環境全体を指す。いわゆるソフトウェアシステムのことではない。

AIは、システムの “良い部分” だけでなく “悪い部分” までも映し出し、増幅する。システムに非効率やボトルネックがあれば、その弱点もAIのスピードによって一気に表面化する。

こうした状況の中で、2024年時点では、多くの組織がAI導入を始めたばかりであり、システム側の準備が追いついていなかった。

そう、2024年のアノマリーは、この構造によって起きていたのである。

実際、2025年度の調査では、システム側をAIのスピードに適応させた組織ほどスループットが回復している*5。

この結果は、W・エドワーズ・デミングによる1993年の言葉を思い起こさせる。

悪いシステムは、良い人をいつも打ち負かす。

引用: John Hunter「A Bad System Will Beat a Good Person Every Time」The W. Edwards Deming Institute, 2015年, 記事内の文を筆者が翻訳

30年以上経ったAI時代でもなお、この原則は変わらない。AIの効果を引き出せるかどうかは、ツールや個人の能力だけでなく、それを支えるシステムの成熟度に大きく依存する。

次節では、システムの成熟度を高めるために何が必要なのか、レポートの示唆を見ていく。

AI導入による個人への効果を組織の成果に “変換” するためのシステム強化

AI導入の効果がもっとも顕著に現れるのは、「個人の生産性（individual effectiveness）」である*6。これは多くの開発者が実感しているだろう。

しかし、それで満足していては、組織パフォーマンスは向上しない。

個人レベルで増幅された効果を、チームや組織の成果へと変換するためには、システム側で相乗効果を生み出す必要がある。どれだけシステムを強化できるかが、その成否を決める。

DORAが有効性を確認した取り組みは次の2つである。

  • バリューストリームマネジメント（VSM）*7
  • プラットフォームエンジニアリング*8

「VSM」は、ソフトウェアがアイデアから顧客に届くまでのフローを可視化し、滞留たいりゅう箇所を特定・改善するための手法である。どこか一工程でもスループットが下がれば、そこがボトルネックとなり全体の性能を押し下げる。それを解消しなければ、AIがもたらした個人レベルの生産性向上も組織全体へ波及しない。

一方「プラットフォーム」は、DevOpsの観点（DORAの “D” は DevOps の “D” である）では、社内開発者向けのCI/CDやセルフサービス型インフラなどを指す*9。これらが整備されていれば、フローは速く、かつ安定する。結果として、VSMの成果にも寄与する。

いずれにせよ、焦点となるのは「フロー」である。

AI時代こそ “フロー” に注意を傾ける

VSMの実践とは、端的に言えばフローに目を向けることだ。これまでのソフトウェア開発では、人員配置や工数といった “リソース” に比べ、システム全体の “フロー” は意識されにくかった。

バリューストリームは、複数のプロセスが連なるパイプラインのように捉えると理解しやすい。その中をいくつものジョブが流れていく。このジョブの単位がフロー（フローユニット）だ。

VSMとは、この流れの中でボトルネックを特定し、取り除く実践である。これはソフトウェアシステムのパフォーマンスチューニングに近い。

バリューストリームやフローは、組織づくりを考えるうえで欠かせないテーマであり、拙著『チームの力で組織を動かす』でも基礎概念として整理している。そこで用いている説明の一部を、下記に引用する。

　たとえば、バリューストリーム内に、A, B, Cという3つのプロセスがあったとしましょう。これらのスループット上限がそれぞれ5, 3, 4である時、バリューストリーム全体のスループットは3です。Bのスループット上限である3がボトルネックになっているからです。

　ここで、Cのスループット上限を5に高めたとしても、やはりバリューストリーム全体のスループットは3のままです。Cのスループットがいくら高くても、BからCへのフローユニットの引き渡しは、Bのスループット上限である3でしか行われないからです。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 2-2-3

AI導入によって一部工程（プロセスやステージ）のスループットがいくら増幅されても、下流工程がそれを受け止められなければ、全体のスループットは変わらない。

次に、開発者にとってもっと身近な具体例を考えてみたい。

よくある例: AI導入でコーディングが速くなった代償としてコードレビューで詰まる

AIの導入によってコーディング速度が上がり、プルリクエスト数が一気に増えた──そんな経験を持つ組織は少なくないだろう。

典型的な開発プロセスを示すカンバンボードは、次の4ステージで構成される*10。

  1. To Do
  2. 進行中（設計や実装）
  3. コードレビュー
  4. 完了

「進行中」のスループットだけが上がると、「コードレビュー」に多くのチケットが滞留たいりゅうする。レビューさえ通れば、あとは自動化されたCIが流れを進めてくれるため、ボトルネックは明らかにレビュー工程にある。

つまり、この状態でのAI導入は「設計・実装」工程における “個人の生産性” を高めただけで、システム全体の流れは変わっていない。

レビュー工程に長い待ち行列ができる光景は、AI以前から珍しくない。それを放置したままAI導入を進めれば、その待ち行列は拡大するだけだ。これこそ、AIが鏡となってシステムの “悪い部分” を増幅した典型例である。

ここで多くの組織は、ボトルネックの解消に向けて対策を検討しはじめる。たとえば次のような手段だ。

  • 「WIP制限」を導入する
  • ペアプロの導入によって、レビュー自体を不要にする
  • コードレビューにもAIを活用し、負荷を軽減する
  • 一部のプルリクエストをAIレビューのみで通過させる

これらの施策でレビュー工程の詰まりが解消されれば、ボトルネックは別の場所に変わる。それをまた解消する。パフォーマンスチューニング同様、VSMもこの繰り返しである。

しかし、なぜレビュー工程は詰まるのか。たとえば開発者が期限に追われ、自分の作業を優先し、レビューを後回しにしているのかもしれない。

こうした構造的な原因を取り除かない限り、システムは本質的に強化されない。表面の問題は解消されても、流れの奥底に潜む “詰まりやすさ” は残ったままだ。

その構造的な問題こそが、次に述べる「摩擦」である。

フローを詰まらせる見えない “摩擦” の正体

フローを阻害する本質的な要因として、DORAレポートは「摩擦（friction）*11」を挙げている*12。摩擦とは、個人の作業を妨げたり、遅らせたりする要因の総称だ。これが少ないほどフローは滑らかになり、組織全体のスピードが上がる。

しかしレポートは、AI導入が「個人の生産性」や「コード品質（code quality）」を高める一方で、「摩擦」や「燃え尽き症候群（burnout）」にはほとんど影響を与えない、という興味深い結果を示した。これは “stubborn results（動かない結果）” と表現されている*13。

なぜこれらはAIでは解消されないのか。その中でもフローを直接阻害する「摩擦」による “見えにくい抵抗” に焦点を当てて考えていく。

気づかぬうちに効率を失ってしまう、現実のフローの複雑さ

現実のフローは想像以上に複雑で、さまざまな経路が絡み合う中で効率を失いやすい。その経路は、バリューストリームやカンバンボードでは捉えきれない領域や粒度にまで広がる。結果として、個々の集中力を奪い、チーム全体の流れを鈍らせてしまう。

たとえば──

  • 集中してコーディングしたいのに、頻繁にミーティングや割り込みタスクで中断される
  • ちょっとした変更でも、複数チームでの確認や誰かの承認が必要になる
  • 必要な情報がすぐに見つからない
  • ツールが使いにくい

これらはすべて、フローを阻害する摩擦である。DORAレポートが紹介する2019年のマイクロソフトの調査でも、開発者の一日を妨げる要因として同様の問題が指摘されている*14*15。

こうした摩擦による停滞は、少なからず、組織設計に起因する。組織構造に歪ひずみがあるとバリューストリームは複雑になり、フローはすぐに効率性を失う。さらにコミュニケーションの経路も入り組み、コストが増大する。

その帰結として、コンウェイの法則*16が示す通り、システム構造──すなわち内部品質──にまで悪影響が及ぶ。

とはいえ、こうした組織設計上の問題は、AI導入だけでは解決しにくい。そもそも問題の存在に気づくことすら難しい。では、どう取り組めばよいのか。

フローを詰まらせる組織設計アンチパターン

どのような設計が、組織にどのような影響を与えるのか。それがわかれば、組織設計者は現状に合わない設計を避け、より適した構造を選びやすくなる。

そこで役立つのが、組織設計に関する「アンチパターン」である。『チームの力で組織を動かす』では、16のアンチパターンを収録しており、そのうち8つはフロー（およびコミュニケーション）の効率を悪化させるパターンだ。

その簡易版としてまとめたのが、資料「内部品質・フロー効率・コミュニケーションコストを悪化させ、現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」である。

P15からP24までが、その8つのアンチパターン集となっており、下に貼り付けたスライドが、その1つめのパターン「スパゲッティ組織」だ（P17）。

mtx2s「内部品質・フロー効率・コミュニケーションコストを悪化させ現場を苦しめかねない16の組織設計アンチパターン［超簡易版］」SpeakerDeck, 2025年, P15-P24

AIによる音声解説はこちら。

open.spotify.com

こうしたアンチパターンによってプロセスが非効率化している組織は、DORAレポートの7類型のひとつである「クラスター3: プロセスに制約される（constrained by process）*17」に当てはまりやすい。

クラスター3のチームは、技術的には安定したシステム基盤を持ちながらも、煩雑はんざつなプロセスがメンバーの努力を消耗させている。その結果として、「摩擦」や「燃え尽き症候群」が生じやすくなり、ワークフローは過度に負荷の高いものとなる。いくら基盤が整っていても、その状態では顧客価値やビジネス価値を十分に高めることは難しい。

言い換えれば、組織設計上の問題が解決されない限り、技術的な安定性だけではフローは守れない、ということだ。組織構造自体が、自体が過酷で持続不可能な環境を生み出している。

DORAレポートも次のように指摘している。

Treat your AI adoption as an organizational transformation.

（AI導入を組織変革として捉えよ）

引用: 「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17（日本語訳は筆者によるもの）

AIの導入は、組織構造そのものを見直す契機と捉えるべきである。その際の設計思想として重要になるのが、次に述べる「ストリームアラインド」というアプローチだ。

“ストリームアラインド” での継続的なフロー改善

レポートでも述べられているように、VSMによるフロー改善は “単発” で終わる取り組みではない*18。

したがって、改善の主体となる組織体制も “継続的” であることが望ましい。プロジェクトごとに都度チームを組み替えるような体制では、バリューストリームが安定せず、改善した効果も蓄積されにくい。

継続的な体制を構築するうえでは、チームを「ストリームアラインド（Stream-aligned）」として編成するアプローチが有効だ。『チームの力で組織を動かす』でも、この考え方を指針として整理している。

プロジェクトに対してチームを編成するのではなく、バリューストリームに対してチームを編成します。チームをストリームに専属配備するということです。それは、開発チームであっても企画チームであっても、スクラムチームのような機能横断型のチームであっても同様です。

引用: 『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』技術評論社, 2025年, 6-1

バリューストリームに専属するチームは、メンバー構成も責務も安定し、継続的な改善に取り組むことができる。日々の業務を通して実験し、学び、適応を積み重ねることで、摩擦が削減され、フローの効率性は確実に向上する。

このようなチームを「ストリームアラインドチーム*19」と名付けた『チームトポロジー』はDevOpsを基盤としており、同じくDevOpsの体系に立脚したDORAレポートとも高い親和性がある。AI導入を組織変革として進めるのであれば、ストリームアラインド型の体制はその基盤になりうる。

摩擦を軽減する “AIケイパビリティ”

摩擦の軽減に向けては、組織設計の改善だけでなく、日々の働き方そのものを変えるアプローチも有効である。

DORAレポートでは、AI導入と組み合わせた際に摩擦の減少が確認された二つのケイパビリティが紹介されている。

  1. 明確に伝達されたAIスタンス（Clear and communicated AI stance）
  2. 小さなバッチでの作業（Working in small batches）

明確に伝達されたAIスタンス

組織がAI利用に関する明確な方針を持ち、それが現場まで徹底的に共有されている状態を指す*20。

方針が不明瞭であれば、開発者は「使ってよいのか」「どこまで任せてよいのか」といった不安を抱えやすい。こうした迷い自体が摩擦となり、AI活用の速度を落とす。

明確なスタンスは、開発者を余計な不安から解放し、“創ること” に集中できる環境を生む。その結果、「摩擦」の減少だけでなく、「個人の生産性」「スループット」「組織パフォーマンス」の向上にも寄与する。

小さなバッチサイズでの作業

短時間で完了可能な作業単位に分割し、コード変更行数を抑え、1回のデプロイに含まれる変更数を小さく保つプラクティスである*21。AI以前からDevOpsやリーンソフトウェア開発で推奨されるプラクティスでもある。

しかし、AI導入が進むと逆にバッチが肥大化しやすい。するとどうなるだろうか。

たとえばプルリクエストのサイズが大きくなれば、レビューが重くなり品質担保も難しくなる。これは典型的な摩擦の発生である。

一方で、小さなバッチは「個人の生産性」を下げる側面もある。AIは大量の変更を一気に進める場面で特に強力だが、このケイパビリティはその伸び代を意図的に抑えるからだ。

とはいえ、「個人の生産性」は手段であり目的ではない。それよりも、このケイパビリティの効果である「摩擦」の軽減と「プロダクトパフォーマンス（product performance）」の向上を増幅させたい。部分最適より全体最適だ。

最後に

ここまで見てきたように、AIの効果を最大化するために重要なのは、個人の高速化ではなく、システム全体の「フローを整え、摩擦を減らすこと」である。

AI導入によって個々のアウトプットが増えても、組織のシステムがそのスピードに対応していなければ、本来の効果は相殺されてしまう。これは、デミングが述べた原則の現代的な再確認でもある。

では、私たちはどこを測り、どう改善すべきか。

個人レベルの「活動量」だけに着目するのではなく、システムレベルの「パフォーマンス」や「効率とフロー」の観点でモニタリングし、改善を続ける必要がある*22。

DORAのクラスター分析が示す通り、スループットが高いチームは、不安定性が低いチームでもある*23。高速でありながら安定している──そこが目指すべき姿だ。

そのための重要なAIケイパビリティが「ユーザー中心主義（User-centric focus）」である*24。ユーザー価値に結びつかないアウトプットを高速に生成しても意味はない。フロー改善と価値創出は常にセットで取り組む必要がある。

本稿では、DORAレポートを軸にフローと摩擦の視点から解説した。バリューストリームやフローの改善に関心があれば、拙著『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』も手にとってみて欲しい。組織構造とフローの関係について、体系的に整理している。

gihyo.jp

*1:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P35

*2:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P9

*3:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P87

*4:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P70およびP74

*5:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P42

*6:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P38 Figure 28

*7:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P73

*8:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P65

*9:「プラットフォーム エンジニアリングとは」Google Cloud

*10:Dan Radigan「カンバン」Atlassian,, ボトルネックの減少

*11:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P37

*12:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P77の "You’re no longer just optimizing a small step; you’re removing friction from the system’s biggest constraint." など（constraintとは、TOCでは「ボトルネック」を指す）

*13:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P39

*14:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P40

*15:Meyer, André N., Earl T. Barr, Christian Bird, and Thomas Zimmermann「Today was a good day: The daily life of software developers」IEEE Transactions on Software Engineering, 2019, 47, no. 5. (2019): 863–-880

*16:Melvin E. Conway「How Do Committees Invent?」Mel Conway’s Home Page, 1968年

*17:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P17

*18:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P76

*19:マシュー・スケルトン, マニュエル・パイス 著／原田 騎郎, 永瀬 美穂, 吉羽 龍太郎 訳『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』日本能率協会マネジメントセンター, 2021年, CHAPTER5

*20:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P51-P53

*21:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P58

*22:Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler「The SPACE of Developer Productivity: There's more to it than you think.」『ACM Queue』2021年

*23:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P19 Figure 10

*24:「2025 DORA State of AI-assisted Software Development Report」DORA, 2025年, P95