プロジェクト計画書

プロジェクト計画書の役割を「何のために作るのか」という軸で見ると、主に合意形成と判断基準の二つに整理できます。発注側・開発側・運用側といった立場の異なる関係者が、同じ前提に立って進むための共通認識をつくるのが第一の目的です。

合意の土台をつくる
スコープ・納期・体制・予算を文書として明文化し、キックオフの場で読み合わせます。口頭だけの了解はあとで食い違いやすいため、計画書に落として初めて「ここまでをこの期間でやる」という線引きが共有されます。

進行中の判断基準になる
プロジェクトが動き出すと、仕様追加の相談や遅延の兆候が出てきます。そのとき計画書に書かれた前提やスコープが、受けるか断るか、変更管理にかけるかを判断する拠りどころになります。計画書は作って終わりではなく、折に触れて参照される運用文書です。

PMBOKの文脈では、各領域の計画をまとめた上位文書として扱われることが多く、個別のスケジュール表やリスク一覧を束ねる親文書のような位置づけになります。

何を書くかは「対象・制約・進め方・備え」という軸で押さえると漏れにくくなります。PMは関係者へのヒアリングと上流の成果物をもとに、次のような項目を埋めていきます。

• 目的とスコープ
  プロジェクトが達成したいことと、やること・やらないことの境界を書きます。スコープ外の明記が、のちの認識ずれを減らします。
• 体制と役割
  発注側の責任者、PM、各担当チームの関係を示します。誰が何を決めるかを責任分担として整理しておくと、判断の停滞を防ぎやすくなります。
• スケジュールとマイルストーン
  要件定義・設計・開発・テスト・移行といった工程と、節目の期日を置きます。工程表やガントチャートと紐づけて管理します。
• 予算・工数とリスク対応
  見積もった工数とコスト、想定されるリスクとその対応方針を書きます。起きうる問題をあらかじめ挙げておくことで、発生時の初動が早まります。

作成の順序としては、プロジェクト憲章や要件の情報を起点に、PMが骨子を書き、関係者のレビューを経て合意版へ仕上げる流れが一般的です。最初から完璧を狙うより、たたき台を早く回して精度を上げるほうが現実的です。

計画書は作り方そのものより、作ったあとの扱いで差が出やすい文書です。よく見られるつまずきを、原因の軸で挙げます。

作ったまま更新されない
初版を作って承認を得たあと、現場の実態と計画書がずれていく例があります。スコープや日程が変わったのに文書が古いままだと、参照する価値が下がり、判断基準として機能しなくなります。変更管理の運用とセットにしておくと、ずれを拾いやすくなります。

スコープの境界があいまい
「やること」は書かれていても「やらないこと」が書かれていないと、追加依頼を断る根拠が持てません。境界を言葉で明記しておくと、相談が来たときに変更管理へ乗せる判断がしやすくなります。

関係者が読んでいない
分量が多く、体裁を整えることに力が入りすぎると、肝心の読み手に中身が届かないことがあります。キックオフで要点を読み合わせる、節目ごとに差分を共有するなど、文書を会話の起点として使う工夫が要ります。

計画書と混同されやすい文書を「扱う対象」と「作られるタイミング」の軸で並べると、役割の違いがはっきりします。

プロジェクト憲章との違い
プロジェクト憲章は、プロジェクトの発足を正式に認め、目的やPMの権限を示す立ち上げ段階の文書です。これに対し計画書は、憲章で定まった枠のなかで「どう進めるか」を具体化します。憲章が入口の承認なら、計画書は進め方の設計図にあたります。

要件定義書との違い
要件定義書は、作るシステムや成果物が満たすべき機能・非機能を記す文書です。対象は成果物そのものです。計画書が扱うのは、その成果物を作り上げるための進め方・体制・日程であり、対象が異なります。

スケジュール表やWBSとの関係
工程表やマイルストーン、作業分解は計画書の一部を詳細化したものと捉えられます。計画書は全体の方針を束ね、これらの個別文書を参照しながら運用される、上位の位置づけになります。

プロジェクト計画書を書けることは、PMとしての土台になる力の一つと考えられます。立場の違う関係者を同じ前提に乗せ、進め方の合意をつくる作業そのものが、PMの中核的な仕事だからです。計画書を単なる提出物ではなく、合意形成と判断の道具として使えているかは、面談や職務経歴の説明でも伝わりやすいポイントになります。

経験を語るときは、どんな体裁の文書を作ったかより、スコープの境界をどう引き、変更や遅延にどう対応したかという運用の中身を具体的に示すと、進め方を設計できる人だと伝わりやすくなります。計画書を起点に、工程管理・変更管理・リスク管理へ経験を広げていく流れも描きやすい領域です。

プロジェクト計画書は誰が作りますか。

作成と維持の責任は、プロジェクトマネージャー（PM）が担うことが多いです。ただしPMが一人で書き切るというより、発注側の責任者や各担当チームへのヒアリングとレビューを重ね、合意版に仕上げていく進め方が一般的です。関係者を巻き込むほど、実態に合った計画になりやすくなります。

プロジェクト憲章と計画書はどう違いますか。

プロジェクト憲章は立ち上げを正式に認め、目的やPMの権限を示す入口の文書です。計画書は、その枠のなかでスコープ・体制・スケジュール・リスク対応など「どう進めるか」を具体化します。憲章が発足の承認なら、計画書は進め方の設計図という関係になります。

計画書は一度作ったら変えないものですか。

いいえ、進行中に参照し、必要に応じて更新していく運用文書と考えられます。スコープや日程が変わったのに古いままだと、判断基準として機能しにくくなります。変更管理の仕組みと紐づけ、節目ごとに差分を関係者と共有しておくと、実態とのずれを抑えやすくなります。