「どちらでもいける」という判断が、プロジェクトを崩壊させる
アジャイルとウォーターフォール。どちらを選ぶべきか——この問いに対して、「プロジェクトの性質による」「要件が固まっているかどうかで決める」という答えを聞いたことがない人はいないだろう。
だが、現場で本当に多いのは、「どっちでもいけそうだから、なんとなく決めた」というケースだ。そしてその「なんとなく」が、プロジェクトの中盤以降に致命的な歪みとして噴出する。
本記事では、正しい手法選択の原則論ではなく、「間違った選択をしたプロジェクトが実際にどう壊れるか」という失敗パターンを起点に、逆算式で判断基準を導くアプローチをとる。過去記事「どちらが正解かという問いを捨てる」が選択の思考法を論じたのに対し、本記事は”失敗の解剖”から実践的な判断軸を構築することを目的とする。
失敗パターン①：「変わるはずのない要件」がアジャイルで空中分解する
何が起きたか
官公庁向けの基幹システム刷新プロジェクト。「アジャイルの方がスピーディ」というCTOの鶴の一声でスクラムを採用した。しかし3ヶ月後、プロジェクトは混乱の極みにあった。
原因は明確だった。このプロジェクトには法令に基づく仕様、監査要件、外部システムとの厳密なインターフェース定義が存在していた。スプリントごとに「ちょっと変えてみる」が許される性質のものではなかったのだ。
バックログは積み上がり、「完成の定義」が毎回揺れ、ステークホルダーは「いつ終わるのか」という問いに答えられないチームに不信感を募らせた。
逆算される判断軸
以下の条件が複数重なる場合、アジャイルの採用は慎重に再考すべきだ。
- 成果物の受け入れ基準が契約・法令・外部標準によって事前に固定されている
- ステークホルダーがスプリントレビューに参加できない、または意思決定権を持たない
- 変更コストが極めて高い（ハードウェア連携、レガシーシステム統合など）
Tip：「変更の余地があるか」ではなく「変更の権限が誰にあるか」を確認せよ。意思決定者がプロジェクト外にいるなら、アジャイルの前提が成立しない。
失敗パターン②：「要件が固まっている」という思い込みでウォーターフォールに突入し、終盤で崩壊する
何が起きたか
新規事業向けのWebサービス開発。「要件定義フェーズで徹底的に詰めたから大丈夫」という自信のもと、ウォーターフォールで進行した。ところが、開発終盤のUATで「これじゃない」という声がユーザーから噴出した。
要件定義書は確かに詳細だった。しかし、ユーザーは実際に動くものを見るまで、自分が何を求めているかを言語化できなかったのだ。ドキュメントへのサインオフは「内容を理解した」ではなく「読んだ」に過ぎなかった。
逆算される判断軸
次の条件が重なる場合、ウォーターフォールの採用リスクは高い。
- 顧客・ユーザーが自分のニーズを言語化した経験がない（新規事業、新規ユーザー層）
- 競合環境や市場の変化スピードが速く、リリース時点での要件陳腐化リスクが高い
- PoC（概念実証）なしにフル開発へ移行しようとしている
Tip：「要件定義書に署名をもらった」は安心の根拠にならない。「ユーザーが動くものを見て確認した」かどうかを問え。
失敗パターン③：「ハイブリッド」という名の無秩序
何が起きたか
「アジャイルとウォーターフォールのいいとこ取り」を標榜したプロジェクト。要件定義と設計はウォーターフォール、開発以降はスクラムで回す設計だった。しかし実際には、設計フェーズが長引いてスクラムの開始が遅れ、スプリント中に「やっぱり設計を変えたい」という要求が頻発。どちらのルールも中途半端に機能し、どちらのメリットも享受できなかった。
逆算される判断軸
ハイブリッドを選ぶなら、以下の3点を事前に明文化しなければならない。
- フェーズの境界条件：「どの成果物が承認されたら次フェーズへ移行するか」を定義する
- 変更の窓口と凍結ルール：アジャイルフェーズに入ったら設計ベースラインを凍結し、変更は変更管理プロセスを経ることを明示する
- ガバナンスの統一：スクラムイベントとステアリングコミッティの報告タイミングを整合させる
Tip：「ハイブリッド」はデフォルトの選択肢ではなく、意図的な設計の産物でなければならない。「どちらでもいけそうだからハイブリッド」は最も危険な出発点だ。
選択を「失敗から守る」ための3つの問い
手法選択の場面で、次の3問を自分に投げかけてほしい。
- 「フィードバックループの速さ」と「意思決定者のアクセス可能性」は一致しているか？
アジャイルは頻繁なフィードバックが前提だ。意思決定者が毎スプリント関与できない構造なら、機能しない。 - 「変更コスト」と「変更の蓋然性」のどちらが高いか？
変更コストが高く変更の可能性が低い→ウォーターフォール。変更コストを低く保てて変更が起こりやすい→アジャイル。 - 「完成の定義」はプロジェクト開始前に合意できるか？
できるならウォーターフォールの土台がある。できないなら、アジャイルで「完成に近づける」プロセスが必要だ。
おわりに——手法は「選ぶ」のではなく「設計する」もの
アジャイルとウォーターフォールの議論で陥りがちな罠は、「どちらが優れているか」という比較論に引きずられることだ。しかし現場のプロジェクトマネージャーに本当に必要なのは、「このプロジェクトが失敗するとしたら、どんな理由で失敗するか」を先読みし、その失敗を構造的に防げる手法を選び取る力だ。
手法の選択は、プロジェクト開始時の一度きりの判断ではない。フェーズが進むにつれて「この手法は今のフェーズに合っているか」を問い続ける動的なプロセスでもある。
「なんとなく決めた手法」がプロジェクトの終盤に牙を剥く前に、今一度、失敗パターンから逆算した選択の問いを自分のプロジェクトに当ててみてほしい。
