AIが成果になる7条件 — DORA 2025で見直す開発組織の投資先

サマリ

AIのライセンスを配り、コードの生成量が増えても、それだけでは開発投資の成果を判断できません。変更を安全に届けられたか、顧客の困りごとが減ったかまで見る必要があります。

DORA 2025は、AIを組織の強みや弱みを増幅するものとして捉えています。本稿では、そのDORA AI Capabilities Modelが示す組織能力を「AIが成果になる7条件」として整理します。ツール代に加え、AIを使う仕事の仕組みに投資するための判断材料です。7条件は成功の保証ではありません。

データの整理：利用率と成果を分けて読む

調査対象と時点

DORAはGoogle Cloudが運営するソフトウェア開発・運用の研究プログラムです。2025年版は、世界の技術職など約5,000人への調査と質的調査を基にしています。年次報告書の調査期間は2025年6月13日〜7月21日です。

2026年9月16日にDORA公式の年次一覧を確認した範囲では、2026年版の年次調査報告は確認できませんでした。公式サイトにはAI投資回収を扱う別の報告書もありますが、本稿の数値と7条件は2025年調査に基づきます。現在の全開発者の利用率を示す数字としては扱いません。

利用していても、無条件には信頼していない

0%50%100%

• 業務でAIを利用調査回答者の割合
  90%
• AI生成コードをほとんど、または全く信頼しない生成コードへの信頼に関する回答
  30%

※出典：DORA 2025、Google Cloud公式発表。別設問の割合を並べており、差の60ポイントに意味を持たせる比較や、足して100%になる内訳ではありません。日本の開発者全体の代表値でもありません。

Google Cloudの公式発表では、生産性が向上したと考える回答は80%超でした。これは生産性が80%増えたという意味ではなく、向上を感じた回答者の割合です。会社の利益や、同じ仕事に要した実測時間の変化とも区別します。

利用と信頼は両立しない概念ではありません。たとえば、下書きに使い、内容を確かめてから採用する使い方もあります。ただし、この集計だけで回答者が具体的にどの確認工程を設けていたかは分かりません。

速さと不安定さを、同時に見る

DORA 2025の要約は、AI導入がソフトウェア提供のスループット向上と関連する一方、不安定性の増加とも関連すると報告しています。ここでいうスループットは、単純なコード行数ではありません。

指標のまとまり	DORA 2025が用いる要素	自社で確認する問い
スループット	変更のリードタイム、デプロイ頻度、失敗したデプロイからの復旧時間	変更を届けるまでの待ち時間や復旧時間はどう変わったか
不安定性	変更失敗率、デプロイの手戻り率	緊急対応や、本番障害に起因する予定外のデプロイが増えていないか

出典はDORA 2025「Understanding your software delivery performance」です。右端は私たちの確認案です。調査と統計モデルから得た関連を、御社でもAIが障害を起こすという因果関係や将来予測に読み替えることはできません。

DORAが示す7条件を、確認できる仕事にする

次の表の「組織能力」はGoogle Cloudの公式解説に沿った要約です。「自社で確認する例」はフィールフロウの提案であり、DORAの設問や効果を保証するチェックリストではありません。

組織能力	自社で確認する例
1. AIへの方針が明確で、共有されている	利用できるツール、入力できる情報、迷ったときの相談先が分かるか
2. 健全なデータ環境	仕様書や業務データが正確で、探せて、矛盾を解消できるか
3. AIが社内データにアクセスできる	必要な仕様やコードを、権限の範囲でAIに渡せるか
4. 強いバージョン管理の実践	変更を記録し、問題があれば戻せるか
5. 小さな単位で進める	レビューと検証が可能な大きさに変更を分けているか
6. 利用者を中心に考える	何を生成したかに加え、誰のどの困りごとを減らしたかを確認できるか
7. 質の高い社内プラットフォーム	テストやデプロイなどの共通作業を、開発者が安定して使えるか

各能力は同じ成果指標に一律に結び付くわけではありません。公式解説では、個人の有効性、コード品質、製品の成果、チームや組織の成果などとの関連を分けています。方針の明確さについても、特定の方針の内容が優れているかを測ったものではないと明記されています。

「データ環境を整える」と「AIがアクセスできる」も別です。社内文書が散在したまま接続を増やせば、古い情報を参照する問題が残ります。逆に、情報が整理されていても必要な文脈をAIへ渡せなければ、一般論を自社向けに直す負担が残ります。私たちは、情報の品質と接続の範囲を別々に確認することを提案します。

岡崎の分析

私たちは、AI開発投資の評価で見落としやすいのは、作成の短縮が、確認や運用の負担へ移っていないかという点だと考えています。

仮に実装が早くなっても、レビュー待ちが長くなり、顧客への提供が遅れるなら、次の投資先は生成量の拡大だけではありません。変更の分割、テストの整備、判断に必要な仕様の明確化が候補になります。これはDORAの数値から算出した効果予測ではなく、7条件を自社の工程に適用する考え方です。

経営者が確認したいのは「どのAIを契約したか」に続く問いです。何が早くなり、どこで待ち、誰が確認しているのか。その結果、顧客に届く価値と、不具合への対応負担はどう変わったのか。開発部門だけの作業量で判断せず、運用や顧客対応まで含めて確かめる必要があります。

WORKBankを扱ったレポートは、現場が任せたい業務の選び方を整理しています。本稿の7条件と合わせることで、何にAIを使うかと、それを支える仕組みを分けて検討できます。

提言 — どう付き合っていくか

1. 1対象と責任を決める改善する顧客課題、対象工程、AIへ渡す情報、人が承認する範囲を合意する。→↓
2. 2小さく変更して測る比較できる業務範囲で、所要時間、レビュー待ち、修正、顧客への影響を記録する。→↓
3. 3詰まった工程に投資するデータ、テスト、変更管理、共通基盤のどこが制約かを確かめ、対象を広げる。

✓AIの導入数だけでなく、届ける速さ、失敗と手戻り、顧客成果を一緒に見る。

AIが作った変更も、人が採用と本番反映の責任を持ちます。生成されたテストに通ることだけを合格条件にせず、利用者の要求と照らした検証、影響範囲の確認、問題が起きた場合の復旧を工程に入れてください。これは本稿の実務上の提言です。

御社でどの条件が足りているか、どの工程から測るべきか迷う場合は、フィールフロウへご相談ください。AIの選定と合わせて、仕様・データ・検証・運用までを対象に、投資先を整理します。