プロジェクト計画書のコンテンツとテンプレート
プロジェクト計画書を書くのはレビューを受けるために書くと思っているならプロジェクトマネージャは辞めた方が良い。書くことを強制されるから、書かないと怒られるから、レビューを受けないと……、などと思っているとするなら、その人はプロジェクトマネージャの仕事を分かっていないのだ。メンバを不幸なプロジェクトにいれないためにも辞めた方が良い。
PMP(Project Management Professional)がクローズアップされたのは2004年ごろだったから、PMBOKがバズッてから10年経つ。さすがにプロジェクト計画を書くことが定着した感はあるけれど、10年の間に人は世代交代していくものなので10年前にあったような「なぜプロジェクト計画書を書かないといけなのか？」ということを言い、書かない理由を並べる自称プロジェクトマネージャは今も後を絶たない。ただ、残念ながらプロジェクト計画を書いたとしても、楽をしたいためだけに流用して改悪したプロジェクトマネージャは、元の計画書がなぜそのように書かれたのかその意図も理解できず運営される結果、自称プロジェクトマネージャに振り回されるプロジェクトも後を絶たない。
本来、プロジェクトは一人ではできず多くの人を巻き込んで運営するものだから、プロジェクトをリードするプロジェクトマネージャがどのように運営するつもりなのか、プロジェクトに関わる人達のふるまい方を決め、示さねばならない。それがプロジェクト計画書であるし、プロジェクト計画書をわざわざ作成する目的もそのためなのである。
とは言え、プロジェクトを受注するたびに真新しく一からプロジェクト計画書を作成するのでは効率が悪いし、書かなければならないコンテンツが抜けてしまうことだってある。だから、テンプレートを作っておく。テンプレートと別にそのコンテンツに書かなければならない具体的な事例を書いておく。これは、初めてプロジェクトマネージャを担う若葉マークのプロマネにとってとても助かるのだ。そして、それはテンプレートを整備し続ける人への一次問い合わせを軽減することが出来る。具体的な事例の他に、プロジェクト計画書から外部文書を参照するケースもある。例えば、品質管理実施要領とか変更管理実施要領などである。これらの文書をプロジェクト計画書から参照するのであれば、その参照する文書の所在を記載する。プロジェクト計画書の目次の前に関連文書の一覧を記載するとか、この後で述べるプロジェクト計画書に書くコンテンツの本文として参照先のドキュメント名称と所在を書いておくことでテンプレートに書くひと手間がそのテンプレートを利用する複数のプロジェクトマネージャの作業コストを削減することになる。
プロジェクト計画書に書くコンテンツ
プロジェクト計画書に書かなければならないコンテンツは、どのプロジェクトでも必ず書かなければならないコンテンツと必要に応じて書けばよいコンテンツに分かれる。プロジェクト計画書のテンプレートを作成するとするならば、知る限りのコンテンツを一旦は取り込み、そのコンテンツから組織として共通項であるものを取捨選択した上でテンプレートとと決めておく方が良い。テンプレートにある組織の事業特有のコンテンツが混じることは他の組織だけで使われるコンテンツを誘い込むことになるしそれは迷路のような文書構成を自ら作り上げるようなものだからだ。目次構成こそ構成管理されていなければならない。
プロジェクト計画書の目次
プロジェクト計画書に書くコンテンツをざっと記憶の奥底から拾い上げると以下のとおりになる。大項目だけでこれだけ必要になるのだ。中項目以降まで展開していくつもりでいたならテンプレートを作った方が良いと実感するだろう。そして、記述要領がなければ書けないと思う事も、又、正しい感想だと思う。
大項目だけでこれだけのコンテンツがあることがわかれば、逆の観点から言えば、プロジェクト計画書を書かずにソラで必要なときに必要なコンテンツを提示できるのは素晴らしいことだと感心する。ただし、それは個人事業のカリスマプロジェクトマネージャならば。組織の中のプロジェクトマネージャなのであれば、後進を育成することも先人の仕事であるしそれが組織の継続的な維持繁栄上必要なことであるから許されない。依って、然るべきプロジェクト計画書のテンプレートを整備しなけばならない。
プロジェクト計画書の文書構成と目次
これだけの文書構成を鑑みれば、プロジェクト計画書を文書としての維持管理の手軽さを考慮する結果、プロジェクト計画書は方針、イベントレベルの予実と参照する文書のリファー先のポインタに絞る構成とした方が良い。つまり、具体的な要領は分冊としてしまうのである。プロジェクト計画書という本編の文書と分冊する要領編に分けるのである。また、成果物と記録類なども合わせてプロジェクト構成管理をどうするか最初に決めておくことが肝要となる。
プロジェクト計画書の目次構成は、事を動かす前に定義すべきことを定義し、後続のアクティビティでその定義を踏まえふるまうような構成が望ましい。ただ、実際のテンプレートでは組織ごとの都合に合わせて適宜調整されるのが現実的で利用されるテンプレートとなるのだろう。
プロジェクト計画書のコンテンツのテーラリング
プロジェクトの特性により、プロジェクト計画書のコンテンツをすべて書くことが難しいものが想定される。例えば、設備とアプリケーション開発では違いそうだということは誰にでも想定できることである。それはプロジェクト計画書を作成しなければならないプロジェクトの特性でコンテンツを取捨選択せよということである。先の設備の場合が物理的な成果物が多いが故にソフトウェア開発プロジェクトと差異が明確に示せるのであり、インフラ構築とアプリケーション開発ではプロジェクト計画の大項目レベルでは目次構成の差異はほとんどないと言い切ってよい。そのコンテンツとして記載するレベル、具体的な内容が違うだけだ。
結論から言えば、テンプレートは設備も含めて1つで充分で、何を実際書けばよいか記述要領の方で具体的に設備は記載が不要とか、アプリケーション開発では「こう書け。」と指示すればよい。
プロジェクト計画書の更新とテンプレートの更新タイミング
プロジェクト計画書はいつも最新でなければならい。それは、常に先を見て計画し、実績が計画と差異を生じているなら軌道修正をするべく策を打つか、計画そのものを修正しなければならないからである。計画を実行しその結果際の予兆があれば課題とし、そのインパクトの大小でリスク管理へ遷移させる。リスクがプロジェクト全体の問題であり、顧客要件の実現に影響するのであれば会議体を通じ対策の実行の裁可と実績の評価を踏まえ、変更するか否かをプロジェクトの目標から設定するクライテリアに沿って判断しなければならない。こうした極端な事態にならなくても日々計画どおりに進捗していても計画に予実が生じることから主なマイルストーンの実績を更新することなり、やはり、プロジェクト計画書は次へ進むために維持されるのである。
プロジェクト計画書のテンプレートも適宜更新されなければならない。それはテンプレート自体に過不足があると言うことを当然とするからである。システムの開発はシステム開発手法に新しい考え方が提示され、それをプロジェクトで採用するとするならばテンプレートはその新しい考え方を取り込むかどうかを判断しなければならない。判断したうえで取り込むのであれば、テンプレートのコンテンツとして取り込むのか、記述要領として具体的に例示するかで対応する。いずれにしても、潮流に合わせて更新されるものであり、一旦テンプレート化すれば維持管理は不要だと言う硬直した考えは使われるプロジェクト計画書のテンプレートから遠ざかってしまうのである。
