「方法論を選ぶ」のではなく「問いを設計する」——アジャイル・ウォーターフォール選択を”プロジェクトの本質”から逆算する思考フレーム

＜目次＞

「どちらを使うか」より先に問うべきことがある
不確実性には「2つの種類」がある
1. ① 既知の未知（Known Unknowns）
2. ② 未知の未知（Unknown Unknowns）
「変化のコスト」で見極める実践的判断軸
「誰が正解を持っているか」という問い
PMが持つべき「問いの設計力」
おわりに——「選択する前に、問いを設計せよ」

「どちらを使うか」より先に問うべきことがある

アジャイルかウォーターフォールか——この問いは、プロジェクト開始時に必ずといっていいほど浮上する。しかし多くのPMが、この問いに対して「規模」や「業種」や「チームの慣れ」という表層的な基準で答えを出してしまっている。

本記事では、方法論の比較ではなく、「そもそも何を問うべきか」という視点から選択の思考プロセスを再設計する。過去記事で扱ってきた「失敗パターン」「ハイブリッド設計」「どちらでも行ける幻想」といった切り口とは異なり、ここではプロジェクトの本質的な不確実性の構造に着目する。

不確実性には「2つの種類」がある

選択を誤る根本的な原因のひとつは、「不確実性」をひとくくりに捉えていることだ。実は不確実性には性質の異なる2種類がある。

① 既知の未知（Known Unknowns）

「詳細はまだ決まっていないが、何が決まっていないかはわかっている」状態。たとえば、要件定義の段階で「画面デザインは未確定」とわかっている場合がこれにあたる。この種の不確実性は、計画の精度を上げることで対処できる。ウォーターフォールが有効に機能するのは、この領域だ。

② 未知の未知（Unknown Unknowns）

「何がわかっていないか自体がわからない」状態。新規市場への参入、前例のないプロダクト開発、ユーザーの使い方が読めないサービス設計などがこれにあたる。この種の不確実性は、計画では解消できない。仮説を立て、実験し、学びながら進むアジャイルのアプローチが必要になる。

Tips：プロジェクト開始時に「私たちが知らないことを、私たちは知っているか？」と自問してみよう。この問いへの答えが、方法論選択の最初の分岐点になる。

「変化のコスト」で見極める実践的判断軸

もうひとつの重要な問いは、「このプロジェクトにおいて、変化のコストは時間とともに増大するか？」だ。

建設プロジェクトを例にとろう。基礎工事が終わったあとに「やっぱり3階建てを5階建てにしたい」となれば、変更コストは膨大になる。このように、後戻りのコストが指数関数的に増大する構造を持つプロジェクトでは、前工程を丁寧に固めるウォーターフォールが合理的だ。

一方、ソフトウェア開発では、適切な設計と自動テストが整備されていれば、後半での変更コストをある程度抑えられる。つまり変化のコスト曲線をなだらかにできる環境では、アジャイルの「変化への適応」という強みが活きる。

プロジェクトの物理的・技術的特性を踏まえ、「変化のコスト構造」を見極めることが、表面的な業種・規模の判断よりも本質的な選択基準になる。

「誰が正解を持っているか」という問い

もう一歩踏み込んだ問いを加えよう。それは、「このプロジェクトの正解を、誰がいつ知ることができるか」だ。

正解がプロジェクト開始前からステークホルダーの頭の中に存在しており、それを引き出して仕様化できるなら、ウォーターフォール的アプローチが機能する。要件定義という行為が意味を持つのは、この前提があるときだ。

しかし、正解がユーザーの使用体験の中からしか生まれない場合——たとえば「使ってみないと何が嬉しいかわからない」サービス——では、どんなに精緻な要件定義をしても「作ったが使われない」という結末を迎えるリスクがある。この場合は、仮説検証のサイクルそのものをプロジェクト設計に組み込むアジャイル的発想が必要だ。

具体例：社内の基幹システム刷新（業務フローが明確）ではウォーターフォール寄りが合理的。一方、新規ユーザー向けのアプリ開発（使われ方が未知）ではアジャイル寄りが適切になる。同じ「システム開発」でも、この問いへの答えは全く異なる。