前回までは、見積もりの基本的な事項として「見積もりプロセス」「システム開発プロセスと見積もりの関係」をテーマに取り上げました。今回は、見積もりを行う上で発生しがちなユーザーとベンダーの認識の齟齬について、その発生原因と解決策を説明します。
システム開発はユーザーとベンダーの共同作業です。それぞれの立場の担当者が集まって話を進めてみると、どうも話が噛み合わない。システム開発の上流工程では、そんな場面がたびたび発生するものです。例えば、「要求事項を細かく確認してみたら、ベンダー担当者が理解したと思っていた内容が、ユーザー担当者の意図とは異なっていた」「従来通り動作するというユーザーの認識が、ベンダー担当者には伝わっていなかった」などです。
契約を交わす前なら、こうした事態に気付いた時点で双方が確認し合うことにより手戻りを未然に防ぐことができます。しかし、見積もり内容を双方が確認し契約を交わした後にも関わらず認識の食い違いが残ったままになっていると、予定外に発生した作業の対応や開発期間の延伸などプロジェクト全体に大きな影響を与えてしまいます。
このような認識の食い違いを、以降では「認識の齟齬」と呼びます。ここでは、第2回で登場したITベンダーのSE、山田さんの事例を通して、システム開発の上流工程ではユーザーとベンダーの間では認識の齟齬が発生しやすい、という特徴を説明します。齟齬が発生する原因や解決策についても説明します。
そんなところに認識の食い違いが
山田さんが所属する部署は、ユーザーX社の福利厚生システム開発を受注しました。山田さんは、見積もり担当を任されます。前回の失敗を踏まえて見積もりプロセスを意識しました。
見積もりを行う際に、X社から提示されたRFP（提案依頼書）や添付されていた要求機能の一覧を確認し、X社システム部の佐藤部長や見積もり経験が豊富な社内のメンバーと見積もり内容を検証したので自信満々です。
今回は要件定義の作業結果のレビューのため佐藤部長を訪問しています。
～打ち合わせの会議室にて～
山田さん：「今回の福利厚生システムでは、ユーザーが利用可能な施設の一覧をこちらの画面に表示します。具体的な表示内容の項目は、このシートにまとめました」
佐藤部長：「ふむふむ…あれ、おかしいな。当社の福利厚生システムは、宿泊施設を予約できるのだけれど、支社によって利用可能な施設が違うからね。支社ごとに、利用可能な施設を表示する必要があります」
山田さん：「支社によって利用可能な施設が違うのですか。RFPに添付されていた機能一覧のこの部分の表示機能については『施設情報を管理し、ユーザーが利用可能な施設情報を表示する』と書かれていたので、支社に関係なく、提携の施設情報を検索して表示するものと理解していました」
佐藤部長：「それは勘違いだね。もう一つ、施設情報のデータ連携先の記述も漏れているよ。現行システムと同じ仕様で、別のデータベースに登録する必要があります」
山田さん：「（ええっ、そんな前提があったなんて！）分かりました。会社に戻って再度検討します」
