ソフトウェアエンジニアなら誰もが通るであろう見積作業に関する話です。
ソフトウェアの見積作業ってめちゃくちゃ難しくないですか？
ソフトウェアの開発って、大体半年から1年長いと3年先くらいまでのやることを見据えないと書けません。
でこの見積もり作業って、ソフトウェアを開発するための代金に直結してくるので見積もりを高くしすぎると、仕事がもらえないですし、安くしすぎると赤字の仕事になったり、納期が短くなってそもそも開発が終わらないといった状況になります。
IPAの情報が役立つ
開発規模の情報って社外秘であることが多いんで、なかなか手に入らない情報なんですよね。
なので、自分で出した見積もりの妥当性が分からず結構困ってしまいます。
自分は、見積もりの際に下記のIPAのデータ白書を利用しています。
色んな企業の色んな規模のソフトウェア開発の実績工数が掲載されているので非常に参考になります。
https://www.ipa.go.jp/files/000069381.pdf
コード行数が見積もることの盲点
個人的にソースコード行数から工数を見積るのは微妙なきがします。
プロジェクトごとに抱えている開発課題がそもそも異なるので、それらを無視してコード行数から見積もるのはずれが大きくなると思います。
ソースコードを作成する速度って開発者の技量によっても左右されますからね。
趣味プログラミングではありますが、早い人は一日に1万行くらい作成する人もいるわけですし。
一方で、仕事の開発となると、情報共有だったり設計文書の作成だったりして、1日に数百行しか進まないこともザラですからね。
実際データ白書を見ると、１時間あたりに生産できる行数なんて数十行程度ですからね。
実装だけではなく、設計やらテスト含めての指標なので、乖離が出るのは仕方ないですが。
結局経験と勘に頼る
データ白書をみていると分かるのですが、データが集まっている箇所はあるのですが、
プロジェクトが抱えている課題などは全く異なってくるので、結局勘になることが多いです。
というのも、見積もりの内容ってすぐに返答を求められることが多いんですよね。
2日とかそれくらいで見積もれ！くらいのことが多いです。
何らかの数値的な根拠は出しつつも、実態は経験と勘で出した答えを裏付けているだけのものが多かったり。
このあたりの見積もりの妥当性を完璧にするツールとかあったらめちゃくちゃニーズがあると思う。
