PMP 統合管理 完全対策｜PMBOK の幹となる領域

※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます

「PMP® の統合マネジメントは、ほかの 9 領域をまとめる“ハブ”だと言われるけれど、結局なにをする領域なのかピンとこない」——本記事はその疑問を 1 本で解消します。結論から言えば、統合マネジメントは プロジェクト憲章の作成から終結まで、全体を 1 つに束ねる司令塔の領域。スコープ・スケジュール・コストといった個別領域がそれぞれの専門作業を担うのに対し、統合は それらの成果を統合し、トレードオフを判断し、変更を一元管理する 役割を持ちます。そして 10 ナレッジエリアの中で 唯一、立ち上げ・計画・実行・監視・終結の 5 プロセス群すべてにまたがる のが最大の特徴です。

本記事では 統合マネジメントの 7 プロセスを順に解説し、試験頻出のプロジェクト憲章・統合変更管理（CCB）・知識のマネジメントを整理 します。10 領域全体の地図は「PMP 試験 10 のナレッジエリア 完全解説」、時間軸である 5 プロセス群は「PMP 試験 5 つのプロセス群 完全解説」、1 つ前の領域は「PMP リスク管理 完全対策」、受験資格や学習計画は柱記事「PMP® 試験完全ガイド」をご覧ください。

統合マネジメントとは｜10 領域を束ねる「幹」

プロジェクト統合マネジメントとは、プロジェクトのさまざまな構成要素（スコープ・スケジュール・コスト・品質・リスクなど）を 1 つにまとめ上げ、全体最適の視点で調整・統合する 知識エリアです。個別の領域が「木」だとすれば、統合は すべての枝を支える「幹」。PM が日々行っている「どの要求を優先するか」「この変更をどう全体に反映するか」という意思決定そのものが、統合マネジメントの中身です。

統合マネジメントの 7 プロセス｜全体像

PMBOK® 第 6 版では、統合マネジメントは 7 つのプロセス で構成されます。注目すべきは、所属するプロセス群が 5 つすべてに分散している こと。これは 10 ナレッジエリアの中で統合だけが持つ特徴です。

#	プロセス	プロセス群	一言でいう役割
1	プロジェクト憲章の作成	立ち上げ	プロジェクトを正式に認可し、PM に権限を与える
2	プロジェクトマネジメント計画書の作成	計画	全領域の計画を 1 冊に統合する
3	プロジェクト作業の指揮・マネジメント	実行	計画どおりに作業を遂行し成果物を生む
4	プロジェクト知識のマネジメント	実行	既存知識の活用と新たな教訓の蓄積
5	プロジェクト作業の監視・コントロール	監視・コントロール	進捗を計画と比較し是正・予防を判断
6	統合変更管理	監視・コントロール	すべての変更要求を一元的に審査・承認
7	プロジェクトやフェーズの終結	終結	成果を引き渡し、教訓を残して正式に閉じる

💡 覚え方：統合の 7 プロセスは 立ち上げ 1・計画 1・実行 2・監視 2・終結 1。10 領域で唯一、5 プロセス群すべてに 1 つ以上のプロセスを持つ のが統合です。「プロジェクトの始まり（憲章）と終わり（終結）を担うのは統合だけ」と覚えると、ほかの領域との違いが鮮明になります。

① プロジェクト憲章の作成｜プロジェクトを“正式に”立ち上げる

最初のプロセスでは、プロジェクトを公式に認可する文書 プロジェクト憲章 を作成します。憲章には、プロジェクトの目的・目標、ハイレベルな要求事項、前提条件と制約条件、マイルストーン・スケジュールと概算予算、主要リスク、そして PM の名前と権限レベル が記載されます。

② プロジェクトマネジメント計画書の作成｜全領域の計画を 1 冊に

2 つ目は、スコープ・スケジュール・コスト・品質・リスクなど 各領域の個別計画（補助計画書）とベースラインを 1 つに統合 するプロセスです。アウトプットである プロジェクトマネジメント計画書 は、プロジェクトの実行・監視・終結すべての基準となる“設計図”であり、ベースライン化された後は 統合変更管理を通さなければ変更できません。

③ プロジェクト作業の指揮・マネジメント｜計画を成果物に変える

3 つ目は 実行プロセス群 に属し、計画書に従って作業を遂行し、成果物（deliverables） を生み出すプロセスです。ここで集まる作業実績データ（ワークパフォーマンスデータ）が、後段の監視・コントロールで分析される素材になります。承認済みの変更要求を実装するのもこのプロセスです。

④ プロジェクト知識のマネジメント｜「教訓」を資産にする

4 つ目も 実行プロセス群 に属し、第 6 版で新設されました。プロジェクト目標の達成と組織の学習のために、既存の知識を活用し、新しい知識を創造する プロセスです。扱う知識には、文書化しやすい 形式知 と、経験・ノウハウのように言語化しにくい 暗黙知 の 2 種類があります。

⑤ プロジェクト作業の監視・コントロール｜計画と実績を突き合わせる

5 つ目は 監視・コントロールプロセス群 に属し、実績を計画（ベースライン）と比較し、差異を分析して 是正処置・予防処置・変更要求 を生み出すプロセスです。各領域の監視結果を統合し、プロジェクト全体のパフォーマンスを俯瞰するのが統合ならではの役割です。

⑥ 統合変更管理｜すべての変更は“ここ”を通す

6 つ目は試験の最大の山場です。プロジェクトに対するあらゆる変更要求を一元的にレビューし、承認・却下を決定する プロセスで、ベースライン化された計画書への変更は 必ずこのプロセスを経由 しなければなりません。

項目	内容
対象	スコープ・スケジュール・コスト等、ベースラインへの全変更要求
判断する場	変更管理委員会（CCB：Change Control Board）
流れ	変更要求 → CCB でレビュー → 承認／却下／保留 → 承認分のみ実装へ
原則	承認されるまで作業に反映しない（勝手な変更は禁止）

⑦ プロジェクトやフェーズの終結｜成果を引き渡し、学びを残す

7 つ目は 終結プロセス群 に属し、10 領域で 終結プロセスを持つのは統合だけ です。成果物の正式な引き渡し、契約や調達の完了確認、教訓の最終的な記録と OPA への移管、資源の解放、関係者への完了通知などを行い、プロジェクト（またはフェーズ）を正式に閉じます。

つまずきやすいポイント整理｜よくある誤解 vs 正しい理解

よくある誤解	正しい理解
統合は個別作業を直接行う領域	統合は 各領域の成果を束ね、トレードオフを判断 する領域
PM は最初から権限を持っている	プロジェクト憲章の承認で PM に権限が与えられる
変更は PM が判断して即実装してよい	ベースラインへの変更は 統合変更管理（CCB）を必ず経由
終結プロセスは複数の領域にある	終結を持つのは統合だけ（10 領域で唯一）
中止したプロジェクトは終結不要	中止でも 終結して教訓を残す
知識マネジメントは形式知の文書化だけ	暗黙知の共有（対話・ネットワーキング） も含む

まとめ｜統合は「束ねて・判断して・変更を制御して・閉じる」

PMP® の統合マネジメントは、①憲章作成 → ②計画書作成 → ③作業の指揮 → ④知識のマネジメント → ⑤監視・コントロール → ⑥統合変更管理 → ⑦終結 の 7 プロセスで、プロジェクトの始まりから終わりまでを貫きます。試験では、統合が 10 領域で唯一 5 プロセス群すべてにまたがる理由、プロジェクト憲章は誰が承認し PM に何を与えるのか、そして最頻出の 「変更はまず変更要求として統合変更管理（CCB）にかける」 が繰り返し問われます。“統合は幹、ほかの 9 領域は枝” と “ベースラインへの変更は必ず統合変更管理を通す” の 2 点を手元に置けば、統合分野は迷わず解けるようになります。

---

注釈：

• PMP®、PMI®、PMBOK® は Project Management Institute, Inc. の登録商標です
• 本記事のプロセス構成・用語は PMBOK® 第 6 版に基づく執筆時点（2026 年 6 月）の整理です。最新の試験範囲（ECO）は必ず PMI 公式サイトでご確認ください