少し前に話題となったネット上のやりとりを読みながら考えたこと。別に意見を人に押し付けるつもりもないし、自由競争の世の中なので皆が好きにやれば良いと思うけれども。ちなみに当方基本的にアプリ屋なので、ハードやインフラ絡みの観点は一切漏れているので注意いただきたい。
ラフな見積もり
オーダーメードのソフトウェアを見積る場合
- 初期の見積もりは出来れば「ソフトウェアの規模」などを根拠に計算したほうが良いと思う。個人的にはFPあたり。
- 面倒な場合は、NEMSA法という恐ろしく簡単な計算方法もある。(35×内部論理ファイル)＋(15×外部インターフェースファイル)が試算されたFPである
- 他にもGUI要素を数えて試算するなど、簡易計算方法はいろいろある。
- それも面倒だったら同種のソフトウェアのコード行数を図って、FPに換算してもいい。言語別のコード行・FPの換算は簡単。
- 「ソフトウェアの規模」に加えて、ソフトウェアの規模によらない作業を付加したものがラフな見積もりとなる。
- 例えば「利用者教育のサポート」とかの作業の積み上げ。
- 住宅を例に取れば、地域毎に「坪単価」 という指標がある。土地の広さと坪単価を掛け合わせることで概算費用が決まる。同じように、とまで簡単にはいかないけれど、何らかの面積を割り出して見積もるのがいい。
ただし、この段階では所詮ラフな見積もりなので、コミットできるような代物ではない。
費用コミットを強く要請されるのであれば大きくリスクバッファを積まざるを得ない。かつ早期のコスト確定をしてしまうと発注者側はどうしても「決められた費用の中で出来るだけ機能を盛る」マインドになってしまうのでプロジェクトがうまくいかなかったりする事が多いと思う。
一般的かどうかはわからないけれども、注文住宅をイチから設計して建てる場合、設計費用は最初には確定しない(設計が進んだ段階で決まる)。そもそも、設計と施工で見積もりも分かれていたので、これをまとめてやろうとするソフトウェア開発の見積もりが問題なような気もする。
