「見積もりの精度は想像力に比例する」

新人プログラマの試練のひとつに、『正確な工数見積もりの算出』がある。

同じ製品を複数人で作るとき、みんなの進捗を管理する先輩(上司)に「自分はこの作業に何日かかります」という見積もりを出す必要があるのだ。

今ちょうど、はじめて工数見積もりを出すタイミングで、先輩に見せたら「これではコメントできないよ」と突き返されてしまった。総合して「想像力が足りてない」とのことなのだけど、ダメだった点を列挙してみる。

作業の工程が少ない

先輩
要望ヒアリングするにも時間かかるよね?

調査時間ないけど大丈夫なの?

コードレビュー1回で済むかな?

わたし
……あぁ…たしかに……

 

コーディングの時間しか考えていなかった

コーディングする前の、要件定義、調査、設計、コーディングした後にコードをチェックしてもらう(コードレビュー)ための調整と実施、そこからの修正、再度レビュー、、などやることがいっぱいあった

 

一つの作業内容が粗い

先輩
それで本当にできると思う?

ここのページ遷移はどう実装するかによって、かかる時間変わるよね?

わたし
……はぃ…たしかに……

 

実際どんなコードを書いて実装するつもりなのか」まで考えて書き直した。

 

根拠がない

先輩
この時間を出した根拠は?
わたし
……えっと感覚です…!……

 

一応、同じような機能を実装するのに以前かかった時間から考えてはいたので、発想はいいけれど、それを言語化するまで詰める必要があった。

「もう少し早くできそう」なときは、大抵「1回やって、正解が分かっているから」が根拠になる。「もうちょっとかかりそう」なときは、大抵「やったことないからわからない」(新人なので)。

そういうときは、「わからないので調査時間をください、調べてわからない時は質問させてください」だ!
※調査は時間で区切って見切りをつけるのも大事。15分とか30分とか。

 

もしもの事態を考えてない

先輩
このプラグイン使ったことある?スムーズに使えるかな?

この人のスケジュール確認した?合わなかったらずれるよね?

わたし
…あー………。

 

“超順調に進んだ場合”で書いていた。”世界がわたしを中心に回っている場合”と言い換えてもいいかもしれない。

そこで『楽観的工数と悲観的工数を出して、そこから標準工数を出すといいよ』と教えてもらった。

特に悲観的工数を出す時に、考えうるトラブルや、不明瞭なので調査が必要な項目、逆に悲観する理由がない理由、などをザーッとブレストした

 

『PERT手法』がいいらしい

世の中には『PERT手法』という計算方法があるらしい。LIGさんより引用。
想定する見積をより正確に!工数見積の誤差を減らすPERT手法とは

PERT(Program Evaluation and Review Technique)とは、プロジェクトマネジメントのモデルの一種であり、プロジェクトの完遂までに必要なタスクを分析する手法である。(Wikipedia)

ふむふむ。

PERTではまず以下の3つの値(工数)を出します。

最良な状態でプロジェクトが進んだ「楽観値」
現実的な「標準値」
最悪な状態でプロジェクトが進んだ「悲観値」
そしてその3つの値から実際のプロジェクトにかかる工数に一番近いであろう「期待値」

を算出します。

自分が出していたのは「楽観値」だった。現実的な「標準値」からさらに工数に近い「期待値」を出すのか。

「期待値」は以下の式から算出できます。(楽観値+4×標準値+悲観値)/6

LIGさんの具体例では、標準値より期待値の法が、各タスク0.5人日ほど誤差が出ていた。

タスクが多い開発を想定すると、軽く15人日くらいずれそうでゾッとする。

今後この計算方法で工数見積もりしてみようと思う。

 

さいごに

工数を考え出す時間が、予想よりかなりかかってしまった。

わかったことは、「詳細に想像すればするほど、より正確な見積もりができる」という事実。逆に言うと、超こまかく想像できることは、実現できる

結果として全体の工数はあまり変わらなかった(まぐれかな)けれど、説明する際に自信を持って伝えられる、つまり説得力が増したと感じた。

当たり前だよ!と思われるかもしれないけれど、ハラオチしたので今後はよい見積もりができそうだ。


スポンサーリンク




スポンサーリンク




コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA