前々回「第9回 丸投げは失敗の始まり――調達マネジメント(1)」と前回「分からないまま進めない――調達マネジメント(2)」と2回にわたり、調達マネジメントの勘所を解説した。
そのポイントは、ベンダ任せではなく、発注者側もその選定・作業管理に積極的に関与していく「丸投げからの脱却」である。これは、一朝一夕に果たせるものではない。技術領域の細分化、複雑化する現在のプロジェクト環境、および、現業を抱える発注者側メンバーの時間的な制約など、さまざまな理由が考えられる。
しかし、ベンダに泣かされるのが嫌なら自分たちがしっかりするしかない。このことを忘れず、いま以上に一歩踏み込んでベンダマネジメントに取り組んでいただきたい。
さて、当連載もいよいよ今回で最終回だ。当連載は、「第1回 プロジェクトメンバーを1つにまとめる」で開始した。以来、PMBOKで定義される知識エリア(スコープ、スケジュール、コスト、品質、人的資源、コミュニケーション、リスク、調達)を順を追って解説してきた。
最終回となる今回は、統合マネジメントについて解説する。統合マネジメントとは、先に述べた8つの個別知識エリアを統合してマネジメントすることを意味する。
例えば、スコープを拡大するとスケジュールやコスト、あるいは、組織(人的資源)も合わせて変更する必要が出てくる。つまり、各知識エリアは、互いに密接に関係しており、個別に検討や取り組みを行うのではなく、関連のある要素(知識エリア)を見極め、全体的にバランスさせていくことが求められるのだ。では、まずPMBOKにおける統合マネジメントの定義を確認しよう。
PMBOKには、「プロジェクトのさまざまな要素を調和の取れた形に統合するのに必要なプロセスからなる」とある。
統合マネジメントのプロセス | 主要成果物 | 説明 |
---|---|---|
プロジェクト計画の策定 | プロジェクト計画書 詳細資料 |
プロジェクトにおけるすべての計画を統合・調整し、首尾一貫した文書を作成する ⇒実際の成果物としては、ほかの知識エリアで定義されている各マネジメント計画書の統合版をイメージするとよい |
プロジェクト計画の実行 | 作業結果 変更要求 |
プロジェクト計画書に含まれているアクティビティを実行することにより、プロジェクト計画を実行する。⇒ここでいう作業結果は、プロジェクトで遂行した作業の結果、つまりは作成した成果物を意味する |
プロジェクト計画の実行 | 作業結果 変更要求 |
プロジェクトにおけるすべての計画を統合・調整し、首尾一貫した文書を作成する ⇒実際の成果物としては、ほかの知識エリアで定義されている各マネジメント計画書の統合版をイメージするとよい |
表1 PMBOK(2000Edition)における統合マネジメント |
表1のようにPMBOKでの統合マネジメントは、3つのプロセスにより構成されている。しかし、これまでの知識エリアの定義と比較すると、具体的に何をするのかピンとこない読者もいるかもしれない。これは統合マネジメントが、ほかの知識エリアでのマネジメント結果を、統合・調和させていくことを狙いとしているからだ。
つまり、何かを独自にマネジメントするのではない。ほかの知識エリアとの統合・調和とはどういうことか? ケーススタディで詳しく解説する。
ちなみに、現在公表されているPMBOK第3版では、この統合マネジメントは大きく変更されている。その内容は、新たなプロセスが追加されるなど、以前より強調され、重要性が高まったものとなっていることを補足しておく。興味がある方は、「改定されたPMBOK−PMBOKの最新バージョンとは?」を参照してほしい。
Copyright © ITmedia, Inc. All Rights Reserved.