1. 序論：プロジェクトマネジメントのパラダイムシフトと試験の変遷
プロジェクトマネジメント・プロフェッショナル（PMP®）認定試験は、世界的なビジネス環境の変化、特にデジタル化の加速と市場の不確実性の増大に伴い、その評価基準を劇的に進化させてきました。2025年から2026年にかけての試験内容は、従来のプロセスベースの管理手法から、価値提供（Value Delivery）と成果（Outcomes）を重視する原理・原則ベースのアプローチへと完全に移行しています1。この変化は、PMBOKガイド第6版から第7版への改訂に象徴されており、受験者は単なる用語の暗記ではなく、複雑な状況下での最適な判断能力を問われることになります。
本報告書は、最新の試験内容概要（Examination Content Outline: ECO）およびPMBOKガイド第7版、アジャイル実務ガイドに基づき、試験に頻出する200以上の重要用語を包括的に調査・分析したものです。「人（People）」、「プロセス（Process）」、「ビジネス環境（Business Environment）」の3つのドメイン構造を軸に、予測型（ウォーターフォール）、アジャイル型、ハイブリッド型のアプローチを横断的に解説します。各用語は単独で存在するのではなく、相互に関連し合いながらプロジェクトの成功を支えるシステムの一部として機能しており、その文脈を深く理解することが合格への鍵となります。
1.1 価値提供システムと12の原理
現代のプロジェクトマネジメントにおいて、プロジェクトは単独の活動ではなく、組織の戦略的目標を実現するための「価値提供システム（Value Delivery System）」の一部として位置付けられます3。このシステムを機能させるための行動規範として、以下の12の原理が定義されており、これらはすべてのドメインにおける判断の基礎となります。
| 原理 (Principle) | 定義と試験的意義 (Definition & Exam Context) |
| スチュワードシップ (Stewardship) | 誠実さ、配慮、信頼性を持って行動すること。単なる管理責任を超え、組織内外のリソース、倫理、環境に対する受託責任を意味します。試験では、倫理的なジレンマに対するPMの行動規範として問われます3。 |
| チーム (Team) | 協働的なプロジェクトチーム環境を構築すること。多様なスキルを持つメンバーが共通の目標に向かって協力できる文化の醸成が求められます3。 |
| ステークホルダー (Stakeholders) | ステークホルダーと効果的に関与（エンゲージメント）すること。彼らの利益や影響力を理解し、プロジェクトの価値実現に向けて協力を得ることが重要です3。 |
| 価値 (Value) | 価値に焦点を当てること。成果物（アウトプット）の完成だけでなく、それがもたらす成果（アウトカム）とビジネス価値の最大化を常に意識します3。 |
| システム思考 (Systems Thinking) | システムの相互作用を認識し、評価し、対応すること。プロジェクトを孤立した要素ではなく、動的に変化する全体システムの一部として捉える視点です3。 |
| リーダーシップ (Leadership) | 動機付け、影響力、コーチング、学習を通じてリーダーシップを発揮すること。権限（Authority）ではなく影響力（Influence）による指導が重視されます3。 |
| テーラリング (Tailoring) | 文脈に基づいてアプローチを最適化すること。「万能な方法（One size fits all）」は存在しないという前提に立ち、プロジェクトの特性に合わせてプロセスを調整します3。 |
| 品質 (Quality) | プロセスと成果物に品質を組み込むこと。顧客の期待を満たすだけでなく、欠陥の予防と継続的な改善を含みます3。 |
| 複雑性 (Complexity) | 複雑さに対処すること。人間の行動、システム挙動、曖昧さなどから生じる複雑性を理解し、適応します3。 |
| リスク (Risk) | リスクへの対応を最適化すること。脅威だけでなく好機（機会）もリスクとして捉え、プロジェクト目標への影響を管理します3。 |
| 適応性と回復力 (Adaptability & Resiliency) | 変化に適応し、回復力を持つこと。不確実な環境下でも迅速に立ち直り、方向修正を行う能力です3。 |
| 変革 (Change) | 想定される未来の状態へ到達するために変革を可能にすること。組織変革マネジメント（OCM）の視点を持ち、変化に対する抵抗を管理します3。 |
これらの原理は、特定の開発手法（アジャイルかウォーターフォールか）に依存せず、あらゆるプロジェクトシナリオにおいて「正しい判断」を下すための羅針盤となります。
2. ドメイン I：人 (People) - リーダーシップ、チーム形成、ステークホルダー
ECOの約42%を占める「人」ドメインは、プロジェクト成功の最大の要因である「人間系」の管理に焦点を当てています2。ここでは、従来の「指揮統制型（Command and Control）」から、チームの自律性を促す「サーバントリーダーシップ（Servant Leadership）」への移行が顕著です。PMは管理者ではなく、チームが成果を出せるように環境を整える「庭師」のような役割を期待されます。
2.1 コンフリクト（葛藤）マネジメントと交渉
プロジェクト環境において、異なる背景を持つステークホルダー間の意見の不一致は避けられません。PMBOKの視点では、コンフリクトは必ずしも悪いことではなく、適切に管理されれば創造的な解決策やチームの結束強化につながる機会と捉えられます。試験では、状況に応じた最適な解決技法を選択するシチュエーション問題が頻出します6。
コンフリクト解決と交渉の重要用語
| 用語 (Term) | 定義 (Definition) | 試験における適用シナリオとニュアンス (Context) |
| コラボレーション (Collaborate/Problem Solve) | 双方の視点を取り入れ、根本原因を特定して解決する手法。Win-Winの結果を目指す。 | 推奨される最善策。時間はかかるが、長期的な関係維持と問題の再発防止に最も効果的。選択肢にこれがある場合は正解の可能性が高い7。 |
| 妥協 (Compromise/Reconcile) | 双方が主張を一部取り下げ、中間点で合意する手法。Lose-Loseの側面がある。 | 膠着状態を打開する必要がある場合や、時間が限られている場合に有効。一時的な解決策として選ばれることが多い7。 |
| 強制 (Force/Direct) | 権限を用いて一方の意見を押し通す手法。Win-Loseの結果となる。 | 緊急時、安全に関わる問題、あるいは不人気だが重要な決定を下す必要がある場合に限定的に使用される7。 |
| 鎮静 (Smooth/Accommodate) | 相違点を軽視し、同意できる点を強調して調和を保つ手法。譲歩に近い。 | 根本解決にはならないが、関係性の維持を最優先する場合や、冷却期間が必要な場合に使用される7。 |
| 撤退 (Withdraw/Avoid) | 問題から立ち去る、あるいは決定を先送りにする手法。 | 準備不足、情報不足、他により重要な問題がある場合、または感情的になりすぎている場合の一時的措置7。 |
| Win-Win交渉 | 双方が利益を得る合意を目指す交渉スタイル。 | コラボレーションと同様、長期的なパートナーシップにおいて重要。 |
| BATNA (Best Alternative to a Negotiated Agreement) | 交渉が決裂した場合の最善の代替案。 | 交渉力を高めるために、事前にBATNAを把握しておくことが重要。 |
| 感情的知性 (Emotional Intelligence: EI/EQ) | 自己および他者の感情を認識・理解し、適切に管理する能力10。 | コンフリクトの予兆を察知し、エスカレーションを防ぐために不可欠なスキル。 |
2.2 リーダーシップスタイルとチーム力学
プロジェクトマネージャーは、チームの発達段階や状況に応じてリーダーシップスタイルを使い分ける必要があります。
リーダーシップとチーム形成の重要用語
| 用語 (Term) | カテゴリー | 定義と解説 (Analysis) |
| サーバントリーダーシップ | リーダーシップ | チームメンバーへの「奉仕」を第一義とし、障害（Impediments）を取り除き、チームの成長と自律を促すスタイル。アジャイル開発において必須の概念であり、「水と食料を運ぶ」役割とも表現される4。 |
| 変革型リーダーシップ (Transformational) | リーダーシップ | ビジョンと情熱によってチームを鼓舞し、革新と変化を促進するスタイル。組織変革が必要な場面で有効4。 |
| 取引型リーダーシップ (Transactional) | リーダーシップ | 報酬と罰則に基づいて目標達成を図るスタイル。例外管理（Management by Exception）を特徴とし、ルーチンワークや安定した環境で機能する4。 |
| レッセフェール (Laissez-faire) | リーダーシップ | 「なすがまま」に任せる放任型スタイル。高度なスキルを持ち、自律性の高い専門家チームに対してのみ有効だが、方向性を見失うリスクもある11。 |
| 状況的リーダーシップ (Situational Leadership) | 理論モデル | メンバーの能力と意欲（成熟度）に応じて、指示型（S1）→コーチ型（S2）→支援型（S3）→委任型（S4）へとスタイルを変化させる理論（Hersey & Blanchardなど）4。 |
| タックマンモデル | チーム開発 | チーム形成の5段階：成立期 (Forming)、動乱期 (Storming)、安定期 (Norming)、遂行期 (Performing)、解散期 (Adjourning)。PMは動乱期におけるコンフリクトを乗り越えさせ、遂行期へと導く必要がある13。 |
| マズローの欲求5段階説 | 動機付け | 生理的、安全、社会的、承認、自己実現の順に欲求が満たされるとする理論。下位の欲求が満たされないと上位の欲求は動機付け要因とならない。 |
| ハーズバーグの二要因理論 | 動機付け | 衛生要因（不満を防ぐ：給与、環境）と動機付け要因（満足を高める：達成、承認）を区別する。給与を上げても不満は減るが、やる気が上がるとは限らないとする13。 |
| マクレガーのX理論・Y理論 | 動機付け | X理論（人は仕事を嫌う＝厳格な管理が必要）、Y理論（人は自己実現を望む＝自律性を尊重）という人間観の対比。現代のPMはY理論に基づきエンパワーメントを行うべきとされる。 |
| エンパワーメント | チーム育成 | 権限移譲。チームメンバーが自ら意思決定を行えるようにし、自己組織化（Self-organization）を促進すること10。 |
| バーチャルチーム | チーム形態 | 地理的に分散したチーム。コミュニケーションの非同期性や文化的な壁が課題となる。「フィッシュボーンウィンドウ」などの常時接続ツールや、信頼構築のための工夫が試験で問われる10。 |
2.3 ステークホルダー・エンゲージメント
ステークホルダーは「管理」する対象ではなく、プロジェクトの成功のために「関与（Engage）」してもらうパートナーです。
ステークホルダー関連用語
| 用語 (Term) | 定義 (Definition) | 試験的意義 (Exam Relevance) |
| ステークホルダー登録簿 | 識別された全てのステークホルダーの情報、期待、影響力などを記録した文書。プロジェクト初期に作成され、随時更新される16。 | 個人の名前だけでなく、分類や戦略も含む重要文書。 |
| サリエンスモデル | ステークホルダーを「権力 (Power)」「正当性 (Legitimacy)」「緊急性 (Urgency)」の3軸で分析するモデル。 | 誰を優先すべきかを決定するために使用される。「決定的なステークホルダー」は3つ全てを持つ。 |
| 権力と関心度のグリッド (Power/Interest Grid) | ステークホルダーを権力と関心度の2軸で分類し、対応戦略（密に管理、満足させる、情報提供、監視）を決定するツール。 | 最も頻出する分析ツール。「権力高・関心高」のグループは「密に管理（Manage Closely）」する必要がある。 |
| ステークホルダー・エンゲージメント計画書 | 現在の関与レベル（不認知、抵抗、中立、支援、指導）から、望ましい関与レベルへ移行させるための戦略を記述した計画書。 | 「抵抗」しているステークホルダーを「中立」や「支援」に変えるための具体的なアクションが含まれる。 |
| ステークホルダー・キューブ | 3次元（権力、関心、態度など）でステークホルダーを分析するモデル。 | より複雑な関係性を可視化するために用いられる。 |
3. ドメイン II：プロセス (Process) - アジャイル、ハイブリッド、予測型
プロセスのドメインは試験の50%を占める中核部分です。ここでは、伝統的な予測型（ウォーターフォール）の知識エリアに加え、アジャイルおよびハイブリッド手法が深く統合されています2。実際の試験問題の半数以上がアジャイルまたはハイブリッドのシナリオであることを踏まえ、両者の用語と概念を詳細に解説します。
3.1 アジャイルおよび適応型アプローチ (Agile & Adaptive)
アジャイルは単なる開発手法ではなく、マインドセット（考え方）です。不確実性の高い環境下で、変化を受け入れ、早期に価値を提供することを目指します。
スクラム (Scrum) 関連用語
スクラムはアジャイルの中で最も普及しているフレームワークであり、PMP試験におけるアジャイル問題の多くがスクラムの用語や概念に基づいています。
| 用語 (Term) | 定義 (Definition) | 試験における重要ポイント (Key Insights) |
| スプリント (Sprint) | 1〜4週間の固定された期間（タイムボックス）。この期間内に開発、テスト、レビューを行い、インクリメントを作成する18。 | 期間中にスコープ（スプリントゴール）を変更してはならない。これによりチームに集中とリズム（ケイデンス）をもたらす。 |
| プロダクトバックログ | プロジェクトで必要な機能、要件、修正などの優先順位付きリスト。常に変化し続ける「生きた文書」19。 | プロダクトオーナー (PO) が管理・優先順位付けの全責任を持つ。チームはここからアイテムを選択する。 |
| スプリントバックログ | 特定のスプリントで完了させるために、開発チームがプロダクトバックログから選択したアイテム群19。 | 開発チームが所有し管理する。スプリントゴール達成のための詳細な作業計画を含む。 |
| インクリメント (Increment) | スプリント終了時に完成している、動作可能なプロダクトの増分。 | 「完成の定義 (DoD)」を満たしている必要があり、POがリリースを判断すれば即座に提供可能な状態であるべき。 |
| スクラムマスター | チームがスクラムの理論、プラクティス、ルールを理解し、遵守できるよう支援する「サーバントリーダー」19。 | 指示命令権限はないが、プロセスに対する権限を持つ。最大の責務は障害除去 (Impediment removal)。 |
| プロダクトオーナー (PO) | プロダクトの価値を最大化することに責任を持つ一人（委員会ではない）19。 | バックログの優先順位決定権を持つ唯一の人物。ROI（投資対効果）に責任を持つ。ステークホルダーとチームの橋渡し役。 |
| 開発チーム (Development Team) | インクリメントを作成する専門家集団。自己組織化され、機能横断的（Cross-functional）である19。 | 上下関係のないフラットな構造。タスクの割り当て（Assign）ではなく、自ら選択（Pull）する。 |
| デイリースクラム (Daily Scrum) | 毎日同じ時間・場所で行う15分以内のミーティング。進捗、今日の予定、障害を確認する18。 | 報告会ではなく、チームの「同期」と「再計画」の場。PM/スクラムマスターはこれを聞いて障害除去に動く。 |
| スプリントレビュー | スプリントの終了時に、成果物（インクリメント）をステークホルダーにデモし、フィードバックを得るイベント。 | プロダクトの検査と適応の場。ここでバックログの優先順位が変わることもある。 |
| レトロスペクティブ (Retrospective) | スプリントの最後に、プロセス、人、ツールに関する改善点を議論する「振り返り」18。 | 「継続的改善 (Kaizen)」の核心。批判ではなく建設的な改善アクションに焦点を当てる。 |
| バックログリファインメント | 次のスプリントに備えて、バックログアイテムの内容を明確化し、詳細を詰め、見積もりを行う活動（グルーミング）19。 | 公式なイベントではないが、スプリント期間の10%程度を充てて継続的に行う重要な活動。 |
その他アジャイル・リーン重要用語
| 用語 (Term) | 定義 (Definition) | 解説 (Analysis) |
| MVP (Minimum Viable Product) | 顧客からのフィードバックを得て学習するために必要な、最小限の機能を備えた製品バージョン19。 | 「早期の失敗」と「検証された学習 (Validated Learning)」を重視する概念。完成品ではない。 |
| MMF (Minimum Marketable Feature) | 顧客に価値を提供でき、収益を生み出せる最小の機能単位19。 | MVPの次のステップとして、市場投入可能な最小セット。ビジネス価値実現に直結する。 |
| ユーザーストーリー | 「[ユーザー]として、[機能]が欲しい。それは[価値]のためだ」という形式で記述される要件14。 | 3C（Card, Conversation, Confirmation）が重要。詳細な仕様書ではなく、会話のきっかけとしての役割を持つ。 |
| ストーリーポイント | 機能の実装にかかる規模や複雑さを相対的に見積もる単位。フィボナッチ数列（1, 2, 3, 5, 8...）がよく使われる19。 | 時間（Hour）ではなく規模（Size）で見積もることで、個人のスキル差によるブレを防ぐ。 |
| ベロシティ (Velocity) | チームが1スプリントで完了できたストーリーポイントの合計量19。 | チームの生産性指標だが、チーム間の比較には使用してはならない。将来の予測（いつ終わるか）に使用する。 |
| バーンダウンチャート | 残作業量を時系列でプロットしたグラフ。理想線と比較して進捗を可視化する19。 | 残り作業の可視化。線が理想線より上にあれば遅延、下にあれば順調。 |
| カンバン (Kanban) | タスクを可視化し、**WIP（Work In Progress：仕掛り作業）**を制限することでフローを最適化するリーン手法。 | 途中やめ、途中始めを減らし、リードタイムを短縮する。「プル（引っ張り）システム」を採用。 |
| 定義済み (Definition of Done: DoD) | インクリメントが完成したとみなされるための品質基準チェックリスト（例：テスト完了、文書化完了など）20。 | 品質の透明性を確保する。スプリントレビューの前に必ず満たす必要がある。 |
| 準備完了の定義 (Definition of Ready: DoR) | バックログアイテムがスプリント計画に投入できる状態（明確さ、テスト可能性など）にあるかの基準20。 | 開発チームが着手可能であることを保証し、手戻りを防ぐ。 |
| スパイク (Spike) | 技術的な不確実性を解消するためや、見積もりのための調査・実験を行う特別なタスク。 | リスク軽減のためにタイムボックスを切って行われる。 |
| インフォメーションラジエーター | 壁に貼られたチャートやカンバンボードなど、誰でも見ることができる情報表示16。 | 透明性を高め、プル型のコミュニケーションを促進する。 |
| XP (Extreme Programming) | 技術的プラクティス（ペアプログラミング、TDD、リファクタリング、継続的インテグレーション）を重視するアジャイル手法18。 | 品質の向上と変更への対応力を高める。 |
3.2 予測型（ウォーターフォール）プロセス
予測型アプローチは、要件が明確で変更が少ないプロジェクトや、コンプライアンス要件が厳しい建設・エンジニアリング分野で依然として重要です。計画（Plan）を重視し、計画通りに進めることが成功とされます。
統合・スコープ・スケジュール管理用語
| 用語 (Term) | 定義 (Definition) | 試験的意義・関連性 (Exam Relevance) |
| プロジェクト憲章 | プロジェクトの存在を正式に認可し、PMにリソース使用権限を与える文書。ビジネスケースに基づく14。 | プロジェクトの開始（Initiating）に不可欠。スポンサーが発行する。 |
| 統合変更管理 | スコープ、スケジュール、コストへの変更要求をレビューし、承認・却下を行うプロセス22。 | 変更管理委員会 (CCB) が関与。承認された変更のみがベースラインに反映される。 |
| WBS (Work Breakdown Structure) | プロジェクトのスコープを管理可能な「ワークパッケージ」まで階層的に分解したもの21。 | 100%ルール（WBSに含まれない作業はプロジェクト外）が適用される。スコープベースラインの一部。 |
| スコープクリープ | 時間、コスト、リソースの調整なしに、制御不能な状態でプロジェクトスコープが拡大すること25。 | 変更管理プロセスの欠如が原因。「顧客満足」とは区別されるべき悪しき現象。 |
| ゴールドプレーティング | 顧客から要求されていない機能や品質を、PMやチームの判断で勝手に追加すること（金メッキ）20。 | リソースの浪費であり、PMIイズムでは推奨されない。 |
| クリティカルパス法 (CPM) | プロジェクトの最短完了期間を決定する、フロート（余裕）がゼロの活動経路24。 | クリティカルパス上のタスクが遅れると、プロジェクト全体が遅延する。重点管理対象。 |
| トータルフロート | プロジェクトの終了日を遅らせることなく、ある活動を遅らせることができる期間24。 | クリティカルパス上のタスクはトータルフロートがゼロ（またはマイナス）。 |
| フリーフロート | 直後の後続活動の早期開始日（ES）を遅らせることなく、ある活動を遅らせることができる期間27。 | 個々のタスクレベルでの余裕。 |
| クラッシング | コストを追加（リソース増員、残業など）して、スケジュールを短縮する技法24。 | コスト増加のリスクがある。クリティカルパス上のタスクに適用する。 |
| ファストトラッキング | 本来順番に行う活動を並行して行う（重複させる）ことで期間を短縮する技法24。 | 手戻り（Rework）やリスク増加の可能性がある。 |
| ローリングウェーブ計画法 | 直近の作業は詳細に、遠い将来の作業は粗く計画する段階的詳細化の手法。 | 不確実性が高いプロジェクトで有効。ウォーターフォールでも柔軟性を持たせる手法。 |
コスト・品質・リスク・調達管理用語
| 用語 (Term) | 定義 (Definition) | 解説 (Analysis) |
| アーンドバリューマネジメント (EVM) | スコープ、スケジュール、コストを統合してプロジェクトのパフォーマンスを測定する手法28。 | 現状把握だけでなく、将来予測（EAC, ETC）にも使用される強力なツール。 |
| コンティンジェンシー予備 | 識別されたリスク（既知の未知）に対応するために、コストやスケジュールに含まれる予備26。 | ベースラインに含まれ、PMの権限で使用可能。 |
| マネジメント予備 | 識別されていないリスク（未知の未知）に対応するための予備27。 | ベースラインには含まれず、使用には変更管理手続きが必要。 |
| 品質コスト (COQ) | 品質の確保にかかる総コスト。適合コスト（予防、評価）と不適合コスト（内部失敗、外部失敗）に分類される。 | 予防コストをかける方が、後で欠陥を直す（不適合コスト）よりも安上がりであるという考え方。 |
| 石川特性要因図 | 問題の根本原因を特定するための図（フィッシュボーン・ダイアグラム）。人、機械、方法などに分類して分析30。 | 「なぜなぜ分析」と共に使用される品質管理の基本ツール。 |
| パレート図 | 発生頻度の高い順に項目を並べた棒グラフと累積曲線（80:20の法則）30。 | 改善効果の最も高い「重要な少数（Vital Few）」の問題を特定するために使用。 |
| 管理図 (Control Chart) | プロセスが安定しているか（管理限界内か）を時系列で監視する図。上方管理限界(UCL)と下方管理限界(LCL)を持つ30。 | 「7つのルール」（7点が平均の片側に連続するなど）による異常検知が試験で問われる。 |
| リスクレジスター | 識別されたリスク、その原因、影響、確率、対応策、担当者を記録する文書16。 | リスク管理活動の中心となる文書。常に更新される。 |
| 二次リスク (Secondary Risk) | リスク対応策を実施した結果として、新たに発生するリスク16。 | 例：火災リスク回避のためにスプリンクラーを設置したら、水漏れリスクが発生した。 |
| 残存リスク (Residual Risk) | リスク対応策を実施した後にも残るリスク27。 | コンティンジェンシー予備でカバーされるべき部分。 |
| 定額契約 (Fixed Price: FP) | 総額を固定する契約。スコープが明確な場合に適す31。 | ベンダー（受注者）側のコストリスクが高い。仕様変更があると揉めやすい。 |
| 実費償還契約 (Cost Reimbursable: CR) | かかった実費に利益を上乗せして支払う契約。スコープが不明確な場合に適す31。 | 発注者（購入者）側のコストリスクが高い。コスト増大を防ぐための監査が必要。 |
| タイム＆マテリアル (T&M) | 時間単価と材料費で支払う契約。人的支援や小規模、緊急案件に適す31。 | ハイブリッド型契約。上限額（Not to exceed）を設定することが一般的。 |
3.3 EVM計算式とその解釈（徹底解説）
EVM（アーンドバリューマネジメント）はPMP試験の鬼門とされますが、公式の暗記以上に「その数字が何を意味するか」の解釈が重要です。
| 指標 (Metric) | 略称 | 計算式 (Formula) | 解釈と試験対策 (Interpretation & Exam Tip) |
| アーンドバリュー | EV | 完了作業 × 予算単価 | 「実際にどれだけの価値（仕事）を生み出したか」。全ての計算の基礎となる最重要数値。 |
| プランドバリュー | PV | 計画作業 × 予算単価 | 「この時点までにどれだけやる予定だったか」。スケジュールの基準。 |
| 実コスト | AC | 実際にかかった費用 | 「いくら財布から出ていったか」。コストの基準。 |
| コスト差異 | CV | $CV = EV - AC$ | 正の値（＋）：予算内（黒字）。負の値（－）：予算超過（赤字）。「EV（稼ぎ）からAC（出費）を引く」と覚える。 |
| スケジュール差異 | SV | $SV = EV - PV$ | 正の値（＋）：進んでいる。負の値（－）：遅れている。「EV（実績）からPV（予定）を引く」。 |
| コスト効率指数 | CPI | $CPI = EV / AC$ | $1.0$以上：効率的（良い）。$1.0$未満：非効率（悪い）。例えば0.8なら「1ドルの予算で80セント分の仕事しかしていない」。 |
| スケジュール効率指数 | SPI | $SPI = EV / PV$ | $1.0$以上：早い。$1.0$未満：遅い。 |
| 完成時総予算 | BAC | - | プロジェクトの総予算（ベースライン）。変更承認がない限り不変。 |
| 完成時総コスト見積り | EAC | $EAC = BAC / CPI$ | 「現在のコスト効率が今後も続く場合」の最終予測コスト。最も一般的な予測式。 |
| 残作業コスト見積り | ETC | $ETC = EAC - AC$ | 「あといくらかかるか」。 |
| 残作業効率指数 | TCPI | $\frac{(BAC - EV)}{(BAC - AC)}$ | 「残りの予算で、どれだけの効率で作業しなければならないか」。$1.0$を超えると、今までより効率を上げる必要があり、達成困難な場合が多い。 |
インサイト: 試験では「CPIが0.8、SPIが0.9のプロジェクトの状態は？」といった問われ方をします。この場合、「予算超過かつスケジュール遅延」という最悪の状態を即座に判断し、是正処置（クラッシングやスコープ調整など）を提案する選択肢を選ぶ必要があります。
4. ドメイン III：ビジネス環境 (Business Environment)
全体の8%と割合は少ないものの、プロジェクトマネージャーが単なる「作業管理者」から「ビジネスリーダー」へと視座を高めるために不可欠なドメインです。コンプライアンス、組織変革、価値実現がキーワードです5。
4.1 コンプライアンス、ガバナンス、組織構造
プロジェクトは真空中で行われるのではなく、組織の戦略や法的要件の枠組みの中で実行されます。
| 用語 (Term) | 定義 (Definition) | 解説と試験的意義 (Insight) |
| 組織のプロセス資産 (OPA) | 組織固有のプロセス、ポリシー、テンプレート、過去のプロジェクト知識ベース（教訓、履歴データ）27。 | チームが利用・更新できる内部資産。「教訓（Lessons Learned）」はOPAの最重要構成要素。 |
| 組織体の環境要因 (EEF) | 市場環境、法規制、組織文化、インフラ、ステークホルダーのリスク許容度など、チームがコントロールできない制約条件27。 | プロジェクト憲章作成時の入力情報。所与の条件として扱う。 |
| ガバナンス | 組織がプロジェクトを指揮・管理するための枠組み（ポリシー、ルール、プロセス、意思決定構造）16。 | プロジェクトが組織の戦略目標と整合しているかを監視・統制する機能。フェーズゲートでの審査などが該当。 |
| コンプライアンス | 政府規制、法的要件、社内規定、品質標準などを遵守すること15。 | コンプライアンス違反はプロジェクトの強制終了リスクとなる。「品質」の一部としても扱われるが、法的拘束力が強い。 |
| PMO (Project Management Office) | プロジェクト関連のガバナンスプロセスを標準化し、リソースやツールを共有する組織16。 | 支援型（テンプレート提供）、コントロール型（コンプライアンス要求）、指揮型（直接管理）の3形態がある。試験ではPMOのタイプによってPMの権限範囲が変わる点に注意。 |
| 機能型組織 | 部門ごとに専門化された伝統的な組織構造。PMの権限は弱く、リソース調整が困難16。 | 「サイロ化」の問題が発生しやすい。 |
| マトリックス型組織 | 機能型とプロジェクト型の中間。弱い（PM権限小）、バランス（中）、強い（PM権限大）に分類される38。 | メンバーは「二人の上司（機能マネージャーとPM）」を持つため、コンフリクトが発生しやすい。 |
| プロジェクト型組織 | PMに最大の権限があり、チームはプロジェクト専任となる組織16。 | プロジェクト終了後のメンバーの行き場（Home）がない「No Home」問題がある。 |
4.2 ベネフィット実現と組織変革
プロジェクトが完了した後、その成果物がどのようにビジネス価値（ベネフィット）を生み出すかを計画・管理します。
| 用語 (Term) | 定義 (Definition) | 解説 (Insight) |
| ベネフィット実現計画書 | プロジェクトが生み出すベネフィット、その実現時期、測定方法、責任者を定義した文書39。 | ビジネスケースと対になり、プロジェクト終了後も運用部門で参照される。成果物が運用に移管された後の価値創出を追跡する。 |
| バリューストリームマップ (VSM) | 製品やサービスが顧客に届くまでの「情報の流れ」と「物の流れ」を可視化し、無駄（Muda）を排除するためのリーン手法41。 | プロセス改善やリードタイム短縮のために使用される。全体最適の視点を持つ。 |
| 組織変革 (Organizational Change) | 新しいプロセスやシステム導入に伴う、組織構造や文化の変革34。 | プロジェクトの成功には、成果物を受け入れる組織側の変化（チェンジマネジメント）が不可欠。 |
| ADKARモデル | 組織変革を個人の視点で捉えるモデル。Awareness（認知）、Desire（欲求）、Knowledge（知識）、Ability（能力）、Reinforcement（定着）13。 | 変革に対する抵抗を減らし、定着させるためのステップ。 |
| コッターの8段階変革モデル | 危機意識の醸成、連帯チームの結成、ビジョンの創造などを経て変革を定着させるプロセスモデル44。 | 大規模な組織変革を成功させるためのロードマップ。 |
5. モデル、メソッド、アーティファクト（PMBOK第7版の新概念）
PMBOK第7版では、特定のプロセスを強制するのではなく、状況に応じて適切な「モデル」「メソッド」「アーティファクト」を選択利用することが推奨されています13。これにより、プロジェクトマネージャーのツールボックスが拡張されました。
5.1 一般的に使用されるモデル
| モデル (Model) | カテゴリー | 概要 (Overview) |
| 状況的リーダーシップ II (SLII) | リーダーシップ | ケン・ブランチャード提唱。メンバーの発達レベル（D1〜D4）に合わせて、S1（指示型）〜S4（委任型）へとスタイルを変える13。 |
| OSCARモデル | コーチング | Outcome（成果）、Situation（状況）、Choices/Consequences（選択肢/結果）、Action（行動）、Review（レビュー）のフレームワーク13。 |
| コミュニケーションモデル | コミュニケーション | 符号化、発信、媒体、ノイズ、受信、復号化のプロセス。クロスカルチュラルなモデルも重要13。 |
| 動機付けモデル | 動機付け | ダニエル・ピンクの「モチベーション3.0」（自律性、熟達、目的）や、前述のマズロー、ハーズバーグなど45。 |
| クネビン (Cynefin) フレームワーク | 複雑性 | 問題を「単純」「繁雑」「複雑」「カオス」の4領域に分類し、それぞれの領域に適した意思決定アプローチ（Sensing, Categorizing, Respondingなど）を示唆する13。 |
| ステイシー行列 | 複雑性 | 「要件の確実性」と「技術の確実性」の2軸で、プロジェクトの複雑さをマッピングし、アジャイルの適用可否などを判断する13。 |
5.2 一般的に使用されるメソッド
| メソッド (Method) | カテゴリー | 概要 (Overview) |
| プランニングポーカー | 見積もり | アジャイルにおける相対見積もり手法。フィボナッチ数列のカードを使い、全員の合意形成を図る。声の大きい人の影響（アンカリング）を防ぐ19。 |
| ワイドバンド・デルファイ法 | 見積もり | 専門家の匿名性を保ちながら複数ラウンドの見積もりを行い、合意を形成する手法。 |
| 親和図 (Affinity Diagram) | データ収集・分析 | ブレインストーミングで出た大量のアイデアを、類似性に基づいてグループ化して整理する（KJ法に類似）20。 |
| ノミナルグループ技法 | データ収集・分析 | ブレインストーミングの後、参加者による投票やランキングを行い、アイデアの優先順位付けをする27。 |
| インパクトマッピング | 計画 | ゴール（Why）、アクター（Who）、インパクト（How）、デリバリー（What）をつなげて視覚化し、スコープとビジネスゴールの整合性を図る13。 |
5.3 頻出する紛らわしい用語の対比
試験では、似たような用語の微妙な定義の違いを問う問題が頻出します。以下の対比を明確に理解しておくことが重要です23。
| 用語 A | 用語 B | 決定的な違い (Key Distinction) |
| 妥当性確認 (Validate Scope) | 品質管理 (Control Quality) | 品質管理は「製品が仕様通りか（Correctness）」を内部で確認する（QC）。妥当性確認は「顧客が製品を受け入れるか（Acceptance）」を外部（顧客）と確認する。プロセス順序は通常 QC → Validate Scope。 |
| 精度 (Precision) | 正確さ (Accuracy) | 精度は「バラツキの小ささ（値が密集しているか）」。正確さは「真の値に近いか」。 |
| 検証済み成果物 (Verified Deliverables) | 受け入れ済み成果物 (Accepted Deliverables) | VerifiedはQC（品質管理）を通過したもの。AcceptedはValidate Scope（妥当性確認）で顧客が承認したもの。 |
| 品質保証 (Quality Assurance) | 品質管理 (Quality Control) | QAは「プロセス」に焦点を当て、欠陥を予防する（Manage Quality）。QCは「成果物」に焦点を当て、欠陥を発見・修正する。 |
| 是正処置 (Corrective Action) | 予防処置 (Preventive Action) | 是正は「既に発生した」パフォーマンスのズレを直す。予防は「将来発生しそうな」ズレを未然に防ぐ。 |
| 作業パフォーマンスデータ | 作業パフォーマンス情報 | データは実行プロセスから出る「生の数字（進捗率、実コストなど）」。情報は監視・コントロールプロセスでこれらを分析・比較し、「遅れている」「予算内」などの文脈が付加されたもの。 |
6. 結論と学習への提言
2025年のPMP試験およびPMBOKガイド第7版の体系は、プロジェクトマネジメントを単なる管理技術から、価値創造のためのリーダーシップ体系へと昇華させました。本報告書で網羅した200以上の用語と概念は、それぞれが断片的な知識ではなく、**「不確実な世界でいかにしてチームを導き、価値を届けるか」**という一つの大きな物語を構成しています。
特にアジャイルとハイブリッドアプローチの台頭は、PMに対して「計画に従うこと」よりも「変化への適応」を、そして「管理すること」よりも「チームへの奉仕」を求めています。受験者は、各用語の定義を覚えるだけでなく、それが「どの原理に基づいているか」「どのパフォーマンスドメインで活用されるか」「アジャイルとウォーターフォールでどう適用が異なるか」という多次元的な理解を深める必要があります。
本資料が、PMP資格取得を目指す専門家にとって、試験合格だけでなく、実務における真のプロフェッショナルとしての成長に寄与することを願っています。
