何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

人月見積で困るところ

ソフトウェア開発のプロジェクトで見積を行う際にいつも思い悩んでいること

  • 人がアサインされる前に見積もる

これに尽きる

で、困っているばかりでは仕事にならないので今までやってきたことを書き残しておきます。

経験の浅い頃

  • 標準的な人で見積もる まず、標準的な人ってなんですか?って感じですね。

  • 自分を標準とする

  • 2年目くらいの若手を標準とする
  • プロジェクトに参加しそうな人を周囲に聞いて回り、候補者からなんとなく平均像を標準とする

ぱっと見では、一長一短のようにも見えますが結論としてはほとんどうまくいきませんでした。 あまり上手くいかなかった原因の分析は出来てませんが、上記のいずれも未来を見通せたものではなかった。 というのが結果論的には言えると思います。
特に最後のプロジェクトに参加しそうな人を聞いて回るの案とか、最初は良い案だと思ったのですが、他案件の動きもあり大はずれしてしまいました。

最近

色々見積に失敗して、勉強もしました。

その結果、最近やっている方法

  • 相対単位で見積、人がアサインされた段階で相対単位を係数としてかける。

というものです。
アジャイルな見積に近いですね。
一番最初の見積がコミットメントになってプロジェクトの予算と納期が固定になってしまう案件だと辛いのですが、*1少なくとも
プロジェクト開始後にはある程度正確な見積ができ、
正直ベースのリリーススケジュールを立てることができるようなやり方だと思います。

ちなみに勉強したのはこんな書籍

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

*1:そのような案件の見積をどうやったらうまくいくかなんて天のみぞ知るだと思う