立ち上げ期にかなりの時間をかけ、工程を細かく割り、担当と期日をびっしり埋めたWBS。見た目にはとても安心感があった——のに、前提が動いた途端、あれほど時間をかけた計画は作り直しの山になり、更新だけで手いっぱいに。この記事では、私のこの失敗から始めて、計画パフォーマンスドメインが扱う範囲と、「詳細な計画=良い計画」ではない理由を一緒に考えていきます。
この記事でわかること
- 「詳細に作り込むほど良い計画」が、なぜ思い込みなのか(筆者の失敗談)
- 計画パフォーマンスドメインが扱う範囲を、試験の定義と現場の感覚の両方から
- 学び始めの人が計画で誤解しやすいところと、今日からの向き合い方
筆者はSIerのPMです。計画を「作り込んでは崩れる」経験を重ねてきた立場から、PMPの学び直しで得た視点を書いています。
先に定義だけ。計画パフォーマンスドメインとは、プロジェクトをどう進めるかを組み立て、状況に合わせて練り直していく一連の活動です。スコープ・スケジュール・コスト・体制・コミュニケーション・調達など「動き出すために決めておくこと」全般を扱います。ポイントは、計画は一度作って終わりではなく続く営みであること、そして最初から全部を細かく決めず、分かっている範囲から詳しくしてよい(段階的詳細化)ことの2つです。
「詳細に固めた計画」が崩れた
私が痛い目を見た話を、ひとつ。まだリーダーになって日の浅い頃です。
ある基幹システムの刷新案件で、私は立ち上げ期にかなりの時間をかけて、WBSを細部まで作り込みました。工程を細かく割り、担当と期日をびっしり埋めた計画表は、見た目にはとても安心感がありました。当時の私は「ここまで詳細なら、あとはこの通りに進めるだけだ」と思っていたのです。
ところが数か月後、業務側の要件がいくつか変わり、前提が動きました。すると、あれほど時間をかけた詳細な計画は、あちこち作り直しになります。細かく決めていたぶん、直す箇所も膨大で、更新だけで手いっぱい。計画が現実に追いつかず、かえって足を引っ張り始めたのです。
そこで私は途中から進め方を変えました。全体はマイルストーン(節目)で大きく押さえ、直近の数週間だけを詳細に計画し、先は状況を見ながら詳しくしていく。いわゆる段階的な計画に切り替えたのです。すると、変化が起きても直すのは直近の一部だけで済み、判断のスピードが上がりました。手戻りは減り、チームも「どこまで決まっていて、どこはこれからか」を共有しやすくなりました。この経験から、計画の価値は詳細さではなく、変化に合わせて更新し続けられることにあるのだと考えるようになりました。
「計画通り=良いPM」だと思い込んでいた
正直に言うと、私はしばらく「計画通りに進めること」がPMのゴールだと思い込んでいました。でも学ぶほど、それは逆だと気づきます。
計画は、現実がわかってきたら変えるためにあるもの。変更は失敗ではなく、計画が機能している証拠です。そして「詳細であること」と「精度が高いこと」は別物でした。分からないことまで細かく決めても、それは精度ではなく「仮の細かさ」にすぎず、変化が来れば崩れます。試験勉強をしている方は、「計画は最初にすべて確定させる」という選択肢を外すところから始めると迷いません。
計画は、他のドメインをつなぐ結節点
計画を捉え直すと、プロジェクト全体の見通しが一気に良くなります。開発アプローチ(予測型か適応型か)によって計画の粒度は変わりますし、立てた計画は日々のプロジェクト作業として実行され、デリバリーへとつながっていく。「関係者が迷わず動けるだけの見取り図を、その都度ちょうどよく整えること」——学び始めのうちは、計画をそう捉えておけば十分です。
今は必ずやっていること
続けている習慣を、3つだけ。合いそうなものがあれば取り入れてみてください。
- 計画を作るとき「これは今、この粒度で決める必要があるか?」を一度立ち止まって考える
- 全体はマイルストーンで、直近だけ詳細に、と粒度を意図的に分ける
- 前提が変わったら、計画を「直す手間」ではなく「更新のサイン」として受け止める
ここでよく迷うところ
Q. 計画は最初にどこまで作り込むべき?
「関係者が次の一歩を迷わず踏み出せる」ところまで、が目安です。先の見えない部分まで無理に細かくするより、節目を押さえて直近を詳しくするほうが、結果的に破綻しにくくなります。
Q. 途中で計画を変えるのは、管理がずさんということ?
いいえ。前提が変わったのに計画を変えないほうが問題です。変更の理由と影響を関係者に説明できていれば、それは健全な計画運営です。
ここまでの整理
計画パフォーマンスドメインとは、進め方を組み立て、状況に合わせて練り直し続ける活動でした。そして計画の価値は詳細さではなく、変化に合わせて更新できることにありました。
あなたの現場でも、「作り込んだ計画が、変化についていけなかった」経験はないでしょうか。もしあれば、それはこのドメインが問われた場面だったのだと思います。関連記事もあわせてどうぞ。
関連記事
- 開発アプローチとライフサイクルとは?予測型と適応型の使い分け ― 計画の粒度を左右する前提
- プロジェクト作業パフォーマンスドメインとは?日々の運営を仕組み化する ― 立てた計画を「回す」側の話
- テーラリングとは?標準プロセスをそのまま使わない考え方 ― 計画の作り込み度合いを調整する原則
コメント