クオリティスタート
社内にPMがいない会社の発注進め方RFP要件定義見積もり

RFPを出しても見積もりがばらつくのはなぜか|要求と要件の違いと、見積もりの精度を上げる進め方

公開日 更新日 読了目安 5分執筆 湯本 堅隆(株式会社クオリティスタート)

RFP(提案依頼書)を出して複数の開発会社から見積もりを取ったのに、金額が大きくばらついて比べられない。そんな経験のある方に向けた記事です。結論から言うと、見積もりがばらつくのは、RFPに書かれているのが「要求」で、開発会社が見積もりに必要としているのが「要件」だからです。この記事では、要求と要件の違い、見積もりの精度を上げる進め方、RFPに書いておくべきことを説明します。

RFPを出しても見積もりがばらつくのはなぜか

RFPに書かれた要求を、開発会社がそれぞれ自分の解釈で要件に置き換えて見積もるからです。同じRFPでも、置き換え方が会社ごとに違えば、金額も違ってきます。

RFPに書く内容は、おおむね次の5つです。

  1. システム化の背景
  2. 解決したい課題と現状
  3. システムに必要な機能
  4. スケジュールと予算
  5. 納品物と契約形態

どれも大切ですが、ここに書かれるのは「こういうものが欲しい」という要求です。開発会社は、そこから画面・データ・機能を想像して見積もります。想像の幅が広いほど、ばらつきも、後からの追加費用も大きくなります。

RFP(提案依頼)と要件定義の差が大きいほど、導入する側のリスクとコストが高まることを示した図。IT企画をしっかり行うと差が小さくなる

要求と要件は、どう違うのか

要求は「どうなりたいか」、要件は「そのために何をどう作るか」です。注文住宅にたとえると分かりやすくなります。

  • 要求:「リビングは12畳以上」「書斎が欲しい」「床の木からぬくもりを感じたい」
  • 要件:「間取りはこうする」「構造材はこれ、壁にはこの塗料を使う」

要求を満たす要件が固まって、初めて「どんなシステムを作るか」が決まり、正確な見積もりが出せます。要求と要件の間には、大きな溝があります。

なぜ要件を先に固めるのは難しいのか

ソフトウェアは、使ってみないと期待どおりかを確かめにくいからです。家なら図面を見て生活の動きを想像できますが、業務システムでは「その画面の順番だと、現場の作業に合わない」という話が、使い始めてから多く出ます。

しかも、プログラムは「この場合はこうする、次はその結果を使ってこう計算する」という前後関係が絡み合った命令の集まりです。前提が一つ変わると、家具の配置換えのようにはいかず、作り直しになることがあります。だからこそ、作る前に要件を確かめる工程が要ります。

見積もりの精度を上げるには、どうすればよいか

要件定義を開発から切り出して先に契約し、固まった要件をもとに開発を見積もる、2段階で進めます。

  1. 要件定義を先に契約する:何を作るかを決めていく段階なので、作業に対して費用を払う準委任契約が向いています
  2. 要件を確かめながら固める:業務の流れとデータから要件を洗い出し、画面の試作品を現場の方に操作してもらって確かめます
  3. 固まった要件で開発を見積もる:作る画面・データ・機能を数えられるので、見積もりの根拠がはっきりします

最初から開発全体の金額を確定させたい気持ちは分かります。ただ、要件があいまいなまま確定させた金額は、あいまいな部分を安く見積もったか、リスクを上乗せしたかのどちらかです。

RFPには何を書いておけばよいか

機能の一覧より先に、開発会社が要件を考える材料を書きます。次の3つがあると、見積もりの解釈の幅が狭まります。

  • 解決したい業務の課題:誰が、どの作業で、何に困っているか
  • 今の業務の流れ:使っているシステム、帳票、Excelと、その使い方
  • 決める人:社内の決裁者と、開発会社とやり取りする窓口

今の業務を調べることの意味は「システム導入の成否は、現状分析が9割」で、見積もりの値段が不透明になる背景は「システム開発の値段が不透明になる背景」で説明しています。

当社ではこう進めています

当社では、開発に入る前に、次の4つの段階で要件を固めます。AI開発のページでも紹介している進め方です。

  1. コンセプトワーク:業務フローと作業一覧、使っているシステムや帳票を調べ、現場の負担を言葉にします
  2. 構想立案:あるべき業務を描き、必要な機能を洗い出して優先順位をつけます。ここでできる機能一覧が、RFPの土台になります
  3. 仮説検証:入力画面を中心にHTMLの試作品を作り、日々の業務で使えるかを現場の方に操作して確かめます
  4. 要件定義:どんなデータを、どの画面で、どう操作するか。データモデリングから始めて、画面と機能を固めます

「使ってみないと分からない」を、作る前の試作品で確かめるのが3つ目の段階です。モバイルオーダーの再構築でも、要件定義の段階で、注文の流れと、条件の組み合わせで増えていくクーポンの適用ルールを整理してから、設計と実装に入りました。

まとめ

  • 見積もりがばらつくのは、RFPに書かれた要求を、各社が別々に要件へ置き換えるから
  • 要件定義を先に切り出して契約し、固まった要件で開発を見積もると、精度が上がる
  • RFPには、機能の一覧より先に、業務の課題・今の業務の流れ・決める人を書く

社内にPMがいない状態での外注の進め方全体は、「社内にPMがいない会社のシステム開発外注ガイド」にまとめています。

RFPを書く前の段階から相談したい方は、お問い合わせからご連絡ください。PMが同席してお話しします。

よくある質問

RFPのテンプレートを使えば、見積もりはそろいますか?

そろいにくいままです。テンプレートは書く項目をそろえてくれますが、書かれる中身は要求のままだからです。見積もりをそろえるには、項目より先に、業務の課題と今の業務の流れを具体的に書くことが効きます。

見積もりは何社に頼めばよいですか?

社数より、比べ方を先に決めます。金額だけを比べると、あいまいな部分を安く見積もった会社が選ばれがちです。要件定義をどう進めるか、誰がPMを担うかを聞いてから金額を比べると、後からの追加費用で逆転されにくくなります。

概算の見積もりと、正式な見積もりは何が違いますか?

概算は、要求をもとに経験から幅を持たせて出す金額です。正式な見積もりは、要件が固まり、作る画面・データ・機能を数えられるようになってから出す金額です。概算の段階では、金額よりも、何が決まれば金額が固まるかを確かめます。

記事の内容について、相談してみませんか。

記事で紹介した進め方を、貴社のプロジェクトでどう使えるか、PMとエンジニアがお話しします。