PMBOKのスコープマネジメントとは？対応範囲の決め方を会計士が解説

※本記事にはプロモーション（広告）が含まれています。

「それ、やる範囲でしたっけ？」――プロジェクトの終盤でこの一言が出るとき、たいていスコープ（対応する範囲）の線引きが曖昧なまま走り出しています。本記事では、PMBOKの10の知識エリアのひとつスコープマネジメントを、プロジェクトマネジメントを学び始めた社会人に向けて解説します。読み終えると、スコープマネジメントの役割・6つのプロセス・実務で効くコツがつかめます。

分かりやすさを優先して第6版（プロセス重視）をベースに解説し、最後に第7版・第8版での位置づけにも触れます。PMBOK全体の位置づけは別記事「PMBOKとは何か」に、全体を束ねる統合マネジメントは前回の記事にまとめています。

結論：スコープマネジメントは「やること」と「やらないこと」を線引きし、範囲を守る
スコープマネジメントとは何か――「やること」と「やらないこと」を線引きする
1. ①2つのスコープ：プロダクトスコープとプロジェクトスコープ
2. ②「やらないこと」を決めるのがカギ
スコープマネジメントの6つのプロセス
WBSとスコープベースライン――範囲を「見える化」する
1. ①WBS：大きな塊を小さな作業に分解する
2. ②スコープベースライン：3点セットで基準を固定する
実務で効く2つの肝――WBSと変更管理
1. ①WBSで「抜け漏れ」と「やりすぎ」を防ぐ
2. ②変更は必ず統合変更管理を通す――スコープクリープを防ぐ
スコープマネジメントが弱いとどうなる
まとめ

結論：スコープマネジメントは「やること」と「やらないこと」を線引きし、範囲を守る

スコープマネジメントは、プロジェクトで「やること」と「やらないこと」を決め、その範囲どおりに完了させるための知識エリアです
スコープには2種類あります。プロダクトスコープ（成果物そのものの特性・機能）と、プロジェクトスコープ（それを生み出すために必要な作業）です
中身は6つのプロセス（①スコープの計画 ②要求事項の収集 ③スコープの定義 ④WBSの作成 ⑤妥当性確認 ⑥コントロール）
成果物はスコープベースライン＝「スコープ記述書＋WBS＋WBS辞書」の3点セットで、範囲の基準になります
実務で効くのは、WBSで作業を漏れなく分解することと、変更を必ず統合変更管理に通して「スコープクリープ（やることがどんどん増えること）」を防ぐことの2つです

スコープマネジメントとは何か――「やること」と「やらないこと」を線引きする

スコープマネジメント（Project Scope Management）は、プロジェクトに必要な作業を過不足なく含めることを目的とした知識エリアです。ポイントは「必要な作業だけを」という点で、やるべきことを漏らさないと同時に、余計なことをやらないことも同じくらい重要です。

①2つのスコープ：プロダクトスコープとプロジェクトスコープ

PMBOKでは「スコープ」を2つに分けて考えます。

プロダクトスコープ：完成する成果物（プロダクト・サービス）が持つ特性や機能。「何を作るか」
プロジェクトスコープ：その成果物を生み出すために実行しなければならない作業。「そのために何をするか」

たとえば社内システムを作るなら、「どんな機能を持つシステムか」がプロダクトスコープ、「設計・開発だけでなく、データ移行や利用者教育まで含めるのか」がプロジェクトスコープです。
この2つを分けて考えると、「成果物は決まっているのに作業範囲が曖昧」という食い違いに気づけます。

②「やらないこと」を決めるのがカギ

スコープでもっとも揉めやすいのは、境界線の外側です。
「システム開発はするが、既存データの移行は先方が行う」「教育は初回研修まで」――
このようにやらないこと（除外事項）を最初に明文化すると、後の「言った・言わない」を大きく減らせます。範囲を広げる方向の期待は自然に膨らむため、あえて線を引いておくことが肝心です。

業務改善の現場でも、「どこまでが今回の対応範囲か」を最初に紙一枚で握っておくだけで、後半のトラブルがぐっと減る印象です。
「やらないこと」を決めるのがポイントな気がします。
（※そのやらないことの合意は対応者だけの合意なのか、それとも関わる他のキーパーソンもそう思っているのかを見極めないと後でひっくりかえることもあるので注意が必要かも。。？）

スコープマネジメントの6つのプロセス

第6版のスコープマネジメントは、6つのプロセスで構成されます。
前半4つは「計画」、後半2つは「監視・コントロール」に属します（立上げ・実行・終結にはプロセスを持ちません）。まず一覧で全体像をつかみましょう。

プロセス	プロセス群	ひとことで言うと
① スコープ・マネジメントの計画	計画	スコープの決め方・管理の仕方を決める
② 要求事項の収集	計画	関係者のニーズを集めて文書化する
③ スコープの定義	計画	何をやり、何をやらないかを記述する
④ WBSの作成	計画	作業を管理できる大きさに分解する
⑤ スコープの妥当性確認	監視・コントロール	完成物を顧客に正式に受け入れてもらう
⑥ スコープのコントロール	監視・コントロール	範囲どおりか監視し、変更を管理する

①計画：スコープ・マネジメントの計画

最初に、スコープをどう定義し、どう管理していくかの「方針」を決めます。
要求をどう集め、WBSをどう作り、変更をどう扱うか――進め方のルールをスコープマネジメント計画書としてまとめます。作業そのものではなく、作業の「段取りの設計」です。

②計画：要求事項の収集

関係者（ステークホルダー）が本当に求めていることを聞き出し、文書化するプロセスです。
ヒアリング・ワークショップ・アンケートなどで集め、要求事項をリスト化します。ここで集めた要求は、後で要求事項トレーサビリティ・マトリックス（要求と成果物の対応表）で「どの要求がどの成果物で満たされたか」を追跡します。要求の取りこぼしは、後工程の手戻りに直結します。

③計画：スコープの定義

集めた要求を絞り込み、プロジェクト・スコープ記述書にまとめます。
ここに、成果物・作業範囲に加えて、前提条件・制約・そして除外事項（やらないこと）を明記します。「何をやるか」と同じ重みで「何をやらないか」を書くのが、この文書の勘どころです。

④計画：WBSの作成

WBS（Work Breakdown Structure＝作業分解構成図）で、大きなスコープを管理できる小さな作業単位に分解します（詳しくは次章）。スコープマネジメントの中核となる成果物です。

⑤監視・コントロール：スコープの妥当性確認

完成した成果物を、顧客やスポンサーに正式に「受け入れてもらう」プロセスです。
ここは「作った側が品質を確認する」品質コントロールとは目的が違い、「受け取る側の正式な受入」が主眼です。両者を混同すると、「動作確認は済んだのに、顧客の承認印がない」という宙ぶらりんが起きます。

⑥監視・コントロール：スコープのコントロール

スコープベースラインどおりに進んでいるかを監視し、発生した変更を管理するプロセスです。変更要求は現場の独断で受けず、必ず統合変更管理のプロセスを通します（次章で解説）。

量が増えてきたときにまとめておかないと管理しきれなくて取りこぼしてしまうことが怖いからこのプロセスを踏まえて動いたほうがいいんだろうな

WBSとスコープベースライン――範囲を「見える化」する

スコープマネジメントの成果物の中心が、WBSとスコープベースラインです。ここを押さえると、範囲がぐっと扱いやすくなります。

①WBS：大きな塊を小さな作業に分解する

WBSは、プロジェクト全体を成果物や作業のまとまりごとに階層で分解し、最下層を「ワークパッケージ」（見積り・管理ができる最小単位）まで落とし込んだものです。
原則として、分解した要素をすべて足すと元の全体に一致するように作ります（いわゆる「100%ルール」）。裏を返せば、これは「WBSに無い作業はやらない・WBSにある作業は必ずやる」という実務上の含意になり、作業の抜け漏れと、逆に「頼まれていない作り込み」の両方を防げます。

②スコープベースライン：3点セットで基準を固定する

承認されたスコープベースラインは、次の3つで構成されます。

構成要素	内容
スコープ記述書	成果物・作業範囲・除外事項・前提・制約を記した文書
WBS	作業を階層分解した構成図
WBS辞書	WBSの各要素の詳細（作業内容・担当・成果物等）を説明した文書

この3点セットが「範囲の基準」になり、以降の変更はこの基準に対して管理します。
基準がないと、そもそも「範囲が変わった」ことすら検知できません。

先方との打ち合わせや社内の上位者とのミーティングの中で、いわれたことをどんどん取り込んでいって、やることが増えたり、結局言われたことをやってなくて先方のニーズを満たせなかったり、自己満で余計なことをしてしまうことはある気がする。
初心を忘れないためにもここはまずはしっかりしておきたい。

実務で効く2つの肝――WBSと変更管理

6つのプロセスの中でも、実務で差がつくのが「WBSの作り込み」と「変更管理」です。

①WBSで「抜け漏れ」と「やりすぎ」を防ぐ

失敗するプロジェクトの多くは、着手時点で作業の洗い出しが甘く、後から「この作業が抜けていた」が続出します。WBSで作業を分解しておくと、見積り・担当割り当て・進捗管理の土台ができます。
逆方向のムダも重要で、頼まれてもいない機能を良かれと思って作り込む過剰品質も、WBSに無い作業＝やらない、という原則で抑えられます。

②変更は必ず統合変更管理を通す――スコープクリープを防ぐ

実務で最も差が出るのがここです。プロジェクトが進むと「ついでにこれも」という追加要望が必ず出ます。これを現場判断で少しずつ受け入れ続けると、時間・コスト・資源を調整しないまま範囲だけが膨張する「スコープクリープ」に陥ります。

これを防ぐには、変更要求を単体で判断せず、スコープ・コスト・スケジュール・品質への波及まで含めて評価し、承認された変更だけを実施することです。この判断は前回解説した統合マネジメントの「統合変更管理」が担い、スコープマネジメントはその結果に沿ってベースラインを更新します。

「ついでにこれも」を優しさで受け続けると、気づけば炎上案件に。
ニーズコントロールも重要で、本来の趣旨に合わない対応についてはうまく調整をしていきたい。

スコープ管理をはじめPMBOKのスキルは、身につけるほど市場で評価されやすくなります。
将来フリーランスのコンサルタントとして独立を考えるなら、案件を紹介してくれるStrategy Consultant Bankのようなサービスで、どんな案件・条件があるかを見ておくと、キャリアの選択肢が広がります（PR）。

フリーコンサル案件をみる

スコープマネジメントが弱いとどうなる

範囲の線引きが甘いと、次のような失敗が起きがちです。

スコープクリープ：追加要望を場当たりで受け続け、範囲だけが膨らんでコスト・納期が破綻する
認識の食い違い：「やってくれると思っていた」「聞いていない」の綱引きが終盤に噴き出す
受入で揉める：完成の基準が曖昧なため、「これで完了か」を巡って顧客と対立する

これは大型プロジェクトに限りません。
「家のリフォームで『ついでにここも』を重ねて予算オーバー」「資格勉強で手を広げすぎて、どれも中途半端」――こうした身近なつまずきも、スコープの線引き不足という同じ構図です。
範囲を決めて守る考え方は、日常の取り組みにも応用できます。

自分は当初の趣旨と、「今回やる範囲」と「やらない範囲」の判断軸をもっておくと動きやすいと感じます。

まとめ

スコープマネジメントは「やること」と「やらないこと」を線引きし、その範囲どおりに完了させる知識エリア
スコープはプロダクトスコープ（成果物の特性）とプロジェクトスコープ（必要な作業）の2つに分けて考える
構成は6つのプロセス（①スコープの計画 ②要求事項の収集 ③スコープの定義 ④WBSの作成 ⑤妥当性確認 ⑥コントロール）。計画プロセス群に4つ、監視・コントロールプロセス群に2つ
成果物の中心はWBSと、スコープベースライン（スコープ記述書＋WBS＋WBS辞書）の3点セット
実務の肝は、WBSで漏れとやりすぎを防ぐことと、変更を統合変更管理に通してスコープクリープを防ぐこと

なお本記事の構成は第6版のものです。第7版では原則・成果重視の構成に変わりスコープは独立した章ではなくなりましたが、「範囲を明確にして守る」という考え方は受け継がれ、第8版ではプロセスが再収録されています（版ごとの違いはPMBOKとは何かを参照）。