要件定義フェーズは順調に見えた。ビジネス部門からのヒアリングを重ね、要望をひとつひとつ丁寧に拾い上げ、要件一覧表は当初の倍近くに膨らんでいった。プロジェクトマネージャーは「ステークホルダーの声をしっかり反映しています」と報告し、経営層は満足げにうなずく。
しかし数か月後、プロジェクトは暗礁に乗り上げている。典型的なパターンとして、開発工数は当初見積りの1.5〜2倍に膨らみ、スケジュールは数か月遅延し、「優先度：高」のラベルが貼られた要件が全体の大半を占めている。テスト工程は圧縮され、Go Liveは延期か品質妥協かの二択を迫られる。経営会議で報告される「スケジュール遅延」や「追加予算要求」の裏には、しばしばこの構造が潜んでいる。何が起きたのか。
要件の膨張（Requirements Bloat）── 本来解くべき課題の範囲を超えて要件が際限なく積み上がる現象 ── が、プロジェクトを静かに、しかし確実に溺れさせたのだ。
Standish GroupのCHAOS Reportは、プロジェクトの失敗要因として要件に関する問題を長年にわたり主要因に挙げてきた (Standish Group, 2020)（※版により表現が異なるため原典で要確認）。しかし注目すべきは、要件が「不足」しているから失敗するのではないということだ。むしろ、要件が「過剰」であることが、プロジェクトを構造的に追い詰めているケースの方が多い。
以前のInsight「『通じない』が変革を止める」では、課題定義の不在がSaaS導入の泥沼を生む構造を論じた。「BABOKとは何か」では、ソリューションを決める前にニーズを定義する思考の枠組みを紹介した。本稿はその先を問う。ニーズの定義が曖昧なまま要件を積み上げると、プロジェクトに何が起きるのか。そして、要件の膨張をどう防ぐのか。
なぜ要件は膨張するのか ── 3つの構造的要因
要因① ── 「課題」ではなく「要望」を集めている
要件定義の最も根本的な問題は、出発点が間違っていることだ。
多くのプロジェクトでは、要件定義フェーズで「ビジネス部門が何をしてほしいか」をヒアリングする。営業部門は「顧客データを一覧表示したい」、経理部門は「承認フローを3段階にしたい」、マーケティング部門は「セグメント別のダッシュボードがほしい」。プロジェクトチームはこれらの声を誠実に拾い、要件一覧に加えていく。
しかしここで問われるべきは、その要望の裏にある「課題」は何かという問いだ。「顧客データを一覧表示したい」の裏には「訪問先の優先順位が分からない」という課題があるかもしれない。その課題の最適な解は、一覧表示ではなくアラート通知かもしれないし、そもそもシステム化ではなく営業プロセスの見直しかもしれない。
BABOKが「要求（Requirement）」と「ニーズ（Need）」を明確に区別しているのは、まさにこの構造を捉えているからだ (IIBA, 2015)。要求はステークホルダーが自覚している要望であり、ニーズは本人すら言語化できていない潜在的な課題だ。要求をそのまま要件にすると、課題の本質に届かない要件が増殖する。結果として、どれだけ要件を積み上げても「作ったが使われない」機能が量産される。
要因② ── 「ノー」と言えない力学が働いている
要件が膨張するもうひとつの構造的要因は、要件を却下することに対する組織的な抵抗だ。
ビジネス部門が要望を出すとき、それは部門としての意思表明だ。「この機能がないと困る」と言われたとき、プロジェクトチームが「その機能は今回のスコープに含めません」と回答するのは、政治的にリスクを伴う。とりわけ日本企業では、ステークホルダーの要望を「断る」ことは関係性の毀損と捉えられがちだ。
結果として、プロジェクトチームは安全策を取る。「優先度を下げて検討します」という回答は、実質的には「断らずに先送りする」ことを意味する。先送りされた要件は消えない。やがて「検討中」の要件がリストに堆積し、いつの間にかスコープの一部として既成事実化していく。
以前のInsight「『スポンサー不在』がプロジェクトを殺す」で論じたABCモデルが、ここでも重要になる。スコープの判断 ── 何を含め、何を含めないか ── は、プロジェクトマネージャーの権限だけでは下せない。スポンサーが「この要件はやらない」と明確に意思決定し、その判断をステークホルダーに直接伝えることで初めて、要件の歯止めが機能する。スポンサー不在のプロジェクトでは、要件の膨張を止めるブレーキが構造的に存在しない。
要因③ ── 「全部入り」が最もリスクが低いという錯覚
要件の膨張を加速させる3つ目の力学は、「要件を削ると、後で困る」という恐怖だ。
プロジェクト関係者の多くは、過去に「あの機能を入れなかったせいで、追加開発に多額のコストがかかった」という経験を持っている。この学習が、「念のため入れておこう」というバイアスを生む。要件を追加するコストは将来のどこかで発生するが、要件を削るリスクは今すぐ目に見える。行動経済学の知見を援用すれば、人間の認知は目の前のリスク回避を過大評価し、将来のコスト増大を過小評価する傾向がある (Kahneman, 2011)。
しかし現実には、「全部入り」こそが最もリスクの高い選択だ。要件が増えるほど、開発の複雑性は線形ではなく指数的に増大する。要件間の依存関係、テストケースの組み合わせ爆発、ステークホルダー間の調整コスト。Brooks (1995) が『人月の神話』で示したように、要素の追加がもたらす複雑性は線形ではない。要件を1.5倍にすれば、プロジェクトの複雑性は2倍以上になる。 この非線形性を直感的に把握することは難しく、だからこそ「全部入り」の罠にはまる。
要件の膨張は、「要望に応える誠実さ」の姿をまとって進行する。しかしその実態は、課題定義の不在、スコープ判断の回避、そしてリスク認知のバイアスが重なった構造的な問題だ。
膨張した要件がプロジェクトにもたらすもの
要件の膨張は、QCDの崩壊というプロジェクトマネジメント上の問題にとどまらない。変革プロジェクト全体の成功を蝕む、より深い影響をもたらす。
「谷」が深く、長くなる
以前のInsight「変革の『谷』を乗り越える5つのレバー」で論じた通り、変革にはJカーブの谷が必ず訪れる。要件が膨張したプロジェクトでは、この谷はさらに深く、長くなる。
理由は単純だ。機能が多ければ多いほど、現場が覚えるべき操作が増え、変更される業務プロセスの範囲が広がり、混乱期間が長期化する。「一斉展開」が変革を沈没させるのと同じ力学が、機能レベルでの「一斉投入」でも作用する。100の機能を同時にGo Liveすることは、100の変化を同時に現場に強いることだ。
加えて、膨張した要件の中には「あれば便利だが、なくても業務は回る」機能が多数含まれている。こうした機能は、Go Live直後の混乱期に現場の注意を分散させ、本当に重要な機能の習熟を妨げる。要件の膨張は、変革の焦点をぼやけさせる。 さらに、以前のInsight「『変革疲れ』が静かに組織を蝕む」で論じた通り、組織の変革吸収力には限界がある。機能過多による混乱の長期化は、変革疲れを加速させ、次の変革に対する組織の受容力をも蝕んでいく。
定着の対象が拡散する
「『プロジェクト完了＝成功』という幻想」で論じた通り、Go Liveは完了であって成功ではない。成功とは、新しい仕組みが組織に定着している状態だ。しかし、定着させるべき対象が膨大であれば、定着活動も分散する。
チェンジマネジメントのリソースは有限だ。トレーニング、コミュニケーション、チェンジエージェントの配置、フィードバック収集。これらの活動を100の機能に対して等しく行うことはできない。結果として、すべての機能が「中途半端に定着した」状態になる。全部を定着させようとして、何も定着しない。
便益実現の焦点が失われる
「『投資対効果』を語れない変革は、やがて止まる」で論じた便益実現マネジメント（BRM）── ビジネスケースで約束した便益を体系的に追跡・検証するアプローチ ── の観点からも、要件の膨張は深刻だ。ビジネスケースで約束した便益は、通常、コアとなる少数の機能によって実現される。しかし要件が膨張すると、コア機能と「あれば便利」な機能の区別が曖昧になり、便益に直結する要件がどれなのか、誰にも分からなくなる。
便益の追跡ができなければ、プロジェクトの投資対効果は検証不能になる。検証不能な投資は、やがて経営層の支持を失う。要件の膨張は、プロジェクトのQCDだけでなく、変革の持続可能性そのものを蝕んでいく。
膨張の進行は「データ」で検知できる
要件の膨張は、意識しなければ気づかないまま進行する。しかし、いくつかの先行指標を定期的にモニタリングすることで、膨張の兆候を早期に検知できる。要件総数の推移、Must have比率の変動、便益に紐づかない要件の割合、要件あたりの平均テストケース数。これらの指標を週次でトラッキングし、閾値を超えた場合にアラートを出す仕組みがあれば、プロジェクトが「溺れ始めている」ことをデータで語れる。勘と経験ではなくデータで、スコープの健全性を監視する。この視点が、膨張を「気づいたときには手遅れ」にしない唯一の方法だ。
要件の膨張を防ぐ ── スコープガバナンスの設計
「課題の再定義」を要件定義の前に置く
要件の膨張を根本から防ぐ第一の手段は、要件を集める前に「課題」を定義することだ。
BABOKの戦略アナリシス知識エリアが示すのは、プロジェクトの構想段階で「現状（As-Is）」と「あるべき姿（To-Be）」のギャップを構造的に分析し、そのギャップを埋めるためのアプローチを定義するプロセスだ (IIBA, 2015)。このプロセスを経ていれば、個々の要望が「このギャップの解消に寄与するか」という判断軸ができる。寄与しない要望は、どれほど声が大きくても「今回のスコープ外」と判断できる。
以前のInsight「なぜ日本企業には『橋渡し役』がいないのか」で論じたビジネスアナリストの機能が、ここで威力を発揮する。ビジネス部門の要望をそのまま要件に変換するのではなく、「それは本当に解くべき課題ですか」と問い返す機能が組織にあるかどうか。この機能の有無が、要件の膨張の分岐点になる。
要件に「賞味期限」と「便益リンク」を設定する
すべての要件に対して、2つの属性を付与することが有効だ。
第一に、便益リンク。 各要件が、ビジネスケースのどの便益に紐づくかを明示的に記録する。便益に紐づかない要件は、原則としてスコープに含めない。このトレーサビリティ ── BABOKが要求のライフサイクルマネジメントとして体系化している機能 ── が、要件の膨張に対する構造的な歯止めになる (IIBA, 2015)。
第二に、賞味期限。 「検討中」のまま放置される要件を防ぐため、各要件に判断期限を設定する。期限内にスポンサーがIn/Outの判断を下さなかった要件は、自動的にバックログに移管される。要件が永遠に「保留」のまま残る状態を、プロセスで防ぐ。
MoSCoW法による「やらない」の構造化
要件の優先順位付けにおいて、MoSCoW法は実務的に強力なフレームワークだ。Must have（必須）、Should have（推奨）、Could have（可能なら）、Won't have this time（今回はやらない）の4区分に要件を分類する。
この手法の核心は、「Won't have」カテゴリの存在にある。多くの優先順位付けでは「高・中・低」の3段階を使うが、「低」は「やらない」を意味しない。結果として、すべての要件が「いつかやるもの」としてスコープに残り続ける。MoSCoW法は「今回は明確にやらない」というカテゴリを正式に設けることで、スコープからの排除を意思決定として構造化する。
ただし、MoSCoW法が機能するためには、一般的な目安として、Must haveの合計がプロジェクトリソースの60%以内に収まるよう設計する規律が必要だ。Must haveが80%を超えていれば、実質的に優先順位は機能していない。Must haveの上限を設けること自体が、要件の膨張に対する最も効果的なガードレールになる。
要件の膨張を防ぐのは、より精緻な要件定義プロセスではない。「何をやらないか」を決める組織の意思決定能力だ。
実務への示唆
要件の膨張を防ぎ、プロジェクトの焦点を維持するための具体的なアクションを3つ提示する。
第一に、要件定義フェーズの冒頭で「課題定義ワークショップ」を実施する。 ビジネス部門への要望ヒアリングの前に、1時間のワークショップを設け、BABOKのコアコンセプトモデル（BACCM）の6つの問い ── 何を変えるのか（チェンジ）、なぜ変えるのか（ニーズ）、誰が影響を受けるのか（ステークホルダー）、どんな制約があるのか（コンテキスト）、何が良くなるのか（価値）、どう変えるのか（ソリューション）── を関係者全員で議論し、A3一枚の「課題定義シート」にまとめる。この6問への合意が、以降の要件定義における判断軸になる。「この要件は、合意したニーズの解消に寄与するか」── この一問で、要件の大半は自ずとふるいにかけられる。
第二に、スポンサーが「やらないリスト」を四半期ごとに承認する。 要件の追加は自然発生的に起きるが、削減は意識的な意思決定でしか起きない。既存のステアリングコミッティの冒頭10分を「スコープレビュー」に充て、スポンサーが四半期に一度、Won't have リスト（今回やらない要件）を正式に承認し、ステークホルダーに通知する仕組みを設ける。「やらない」を決めるのはプロジェクトマネージャーではなくスポンサーの仕事だ。この意思決定をスポンサーの責務として明文化することで、プロジェクトチームは安心してスコープを守れる。
第三に、要件数と便益の対応表を経営レポートに含める。 ステアリングコミッティの報告に、現在の要件総数、Must haveの比率、各便益に紐づく要件数を可視化した「要件ヒートマップ」（要件と便益の対応マトリクス）を加える。便益に紐づかない要件が全体の何%を占めているかを経営層に示すだけで、「本当にこの要件は必要か」という問いが自然に生まれる。勘と経験ではなくデータで、スコープの健全性を語る。
まとめ ── 「全部やる」は、何もやらないに等しい
要件の膨張は、プロジェクトに対する善意の集積で起きる。ステークホルダーの声に耳を傾け、要望を丁寧に拾い上げ、「できるだけ多くの期待に応えたい」という誠実さが、皮肉にもプロジェクトを溺れさせる。
しかし、すべての要件を等しく扱うことは、すべての要件を等しく中途半端にすることに他ならない。多くのプロジェクトでは、ビジネスケースで約束した便益の大部分はコアとなる少数の機能によって実現される。100の機能を60%の完成度で届けるよりも、便益の核心を担う30の機能を100%の完成度で届け、確実に定着させる方が、組織に生まれる価値は圧倒的に大きい。
課題を定義し、便益に紐づく要件を選び、「やらない」を決め、コアな変革に焦点を絞る。この「引き算の設計」こそが、変革プロジェクトの成功確率を構造的に高める。要件の膨張を防ぐことは、プロジェクト管理のテクニックではない。組織として「何を変えるか」を選び取る、戦略的な意思決定だ。
テクノロジーだけでは、組織は変わらない。そして、すべてを変えようとしても、組織は変わらない。変えるべきものを見極め、そこに集中し、定着するまで離れない。要件の海に溺れるのではなく、焦点の力で水面に浮かび上がる。引き算の勇気が、変革の焦点を研ぎ澄ます。