スコープマネジメント 【scope management】

概要

プロジェクトの目的や利害関係者の要求、予算や期間、人員などの制約に基づいて、初期の計画段階で「何を作るのか」「何をやるのか」「どこまでやるのか」といった範囲（scope）をスコープ記述書などの形で定義する（スコープ計画）。

プロジェクト全体のスコープの概要が決まったら、これを成果物や対応するタスクに分解してスケジュールや組織体制を策定する（スコープ定義）。プロジェクトの進行中は、各タスクで生み出される成果物がスコープに適合しているかを確認する（スコープ検収）。進行途上で初期の計画通りに進まないことが分かった場合は成果物や作業の見直しを行う（スコープコントロール）。

プロダクトスコープ （product scope/成果物スコープ）

プロジェクト全体を通じて、また、途中の各段階で「何を作り出すのか」を定義したものを「プロダクトスコープ」（product scope）あるいは「成果物スコープ」という。スコープ計画ではまず開発すべきシステムやプログラム、設計文書などの成果物について定義を行い、発注者などの利害関係者で合意と共有が行われる必要がある。

プロジェクトスコープ （project scope/作業スコープ）

プロジェクトを構成する各タスクで「何を行うのか」を定義したものを「プロジェクトスコープ」（project scope）あるいは「作業スコープ」と呼ぶ。プロダクトスコープを元に、成果物を生み出すために必要なタスクを洗い出し、WBS（Work Breakdown Structure）などの形で体系化する。

スコープコントロール （scope control/スコープ変更管理）

プロジェクトの進行途上で当初の計画通りに進まない、あるいは進める必要がないことが判明した場合に、成果物や作業の追加や削減、変更を行うことを「スコープコントロール」（scope control）あるいは「スコープ変更管理」（scope change control）という。

例えば、連携を予定していた外部のオンラインサービスが廃止となり、連携機能が不要になったといった場合、この機能に関連する成果物と作業をスコープから削除し、予算やスケジュール、人員の配置なども再定義する変更が行われる。

変更点や変更後のスコープは文書化してプロジェクト内および利害関係者で共有する必要があり、これが行われず「なし崩し」的にスコープが変化（大抵の場合は要件の肥大化）してしまう状態を「スコープクリープ」（scope creep）という。