「プロジェクト計画書を作成する必要があるか」とプロジェクト・マネージャ(PM)に尋ねると,100%と言ってよいほど「Yes」という答えが返ってくる。では,実際に皆さんの社内プロジェクトの計画書作成率はどうだろうか?「100%の作成率だ!」という会社は少数ではないだろうか。筆者の会社も,今は100%に近い作成率であるが,5年前は60%程度であった。計画書作成をペーパーワークと思ってはいけない。

 なぜ頭では分かっているのに,作成しないのか。PMに聞いてみると「忙しくて計画など作成している暇がない」「スタート時点で明確に決定している項目が少なく書けない」「計画通り進まないので必要性をあまり感じない」など様々な事情がある。

 そもそも計画書は何のために作成するのか。計画書は,プロジェクトの成功可否を決定する重要なドキュメントである。見積もり時点より詳細化されたスコープやコスト,スケジュールといったマネジメント基準となる「ベースライン」となるからだ。

 筆者はPMO(プロジェクト・マネジメント・オフィス)の立場で,多くのプロジェクトを見てきている。そこから言えることは「忙しくて計画など作成している暇がない」というPMでも,途中で何度も工程を作り直す時間は持っている。「スタート時点で明確に決定している項目が少なくて書けない」というPMは,「ベースライン」がないため一見予定通り進捗しているように見えていても,実際は遅れていることに気づかず,気づいたときには既に工程が大幅に遅延している。「計画通り進まないので必要性をあまり感じない」というPMは,プロジェクトを計画通りに完遂しようという意志がないのでトラブル・プロジェクトとなる。

 以上のような状況に陥らないためには,プロジェクト計画書をきちんと策定し,ベースラインを作る必要がある。では,どんな点に注意して策定すればよいか。

計画書はPMの意志表示である

 PMは,見積もりの「成功へのシナリオ」を描いているはずである。それを思い出し,計画書に落とし込む必要がある。「成功へのシナリオ」を実現するために,何をしなければいけないか。具体的な作業や行動を洗い出す。これができなければ,成功へのシナリオも絵に書いたもちとなってしまう。

 プロジェクトには不確実性や複雑性が伴う。放っておいて計画通りに遂行できるということはまずない。計画書に書く内容は,PMがプロジェクトをどのように遂行していくかの意志表示である。PMは計画の範囲内に収まるように,プロジェクトをマネジメントする必要がある。

 類似プロジェクト,成功プロジェクトの計画書の流用は間違っていない。むしろ効率面や経験の利用,参加意識の向上などを考えると必要だ。だが,ここにPMの意志が反映されなければ,計画書作成が単なるペーパーワークとなってしまう。PMがリーダーシップを発揮して,メンバーの協力を得て作成すべきである。

 計画書作成にメンバーを参加させることで参画意識の向上が図れ,プロジェクトの進め方を理解させることもできる。計画書を流用する場合,PMがプロジェクト全体の流れをよく理解せず,意志を持っていないと,リスクまで一緒に流用してしまうので気をつけよう。

大事なのはベースラインの共有

 計画書には,プロジェクトのゴールを達成するには何をすべきかを記載する。それをメンバー全員が共有する。それは分かりやすい内容でなければならない。計画書の項目は,プロジェクトの規模や性質によって異なると思うが,筆者の会社ではのような計画書を作成している。


プロジェクト計画書
――目次――

  1. お客様の情報・・・業務内容や規模(売上高や従業員数),プロジェクトに対する期待など
  2. プロジェクト概要・・・プロジェクトでどのような作業を行うのかを明確にする
  3. システム概要・・・システム構成図で開発するシステムのスコープを明確にする(ハードウエア/ソフトウエア/ネットワーク/インフラ構成など)
  4. システム要件・・・主要機能,性能(顧客要求・定義),信頼性(決定事項,回復許容時間など)を明確にする
  5. プロジェクト体制・・・担当者や責任者,指揮命令系統,要員計画(顧客体制や協力会社を含む)などを明確にする
  6. WBS/作業量・・・プロジェクトの必要作業項目や担当者,作業量(開発規模など)を明確にする
  7. 品質/生産性・・・作業工程ごとの品質基準や管理方法,生産性基準や把握方法などを明確に定義する
  8. コスト・・・プロジェクトにどれだけのコストをかけられるのかを明確にする
  9. 日程(スケジュール)・・・作業工程やプロジェクト全体(開始から終了まで)のスケジュールを明確にする
  10. 主要マイルストーン・・・お客様の作業を含めた主要マイルストーンを設定する
  11. リスク/問題点/懸案事項・・・リスクや懸案事項,問題点を一覧にし,状況が分かるようにする
  12. 会議体(モニタリング計画)・・・会議体の目的や位置づけを含め,モニタリング計画を明確にする
  13. 中間成果物/最終成果物・・・作業工程ごとのプロジェクトで作成する成果物を定義する
  14. セキュリティ管理・・・ポリシーやルールを明確にする
図●プロジェクト計画書の例

 開始時点で内容をすべて明確に定義できない場合は,段階的に詳細化していけばよい。重要なのは,メンバーがプロジェクトの計画(ベースライン)を共有することである。プロジェクト開始時点で決まっていることは何か,決まっていないことは何かについて,共通認識を持っておく。

 また,スケジュール,進捗/品質の管理方法,リスクや問題点とその管理方法なども共有する。計画書の内容は途中で変更が生じるので,変更(更新)管理もマネジメントの重要な要素の一つである。計画書以外の必要項目は,プロジェクト開始後に「開発計画書」で段階的に詳細化し定義する仕組みを,筆者の会社では採用している。


千種 実(ちくさ みのる)
日立システムアンドサービス
プロジェクト推進部 部長
1985年,日立中部ソフトウェア(現 日立システムアンドサービス)に入社。入社以来,一貫してプロジェクト管理に従事。PMOの立場でトラブル・プロジェクト支援を数多く経験した後,社内のプロジェクト管理制度の構築やプロジェクト管理システム(PMS)開発およびプロジェクト支援,プロジェクト・マネージャ教育講師に携わる。また,他社のプロジェクト管理に関するコンサルティングや研修講師,講演などを経験し,現在もPMOの立場からITプロジェクトを成功へ導くために幅広く,社内外で活動中。1962年,三重県出身。岡山理科大学理学部応用物理学科卒。