システム開発業界の特殊性として、開発当初の段階から正確な見積が出しにくいことがあります。
開発工程が進むにつれて詳細が明確になっていくのですが、「終わってみなければ分からない」といったことも珍しくありません。
予算には限度があり、できるだけ早期の段階から正確な見積を求めるのは、企業として当然のことです。
業界の特殊性が理解されず、「なぜ正確な見積が出せないのか？」といったトラブルも多いのです。
どんな見積もそうなのですが、前提と根拠が示されていなければなりません。建設業を例にとると、建物の規模構造は〇〇なのだから、材料費や工事費は〇〇となり、工期は〇〇となる、といった具合です。
つまり、当初から詳細に根拠となる前提が明確になっていればいるほど、正確な見積が出せるということなのです。
システム開発でよくあるのですが、最終テストの段階で仕様変更や機能追加が発生することがあります。
先の建設業で言えば、施主に引き渡し直前の検査で「窓を開けてほしい、壁を取ってほしい」といった注文が入るようなものです。
窓や壁なら対応可能かもしれませんが、「2階建を3階建にしてほしい、鉄骨構造を木造にしてほしい」となれば、最初からやり直しです。
建設業の場合、眼に見えることなのでこうした非常識は考えられませんが、システム開発では「2階建を3階建に・・・」といったアクシデントがあるのです。
これは決してクライアントだけが悪いわけではありません。

クライアント、開発業者にとって、開発が進んだ段階で仕様変更や機能追加をすることは時間費用面で大きなロスになります。
さらには高額な投資をしてシステムを導入したのに、現場では元の手作業に戻り、全くシステムが活用されていない、といった最悪のケースもあるのです。
こうした事態にならないために、双方に綿密な打ち合わせが求められます。開発業者は「クライアントの注文だけ仕上げれば良いだろう」などという考えでは不十分です。
一方、クライントも「お金を払うのだから後はお任せする」といった考えでは、後になって困ることになってしまいます。
クラインアントはシステム開発の専門家ではありませんので、開発業者が主導しながらの打ち合わせに、クライアントも積極的に協力する姿勢が求められます。
一方、クライアントと開発業者の間に立って助言するシステムコンサルタントの活用がこうした損失防止にとても有効です。

見積の出し方としては
見積は進行に応じて出されることになります。前提と根拠がわかる部分と、現時点ではわからない部分を明確にして概算見積を出しますが、クラアントとしてもこうした特殊事情に歩み寄る必要があります。
そして、再見積りを出すタイミングを予め明確にしておくことです。
クライアントは絶対に譲れない機能や予算の上限を最初から明確にしておくのです。
この絶対に譲れない機能は、クラインアントが専門知識を駆使して開発業者に提示することはできません。
開発業者が打合せの中から汲み取る必要があります。
こうした下準備を入念に行えば、仮に仕様変更や機能追加が発生することあっても、「窓を開けてほしい・・・」程度に収まり対応も容易となります。