1.3スコープ定義とWBS

スコープマネジメントは「WBSとは何か」を暗記する分野ではなく、ステークホルダの要求に曖昧さや認識齟齬がある状況で、それをどう明文化し、作業として漏れなく分解するかを判断する力が問われます。要求が曖昧なままプロジェクトを開始すると、後になって「これは対応範囲内のはずだ」「いや対応範囲外だ」という対立が生じ、スコープクリープの温床になります。要求収集→スコープ記述書での明文化→WBSでの作業分解という一連の手順を、状況に応じて適切に実行する判断力が問われる分野です。

1.3.1要求収集とスコープ記述書

• 要求収集＝インタビュー・ワークショップ・アンケート・プロトタイピングなどの技法で、ステークホルダのニーズを明確化する活動。利害関係者ごとに期待や優先順位が異なることが多く、収集した要求同士が矛盾する場合はその調整も要求収集の一部となる。
• スコープ記述書＝プロジェクトの成果物・作業の範囲を明文化し、何が対応範囲に含まれ何が含まれないか（除外事項）を明確にする文書。「暗黙の了解」に頼らず合意した範囲を文書として残すことで、後の認識齟齬や対立を防ぐ役割を持つ。

1.3.2WBSとワークパッケージ、100%ルール

• WBS（作業分解構成図）＝プロジェクトのスコープ全体を、成果物やフェーズを軸に階層的に細分化した図。最下層の分解単位をワークパッケージと呼び、これがスケジュール作成・コスト見積り・作業割当ての基礎単位になる。成果物指向で分解するのが原則で、単なる作業手順の羅列（工程表）とは異なる。
• 100%ルール＝WBSの各階層において、子要素の合計が親要素のスコープを100%（過不足なく）カバーしなければならないという原則。子要素の合計が親要素より少なければ作業の漏れがあり、多ければスコープ外の作業が紛れ込んでいることを意味する。100%ルールを守ることで、WBS自体がスコープの網羅性を検証する手段になる。

あなたは新規ECサイト構築プロジェクトのPMで、要求収集の段階で、営業部門は「決済方法はクレジットカードだけでなくコンビニ払いにも対応してほしい」と要望する一方、開発部門は「初回リリースはクレジットカードのみとし、コンビニ払いは次フェーズに回したい」と主張しており、両ステークホルダの要求が対立している状況にあります。ここで曖昧なまま両者の言い分を併記してプロジェクトを進めてしまうと、後になって「コンビニ払いは初回リリースの対応範囲のはずだ」という認識齟齬が発生し、スコープ記述書に明文化されていない事項をめぐる対立に発展しかねません。PMとして取るべき対応は、まず両ステークホルダの背景にある目的（営業部門は顧客獲得の裾野拡大、開発部門はリリース時期の厳守）を引き出した上で、優先順位や制約条件（納期）を踏まえて調整案を提示し合意形成することです。例えば「初回リリースはクレジットカードのみとし、コンビニ払い対応は次フェーズの明示的なスコープとしてスコープ記述書に記載する」といった形で除外事項を明文化すれば、両者の期待を否定するのではなく時間軸で整理でき、後の対立を防げます。合意した範囲をWBSへ落とし込む際も、「決済機能」という親要素の下に「クレジットカード決済」というワークパッケージだけを置き、コンビニ払いを含めないのであれば、それは100%ルール上「初回リリースの決済機能スコープを正しく100%カバーしている」状態であり、コンビニ払いを含めないこと自体が誤りではありません。逆に、スコープ記述書には明記していないのにWBSにコンビニ払い対応のワークパッケージが紛れ込んでいれば、それはスコープ外の作業が混入した100%ルール違反であり、要修正のサインです。

1.3.3この節のまとめ

• 要求収集では利害関係者間の対立を明らかにし、スコープ記述書で対応範囲と除外事項を明文化して認識齟齬を防ぐ
• WBSは成果物指向で階層的に分解し、最下層のワークパッケージが見積り・進捗管理の基礎単位になる
• 100%ルールで子要素の合計が親要素を過不足なくカバーしているかを検証し、漏れとスコープ外混入の両方を判別する