オルタナティブ・ブログ > プログラマー社長のブログ >

プログラミングでメシが食えるか!?

受託開発の見積

»

GWの合間ですが、今日は新規のお客さんのところに打ち合わせに行き、RFPの読み合わせを行いました。都度質問をしながら要件を把握し、来週には見積と提案書を提出することになります。

毎度のことながら、受託開発というか、開発の見積は実に困難です。画面や帳票のように、ある程度同じようなものを、大量に作るようなものであれば、多少の難易度の差はあるとしても、かけ算すれば大体見積もることができますが、試行錯誤しなければならないタイプは実際にやってみないとわからないものです。

私が得意としているネットワークプログラミングであれば、大体似たようなものを作った経験から、おおよそこのくらい、と見積もることができることもありますが、そうでない場合は、見積もる前にプロトタイプを作ってみることも良くあります。実はプロトタイプとはいえ、ほぼそのまま使えてしまうことも多く、見積もる時点ですでに完成に近い状態、ということもよくあります。

しかし、いくつかの機能が連携するようなものや、何人かで、あるいは何社かで分担して開発するようなタイプは、さすがに目処をつけてから見積もるわけにはいきませんので、机上で頭を悩ますことになります。私はこの作業があまり好きではありません。。

いっそのこと、予算を言ってもらい、それならここまでやりましょう、という感じの方が楽なくらいです。指し値をするのは下請けいじめだといわれていますが、見積を何度も修正させられるくらいなら、最初から指し値をしてもらう方が楽ということも結構多い気がします。

何度かお取引が続いているお客さんだと、お互いどんな感じかをわかっているので、見積はある程度形式的になり、お互いに目的を達成することに集中することができることもあるのですが、さすがに新規のお客さんだとそうはいきませんね。

机上で見積もる場合は、目処がついていない部分のリスクを見込まなければということになり、大抵高めになるものです。見積を提出すると、もう少しなんとかならないか?ということになり、何度かやりとりをすることになります。何となく、お互いにとって時間の無駄という感じもしますね・・・。

どう見積もっても、結局最後は、「なんとかするしかない」わけで、思ったより楽に終わることもありますが、大抵は予想より手間がかかることが多いような気がします。とくに、ノウハウがあまりない分野の場合はそうですね。。

Comment(2)