3. パフォーマンス領域（第7版8個 → 第8版7個）
⚠️ 要検証セクション：本ファイルの「第8版の7領域」の具体的名称・境界線は、 執筆時点（2026-08-26）で公式ガイド原文と一語一句の照合ができていない。 第7版の8領域（下表）は確立情報として扱い、第8版側は「統合の考え方」までを 暫定的に示す。研修で使う前に必ず公式ガイド日本語版で該当ページを確認し、 表を確定版に置き換えること。
3.1 第7版：8つのパフォーマンス領域（確立情報・ベースライン）
| # | パフォーマンス領域（英語） | 日本語 | 概要 |
|---|---|---|---|
| 1 | Stakeholders | ステークホルダー | 関係者の特定・エンゲージメント・期待値管理 |
| 2 | Team | チーム | チーム文化・リーダーシップ・育成 |
| 3 | Development Approach and Life Cycle | 開発アプローチ・ライフサイクル | 予測型／適応型／ハイブリッドの選択とテーラリング |
| 4 | Planning | 計画 | スコープ・スケジュール・コスト・リソースの計画活動全般 |
| 5 | Project Work | プロジェクト作業 | プロセスの確立、資源の獲得、コミュニケーションの運営 |
| 6 | Delivery | デリバリー | 価値ある成果物を計画通り／適応的に届ける |
| 7 | Measurement | 測定 | パフォーマンス評価、指標の設計と解釈 |
| 8 | Uncertainty | 不確実性 | リスク・曖昧さ・複雑性・変動性への対応 |
図：8領域をプロジェクトの流れに置くと
3.2 第8版：7領域への統合（暫定・要検証）
第8版で8→7に整理された背景として、本資料集では次の仮説を採用する （あくまで学習用の仮説であり、公式の統合方針そのものではない）：
- 「プロセスと成果物に品質を組み込む」（原則3）が本編に強く 統合されたことで、Measurement（測定）とDelivery（デリバリー）の一部機能が 品質管理の文脈に吸収されている可能性がある
- プロセス（40プロセス）が本編に復活したことで、Planning と Project Work の境界が プロセス群（立ち上げ・計画・実行・監視コントロール・終結）側で再定義され、 パフォーマンス領域側の重複が整理された可能性がある
| 暫定領域名（要検証） | 統合元の想定 | 研修上の扱い方 |
|---|---|---|
| ステークホルダー | Stakeholders | そのまま継続 |
| チーム | Team | そのまま継続 |
| 開発アプローチ・ライフサイクル | Development Approach and Life Cycle | そのまま継続 |
| 計画とプロジェクト作業 | Planning + Project Work | 統合の可能性（要検証） |
| デリバリーと品質 | Delivery + 測定の一部 | 統合の可能性（要検証） |
| 測定（縮小版） | Measurement の残部 | 独立領域として残るか要確認 |
| 不確実性 | Uncertainty | そのまま継続 |
図：8→7 統合の考え方（仮説・要検証）
3.3 研修での使い方（確定情報が無くても進められる部分）
パフォーマンス領域は「プロジェクトのどの側面を定期的にチェックすべきか」の チェックリストの見出し として使うのが実務的な価値。具体的な領域数・名称が 確定するまでは、以下の運用で代替できる：
- 週次／隔週のプロジェクトレビューで、7版の8領域（3.1の表）を順番に確認する
- 「この領域について、直近2週間で悪化・改善したことは何か」を一言で記録する
- 公式の第8版7領域が確定した時点で、記録フォーマットの見出しだけを差し替える （運用の実質は変わらない）
3.4 演習：自分のプロジェクトの領域別ヘルスチェック
| 領域（第7版8区分を使用） | 状態（◎/○/△/✕） | 一言コメント |
|---|---|---|
| ステークホルダー | ||
| チーム | ||
| 開発アプローチ・ライフサイクル | ||
| 計画 | ||
| プロジェクト作業 | ||
| デリバリー | ||
| 測定 | ||
| 不確実性 |
✕がついた領域は、02_six_principles.md のどの原則の 実践不足が原因になっているかをセットで書き出すと、原則とパフォーマンス領域の つながりが実感として理解できる。