プロセスに着目し、統合マネジメントをイメージする：メンバーに贈るプロマネ基礎講座（2）（2/3 ページ）

[田中亮，グローバル ナレッジ ネットワーク]

プロジェクトマネジメント計画の統合〜「プロジェクトマネジメント計画書作成」プロセス（第4章3項）

　プロジェクトが立ち上がり、スコープ記述書の暫定版が作成されると、プロジェクトマネージャはチームを編成し、プロジェクトの計画を立てていきます。このとき、プロジェクト作業をどのように進めるかという計画とともに、どのように管理していくかという計画も立てます。

　例えば、「プロジェクト・スコープ・マネジメント」の知識エリアでは、プロジェクトのスコープを詳細に定義し、WBSを作成していきますが、それらの作業に先立ち、そのプロジェクトにおけるスコープ・マネジメントをどのような方針で行っていくかを決める必要があります。これをまとめた文書がスコープ・マネジメント計画書ですが、詳細は次回解説します。同様に、今回のプロジェクトの計画でも、プロジェクト計画を詳細に定義していく中で、プロジェクト作業の進め方や管理の仕方といった方針を立てていきます。

　プロジェクトの計画を立てるプロセスでは、スコープ・マネジメント計画書など、補助となる計画書を統合、調整し、最終的に、プロジェクトマネジメント計画書という形で取りまとめます。プロジェクトマネジメント計画書には、スコープ・マネジメント計画書などのほかに、計画段階で策定した、プロジェクトスケジュールや予算などのベースライン（パフォーマンス測定ベースラインという）なども含みます。また、プロジェクトマネージャやプロジェクトマネジメント・チームが選択したプロセスとそのプロセスの実行レベルなども定義されます。

　ところで、プロジェクトマネジメント計画書作成プロセスを理解するためのコツをご紹介します。PMBOKガイドの第3章の計画プロセス群の個所では、すべての計画プロセス群の流れが定義されており、プロジェクトマネジメント計画書作成プロセスは、計画プロセス群の最初に行うプロセスとして定義されています。しかし、このプロセスのインプットに「プロジェクトマネジメント・プロセス（5章〜12章に記載）」が定義されています。これは、プロジェクトマネジメント計画書作成プロセスが、そのほかのプロセスをインプットとして使用することを意味しますので、いささか矛盾しているように感じます。

　でも、これは矛盾しているわけではありません。計画プロセス群全体を統括するのがこのプロセスの役割ですから、個々の計画プロセスは、このプロセスの一部として作業していると考えるとよいでしょう。なお、これ以降に登場する統合マネジメントの各プロセスは、これと同じような特徴を持っています。

プロジェクト作業の実行〜「プロジェクト実行の指揮・マネジメント」プロセス（第4章4項）

　プロジェクトマネジメント計画書作成プロセスと同様、プロジェクトの実行プロセス群を統括するのが「プロジェクト実行の指揮・マネジメント」プロセスです。このプロセスの主要なアウトプットは要素成果物であり、要素成果物を生成するために行った活動の状況は、作業パフォーマンス情報として収集されます。また、表3のように、インプットには「承認済み変更要求」など、「承認済み××」という名前の要素が、アウトプットには「実施済み変更要求」など、「実施済み××」という名前の要素が多数含まれます。

　これは、このプロセスが単にプロジェクトの成果物を生成するための活動だけでなく、次に説明する「プロジェクト作業の監視コントロール」プロセスなどによって承認された、変更要求や是正処置などを実施する、プロジェクトマネジメントにかかわる活動もこのプロセスの範囲であることを意味します。

プロジェクト実行の指揮・マネジメント
インプット	1．プロジェクトマネジメント計画書 2．承認済み是正処置 3．承認済み予防処置 4．承認済み変更要求 5．承認済み欠陥修正 6．確認済み欠陥修正 7．事務終了手順
ツールと技法	1．プロジェクトマネジメント方法論 2．プロジェクトマネジメント情報システム
アウトプット	1．要素成果物 2．要求済み変更 3．実施済み変更要求 4．実施済み是正処置 5．実施済み予防処置 6．実施済み欠陥修正 7．作業パフォーマンス情報
表3　プロジェクト実行の指揮・マネジメントプロセスのインプット／ツールと技法／アウトプット

プロジェクトの状況の確認〜「プロジェクト作業の監視コントロール」プロセス（第4章5項）

　「プロジェクトの監視コントロール」プロセスもこれまでのプロセスと同様、監視コントロールプロセス群を統括するプロセスです。プロジェクトの立ち上げ、計画、実行、終結に関連するプロセス全体を監視します。そしてプロジェクト計画に沿ってプロジェクトが進むようにするため、是正処置や予防処置を提案します。これらを実施するのは、実行プロセス群の仕事です。

　また、プロジェクトが進むに従って、これまで不明確だったものが明確になるなど、当初の計画の内容を変更する必要が発生します。プロジェクト計画に対する変更は変更要求（要求済み変更）と呼ばれ、このプロセスの主要なアウトプットを構成します。

プロジェクト計画変更の統括〜「統合変更管理」プロセス（第4章6項）

　プロジェクトの特徴に「独自性」があったように、プロジェクトにはこれまでに実施したことのない作業などが含まれる可能性があります。その結果として、プロジェクトには計画の変更が付きまといます。これが、監視コントロールのプロセスからアウトプットされる変更要求です。

　ただし、プロジェクトに変更は付き物とはいえ、すべての変更に対応していたら、予算は超過し、スケジュールは遅延する可能性が大きくなります。従って、発生した変更要求は適切に管理し、変更は必要なもののみに限定しなければなりません。

　そのために、統合変更管理プロセスは、プロジェクトで発生する変更要求を一元管理するための仕組みを提供します。一般にプロジェクトで発生した変更要求はすべて、プロジェクト・スポンサー、イニシエーター、顧客などから構成される変更委員会にかけられ、承認または却下されることになります。変更要求が承認されると、プロジェクト計画は変更され、ベースラインも改訂されます。

プロジェクトの公式な終了〜「プロジェクト終結」プロセス（第4章7項）

　プロジェクトはプロジェクト憲章によって公式に認可され、開始されましたが、同様に公式に終了させる必要があります。「プロジェクト終結」のプロセスでは、プロジェクトを公式に終了させるための手順（事務終了手順）を定義します。

　PMBOKでは、プロジェクトを終了した際、プロジェクトで作成した文書やプロジェクトで得た教訓などを整理し、以降のプロジェクトで参照し、活用することを推奨しています。

　解説の最後に、組織のプロセス資産について触れておきます。プロジェクト終結の際、プロジェクトで得られた教訓などを記録することが推奨されますが、これらは組織のプロセス資産として蓄えられていくことになります。組織のプロセス資産には、教訓や過去の情報のほか、母体組織が持つプロジェクトマネジメントの標準プロセスやテンプレートなどを含み、プロジェクトのいたるところで参照されます。プロジェクト統合マネジメントの知識エリアでも、プロジェクト憲章作成、プロジェクト・スコープ記述書暫定版作成、プロジェクトマネジメント計画書作成、各プロセスのインプットに定義されています。