Process① 統合・スコープ・スケジュール
1. 統合マネジメント（Integration Management）
PMの 「全体を見て調整する」 中核責務。
主要プロセス（PMBOK6）
| プロセス | 出力 | タイミング |
|---|---|---|
| Develop Project Charter | プロジェクト憲章 | Initiating |
| Develop Project Management Plan | PMP（プロジェクトマネジメント計画） | Planning |
| Direct and Manage Project Work | 成果物・作業パフォーマンスデータ | Executing |
| Manage Project Knowledge | レッスン・ラーンドレジスター | Executing |
| Monitor and Control Project Work | 変更要求・作業パフォーマンス報告書 | M&C |
| Perform Integrated Change Control | 承認された変更要求 | M&C |
| Close Project or Phase | 最終成果物・組織のプロセス資産更新 | Closing |
プロジェクト憲章（Project Charter）
- スポンサーが署名する プロジェクトの正式な認可文書
- PMの権限を定義
- 高レベルの目的・要件・予算・マイルストーン
- プロジェクト憲章なしにPMは仕事を始めない（重要）
Integrated Change Control（統合変更管理）
変更が来たら必ずこのプロセスを通す。
変更要求
↓
影響分析（スコープ・スケジュール・コスト・品質・リスクへの影響）
↓
CCB（Change Control Board）審査
↓
承認 → ベースライン更新・関係者通知
拒否 → 記録のみ
よくある誤答パターン
- 「変更要求を即座に実行する」→ 誤（影響分析・承認が先）
- 「小さい変更だから自分の判断で」→ 誤（必ずプロセス）
出題ポイント
- ステークホルダーが「すぐ変更してほしい」と言ってきた → 影響分析→CCB
- スポンサーから「予算追加」 → 同様にプロセスを通す
2. スコープマネジメント（Scope Management）
主要プロセス
- Plan Scope Management — スコープ計画
- Collect Requirements — 要件収集
- Define Scope — スコープ記述書
- Create WBS — WBS作成
- Validate Scope — 顧客検収
- Control Scope — スコープ統制
要件収集の手法（ステークホルダーから情報を引き出す）
| 手法 | 内容 |
|---|---|
| Interview | 1対1で深堀 |
| Focus Group | 小グループで意見交換 |
| Workshop | 多部門合同（Joint Application Design） |
| Brainstorming | 発散思考 |
| Survey | 大量人数への定型質問 |
| Observation | Job Shadowing |
| Prototyping | 試作で要件を引き出す |
| Benchmarking | 他社事例から抽出 |
| Document Analysis | 既存資料分析 |
Product Scope vs Project Scope
- Product Scope: プロダクトの機能・特性
- Project Scope: プロジェクトの作業（プロダクト + 文書 + 移行支援など）
WBS（Work Breakdown Structure）
- プロジェクト作業を deliverable-oriented に階層分解
- 末端は Work Package（見積もり・割当の単位）
- WBSにないものは スコープ外
- WBS Dictionary: 各Work Packageの詳細記述
100%ルール
WBSは プロジェクト作業の100%を含む。サブレベル合計 = 親レベル。
8/80 ルール
Work Package は 8〜80時間 が目安。
スコープ・ベースライン
Scope Statement + WBS + WBS Dictionary = Scope Baseline
Validate Scope vs Control Quality
- Validate Scope: 顧客が成果物を 受け入れるか 検収（formal acceptance）
- Control Quality: 内部で品質基準を 満たすか 検査
- 順序: Control Quality → Validate Scope
スコープクリープ（Scope Creep）
管理されない変更が積み重なり、スコープが膨張する現象。
PMの対応
- 変更要求は必ずIntegrated Change Controlへ
- ステークホルダーに「これはスコープ外」と早期に明示
- Backlog（アジャイルなら）に追加して優先度判断
Gold Plating
依頼されていない機能を 善意で追加 すること。禁止（スコープクリープの一形態）。
3. スケジュールマネジメント（Schedule Management）
主要プロセス
- Plan Schedule Management
- Define Activities（アクティビティ定義）
- Sequence Activities（依存関係決定）
- Estimate Activity Durations（所要期間見積）
- Develop Schedule（スケジュール作成）
- Control Schedule
依存関係（Dependencies）
| 種類 | 内容 |
|---|---|
| Mandatory（必須） | 物理的・契約上の制約（壁を作ってから屋根） |
| Discretionary（任意） | ベストプラクティス・経験則 |
| External（外部） | プロジェクト外の制約（規制承認） |
| Internal（内部） | プロジェクト内の制約 |
関係タイプ（Precedence Relationships）
| 略号 | 意味 |
|---|---|
| FS（Finish-to-Start） | A完了後にB開始（最も一般的） |
| FF（Finish-to-Finish） | AとBが同時完了 |
| SS（Start-to-Start） | AとBが同時開始 |
| SF（Start-to-Finish） | A開始でB完了（稀） |
Lag と Lead
- Lag: 待ち時間（コンクリ硬化に3日待つ）
- Lead: 前倒し（A完了前にB開始）
所要期間見積手法
| 手法 | 内容 | 精度 |
|---|---|---|
| Analogous | 類似プロジェクトから類推 | 低 |
| Parametric | 単価×数量（1ページ翻訳1h） | 中 |
| 3-Point Estimating（PERT） | (O+4M+P)/6 | 高 |
| Bottom-Up | WBSから積み上げ | 高 |
PERT 公式
- 期待値: (O + 4M + P) / 6
- 標準偏差: (P - O) / 6
- 分散: ((P - O) / 6)²
例: O=4, M=8, P=18
- 期待値 = (4 + 32 + 18)/6 = 9
- 標準偏差 = (18-4)/6 = 2.33
クリティカルパス法（CPM）
用語
- Total Float（Slack）: アクティビティが遅延しても全体に影響しない余裕時間
- Free Float: 後続アクティビティに影響しない余裕時間
- Critical Path: Total Float = 0 のパス。最長経路。
- Near-Critical Path: クリティカルパスに近い経路（注視必要）
計算手順
- Forward Pass: ES（最早開始）・EF（最早終了）を左→右に計算
- Backward Pass: LS（最遅開始）・LF（最遅終了）を右→左に計算
- Float = LS - ES = LF - EF
例題
A(3) → B(5) → D(2)
↓
C(4) → D
- Path1: A→B→D = 3+5+2 = 10
- Path2: A→C→D = 3+4+2 = 9
- Critical Path: A→B→D（10日）
- BのFloat = 0、CのFloat = 1
スケジュール圧縮
| 手法 | 内容 | リスク |
|---|---|---|
| Crashing | リソース追加でアクティビティ短縮 | コスト増 |
| Fast Tracking | 直列を並列化 | リスク増 |
「Crashing」はコスト最適なものから。
スケジュール・ベースライン
承認された Schedule Model + 計画期日 = Schedule Baseline
スケジュール統制ツール
- Schedule Performance Index（SPI = EV/PV）
- Variance Analysis（差異分析）
- Forecasting（予測）
バッファ管理（Critical Chain Method）
- フィーディング・バッファ: 非クリティカルパスの末尾に配置
- プロジェクト・バッファ: 全体の末尾
- バッファ消費率を監視
4. WBS作成演習
演習: ECサイト構築PJ
レベル1: ECサイト構築PJ レベル2:
- 1.1 要件定義
- 1.2 設計
- 1.3 実装
- 1.4 テスト
- 1.5 リリース・移行
- 1.6 プロジェクト管理
レベル3 (1.3 実装の例):
- 1.3.1 フロントエンド
- 1.3.2 バックエンド
- 1.3.3 DB
- 1.3.4 決済連携
- 1.3.5 インフラ
レベル4 (1.3.2 バックエンド):
- 1.3.2.1 ユーザー管理API
- 1.3.2.2 商品管理API
- 1.3.2.3 注文管理API
- 1.3.2.4 在庫管理API
各 Work Package が 8〜80h、明確な成果物（API実装＋ユニットテスト＋ドキュメント）を持つ。
5. 出題で押さえるポイント
スコープ系
- 変更は 必ずプロセス を通す
- Gold Plating は禁止
- Scope Creep は早期検出
スケジュール系
- Critical Path は Float = 0
- PERT 公式は暗記
- Crashing はコスト・Fast Tracking はリスク
統合系
- プロジェクト憲章なしに開始しない
- 変更要求は影響分析→CCB
- レッスン・ラーンドは継続的に蓄積
チェック問題
Q1
クリティカルパスとは？
A) 最も短い経路 B) 最もコストの高い経路 C) Float が 0 の経路（最長経路） D) 最も多くのリソースを使う経路
Q2
PERT で O=10, M=20, P=42 の期待値は？
A) 22 B) 22（実際の計算: (10+80+42)/6 = 22） C) 24 D) 19
Q3
スポンサーが「重要顧客のため、追加機能をスコープに入れて」と要求した。最初の対応は？
A) すぐ実装 B) 影響分析（スケジュール・コスト・品質・リスク）し、CCBへ提出 C) 拒否 D) チームに丸投げ
解答
- C — Float=0が定義。
- B — (10+4×20+42)/6=132/6=22。
- B — 統合変更管理プロセス。