プロジェクト統合管理とは？PMBOKの中核を担う7つの統合プロセスを解説

プロジェクト統合管理とは

プロジェクト統合管理（Project Integration Management）とは、プロジェクトマネジメントの各知識エリア（スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダー）を横断的に調整し、プロジェクト全体としての一貫性と整合性を確保する管理領域です。

PMBOKでは10の知識エリアの筆頭に位置づけられており、他の9つの知識エリアの成果物を統合し、トレードオフの判断を行う「プロジェクトマネージャーの本質的な仕事」として定義されています。

統合管理が必要となる理由は明確です。スコープを拡大すればコストとスケジュールに影響します。コストを削減すれば品質やスコープに影響します。個別の知識エリアで最適化しても、全体としては矛盾が生じる可能性があります。統合管理は、こうしたトレードオフの中で全体最適を追求するプロセスです。

構成要素

統合管理は7つのプロセスで構成され、プロジェクトの立上げから終結までのすべてのフェーズをカバーします。

1. プロジェクト憲章の作成（立上げ）

プロジェクトの存在を正式に承認する文書を作成します。プロジェクトの目的、主要な成果物、前提条件、制約条件、概算予算、マイルストーン、プロジェクトマネージャーの任命と権限を記載します。ビジネスケースと契約書がインプットとなります。

2. プロジェクトマネジメント計画書の作成（計画）

スコープ、スケジュール、コストなど各知識エリアの個別計画を統合した包括的な計画書を作成します。この計画書がプロジェクト実行と管理のベースラインとなります。変更管理計画、コンフィギュレーション管理計画も含まれます。

3. プロジェクト作業の指揮とマネジメント（実行）

承認された計画書に基づき、プロジェクト作業を実行します。成果物の作成、チームメンバーへの作業指示、リソースの配分、ステークホルダーとのコミュニケーションを管理します。

4. プロジェクト知識のマネジメント（実行）

過去のプロジェクトの教訓を活用し、現在のプロジェクトで得られた知識を組織に還元するプロセスです。PMBOK第6版で新たに追加されたプロセスであり、組織のナレッジマネジメントとの連携が求められます。

5. 統合変更管理（監視・コントロール）

すべての変更要求を審査し、承認・却下・保留を判断するプロセスです。変更管理委員会（CCB）が審査機関として機能します。承認された変更はベースラインに反映され、不正な変更（スコープクリープ）を防止します。

6. プロジェクト作業の監視・コントロール（監視・コントロール）

計画と実績の差異を監視し、必要に応じて是正措置・予防措置を実施するプロセスです。パフォーマンスレポートの作成、EVM指標のモニタリング、リスクの再評価が含まれます。

7. プロジェクトまたはフェーズの終結（終結）

すべての活動を公式に完了し、成果物の受入確認、契約の完了、教訓の文書化、資源の解放を行うプロセスです。

実践的な使い方

ステップ1: プロジェクト憲章でスコープと権限を明確にする

プロジェクトの開始時に、目的・成果物・制約条件をプロジェクト憲章として文書化し、スポンサーの承認を得ます。ここでプロジェクトマネージャーの権限範囲を明確にしておくことが、後の変更管理やリソース調達の際に効果を発揮します。

ステップ2: 統合計画書で各知識エリアの整合性を確保する

スコープ計画、スケジュール計画、コスト計画などを個別に作成した後、相互の整合性を確認して統合します。例えば、スケジュールの制約がコスト見積りの前提と矛盾していないか、リスク対応計画に必要な予備費が予算に含まれているかなどを検証します。

ステップ3: 変更管理プロセスを厳格に運用する

統合変更管理は、プロジェクトの規律を維持するための生命線です。すべての変更要求を文書化し、影響分析を実施し、CCBで審査するプロセスを徹底します。口頭での合意や非公式な変更は、スコープクリープの温床になります。

ステップ4: パフォーマンスを定期的にモニタリングする

計画と実績の差異を定期的（週次・月次）に測定し、トレンドを分析します。差異が許容範囲を超えた場合は、原因を分析して是正措置を講じます。SPI、CPI、リスク登録簿の状況を統合的にレビューすることが重要です。

ステップ5: 教訓を組織の知識資産として蓄積する

プロジェクト終了時だけでなく、各フェーズの終了時にも教訓を記録します。「何がうまくいったか」「何がうまくいかなかったか」「次回はどうすべきか」を構造化して記録し、組織のナレッジベースに格納します。

活用場面

• 大規模ITプロジェクトにおける複数チーム間のスコープ・スケジュール・コストの統合調整
• 組織変革プロジェクトでの技術要件と組織要件のトレードオフ判断
• グローバルプロジェクトにおける地域間の計画統合と変更管理の標準化
• ウォーターフォール型とアジャイル型のハイブリッドプロジェクトにおける統合計画の策定
• プログラムマネジメントにおける複数プロジェクト間の依存関係管理

注意点

統合管理はPMだけの仕事ではない

統合管理はプロジェクトマネージャーの中核業務ですが、一人で完結できるものではありません。各知識エリアのリード、CCBメンバー、スポンサーとの協働が不可欠です。統合管理の責任はPMにありますが、実行は組織的な取り組みです。

変更管理の形骸化を防ぐ

変更管理プロセスが煩雑すぎると、現場が非公式なルートで変更を進めてしまいます。変更の規模に応じた承認レベルの設定（小規模変更はPM承認、大規模変更はCCB承認など）で運用の実効性を確保してください。

終結プロセスを省略しない

プロジェクト完了後は次のプロジェクトに急ぎがちですが、終結プロセスの省略は教訓の喪失と契約リスクの見落としにつながります。公式な終結手続きを確実に実施してください。

まとめ

プロジェクト統合管理は、7つのプロセスを通じて各知識エリアを横断的に調整し、プロジェクト全体としての一貫性を確保する管理領域です。プロジェクト憲章による公式な立上げ、統合計画書によるベースライン設定、変更管理による規律の維持、教訓の蓄積が中核的な活動です。個別最適ではなく全体最適を追求する視点が、プロジェクトマネージャーに求められる統合管理の本質です。