「あと一つだけ、この機能も入れてほしい」。その一言が、プロジェクトの命取りになる。
新しい基幹システムの要件定義が終盤に差しかかった頃、営業部門から追加要望が上がった。「顧客の購買履歴をリアルタイムで表示できるようにしてほしい」。合理的な要望だ。誰も反対しない。プロジェクトマネージャーは「対応可能」と判断し、スコープに追加した。翌週、経理部門から別の要望が入る。「請求書の自動照合機能も必要だ」。これも妥当な要求だ。さらに翌月、経営企画部門が「経営ダッシュボードとの連携」を求めてきた。一つひとつは小さく見える。しかし気がつけば、当初のスコープは1.5倍に膨張し、スケジュールは3ヶ月遅延し、追加予算の承認を取り直す事態に陥っていた。
この光景に見覚えがあるだろうか。
PMI（Project Management Institute）の調査「Pulse of the Profession」によれば、プロジェクトの約半数がスコープクリープ（要件の際限なき膨張）を経験しているとされる (PMI, 2021 )。Standish Groupの長年にわたる追跡調査「CHAOS Report」は、プロジェクトの成功率がわずか30%台にとどまることを繰り返し示してきたが、その失敗要因として要件の不安定さとスコープの膨張は常に上位に挙がる (Standish Group, 2020)。スコープクリープは、プロジェクトマネジメントの世界で最も広く知られた失敗パターンでありながら、最も改善されていない問題の一つだ。
なぜ、これほど知られた問題が繰り返されるのか。本稿では、スコープクリープを個人の管理能力の問題ではなく組織の構造的な問題として捉え直し、データに基づく要件管理の設計を論じる。
なぜ要件は膨張するのか ── 3つの構造的原因
スコープクリープは、プロジェクトマネージャーの管理力不足として語られがちだ。しかし現実には、個人の努力では抗えない構造的な力学が要件の膨張を駆動している。
原因① ── 「合理的な追加」の積み重ねという罠
スコープクリープの厄介さは、追加される要件の一つひとつがそれ自体としては合理的であることだ。顧客の購買履歴をリアルタイムで見たい。請求書の照合を自動化したい。経営ダッシュボードと連携させたい。いずれも「あれば便利」どころか「なければ困る」と感じられる要望だ。
問題は、個々の追加要件を承認する判断と、プロジェクト全体のスコープを制御する判断が別々の文脈で行われていることにある。現場の要望は業務の文脈で語られ、その妥当性は業務の論理で評価される。しかし、その要望がプロジェクト全体のスケジュール、予算、技術的整合性にどれだけの影響を及ぼすかは、業務の文脈からは見えない。
Brooks (1995) が『人月の神話』で描いた「セカンドシステム効果」── 最初のシステムで我慢した機能を次のシステムに全部盛り込もうとして過剰設計に陥る現象 ── は、まさにこの力学の古典的な記述だ。以前のInsight「『投資対効果』を語れない変革は、やがて止まる」で論じた通り、変革施策のROIを可視化しなければ投資判断は歪む。スコープの追加も同じ構造だ。追加要件の「便益」は語られるが、「コスト」は語られない。 便益だけを見て承認を重ねれば、スコープは必然的に膨張する。
原因② ── ステークホルダーの「窓」が開くタイミング
要件定義フェーズは、ステークホルダーにとって自部門の要望をプロジェクトに反映できる数少ない機会だ。次にいつこの「窓」が開くかわからない。だからこそ、この機会に可能な限り多くの要望を盛り込もうとする力が働く。
以前のInsight「『関係者の地図』なき変革は漂流する」で論じたステークホルダーマッピングの不在は、この問題を悪化させる。誰がどんな期待を持ち、どんな影響力を持つかが可視化されていなければ、声の大きいステークホルダーの要望が優先され、声の小さい ── しかしプロジェクトの成否に重要な ── ステークホルダーの要件は後から「漏れ」として追加される。結果として、要件定義が終わった後にも追加要件が次々と発生する。
この力学の根底にあるのは、各部門がプロジェクトを「自部門の課題を解決する手段」として捉えていることだ。プロジェクトの全体最適ではなく、部門最適の視点から要件が提出される。ビジネスアナリシスの知識体系であるBABOKが「要求のライフサイクルマネジメント」を独立した知識エリアとして体系化しているのは (IIBA, 2015)、まさに要件が「定義した時点で完了」ではなく、プロジェクトの全期間にわたって変化し続ける生き物であることを前提としているからだ。
原因③ ── 「断れない」構造
追加要件を提出するのは、多くの場合、プロジェクトのスポンサーに近い立場のビジネス部門だ。プロジェクトマネージャーやシステム部門にとって、ビジネス部門の要望を「断る」ことは政治的リスクを伴う。「現場の声を聞かない」「柔軟性がない」という評価は、プロジェクトへの協力を失わせかねない。
以前のInsight「『スポンサー不在』がプロジェクトを殺す」で論じた通り、変革スポンサーのアクティブな関与がプロジェクトの成否を左右する。しかし皮肉なことに、スポンサーの関与が「追加要件の承認」として現れた場合、プロジェクトチームはそれを拒否しにくい。スポンサーが「この機能は絶対に必要だ」と言えば、それがスコープ外であっても、チームは対応しようとする。
スコープクリープは、意志の弱さから生まれるのではない。「合理的な追加」「機会の希少性」「断れない力学」という三つの構造的な力が、プロジェクトのスコープを内側から膨張させている。
スコープクリープが組織に与える「見えないコスト」
スコープクリープの直接的な影響 ── スケジュール遅延と予算超過 ── は認識されやすい。しかし、より深刻なのは見えにくいコストだ。
第一に、品質の劣化と技術的負債の蓄積。 追加された要件を限られた時間と予算の中で実装しようとすれば、テストは圧縮され、設計の整合性は妥協される。「とりあえず動く」コードが量産され、技術的負債として蓄積する。Go Live後に不具合が頻発し、現場は「新しいシステムは使いにくい」と感じ、定着が遅れる。変革のJカーブの谷は、スコープクリープによって不必要に深く、長くなる。以前のInsight「プロジェクトは『終わり方』で決まる」で論じたクローズフェーズの品質が、構造的に毀損される。
第二に、チームの疲弊。 膨張したスコープに対応するために、プロジェクトメンバーは残業を重ね、モチベーションが低下する。以前のInsight「『兼務プロジェクト』が生む静かな失敗」で論じた通り、多くのプロジェクトメンバーは既存業務との兼務だ。スコープの膨張は、すでに限界に近い兼務メンバーの負荷をさらに押し上げ、離脱やバーンアウトのリスクを高める。
第三に、次のプロジェクトへの不信。 スコープクリープで苦しんだプロジェクトの記憶は、組織に残る。「またあの繰り返しになるのでは」という警戒が、次の変革プロジェクトへの協力を鈍らせる。以前のInsight「『変革疲れ』が静かに組織を蝕む」で論じた変革疲れの蓄積に、スコープクリープは直接的に寄与している。
データで「断る」設計 ── 要件管理の再構築
スコープクリープを防ぐ鍵は、「断る勇気」ではない。「断る根拠」を組織の仕組みとして設計することだ。ここにデータマネジメントの視点が活きる。
変更影響の定量化 ── 「この追加はいくらか」を即座に示す
追加要件が上がったとき、多くのプロジェクトでは「対応できるか／できないか」という二択で議論される。しかし本来問われるべきは、「この追加が、スケジュール・予算・品質・他の要件にどれだけの影響を与えるか」だ。
PMBOKが定義する統合変更管理プロセスは、変更要求に対して影響分析を行い、承認・却下・延期を判断する仕組みを体系化している (PMI, 2021)。この仕組みが形骸化する原因は、影響分析が定性的な「感覚」で行われていることにある。「たぶん2週間くらいで対応できる」「大きな影響はないと思う」── この曖昧な見積もりが、追加の承認を容易にしている。
データに基づく影響分析とは、追加要件ごとに「工数（人日）」「スケジュールへの影響（日数）」「他の要件との技術的依存関係」「テスト工数の増加」を定量的に算出し、累積的な影響をダッシュボードで可視化することだ。追加要件の一つひとつは小さくても、累積効果は大きい。この累積を「見える化」することが、合理的な判断の基盤になる。
優先順位のデータ化 ── MoSCoW を「感覚」から「基準」へ
要件の優先順位付け手法として広く知られるMoSCoW法（Must / Should / Could / Won't）は、概念としては明快だが、実践においては各ステークホルダーが自部門の要件をすべて「Must」に分類するという問題が起きる。全員が「必須」と主張すれば、優先順位は機能しない。
この問題を解決するには、優先順位の判断基準を事前に合意し、データで裏付けることが必要だ。たとえば、「この要件が実装されない場合のビジネスインパクト（売上損失、業務効率低下、法的リスク）」を定量的に評価し、インパクトの大きさで順位をつける。定量化が難しい要件については、複数のステークホルダーによる重み付け投票（Weighted Scoring）を行い、属人的な判断を排除する。
勘と経験ではなくデータで優先順位を語る。 これは「データドリブン経営」の原則を、要件管理という具体的な意思決定場面に適用したものだ。
変更予算（Change Budget）の事前確保
プロジェクト計画の段階で、スコープの変更に対応するための変更予算を明示的に確保するアプローチが有効だ。PRINCE2はこの概念を「Change Budget」として正式に体系化しており、プロジェクトボードが事前に承認した変更対応枠の中でプロジェクトマネージャーが迅速に判断できる仕組みを設計している (Axelos, PRINCE2)。たとえば、全体予算の10〜15%を「変更対応枠」として事前に設定し、その枠内であれば迅速に追加要件を承認できる仕組みにする。枠を超える変更は、スポンサーによる正式な再承認を必要とする。
この設計の効果は二つある。第一に、追加要件が「タダ」ではないことをステークホルダーに認識させる。変更予算の消費状況を可視化すれば、「まだ余裕がある」のか「もう枠を使い切った」のかが一目でわかる。第二に、プロジェクトマネージャーが「断る」のではなく、仕組みが「制約する」構造を作れる。個人の政治的判断ではなく、組織として合意したルールに基づいて変更を管理する。
スコープを守るのは、プロジェクトマネージャーの「意志の力」ではなく、影響を定量化し、優先順位をデータで裏付け、変更の枠を事前に設計する「仕組みの力」だ。
実務への示唆
スコープクリープを「仕方ないもの」から「管理可能なもの」に変えるために、明日から始められることがある。
第一に、次のプロジェクトのキックオフで「変更管理ルール」を合意することだ。 追加要件が発生した場合のプロセス ── 誰が影響分析を行い、誰が承認し、どの基準で判断するか ── をプロジェクト憲章に明記する。ルールが存在しなければ、すべての追加要件は「なし崩し」で承認される。ルールの存在自体が、膨張への最初の防波堤になる。
第二に、要件の「凍結点（Baseline）」を明示的に設定し、凍結後の変更を定量的に追跡することだ。 要件定義の完了時点でベースラインを確定し、それ以降に追加・変更された要件の件数、累積工数、スケジュール影響をダッシュボードで週次追跡する。具体的に追跡すべき指標は、ベースライン後の変更要求件数（累積）、変更に費やされた工数の累積（人日）、変更予算の消化率（%）、そして変更起因のスケジュール遅延日数だ。この4指標を一枚のダッシュボードに並べるだけで、「小さな追加の積み重ね」が全体に与えるインパクトを、ステークホルダー全員が認識できる。
第三に、スポンサーを「スコープの守護者」として巻き込むことだ。 スコープクリープの最大の推進力はステークホルダーからの追加要求であり、それを制御できるのはスポンサーだけだ。スポンサーに対して、変更影響のデータを定期的に報告し、トレードオフの判断を求める。たとえば「経営ダッシュボード連携を追加する場合、工数は+40人日、納期は3週間遅延します。代わりに、Phase 2に送れる要件はこの3件です」── この選択肢をデータとともに提示すれば、スポンサーは「すべて入れろ」ではなく「優先順位をつけよう」と判断できる。Prosci のADKARモデル (Hiatt, 2006) で言えば、スポンサー自身がスコープ管理の重要性をAwareness（認知）し、トレードオフの判断を自ら引き受けるDesire（意欲）を持つことが出発点だ。その一言が、組織全体のスコープ管理の文化を変える。
まとめ
スコープクリープは、プロジェクトマネージャーの管理力の問題ではない。合理的に見える追加要件が、構造的な力学によって積み重なり、プロジェクト全体を沈没させる組織の問題だ。
一つひとつの追加要件は小さい。しかし、その累積は致命的になり得る。水面がじわじわと上昇し、気づいたときにはプロジェクトが水没している ── スコープクリープとは、そういう種類の脅威だ。
テクノロジーだけでは、組織は変わらない。同様に、プロジェクト管理のフレームワークだけでは、スコープクリープは防げない。変更の影響をデータで定量化し、優先順位を合意された基準で判断し、スポンサーがトレードオフの責任を引き受ける。仕組みと文化の両面で、「断る力」を組織に実装する。 それが、プロジェクトを溺れさせない唯一の方法だ。
変革のJカーブの谷を越えるためには、プロジェクトが本来の目的に集中し、限られたリソースを最も重要な要件に注ぎ込む必要がある。スコープを守ることは、制約ではない。プロジェクトの成果を最大化するための、最も重要な意思決定だ。