1.4スコープ検証と変更管理

この節では「スコープ検証とは何か」という定義ではなく、プロジェクトの現場でスコープクリープが静かに進行している兆候をどう見抜き、どの段階で・どう軌道修正するかを判断する力を扱います。スコープクリープは多くの場合、一つの大きな不正な変更ではなく、個々には些細に見える非公式な追加要望の積み重ねとして進行するため、PMが早期に兆候を察知できるかどうかが被害の大きさを左右します。

1.4.1スコープ検証（検収）の位置づけ

• スコープ検証（検収）＝完成した成果物が、合意したスコープ記述書・要求事項を満たしているかを顧客・スポンサーが正式に確認し受け入れるプロセス。品質管理（成果物が正確かを技術的に検証する内部活動）とは目的が異なり、受け入れる側の合意そのものが焦点になる。
• 品質管理は通常スコープ検証より先に行われる（技術的に正しいことを確認してから、顧客に受け入れてもらう）。品質検証を経ていない成果物をそのままスコープ検証に出すと、顧客側で不具合が見つかり検収が長引く・信頼を損なうリスクが高まる。

1.4.2スコープクリープの兆候と対処

• スコープクリープ＝統合変更管理のプロセスを経ずに、非公式・段階的にプロジェクトのスコープが拡大していく現象。単発の大きな変更要求より、「ついでにこれも」「せっかくだからこの機能も」といった個々には小さい追加が黙認される形で進行することが多く、気づいたときには当初のスケジュール・コストの前提が成立しなくなっている。
• 兆候の例＝「口頭やチャットでの非公式な追加要望が増えている」「WBS・スコープ記述書を更新しないまま作業が進んでいる」「担当者が『これくらいなら』と個別に判断して対応している」「進捗は順調に見えるのに完了予定の成果物一覧が当初より膨らんでいる」など。対処は、個々の追加要望を一旦止めて統合変更管理プロセスへ載せ直し、ステークホルダ全体でスコープの現状を再確認すること。

あなたは基幹システム再構築プロジェクトのPMで、開発の中盤に差し掛かったころ、進捗会議で各チームリーダーから「実は現場の担当者から細かい依頼がちょこちょこ来ていて、その都度対応している」という発言が相次いだとします。個々の依頼は「入力欄の順番を変えてほしい」「このメッセージの文言を直してほしい」といった一見軽微なものばかりですが、注意すべきはこれがまさにスコープクリープの典型的な兆候だという点です。表面的な進捗率（タスクの消化数）は順調に見えても、WBSやスコープ記述書が更新されないまま作業内容だけが膨らんでいる状態は、後になって「想定より工数がかかっている理由が説明できない」「テスト範囲が当初計画と合わなくなっている」といった問題として顕在化します。ここでPMが取るべき対応は、まず全チームリーダーに、非公式な追加対応をいったん停止し、これまでに個別対応した内容を洗い出して一覧化するよう指示することです。洗い出した項目は、改めて統合変更管理のプロセス（記録→影響評価→承認）に載せ直し、軽微であっても正式にスコープ記述書とWBSへの反映要否を判断します。同時に、なぜ非公式な対応が常態化したのか（変更要求のプロセスが現場にとって重すぎて敬遠されていた可能性、担当者が独断で判断できる範囲の認識が曖昧だった可能性）という根本原因も点検し、必要であれば前述したような軽微な変更向けの簡易承認フローを整備します。「個々の対応は妥当だったかもしれないが、統制されたプロセスを経ずに積み重ねたこと自体がリスクだった」という認識を関係者と共有することが、スコープクリープへの適切な対処の出発点です。

1.4.3この節のまとめ

• スコープ検証（検収）は顧客による受入れ確認で、先行する内部の技術検証（品質管理）とは目的が異なる
• スコープクリープは非公式・段階的な小さな追加の積み重ねで進行し、進捗率だけでは検知できない
• 兆候を察知したら個々の追加対応を統合変更管理プロセスへ遡って載せ直し、根本原因も点検するのが適切な対処