受託額の見積もりというのは定量的に計ることの出来ない工数に定量的な金額を当てはめる作業なんで、正しい方法はありません。出てきた金額を発注側受託側の双方が納得できるかどうかだけです。極端な話、サイコロふって決めてもいいんですが、さすがにそれではいい加減過ぎるんで、損にならない程度に現実的な方法を採る必要があります。
代表的な方法には大きく分けて成果物ベースと工数ベースがあります。成果物ベースとは例えばウェブ制作の場合にページ当たり○○円という考え方。プログラム開発ならば行当たりいくらとかですね。工数ペースは1人月(人日)当たりいくらという考え方。私は基本的に工数ベースで見積もりをしています。なぜなら、プログラム開発では掛かる費用は人件費がほとんどです。その人件費は月給という形で時間に応じて支払われるわけですから、工数ベースの方が整合性が採れると思うからです。
ただ、この工数ベースという考え方は特にソフトウェア業界では非常に評判が悪いです。それは特にプログラマの場合は人によって生産性に非常に大きな開きがあるからです。普通の人なら何カ月も掛かるようなプログラムを、優秀な人なら数日で作ってしまうなんてことは平気である業界です。この場合工数ベースだけで見積もってしまうと優秀な人は同じ成果を上げても安い報酬しか得られない事になり、それはおかしいという考え方です。でも、この場合は何カ月という工数で見積もればいいと私は思います。だって普通の人なら実際にそれだけかかるんですから。また、工数ベースは完全な見積もり法でないのは確かですが、では代わりに何かいい方法があるかというとなかなかありません。ならば、欠点はあっても比較的マシな方法で見積もるのが現実的な対処だと思います。
成果物ベースも工数ベースもどちらも掛かった手間に応じた見積もり方です。それに対して成果物の生み出す価値をベースにするという考え方もあります。1日で作った小さなプログラムだけど、顧客に何億円もの利益を生み出したなんてことは、めったにないけれども無い話ではありません。こうしたときに手間に応じた見積もりだとほんの少額しかうけとれませんので面白くないというのは感情としては分かります。でも、これはうまくいった例の話。逆に何カ月も掛かって作ったけど顧客は1円の利益も得られなかった場合もあります。商売ですからそういうリスクもありますね。そのリスクを負っているからこそ顧客は成功時に莫大な利益を受け取ることもできるわけです。受託側もそのリスクを負ってリターンを得る方法としてロイヤリティ方式がありますが、私はリスクが大きすぎるので使ったことはありません。
ということでうちは基本的に工数ベースで見積もってます。会社によっては業務の難易度に応じて単価に差をつけている場合もありますが、うちは難易度調整は工数で行って単価は均一にしてます。逆にデータ入力のような比較的低難易度の業務でも1日掛かるなら1日分。
工数は純粋に業務に掛かる部分だけで見積もってますので、それ以外に業務管理費として5%の金額を計上しています。これが打合せの時間とか交通費などの費用。5%なんで乱暴ですが、詳細に見積もるのも大変なんでここは概算でやってます。
値切り要請を受けることはそれほどないんですが、やはり時々はあります。半額とかの極端なものならともかく、ある程度なら応じることもあります。ただし一括での値引きだけ。工数や単価での値下げ要請は一切受け付けないようにしています。それをすると、下げた数字が次回以降の標準になってしまうと思うからです。