あるプロジェクトがあって、その作業量を見積もるとしよう。その時に普通に行われることは、そのプロジェクトが、どのような作業から構成されているのか分割していく。分割されたものをさらに細かく分割することもある。そして分割されたそれぞれの項目の作業量を見積もって合計する。
これをプロジェクト管理なんかの本ではWBS(Work Breakdown Structure)という。和歌山放送のことでもあるらしい。このような単純なことに立派な名称がつけられていることにも驚くが、それは主題ではない。
個々の作業の見積もりには、(見積もりなので)誤差がある。当然合計したものにも誤差が含まれる。
誤差がちょうど打ち消し合って、ぴったりの見積もりができることもあるだろう。逆に個々の見積もりが大きめあるいは小さめにずれていたら、それらを合計すると誤差が重なり合ってとんでもない見積もりができる。
一般的に言って、作業を細かく分割しすぎると、大きめにずれるようである。
ここで言いたいのは、小さい単位で見積もると、誤差の絶対値は小さくなるだろうが、誤差の割合すなわち誤差÷作業量は、ほぼ確実に大きくなる。そしてそれを合計するので、全体としても誤差の割合が大きくなる可能性が高いということを注意したい。ここに分割して見積もることの落とし穴がある。
私はかなりの数のソフトウェア開発のプロジェクトの見積もりをしてきた。多くは小規模プロジェクト。昔は小さめにずれることが多かったが、近年はほぼ合っている。
私はまず、全体を勘で一発で見積もり、それをメモしておいて忘れる。勘といっても馬鹿にしてはいけない。それなりに正しいものがでる。
次に上記のように作業項目に分解して、個々の項目の作業量を見積もり、合計する。そして先の勘による見積もりと比較する。両者が合わなければ、項目ごとに検討していって調整する。これで少し精度が上がる。