3.1 スコープの定義とは？｜プロジェクトの境界線を明確にする技術

3.1 スコープの定義

プロジェクトマネジメントにおいて、スコープ（scope）の定義は最重要とも言える工程のひとつです。
なぜなら、スコープとはプロジェクトの「土俵」だからです。つまり、どこまでがこのプロジェクトの責任範囲なのか、何を達成し、何は対象外なのかを明確にすることです。

スコープが曖昧なまま進めば、関係者による認識のズレ、作業の追加要求、スケジュールの圧迫、予算超過など、あらゆる問題の火種となります。
逆に、明確なスコープがあるプロジェクトは、チームが安心して動きやすく、意思決定の軸もブレません。

---

スコープとは何か？

PMBOK（プロジェクトマネジメント知識体系ガイド）では、スコープを以下のように定義しています：

「プロジェクトで提供する製品・サービス・成果物の作成に必要な作業の範囲」

つまり、スコープとはプロジェクトが生み出すもの（成果物）と、そのために必要な作業の範囲のことを指します。
そして同時に「何をしないか（=アウト・オブ・スコープ）」も定義することが極めて重要です。

---

なぜスコープの定義が必要なのか？

スコープ定義が必要な理由は以下のようにまとめられます：

• 期待のコントロール： ステークホルダー間の「これくらいやってくれるよね？」という無意識の期待を防ぐ
• 作業の境界線を明確化： チームが迷わず進めるための道しるべになる
• 変更管理の基準になる： 「追加の依頼」が来たときに、それがスコープ内かどうか判断できる
• 進捗管理の土台になる： スコープが明確であれば、進捗も明確に測定できる

スコープの曖昧さは、プロジェクトの遅延・コスト増・品質劣化の三大原因の出発点でもあります。

---

スコープ定義のステップ

スコープは、以下のようなステップで定義・文書化されます：

1. 要件の収集

顧客・関係者（ステークホルダー）から、「何が必要か」「何を期待しているか」の要件をヒアリングします。
ここではあえて広く情報を集め、後で絞り込む材料にします。

2. スコープ記述の作成

要件をもとに、実際にプロジェクトで扱う作業内容を定義します。
「何をやるか」「何をやらないか（除外範囲）」を明文化し、関係者の合意を得ることが重要です。

3. WBS（作業分解構成図）への展開

定義したスコープをもとに、プロジェクトの作業を細かく分解していきます。
これにより、実際のスケジュール作成やリソース配分が可能になります。

4. スコープベースラインの確定

スコープ記述やWBS、WBS辞書（各作業の詳細説明）をまとめて「スコープベースライン」と呼び、これをプロジェクトの基準として以降の判断材料とします。

---

スコープの構成要素

スコープ定義書には、以下のような要素を含めるのが一般的です：

• プロジェクトの目的と背景
• 成果物一覧（Deliverables）
• 作業範囲（In Scope）
• 除外範囲（Out of Scope）
• 制約条件（Constraints）
• 前提条件（Assumptions）

このように整理しておくことで、チームやステークホルダーの間に共通理解が生まれ、ブレのない進行が可能になります。

---

よくある落とし穴

• 関係者の認識ズレ： スコープ定義を共有せず、「そんなこと聞いてない」となる
• 除外範囲が曖昧： 結果として対応範囲が広がり、リソースが逼迫
• 詳細化しすぎる： 初期の段階で細かく決めすぎ、柔軟に変更できなくなる

---

まとめ：スコープは“合意された境界線”

スコープとは、単なる作業一覧ではありません。
それは、プロジェクトチームと関係者のあいだで交わされた約束であり、行動の根拠になる基準です。

プロジェクトを成功させるためには、「どこまでやるのか」「どこから先はやらないのか」をはっきりさせる勇気と技術が必要です。
その起点となるのが、このスコープ定義なのです。

→ 次は「3.2 スケジュール作成」に進みましょう。