0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【PMBOK第8版を学ぶ #4】スコープドメイン — 何を作る/作らないを定義する

0
Last updated at Posted at 2026-04-07

PMBOK第8版の学習シリーズ第4回。スコープ = プロジェクトの境界線。

「何を作るか」だけでなく「何を作らないか」を決めることがスコープ管理の本質。ここが曖昧だと、スコープクリープ(際限のない要件膨張)でプロジェクトが破綻する。

この記事で得られること:

  • スコープドメインの全プロセスと実務での使い方
  • 予測型(WBS)と適応型(バックログ)の使い分け
  • スコープクリープを防ぐ具体的な方法

キーコンセプト

概念 内容
プロダクトスコープ 成果物の機能・特性(何ができるか)
プロジェクトスコープ 成果物を作るために必要な作業全体
スコープベースライン スコープ記述書 + WBS + WBS辞書
スコープクリープ 承認されていないスコープの追加
価値ベースのスコープ定義 第8版で強化。価値に基づくスコープの優先順位付け

プロセス一覧

# プロセス フォーカスエリア やること
1 要求事項の引き出し・分析 計画 ステークホルダーから「本当に欲しいもの」を聞き出す
2 スコープの定義 計画 プロジェクト/プロダクトスコープ記述書の作成
3 WBSの作成 計画 成果物を作業単位に階層的に分解
4 スコープの妥当性確認 監視・制御 成果物の正式な受入(ステークホルダーの承認)
5 スコープのコントロール 監視・制御 スコープベースラインの変更管理

各プロセスの詳細

1. 要求事項の引き出し・分析

ステークホルダーが「欲しい」と言うものと「本当に必要なもの」は違う。このギャップを埋めるプロセス。

主なツール・技法:

  • インタビュー(1対1で深掘り)
  • ワークショップ(複数人で合意形成)
  • プロトタイピング(見せて確認)
  • 観察(実際の業務を見る)
  • アンケート(大人数から収集)

エンジニア的に言うと: ユーザーインタビューとユーザビリティテストの組み合わせ。「ユーザーが言ったこと」ではなく「ユーザーが本当に困っていること」を特定する。

2. スコープの定義

要求事項から「やること/やらないこと」の境界線を引く。

アウトプット:スコープ記述書

  • プロダクトスコープの説明
  • 受入基準
  • 成果物の一覧
  • 除外事項(明示的にスコープ外とするもの)
  • 前提条件と制約条件

「除外事項」が一番大事。 やらないことを明示しないと、後から「これも入ってると思ってた」と言われる。

3. WBSの作成

成果物を階層的に分解する。予測型の核心ツール。

プロジェクト
├── 成果物A
│   ├── サブ成果物A-1
│   │   ├── ワークパッケージA-1-1
│   │   └── ワークパッケージA-1-2
│   └── サブ成果物A-2
├── 成果物B
└── プロジェクト管理

ワークパッケージ = WBSの最下層。見積もり・スケジュール・コスト管理の最小単位。

4-5. スコープの妥当性確認とコントロール

  • 妥当性確認 = 成果物がスコープ記述書と合致しているかの正式な検証
  • コントロール = スコープベースラインからの逸脱を検知し、変更管理プロセスで対応

予測型 vs 適応型のテーラリング

観点 予測型 適応型
スコープ定義 プロジェクト初期にフルスコープを定義 バックログで段階的に詳細化
分解手法 WBS(成果物ベース) エピック → フィーチャー → ストーリー → タスク
要求事項 要求事項文書として凍結 ユーザーストーリーとして反復的に精緻化
変更管理 正式な変更要求 + CCB承認 バックログリファインメントで動的調整
受入 フェーズ末の正式な検収 スプリントレビューでの受入
文書化 詳細な仕様書 「十分な」文書 + 会話 + 確認テスト

スコープクリープを防ぐ3つの方法

  1. 除外事項を明示する — スコープ記述書に「○○はスコープ外」と書く
  2. 変更管理プロセスを用意する — 追加要求は必ず変更要求として評価。影響(コスト・スケジュール・リスク)を算出してから承認/却下
  3. Definition of Done(完了の定義)を明文化する — 「何をもって完了とするか」をチーム全員で合意

他ドメインとの相互作用

  • ガバナンス → スコープ変更の承認権限
  • スケジュール → スコープが確定しないとスケジュールが組めない
  • ファイナンス → スコープの増減がコストに直結
  • ステークホルダー → 要求事項の引き出し元
  • リスク → スコープの不確実性がリスク源

シリーズ一覧:
#0 目次 / #1 原則 / #2 ライフサイクル / #3 ガバナンス / #4 スコープ(本記事) / #5 スケジュール / #6 ファイナンス / #7 ステークホルダー / #8 リソース / #9 リスク / #10 テーラリング+AI+調達

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?