コンテンツ
はじめに：なぜ精緻な計画書ほど機能しないのか
プロジェクトの立ち上げ時、PMはたいてい計画書に多大な労力をかける。ガントチャートは細かく引かれ、WBSは何十行にも展開され、リスク欄には「〇〇に気をつける」という注意書きが並ぶ。
それでもプロジェクトは遅延し、メンバーは迷い、クライアントは承認を保留する。私がPMOとして数多くのプロジェクトに関わってきた中で、一つの確信に至った。
計画書が機能しない理由は、中身の精度ではなく、設計思想にある。
多くの計画書は「それを作ったPMのロジックで組まれた、PM向けの資料」だ。しかし計画書には、PMとは異なる2種類の利用者がいる。メンバー（計画を実行する人）とクライアント（マイルストーンを承認する人）だ。
メンバーはPMよりスキルが低いことが多い。クライアントはプロジェクトの内部事情を知らない。「自分が分かる単位」で作られた計画書は、この2者に届かない。計画書は「タスクリスト」ではなく、利用者向けに設計された「製品」であるべきだ。
ある現場の話
以前、大手金融機関のDXプロジェクトにPMOとして参画した際の話をする。そのプロジェクトは複数チームで構成されており、私は担当チームの立ち上げリードを任されていた。プロジェクト開始から数週間で、現場の状態が見えてきた。
- PMはメンバーのフォローとクライアント対応の両方を一人で抱え、明らかに疲弊していた
- チームメンバーのスキルはタスクの難易度に対して不足していた
- 細かく指示しないと動けない状態で、メンバー自身も「次に何をすべきか」が分からなかった
- クライアントとのコミュニケーションも全てPMに集中していた
計画書はあった。ガントチャートも、WBSも。でも誰も計画書を「使って」いなかった。PMに前フェーズで何がうまくいかなかったかを聞いた。返ってきたのはこんな言葉だった。
「メンバーを取りまとめる役がいなかった。統制が全然効かなくて、後手後手になってしまった。」
この一言が、計画書を作り直す起点になった。
CPPとは何か
ここで私が実践するアプローチを定義しておきたい。私はこれを Calibrated Project Planning（CPP） と呼んでいる。
「計画書を、利用者（メンバーとクライアント）の認知容量と意思決定リズムに合わせて校正（カリブレート）し、製品として仕上げる技術」
通常のPMは「タスクを正しく分解する」までで止まる。CPPはそこから一歩踏み込む。「分解の基準を、実行する人間と承認する人間の能力・リズム・過去の失敗パターンに合わせて調整する」。精緻さではなく、届く設計を目指す。それがCPPの出発点だ。
4つのインプットで計画書を「校正」する
CPPでは、4つの情報を起点に計画書をカリブレートする。
1. メンバースキルの校正 タスク粒度は、最も弱いメンバーが自力で実行できるレベルまで落とす。先の現場では、WBSの各タスクを「判断なしに着手できる粒度」まで分解し直した。
3. 失敗原因の構造変換（最重要） 先の現場で聞いた「統制が効かなかった」という失敗に対して、2段の構造変換を行った。
間接対策: 前倒しできるタスクを全て前倒し（統制機構が動くための余白を設計）
「気をつける」は人に依存する。「構造で防ぐ」はシステムに依存する。どちらが再現性が高いかは明白だ。
4. クライアント意思決定リズムの読み方 クライアントの発言を2軸で観察する。シグナルとノイズを判別できるかどうかで、計画書の承認率は大きく変わる。
| 判定 | シグナル（計画を修正） | ノイズ（計画は変えない） |
|---|---|---|
| 指摘の種類 | 全体の意図・設計への指摘 | 担当者個人の好みや意見 |
| 意見の代表性 | 組織としての総意 | 担当者だけの発言 |
| 典型的なノイズ | — | 全体論なのに個別タスクへの限定発言、上位項目を見ずに細部から入る発言 |
5つの軸で最終確認する
4つのインプットで情報が揃ったら、計画書を5軸でチェックする。
| 軸 | 問い | 優先度 |
|---|---|---|
| 粒度 | 最も弱いメンバーが、指示なしに着手できるか | 状況次第 |
| 順序 | 政治・リスク・資源制約・失敗対策が反映されているか | 状況次第 |
| 物語 | クライアントが読んで、次の行動が分かるか | 状況次第 |
| 当事者性 | 担当者名がタスクに紐づいているか | 状況次第 |
| クライアント対話 | マイルストーンが先方の意思決定タイミングと同期しているか | 死守 |
この5軸のうち、絶対に死守するのは「クライアント対話」だ。ここがずれると、どれだけ内容が正確でも承認されずプロジェクトが頓挫する。他の軸は状況によって優先度を下げることがあるが、この軸だけは譲れない。
計画書は「作って終わり」ではない
計画書はキックオフ時に完成し、あとは進捗を追うだけ——という思い込みがある。しかし現実のプロジェクトは動く。スコープが変わり、メンバーが変わり、クライアントの優先度が変わる。CPPでは、計画書を2層のループでメンテナンスし続ける。
先の現場では、このループを回し始めてから「対応が後手に回る」状況が明らかに減った。何かが起きてから計画書を修正するのではなく、起きる前にシグナルを計画に吸収する仕組みができたからだ。
この能力が長らく「暗黙知」だった理由
実は、CPPとして言語化したこのアプローチは、私にとって長い間「自然にやっていること」だった。誰かに教わったわけでも、方法論として学んだわけでもない。プロジェクトを重ねる中で、気づいたらやっていた。だから言語化されていなかった。これが3つの問題を生んでいた。
この状況を変えるために、私たちはいまCPPを体系化し、チームで再現できる形に変える取り組みを進めている。
おわりに
計画書の品質を決めるのは、情報量や精緻さではない。「誰のために作るか」という設計思想だ。
- メンバーが自力で動ける粒度になっているか
- クライアントが承認できる物語になっているか
- 失敗は「気をつける」ではなく「構造で防ぐ」設計になっているか
この問いに答えられた時、計画書はタスクリストではなく「利用者向けの製品」になる。私たちmetamorphoseは、大手企業の少人数プロジェクト、または大規模プロジェクトの重要領域に特化して、CPPを実践しています。100名を統括する大規模PMOとは意図的に違う土俵で、「計画書を製品化する」PMOを目指しています。
計画書が機能していないと感じたら、一度話しましょう。
metamorphoseは金融・製薬・大手SIer向けにPMOコンサルティングを提供しています。まずは30分のヒアリングから始められます。
お問い合わせ →