システム開発を外部に委託する際、「今回はウォーターフォールか、アジャイルか」という議論は今も多くの現場で繰り返されています。ただ、生成AIがコードを書くようになった現在、この問いの立て方そのものを見直す時期に来ています。
本記事は、開発案件の発注を担当する方、情報システム部門の方を主な読者として想定しています。公開データと研究をもとに、次の3点を整理します。
- 「アジャイルは成功率が3倍」という数字は何を測っているのか
- 請負・準委任という契約形態が、選べる開発手法をどう左右するのか
- AIの普及によって、各手法の前提がどう変わるのか
「成功率3倍」の数字をどう読むか
アジャイルの優位性を示す根拠として、Standish GroupのCHAOSレポートがよく引用されます。成功率はアジャイル39%に対しウォーターフォール11%、大規模案件に限ると18%対3%という数字です（PM Essentials）。
ここで確認しておきたいのが「成功」の定義です。CHAOSでは、当初見積もりに対して納期・予算・機能のすべてを満たした案件を成功としています。アムステルダム自由大学のEveleens氏とVerhoef氏は、同じ基準を実在する1,211件のプロジェクト（見積もり5,457回分）に適用して検証しました。結論は、Standishの数字は実態を反映していない、というものです。見積もりの精度を測っているにすぎず、しかも性質の異なる見積もり手法を1つの平均値にまとめているためです（IEEE Software, 2010）。
社内説明などでこの数字を使う場合は、次の点を踏まえておくと安心です。
- 差が大きく表れるのは、規模が大きく不確実性の高い案件です。
- アジャイルは進行中にスコープを調整しますが、ウォーターフォールは当初合意したスコープで評価されます。両者は同じ物差しで測られているわけではありません。
- 反証研究によれば、成功率は当初の見積もり方法に大きく左右されます。
国内の状況を見ると、IPAのDX白書2021では、アジャイル開発を活用している企業は調査対象の19.3%にとどまっています（@IT）。背景の1つとして考えられるのが、次に取り上げる契約形態です。
契約形態が開発手法を決めている
受託開発では、どの開発手法を採るかは契約を結んだ時点でほぼ決まります。請負と準委任の違いを、手法との関係に絞って整理すると次のとおりです。
| 請負契約 | 準委任契約 | |
|---|---|---|
| スコープ変更のリスク | 受注側が負う | 発注側が負う |
| 成立する条件 | 仕様が明確で、早い段階で確定できる | 発注側が継続的に関与し、判断を下せる |
| 相性の良い手法 | ウォーターフォール | アジャイル、スクラム、カンバン |
IPAが2020年に公表したアジャイル開発版のモデル契約は、準委任を前提としています。開発の途中で機能や優先順位が変わることを想定しているためです。あわせて、発注側が主体的かつ相応に関与する必要があり、委託して任せきりにはできない点も示されています（Publickey、IPA）。
発注側から見れば、請負は予算額を確定できるため稟議を通しやすい契約です。一方で準委任を選ぶと、スコープ変更のリスクを自社で持ち、判断できる担当者を継続的に確保することになります。アジャイルの活用が広がりにくい理由の一端は、ここにあると言えるでしょう。
実務では、次のような組み合わせで折り合いをつけるケースが多く見られます。
- 工程ごとに契約を分ける： 要件定義は準委任、仕様が固まってからの開発は請負とする。
- ラボ型開発： 継続的に改善していくプロダクトでは、専任チームを中長期で確保する。
AIで何が変わるか：コードは速く、仕様の重みは増す
アジャイルは「後工程での修正はコストが高い。だから小さく作って早く誤りを見つける」という考え方を土台にしています。AIの登場は、この前提となるコスト構造に直接影響します。
開発は速くなるが、安定性は下がる傾向。 GoogleのDORAレポート2025によると、ソフトウェア開発者の90%がすでにAIを利用し、80%以上が生産性の向上を感じています。AIの利用はデリバリーのスループットとは正の相関、安定性とは負の相関を示しました。また、AIが生成したコードをほとんど、あるいはまったく信頼していない人も30%にのぼります（Google Cloud）。
AIは組織の強みも弱みも増幅する。 DORAの中心的な指摘は、AIは弱いチームを補うのではなく、既にある状態を増幅するという点です。要件があいまいなまま開発を進める体制にAIを導入すれば、要件とずれたコードが、より速く、より多く生まれることも考えられます。
仕様書が再び主役になる。 AIエージェントにあいまいな指示を与えると、一見正しく動くものの、意図とは異なるコードが出来上がります。こうした背景から、2026年には「スペック駆動開発（spec-driven development）」への関心が高まっています。代表例のGitHub Spec Kitでは、作業をConstitution → Specify → Plan → Tasks → Implementの順に進めます（MarkTechPost）。
この流れは、要件定義 → 設計 → タスク分割 → 実装という、いわば小さなウォーターフォールです。異なるのは、1サイクルが数か月ではなく数時間から数日で回る点です。
これらを総合すると、アジャイルとウォーターフォールの境界は「ウォーターフォール並みに詳細な仕様を、アジャイル並みの短いサイクルで回す」方向に収れんしつつあると考えられます。工数の中心はコーディングから要件定義とレビューへ移り、ビジネスアナリストやプロダクトオーナーの役割がこれまで以上に重要になります。
手法選びの2つの軸
手法の名前からいったん離れると、選定の判断材料は「要件がどこまで明確か」と「発注側がどこまで関与できるか」の2点に集約できます。
注意したいのは左下、要件が固まっておらず、発注側の関与も限られるケースです。5つの手法のどれを選んでも、この状況をそのまま解決することはできません。多くの案件では、開発に入る前に業務分析やプロトタイプの工程を挟んでいます。なお、運用・保守フェーズについては、どの領域の案件でもカンバンが採用されることが多くあります。
5つの手法をAI時代の視点で比較
右端の列は、ここまで紹介した調査をもとに、AIが各手法に与える影響をまとめたものです。
| 手法 | メリット | デメリット | 主な契約形態 | AIによる変化 |
|---|---|---|---|---|
| ウォーターフォール | 費用・スケジュールを見積もりやすい。ドキュメントが整い、引き継ぎやすい | 仕様変更への対応が難しい。完成形が見えるのは終盤 | 請負 | 詳細な仕様書がAIエージェントへの良質なインプットになる。AIでプロトタイプを早期に作り、仕様の妥当性を確かめられる |
| アジャイル | 変化に柔軟。動くものを早く確認できる | スコープと予算を確定しにくい。発注側の継続的な関与が必要 | 準委任 | コードが速く書ける分、技術的負債も速く積み上がる。安定性を保つには自動テストの整備が欠かせない |
| スクラム | リズムが明確。進捗が見える。改善のサイクルが組み込まれている | プロダクトオーナーが不在だと機能しない。会議が形骸化しやすい | 準委任／ラボ型 | AIで数日のうちに作業が終わる場合、2週間のスプリントは長く感じられる。ボトルネックはPOとレビューに移る |
| カンバン | 導入しやすい。突発対応に強い。ボトルネックが見える | 中長期の目標や期限が後回しになりやすい | 準委任 | AIを活用した保守と相性が良い。小さなタスクが途切れなく流れ、「レビュー待ち」の列が最も注視すべき列になる |
| ハイブリッド | 予算を確定しつつ柔軟性も確保できる。稟議に乗せやすい | 工程の境目があいまいだと、双方の短所を抱える | 準委任（要件定義）＋請負（開発） | スペック駆動開発に最も近い。詳細な仕様と短いサイクルを両立できる |
まとめ
- 「アジャイルの成功率は3倍」という数字は、当初見積もりとの一致度を示すもので、ビジネス上の成果を直接測ったものではありません。
- どの手法が現実的かは、契約形態と、発注側がどこまで関与できるかに大きく左右されます。
- DORA 2025が示すように、AIはデリバリーを速める一方、安定性の低下も伴います。今後のボトルネックは要件定義とレビューであり、発注側・受注側ともにこの工程への備えが求められます。
参考文献
- Successful Projects: What We Really Know — PM Essentials（CHAOSレポートのデータ）
- Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures — IEEE Software, 2010
- DX白書2021: アジャイル開発の活用状況 — @IT
- 情報システム・モデル取引・契約書（アジャイル開発版） — IPA
- アジャイル開発の契約は「準委任」が適切 — Publickey
- Announcing the 2025 DORA Report — Google Cloud
- Meet GitHub Spec-Kit — MarkTechPost
