三社から取った見積が、倍以上離れている。どれが高いのか、どれに作業が抜けているのか、比べる物差しが手元にない。「RFPを書いて」と言われても、社内の前例は雛形が一枚だけ。発注担当者がつまずくのは、たいてい開発が始まる前です。
要件を決めるのは、作る側ではなく使う側。IPA(情報処理推進機構)の「ユーザのための要件定義ガイド 第2版」(2019年公開)も、業務部門のユーザが主体的に関与するスタイルへの変革を求めています。とはいえ、要件を決めた経験のある担当者が社内にいるとは限りません。判断の責任は発注者に残したまま、判断の材料をそろえる役が要ります。
私たちはその役を、発注者の側に立って引き受けます。何を作るかより先に、何のために作るのかを言葉にする。構想そのものから描き直したい場合は、業務変革の構想から整理するDX支援を入口にする選択もあります。目的が定まれば、見積の差も読めるようになる。