プロジェクトが崩れる最大の原因は、開発でもバグでもない。「何を作るか」の合意が、いつの間にかズレていくことだ。

「ついでにこれも」が積み重なり、最小限のはずだった機能が肥大化し、「速くて安全なのは当たり前」という暗黙の期待が後から牙をむく。最初に全員が賛同したはずのユーザー像は誰も見なくなり、口頭での約束が「言った・言わない」の泥沼を生む。

これらはすべて要件定義とスコープ管理の盲点だ。そして重要なのは、これらが担当者の不注意ではなく、人間の認知の構造と、合意形成プロセスの設計ミスから必然的に生まれるということだ。

本稿では、要件定義における5つの罠を、行動経済学・認知科学・成功するPMの実践知・AI活用の4軸で解体し、今日から使える防衛設計を提示する。

---

罠① スコープクリープの「温度変化」――茹でガエルのように範囲が広がる

なぜ起きるのか：「漸進的コミットメント」と「拒否の心理的コスト」

スコープクリープ（Scope Creep）とは、プロジェクトの範囲が当初の合意を超えて少しずつ拡大していく現象だ。恐ろしいのは、それが「一度の大きな変更」ではなく「無数の小さな追加」として進行する点にある。茹でガエルが少しずつ上がる水温に気づかないように、PMもチームも「気づいたときには手遅れ」になる。

なぜ拒否できないのか。行動経済学の「漸進的コミットメント（Foot-in-the-door）」が働く。一度「いいですよ」と小さな追加を受け入れると、次の追加も断りにくくなる。さらに、追加要望を拒否することには「関係が悪くなる」「ケチだと思われる」という心理的コストが伴う。一件あたりのコストは小さく見えるため、「これくらいなら」と受け入れ続けてしまう。

具体的な実践策

【「変更ログ」で温度変化を可視化する】
すべての追加要望を、たとえ「5分で終わる小さなもの」でも変更ログに記録する。記録項目は「日付・要望内容・追加工数の見積もり・累積追加工数」の4つ。重要なのは「累積」を常に見えるようにすることだ。「今回の追加は2時間」ではなく「これで累積38時間目」と表示されることで、漸進的コミットメントの罠から抜け出せる。

【「トレードオフ提示」で追加を健全に扱う】
追加要望を拒否するのではなく、「この機能を追加する場合、Aの機能を後回しにするか、納期を1週間延ばすか、予算を追加するかのいずれかが必要です。どれを選びますか？」とトレードオフを提示する。これにより「追加＝無料」という錯覚を解消し、要望者自身に優先順位を判断させる。NOと言わずに健全な境界を引く技術だ。

【AIによる「スコープ影響の即時試算」】
追加要望が来たとき、その内容と現在のタスクリストをAIに入力し、「この追加要望が既存のスケジュール・工数・依存関係に与える影響を試算してください」とプロンプトを投げる。人間が「なんとなく小さい」と感じる要望でも、AIが「実は3つの既存機能に影響し、累計15時間の追加工数が発生」と客観的に試算する。感覚ではなくデータで追加判断を行う仕組みを作る。

---

罠② MVPの「最小」が誰も共有できていない

なぜ起きるのか：「抽象語の解釈拡散」

MVP（Minimum Viable Product＝実用最小限の製品）は、スタートアップやアジャイル開発で広く使われる概念だ。しかし「最小（Minimum）」という言葉の解釈が、関係者全員でバラバラという問題が頻発する。

認知科学の「抽象語の解釈拡散」が原因だ。「最小限」という抽象的な言葉は、各人が自分の立場・経験・願望で意味を補完する。経営者にとっての「最小」は「とにかく早く市場に出す版」、開発者にとっては「技術的に破綻しない最低限の設計」、クライアントにとっては「自分が見せたい機能は全部入っている版」だ。全員が「MVP」という同じ言葉を使いながら、頭の中では全く違う製品を想像している。

具体的な実践策

【「Yes/Noリスト」でMVPの境界を物理的に定義する】
「最小限」という抽象語を使わず、機能を一覧化して「MVPに含む（Yes）」「MVPに含まない＝フェーズ2（No）」を一つひとつ全員で仕分ける。曖昧な言葉ではなく、具体的な機能リストへの〇×で合意を取る。この「Yes/Noリスト」を全関係者が署名（メール承認でも可）することで、後の「これは入っているはずだった」を防ぐ。

【「MVPの目的」を一文で合意する】
MVPで「何を検証したいのか」を一文で定義する。「このMVPは、ユーザーが〇〇という課題に対してお金を払う意思があるかを検証するためのものである」のように。目的が明確になれば、「その検証に必要な最小機能は何か」が自然に導かれる。目的なきMVPは、必ず機能の盛り込み合戦になる。

【AIによる「MVP範囲の妥当性チェック」】
作成した機能リストとMVPの目的をAIに入力し、「このMVPの目的を達成するために、リスト内で本当に必要な機能と、フェーズ2に回せる機能を仕分けてください。また、目的達成に必要なのにリストから漏れている機能があれば指摘してください」とプロンプトを投げる。AIが「目的」を軸に客観的に機能を仕分けることで、各自の願望による盛り込みを抑制できる。

---

罠③ 非機能要件の後回し――「速くて安全」は当たり前ではない

なぜ起きるのか：「目に見える機能」への注意の偏り

要件定義の議論は、ほぼ必ず「機能要件（何ができるか）」に集中する。ログイン機能、検索機能、決済機能――これらは目に見え、説明しやすく、価値が分かりやすい。一方で「非機能要件」――性能・セキュリティ・可用性・拡張性・保守性――は後回しにされる。「速いのは当たり前」「安全なのは当然」という暗黙の前提のまま、明示的に合意されない。

認知科学の「顕著性バイアス（Salience Bias）」が原因だ。人間は目立つ・分かりやすい情報に注意を奪われ、目立たないが重要な要素を見落とす。非機能要件は「動いているときは見えず、壊れたときに初めて意識される」性質を持つため、計画段階で軽視されやすい。そして、これらは後から追加するのが最も高コストな要素だ。

具体的な実践策

【「非機能要件チェックリスト」の標準化】
要件定義の必須プロセスとして、以下の6カテゴリを必ず議論する。①性能（レスポンス速度・同時接続数）②可用性（許容ダウンタイム・障害時の対応）③セキュリティ（認証・暗号化・脆弱性対策）④拡張性（将来のユーザー増・機能追加への耐性）⑤保守性（運用のしやすさ・ドキュメント）⑥互換性（対応ブラウザ・デバイス・既存システム連携）。各項目に具体的な数値目標を設定する。「速い」ではなく「3秒以内」、「安全」ではなく「OWASP Top 10に対応」と定義する。

【AIによる「非機能要件の漏れ」検出】
作成した要件定義書をAIに入力し、「この要件定義書において、明示的に合意されていない非機能要件（性能・可用性・セキュリティ・拡張性・保守性・互換性）を洗い出し、このプロジェクトの性質を踏まえて確認すべき具体的な数値目標を提案してください」とプロンプトを投げる。機能要件に意識を奪われて見落とした非機能要件を、AIが網羅的に補完する。

---

罠④ ペルソナの形骸化――作った瞬間に忘れられるユーザー像

なぜ起きるのか：「儀式化」と「意思決定との断絶」

プロジェクト初期に時間をかけてペルソナ（典型的なユーザー像）を作る。全員が「なるほど」と賛同する。しかし設計中盤になると、誰もそのペルソナを参照しなくなり、いつの間にか「自分たちが作りたいもの」を作り始める。これが「ペルソナの形骸化」だ。

原因は、ペルソナ作成が「儀式」になってしまい、実際の意思決定プロセスと接続されていないことだ。認知科学的に言えば、ペルソナは「知っている知識」としては存在するが、「使う知識（手続き的知識）」になっていない。さらに、開発が進むにつれて議論の焦点が「技術的にどう実装するか」に移り、「誰のために作っているか」という視点が背景に退く。

具体的な実践策

【「ペルソナ照合」を意思決定プロセスに埋め込む】
機能の追加・変更・優先順位の判断をするとき、必ず「これは〇〇さん（ペルソナ名）の課題を解決するか？」という問いを通す。スプリントレビューやデザインレビューのアジェンダに「ペルソナ照合」を固定項目として入れる。ペルソナを「作る対象」から「毎回参照する判断基準」に変える。

【ペルソナを「壁に貼る」物理的可視化】
ペルソナをドキュメントの中に埋もれさせず、オフィスの壁・Slackのピン留め・Notionのトップページなど、全員が日常的に目にする場所に常に表示する。リモートチームの場合は、会議の冒頭でペルソナのスライドを1枚必ず映すルールにする。物理的に目に入る頻度が、参照頻度を決める。

【AIにペルソナを「演じさせる」フィードバック】
設計や機能の判断に迷ったとき、AIにペルソナの設定を伝え、「あなたは〇〇というペルソナです。この機能・このUIについて、あなたの立場からどう感じるか、何が使いにくいか、何が嬉しいかを率直に答えてください」とプロンプトを投げる。AIがペルソナになりきって反応することで、「ユーザー視点」を意思決定の場に即座に呼び戻せる。実際のユーザーテストの代替にはならないが、設計途中の簡易チェックとして有効だ。

---

罠⑤ 「口約束のスコープ」問題――「言った・言わない」の泥沼

なぜ起きるのか：「記憶の再構成」と「自己奉仕バイアス」

廊下での立ち話、電話での「ちょっといいですか」、会議後の雑談――こうした場面で交わされた「じゃあそれもお願いします」「いいですよ」という口約束が、後に「約束した」「していない」の対立に発展する。これはプロジェクトの信頼関係を破壊する最も厄介な問題の一つだ。

認知科学が示すように、人間の記憶は「録画」ではなく「再構成」だ。思い出すたびに、現在の状況・感情・願望によって記憶が無意識に書き換えられる。さらに「自己奉仕バイアス（Self-serving Bias）」により、各自が自分に都合の良い形で記憶を再構成する。発注側は「無料で対応すると言った」と記憶し、受注側は「検討すると言っただけ」と記憶する。どちらも嘘をついていない。本当にそう記憶しているのだ。

具体的な実践策

【「即時テキスト確認」を習慣化する】
口頭で何かが決まったら、その日のうちに「先ほどの〇〇について、△△という認識で進めます」とメール・チャットで送る。相手が反応しなければ「合意」とみなすルールにする。この一手間が、後の数十時間の対立を防ぐ。重要なのは「責める」トーンではなく「認識を揃える」トーンで送ることだ。

【「決定はすべて1か所に集約」する運用】
口頭・メール・チャット・会議など、どこで決まったことでも、最終的に「決定ログ」という一つの場所に集約するルールを設ける。NotionやConfluenceに「このプロジェクトのすべての決定はここに記録される」という単一の真実の源（Single Source of Truth）を作る。「どこで決まったか分からない」状態をなくす。

【AIによる「会話ログからの決定事項抽出」】
会議の文字起こしやチャットのやり取りをAIに入力し、「この会話の中で『決定されたこと』『依頼されたこと』『保留になったこと』を分類し、それぞれの担当者と期限を抽出してください。曖昧で確認が必要な箇所も指摘してください」とプロンプトを投げる。口頭で流れてしまいがちな「決まったのか決まっていないのか曖昧な事項」を、AIが構造化して可視化する。これを決定ログに転記することで、記録の抜け漏れを防ぐ。

---

5つの罠に共通する原則――「曖昧さ」を許さない設計

スコープクリープ・MVPの解釈ズレ・非機能要件の後回し・ペルソナの形骸化・口約束の泥沼。これら5つの罠に共通するのは、すべて「曖昧なまま進む」ことから生まれているという点だ。

「これくらいの追加なら」「最小限でいい」「速いのは当たり前」「だいたいこういうユーザー」「口頭で合意した」――これらの曖昧さが、後の巨大な手戻り・対立・崩壊を生む。成功するPMがやっているのは、特別な交渉術ではない。「曖昧さを具体に変換する仕組み」をプロセスに埋め込むことだ。

累積を可視化する変更ログ、〇×で仕分けるYes/Noリスト、数値で定義する非機能要件、意思決定に埋め込むペルソナ照合、即時テキスト確認。これらはすべて「曖昧さを許さない設計」の具体例だ。

そしてAIは、この「曖昧さの検出と具体化」を加速する。要件定義書の穴を洗い出し、スコープ影響を試算し、会話から決定事項を抽出する。人間が「なんとなく分かった気」になっている箇所を、AIは忖度なく「ここが曖昧です」と指摘する。要件定義のフェーズにAIを「曖昧さ検出器」として組み込むことが、現代のプロジェクト管理における強力な武器になる。

---

まとめ：要件定義の5つの罠と打ち手

罠	根本原因（認知バイアス）	今日から始める打ち手	AIの活用法
①スコープクリープ	漸進的コミットメント・拒否の心理的コスト	累積を可視化する変更ログ＋トレードオフ提示	追加要望のスコープ影響を即時試算
②MVPの解釈ズレ	抽象語の解釈拡散	Yes/Noリストで機能を物理的に仕分け	目的を軸にMVP範囲の妥当性をチェック
③非機能要件の後回し	顕著性バイアス	6カテゴリの非機能要件を数値で定義	合意されていない非機能要件を網羅検出
④ペルソナの形骸化	儀式化・意思決定との断絶	ペルソナ照合を意思決定プロセスに埋め込む	AIにペルソナを演じさせ設計を簡易チェック
⑤口約束のスコープ	記憶の再構成・自己奉仕バイアス	即時テキスト確認＋決定ログへの集約	会話ログから決定事項を構造化抽出

今日から一つだけ始めるとすれば、口頭で決まったことを「その日のうちに一文で確認メッセージを送る」習慣を勧める。最もコストが低く、最も多くの対立を未然に防ぐ。要件定義の質は、特別な才能ではなく、こうした小さな「曖昧さを残さない習慣」の積み重ねで決まる。