AgileとWaterfall: どちらのプロジェクト手法を選ぶべきか

AgileとWaterfallの比較は、プロジェクトマネジメントにおける最も古い議論のひとつです。そして、間違った手法を選ぶと最初の成果物が出る前にプロジェクトが頓挫するため、今もなお重要なテーマです。

重要なデータ

• ソフトウェア案件では、AgileプロジェクトはWaterfallを上回る**成功率64% 対49%**を達成していますが、規制下の業種や物理的な構築を伴う案件ではWaterfallが依然優勢です（Standish Group CHAOS Report、2024年）。
• 71%の組織が何らかの形でAgileを採用している一方、純粋なWaterfallは官公庁や建設業界で引き続き主流です（PMI Pulse of the Profession、2024年）。
• WaterfallモデルはWinston Royceの1970年論文に遡りますが、Royce本人は反復性を主張していました。Agile Manifestoは2001年に発行されています（Software Engineering, 1970; agilemanifesto.org）。

AgileとWaterfallの違いとは

Agileは反復的で柔軟なプロジェクト手法であり、Sprintと呼ばれる短いサイクルで作業が進み、プロジェクト全体を通じて要件を変更できます。Waterfallは順序立った手法で、各フェーズを完了・承認してから次のフェーズに移ります。

両手法の根本的な対立は、確実性に対する姿勢です。Waterfallは事前にすべてを定義できると仮定します。スコープ、予算、スケジュール、仕様。これはドメインが安定しており、要件が本当に変わらない場合に成立します。Agileは逆の仮定をします。要件は進化するもので、早期のフィードバックには価値があり、完璧な計画を遅くに届けるより早く動くスライスを出荷することの方が重要だということです。

どちらの仮定もデフォルトで間違ってはいません。大切なのはどちらがプロジェクトに合うかという問いです。新棟を建設する病院には固定の設計図、規制上の制約、そして単一の納期があります。モバイルアプリを開発するスタートアップには変化するユーザーフィードバック、不確かなプロダクトマーケットフィット、そして2週間ごとに仮定を検証する必要があります。同じ「プロジェクト」でも、リスクプロファイルとそれに合う手法は全く異なります。

Waterfallとは何か

Waterfallは直線的なフェーズゲート型プロジェクトマネジメントアプローチであり、作業は一方向に流れます。要件がデザインにつながり、デザインが開発につながり、開発がテストにつながり、テストがリリースにつながります。次のフェーズに移る前に、現フェーズを完了させます。

Winston Royceは1970年のソフトウェアエンジニアリング論文でこのモデルを説明しました。Royce自身はソフトウェアプロジェクトにとってリスクが高いと指摘し、フィードバックループを主張していましたが、順次処理の図解が定着し、その後30年間の主要なプロジェクトモデルになりました。

標準的なWaterfallプロジェクトにおける5つの順次フェーズは次のとおりです。

1. 要件定義 -- デザインを開始する前に、すべてのプロジェクト要件を収集、文書化し、承認を得ます。
2. システム設計 -- 要件定義書に基づき、技術的・機能的なアーキテクチャを完全に計画します。
3. 実装 -- 開発者が設計仕様に従ってシステムを構築します。
4. テストと検証 -- 完成したシステムを要件に対してテストし、欠陥を修正します。
5. デプロイとメンテナンス -- 製品がリリースされ、継続的なメンテナンスが始まります。

Waterfallが実務でどのように機能するかについては、Waterfallメソドロジーを参照してください。

Agileとは何か

Agileは反復的・段階的なプロジェクト成果物のための価値観と実践のセットです。作業は短いサイクル（SprintまたはIteration）に分割され、通常は1〜4週間です。各サイクルの終わりに、チームは動くIncrementを成果物として提出し、ステークホルダーとレビューし、次のサイクルの計画を調整します。

2001年に17人のソフトウェア開発者が署名したAgile Manifestoは、AgileをPlan重視の手法と区別する4つのコアバリューを定義しました。

1. 個人と対話 プロセスやツールよりも
2. 動くソフトウェア 包括的なドキュメントよりも
3. 顧客との協調 契約交渉よりも
4. 変化への対応 計画に従うよりも

これらの価値観は、プロセス、ドキュメント、契約、または計画が無価値であることを意味しません。両者が競合する場合に、各ペアの左側が優先されるということです。

Agileはフィロソフィーであり、単一のフレームワークではありません。Scrum、Kanban、SAFe、XPはすべてAgileの原則の実装です。ScrumとKanbanが最も広く使われています。この2つを直接比較するには、Scrum vs Kanbanを参照してください。

Agileが実務で何を意味するかの詳細については、Agileメソドロジーとはを参照してください。

AgileとWaterfallの比較

プロジェクト計画において最も重要な観点で、2つの手法を比較します。

表を見るとAgileが明らかな勝者に見えますが、「最適な場面」の行が最も重要です。柔軟性と早期のリスク検出というAgileの強みは、プロジェクトに本当に不確かな要件と素早い反復が必要な場合にのみ優位性を発揮します。

Waterfallが優れている場面

Waterfallは、後期での計画変更コストが低く、要件を誤るコストが高い場合に適切な選択です。以下の場面でWaterfallを検討しましょう。

• 要件が完全に定義されており、作業開始前に契約上固定されている
• 規制やコンプライアンスの枠組みが各フェーズで完全なドキュメントを要求する
• 成果物が物理的（建設、ハードウェア、製造）であり、製造途中で反復できない
• クライアントまたはスポンサーが継続的なレビューサイクルに参加できない
• 別々の専門チーム間の引き継ぎに正式なサインオフが必要

Waterfallが活躍する実例:

官公庁・防衛省の契約案件。 新しいデータセンターインフラを調達する政府機関は、通常、完全な作業明細書、承認済みの設計ドキュメント、Milestone払いが必要です。サーバールームを「反復」することはできません。Waterfallのフェーズゲート構造は、調達とコンプライアンスの要件に直接対応します。

医療機器開発。 クラスIIの医療機器のFDA承認には、文書化された設計管理、トレーサビリティマトリクス、臨床使用前の検証テストが必要です。Agileの「包括的ドキュメントよりも動くソフトウェアを」という価値観は、21 CFR Part 820への準拠とは相容れません。

建設・土木工学。 構造基盤を検査・承認する前に3〜10階を建てることはできません。クリティカルパス法やガントチャートが自然な計画ツールであり、Sprintではありません。

Agileが優れている場面

Agileは、要件が不確かで、フィードバックが得られ、事前の完全性よりも検証された成果への速度が重要な場合に適切な選択です。以下の場面でAgileを検討しましょう。

• ユーザーフィードバックや市場変化に基づいて要件が変わる可能性がある
• 2〜4週間以内に動くIncrementを納品・テストできる
• チームがクロスファンクショナルで、同じ場所にいる（または実質的にリモートで共存している）
• ステークホルダーがSprint Reviewに参加・貢献する意欲がある
• 誤った仮定のコストが、発覚の遅れによるコストより低い

Agileが活躍する実例:

ソフトウェア製品開発。 新しい分析Dashboardを開発するSaaS企業は、ユーザーがプロトタイプを見るまで、どのチャートが最も価値があるかを把握できません。ライブユーザーテストを伴う2週間Sprintによって、6ヶ月を誤った機能セットに投資する前に検証と軌道修正ができます。

マーケティングキャンペーン開発。 Q4の製品ローンチを実行するデジタルマーケティングチームは、週次Sprintで広告クリエイティブ、ランディングページの変種、メッセージの角度をテストし、成果が出ないものを終了し、成果が出ているものに倍賭けできます。1月に12月ローンチのキャンペーン全体を固定するのは、3四半期分の市場学習を無視することです。

R&D・イノベーションプロジェクト。 問題自体が完全に定義されていない場合、反復的な探索が順次計画を上回ります。新しいAI搭載ワークフローツールを開発するチームは、初期バージョンをアーリーアダプターがどう使うかを見るまで、最終的な機能セットを知ることができません。

選択のための意思決定マトリクス

これらの質問を順番に検討して、適切な手法を見つけましょう。各質問はどちらかの手法を支持します。

回答の多くが一方向を向いているなら、その手法が適合しています。ほぼ半々に分かれるなら、ハイブリッドアプローチの検討が必要です。

実践的なテスト: 主要な仮定が3ヶ月目に誤りと判明した場合、何が起きるかを自問してみましょう。壊滅的な手直しなしに軌道修正できるなら、Agileは実現可能です。仮定の誤りが構造鉄鋼の再工事を意味するなら、Waterfallの事前の厳密さに投資する価値があります。

プロジェクトライフサイクルの視点もここで役立ちます。明確に定義されたライフサイクルと予測可能なフェーズ移行を持つプロジェクトは、自然にWaterfallに合います。曖昧または探索的なライフサイクルのプロジェクトは、Agileの継続的な再計画から恩恵を受けます。

ハイブリッドアプローチ

純粋なAgileも純粋なWaterfallも、すべての現実の制約に適合するわけではありません。実践的な妥協案として、3つのハイブリッドモデルが登場しています。

ハイブリッドのリスクは、どちらの手法のメリットも得られないまま両方のコストを引き受けることです。Water-Scrum-FallはScrumチームが中間フェーズで真の自律性を持てるときに機能します。事前のWaterfallの要件フェーズがScrumチームを疑問を持てない設計に縛り付けると破綻します。

KanbanとScrumがどのように融合するかについては、Scrum vs Kanbanを参照してください。

AgileとWaterfallについてよくある誤解

両手法には、チームを間違った選択に向かわせる誤解が積み重なっています。

どちらの手法にも共通するベストプラクティス

これらのプラクティスは、選択した手法に関わらず適用されます。

• 作業開始前に「完了」を定義する。 Sprint StoryのためのAcceptance Criteriaを書く場合でも、WaterfallフェーズのためのSign-off基準を書く場合でも、すべてのチームは完了の共通定義が必要です。
• ガバナンスを手法に合わせる。 WaterfallスタイルのChange Controlプロセスをagileチームに適用しないでください。オーバーヘッドがVelocityを損ないます。実際のチームの動き方に合った承認・エスカレーションプロセスを設計しましょう。
• 作業分解構成図でスコープを分解する。 AgileとWaterfallの両方において、スコープを管理可能な単位に分解することで恩恵を受けます。Waterfallではプロジェクト計画に、Agileではbacklogに使います。
• RACIマトリクスでオーナーシップを割り当てる。 不明確な説明責任は両方の手法を遅くします。誰が責任者で、誰が承認し、誰に相談するか、これらの問いはSprintでもフェーズでも重要です。
• リスクを明示的に追跡する。 Waterfallはデフォルトでリスクを後期に表面化させます。正式なリスク登録とフェーズゲートレビューでこれに対抗しましょう。Agileはリスクを早期に表面化させますが、納品プレッシャーの下で後回しになることがあります。
• 定期的にRetrospectiveを行う。 Agileはretrospectiveを義務付けています。Waterfallチームも同じ規律でフェーズ後レビューを実施すべきです。構造的な振り返りなしに、どちらの手法も改善しません。
• 間違った層への過剰投資を避ける。 Waterfallチームは古くなる事前ドキュメントに過剰投資します。Agileチームはアーキテクチャへの投資が不足し、後のSprintを遅くする技術的負債を生むことがあります。バランスのとれた投資を心がけましょう。
• 手法をクライアントの業務リズムに合わせる。 クライアントが月次で成果物をレビューするなら、2週間のSprintサイクルは摩擦を生みます。意思決定が実際に行われる方法にレビューサイクルを合わせましょう。

よくある質問

AgileはWaterfallより優れていますか？ プロジェクトによります。Agileは変化する要件を持つソフトウェアプロジェクトでWaterfallを上回ります（Standish Group 2024年: 成功率64% 対49%）。しかし規制下の、固定スコープの、物理的な構築を伴う案件では、反復的な納品が実用的でないためWaterfallが上回ります。どちらが普遍的に優れているわけではありません。

AgileとWaterfallを混合できますか？ はい。Water-Scrum-Fall、Wagile、Scrumbanのようなハイブリッドモデルはそれぞれの要素を組み合わせています。重要なのは、どの部分を採用しどの理由で採用するかについて意図的であることです。計画なく混合すると、通常は両者のオーバーヘッドを引き受けながら、どちらのメリットも得られない結果になります。

どちらの手法が速いですか？ Agileは1〜4週間ごとに動くIncrementを出荷するため、価値の提供がより速いです。Waterfallは全製品の納品が遅くなりますが、要件が安定していれば再計画のオーバーヘッドがないため、総所要時間が短くなることもあります。「速い」の定義が、最初の納品までの時間か最終納品までの時間かによって答えは変わります。

どちらの手法がコストが低いですか？ Waterfallは要件が明確なプロジェクトでは再計画コストがないため、コストが低くなります。AgileはSprintでの修正が最終テストでの誤った仮定の発覚より安価なため、要件が不確かな場合はコストが低くなります。Agileはスコープ管理が不十分な場合、予算リスクが高くなります。Waterfallは要件が誤っている場合、予算リスクが高くなります。

どちらの手法がリスクが高いですか？ どちらもリスクを持ちますが、リスクが表面化するタイミングが異なります。Waterfallは統合・テストフェーズにリスクを集中させ、プロジェクト後期になることが多いです。Agileはリスクをsprintに分散させ、修正コストが低い早期に問題を表面化させます。後期での発覚が壊滅的なプロジェクト（防衛システム、医療機器）では、統合時の急増があるものの、Waterfallの事前の厳密さが後期リスクを低減します。

---

AgileとWaterfallのどちらを選ぶかは、哲学的な問いではありません。実践的な問いです。プロジェクトのリスクプロファイルとは実際どのようなものか、そしてどちらの手法がそのプロファイルをよりうまく扱えるかという問いです。意思決定マトリクスから始め、「各手法が優れる場面」の基準に照らして制約を確認し、状況が本当にそれを求めているならハイブリッドも排除しないでください。手法が仕事に合うべきであり、その逆ではありません。