トピックス

PMBOK®ガイド 第5版紹介シリーズ 第10回  プロジェクト統合マネジメント

PMBOK®ガイド  第5版 紹介シリーズ
第10回 プロジェクト統合マネジメント

PMBOK® 委員会
鈴木 安而 

はじめに

 「統合マネジメント」の「統合」とは、インテグレーション(Integration)のことです。つまりプロジェクトマネジメントの中心にあって全体のコーディネーションを行ったり取りまとめを行ったりするプロセス群です。

 そもそも「統合マネジメント」はPMBOK®ガイド の成り立ちから言えば比較的後半に定義された知識エリアです。1969年にPMIが設立され、最初のプロジェクトマネジメント知識体系の研究では、スコープ、タイム、コスト、品質、人的資源、コミュニケーションの6つの領域が定義されました。最初のPMBOK®(まだ“ガイド”にはなっていません)発刊の年には、リスクと調達の領域が追加されて8つになったのですが、その後の研究の結果、全体を取りまとめる概念的な知識エリアとして統合マネジメント領域が定義され、9つとなり、1996年にPMBOK®ガイド として第1版が出版されたのです。その後16年を経て第5版で「ステークホルダー・マネジメント」が追加され10の知識エリアになったことは、シリーズの最初に紹介させていただきました。

6つのプロセス

 「統合マネジメント」は、知識エリアやプロセスの相互作用を取りまとめることがその主たる目的で、次の6つのプロセスが定義されています。

  1.プロジェクト憲章作成

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

  3.プロジェクト作業の指揮・マネジメント

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

  5.統合変更管理

  6.プロジェクトやフェーズの終結

これら6つのプロセスは、プロジェクトの大きな流れを示していますが、「プロジェクト作業の監視・コントロール」と「統合変更管理」は、監視・コントロール・プロセス群の一部でありプロジェクトのバックグラウンドとして機能しますので、プロジェクトの開始から終結まで途切れることなく活動します。プロセスや知識エリア間の相互作用が複雑なので詳細なプロセス・フローは描けません。簡単な流れを「図- プロジェクト統合マネジメント・プロセスを中心としたフロー」に示します。詳細はPMBOK®ガイド を参照してください。

project_togo_management_2.JPG

 コンフィギュレーションとの相違

さて、今回は統合マネジメントの中でも理解が難しいと言われる「統合変更管理」に焦点を当てて解説いたします。例えば「コンフィギュレーション・マネジメント」との違いを中心に説明しましょう。

 コンフィギュレーション・マネジメント活動は、一般に「構成管理」とも呼ばれます。ソフトウェア開発などにおける「バージョン管理」もその一つです。この活動は、プロジェクトにかかわらず日常管理の一つであり、組織にとって必須の管理活動として標準化されているのが一般的です。プロジェクトでは統合変更管理プロセスに含まれるように活動しますが、そもそも組織で標準化されたプロセスなので、プロジェクトにおける管理活動とのすみ分けや役割分担がポイントになります。

 一般的なコンフィギュレーション・マネジメントの主たる活動としては、まず、管理対象とするコンフィギュレーションを決めて、その中から対象とする品目を選びます。次にその品目についての現状把握を行い、事実に基づいた情報を記録し、しかるべきステークホルダーに報告します。その時点でのコンフィギュレーションをベースラインとして、一定の頻度で検証と監査を実施し、品目の構成が正しいかどうか確認します。これらの活動がデミング・サイクル(PDCA)の考え方の下で繰り返されるのです。

 統合変更管理ですること

 では統合変更管理は何をするのでしょうか。理解のためには、統合変更管理の下に「変更管理」と「コンフィギュレーション・コントロール」の二つのプロセスがあると考えてください。ちなみに「変更管理」は「チェンジ・コントロール」です。PMBOK®ガイド によりますと、「変更管理は、プロジェクトの文書、あるいはベースラインに対する変更の特定、文書化、可否、について焦点を合わせる」とありますし、「コンフィギュレーション・コントロールは、成果物とプロセスの仕様について焦点を合わせる」とあります。これを図示すると、「図- 変更管理とコンフィギュレーション・コントロールの担当領域」のようになります。つまり、それぞれの担当領域は、「プロジェクト領域」と「プロダクト領域」に分かれますが、重複する領域があります。したがって変更マネジメント計画において、この重複領域についての役割分担を決めなくてはなりません。

 コンフィギュレーション・コントロールを構成管理ととらえると、プロダクトのコンフィギュレーションやバージョン管理を担うことになります。またその活動のツールとして、コンフィギュレーション・マネジメント・システムを利用しますが、それはPMIS(プロジェクトマネジメント情報システム)の一部とも言えるのです。そして、プロジェクト後における機能性を計画したり文書化を確実にしたりするのですが、最小限の機能から最高位の目的まで幅広い活動となります。

 結局、コンフィギュレーション・マネジメントとプロジェクトの変更管理とは明確な境界がありません。プロジェクトの特性に合わせて、役割分担を決めていく必要があります。

henko_kanri.JPG
以上

当連載の他の記事へのリンク

  第1回 イントロダクション
  第2回 ISO21500について
  第3回 ステークホルダー・マネジメント
  第4回 ナレッジ・マネジメント
  第5回 アジャイル型ライフサイクル
  第6回 プログラム、ポートフォリオ
  第7回 スコープ・マネジメント
  第8回 タイム・マネジメント
  第9回 リスク・マネジメント
第10回 統合マネジメント
第11回 PMBOK®ガイド は使えるのか
第12回 PMBOK®ガイド 拡張版