なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは：TOC流の開発型プロジェクト管理術「CCPM」（1）（3/3 ページ）

[村上悟, 西原隆／ゴール・システム・コンサルティング，＠IT MONOist]

個々のタスクに潜むサバを除けば期間は短縮できる？

　次に開発担当者は開発プロジェクトの中で、どのように作業期間を申告するか考えてみましょう。先ほどの例と同じで、50％確率の見積もり値が10日で、80％確率では30日かかるとします。このようなケース場合、申告を10日としても20日としても、30日としても、どれも間違いとはいえません。なぜならば、これらの見積もりは不確実性を前提として「ある確率条件の下であれば何日である」といっているのにすぎないからです。

　しかし一方で、計画が承認されれば守らなければならない。これは社会人としての常識です。ですから、ある作業を10日で申告して、もし達成できなければ上司に怒られる。これも当たり前の話です。こんな場合、皆さんならどの確率条件で自己申告するでしょうか。

　50％確率である10日ですか？ これでは五分五分の確率ですから、2回に1回は怒られて評価を下げることになります。それではたまりませんから、できれば絶対に遅れない見積もりをしたいと思うのが人の常です。しかし九分九厘となると極めて大きな値になるので、上司には受け入れられないかもしれません。ということで、80％程度つまり30日程度の日数で、上司とサバ読みの攻防をするのが一般的です。

　さらに悪いことに1人1人のサバ読みだけでなく、組織的なサバ読みも発生します。なぜならチームリーダーも任されている管理職ならば、チームが遅れても上司に怒られます。責任感の強いチームリーダーは、現場から上がってきた計画値に対して、さらに余裕を付加し必ず守れる計画を作ろうとするのです。このように現場で1人1人がサバを読み、さらにチームリーダーがサバを読むことで、計画はどんどん長くなっていきます（図2）。

図2　タスク期間見積もりにおけるサバ読みとサバ取りの攻防

　こうして積み上げた開発期間では到底納期に間に合いません。これだけ皆がサバを読めば当然ですね。こうなると次は、マネジメントによるサバ取りが始まります。1つ1つの作業を精査して、もっと短くできないのか交渉したり、それでもダメなら一律カットといった荒療治で「納期どおりの計画」を完成させます。しかし、あくまで立案されるのは「絵に描いた計画」であって、そのとおり進むという保証は何らありません。

　本来プロジェクトは多くの人のかかわりによって行われる業務であり、多くの人を束ねるためには納得ずくの計画が重要なはずです。しかし多くの開発プロジェクトでは、まるでキツネとタヌキの化かし合いのような奇妙な計画立案プロセスがまかり通っているのです。

　こうして考えると開発計画を立てるとは一体何なのでしょうか、あらためて考えてみると非常に不思議です。誰も未来のことなど分からないにもかかわらず、計画は立てなくてはならないのです。実はこれまで皆さんが正しいと考えてきた開発計画の立案方法には、根本的な矛盾があるのです。

◇

　次回は、この矛盾の種明かしをする前に、PDCAサイクルの残りである実行（D）・確認（C）・対策（A）それぞれの段階でどんな問題が生じているか見ていきたいと思います。