はじめに
前回の記事「PMBOK第8版の6原則とは何か？──プロジェクトマネージャの判断を変える行動哲学」では、PMBOK®ガイド第8版で整理された6つの原則を通じて、プロジェクトマネジャーが、どのような前提に立って判断すべきか、すなわち「原則 → 判断」という構図を整理しました。
さらに、「PMBOK®第8版の「プロジェクト・ライフサイクル」とは何か？」にて、プロジェクトをどのような構造で捉えるかを説明するための概念を整理しました。
今回はさらにPMBOK(R)第８版を読みすすめて、「パフォーマンスドメイン」について整理したいと思います。
PMBOK®ガイド第8版を読んで、多くのプロジェクトマネージャが戸惑う概念の一つが「パフォーマンスドメイン」 ではないでしょうか。
ガバナンス、スコープ、スケジュール、ファイナンス、ステークホルダー、リソース、リスク。
どれも従来のPMBOKにも登場してきたおなじみの領域です。
しかし第8版では、これらは「管理すべき知識エリア」でも「実行すべきプロセス群」でもなく、プロジェクトの成果や状態を捉えるための「パフォーマンスドメイン」として再定義されています。
その結果、
- 管理しているはずなのに成果が出ない
- 計画は整っているのに、なぜかプロジェクトがうまく進まない
- どこに問題があるのか説明できない
といった、現場でよくある違和感に対して、別の視点から問い直すための枠組み が提示されたとも言えます。
一方で、パフォーマンスドメインは個々の章を読むと非常に詳細で、いきなり理解しようとすると
「結局、何をどう使えばよいのか分からない」という印象を持ちやすいのも事実です。
そこで本記事では、いきなり各パフォーマンスドメインの詳細に入るのではなく、
- パフォーマンスドメインとは何か
- 第8版で何が、どのように変わったのか
- 原則やプロジェクトフォーカスエリアと、どういう関係にあるのか
といった 全体構造の整理 に焦点を当てます。
本記事の目的は、パフォーマンスドメインを「管理する対象」として理解することではありません。
むしろ、
- 自分の判断は、どの結果として現れているのか
- どの領域に歪みが出ているのか
- どこで判断を見直すべきなのか
を 検証するための視点 として、パフォーマンスドメインをどう捉えるべきかを整理することにあります。
なお、各パフォーマンスドメインについては、本記事では概要レベルの説明に留め、それぞれを1つずつ深掘りする記事を後日あらためて執筆する予定です。
まずは、PMBOK®第8版が描こうとしている「原則 → 判断 → 結果」という構造の中で、パフォーマンスドメインがどこに位置づけられているのかを一緒に確認していきましょう。
※2026年1月現在では、PMBOK(R)第8版の日本語版はリリースされておりませんので、日本語版が出てきたときに用語の翻訳、解釈などの微妙なズレがあるかも知れませんが、あらかじめご了承ください。
パフォーマンスドメインとは？
PMBOK®ガイド第8版において導入された「パフォーマンスドメイン」は、従来のPMBOKに慣れたプロジェクトマネージャほど、誤解しやすい概念です。
なぜなら、名称だけを見ると「新しい管理カテゴリ」、「知識エリアの言い換え」のように受け取れてしまうからです。
しかし、PMBOK®第8版が意図しているパフォーマンスドメインは、何かを管理するための枠組みではありません。
3.2 Principles and Performance Domains
Performance domains are designed to enable the practical application of project management
principles and ensure this mindset is translated into effective practices and outcomes. These
performance domains represent the mechanics of project management, including the knowledge,
processes, and methods that are essential for effective project delivery.（訳）原則とパフォーマンス領域
パフォーマンス領域は、プロジェクトマネジメントの原則を実践的に適用し、この考え方が効果的な実践と成果に繋がるように設計されています。これらのパフォーマンス領域は、効果的なプロジェクトの実施に不可欠な知識、プロセス、手法など、プロジェクトマネジメントの仕組みを表しています。
PMBOK(R)第8版 3.2章「原則とパフォーマンスドメイン」より引用
パフォーマンスドメインは「管理項目」だけではない
第6版までのPMBOKでは、
- スコープ管理
- スケジュール管理
- コスト管理
- リスク管理
といったように、「〇〇を管理する」という発想が前面に出ていました。
知識エリアやプロセスは、「何をすればよいか」「何を作成すべきか」を示す役割を担っていました。
一方、第8版のパフォーマンスドメインは、プロジェクトがどのような状態にあるか、どのような結果が現れているかを捉えるための視点として定義されています。
つまり、
- 実行した結果、今どうなっているのか
- その状態は、意図したものか
- 判断の積み重ねが、どの領域に影響として現れているか
を観察・理解するための枠組み・仕組みです。
「成果の見え方」を整理するための概念
パフォーマンスドメインは、プロジェクトの成功・失敗を単一の指標で判断するためのものではありません。
スケジュールが守られていても、ステークホルダーの信頼が失われていることがあります。予算内で完了していても、ガバナンス上の問題を抱えていることもあります。このように、プロジェクトの結果は複数の側面に分かれて現れる のが現実です。
パフォーマンスドメインは、こうした結果の現れ方を整理し、
- どの側面が健全なのか
- どの側面に歪みが出ているのか
を捉えるための「観測点」として機能します。
判断と結果を結びつけるための枠組み
PMBOK®第8版では、プロジェクトマネジメントを
- 原則（Principles）
- 判断（Decisions）
- 行動（Actions）
- 結果（Outcomes）
の連なりとして捉えています。
この中で、パフォーマンスドメインが位置づけられているのは、結果がどのような状態として現れているかを捉えています。
言い換えると、
- 原則は「どう考えるか」
- アプローチは「どう進めるか」
- パフォーマンスドメインは「その結果、何が起きているか」
を示しています。
そのため、パフォーマンスドメインはチェックリストのように「満たしているか」を確認するものではなく、自分たちの判断が、どのような結果を生んでいるかを検証するための視点として使われることが想定されています。
なぜ第8版でパフォーマンスドメインが必要になったのか
第8版がこの概念を前面に出した背景には、プロジェクトの多様化と複雑化があると思います。（推測です。）
- 従来の手順中心モデルだけでは説明できない現象（整っているのに失敗する）
- すべてを事前に計画できない
- 正解が一つではない
- 成功の定義がステークホルダーごとに異なる
こうした環境では、「正しい手順を踏んだかどうか」だけでは、プロジェクトの状態を説明できなくなっています。
そこで第8版では、手順やプロセスよりも一段抽象度を上げ、結果として何が起きているかを、多面的に捉える枠組みとして、パフォーマンスドメインが導入されたと読み取れます。
第8版での変更点の概要 ― パフォーマンスドメインは「何が変わったのか」
PMBOK®ガイド第8版を理解するうえで重要なのは、新しい概念が追加されたこと そのものよりも、
既存の概念の位置づけがどう変わったのか を捉えることです。
パフォーマンスドメインも、第7版までの考え方を単純に拡張したものではありません。むしろ、第8版ではプロジェクトマネジメント全体の構造が組み替えられ、その中でパフォーマンスドメインが再配置されています。
第7版までの前提構造
第6版・第7版までのPMBOKでは、プロジェクトマネジメントは主に次の構造で説明されていました。
- プロセス群（立上げ・計画・実行・監視・終結）
- 知識エリア（スコープ、スケジュール、コスト、品質、リスクなど）
- プロセスとアウトプットの関係
この構造では、
- どのタイミングで
- どの管理活動を行い
- どの成果物を作成するか
が中心的な関心事になります。
その結果、現場ではしばしば「プロセスを回しているのに、なぜかうまくいかない」「管理はできているはずなのに、評価されない」といった違和感が生まれていました。
第8版で起きた構造的な転換
第8版では、この前提が大きく転換されています。
- プロセス中心 → 原則中心
- 手順の説明 → 判断の説明
- 管理活動 → 結果の状態
へと、軸が移されています。
この構造転換の中で、パフォーマンスドメインは「管理対象」ではなく「結果が現れる領域」として位置づけ直されました。ポイントとしては、第8版が「何をやればよいか」よりも「その判断の結果、何が起きているのか」を重視している点です。
パフォーマンスドメインの「再配置」
第7版では、スコープ、スケジュール、コスト、リスクなどは
明確に「管理すべき対象」として整理されていました。
一方、第8版では同じ領域が
- ガバナンス
- スコープ
- スケジュール
- ファイナンス
- ステークホルダー
- リソース
- リスク
といった パフォーマンスドメイン として再定義されています。
ここでの違いは、何を管理するかではなく、その領域で、どのような状態が現れているかに視点が移っている点です。
たとえば、スケジュールを守るために何をするかではなく、スケジュールという観点で、今どんな状態が起きているかを捉えるための枠組みになっています。
PMBOK(R)第８版 プロジェクトマネジメントの原則とパフォーマンスドメインの関係より
6つの原則との関係性を整理する ― なぜ「原則」が先に置かれているのか
System for Value Delivery を中核にした再構成
PMBOK®第8版を読み進めていくと、全体を貫く前提としてSystem for Value Delivery（価値提供のためのシステム）という考え方が明確に据えられていることに気がつきます。
第8版において、プロジェクトは「独立した活動の集合」ではなく、組織全体の価値創出システムの一部
として位置づけられています。
この前提に立つと、パフォーマンスドメインの役割も変わってきます。
第7版では、ドメインは「プロジェクトをうまく進めるために気を配るべき観点」として整理されていました。
一方、第8版では、ドメインは
「価値創出システムが、今どのような状態にあるかを観察するための要素」
という意味合いが強くなっていると感じます。
つまり、ドメインは実行するための枠組みではなく、システムが健全に機能しているかを観察する視点へと再定義されたと考えられます。
PMBOK®ガイド第8版を読み進めると、パフォーマンスドメインの説明の前提として、6つの原則（Principles） が強調されていることに気づきます。
これは単なる構成上の都合ではありません。
第8版では、
原則 → 判断 → 行動 → 結果（パフォーマンスドメイン）
という因果関係が、意図的に設計されています。
原則は「やり方」ではなく「判断の軸」
まず押さえておきたいのは、第8版における原則の位置づけです。
PMBOK®が原則として示しているのは、プロジェクトに関わる人が、どのような価値観・思考様式で判断すべきかという、判断の前提条件です。
そのため、原則は「何をするか」ではなく、
- どこに目を向けるのか
- 何を優先するのか
- 何を成果とみなすのか
といった、判断の方向性を規定します。
パフォーマンスドメインは「原則の結果が現れる場所」
一方で、パフォーマンスドメインは、原則に基づいて行われた判断と行動の結果が現れる領域です。
ここが、第7版までとの決定的な違いです。
第7版までは、
- 原則的な考え方
- 管理活動
- 成果
が明確に分離されていませんでした。
第8版ではこれを分解し、
- 原則：判断の前提
- パフォーマンスドメイン：結果の現れ方
として役割を切り分けています。
「整っているのに失敗する」理由が説明できる構造
この構造を理解すると、現場でよく起きる次のような違和感が説明できるようになります。
- 計画は適切に作られている
- 進捗管理も行われている
- リスク管理のプロセスも回っている
それでも、
- ステークホルダーの不満が解消されない
- 意思決定が遅れる
- プロジェクトの価値が伝わらない
といった状況が発生することがあります。
これは、管理活動が不足しているのではなく、判断の前提となる原則が十分に機能していない可能性を示しています。
パフォーマンスドメインは、その「結果の歪み」を領域ごとに可視化する役割を果たします。
原則とドメインは一対一ではない
注意すべき点として、原則とパフォーマンスドメインは 一対一で対応しているわけではありません。
1つの原則は、複数のパフォーマンスドメインに影響しますし、1つのパフォーマンスドメインも、複数の原則の影響を受けます。
たとえば、
- 「価値に焦点を当てる」という原則は
- スコープ
- ステークホルダー
- ガバナンス
といった複数のドメインに結果として現れます。
これは、第8版が単純な対応関係ではなく、全体最適を前提とした構造を意図していることを示しています。
原則が「内側」、ドメインが「外側」にある理由
PMBOK®第8版の図では、
- 中心に Mindset and Behaviors
- その外側に Principles
- さらに外側に Performance Domains
という構造が描かれています。
これは、
- 内側：人の思考・態度・判断
- 外側：プロジェクトに現れる状態・結果
という因果関係を視覚的に表しています。
つまり、パフォーマンスドメインは、原則が正しく機能しているかを確認するための観測点だと捉えることができます。
第8版がPMに求めていることは、管理項目を漏れなく実行することではなく原則に照らして判断し、その結果をパフォーマンスドメインで検証することです。
この視点を持つことで、パフォーマンスドメインは「管理の負担を増やす概念」ではなく、判断の妥当性を振り返るためのフレームワーク として機能します。
プロジェクトフォーカスエリアとパフォーマンスドメインの関係
PMBOK®第8版では、パフォーマンスドメインとプロジェクトフォーカスエリアの関係が、
概念説明ではなく、明確なマトリクスとして提示されています。
この章では、添付の Table 2-1「Mapping Project Management Focus Areas to Performance Domains」
をもとに、第8版が意図している構造を読み解きます。
プロジェクトフォーカスエリアとパフォーマンスドメインの対応表（PMBOK®第8版）
| フォーカスエリア／パフォーマンスドメイン | 立上げ（Initiating） | 計画（Planning） | 実行（Executing） | 監視・コントロール（Monitoring & Controlling） | 終結（Closing） |
|---|---|---|---|---|---|
| ガバナンス | プロジェクトまたはフェーズの開始 | プロジェクト計画の統合と整合 調達戦略の計画 | プロジェクト実行の管理 品質保証の管理 プロジェクト知識の管理 | プロジェクトパフォーマンスの監視・管理 変更の評価と実装 | プロジェクトまたはフェーズの終結 |
| スコープ | スコープマネジメント計画 要求事項の収集・分析 スコープ定義 WBS（スコープ構造）の作成 | スコープの監視・管理 スコープの妥当性確認 | |||
| スケジュール | スケジュールマネジメント計画 スケジュール作成 | スケジュールの監視・管理 | |||
| ファイナンス | 財務マネジメント計画 コスト見積り 予算策定 | 財務状況の監視・管理 | |||
| ステークホルダー | ステークホルダーの特定 | ステークホルダーエンゲージメント計画 コミュニケーション計画 | ステークホルダーエンゲージメントの管理 コミュニケーションの管理 | ステークホルダーエンゲージメントの監視 コミュニケーションの監視 | |
| リソース | リソースマネジメント計画 リソース見積り | リソースの獲得 チームのリード | リソースの監視・管理 | ||
| リスク | リスクマネジメント計画 リスク特定 リスク分析 リスク対応計画 | リスク対応の実行 | リスクの監視 |
例えば、ガバナンスパフォーマンスドメインを見ると、
- Initiating：Initiate Project or Phase
- Planning：Integrate and Align Project Plans
- Executing：Manage Project Execution / Quality / Knowledge
- Monitoring and Controlling：Monitor Performance / Implement Changes
- Closing：Close Project or Phase
と、プロジェクト全体を通じて連続的に関与していることが分かります。
これは、「ガバナンスは最初だけ考えればよいものではない」という第8版の明確なメッセージです。
ドメインごとの関与の「濃淡」
一方で、すべてのドメインがすべてのフォーカスエリアに等しく現れているわけではありません。
例えば、
- スコープ、スケジュール、ファイナンス
→ Planning と Monitoring & Controlling に重心がある - ステークホルダー、リソース
→ Initiating から Executing、Monitoring まで広く関与 - リスク
→ Planning での設計と、Executing / Monitoring での対応が中心
この「濃淡」こそが、第8版の重要なポイントです。
第6版までのように、「すべての知識エリアを、すべてのフェーズで均等に回す」という発想ではありません。
フォーカスエリアは作業の順番ではない
第8版では、フォーカスエリアは、
- 必ずこの順番で進むものではない
- 一度きりで終わるものでもない
- 同時並行で発生しうる
という前提で設計されています。
つまりこの表は、「この段階で、この作業をやれ」ではなく、「この局面では、どのドメインに注意が向いているべきか」を示しているマトリクスです。
原則 → フォーカスエリア → ドメインの接続
ここまでの章と合わせて整理すると、
- 原則：どう考え、どう判断するか
- フォーカスエリア：どこに注意を向けるか
- パフォーマンスドメイン：結果がどう現れているか
という構造が、このマトリクスによって接続されています。
マトリクスは、判断の結果が、どのドメインに、どの局面で現れるかを可視化したものだと言えます。
このマトリクスをどう使うのか
実務的には、この表は「作業を網羅するチェックリスト」ではありません。
むしろ、
- どのドメインで違和感が出ているか
- そのドメインは、どのフォーカスエリアで強く関与するのか
- そこでの判断や注意は適切だったか
を振り返るための思考補助ツールです。「管理するための表」ではなく、判断を検証するための構造図と受け取れます。これが、第8版におけるフォーカスエリア × パフォーマンスドメインの本質的な位置づけです。
各パフォーマンスドメインの概要
― 管理対象ではなく「プロジェクトの状態を捉える視点」
前章までで、PMBOK®第8版におけるパフォーマンスドメインが、プロジェクトフォーカスエリアとどのように関係づけられているかを整理してきました。
ここからは、7つのパフォーマンスドメインそれぞれについて概要を確認します。
ただし本章の目的は、各ドメインを詳細に説明することではありません。
第8版におけるパフォーマンスドメインは、「管理すべき項目の一覧」でも「担当領域の切り分け」でもなく、原則に基づく判断の結果が、どの観点にどのように現れているかを観察するための視点として定義されています。
この前提を踏まえ、各ドメインを簡潔に整理します。
① ガバナンス・パフォーマンスドメイン
ガバナンス・パフォーマンスドメインは、プロジェクトにおける意思決定、責任、権限、整合性がどのように機能しているかを捉える視点です。
ここでは、
- 誰が判断を行っているのか
- その判断はどのような根拠で行われているのか
- 組織戦略や方針と整合しているか
といった点が、プロジェクトの振る舞いとして現れます。
「統制が効いているか」ではなく、判断と責任の構造が明確かどうかを確認するためのドメインと捉えると理解しています。
② スコープ・パフォーマンスドメイン
スコープ・パフォーマンスドメインは、プロジェクトで何を実現するのか、その範囲がどのように定義・維持されているかを捉えます。
重要なのは、スコープが固定されているかどうかではなく、
- 価値と結びついたスコープになっているか
- 変更が起きた際に、判断の軸が明確か
- 期待値とのズレが適切に扱われているか
といった点が、結果として現れます。
第8版では、スコープは「守る対象」ではなく、価値創出と判断の結果として変化し得るものとして扱われています。
③ スケジュール・パフォーマンスドメイン
スケジュール・パフォーマンスドメインは、時間に関する判断がプロジェクトの中でどのように機能しているかを示します。
ここで問われるのは、
- 計画通り進んでいるか
- 遅れていないか
といった単純な進捗管理ではありません。
- 何を優先するか
- どの判断をいつ行うか
- 時間制約をどう扱っているか
といった意思決定の結果が、スケジュールという形で表れます。
④ ファイナンス・パフォーマンスドメイン
ファイナンス・パフォーマンスドメインは、コストや予算そのものよりも、資金に関する意思決定の妥当性を捉える視点です。
- どこに投資しているのか
- 何をもってコストと見なしているのか
- 価値とのバランスが取れているか
といった判断が、プロジェクトの財務状態として現れます。
第8版では、単なる「予算管理」ではなく、価値との関係性が重視されています。
⑤ ステークホルダー・パフォーマンスドメイン
ステークホルダー・パフォーマンスドメインは、関係者との関係性や関与のあり方が、どのように機能しているかを捉えます。
ここでは、
- 情報が共有されているか
- 期待値が調整されているか
- 対立や懸念が表に出ているか
といった点が、プロジェクトの状態として現れます。
形式的な報告や会議の有無ではなく、関係性が健全に機能しているかどうかが焦点になります。
⑥ リソース・パフォーマンスドメイン
リソース・パフォーマンスドメインは、人・モノ・スキルといったリソースが、どのように活用されているかを捉える視点です。
単に人数が足りているかではなく、
- 適切なスキルが活かされているか
- チームとして機能しているか
- 制約が認識され、判断に反映されているか
といった点が、プロジェクトの振る舞いとして現れます。
⑦ リスク・パフォーマンスドメイン
リスク・パフォーマンスドメインは、不確実性がどのように扱われているかを捉える視点です。
重要なのは、リスクが洗い出されているかどうかではありません。
- 不確実性が認識されているか
- 判断に織り込まれているか
- 問題が顕在化する前に議論されているか
といった姿勢が、結果として現れます。
各ドメインは「分業」ではなく「多面的な観測点」
ここまで見てきた7つのパフォーマンスドメインは、役割分担や専門領域の切り分けを意図したものではありません。
同じ判断が、複数のドメインに同時に影響を与えることもありますし、1つのドメインの歪みが、別のドメインに現れることもあります。
そのため、第8版では、
- ドメインを個別に最適化する
- チェックリスト的に確認する
のではなく、複数のドメインを行き来しながら、判断の妥当性を検証するという使い方が想定されています。
まとめ
本記事では、PMBOK®第8版で提示された「パフォーマンスドメイン」を、いきなり各ドメインの詳細に入るのではなく、全体構造として整理してきました。
第6版までの感覚で読むと、ガバナンス／スコープ／スケジュール／ファイナンス／ステークホルダー／リソース／リスクは、どうしても「管理すべき領域」に見えます。
しかし第8版では、それらは単なる管理カテゴリではなく、原則に基づく判断と行動が、プロジェクトの中でどのような状態として現れているかを捉えるための観測点として再配置されています。
ポイントは、パフォーマンスドメインを「管理項目のチェックリスト」に還元しないことです。
第8版が強調しているのは、手順を守ったかどうかよりも、判断の結果としてプロジェクトが今どのような状態にあるかを多面的に捉え、必要なら判断を見直す、という流れです。
また、フォーカスエリアとのマッピング（Table 2-1）は、「この順番で作業せよ」という工程表ではなく、各局面で、どのドメインの状態が可視化されやすいかを示す対応表として読むほうが、第8版の意図に近いと考えられます。
この表を使うことで、「どの領域に歪みが出ているか」「その歪みはどの局面の判断と関係しそうか」を振り返る手掛かりが得られます。
結局のところ、第8版が描こうとしている構造は一貫しています。
原則（どう考えるか）→判断（どう決めるか）→結果（何が起きているか）。
パフォーマンスドメインは、この最後の「結果」を捉えるための枠組みであり、現場PMにとっては、判断を検証するための視点として使う価値があるはずです。
参考書籍
※本投稿にはプロモーションが含まれます
PMI『PMBOK® Guide / The Standard for Project Management 第8版（英語版）』
- 3.2 Principles and Performance Domains
- Section 2 Project Management Performance Domains（Table 2-1）
コメント