スコープマネジメントとは?
スコープ(scope)は、プロジェクトが生み出す成果物と、そのために行う作業の範囲です。スコープマネジメントは、その範囲を決め、関係者と合意し、勝手に広がったり抜けたりしないように管理することを指します。
スコープには2つの意味があります。1つはプロダクトスコープで、成果物が持つ機能や特性です。もう1つはプロジェクトスコープで、成果物を作って引き渡すために必要な作業の全体です。たとえば「予約アプリ」の機能一覧はプロダクトスコープです。その設計・開発・試験・研修・移行の作業は、プロジェクトスコープにあたります。
目的は、作るべきものの抜けを防ぎ、頼まれていないものを作らないことです。どちらも、コスト・スケジュール・品質に直結します。
スコープマネジメントはどんな流れで進む?
2026年7月からの ECO で、Process タスク2は「プロジェクトのスコープを作り、管理する」です。イネーブラーは3つだけで、定義する・関係者の合意を得る・分解するです。前後の段階も含めると、流れは次のようになります。
- 1
要求事項を集める
関係者のニーズを引き出す
- 2
スコープを定義する
含めるもの・含めないものを書く
- 3
関係者と合意する
スポンサー・顧客の承認
- 4
分解する
WBS やバックログに落とす
- 5
受け入れと管理
妥当性確認と変更管理
当サイトの整理。アジャイルでは反復ごとに回る
最初の「要求事項を集める」は、スコープの材料をそろえる段階です。集め方は要求事項の収集方法で扱います。
最後の段階では、完成した成果物を顧客が受け入れるかを確かめます。品質管理との違いはスコープの妥当性確認で解説しています。途中の変更は、変更管理の手続きで扱います。
PMBOKの6つのプロセスとは?新ECOとどう対応する?
PMBOK ガイド第6版は、スコープ・マネジメントを6つのプロセスで説明していました。旧来の教材の多くも、この順番で書かれています。新ECOとの対応を表にまとめます。
| PMBOK第6版のプロセス | 何をするか | 新ECO(2026年版)での位置 |
|---|---|---|
| スコープ・マネジメントの計画 | スコープの決め方と管理の仕方を計画する | タスク1(統合された計画)の一部 |
| 要求事項の収集 | 関係者のニーズや条件を集めて文書にする | タスク2の土台(品質の要求はタスク7) |
| スコープの定義 | 含めるもの・含めないものを記述書に書く | タスク2「スコープを定義する」 |
| WBSの作成 | 成果物を管理できる大きさに分解する | タスク2「スコープを分解する」 |
| スコープの妥当性確認 | 完成した成果物を顧客が正式に受け入れる | タスク7の品質レビュー、タスク10の完了承認などに分散 |
| スコープのコントロール | スコープの状態を監視し、変更を管理する | Business Environment タスク3(変更の管理) |
2021年版の ECO では、スコープのタスクに3つのイネーブラーがありました。要求事項を決めて優先順位を付ける、スコープを分解する(WBS・バックログなど)、スコープを監視し妥当性を確認する、です。2026年版では、「定義する」と「関係者の合意を得る」が前に出ています。
新しい ECO は、プロセスの名前ではなく、プロジェクト・マネジャーがすべき仕事で出題範囲を示しています。名前の暗記より、場面ごとに「いま何をすべきか」を判断できるかが問われます。
スコープ記述書には何を書く?
予測型のプロジェクトでは、定義したスコープをスコープ記述書にまとめます。プロジェクト憲章より詳しく、作業の判断に使える細かさで書きます。
| 項目 | 内容 | 書き方のコツ |
|---|---|---|
| プロダクトスコープの記述 | 成果物の機能・特性 | 要求事項とひもづけて書く |
| 主要な成果物 | 引き渡すもの(システム、文書、研修など) | 成果物ごとに完成の状態を書く |
| 受入基準 | 成果物が受け入れられる条件 | 測定できる形にする |
| 除外事項 | このプロジェクトではやらないこと | 誤解が起きそうなものほど明記する |
| 前提条件 | 正しいと仮定していること | 崩れたらどうなるかも考える |
| 制約条件 | 動かせない条件(期限・予算・規制) | 誰が決めた制約かも残す |
見落とされがちなのが除外事項です。「データ移行は含まない」「旧システムの撤去は別案件」などと書いておきます。書かないと、後で「当然やってくれると思っていた」という対立が起きます。スコープが知らないうちに広がる問題は、スコープクリープの記事で詳しく扱います。
関係者とスコープにどう合意する?
スコープは、書いただけでは決まりません。スポンサーと主要な関係者が内容を理解し、承認して初めて基準になります。合意を取るときのポイントは次のとおりです。
- 利害の違う関係者を同じ場に集める:部署ごとに個別に合意を取ると、部署間の食い違いが後で表に出ます。
- 除外事項と受入基準を必ず読み合わせる:機能の一覧だけでなく、「やらないこと」と「何をもって完成とするか」で認識をそろえます。
- 対立したら目的に立ち返る:どちらの要望が、憲章の目的と成功基準に効くかで議論します。決まらなければスポンサーが判断します。
- 承認を記録に残す:承認された版をスコープ・ベースラインとし、以後の変更は変更管理の手続きで扱います。
アジャイルでも合意は必要です。違いは、合意の対象が「全機能の一覧」ではなく、ビジョン・優先順位の付け方・完了の定義(DoD)になることです。何を作るかの細部は、プロダクトオーナーが関係者と相談しながら決めていきます。
スコープはどう分解する?
合意したスコープは、見積もりと担当の割当てができる大きさまで分解します。
予測型では WBS(ワーク・ブレークダウン・ストラクチャー) を使います。成果物を上から下へ分け、最下層のワークパッケージで見積もりと管理を行います。作り方と100%ルールはWBSの作り方で詳しく解説しています。
アジャイルでは、エピック→フィーチャー→ユーザーストーリーのように分け、プロダクトバックログに並べます。上位の項目ほど粗く、近いうちに着手する項目ほど細かくします。
予測型
- いつ決めるか計画の初期にまとめて
- 主な成果物スコープ記述書・WBS・WBS辞書
- 変更の扱い変更要求と承認で変える
- 受け入れの場スポンサー・顧客の承認
アジャイル
- いつ決めるか反復ごとに少しずつ
- 主な成果物プロダクトバックログ
- 変更の扱いバックログの並べ替えで吸収
- 受け入れの場スプリントレビューでの確認
当サイトの整理
アジャイルでスコープが「変えやすい」のは、時間とコストを先に固定し、その中で価値の高い順に作る仕組みだからです。何でも追加できるという意味ではありません。追加すれば、優先度の低い項目が後ろに回ります。
PMP試験ではスコープマネジメントがどう問われる?
典型的な場面と、考え方の筋を挙げます。
- 関係者が直接チームに機能追加を頼んだ:チームがそのまま作るのは誤りです。予測型なら変更の手続きへ、アジャイルならプロダクトオーナーがバックログで判断します。
- 関係者の間でスコープの理解が違う:記述書の除外事項と受入基準を確認し、関係者を集めて合意し直します。
- 作業が漏れていた:WBS やバックログに無い作業は、スコープに入っていない可能性があります。影響を分析して、変更として扱います。
こうした判断は、無料模試30問の Process 問題で確かめられます。
確認問題1
除外事項をめぐる食い違い
(当サイトの独自問題)社内システムの更新プロジェクトの終盤、利用部門から「旧システムのデータ移行が入っていない」と苦情がありました。スコープ記述書では、データ移行は除外事項として記載され、利用部門の部長も承認しています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:2。合意済みのスコープを根拠に状況を説明します。移行の必要性があるなら変更要求として影響を分析し、決められた手続きで判断します。
1:承認の無いスコープ追加になります。3:変更の手続きを経ずに約束しており、コストとスケジュールへの影響も確かめていません。4:ニーズそのものを検討せずに打ち切っており、価値の観点が欠けています。
確認問題2
アジャイルでの機能追加の依頼
(当サイトの独自問題)スクラムで開発中のアプリについて、営業部長が開発者に直接「次のスプリントでクーポン機能を入れてほしい」と頼みました。スプリントプランニングは、まだ行われていません。プロジェクト・マネジャー(サーバント・リーダー)が次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:3。アジャイルでは、何を作るかの優先順位はプロダクトオーナーがバックログで決めます。依頼はバックログ項目として持ち込み、価値に照らして並べてもらいます。
1:プロダクトオーナーを飛ばして、優先順位が決まってしまいます。2:スプリントの範囲外の要望は、正式な変更管理を経ずにバックログで扱えます。4:関係者の要望を受け止める機会を失います。
確認問題3
見積もりに使えないWBS
(当サイトの独自問題)予測型のプロジェクトで、チームが作った WBS の最下層が「設計」「開発」「試験」の3つしかありません。どれも数か月の作業で、担当も複数の部署にまたがっています。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解:4。最下層(ワークパッケージ)は、見積もり・担当の割当て・進捗の管理ができる大きさにする必要があります。作業を知るチームと一緒に分解すると、抜けも見つかります。
1:粗すぎる単位では、見積もりの根拠が弱くなります。2:分解しないまま作ったスケジュールは当てになりません。3:ワークパッケージが粗いまま割り当てると、責任の所在があいまいになります。