ソフトウエアの規模や開発工数、コストなどを算出する「ソフトウエア見積もり」。思えばこの10年、記者はこのソフトウエア見積もりというテーマを追い続けてきた。
その間、さまざまな変化が現場で表れてきたほか、記者の思いも変わってきた。この週末スペシャルでは、そんなソフトウエア見積もりの10年を振り返ってみたい。
勘や経験に頼る見積もりがほとんど
まずは現場のITエンジニアに対して、どのように見積もりをしているかを探り続けた。今から8～10年前のことである。当時は勘や経験に頼った見積もりが大半で、それがプロジェクトの失敗につながることが多かった。
アンケートに寄せられた回答を見ると、やはり大半は勘や経験に頼る見積もりで、6割を超える回答者が見積もりを巡るトラブルを経験していた。以下がその結果報告である。
■大半は「勘」や「経験」で見積もり---6割超が見積もりを巡るトラブルを経験
この結果を受けて、記者は取材を進め、合理的・論理的な見積もりとはどんなものなのかを探った。数十社に及ぶ取材を経て、以下のような結論にたどり着いた。それが6年前のことである。
この頃、見積もり技法や見積もりプロセスが広がりを始めてきたが、一方で「教科書的な見積もり」が引き起こす問題も出始めた。標準技法が普及してきた半面、そこには落とし穴がいくつもあったのだ。それをまとめたのが以下の記事だ。
ソフトウエア見積もりには、規模見積もり、工数見積もり、コスト見積もり、価格見積もりがある。このうちプロジェクトの成否に直結するのは、規模・工数・コスト見積もりの三つだ。これらの技法の穴をふさぐアプローチをまとめたのが以下である。
「勘」や「経験」が必要な場面もある
ここまできて、当初問題視してきた「勘」や「経験」を一概に否定できないことに気付き始めた。むしろ勘や経験に頼る場面はあり、それがより精度高く見積もるための重要な点だと分かった。それを報告したのが以下の記事である。
特に未知のプロジェクトの場合、合理的・論理的な見積もりプロセスに、プロジェクトマネジャーの勘や経験を加える必要がある。その例を、以下の大規模プロジェクトで紹介した。
ここ最近は、個別の技法の特徴や今後のあり方について興味が沸くようになった。特にプロジェクトの作業や成果物を構造化するWBS（Work Breakdown Structure）を追い続けたのがこの2～3年である。
また、開発プロセスの変化とともに規模見積もりのあり方にも注目するようになった。アジャイル型開発プロセスに傾倒する一部の方からは批判を浴びたが、記者はむしろアジャイル推進派である。だからこそ、以下の記事をあえて執筆した。
いずれにしても、目に見えないソフトウエアを見積もる方法におそらく答えはない。だからこそ先人らが試行錯誤を重ね、今の見積もり技法や見積もりプロセスがある。これから先も進化を続けるに違いない。引き続き、ソフトウエア見積もりを追い続るつもりだ。
