ユーザーとベンダー間の齟齬をなくすためには、見積り方法がユーザーとベンダー間のコミュニケーションツールとなるべきだと思います。つまり、見積りを"見える化"していかなければなりません。

"見える化"された見積りには、見積りの入力情報である要求仕様や前提条件との関連性が明らかにされていることが必要です。この関連性が明確であれば、ユーザーは「予算内に収めるには要求仕様を削るべきか、それとも予算を増やすべきか」の判断が可能になります。

見積りは「当てる」ことを優先して考えるのではなく、いかにしてユーザーに理解してもらうかを工夫しなければなりません。相互理解が深まれば、破綻するプロジェクトも減ることでしょう。

ただし、見積り方法の中にベンダー側の都合を入れてはいけません。ユーザーから見た要求仕様に比例するような見積り方法でないと、コミュニケーションツールにはなり得ません。例えば、開発者のスキルなどはベンダーがシステム構築コストを見積もる上では大きな変動要素であり、重要なパラメータですが、これをユーザーと共有する見積り方法のパラメータに入れるべきではないのです。

ちょっと話はそれますが、筆者が見積りの前提条件が重要だと認識したきっかけは、あるプロジェクトの見積りです。

やはり曖昧な要求仕様から見積りを実施しなければならない案件でした。A社の見積り額は6億円、B社は8億円を提示しました。この案件はA社が受注したのですが、結局出来上がりは8億円だったと後で聞きました。

A社は前提条件を付けた上で6億円という見積りを出し、その前提条件内で収まらなかったため8億円となったそうです。B社は類似のシステムを構築した経験もあり、自信を持って8億円とだけ提示しました。見積りの精度としてはB社の方が良かったのかもしれませんが、ユーザーには理解されなかったということです。

金額を提示することだけが見積りではありません。見積りと前提条件が結び付いてこそ、ユーザーとベンダーのコミュニケーションが可能になるのだと痛感した出来事でした。

執筆者プロフィール

藤貫美佐(Misa Fujinuki)
株式会社NTTデータ SIコンピテンシー本部 SEPG 設計積算推進担当 課長。IFPUG Certified Function Point Specialist。日本ファンクションポイントユーザー会の事務局長を務める。

『出典:システム開発ジャーナル Vol.1(2007年11月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。