スコープのマネジメントの用語をゆるく説明｜PMP試験用語2

スコープという言葉には「範囲」という意味があり、PMBOKガイドでは「範囲」の意味で使っています。

プロジェクトマネジメントでスコープとは、「仕様」まで含めた「作業範囲」や「責任範囲」を表します。

つまり、顧客要求を把握し、それに応じた適切な成果物を提供するという領域になります。

そんなスコープのマネジメントに関し、次の用語をざっくばらんに説明します。

• 要求のマネジメント
• ユーザーストーリー
• バックログの優先順位付け
• スコープベースライン
• WBS
• スコープクリープ

実際の試験用語として厳密に参照されたい場合は、PMPOKや参考書をご確認ください。

要求のマネジメント

要求の管理とは?

要求の管理とは、ざっくりと言うと

「お客さんの『こうしてほしい！』をちゃんと集めて、漏れなくブレずにプロジェクトに反映させる技術」

いわば、恋人とのデートプランを立てるようなもの。

「海に行きたい」「美味しいランチが食べたい」「日焼けはNG」
――これ、全部「要求（要件）」です。

要求のマネジメント5ステップ（PMBOK的な説明）

1. 要求の計画（Plan Requirements Management）
   　どうやって要求を集めて、記録して、管理するかの決めルール。
   　👉「デートの前に、希望をLINEで聞いてとこ」みたいなノリです。
2. 要求の収集（Collect Requirements）
   　客さん、ユーザー、ステークホルダーなどから要求を聞き出します。
   　👉まるで「彼女の友達にも調査して、理想のサプライズを探す」感じです。
3. 要求の分析（Define Scope）を集めた
   　要求をもとに、どこまでプロジェクトでやるかを決定します。
   　👉「海に行って、水族館はOK。夜のバーベキューは今回は無理だな…」みたいに調整します。
4. 要求の文書化（Create Requirements Documentation）
   　要求を正しく書面に残します。その後「言った・言わない」にならないように
5. 要求のトレーサビリティ・マトリクス（Requirements Traceability Matrix）作成
   　要求がどこでどう生きて来るか追跡できるように

要求管理でありがちなNG集（あるある）

• 「あ、それ言ってなかったっけ？」
  　→要求の収集ミス。
  　👉デート中「やっぱ夜景も見たかったな…」って言われて真顔になる。
• 「そんな要求なかったよね？」
  　→文書化不足。
  　👉「いやいや、絶対言ってたって！証拠はLINE！」みたいな論争に。
• 「この機能、誰の要求だけ？」
  　→トレーサビリティなし。
  　👉「なんで突然ビーチバレーの道具買ったんだっけ…？」状態。

PMP試験でのポイント

• ステークホルダーとの関係性を重視！要求はあくまでも期待を反映しているので、信頼関係が命。
• 変更管理とセットで理解しよう！要求は変わる。いやマジで変わる。恋人のような気持ち。
• ツールや技法もチェック
  　→インタビュー、ワークショップ、ブレスト、プロトタイピングなど

要求の管理は、「ステークホルダーが何を望んでいるか」を把握し、それをブレズにプロジェクトに反映させるための仕組みです。恋人とのデートですら、ちゃんと管理しないと「機嫌が悪くなってしまう（=プロジェクト失敗）」んです。予算何億のプロジェクトで、要求の管理をやらない手はない！

ユーザーストーリー

ユーザーストーリーとは？

ユーザーストーリーとは、ざっくりと言うと、

「ユーザーの立場から、“超シンプルに書いた短い物語”」

です。

これは、芥川龍之介でも村上春樹でもなく、
もっと軽くて実用的で、「つぶやきレベルの要件定義」のようなもの。

たとえ話：ラーメン屋アプリの場合

あなたは、ラーメン屋さんの注文アプリを作るプロジェクトのPM。

ここに出てきたユーザーストーリーがこれ：

「私は客として、並ばずに注文できるように。そうすればスムーズにラーメンを食べられるからだ。」

これだけ！
小説の一節、Twitterで言えちゃうレベルです。

ユーザーストーリーのテンプレ

私は（誰）として、（何を）したい。そうすれば（なぜ／何の価値）

この3つが入っていればOK！

要素	意味	例（ラーメンアプリ）
誰（Who）	どのユーザーですか？	「私は客として」
何を（What）	したい？	「並ばずに注文したい」
どうして（Why）	なぜそれが大事ですか？	「スムーズにラーメンを食べたい」

PMP試験として理解すべきことは

• アジャイルでの要求の表現方法
• 製品バックログアイテムのひとつ
• プロジェクトの範囲をスコープではなく価値で定義する考え方

先に「ユーザーが本当に欲しいもの」にフォーカスした手法です。

ユーザーストーリーは、ユーザー視点で価値に重点を置いた要求の表現方法。

堅実な「仕様書」ではなく、「ユーザーの声」をラフに形にするものです。

バックログの優先順位付け

PMP試験のアジャイル分野で出てくる「バックログの優先順位付け（Backlog Prioritization）」って、シンプルに聞こえるけど、いざ出題されると「え、どの順でやるのが正解!?」って悩ましいです。

まず「バックログ」ってなに？

まず「バックログ」とは簡単に言うと、

「やりたいこと全部書いている『やることリスト』」

でもただのリストじゃありません。
プロダクトオーナーの夢と妄想と現実が詰まった、無駄なToDoリストです。

バックログの優先順位とは？

バックログの優先順位とは・・

「この中で、どれからやる？何を一番大事にする？」を決めること。

ただし、決める際は「なんとなく」や「思いつき」は禁止です。

ハンバーガー屋でのバックログ考察

あなたがハンバーガー屋をオープンするプロジェクトのPMだとします。
バックログにはこんな項目が…

• チーズバーガーを追加する
• モバイル注文に対応する
• ハンバーガーの箱を金ピカにする
• フライドポテトにトリュフオイルをかける
• 期間限定でベーコン20枚バーガーを出す

これ、どれからやりますか？

見た目のインパクト？売上？コスト？お客さんの要望？
ここで優先順位付けのテクニックが登場します！

主な優先順位付けの考え方

1.ビジネス価値（ビジネスバリュー）
「それで売上や顧客満足がグンと上がる？」
👉 例：モバイル注文対応→ 消費性爆上がり！

2.リスクと機会（リスクの軽減 / 機会の実現）
「今やっとあと後々助かる？」
👉 例：モバイル注文の技術を今頑張って、他店舗展開が楽に！

3.依存関係（Dependency）
「これを先にやらないと、他のが進まない？」
👉 例：パティの規格変更がわら終わらず、20枚バーガー作れない…

4.コストと労力（労力 / コスト）
「めっちゃ時間かかる？すぐ終わる？」
👉金ピカの箱→コスパ最悪

---

優先順位の現場あるある

• 開発者：「やっぱ最初に金ピカの箱やっときましょ！」
  　→ 見た目は大事だけど…誰が買うんやそれ（笑）
• ステークホルダー：「全部優先度“最高”で」
  　→ はい出ました。「全部大事」は「何も決まってない」と同義です！
• プロダクトオーナー：「とりあえずカッコいいのから」
  　→ 感情も大事だけど、価値と根拠で語ろう！

優先順位付けは、「最も価値があるものを、最も早く届ける」ための技術。
アジャイルの価値観とズレたらNGです！

スコープベースライン

「スコープ・ベースライン（Scope Baseline）」も、PMP試験でバッチリ出るポイントです。

スコープ・ベースラインとは？

一言でいうと…

「プロジェクトで“何を作るか”の公式な決定版メニュー表！」

です。

あなたが「結婚式のウェディングケーキを作るプロジェクト」のPMだったとして、

• 「3段重ね」
• 「チョコレート味」
• 「フルーツ乗せ」
• 「名前入りプレート」

と決めたら、それがスコープ・ベースライン。
この内容は「そのうちブレないように」「勝手に変わらないように」 固定しておく、というわけです。

内容は3つのセットメニュー！

スコープ・ベースラインは3点セットで構成されます：

要素	概要	例（ウェディングケーキ）
スコープ記述書	何をやる／やらないかの詳細説明	「3段」「チョコ」「名前入り」など詳細に書いている
WBS（作業分解構成図）	どの作業で分かれるか、ツリー構造で分解	材料準備→スポンジ焼く→フルーツカット→デコる…
WBS辞書	各WBS要素の説明（仕様書的なやつ）	「スポンジはココア味」「フルーツは季節のもの」など細かいところ

ケーキ屋で例えるスコープ・ベースライン

これを想像してみてください:
あなたがお客さんにケーキを届けるとして、口頭だけで「いい感じのケーキで！」って言われたらどうですか？

• あなた「３段で行きますね！」
• 客「いや、1段って言いましたけど？」
• あなた「チョコ味にしておきました！」
• 客「バニラって言ったじゃん！」

＼修羅場／

このような事態を防ぐために「これが公式のケーキ仕様です！」とする文書が、スコープ・ベースラインなのです。

なぜ「ベースライン」なの？

「ベースライン」とは、**比較や変更管理のための「ものさし」**のこと。

例：

「スコープ・ベースは『3段ケーキ』だったけど、2段に変更するなら、ちゃんと変更管理プロセスずっとね！」

勝手に変更されたら、ケーキは倒れるし、予算はオーバーするし、嫁は泣きます。

あるある・やってはいけない例

• 「ちょっとだけトッピング増やしてもバレないでしょ」
  　→ 小さな「スコープクリープ」が命取り！
• 「この変更、口頭で伝えたんで大丈夫っす！」
  　→ どこにも記録されてない！？PMP的にはアウト！
• 「スコープ・ベースラインって、どっかにあった気がする…」
  　→ ベースラインが迷子になると、プロジェクトも迷子。

PMP試験として重要なポイント

• スコープ・ベースラインはプロジェクト・経営計画書一部
• 変更したいときは統合変更管理プロセスを必要あり
• スコープ管理において、「何をやる・やらない」を線引きするための核
• WBSとのが、**「範囲の定義→分解→管理」**という流れをしっかりと保持して強い！
• 「やること・やらないこと」を明文化！
• WBSとセットで、構造的に管理！
• 勝手な変更はNG！変更管理プロセスを通そう！
• ケーキだって仕様通りに作らないとブーケが飛んできます！

WBS

PMP試験ではおなじみのWBS（Work Breakdown Structure）。ただ、名前からして「なんだか機械的で、まるでExcelとらめっこしそうなやつ…」という印象を持ちがち。でも大丈夫。 今回は、WBSを「笑いとスイーツ」で優しく分解してみましょう！

WBSってなに？

ざっくりと言うと、

「プロジェクトでやることを、漏れ漏れなく、全部分けてツリー一覧表」

です。WBSは「お菓子作りレシピの分解図」みたいなもの！

ケーキ作りプロジェクトで例えるWBS

あなたが「誕生日ケーキを作るプロジェクトのPM」とします。

このとき、WBSはこう書かれます：

0.プロジェクト目標
「誕生日ケーキを完成させる」

1.材料の準備
卵を買う
小麦粉を計る
生クリームを冷やしやすい

2. ケーキ本体の作成
スポンジを焼く
スポンジを冷ます
デコレーションする

3. ケーキの納品
写真を撮る
ケーキを箱詰めする
誕生日パーティー会場へ移動

WBSとは「仕事を分けて、箱にしまう技術」

WBSでは、プロジェクトを「作業のかたまり（ワークパッケージ）」に分けていきます。

• 「材料買う」っていう箱
• 「焼く」っていう箱
• 「届ける」っていう箱

この箱たちを上から順に、徐々に細かく分けていくことで、「やるべきことを全部洗い出す」わけです。

なぜWBSが重要なのか

• 抜け漏れを防ぐ
  → 絶対やってはいけないことが全部見える！
• 見積りしやすい
  →各パッケージを見える化
• 誰が何するか割り振れる
  → ワークパッケージ単位で担当をアサイン！
• 「仕様にないことやるな！」の線引きになる
  → スコープ管理のカギ！

PMP試験でのポイント

覚えておくべきこと	内容
WBSはスコープ・ベースラインの一部	「スコープ記述書＋WBS＋WBS辞書」
ワークパッケージ	WBSの一番下具体的な作業単位（タスクではない）
構造はトーナメントのような階層構造	どんどん分割していく（階層構造）
100％ルール	親要素は子要素すべての合計（抜け漏れ×）
「要素に“名詞”を使う」	作業ではなく、成果物として本来のが一般的（例：「スポンジ作成」ではなく「スポンジ」）

よくあるWBSあるある

• 「WBS作ったら仕事が終わった気になる」
  　→実はここからが始まる！
• 「めっちゃ分解したけど、実行フェーズで「何だったらいいの？」って言われる」
  　→ WBSが「成果物ベース」じゃないと、作業のイメージが湧かない…
• 「その作業、WBSにならないからスルーしました」
  　→ うっかり「スコープ外」扱いされる悲劇…

WBSまとめ

WBSとは…	意味
全体を分解	目標 → 成果物 → 作業単位段階的に検討
箱詰め思考	各要素を「抜けなく」分類して管理
スコープ制御	「これやしからん！」と明確に宣言できる
PMPの重要用語	計画プロセス群の要（中心）です！

スコープクリープ

PMの天敵とも言えるこの言葉──スコープ・クリープ（Scope Creep）。名前はちょっとカッコイイけど、プロジェクトマネージャーにとっては横から忍び寄るホラー映画の怪物みたいな存在です。では今回もたっぷりに、優しく解説していきます🍰

スコープ・クリープとは？

一言で言えば、

「気がついたら、やることが増えてる」現象。 じつは、正式な変更手続きナシだったのが原因！？

こんな感じです

👨‍💼「あのぅ…ついでにこれもお願いしていい？」
👩‍💻「えっ…前に言ってなかったんですよね？」
👨‍💼「まあ、大変じゃないですよね？頼むよ〜♪」
👩‍💻（あ、出た。スコープクリープ…）

ケーキ屋で例えるスコープ・クリープ

あなたがPMとして「結婚式のケーキを作る」プロジェクトを管理しています。

最初のスコープ（やること）は：

• 3段のチョコレートケーキ
• 生クリームデコレーション
• 新郎新婦の名前入りプレート

もしかして、もしかして…

👰「やっぱ中にイチゴも入れて」
🤵「花火も仕込んでくれる？」
👰「ドライアイスでもモクモクってのも…！」

あなた（PM）「えっっっっ……（聞いてない）」

スコープが徐々に増えてきています…それがスコープ・クリープです。

なぜ「クリープ」なの？

「クリープ（creep）」は英語で「忍び寄る」とか「少しずつ進む」って意味です。

そうですね、スコープクリープは…

💀「こっそり」「ジワジワ」「気づいたら取り返しがつかない」

という、怖い特徴を持っているわけです。

なぜスコープクリープは問題なのか?

スコープクリープの問題	内容
スケジュール遅延	追加作業のせいで納期ぎりぎりに
予算オーバー	見積もってない作業のせいで負けに
チーム疲労問題	「え、これもやるの？」の連続でモチベダウン
顧客トラブル	「聞いてない！」または「やったのに認めてもらえない！」

スコープ・クリープを防ぐ方法

1. スコープ・ベースを明確にする
   　→ 「やることリスト」は文書でしっかり残しておきます！
2. 変更管理プロセスを使う
   　→ 追加や変更は正式な申請＆承認フローをよろしく！
3. 「イエスマンPM」にならない
   　→ 「それ、スコープ外ですので」と勇気を！
4. ステークホルダーと密なコミュニケーション
   　→ 勝手に期待値がふくらまないように、丁寧に説明！

PMP試験での用語整理

用語	意味
スコープクリープ	正式な変更プロセスなしでスコープが拡大すること
Integrated Change Control（統合変更管理）	スコープ変更を正式に処理するプロセス
スコープ・ベースライン	スコープを明確化＆固定する基準。クリープの防波堤！

現場あるある

• 「ちょっとだけ」って言われたけど、1週間かかった
• 誰も知らない作業が終わった
• PMが「頼まれたら断れない性格」で大炎上
• 「最初より完成品が豪華すぎる」のに、誰も褒めてくれない

まとめ：「スコープクリープ＝プロジェクトの『勝手にミッション増やす屋』」

• 変更は「正式な手続き」を通すべし！
• スコープ・ベースラインを「防波堤」に！
• PMはスコープガードマン！
• 「ついでにやっといて」は禁句！

スコープクリープを許すと、プロジェクトは「便利屋」へと変わり、
最後には「誰も得しないカオス状態」になるので注意！