Lesson 1 : 統合管理

統合管理とは?

『統合管理』とは、PMBOK準拠の弊社プロジェクト管理方法論PMM^※1で定義されている、プロジェクトマネジメントの管理領域の1つである。他の8つの管理領域^※2を束ねる形で、プロジェクトの立上げ～終結までを管理する。計画フェーズにおいてプロジェクトの管理計画及び実行計画の作成と、後続フェーズにおいてプロジェクトの総合的なパフォーマンス管理、コンフィギュレーション管理、変更管理を実施する。

※1 Hitachi Consulting Project Management Methodology

※2 前回の「"PM力"向上に向けて」章を参照されたい。

今回はこの統合管理に関連したお話である。

漏れのないプロジェクト実行計画を立てるには

プロジェクトの実行計画は、通常、WBS^※3によりプロジェクト・スコープを策定し、WBSの最下層となるワークパッケージや子となるアクティビティに対して、所要時間や依存関係、必要リソースやコストを調整していくことで作成される。品質計画や調達計画など、プロジェクトマネジメントに関する他の管理領域を俯瞰しつつ作業を実施する必要があるわけだが、全ての中心となるのはWBSである。

※3 Work Breakdown Structure

WBSとはプロジェクトで実施する作業を構造化したものであり、親となる作業を遂行するために必要な作業をその子として全て書き出していくことで作成される成果物である。WBS作成にあたっては、プロジェクトの最終成果物(例えば、ITシステム)に対して、その成果物を生み出すために必要な作業とは何かをゼロベース思考で洗い出していくことが必要となるが、WBS作成担当者の知識や習熟度に依存するリスクとして検討不足や漏れが懸念される。

このリスクを回避するための施策の1つが『テーラリング』手法である。

テーラリングでは、事前に標準化したWBSをお手本として、対象プロジェクトに合わせて必要な作業を取捨選択していく。標準として提供されるWBSが企業のベストプラクティスとして構築されたものであれば、必要な作業をすべて含む網羅的なものとなっていると考えられるため、経験不足などのWBS作成担当者個人に起因するリスクを回避することができる。

またWBS作成にかかる時間も短縮できるので一石二鳥である。プロジェクトマネジメントを支援するツールの中にも、標準WBSをテンプレートとして保存できるものも登場してきており、テーラリングはプロジェクトマネジメントにおける常識として着実に浸透している。

では、テーラリングに落とし穴はないのか?

答えはノーである。効率化や省力化に寄与する手法やツールの採用は、作業者に対して思考停止をもたらす可能性がある。これまでプロジェクトマネジメントの領域で試行錯誤をしてきた経験者であればテーラリングを上手く使いこなすことができるであろうが、新しくプロジェクトマネジャーに任命されたばかりの初心者にとっては諸刃の剣である。

ベストプラクティスをテーラリングすれば上手く行く、と安易に考えてはいけない。テーラリングした結果であるWBSが本当に該当プロジェクトの作業スコープを全て含んでいるか、不足はないか、抜け漏れはないか、経験者の多くが当たり前のように行っているゼロベース思考を、意識的に実施することを心がけるべきである。プロジェクトの定義の1つに『特異性(ユニーク性)』があるが、まだ誰も通ったことのない道を歩き出すのだから、参考はあくまで参考として、自身のゼロベース思考を磨くことを決して忘れてはいけない。

変更要求に振り回されないために

ITシステム開発プロジェクトにおいて、避けて通れないのが変更要求(仕様変更)である。

プロジェクト期間が長ければ長いほど、変更要求が発生する可能性は高まる。変更要求に対する管理プロセスをユーザー企業とシステムインテグレーター間で合意しておくことは、プロジェクト開始前の前提条件の1つである。

変更管理プロセスとしては、要求事項に対する判断基準や判断権限のレベル、変更要求書や変更一覧表の準備および運用ルールなどを明確化する。プロジェクトが開始されたら、全ての変更要求に対して例外なく、変更管理プロセスを適用していく必要がある。これは仮に変更管理プロセス自体に問題が見つかった場合であっても同様である。

最後に不可避である変更要求と上手く付き合うために、ユーザー企業およびシステムインテグレーターに共通するTIPSをご紹介しよう。

それは、プロジェクト開始の前提条件として、変更要求への対応コストを予備費として予め計上しておくことである。承認された変更要求への対応コストに加え、その前段となる『承認するかどうか判断をするために必要な諸作業』に対する対応コストを見ておくことが重要である。一度、変更要求が発生すれば、担当作業への影響分析や変更判定会議への参加など、見えないコストがかさむ。変更要求の発生は不可避と考え、プロジェクト開始前に予備費を計上しておくことを強く推奨する。