互いに相手を必要とするものの、相手のことが分かっているようで分かっておらず、利害が一致することもあるが多くの場合相反する。そんな関係が世の中にはたくさんある。システム開発者とユーザーの関係もまたしかりだ。開発現場はご存じのように泥臭い。開発者とユーザーはいろいろな場面でぶつかったり、すれ違ったりする。このコラムでは、開発者とユーザーのギャップに焦点を当てて論じていきたい。今回は開発者とユーザーの間で利害対立がほぼ必ず発生する「システム開発の見積もり」をテーマにする。
システム開発の費用ほど、買い手（ユーザー）から見えにくいものはない。人月いくらの世界はベンダー都合の価格体系であり、ユーザーは仕方なく受け入れているだけだろう。根本的には納得していないと思う。一方、システム開発の売り手（開発者）にとっても、見積もりは非常に難しく不確実なものである。いろいろな見積もり技法があるが、プロジェクトマネジメントをしくじれば机上の見積もりなど一発で吹き飛んでしまう。
こうした状況なので、ユーザーはこう考える。「ベンダーの見積もりはリスクをたっぷり取ってふっかけてくるのではないか？」。一方のベンダーはユーザーより複雑である。「リスクがあるのでそれを織り込みたいのはやまやまだが、あまり高い価格だと競合に負けてしまう。だが、自社が原因のリスクは仕方ないが、ユーザー側のリスクは背負いきれないので見積もりに含めておきたい。それに、提示価格から値下げを求められる可能性もある。それも考慮すべきか？」。
このように、互いに疑心暗鬼になってしまうのだ。この疑心暗鬼を防ぐためにユーザーが予算の上限を提示するという方法がある。だが、決定打とは言えない。「本当は8000万円でできるのに予算が1億円だからそれに合わせてくるのではないか」という新たな疑念が生まれてしまうからだ。
システム開発に限らないが、売買の基本原理は「売り手はなるべく高く売りたい。買い手はできるだけ安く買いたい」である。こうした人の本性的な基本原理がある以上、見積もりを巡る疑心暗鬼を完全に無くすことは難しい。また、今後見積もり技法がどんなに進化しても、システム設計やプログラミングを行うのが人である限り、リスクを無くすことはできない。だからこそ、どこかで折り合いをつけることが必要になる。
見積もりで折り合いをつけるための知恵として挙げられるのは、複数提案の比較だろう。ユーザーがRFP（提案依頼書）を書き、ベンダーがそのRFPを受けて提案書を書く。そして、複数ベンダーの提案書を比較検討して最も納得がいったものを選定する。このプロセスを経れば疑心暗鬼にならずに済む可能性が高まる。
もちろん、完璧に要求を記述したRFPを作成することは不可能だし、要求を完全に満たす提案書もない。だが、時間と手間を掛けてRFPや提案書を作成することは、互いに相手を理解し、歩み寄る行為であることは間違いない。その歩み寄りこそが、折り合い地点を見つけるために必要なことではないだろうか。
