多くの炎上プロジェクトは、
開発後半ではなく、要件定義の段階ですでに崩れ始めています。
しかし当事者はそれに気づきません。
なぜなら要件定義は、
「順調に進んでいるように見える工程」だからです。
- 会議もしている
- ドキュメントも作っている
- 合意も取っている
それでも、崩壊は静かに始まっています。
要件定義で本当に起きていること
多くの現場で起きているのは、
“要望の整理”であって、“要件の定義”ではないという現象です。
顧客や事業側の声を集め、
- これも必要
- あれも欲しい
- 将来的にはこうしたい
それを資料にまとめる。
一見、正しいプロセスに見えます。
しかし、本来の要件定義は違います。
「何をやらないか」を決める工程
です。
ここが曖昧なまま進むと、
後工程で必ず歪みが生まれます。
崩壊が始まる3つのポイント
1. 目的が抽象的なまま進む
典型例：
- 「ユーザー体験を向上させたい」
- 「業務を効率化したい」
- 「競争力を強化したい」
間違ってはいません。
しかし抽象的な目的は、
無限に解釈可能です。
その結果、
- スコープが膨張する
- 優先順位が揺れる
- 意思決定がブレる
要件定義の最初にやるべきことは、
このプロジェクトが“成功”と言える状態は何か？
を定義することです。
これがないまま仕様に入ると、
プロジェクトは必ず迷走します。
2. 前提条件が言語化されていない
多くの要件定義書には、機能一覧はあります。
しかし、
- 技術制約
- 予算制約
- スケジュール制約
- 組織的制約
が明文化されていないことが多い。
結果として、
「そんな前提は聞いていない」 「それは想定外だった」
という衝突が起きます。
要件とは、
機能 + 制約条件 です。
制約を書かない要件定義は、
設計図のない建築と同じです。
3. 決定構造が曖昧
要件定義中によく聞く言葉があります。
- 「一旦これでいきましょう」
- 「仮で置いておきます」
- 「後で調整しましょう」
仮置きが多いプロジェクトは、
ほぼ確実に後半で爆発します。
問題は仮置きそのものではありません。
問題は、
その仮置きの責任者と見直しタイミングが定義されていないこと
です。
決定構造が曖昧なまま開発に入ると、
仕様変更が連鎖的に発生します。
なぜPMは止められないのか？
多くのPMは、違和感を覚えています。
- 目的がふわっとしている
- 制約が整理されていない
- 合意が曖昧
それでも止められない。
理由は主に3つです。
- 早く開発に入りたいという圧力
- 上位者の意向への遠慮
- 技術的制約への理解不足
しかしここで立ち止まれないと、
後で何倍ものコストを払うことになります。
要件定義を崩壊させないために
高度な手法は不要です。
最低限、以下を明文化するだけでよい。
1. 成功定義（Success Criteria）
- 数値で測れるか？
- 誰が評価するのか？
2. スコープの外側
- 今回やらないことは何か？
3. 制約条件一覧
- 技術
- 予算
- スケジュール
- 組織
4. 意思決定ルール
- 誰が最終決定者か？
- 変更時のプロセスは？
これが揃って初めて、
要件定義は「完了」と言えます。
本質的な問題
要件定義が崩壊する本当の理由は、
曖昧さを放置したまま前に進んでしまうこと
です。
曖昧さは楽です。
対立も起きません。
しかし曖昧さは、
必ず後工程でコストとして返ってきます。
最後に
炎上は、設計ミスではありません。
ほとんどの場合、
要件定義の曖昧さが時間差で爆発した結果
です。
もし今、
- 要件定義に不安がある
- 合意形成に違和感がある
- 開発前なのにモヤモヤしている
そんな状態なら、一度立ち止まり、
構造を整理する価値があります。
プロジェクトを守る最大の防御は、
「早く作ること」ではなく
「正しく決めること」 です。
PMプロフェッショナル育成コーチングでは、実践に即した独自のカリキュラムで、プロジェクトを成功に導くPM育成を行っています。
ご興味ある方は、こちらをご覧ください。