第1章 序論：プロジェクトマネジメント資格の変遷とCAPM®の現代的意義
1.1 プロジェクトマネジメント環境のパラダイムシフト
現代のビジネス環境は、VUCA（変動性、不確実性、複雑性、曖昧性）の時代と呼ばれるように、かつてない速度で変化している。これに伴い、プロジェクトマネジメントの標準も大きな転換期を迎えた。Project Management Institute (PMI) が発行する『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』は、第6版までの「プロセスベース（入力、ツールと技法、出力）」のアプローチから、第7版における「原理・原則ベース（Principles-based）」のアプローチへと根本的な構造改革が行われた。
この変化は、Certified Associate in Project Management (CAPM)® 資格試験にも直接的に反映されている。2023年に改定された試験内容概要（ECO: Exam Content Outline）は、単なるプロセスの暗記ではなく、プロジェクトマネジメントの「価値提供システム」としての理解を問うものへと進化した。特に、従来は上級資格であるPMI-PBA®（ビジネスアナリシス）やPMI-ACP®（アジャイル）で扱われていた領域が、エントリーレベルであるCAPMの試験範囲に大幅に組み込まれたことは、プロジェクト実務者に求められるスキルセットが「管理（Management）」から「価値創造（Value Delivery）」へと拡大していることを示唆している。
1.2 CAPM®試験の構造的特徴と学習戦略
本調査において、CAPM試験は以下の4つのドメインによって構成されていることが確認された。これは、プロジェクトマネージャーが直面する現代的な課題を網羅的に反映している。
- プロジェクトマネジメントの基礎とコアコンセプト（36%）: プロジェクトのライフサイクル、役割、および12の原理と8つのパフォーマンスドメインに関する理解。
- 予測型（計画主導型）アプローチ（17%）: 従来のウォーターフォール型開発における詳細計画、スケジュール管理、コスト管理、リスク管理。
- アジャイル・フレームワーク／アプローチ（20%）: 変化に適応するための反復的・漸進的な開発手法（スクラム、カンバン等）。
- ビジネスアナリシス・フレームワーク（27%）: ビジネスニーズの特定、要件の引き出し、ソリューションの評価。
特筆すべきは、ビジネスアナリシス（BA）領域が全体の約3割を占めている点である。これは、プロジェクトが「与えられた仕様通りにモノを作る」ことから「ビジネス上の問題を解決し、成果（Outcome）を提供する」ことへと重点が移行していることを意味する。
本報告書では、これら4つのドメインを深く掘り下げ、各領域における理論的背景、実践的メカニズム、および試験対策に不可欠な用語を体系的に解説する。特に、用語の定義にとどまらず、それらがプロジェクトの現場でどのように相互作用し、成功に寄与するかという文脈（コンテキスト）を重視して記述する。
第2章 プロジェクトマネジメントの基礎とコアコンセプト (Domain 1)
2.1 価値提供システムとしてのプロジェクト
プロジェクトマネジメントの基礎において最も重要な概念は、プロジェクトを単独の作業としてではなく、組織の戦略的目標を達成するための「価値提供システム（System for Value Delivery）」の一部として捉える視点である。ここでは、ポートフォリオ、プログラム、プロジェクトという階層構造と、それらがどのように連携してベネフィット（便益）を生み出すかが問われる。
組織戦略はポートフォリオマネジメントを通じて優先順位付けされ、プログラムやプロジェクトとして具体化される。プロジェクトは成果物（Output）を生み出し、それが運用されることで成果（Outcome）となり、最終的に組織にベネフィット（Benefit）と価値（Value）をもたらす。この一連の流れ（バリューストリーム）を理解することが、CAPM合格の第一歩となる。
2.2 PMBOK®ガイド第7版における「12の原理」
第7版への移行により、プロジェクトマネジメントは「正しいプロセスを踏むこと」から「正しい考え方（マインドセット）を持つこと」へと重心を移した。以下の12の原理は、予測型、適応型（アジャイル）、ハイブリッド型のいずれのアプローチにおいても適用される普遍的な行動指針である。
- スチュワードシップ（Stewardship）: 管理責任者として、誠実さ、配慮、信頼性を持って行動すること。単なる管理者ではなく、資源や倫理に対する「預かり人」としての姿勢が求められる。
- チーム（Team）: 協働的な環境を醸成すること。個人の能力だけでなく、チーム全体のシナジーを最大化する。
- ステークホルダー（Stakeholders）: 効果的に関与すること。単なる報告対象ではなく、価値共創のパートナーとして扱う。
- 価値（Value）: 常に価値に焦点を当てること。成果物の完成自体ではなく、それがもたらすビジネス価値を成功の基準とする。
- システム思考（Systems Thinking）: 全体観を持つこと。プロジェクト内外の要素がどのように相互作用し、影響し合うかを認識する。
- リーダーシップ（Leadership）: 権限によらないリーダーシップを発揮すること。役職に関わらず、すべてのメンバーが動機づけやコーチングを行うことができる。
- テーラリング（Tailoring）: 文脈に合わせて調整すること。一つの方法論を盲目的に適用するのではなく、プロジェクトの特性に応じてプロセスを最適化する。
- 品質（Quality）: プロセスと成果物に品質を作り込むこと。後工程での検査だけでなく、予防的な品質確保を重視する。
- 複雑さ（Complexity）: 複雑さに対処すること。人間の行動、システム、曖昧さから生じる予測不能な要素を認識し、対応する。
- リスク（Risk）: リスク対応を最適化すること。脅威を最小化し、好機を最大化するためのプロアクティブなアプローチをとる。
- 適応性と回復力（Adaptability and Resiliency）: 変化に対応し、打撃から回復する能力を持つこと。レジリエンス（強靭性）のあるチームを作る。
- チェンジ（Change）: 変革を可能にすること。プロジェクトは組織を現在の状態から将来の状態へと移行させる「変革の手段」である。
2.3 8つのパフォーマンスドメイン
原理が行動作法であるのに対し、パフォーマンスドメインは実際に活動を行う領域を示す。これらは独立しているのではなく、相互に依存し合いながら機能する。
- ステークホルダー: 関係者との生産的な関係構築。
- チーム: メンバーの成長と協働。
- 開発アプローチとライフサイクル: 予測型か適応型かの選択とフェーズ設定。
- 計画: 何を、いつ、どのように行うかの整理。
- プロジェクト作業: 計画の実行とリソース管理。
- デリバリー: スコープと品質を満たす成果物の提供。
- 測定: 進捗とパフォーマンスの評価。
- 不確実性: リスクと曖昧さへの対処。
2.4 基礎・コアコンセプト用語集（65語）
| 用語 (英語) | 用語 (日本語) | 解説・コンテキスト |
| Project | プロジェクト | 独自のプロダクト、サービス、所産を創造するために実施される有期性の業務。定常業務とは異なり、明確な開始と終了を持つ。 |
| Operations | 定常業務 | ビジネス機能を維持するために継続的に行われる反復的な活動。プロジェクト終了後の成果物は定常業務に移管される。 |
| Program Management | プログラムマネジメント | 個別に管理するだけでは得られない利益やコントロールを得るために、相互に関連するプロジェクト群を調整して管理すること。 |
| Portfolio Management | ポートフォリオマネジメント | 戦略目標を達成するために、プロジェクト、プログラム、業務をグループ化し、優先順位付けと資源配分を行う管理活動。 |
| Organizational Project Management (OPM) | 組織的プロジェクトマネジメント | ポートフォリオ、プログラム、プロジェクトマネジメントを統合し、組織の戦略的目標とリンクさせるフレームワーク。 |
| Predictive Approach | 予測型アプローチ | 開始時にスコープ、コスト、スケジュールを詳細に定義し、計画通りに進める手法。ウォーターフォール型とも呼ばれる。 |
| Adaptive Approach | 適応型アプローチ | 要件の変更や頻繁なフィードバックを前提とし、短いサイクルで計画を修正しながら進める手法。アジャイル型とも呼ばれる。 |
| Hybrid Approach | ハイブリッド・アプローチ | 予測型と適応型の要素を組み合わせた手法。例：ハードウェア開発は予測型、ソフトウェア部分はアジャイル型で進める等。 |
| Product Lifecycle | プロダクト・ライフサイクル | 製品の構想から、開発、市場投入、成長、成熟、そして撤退までの一連の段階。プロジェクトライフサイクルより長い概念。 |
| Project Lifecycle | プロジェクト・ライフサイクル | プロジェクトの開始から終了までの一連のフェーズ（段階）。業界やプロジェクトの性質により異なる（例：要件定義→設計→実装→テスト）。 |
| Phase Gate | フェーズ・ゲート | フェーズの終了時に行われるレビューポイント。次のフェーズへの進むか、修正するか、中止するかを決定する。キル・ポイントとも呼ばれる。 |
| Project Management Plan | プロジェクトマネジメント計画書 | プロジェクトの実行、監視、コントロール、終結の方法を記述した包括的な文書。すべての補助計画書を統合したもの。 |
| Product Management Plan | プロダクトマネジメント計画書 | 製品そのものの特徴、市場展開、ライフサイクル管理に焦点を当てた計画。プロジェクト計画とは区別される。 |
| Baseline | ベースライン | 進捗測定の基準となる、承認された計画（スコープ、スケジュール、コスト）。変更管理プロセスを経ないと変更できない。 |
| Requirement | 要求事項 | プロダクトやサービスが満たすべき条件や能力。ステークホルダーのニーズ、期待、義務を定量化・文書化したもの。 |
| Deliverable | 成果物 | プロジェクトのフェーズや完了時に生成される、独自の検証可能なプロダクト、結果、または能力。 |
| Milestone | マイルストーン | プロジェクトスケジュール上の重要な時点やイベント。期間を持たない（所要期間ゼロ）ポイントとして表現される。 |
| Task Duration | タスク所要期間 | 個々のアクティビティを完了するために必要な作業時間（または経過期間）。マイルストーンとは区別される。 |
| Business Case | ビジネス・ケース | プロジェクトへの投資の妥当性を、コスト対効果や戦略的整合性の観点から正当化する文書。プロジェクト憲章の入力となる。 |
| Benefits Management Plan | ベネフィット・マネジメント計画書 | プロジェクトが生み出すベネフィット（便益）がいつ、どのように実現され、測定されるかを記述した文書。 |
| Constraints | 制約条件 | プロジェクトチームの選択肢を制限する要因。鉄の三角形（スコープ、スケジュール、コスト）や、資源、品質、リスクなどが含まれる。 |
| Assumptions | 前提条件 | 計画時点において、証拠なしに真実、リアル、または確実であると見なされる要因。リスクの源泉となり得る。 |
| Issues | 課題（イシュー） | 現在発生しており、プロジェクトに悪影響を与えている問題点。リスク（未来の不確実性）とは異なり、即時の対応が必要。 |
| Risk | リスク | プロジェクト目標にプラスまたはマイナスの影響を与える可能性のある、不確実な事象や状態。 |
| Scope Creep | スコープ・クリープ | 時間、コスト、資源の調整（承認）なしに、プロジェクトのスコープが制御されずに拡大・肥大化する現象。 |
| Project Manager (PM) | プロジェクトマネジメント | プロジェクト目標の達成に責任を持つ人物。チームをリードし、ステークホルダー間の調整役となる。 |
| Project Sponsor | プロジェクト・スポンサー | プロジェクトに資金やリソースを提供し、プロジェクトの成功に対して最終的な責任を持つ上位の個人またはグループ。 |
| Product Owner (PO) | プロダクトオーナー | アジャイル環境において、プロダクトの価値を最大化することに責任を持つ役割。バックログの優先順位を決定する。 |
| Stakeholder | ステークホルダー | プロジェクトの決定、活動、成果に影響を与える、あるいはそれらから影響を受ける個人、グループ、組織。 |
| Project Team | プロジェクトチーム | プロジェクトの作業を実行し、成果物を作成するために必要なメンバーの集まり。 |
| Functional Manager | 機能部門マネージャー | 組織内の特定の機能分野（人事、経理、エンジニアリング等）を統括するマネージャー。リソースの所有者であることが多い。 |
| Project Management Office (PMO) | プロジェクトマネジメント・オフィス | プロジェクト関連のガバナンス・プロセスを標準化し、資源、方法論、ツールの共有を促進する組織構造。 |
| Supportive PMO | 支援型PMO | テンプレート、ベストプラクティス、トレーニングなどを提供し、コンサルタント的な役割を果たすPMO。管理度は低い。 |
| Controlling PMO | コントロール型PMO | 支援に加え、特定のフレームワークや手法の採用を要求し、コンプライアンスを監査するPMO。管理度は中程度。 |
| Directive PMO | 指揮型PMO | プロジェクトを直接管理・指揮するPMO。プロジェクトマネージャーはPMOに所属し報告する。管理度は高い。 |
| Stakeholder Register | ステークホルダー登録簿 | 特定されたステークホルダーの身元、評価、分類（権力、関心度など）を記録した文書。 |
| Stakeholder Analysis | ステークホルダー分析 | ステークホルダーの利益、期待、重要性、影響力を体系的に収集・分析する技法。 |
| Power/Interest Grid | 権力・関心度グリッド | ステークホルダーを「権力」と「関心度」の2軸で分類し、管理戦略（密に管理、満足させる等）を決定するツール。 |
| Enterprise Environmental Factors (EEF) | 組織の環境要因 | プロジェクトチームの管理下にないが、プロジェクトに影響を与える内部・外部の条件（市場状況、法規制、組織文化、インフラ等）。 |
| Organizational Process Assets (OPA) | 組織のプロセス資産 | 組織が保有し利用可能な、プロセス、ポリシー、手順、および知識ベース（過去の教訓、履歴情報、テンプレート）。 |
| Code of Ethics | 倫理・職務規定 | PMI会員および資格保有者が遵守すべき倫理規定。責任、尊重、公正、誠実の4つの価値観に基づく。 |
| Tailoring | テーラリング | プロジェクト固有の状況、規模、複雑さに合わせて、PM手法、プロセス、ツールを適切に選択・調整すること。 |
| Change Management | 変更マネジメント | プロジェクトのスコープ、スケジュール、コスト等のベースラインに対する変更要求を特定、文書化、承認、管理するプロセス。 |
| Change Control Board (CCB) | 変更管理委員会 | 変更要求をレビューし、承認、保留、または却下する権限を持つ正式なグループ。 |
| Configuration Management | 構成管理 | プロダクトの機能的・物理的特性を文書化し、変更を制御・記録し、適合性を監査する活動。バージョンの管理。 |
| Lessons Learned Register | 教訓登録簿 | プロジェクト中に得られた知識や経験（成功例、失敗例、改善点）を記録し、将来のプロジェクトに役立てるための文書。 |
| Issue Log | 課題ログ | 発生した課題（イシュー）の内容、担当者、解決期限、ステータスを記録・追跡するための文書。 |
| Assumption Log | 前提条件ログ | プロジェクトの進行に伴い特定された前提条件と制約条件を記録し、そのステータス（有効か無効か）を追跡する文書。 |
| Conflict Management | コンフリクト・マネジメント | 意見の不一致や対立を建設的に解決するスキル。強制、鎮静、妥協、撤退、問題解決（コラボレーション）の5つの技法がある。 |
| Emotional Intelligence (EQ) | 感情的知性 | 自分自身と他者の感情を認識、理解、管理する能力。リーダーシップやチームビルディングに不可欠。 |
| Servant Leadership | サーバント・リーダーシップ | チームに奉仕し、障害を取り除き、メンバーの成長を支援することで成果を出すリーダーシップスタイル。アジャイルで推奨される。 |
| Leadership vs Management | リーダーシップ vs マネジメント | リーダーシップは「人」に焦点を当て、ビジョンを示し動機づけること。マネジメントは「物・事」に焦点を当て、計画・維持・制御すること。 |
| Active Listening | アクティブ・リスニング | 話し手の言葉だけでなく、感情や意図まで含めて能動的に聴く技法。コミュニケーションの質を高める。 |
| Brainstorming | ブレーンストーミング | 批判を禁止し、自由奔放に多数のアイデアを出し合う集団発想法。質より量を重視する。 |
| Focus Groups | フォーカス・グループ | 訓練されたモデレーターの下で、選ばれたステークホルダーのグループが特定のテーマについて議論し、意見を収集する技法。 |
| Interview | インタビュー | ステークホルダーと個別に対話し、情報を引き出す技法。機密情報の収集や深い理解に適している。 |
| Virtual Teams | バーチャルチーム | 地理的に分散し、通信技術を用いて連携して活動するチーム。コミュニケーション計画が重要となる。 |
| Resource Management | 資源マネジメント | 人材、設備、資材などの資源を計画、確保、管理し、効率的に活用するプロセス。 |
| RACI Chart | RACIチャート | 責任分担マトリックスの一種。実行責任（Responsible）、説明責任（Accountable）、相談対応（Consulted）、情報提供（Informed）を定義する。 |
| Quality | 品質 | 要求事項に対する適合度、および使用目的への適合性（フィット・フォー・ユース）。グレード（等級）とは異なる概念。 |
| Grade | グレード（等級） | 同一の機能用途を持つが、技術的特性が異なるカテゴリー（例：エコノミークラスとファーストクラス）。低品質は問題だが、低グレードは問題ではない。 |
| Complexity | 複雑さ | 多くの要素が相互に関連し、不確実性や曖昧さを含むため、単純な因果関係で予測できない状態。 |
| Ambiguity | 曖昧さ | 概念的な不明瞭さや、複数の解釈が可能な状態。漸進的具体化によって対処する。 |
| Project Initiation | プロジェクトの立ち上げ | プロジェクトまたはフェーズの開始を正式に認可し、初期のスコープとリソースを定義するプロセス。 |
| Project Closure | プロジェクトの終結 | プロジェクト、フェーズ、または契約を正式に完了させるプロセス。成果物の移管、教訓の記録、リソースの解放を含む。 |
第3章 予測型（計画主導型）アプローチ (Domain 2)
3.1 予測型アプローチのメカニズム
予測型アプローチ（一般にウォーターフォールモデルと呼ばれる）は、プロジェクトの初期段階で最終的な成果物を明確に定義できる場合に最も効果を発揮する。このアプローチの核心は「事前の詳細な計画」にある。変更はコストとリスクを増大させる要因と見なされるため、厳格な変更管理プロセスを通じて制御される。
CAPM試験のこのドメインでは、PMBOKガイド第6版までで体系化されていた「プロセス群（立ち上げ、計画、実行、監視・コントロール、終結）」と「知識エリア（スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー）」の概念が色濃く反映されている。特に、スケジュール・ネットワーク分析やアーンドバリュー・マネジメント（EVM）といった、計画と実績を定量的に比較・制御するための技術的側面が重視される。
3.2 スケジュールとコストの数学的モデル
予測型プロジェクトでは、クリティカルパス法（CPM）を用いてプロジェクトの最短完了期間を算出し、EVMを用いてコストとスケジュールの健全性を測定する。これらの計算は試験の頻出領域であり、単なる公式の暗記ではなく、数値が示すプロジェクトの状態（「予算超過」「スケジュール遅延」など）を解釈できる能力が求められる。
3.3 予測型アプローチ用語集（55語）
| 用語 (英語) | 用語 (日本語) | 解説・コンテキスト |
| Work Breakdown Structure (WBS) | 作業分解構成図 | プロジェクトのスコープ全体を、管理可能な構成要素（ワークパッケージ）へと階層的に分解したもの。スコープ・ベースラインの核心。 |
| Work Package | ワークパッケージ | WBSの最下層に位置する作業項目。コストや期間の見積もり、実行、監視・コントロールの単位となる。 |
| WBS Dictionary | WBS辞書 | WBSの各構成要素に関する詳細情報（作業内容、担当者、前提条件、基準など）を記述した文書。 |
| Scope Baseline | スコープ・ベースライン | 承認されたプロジェクト・スコープ記述書、WBS、およびWBS辞書からなる構成要素。進捗測定の基準。 |
| Requirements Traceability Matrix (RTM) | 要求事項トレーサビリティ・マトリックス | 各要求事項の起源から成果物までを追跡可能にする表。要件が漏れなく実装され、テストされたことを保証するために使用。 |
| Decomposition | 分解 | プロジェクトのスコープや成果物を、より小さく管理しやすい要素に分割する技法。WBS作成時に用いる。 |
| Rolling Wave Planning | 段階的詳細化（ローリング・ウェーブ計画法） | 直近の作業は詳細に計画し、将来の作業は大まかに計画しておき、時期が近づくにつれて詳細化する反復的な計画技法。 |
| Critical Path Method (CPM) | クリティカルパス法 | アクティビティの順序と所要期間を分析し、スケジュールの柔軟性（フロート）とプロジェクトの最短完了期間を算出する技法。 |
| Critical Path | クリティカルパス | プロジェクトの開始から終了までの経路の中で、最も所要期間が長い経路。この経路上の遅延はプロジェクト全体の遅延に直結する。フロートは通常ゼロ。 |
| Total Float (Slack) | トータル・フロート | プロジェクトの完了日を遅らせることなく、あるアクティビティの開始を遅らせることができる期間。 |
| Free Float | フリー・フロート | 直後の後続アクティビティの早期開始日を遅らせることなく、あるアクティビティを遅らせることができる期間。 |
| Precedence Diagramming Method (PDM) | プレシデンス・ダイアグラム法 | ノード（箱）でアクティビティを表し、矢印で論理的依存関係を示すスケジュール・ネットワーク図の作成手法。AON（Activity on Node）とも呼ばれる。 |
| Dependency | 依存関係 | アクティビティ間の順序関係。強制（ハードロジック）、任意（ソフトロジック）、外部、内部の4種類がある。 |
| Logical Relationships | 論理的順序関係 | 終了-開始（FS）、終了-終了（FF）、開始-開始（SS）、開始-終了（SF）の4つの関係性。FSが最も一般的。 |
| Lead | リード | 後続アクティビティを、先行アクティビティの完了前に前倒しして開始すること（時間の短縮）。 |
| Lag | ラグ | 先行アクティビティの完了後、後続アクティビティを開始するまでに意図的に設ける待機時間。 |
| Analogous Estimating | 類推見積り | 過去の類似プロジェクトのデータを用いて、期間やコストを見積もる技法。早い段階で使えるが精度は低い。トップダウン見積りとも言う。 |
| Parametric Estimating | パラメトリック見積り | 過去のデータとその他の変数との統計的関係（例：1平方メートルあたりの建設費）を用いて計算する見積り技法。データの質が高ければ精度が高い。 |
| Bottom-Up Estimating | ボトムアップ見積り | 下位レベルの構成要素（ワークパッケージ）を詳細に見積もり、それを積み上げて全体を見積もる技法。最も精度が高いが手間がかかる。 |
| Three-Point Estimating | 3点見積り | 最頻値（M）、楽観値（O）、悲観値（P）の3つの値を用いて不確実性を考慮した見積もりを行う技法。ベータ分布（PERT）や三角分布を用いる。 |
| Earned Value Management (EVM) | アーンドバリュー・マネジメント | スコープ、スケジュール、コストの指標を統合し、プロジェクトのパフォーマンスと進捗を客観的に測定する技法。 |
| Planned Value (PV) | 計画価値（プランド・バリュー） | 特定の時点までに完了する予定だった作業に対して割り当てられた承認済み予算。 |
| Earned Value (EV) | 達成価値（アーンド・バリュー） | 特定の時点までに実際に完了した作業に対して、承認された予算を割り当てた価値。進捗の実績値。 |
| Actual Cost (AC) | 実コスト | 特定の時点までに完了した作業のために、実際に費やされたコスト。 |
| Schedule Variance (SV) | スケジュール差異 | EV - PV で算出。正の値なら進んでいる、負の値なら遅れていることを示す。 |
| Cost Variance (CV) | コスト差異 | EV - AC で算出。正の値なら予算内、負の値なら予算超過を示す。 |
| Schedule Performance Index (SPI) | スケジュール効率指数 | EV / PV で算出。1.0より大きければ計画より効率的に進んでいる。 |
| Cost Performance Index (CPI) | コスト効率指数 | EV / AC で算出。1.0より大きければコスト効率が良い（予算より安く済んでいる）。 |
| Budget at Completion (BAC) | 完成時総予算 | プロジェクト完了時点での総予算（PVの総和）。ベースラインの一部。 |
| Estimate at Completion (EAC) | 完成時総コスト見積り | 現在のパフォーマンスに基づいた、プロジェクト完了時の予想総コスト。EAC = BAC / CPI （現在の傾向が続く場合）などで算出。 |
| Estimate to Complete (ETC) | 残作業コスト見積り | 現時点からプロジェクト完了までにかかると予想されるコスト。ETC = EAC - AC。 |
| Variance at Completion (VAC) | 完成時差異 | VAC = BAC - EAC。プロジェクト完了時に予想される予算との差異。 |
| To-Complete Performance Index (TCPI) | 残作業効率指数 | 残りのリソース（予算）で目標（BACまたはEAC）を達成するために維持しなければならないコスト効率（CPI）。 |
| Contingency Reserve | コンティンジェンシー予備 | 特定されたリスク（既知の未知）に対応するために、コスト・ベースラインやスケジュールに追加される予備。 |
| Management Reserve | マネジメント予備 | 特定されていないリスク（未知の未知）に対応するために確保される予算。プロジェクト予算には含まれるが、コスト・ベースラインには含まれない。 |
| Quality Assurance (QA) | 品質保証 | 品質要件が満たされるという確信を与えるための活動。プロセスが適切に実行されているかを監査する（プロセスの質）。 |
| Quality Control (QC) | 品質管理 | 成果物が品質要件を満たしているかを監視・記録し、不適合を特定して修正する活動（成果物の質）。 |
| Plan-Do-Check-Act (PDCA) | PDCAサイクル | 継続的改善のための反復的なモデル。予測型プロジェクトの品質管理の基礎となる概念。 |
| Cost of Quality (COQ) | 品質コスト | 品質の確保にかかるコスト（適合コスト）と、品質不足による損失コスト（不適合コスト）の総和。 |
| Statement of Work (SOW) | 作業範囲記述書 | プロジェクトで提供される製品やサービスの範囲を記述した文書。調達においては契約の一部となる。 |
| Fixed Price Contract | 定額契約 | 作業範囲が明確な場合に適した、総額が固定された契約。売主（受注者）のリスクが高い。 |
| Cost Reimbursable Contract | 実費償還契約 | かかった実費に利益（フィー）を上乗せして支払う契約。スコープが不明確な場合に適する。買主（発注者）のリスクが高い。 |
| Time and Material (T&M) | タイム・アンド・マテリアル契約 | 労働時間と材料費に基づいて支払う契約。定額と実費償還のハイブリッド。短期的な業務支援などに適する。 |
| Make-or-Buy Analysis | 自製・購入分析 | プロダクトやサービスを組織内部で作るか（自製）、外部から調達するか（購入）を決定するための分析技法。 |
| Source Selection Criteria | ソース・セレクション基準 | 提案書を評価し、適切な供給者を選定するために用いる基準（価格、技術力、過去の実績など）。 |
| Risk Management Plan | リスク・マネジメント計画書 | リスク管理活動のアプローチ、ツール、データソース、役割と責任、予算などを定義した計画。 |
| Qualitative Risk Analysis | 定性的リスク分析 | 各リスクの発生確率と影響度を主観的に評価し、リスクの優先順位付けを行うプロセス。 |
| Quantitative Risk Analysis | 定量的リスク分析 | 優先順位の高いリスクがプロジェクト目標（コストやスケジュール）に与える影響を数値化（金額や日数）して分析するプロセス。シミュレーション等を用いる。 |
| Probability and Impact Matrix | 発生確率・影響度マトリックス | リスクの発生確率と影響度を掛け合わせ、リスクの重要度（スコア）を決定するためのグリッド。 |
| Risk Register | リスク登録簿 | 特定されたリスク、その分析結果、対応策、担当者などを一元管理する文書。 |
| Risk Response Strategies (Threats) | 脅威への対応戦略 | マイナスのリスクに対する戦略。回避（除去）、転嫁（第三者へ移転）、軽減（確率・影響の低減）、受容（対策せず受け入れる）。 |
| Risk Response Strategies (Opportunities) | 好機への対応戦略 | プラスのリスクに対する戦略。活用（確実に発生させる）、共有（第三者と利益を分かつ）、強化（確率・影響の増大）、受容。 |
| Active Acceptance | 能動的受容 | リスク発生時のためのコンティンジェンシー予備（予備費や予備時間）を確保しておく受容戦略。 |
| Passive Acceptance | 受動的受容 | 特に対策を講じず、リスクが発生したらその時に対処するという戦略。 |
| Work Performance Data | 作業パフォーマンス・データ | 実行プロセスで収集される生の観察結果や測定値（例：完了したタスク数、実際のコスト）。 |
第4章 アジャイルおよび適応型アプローチ (Domain 3)
4.1 経験的プロセス制御とアジャイルマインドセット
予測型アプローチが「定義されたプロセス制御」に依存するのに対し、アジャイルアプローチは「経験的プロセス制御（Empiricism）」に基づく。これは、複雑な問題に対しては事前の完璧な計画よりも、透明性（Transparency）、検査（Inspection）、適応（Adaptation）のサイクルを回しながら進む方が効果的であるという考え方である。
CAPM試験では、特定の手法（スクラム、カンバン、XP等）のルールだけでなく、アジャイルマニフェストに基づく価値観や原則、サーバント・リーダーシップといったマインドセットの理解が重要視される。アジャイルチームは自己組織化されており、機能横断的（クロスファンクショナル）であることが求められる。
4.2 アジャイル用語集（55語）
| 用語 (英語) | 用語 (日本語) | 解説・コンテキスト |
| Agile Manifesto | アジャイルソフトウェア開発宣言 | 4つの価値と12の原則からなるアジャイルの基本理念。「プロセスやツールよりも個人と対話を」「包括的なドキュメントよりも動くソフトウェアを」等を重視する。 |
| Adaptive Approach | 適応型アプローチ | 要件の不確実性が高い環境において、短いサイクルでのフィードバックと学習を通じて計画を修正し続ける手法。 |
| Iterative Development | 反復型開発 | 作業を繰り返すことで製品を徐々に洗練させ、詳細化していくアプローチ。一度で完成させるのではなく、何度も磨き上げるイメージ。 |
| Incremental Development | 漸進型開発 | 完成した機能（インクリメント）を少しずつ、頻繁に提供していくアプローチ。早期に価値を届けられる。 |
| Scrum | スクラム | 複雑な問題に対応するための軽量なフレームワーク。役割、イベント、作成物を定義し、経験的プロセス制御を実践する。 |
| Product Owner (PO) | プロダクトオーナー | プロダクトの価値を最大化することに責任を持つ役割。バックログを管理し、何を作るか（What）を決定する唯一の責任者。 |
| Scrum Master | スクラムマスター | チームがスクラムの理論と実践を理解・遵守するよう支援し、外部からの妨害を排除するサーバント・リーダー。 |
| Development Team | 開発チーム | インクリメント（成果物）を作成する専門家グループ。誰が何をするか（How）を自分たちで決定する自己組織化されたチーム。 |
| Sprint | スプリント | 1ヶ月以内の固定された期間（タイムボックス）。この期間内に「完成の定義」を満たすインクリメントを作成する。 |
| Timebox | タイムボックス | 作業を行うために設定された固定の期間（期限）。期間が来たら作業が完了していなくても打ち切ることで、集中力とリズムを生む。 |
| Sprint Planning | スプリント・プランニング | スプリントの開始時に行う計画イベント。「何を作るか」と「どう作るか」を決定し、スプリントバックログを作成する。 |
| Daily Scrum | デイリースクラム（朝会） | 開発チームが毎日行う15分間のミーティング。ゴールに対する進捗を確認し、その日の作業を調整する。 |
| Sprint Review | スプリント・レビュー | スプリント終了時に、成果物をステークホルダーにデモし、フィードバックを得てプロダクトバックログを適応させるイベント。 |
| Sprint Retrospective | スプリント・レトロスペクティブ | スプリント終了時に、チームのプロセス、関係性、ツールなどを振り返り、改善策を決定するイベント。 |
| Product Backlog | プロダクトバックログ | プロダクトに必要な機能、改善点、修正点の優先順位付きリスト。POが所有し、常に変化する「生きた」文書。 |
| Sprint Backlog | スプリントバックログ | 特定のスプリントで実施するために選ばれたアイテムと、それを完了させるための作業計画。開発チームが所有する。 |
| Increment | インクリメント | スプリント中に完成した、出荷可能な品質を持つプロダクトの一部。これまでの全インクリメントの積上げ。 |
| Definition of Done (DoD) | 完成の定義 | 成果物が「完成した」と見なされるために満たすべき品質基準のチェックリスト。透明性を確保するために不可欠。 |
| Definition of Ready (DoR) | 準備完了の定義 | バックログアイテムがスプリント計画で選択できる状態（明確さ、実行可能性）になっているかを確認する基準。 |
| User Story | ユーザーストーリー | ユーザー視点で記述された要件の形式。「[役割]として、[目的]のために、[機能]が欲しい」という構文を用いる。 |
| Story Points | ストーリーポイント | ユーザーストーリーの規模（複雑さ、労力、不確実性）を表す相対的な見積もり単位。時間（絶対値）ではない。 |
| Velocity | ベロシティ | 1スプリントあたりにチームが完了させたストーリーポイントの合計値。チームの処理能力を示し、将来の予測に使用する。 |
| Burndown Chart | バーンダウンチャート | 横軸に時間、縦軸に残作業量（ポイント）をとり、作業が計画通りに消化されているかを可視化したグラフ。 |
| Burnup Chart | バーンアップチャート | 完了した作業量の積み上げを表示するグラフ。スコープ全体の増加と進捗を同時に確認できる。 |
| Kanban Board | カンバンボード | 作業（タスク）をカード化し、プロセス（To Do, Doing, Done等）を列として可視化したボード。フローの管理に用いる。 |
| WIP (Work In Progress) Limit | WIP制限（仕掛り制限） | 各工程で同時に実行できる作業数に上限を設けること。マルチタスクを防ぎ、ボトルネックを顕在化させ、フローを改善する。 |
| Flow | フロー | 作業が滞りなくプロセスを通過していく状態。カンバン方式ではフローの最適化（リードタイムの短縮）を目指す。 |
| Lead Time | リードタイム | 顧客のリクエストから納品までの総時間。 |
| Cycle Time | サイクルタイム | 作業に着手してから完了するまでの実作業時間。 |
| Information Radiator | 情報ラジエーター | チームの誰もが見える場所に掲示された、プロジェクト状況（チャート等）を示す大型ディスプレイやボード。 |
| XP (Extreme Programming) | エクストリーム・プログラミング | ソフトウェア開発の技術的卓越性を重視するアジャイル手法。ペアプログラミング、TDD、CIなどを実践する。 |
| Pair Programming | ペアプログラミング | 2人のエンジニアが1台のPCを使い、一方がコードを書き（ドライバー）、もう一方がレビュー・思考する（ナビゲーター）手法。 |
| Test-Driven Development (TDD) | テスト駆動開発 | コードを書く前にまず失敗するテストケースを作成し、そのテストにパスするように必要最小限の実装を行う手法。 |
| Continuous Integration (CI) | 継続的インテグレーション | 開発者がコードを頻繁（1日複数回）にメインリポジトリに統合し、自動テストを行うことで、統合時の問題を早期発見する習慣。 |
| Refactoring | リファクタリング | 外部から見た振る舞い（機能）を変えずに、内部構造（コード）を整理・改善すること。技術的負債を解消するために行う。 |
| Technical Debt | 技術的負債 | 短期的な速度を優先して、汚いコードや場当たり的な設計を採用した結果、将来的に発生する修正・保守のコスト。 |
| Servant Leadership | サーバント・リーダーシップ | 従来の「指示命令型」ではなく、チームに奉仕し、権限を委譲し、障害を取り除くことで成果を最大化するリーダーシップ。 |
| Self-Organizing Team | 自己組織化チーム | 外部からの詳細な指示を待つのではなく、目標達成のために誰が何をすべきかを自律的に決定し行動するチーム。 |
| Cross-Functional Team | 機能横断型チーム | プロダクトを完成させるために必要なすべてのスキル（設計、実装、テスト、UI等）をチーム内部に備えている状態。 |
| Minimum Viable Product (MVP) | 実用最小限の製品 | 顧客からフィードバックを得て仮説を検証するために必要な、最小限の機能を備えた初期バージョンの製品。 |
| Product Roadmap | プロダクト・ロードマップ | プロダクトのビジョンが時間の経過とともにどのように実現されるかを示した高レベルの計画。リリースの方向性を示す。 |
| Backlog Refinement | バックログ・リファインメント | 次期スプリントに備えて、バックログアイテムの詳細化、見積もり、優先順位付けを行う継続的な活動。グルーミングとも呼ぶ。 |
| Spike | スパイク | 見積もりが困難な技術的課題やリスクに対して、調査や実験を行うために設ける短いタイムボックス期間。 |
| Planning Poker | プランニングポーカー | フィボナッチ数列が書かれたカードを使い、チーム全員で相対見積もりを行うゲーム形式の手法。アンカー効果（偏り）を防ぐ。 |
| INVEST | INVEST | 良いユーザーストーリーの基準。Independent（独立している）、Negotiable（交渉可能）、Valuable（価値がある）、Estimable（見積り可能）、Small（小さい）、Testable（テスト可能）。 |
| Cone of Uncertainty | 不確実性のコーン | プロジェクト初期は見積もりの不確実性が高く、進行するにつれて情報が増え、精度が高まっていく現象を示すモデル。 |
| Osmotic Communication | 浸透的コミュニケーション | 同じ部屋（チームルーム）にいることで、会話を直接していなくても周囲の情報が自然と耳に入り、共有される現象。 |
| Daily Standup | デイリー・スタンドアップ | 立ったまま短時間で行うミーティング。アジャイルに限らず、予測型プロジェクトでもコミュニケーション促進のために採用される。 |
| Retrospective | 振り返り（レトロスペクティブ） | 定期的（フェーズ終了時やスプリント終了時）に行われる、プロセス改善のためのミーティング。KPT法などが使われる。 |
| Features | 機能（フィーチャー） | ユーザーにとって価値のある製品の機能。複数のユーザーストーリーを束ねた単位として扱われることがある。 |
| Epics | エピック | 非常に大きなユーザーストーリー。1回のスプリントでは完了できないため、より小さなストーリーに分解される必要がある。 |
| Persona | ペルソナ | 典型的なユーザー像を表す架空のキャラクター。ユーザーストーリーを作成する際の視点として重要。 |
| Stakeholder Engagement | ステークホルダー・エンゲージメント | アジャイルでは、デモやレビューを通じてステークホルダーを頻繁に関与させ、フィードバックループを回すことが重視される。 |
| Value Stream Mapping | バリューストリーム・マッピング | 現状のプロセスを可視化し、価値を生む工程と無駄（待機時間など）を特定して、プロセス全体を最適化するリーン手法。 |
| Hybrid Methodology | ハイブリッド手法 | ウォーターフォールとアジャイルを組み合わせた手法。例：要件定義はアジャイル、開発はウォーターフォール、あるいはその逆など。 |
第5章 ビジネスアナリシス・フレームワーク (Domain 4)
5.1 プロジェクトマネージャーとビジネスアナリシス
CAPM試験において最も劇的な変化が、このビジネスアナリシス（BA）ドメインの強化である。従来のPMBOKでは「要件収集」という一プロセスに過ぎなかった領域が、独立したドメインとして27%の配分を持つに至った。これは、プロジェクトマネージャーが「プロジェクトを正しく進める（Do the project right）」だけでなく、「正しいプロジェクトを行う（Do the right project）」ための視点を持つこと、あるいは専任のビジネスアナリスト（BA）と協働するスキルが必須となったことを意味する。
ビジネスアナリシスは、プロジェクトの開始前（ニーズ評価）から、実行中（要件の管理）、そして終了後（成果の評価）まで、一貫して「ビジネス価値」に焦点を当てる。
5.2 ビジネスアナリシス用語集（50語）
| 用語 (英語) | 用語 (日本語) | 解説・コンテキスト |
| Business Analysis | ビジネスアナリシス | ニーズを特定し、ソリューションを推奨することで、組織に価値を提供する活動の総称。 |
| Needs Assessment | ニーズ・アセスメント | プロジェクト開始前に、ビジネス上の問題や機会を分析し、現状と将来状態のギャップを特定して、プロジェクトの必要性を評価する活動。 |
| Business Need | ビジネス・ニーズ | 組織における変更の原動力となる問題や機会。プロジェクトを開始する根本的な理由。 |
| Situation Statement | 状況記述書 | 特定された問題や機会、およびそれが組織に与える影響を明確に記述したもの。ニーズ・アセスメントの成果物。 |
| Gap Analysis | ギャップ分析 | 現状（As-Is）とあるべき姿（To-Be）の差（ギャップ）を比較し、その差を埋めるために必要なアクション（プロジェクト）を特定する技法。 |
| Root Cause Analysis (RCA) | 根本原因分析 | 問題の表面的な症状ではなく、根本的な原因を特定する技法。これが不十分だと、対症療法的なプロジェクトになってしまう。 |
| Fishbone (Ishikawa) Diagram | 特性要因図（フィッシュボーン図） | 結果（問題）に対する原因を体系的（人、方法、機械、材料など）に図示したもの。根本原因の特定に役立つ。 |
| 5 Whys | なぜなぜ分析 | 「なぜ？」を5回繰り返すことで、問題の深層にある根本原因を突き止めるシンプルな技法。 |
| SWOT Analysis | SWOT分析 | 組織の内部要因（強み、弱み）と外部要因（機会、脅威）を分析し、戦略的オプションを導き出すフレームワーク。 |
| Stakeholder Engagement Plan | ステークホルダー・エンゲージメント計画書 | ビジネスアナリシス活動にステークホルダーをどのように関与させ、情報を引き出し、合意形成するかを定義した計画。 |
| Elicitation | 引き出し（エリシテーション） | ステークホルダーから情報を「集める」のではなく、潜在的なニーズや隠れた要件を能動的に「引き出す」活動。 |
| Brainstorming | ブレーンストーミング | 質より量を重視し、批判を禁止して多数のアイデアを出し合う発散的思考技法。 |
| Interviews | インタビュー | ステークホルダーと個別に対話し、情報を引き出す技法。本音や機密情報を得るのに適している。 |
| Focus Groups | フォーカス・グループ | 司会者（モデレーター）の進行のもと、特定のテーマについて選ばれたステークホルダーグループが議論する技法。 |
| Observation (Job Shadowing) | 観察（ジョブ・シャドウイング） | ユーザーが実際に業務を行っている様子を観察し、言葉にされない要件や実際のプロセス手順を把握する技法。 |
| Prototyping | プロトタイピング | 製品の模型（プロトタイプ）を早期に作成し、実際に触ってもらうことで具体的なフィードバックを得る技法。要件の誤解を防ぐ。 |
| Workshops | ワークショップ | 主要なステークホルダーを集め、集中的に議論して要件を定義したり、対立を解消したりする協働セッション。 |
| Document Analysis | 文書分析 | 既存の文書（マニュアル、規定、過去のレポート等）を分析し、要件や制約条件を抽出する技法。 |
| Benchmarking | ベンチマーキング | 他組織や業界標準のベストプラクティスと自社のプロセスを比較し、改善点や目標を設定する技法。 |
| Context Diagram | コンテキスト図 | システム全体を一つの円（プロセス）として捉え、外部エンティティ（人や他システム）とのデータのやり取りを示した最上位のデータフロー図。 |
| Use Case Diagram | ユースケース図 | システムがユーザー（アクター）に対して提供する機能（ユースケース）と、それらの関係を図示したもの。システムの振る舞いを定義する。 |
| Data Flow Diagram (DFD) | データフロー図 | システム内でのデータの流れ（入力、処理、保存、出力）を視覚化した図。機能要件の定義に役立つ。 |
| Entity Relationship Diagram (ERD) | 実体関連図（ER図） | データの実体（エンティティ）とそれらの関係（リレーションシップ）を定義した図。データベース設計の基礎となる。 |
| State Transition Diagram | 状態遷移図 | オブジェクトがどのような状態（ステート）を取り得るか、イベントによってどう状態が変化するかを示したもの。 |
| Process Flows | プロセスフロー | 業務プロセスの手順や流れを図示したもの。スイムレーン図などが用いられ、業務の可視化や改善点の特定に使用される。 |
| Traceability | トレーサビリティ | 要求事項がその起源（ビジネスニーズ）から、成果物、テストケースまで相互にリンクされ、追跡可能である状態。 |
| Requirements Traceability Matrix (RTM) | 要求事項トレーサビリティ・マトリックス | トレーサビリティを管理するための表。要件の抜け漏れ防止や、変更時の影響範囲分析（インパクト分析）に不可欠。 |
| Verification | 検証 | 「プロダクトを正しく作ったか？」を確認すること。仕様書や設計書通りに作られているかをチェックする（品質管理的視点）。 |
| Validation | 妥当性確認 | 「正しいプロダクトを作ったか？」を確認すること。ステークホルダーのニーズやビジネス目標を満たしているかを確認する（ビジネス視点）。 |
| Acceptance Criteria | 受け入れ基準 | ソリューションがステークホルダーに受け入れられるために満たすべき具体的な条件や指標。ユーザーストーリーに付随することが多い。 |
| Prioritization | 優先順位付け | 限られたリソースで最大の価値を生むために、実装する要件の順序を決定すること。 |
| MoSCoW Analysis | MoSCoW分析 | 要件をMust have（必須）、Should have（すべき）、Could have（あればよい）、Won't have（今回は対象外）に分類する優先順位付け手法。 |
| Timeboxing | タイムボクシング | 作業時間を固定し、その時間内で完了できる範囲にスコープを調整する手法。優先順位の高いものから実施する。 |
| Voting | 投票（ドット投票等） | チームメンバーやステークホルダーが投票を行い、多数の選択肢から優先順位を決定する参加型の手法。 |
| Weighted Ranking | 加重ランキング | 複数の基準（コスト、価値、リスク等）に重み付けを行い、各選択肢をスコアリングして客観的に優先順位を決める手法。 |
| Business Requirement Document (BRD) | ビジネス要件定義書 | プロジェクトが解決すべきビジネス上の問題、目的、高レベルのニーズを記述した包括的な文書。 |
| Functional Requirements | 機能要件 | システムや製品が「何をすべきか（振る舞い）」を記述した要件。例：「ログイン画面を表示する」。 |
| Non-functional Requirements | 非機能要件 | システムの性能、セキュリティ、信頼性など「どのようにあるべきか（品質特性）」を記述した要件。例：「画面は2秒以内に表示されること」。 |
| Solution Evaluation | ソリューション評価 | 導入されたソリューションが実際に期待された価値やベネフィットを提供しているかを測定・評価する活動。 |
| Formative Evaluation | 形成的評価 | プロジェクト進行中にソリューション（の一部）を評価し、設計や要件を修正していくための評価。 |
| Summative Evaluation | 総括的評価 | プロジェクト終了後やリリース後に、ソリューションの成果や価値を測定するための評価。 |
| Persona | ペルソナ | ユーザーグループを代表する架空のキャラクター。具体的で共感可能なユーザー像を作ることで、要件のブレを防ぐ。 |
| Story Mapping | ストーリーマッピング | ユーザーストーリーを時系列（ユーザーの行動順）と優先順位の2軸で配置し、全体像とリリースの切れ目を可視化する手法。 |
| Impact Analysis | 影響分析（インパクト分析） | 要件の変更が、他の要件、プロジェクトのコスト、スケジュール、リスクにどのような影響を与えるかを評価すること。 |
| Solution Scope | ソリューション・スコープ | ビジネスニーズを満たすために提供されるソリューション（機能や特性）の範囲や境界。プロジェクト・スコープとは区別される。 |
| Kano Model | 狩野モデル | 顧客満足度と機能充足度の関係から、要件を「当たり前品質」「一元的品質」「魅力的品質」などに分類するモデル。 |
| Business Analyst (BA) | ビジネスアナリスト | ビジネスニーズの特定、要件の管理、ソリューションの評価を担当する専門職。PMと密接に連携する。 |
| Requirements Management Plan | 要求事項マネジメント計画書 | 要件の分析、文書化、管理の方法、優先順位付けのプロセス、トレーサビリティの構造などを定義した計画。 |
| Product Backlog | プロダクトバックログ | （アジャイルにおける）要件の一覧。ビジネス価値に基づいて常に優先順位が見直される。 |
| User Acceptance Testing (UAT) | ユーザー受け入れテスト | 実際のユーザーが、ビジネス要件を満たしているかを確認するために行う最終段階のテスト。妥当性確認の一部。 |
第6章 結論：CAPM®合格に向けた統合的理解
本報告書で詳述した220以上の用語と概念は、CAPM試験の合格に必要な知識基盤を形成するものである。しかし、試験対策として最も重要なのは、これらの用語を個別に暗記することではなく、4つのドメインがどのように有機的に結合しているかを理解することである。
- 原理（Domain 1）がすべての基盤である: プロジェクトが予測型であれ適応型であれ、スチュワードシップ、価値への焦点、チームへの配慮といった原理は常に変わらない行動規範となる。
- 手法（Domain 2 & 3）は選択肢である: ウォーターフォール（予測型）とアジャイル（適応型）は対立するものではなく、プロジェクトの特性（要件の確実性や変更の頻度）に応じて使い分ける、あるいは組み合わせる（ハイブリッド）べき「道具」である。CAPM受験者は、状況に応じて最適なアプローチを選択する判断力（テーラリング）が問われる。
- ビジネスアナリシス（Domain 4）が方向性を決める: どんなに優れたスケジュール管理やアジャイル開発を行っても、作っているものがビジネスニーズに合致していなければプロジェクトは失敗である。BAスキルは、プロジェクトを「正しい方向」に導くための羅針盤の役割を果たす。
受験者は、本報告書の用語集を参照しつつ、「なぜこのプロセスが必要なのか？」「この状況ではどのアプローチが価値を最大化するか？」という問いを常に持ちながら学習を進めることが推奨される。プロジェクトマネジメントは、単なる管理技術から、変革をリードし価値を創造するための総合芸術へと進化しているのである。
