3.1 スコープの定義
プロジェクトマネジメントにおいて、スコープ（scope）の定義は最重要とも言える工程のひとつです。
なぜなら、スコープとはプロジェクトの「土俵」だからです。つまり、どこまでがこのプロジェクトの責任範囲なのか、何を達成し、何は対象外なのかを明確にすることです。
スコープが曖昧なまま進めば、関係者による認識のズレ、作業の追加要求、スケジュールの圧迫、予算超過など、あらゆる問題の火種となります。
逆に、明確なスコープがあるプロジェクトは、チームが安心して動きやすく、意思決定の軸もブレません。
スコープとは何か？
PMBOK（プロジェクトマネジメント知識体系ガイド）では、スコープを次のように定義しています：
「プロジェクトで提供する製品・サービス・成果物の作成に必要な作業の範囲」
つまり、スコープとはプロジェクトが生み出すもの（成果物）と、そのために必要な作業の範囲のことを指します。
そして同時に「何をしないか（=アウト・オブ・スコープ）」も定義することが極めて重要です。
なぜスコープの定義が必要なのか？
- 期待のコントロール： ステークホルダー間の「これくらいやってくれるよね？」という無意識の期待を防ぐ
- 作業の境界線を明確化： チームが迷わず進めるための道しるべになる
- 変更管理の基準になる： 「追加の依頼」が来たときに、それがスコープ内かどうか判断できる
- 進捗管理の土台になる： スコープが明確であれば、進捗も明確に測定できる
スコープの曖昧さは、プロジェクトの遅延・コスト増・品質劣化の三大原因の出発点でもあります。
スコープ定義のステップ
1. 要件の収集
顧客・関係者（ステークホルダー）から、「何が必要か」「何を期待しているか」の要件をヒアリングします。
ここではあえて広く情報を集め、後で絞り込む材料にします。
2. スコープ記述の作成
要件をもとに、実際にプロジェクトで扱う作業内容を定義します。
「何をやるか」「何をやらないか（除外範囲）」を明文化し、関係者の合意を得ることが重要です。
3. WBS（作業分解構成図）への展開
定義したスコープをもとに、プロジェクトの作業を細かく分解していきます。
これにより、実際のスケジュール作成やリソース配分が可能になります。
4. スコープベースラインの確定
スコープ記述やWBS、WBS辞書（各作業の詳細説明）をまとめて「スコープベースライン」と呼び、これをプロジェクトの基準として以降の判断材料とします。
スコープの構成要素
- プロジェクトの目的と背景
- 成果物一覧（Deliverables）
- 作業範囲（In Scope）
- 除外範囲（Out of Scope）
- 制約条件（Constraints）
- 前提条件（Assumptions）
このように整理しておくことで、チームやステークホルダーの間に共通理解が生まれ、ブレのない進行が可能になります。
よくある落とし穴
- 関係者の認識ズレ： スコープ定義を共有せず、「そんなこと聞いてない」となる
- 除外範囲が曖昧： 結果として対応範囲が広がり、リソースが逼迫
- 詳細化しすぎる： 初期の段階で細かく決めすぎ、柔軟に変更できなくなる
まとめ：スコープは“合意された境界線”
スコープとは、単なる作業一覧ではありません。
それは、プロジェクトチームと関係者のあいだで交わされた約束であり、行動の根拠になる基準です。
プロジェクトを成功させるためには、「どこまでやるのか」「どこから先はやらないのか」をはっきりさせる勇気と技術が必要です。
その起点となるのが、このスコープ定義なのです。
AB ではこう動かす
AB Project Management では、プロジェクトそのものがスコープの境界になります — タスクは必ずプロジェクトの中に住み、外で漂うことはありません。プロジェクトの概要欄が一行のスコープ記述、プロジェクト Wiki に「Out of Scope」を明記した長めのスコープ文書を置けば、後からステークホルダーに「これも入っていなかった？」と言われたときにそのページと変更履歴を指し示せます。新しい依頼がタスクとして飛び込んできたら、「Backlog / Out of Scope」のような区分にタグ付けして仕分ければ、スコープを広げるかどうかの議論が静かな積み上げではなく、明示的な判断として行えます。
→ 次は「3.2 スケジュール作成」に進みましょう。