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

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

計画立案段階に潜む問題

　昔から段取り八分といわれるように、計画立案の重要性は誰もが知っています。しかし、現実の開発現場では計画立案は最も困難な作業なのです。計画を立てるプロセスを大まかに考えると、

• プロジェクトの目標を確認する
• 作業単位（タスク）に分解する
• 分解された作業の前後関係を整理する
• 作業を実施するエンジニアなどの資源を確認しアサインする
• 作業時間を見積もる
• 日程を計画する

といった流れが一般的です。この流れをいかに効率的に進めるかによって、開発効率は大きく左右されます。そして、開発現場には「効率的」に進めるために常識的に行われている行動があります。実はこの「常識」が多くの問題を引き起こす元凶になっているのです。

効率的に開発するためはタスクを細かく分けなければならない？

　開発効率を上げるためには、できるだけタスクを分解して細かく計画した方が良いという考え方があります。不確実な開発工程も、やるべきことを細かく想定して分析すれば確実性が増すと考えるのです。

　私たちコンサルタントが開発現場にお邪魔すると、プロジェクトを数百から数千ものタスクに分解しているといった事例に出くわすことも決して珍しくありません。しかしいくら細かくしても、それは事前に分かっている作業だけが細かくできるので、分からない部分を細かくすることには限界があります。

　技術的に難易度の高いことは、やってみないと分からない。これは誰でも理解できます。もし、そうであるならば事前に作業を細かく洗い出そうとしても、決して100％正確にはできないのです。しかし熾烈（しれつ）な競争の中で、技術的な挑戦を避けて通れないのも現実です。こう考えると、開発業務は始める時点では分からないことがたくさんあって当たり前ということになります。

精度の高い計画には、正確な作業時間の見積もりが必要？

　しかし現実的には「分からないことは分からない」と開き直るわけにはいきません。なぜなら計画がなければ、管理も統制もできないからです。そこで作業を細分化して洗い出た後は、個々の作業の時間見積もりを行います。

　作業時間の見積もりは過去の経験やデータから行うのが一般的なやり方です。量産型の製造工程のように何度も繰り返し作業を行う場合、過去のデータから平均値を算出して、それを見積もり時間としても大きな問題は生じません。ただし熟練した作業でも、すべてが同じ時間でできるわけではありません。仮に平均値が60分だとすると、全体の80％は平均値の±10分のばらつきの範囲内にあるといったバラツキが生じているのが普通です。

　製造現場とは異なる開発工程では、過去とまったく同じ作業はほとんどありません。このような環境では、過去の類似した作業の経験から時間を見積もることになります。こういった方法では、やってみなければ分からないことは分かりませんから、当然結果は大きくバラツキます。

　バラツキだけでなく、プロジェクト型のタスクは、早まる可能性よりも遅れる可能性の方がはるかに大きくなります。例えばある作業の見積もり値が、50％の確率で10日の場合、早く完了したとしてもせいぜい8日程度（2日短縮）にしかなりません。しかし、ひとたびトラブルなどで遅れが発生すれば際限なく遅延します。

　例えばA地点からB地点まで車で行くことを考えてみればよく分かります。たまたま深夜などで渋滞がなく、信号のタイミングも非常によい場合が最短時間ですが、ひとたび事故でも起こればどれだけの時間がかかるかまったく分かりません。

　このような状況で80％の確率で守れる納期を考えると、平均値の倍以上の30日と見積もらなければならないことが図1から見て取れます。このように遅れる側が大きな分布を示す確率分布をβ分布と呼び、開発型プロジェクト業務の時間見積もりはこの分布に従うといわれています。

図1　典型的なタスク期間見積もりのβ分布図

　不確実性の高い作業を詳細に分解しても、不確実性をすべて抑え込めません。むしろ細かくすればするほど「創作」や「作文」が多くなり、精度は悪化します。要するに作業をどれだけ分解しても、開発工程の時間見積もりは正確にはできないということなのです。