2007年09月07日更新

第1回　場当たり的な対応を回避する、「統合マネジメント」の重要性

仕様変更ありきのルール決め

　ただし、この計画に絶対に従わなくてはならないというわけではありません。ITの場合は仕様変更などは当たり前のことなので、仕様変更を踏まえたプロジェクトマネジメント計画書の作成が求められます。その際は、仕様が変更されるときに、どういう手続きで行なうのか一定の基準(ルール)を決めておくことが大切です。これを決めておかないと、それぞれの担当者が各々の判断で仕様変更をしてしまい、プロジェクトに混乱をまねく可能性があります。つまり、仕様変更を考えたルール作りに限らず、細かいところまでしっかりルールを決めていくのがプロジェクトマネジメント計画書の作成なのです。

　特に、仕様変更の凍結をいつ行なうということはしっかり決めなければなりません。そうしないと、いつまで経っても仕様変更が繰り返され、プロジェクトの終わりを見ることができないからです。同時に、何をもって作業が完成したといえるか、何をもってプロジェクトが終結するのかもはっきり決めなければなりません。ITの場合は作業内容がクライアントに見えにくく、すぐに手直しできそうに思われることも多いので、ずるずると作業が続いてしまう可能性もあるからです。

“プロジェクトの資産を残す”という意識

　PMBOKでは、プロジェクトのスタートであるプロジェクトマネジメント計画書について“スコープ・マネジメント計画書、スケジュール・マネジメント計画書、コストマネジメント計画書をはじめ多くのマネジメント計画書を作成する”（図1参照）とあります。しかし、プロジェクトマネジメント計画書をゼロから作るのは大変な作業なので、これらすべてを作成する必要はないと思います。プロジェクトに応じて、必要な計画書だけを作るようにするといいでしょう。その際は過去の仕事の資産を活用することをお勧めします。これをPMBOKでは“組織のプロセス資産”と言い、過去の仕事で漏れた作業や失敗した事例などを修正して作り上げた経過と経験を蓄積したものを表しています。それを参考にプロジェクトマネジメント計画書を作成すると、実際の経験の少なさをカバーでき、成熟したプロジェクトマネジメント計画書ができるはずです。


プロジェクトマネジメント計画書～PMBOKガイド第3版より引用～

　こうして考えると、プロジェクトマネジメントの使命は、プロジェクトをうまく推進し、クライアントが満足する結果を残すことだけではありません。さらに、プロセス資産を蓄積することも使命だと言えるでしょう。そのためにプロジェクトの結果だけでなく、推移を記録し残していく必要があります。そうすれば、自分以外の後進のプロジェクトマネージャーも、そのナレッジを生かしてマネジメントができるはずです。プロジェクトマネージャーはプロジェクトのスタートに際して、今のプロジェクトだけでなく、これから先に発生するプロジェクトをも踏まえた計画と、心構えが必要になってくるのです。