プロジェクト計画書はなぜ作るのか

はじめに

本記事ではプロジェクト計画書の有用性について私見を述べます。筆者の立場は情報システムの開発・導入プロジェクトにおける発注者側（ユーザー企業）のプロジェクトマネージャーです。

プロジェクトを成功に導くための最初の重要な活動は、発注者が魂を込めてプロジェクト計画書を作成することだと信じています。

計画書、作ってますか？読んでますか？更新してますか？

プロジェクト計画書。略してプロ計。システム開発の PM 経験者であればなじみ深いドキュメントのひとつでしょう。プロジェクトの準備期間中に作成し、キックオフでお披露目されるものです。

典型的な計画書の見出しはこんな感じかと思います。

1. プロジェクト概要・ゴール
2. 前提条件および制約条件
3. プロジェクト体制
4. プロジェクト成果物
5. プロジェクト業務範囲(WBS)
6. プロジェクトスケジュール
　6.1. マイルストーンチャート
　6.2. マスタースケジュール
7. コミュニケーションプラン
8. 文書管理規定
9. 各種承認フロー、変更管理
　9.1. 各種承認方法
　9.2. 変更管理方法
10. リスク管理対応計画
11. システム構成概要
12. 各種様式

筆者はこれまで数多くのプロジェクト計画書を目にしてきましたが「使えるレベルの計画書」は、数えるほどしかありません。

キックオフのときに客と合意したらその後、放置されることも珍しくありません。ひどいプロジェクトだとガントチャートだけが提示されるプロジェクトもありましたし、発注者側の PM が「決まりだから」という理由だけで、ほぼテンプレの計画書のみベンダーに作らせる、なんてこともありました。 

「成果物で定められているから」という理由で計画書を作成する PM は今すぐプロジェクトから去ってください。同じく「なんか偉い人が作るちっとも役に立たない文書」と考えているメンバーは、これまで辛いプロジェクトばかり経験してきたか、同じようなプロジェクトばかりルーチンワークのようにこなしてきたのでしょう。同情します。

計画書は成果物だから書くんじゃない、必要だから書くんだ

経験豊富な読者はおわかりのとおり、計画書こそがプロジェクトを成功に導くもっとも重要なコミュニケーションツールです。

Googleをはじめとするテック企業で、ソフトウェア開発時に必ず書くとされる「Design Doc」もプロジェクト計画書の一種です（プロジェクト計画とアーキテクチャ方針を明文化したもの）。Design Doc については以下のサイトの説明がわかりやすいでしょう。

https://www.flywheel.jp/blog/design-doc-of-design-doc/

なぜプロジェクトが立ち上がったのか、その価値はなにか、守りべき規約はなにか、やってはいけないことはなにか、手を取り合う仲間たちと戦うべき敵は何者なのか、そのすべてが記述されているのです。

多様なバックグラウンドをもつ荒くれ物のエンジニアたちがそれぞれスタンドプレーした結果生じるチームワークを実現するためには、同じ目標、同じマインド、同じ信念をもたねばなりません。時にはぶつかりあうことも必要ですが、無駄な衝突はないにこしたことはありません。

プロジェクト計画書とは、プロジェクトに参画するすべてのメンバーが最初に読み、理解すべきドキュメントです。プロジェクト計画書なくして健全なプロジェクト運営はあり得ません。

計画書は受注側が書くもの？違います。

プロジェクト計画書こそ発注者が書くべきものです。なぜならばプロジェクトの意義や価値観を盛り込むもの、魂を込める文書だからです。

一方、受注者側でも作成したほうがよい場合が多いです。これは受注者にとってのプロジェクトスコープが発注者と異なるためです。極端にいうと発注者と受注者がそれぞれ自分のプロジェクトをもっており、すべてのプロジェクトの集合体が真のプロジェクト（PMBOKでいうところのプログラム）といえます。

まとめ

・プロジェクト計画書は、ステークホルダー全員がプロジェクトの骨子を共有するためのツール。

・計画書がないとステークホルダー間で認識の齟齬が生じる。また、プロジェクトを推進するうえで守るべき事項が守り切れない。

・計画はどんどん変化する。変化に応じて計画書も随時更新すべき。そうでないと途中参加のメンバーが取り残される。最初からいたメンバーもどうせ忘れる。