【PMBOK】プロジェクト統合マネジメント｜概要と作業内容を現役PMPが説明します

こんにちは、現役プロマネでPMP＠のMARCUS（マーカス）です。

プロジェクトマネジメントに関わる仕事をしていれば、誰もが一度はPMBOKガイド本を手に取ったことがあると思います。（大切なので、まだの初心者は見てくださいね）

PMBOKは、プロジェクトマネージャーたちの過去の教訓や慣例をもとに、プロジェクト管理に関する手法が体系的にまとめられたガイド本で、実質的な世界標準となっています。

私もプロジェクト管理の項目や手順を再確認したり、情報を文書化するにあたってのテンプレートを参考にしたりと、今でも時折見て、何かと役に立っています。

プロジェクトマネージャーの国際資格となるPMP＠資格取得を目指す人には、学習を進めるための教本となり、PMBOKガイド本の熟読は必須となることでしょう。

PMBOKが規定している10の知識エリアのうち、プロジェクト立上から終結までの5つのプロセス群で、一貫して継続される唯一の知識エリアが「統合マネジメント」です。

ほかの知識エリアでは「スコープ」や「コスト」など管理する対象が明確ですが、「統合マネジメント」では明確な管理対象がなく、イメージを持つことが難しいかもしれません。

そこで今回は、「統合マネジメント」の概要をわかりやすくご説明します。

プロジェクト統合マネジメントの概要

統合マネジメントは、プロジェクトマネジメントの中核となるプロセスです。

統合マネジメントを管理することは、プロジェクト全体に最終責任を負っているプロジェクトマネージャーの責任であり、誰かに任したり、責任を移管することでは出来ません。

統合を、英語ではIntegration（インテグレーション）という単語で表します。一体化や融合といった意味で、2つ以上のものを合併して1つにまとめることです。

プロジェクトは本質的に統合的で、ほとんどの課題が複数のプロセスに関わっています。

プロジェクトでは何か一つを変更すれば、他の複数のプロセスに影響が及びます。

複数のプロセスを同時に調整しながら課題解決や変更承認を行えるのは、プロジェクト全体に関わる「プロジェクトマネージャーだけが出来る仕事」と言えます。

「プロジェクトマネジメントの中核」となり、かつ、「プロジェクトマネージャーが責任を持って当たらなければいけない」プロセスが、統合マネジメントです。

プロジェクト統合マネジメントの各プロセス

プロジェクト統合マネジメントは10の知識エリアの中で唯一、プロジェクト立上げから終結まで5つのプロセス郡で、一貫して継続されるプロセスです。

主なプロセスの目的は、プロジェクトマネジメント活動の作業内容を定義決定したり、各プロセスからの結果を統合統一して、課題解決のために各プロセス間を調整します。

役割を理解するには、「オーケストラの指揮者」をイメージするとわかりやすいでしょう。

✔　統合マネジメントの概要のまとめ

①プロジェクトの目的達成のために、各プロセス間を全体的に統合、調整する。

②それが出来るのは、プロジェクト全体の最終責任者であるプロジェクトマネージャー。

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

プロジェクトで最初に取り掛かる作業が、プロジェクト憲章の作成です。

英語では、Project charter（プロジェクトチャーター）と言います。

プロジェクト憲章が認可されることで、正式にプロジェクトが発足され開始されます。

この時に組織からプロジェクトマネージャーへの権限も認可され、プロジェクトを実行、管理するのに必要な各資源（人や時間など）が与えられます。

✔　プロジェクト憲章を作成する利点

「組織の戦略計画」と「プロジェクトの意義」を、結びつけるられるということ！

プロジェクトは、プロジェクトオーナーの組織での「戦略計画」に沿って実行されます。

プロジェクトから生み出される製品やサービスなどの成果物（目標）が、組織のビジネスにとってどのような効果や影響をもたらすのか。

それらのことを結びつけることによって、プロジェクトの目的や意義を明確にします。

目的や意義は、プロジェクトが成功する確率を上げるために重要です。

プロジェクトが成功する確率は、チームのモチベーションや動機付けにかかっています。

「そもそも何のためにやるのか？」という目的をチームと共有し、自分たちの仕事が組織のためになる、しいては、従業員や社会のためになるという意義を明確にすることでメンバーのモチベーションを高く保つ動機付けになるためです。

プロジェクト憲章には、以下のような項目を規定します。

✔　プロジェクト憲章作成の目的

予算、納期、権限レベルなどへステークホルダーの共通理解を得ることです。

「聞いてなかった」などならないように、活動開始前に関係者全員の共通認識を図ります。

プロジェクトを開始する前にビジネスの戦略計画から、戦略的及び業務上の「制約条件」や「前提条件」などが特定され、プロジェクト憲章に反映されます。

前提条件ログは、プロジェクト開始から終結までのサイクル全体を通して、前提条件や制約条件を記録するために使われます。

前提条件が崩れると仮定が崩れ、プロジェクト全体へのリスクとなります。

プロセス全体を通して、前提条件が維持されていることを監視することに努めましょう。

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

プロジェクトマネジメント計画書は、各プロセスの計画を包括的に集約したものです。

開始当初は要約程度の内容で構いませんが、プロジェクトが進むにつれ詳細化され、プロジェクトの実行、監視・コントロール、終結の方法を規定します。

プロジェクト憲章で承認された大枠の目的を達成するために、スコープやコストなど各プロセスでの目標や作業内容、方法を詳細化し、各計画書にまとめます。

プロジェクトマネジメント計画書は、ベースライン化されなくてはいけません。

実行後に測定されたパフォーマンスの比較基準となるよう、少なくてもスコープ（範囲）、スケジュール（時間）、コスト（予算）については標準値を定義する必要があります。

このベースラインが設定されると、各プロセスからのすべての変更要求は「統合変更管理プロセス」によってのみ、審議承認され、変更できるようになります。

プロジェクトマネジメント計画書は、コントロールされ承認された変更によって、プロジェクトの終結まで継続して運用されます。

✔　プロジェクトマネジメント計画書は、取りまとめ文書

プロジェクトマネジメント計画書という文書と作るというよりは、スコープやスケジュール、コストといった各プロセスで作られた計画書を取りまとめた文書になります。

私もプロジェクトの仕事を始めたばかりの頃、取りまとめるだけで良いと気が付くまでは、同じような中身の計画書を何度も重複して作成していました。

初心者には混乱しやすいので、ここで説明させてもらいました。

プロジェクトマネジメント計画書には、次のような文書を含みます。

上記の計画書を取りまとめることで、プロジェクトマネジメント計画書が完成します。

プロジェクトを管理するには、主にプロジェクトマネジメント計画書が使用されますが、他の補助文書も使用され、計画の複雑さや必要性に応じて作成準備するようにしましょう。

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

プロジェクト作業の指揮・マネジメントは、プロジェクトの目標を達成するためにプロジェクトマネジメント計画書で決められた作業をリードし、実行するプロセスです。

要約すれば、計画書に沿った作業を各プロセス群に実行させるということです。

✔　プロジェクト作業の指揮・マネジメントの利点

作業及び成果物を全体的に管理することにより、プロジェクト成功の可能性を高めること！

プロジェクト実行中に、各プロセスの作業パフォーマンスデータを収集して、現在の状況や詳細情報を確認します。現状の把握とともに、プロジェクトのリスクとなる可能性に注意を向けられます。

またこの収集したデータは、次のプロセスになる監視・コントロールプロセス群のインプット情報としても使用し、将来のプロジェクトでパフォーマンスを改善のために学んだ教訓としても使用できます。

プロジェクト作業の指揮マネジメントからのアウトプットは、以下のようなものです。

特に注意が必要なのは、「変更要求」です。

各プロセスから出た変更要求を必ず監視・コントロールプロセス群の統合変更管理に送り、審議・承認を得てから正式に実行プロセスに戻すという手順を踏まなければいけません。

そうすることで、プロジェクトの全作業に無駄がなく、管理下にあることが保証されます。

各スタッフがプロジェクト内容の変更を独断で了承し作業すると、スコープ、スケジュール、コストのいずれもベースライン内で終結出来なくなるリスクになります。

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

プロジェクト知識のマネジメントでは、プロジェクト目標達成し、組織としての学習の貢献するため、組織やチームにすでにある知識を使って新しい知識を創造するプロセスです。

わかりやすく言うと、プロジェクトの成果を改善するために過去のプロジェクトで得た教訓や経験を活用し、また、プロジェクトで新たに得た教訓や経験を今後のプロジェクトに活かすために記録したり、まとめたりするということです。

PMBOKでは知識には二つの種類あり、文書化出来る知識を「形式知」、ノウハウというような個人的で表現するのが難しい知識を「暗黙知」を定義しています。

✔　知識のマネジメントでもっとも重要なこと

信頼の雰囲気を作って人々に知識を共有するように動機付けること！

文書化できる「形式知」だけをチーム内で共有すれば良いと誤解されがちです。

しかし、プロジェクトの成功のためには、チームメンバーやステークホルダーなどがそれぞれに持っているスキルや経験、専門知識「暗黙知」をどれだけプロジェクトの実行中にチーム内で共有出来るかということになります。

知識の共有を強制することは出来ませんので、お互いに共有したり、他の人が知っていることに注目したりといった動機づけをすることで、暗黙知の共有を促進することが重要です。

このプロセスのアウトプットは、「教訓登録簿」になります。

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

プロジェクト作業の監視・コントロールプロセスは、プロジェクトマネジメント計画書に定義された各プロセスの目標を達成するために、進捗状況を確認レビューし、報告するプロセスです。

✔　プロジェクト作業の監視・コントロールの利点

報告によりステークホルダー（プロジェクトの利害関係者）がプロジェクトの現状を理解し、課題解決のためにとられた処置を認識し、各予測データからプロジェクトの今後の状況を把握できるようになること！

監視とは、各プロセスから測定値や傾向値の収集し、計画書と比較評価することです。

監視を継続することで、プロジェクトマネージャーはプロジェクトの健全度を確認でき、注意が必要な箇所を特定することが出来ます。

コントロールとは、是正処置や予防処置、再計画を決定することで、さらに実施した処置が課題を解決したかどうかをフォローアップすることも含まれます。

プロジェクト作業の監視・コントロールのアウトプットには以下のものです。

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

統合変更管理は統合マネジメントのなかでは、プロジェクトマネジメント計画書の作成と並んで重要になるプロセスです。

各プロセスからのすべての変更要求をレビュー承認して、成果物や計画書などへの変更を管理し、決定事項を伝達することが役目になります。

✔　統合変更管理の利点

文書化された変更要求を統合的な方法で管理することにより、変更によるリスクを低減し、プロジェクトの成功確率を上げること！

統合変更管理プロセスは、プロジェクトの開始から完了まで実施され、最終的な責任は、プロジェクトマネージャーが負います。

統合変更管理プロセスでの注意点としては、以下があります。

統合変更管理プロセスのアウトプットは、以下になります。

プロジェクトやフェーズの終結（終結）

プロジェクトやフェーズの終結は、プロジェクト、フェーズ（段階、区切り）または契約上のすべての活動を完結するプロセスである。

プロジェクトやフェーズの完了した作業の情報や結果を保管し、チーム（資源）を新しい取り組み（仕事）のために開放する。

プロジェクト終結時にプロジェクトマネージャーはプロジェクトマネジメント計画書をレビューし、すべてのプロジェクト作業の完了とプロジェクトの目標が達成されていることを確認しなかればならない。

主な活動内容としては、以下のようなものがあります。

✔　チームは解散され、プロジェクトは完全に終結する

プロジェクトマネージャーはチーム解散のため、すべてのステークホルダーを関与させ、プロジェクトの完全終結への合意を得ることが必要になります。

このプロセスからのアウトプットは、以下になります。

まとめ：プロジェクト統合マネジメントのプロセス

統合マネジメントでは、「プロジェクト」そのものが管理対象です。

プロジェクト全体に進む方向を示す司令塔であり、結果を審査する監査人でもあります。

チームメンバーの中で唯一、プロジェクト開始から終結までプロセス全体に関与するプロジェクトマネージャーが統合マネジメントに責任を負っているというのも納得できます。

それでは、みなさんの参考になれば幸いです。

▼こちらの関連記事もどうぞ！

【PMBOK】プロジェクトマネジメント立ち上げプロセス群、計画プロセス群について【現役PMPが解説】

こんにちは、MARCUS（マーカス）です。 プロマネ初心者で何から手を付けようか悩んでいる人『プロマネを任されたけど、何をすればよいかわからない。』『とりあえず立上げ～計画で、何をすればよいか知りたい ...

続きを見る