「どちらが正解か」という問いを捨てる——アジャイルとウォーターフォールを”状況で選ぶ”思考法

＜目次＞

「どちらの手法を使うべきか」論争に終止符を

プロジェクトマネジメントの現場では、今なお「アジャイルとウォーターフォール、どちらが優れているか」という議論が繰り返されます。しかし、この問いの立て方そのものが間違いです。

優れた料理人が「フライパンと鍋、どちらが良い道具か」とは問わないように、PMが問うべきは「このプロジェクトには、どちらが適しているか」です。手法はあくまで道具。判断基準を持たずに選べば、どちらを選んでも失敗します。

本記事では、両手法の特性を整理したうえで、「状況に応じて選ぶ」ための実践的な判断フレームワークを紹介します。

ウォーターフォールは、要件定義→設計→開発→テスト→リリースという工程を順番に進める手法です。各フェーズの成果物が明確で、進捗管理がしやすく、承認プロセスや契約との相性も良い。

得意な状況は次のとおりです。

アジャイルは、短いサイクル（スプリント）で動くものを作り、フィードバックを受けながら改善を繰り返す手法です。不確実性に強く、顧客や市場の変化に柔軟に対応できます。

得意な状況は次のとおりです。

手法選択に迷ったとき、以下の4軸でプロジェクトを評価してみてください。

「完成形が最初からイメージできるか」を問います。官公庁向けシステムや基幹業務系の刷新では、要件定義書を固めてから進むウォーターフォールが安全。一方、「使ってみないとわからない」新機能の開発にはアジャイルが向きます。

プロジェクトの後半で仕様変更が発生したとき、どれだけのコストがかかるかを見積もります。ハードウェアや建設が絡む案件は変更コストが膨大なため、前半で設計を固めるウォーターフォールが合理的。ソフトウェア開発はコードの変更コストが比較的低いため、アジャイルの反復開発と相性が良い。

アジャイルは、プロダクトオーナー（顧客側の意思決定者）がスプリントごとに参加し、フィードバックを出し続けることが前提です。「承認フローが長い」「担当者がプロジェクトに深く関与できない」組織文化では、アジャイルは機能しにくい。

アジャイルは、チームが自己組織化して動ける状態を前提とします。マネジメント経験が浅いメンバーが多い、あるいは分散チームで連携が難しい場合は、工程と役割が明確なウォーターフォールの方が安定します。

実際の現場では、純粋なウォーターフォールも純粋なアジャイルも、どちらも少数派です。多くのプロジェクトで有効なのは、「ハイブリッドアプローチ」です。

たとえば、こんな組み合わせが実践的です。

重要なのは「どちらかに純化する」ことではなく、プロジェクトの特性に合わせてルールを設計することです。

最後に、現場でよく見られる失敗パターンを2つ挙げます。

罠①「流行っているからアジャイル」
アジャイルへの移行を推進した結果、要件が固まらないまま開発が進み、後半で大量の手戻りが発生するケースは珍しくありません。組織の文化や体制が追いついていないまま手法だけを変えても、混乱を生むだけです。

罠②「大企業だからウォーターフォール」
慣習的にウォーターフォールを続けた結果、リリース時には市場ニーズがズレていた——という事例も多い。特にデジタルプロダクト開発では、長い開発期間が競争機会の喪失につながります。

アジャイルとウォーターフォールは対立するものではなく、それぞれ異なる問題を解くための道具です。PMの役割は、プロジェクトの状況を正確に読み、最適な手法を選び、チームと合意しながら進めることにあります。

「うちはアジャイルでやっている」「ウォーターフォールしか使わない」という固定観念を手放したとき、プロジェクトマネジメントの選択肢は大きく広がります。判断軸を持ち、状況に応じて柔軟に設計できるPMこそが、複雑な現場を動かせるのです。