プロジェクトをブレなく推進するためには、「プロジェクトチャーター（プロジェクト憲章）」や「プロジェクトスコープ記述書」が有効なツールとなる。しかし、これらの名前を知っていても、どのように作成すべき文書なのか、まだ十分に理解されていない。その作成をITベンダーなどに丸投げすると、偏りのある内容になってしまいがちだ。客観的な立場でプロジェクトを見ることができるPMOには、文書を実のあるものにする、大きな役割がある。
高橋信也
マネジメントソリューションズ 代表取締役
システム開発プロジェクトにおいて、詳細設計フェーズ以降、プログラミング、単体・結合テスト、システム・テストなどでは、ほとんどの作業が明確になり、担当者もほぼ完璧に割り振ることができるでしょう。このため、大きな仕様変更でもない限り、作業の抜け・漏れをほとんどなくすことができます。詳細スケジュールとして作成したWBS（Work Breakdown Structure）はうまく活用され、計画と実績の対比も有効に行えます。
しかしながら、プロジェクトの立ち上げフェーズや計画段階、またはシステム開発プロジェクトにおける要件定義フェーズなどでは、作成したWBSがすぐに現実と乖離してしまうでしょう。計画と実績の対比はおろか、担当者の作業の負荷状況も見えにくくなることがよく起こります。当初予定していた作業工数よりも少ないのであれば対応も容易なのですが、ほとんどの場合、予定外の作業が出てきたり、思っていたより調整が難航したりするケースが多いものです。
確固たるスコープは作業のブレを小さくする
そのような事態に陥らないために、プロジェクトのスコープや前提条件を盛り込んだ「プロジェクトチャーター」や「プロジェクトスコープ記述書」を作成することが有効な対策の1つです。プロジェクトチャーターはPMBOK日本語版でプロジェクト憲章と訳されているようですが、「プロジェクトの背景と目的、内容など、これから実施するプロジェクトの定義を明記した文書のこと」であり、「プロジェクト外部でその作成と認可が行われる」とされています。
ただ実際には、プロジェクトを客観的に定義できる外部の人間が作成するのではなく、プロジェクトマネジャが作成したり、ITベンダーやコンサルタントが作成することが少なくありません。特にコンサルタントやシステム開発を請け負うITベンダーが作成した場合、総花的なプロジェクト憲章やプロジェクトスコープ記述書となり、自社に都合のよい内容になることもしばしばです。
また、他のプロジェクトとの関連やプロジェクト実施中に発生し得る様々なリスクも加味して作成すべきですが、利害が偏るため、なかなか網羅的な内容になりません。
PMOは、客観的にプロジェクトの状況を把握する立場として、このプロジェクト憲章およびプロジェクトスコープ記述書の作成に、積極的に関与すべきです。一部のITベンダーでは、プロジェクトの開始前に採算を判断するためのPMOを組織し、収益改善に貢献していますが、プロジェクト憲章の作成段階からPMOが参画することで、プロジェクトを推進していく中でもスコープ調整に貢献することができるようになります。
客観的な視点から率直に意見を出す
もちろんPMOの役割は、他のチームのようにプロジェクトの成果物を作成することではありませんから、中身にまで突っ込んだ議論ができないジレンマもあります。しかし、ある意味コンサルタント的な役割でプロジェクトにかかわり、客観的な視点で貢献することができるため、プロジェクトマネジャやチームリーダーとは違った意見を出せるでしょう。
例えば、想定されるリスクを洗い出す際、プロジェクトマネジャが言いにくいことであっても、PMOの立場であれば言える場合があります。また、コンサルタントやITベンダーの意見を取りまとめ、調整することも可能です。このようなプロジェクト開始当初からのPMOの参画は大変重要であると考えます。
|
