プロジェクト計画書の書き方 — 検証できる12のブロック

1. 多くの「プロジェクト計画」は、ただのタスクリストである

同じプロジェクトについて「計画は何か」を6人に聞くと、6つの答えが返ってきます。ガントチャート、あの表、契約書、メールのスレッド、「Teams にあるファイル」。これこそがプロジェクト計画が解くべき問題です。日程を組むことではなく、「完了とは何か、誰が誰に負っているのか、いくらまで使ってよいのか」を、全員が同じように検証できる形で記述することです。

本稿が扱うフレームワークは、プロジェクト計画のインフォグラフィックが12のブロックに分解したものです。チェックリストとして見れば長い。構造として見れば5つの問い——何をするのか、いつまでに、誰と、いくらで、うまくいかなかったらどうするのか——であり、どの問いにも、監査員・顧客・サプライヤーに渡せる文書が対応します。

12のブロックは4つの局面に分かれます。立ち上げ（1）、定義と計画（2〜9）、実行と監視（10〜11）、クローズ（12）。

2. 立ち上げ：計画する資格を先に得る

ビジネスケース、プロジェクト憲章、ステークホルダーの識別、目標の定義、キックオフ。最も重要なのは憲章です。このプロジェクトがやらないことを書いた唯一の文書だからです。

目標は古典的な4つの制約——スコープ、時間、コスト、品質——であり、図はそれぞれに条件を付けています。スコープは明確、目標は合意、憲章は承認済み。どれか一つ欠ければ、計画は無駄になります。誰も同意していないプロジェクトに対して、精密な計画を作ることになるからです。キックオフは儀式ではなく、4つの制約を、後に責任を問われる人たちの前で口に出す瞬間です。

3. スコープ：意図を「検収できる名詞」に翻訳する

スコープ記述書、成果物、WBS（作業分解構成図）、スコープベースライン、要求の収集——5つの成果物と、一つの流れ：要求を集める → スコープを定義する → WBS を作る → スコープを検証する → 署名して承認する。

プロジェクトはたいてい WBS で失われます。「プロセスを改善する」という作業パッケージは、見積もれず、人も割り当てられず、検収もできません。図はプロジェクトを3フェーズ、各2つの作業パッケージに分け、28の成果物、45の WBS 要素という数字を示します。この2つが計画の骨格です。45要素は、見積もり・要員配置・検収ができる最小単位です。

監査に耐えるルールが一つあります。WBS の末端は検査できる名詞であり、動詞ではありません。「封じ込め在庫の選別完了」は末端です。「封じ込めをやる」は気分です。

4. スケジュール：すべてがクリティカルパスではない

アクティビティ定義、順序付け、所要時間の見積り、マイルストーン、クリティカルパス。スケジュールには2つの見え方があります。全員が見るガントチャートと、実際に完了日を決めるネットワーク図です。

例では全体36日、マイルストーン7つ、クリティカルパス18日。18日と36日の差が、この作業の意味そのものです。余裕（フロート）がないのはクリティカルパスだけであり、そこで失った1日はプロジェクトの1日です。それ以外は自分の余裕の中で動けるので、終了日は動きません。何かが起きた朝に、プロジェクト責任者が最も知りたいのはこの点です。

マイルストーンには独自の規律が必要です。検証できる状態を名指しすること。着手、設計完了、製作完了、試験完了、リリース。5つの状態、それぞれに署名。「フェーズ1は終わった」はマイルストーンではなく、意見です。

5. 資源：すべてが衝突する週

人、設備、材料、割り当て、チームの役割。そして計画と願望を分ける成果物、資源負荷のヒストグラム。

例は15名、総需要960時間、稼働率82%、6週間に分散。この図は横ではなく縦に読みます。問いは「どの週に、人より需要が多いか」です。平均82%の計画でも、ある週が140%になることはあります。そしてその週が実際の完了日を決めます。平均85%以下なら計画、95%を超えるなら物語です。

6. コスト：3つの数字と1つの結論

予算の見積り、コストベースライン、コスト予測、アーンドバリュー。図は S カーブ（計画価値・出来高・実コスト）と6つの数字を示します。BAC 85万ドル、PV 54万ドル、AC 48.6万ドル、CPI 1.12、SPI 1.05、EAC 91万ドル。

アーンドバリューを使えるものにする3つの定義：

• PV — 計画上、いま時点で「終わっているべき量」を予算単価で評価したもの。
• EV — いま時点で「実際に終わった量」を同じ予算単価で評価したもの。
• AC — いま時点で「実際に使った額」。

CPI が1を超えるのは、1ドルで計画より多くを買えている状態。SPI が1を超えるのは、日程が先行している状態。どちらも過去についての比率です。意思決定に使うのは EAC、つまり「この調子なら最終的にいくらになるか」です。9か月効率的に進んだプロジェクトが、最後に予算超過で終わることはあります。

図が結果的に示してしまっている注意点があります。CPI 1.12 と EAC 91万ドルは同じアーンドバリューのデータからは出てきません（BAC 85万ドルで CPI 1.12 なら EAC は約75.9万ドル）。実際のダッシュボードではこの組み合わせが日常的に現れ、意味はいつも同じです。セルごとに EV の取り方が違う。信号を見る前に、6つの数字が同一時点の EV スナップショットから出ているかを確認してください。

7. リスク：「もしも」を金額に換算する

識別、分析、緩和計画、予備費。加えて、リスクを監査可能にする2つの成果物、発生確率×影響のヒートマップと全体のリスクエクスポージャー。

例は高5件、中7件、低6件、全体のエクスポージャーは予算の12%。有用なのは2つ目の数字です。「リスク登録簿があります」は統制ではありません。「識別したリスクに対して予算の12%を確保し、この3名が責任を持つ」が統制です。リスクに紐づかない予備費は予備費ではなく、静かに使われる未配賦の予算行です。

8. 品質：「良い」を判定条件として書く

品質基準、手順、KPI、継続的改善。中央に PDCA。例は**不良率0.6%、品質スコア98%、プロセス遵守率98%**を約束します。

3つのうち2つは先行指標、1つは結果です。品質計画には両方が必要です。この節の実質的な中身は3つのリストです。どの規格が適用されるか、誰がどのゲートで何を測るか、不適合な成果物をどう扱うか。2つ目のリストがなければ、「品質計画」は意図を述べた一段落になります。

9. コミュニケーション：雰囲気ではなく事象

情報要求、チャネル、コミュニケーションマトリクス、ステークホルダーマトリクス。チャネルはメール、レポート、ダッシュボード。頻度は週次、隔週、日次、リアルタイム。

コミュニケーション計画の最小単位は1行です。事象＋対象＋チャネル＋頻度＋責任者。「ステークホルダーに情報を届けておく」は計画ではありません。「プロジェクトチーム、週次、ダッシュボード、月曜9時、PM」が計画です。マトリクスは送らないものを決めるためでもあります。会議の負荷の多くは、書かれなかったコミュニケーション計画です。

10. 調達：契約類型とはリスク配分である

ベンダー選定、契約書作成、調達スケジュール、調達リスク。流れはソーシング → 評価・選定 → 交渉・契約 → 承認 → クローズとレビュー。4つの契約類型があり、違いは主に「変更リスクを誰が負うか」です。

例は稼働中の契約4件、関与ベンダー12社、コスト削減目標10%。削減目標が「計画の数字」になるのは、その達成が可能になる契約類型を選んだときだけです。

11. ステークホルダー：関心×影響力

ステークホルダー分析、権力—関心グリッド、関与戦略、影響力マッピング。25名を関心と影響力で4つに分けます。密接に管理（高/高）、満足を保つ（高影響力・低関心）、情報を届け続ける（高関心・低影響力）、監視（低/低）。

図の関与のはしご——情報提供、意見聴取、参画、協働、支持——はグリッド単体より有用です。関係の語調ではなく、関与の深さを定義しているからです。規制当局は「満足を保つ」、ライン作業者は「情報を届け続ける」に置けば双方が得るものを得ます。入れ替えれば双方が不満になります。

12. 監視とコントロール：一つのデータ、三つの判定

実績の追跡、変更管理、是正処置、予測。指標は CPI、SPI、品質指数で、例では1.05、1.12、0.98。併せて課題の状態（未対応、対応中、解決、クローズ）、変更要求6件、未クローズ課題5件、計画どおり92%。

この節が成立するのは、すべての数字が同じ日の同じスナップショットから出ている場合だけです。もう半分は変更管理です。変更要求のない変更は変更ではなくドリフトです。品質エンジニアが現場でよく知る、あの失敗モードと同じです。実際のやり方が静かに SOP から外れ、誰も記録しない。この規模なら変更要求6件は健全な数字です。ゼロは警告であって、褒め言葉ではありません。

13. クローズ：「完了」とは署名である

最終成果物、教訓、検収署名、引き渡し、クローズチェックリスト。例の結果は納期遵守100%、予算内98%、ユーザー満足95%。

クローズチェックリストは短く、容赦ありません。成果物の検収、文書の完成、顧客の署名、契約のクローズ、チームの解放、教訓の記録。最後の項目が次のプロジェクトの原資になります。誰も見つけられない教訓ファイルは、教訓ファイルがないのと同じです。

14. 12のブロックを1ページに

15. 8D と APQP との関係

12のブロックは品質業務に押しつけるプロジェクトマネジメントの儀式ではありません。APQP がもともと要求している構造そのものです。フェーズゲートは立ち上げとスコープベースライン、管理計画は品質計画、PPAP は署名付きのクローズチェックリストです。品質エンジニアに足りないものは「計画」より具体的です。誰も検査できない WBS の末端、リスクに紐づかない予備費、一度も起票されなかった変更。この3つは、8D の「何も変わっていません」と同じ失敗をプロジェクトで起こします。

関係は一文で言えます。プロジェクト計画は、まだ起きていない失敗を契約条項に変える。8D は、起きた失敗を原因に変える。 どちらも第三の選択——量産ラインで知ること——より安くつきます。

本稿のフレームワークは Template22 の「How to Write a Project Plan」12ブロックのインフォグラフィックに基づきます。図中の数値は同図の説明用の例であり、実在のプロジェクトではありません。読み方に関する注意と品質業務への展開は当サイトによるものです。