最近あったできごと。
ある機能追加に対して概算で工数見積もりをすることになったのだけど、そのときに言われたのが
「設計、製造、単体試験、結合試験までの追加・改修規模をステップ数で出してください。最終的には難易度の係数をかけて作業工数（時間）として計算します」
うーん、製造フェーズにおける新規・改修の規模（ステップ数）なら、あまり納得は行かないが（自分の担当部はCなどではなくJavaだし）なんとか出せないことは無いけど、設計と試験フェーズをステップ数として出せと言われると...？
そもそも設計もしてないし、仕様も箇条書きの要件しか無い状態でステップ数が見積もれたら、それはそれですごいと思うけど、JavaとCだと生産性違うしな...そもそもJavaをステップ数で見積もる意味があるのかどうかもよく分からない...。
時間があれば、私の場合は積み上げ方式で作業の洗い出しとそれぞれにかかる工数を出して足しあわせる方法を使おうと思ったけど、時間もないので結局ドンブリ（エイヤーとも言う）でステップ数ではなく工数を直接見積もった。
私もFPとかもう少しきちんと見積もり手法を身につけていれば良かったのだろうが、現場叩き上げのあまりよろしくない方法しか使えないのが悔しいところ。ただ今回は新規機能の追加で類推できるような実績データも過去に無いし仕方ないといえば仕方無いのかもしれないが。
うちの会社では、メーカーに常駐して組み込み、制御系の作業をしてきた人はステップ数の見積もりを使う傾向にある。組み込み系でC言語だとまだ見積もりやすいのかな。Cなら一人600step/月とかやれば計算は楽だし。
一応、会社標準としての見積もり作成フォーマットはあるけれど、これも
- 基本設計...設計書作成規模（枚数）
とか設計フェーズの見積もりを「設計書の枚数」で見積もるフォーマットだったりする。これもまた見積もり辛い気が...。
とは言っても、ソフトウェアの見積もり方法は正解が無いので、どんなやり方にしても精度が出れば良いんだろうけどね。
コメント