スキルレベルの考慮
(イ) 自分だったら
常に自分だったらどれくらいの工数でできるだろうという感覚を持つといいかもしれません。「この仕様だったらこれくらいかな？」とか見積もりは必ずします。記録に残し最終的にどうであったかを検証し、自分の見積もり感覚を磨いてください。勘を養うのです。
(ロ) 人のスキルレベル（生産性）
自分だったらこれくらいというのがわかれば、今度は自分以外の人がやったらどれくらいになるかという話です。そのためには要員スキルと仕様内容を正しく理解する必要があります。そのうえで、その人だったらどれくらいになるだろうかで見積もります。見積もる上でその人にヒアリングしてもいいと思います。ただし、その内容は原則信用しないし、採用しません。あくまでも自分で見積もります。
その人に見積もり等を聞いた場合でも自分の言動に対する責任を持ってもらう範囲でその結果を利用します。
作業を細かく分解してそれぞれ単純に何をするかイメージがわくレベルにして、そのするのに必要な工数を積算していきます。
ここで重要なのは「実際に何をするかイメージできるレベルまで作業を分解する」ということです。
この方法は開発外作業(研修教育など)・構築作業などの見積もりで使います。根気のいる作業ですが地道に行っていきます。
ＷＢＳを作るという作業は例の変な表を作ることではないことを知っておいてください。「作業を分割してイメージがわくレベルにすること」です。
細かく分解すればするほど工数が大きくなる場合があります。これは作業の分割単位と見積もり単位があっていない場合におきます。
単位が「月」であった場合最少は1M(月)になってしまいます。1W(週間)でできるタスクに分解した場合に最少の１を入れてしまうと３W(週間)分１２０H(時間)のずれが生じることになります。
作業単位が「D(日)」単位で終わるようなものであればH(時間)にすべきです。一つ下の単位を設定して見積もってもらいます。
単位をM(月)のままで０．１とかやめてください。０．１M(月)は２D(日)です(１６０時間前提)当該作業が２日間＝１６時間かかるのかの考慮をするのが嫌になり、妥協することがあるからです。
見積もり精度、分解粒度に合わせて単位を適切に設定してください。
見積もり妥当性を見る場合は、単位に応じた見積もり精度を前提にレビューすることになります。(つまり細かくすればよいものではないということ、余計な突っ込みを受けます。)
部分見積もりの妥当性が無ければそれ以降も見積もり検証をする意味がないと判断され、再見積もりになりますから注意が必要です。
