システム開発の相見積もり｜各社へ同じ情報を渡す進め方
システム開発の相見積もりで難しいのは、複数の会社に声をかけることよりも、各社に同じ条件で考えてもらうことです。この記事では、各社へ同じ情報を渡すために、依頼資料に入れる項目、仕様が固まっていないときの伝え方、質問への答え方、返ってきた提案の比べ方を順に整理します。
相見積もりで金額がそろわない理由
相見積もりを取ると、金額が会社ごとに大きく違うことがあります。このとき、高い会社と安い会社の力量の差だと考えたくなりますが、実際には「何を前提に見積もったか」が違っているだけの場合が少なくありません。見積もりの前提や範囲の違いについては、システム開発の見積もりの違い｜金額より先に見る前提と範囲で詳しく扱っています。
金額に差が出やすい前提には、たとえば次のようなものがあります。
- 管理画面、ログイン機能、決済、通知などを範囲に含めているかどうか
- 想定している利用者数や、求める品質の水準
- 決まっていない部分を、各社がどう仮定して埋めたか
- 納品物の種類や、納品後の保守の範囲
ここで起こりやすいのが、各社に渡した情報そのものが違うという状況です。ある会社にはメールで要望を送り、別の会社には打ち合わせで口頭説明をした場合、各社が受け取った情報量は同じになりません。口頭では「たしか伝えたはず」の内容が、資料には残っていないこともあります。この状態で出てきた見積もりを並べても、公平な比較にはなりにくいのです。
相見積もりの目的を先に決める
資料を作る前に、相見積もりで何を知りたいのかを社内で言葉にしておきます。目的によって、渡すべき情報も、見るべき点も変わるためです。
- 費用の目安をつかみたい
- 進め方や提案の質を比べたい
- 自社の事業との相性や、やり取りのしやすさを確かめたい
新規事業では、金額だけでなく「事業の形を一緒に考えられるか」「途中で方針が変わったときにどう動くか」も大事な比較点になります。目的を先に決めておくと、依頼資料にその観点を書き込めて、各社の提案も比べやすくなります。
各社へ渡す情報をそろえる｜依頼資料に入れる項目
同じ情報を渡す一番確実な方法は、依頼内容を1つの文書にまとめ、全社に同じものを渡すことです。長い仕様書である必要はなく、数ページでも、必要な項目が書かれていれば各社が同じ土台で考えられます。
RFP（提案依頼書）の書き方は、RFP システム開発の書き方｜仕様が固まらない新規事業向けでも扱っています。ここでは、相見積もりで特に差が出やすい項目に絞って整理します。
事業の背景と目的
最初に書きたいのは、どんなシステムを作るかよりも、なぜ作るのかです。
- どんな事業を考えているか
- 誰のどんな課題を解決したいか
- そのシステムが事業の中でどんな役割を持つか
- 今回の開発で何を確かめたいか（事業性、使われ方、提携先への説明など）
新規事業では、システムが事業そのものになる場合も、事業を支える部分になる場合もあります。背景が伝わると、各社は機能の一覧に答えるだけでなく、事業の形に合わせた提案を考えやすくなります。
作る範囲と、今回は作らない範囲
見積もりの差が最も出やすいのが範囲です。機能を並べるときは、「作るもの」と同じ重さで「今回は作らないもの」も書いておきます。
- 利用者の種類（一般の利用者、運営側の管理者、提携先など）
- 最初に必要な機能と、後の段階に回す機能
- 既存のシステムや外部サービスとの連携の有無
- 対応する端末や画面（スマホ、PC、アプリ、Webなど）
範囲の絞り方は、新規事業の管理画面開発｜最初に作る範囲の見極め方やMVP開発の機能の絞り方｜最初に作るものと後回しの基準が参考になります。
決まっていないこと
意外に見落とされるのが、決まっていないことの書き出しです。後述しますが、未確定の部分は各社が自分なりの仮定で埋めるため、見積もりの差の原因になります。「料金体系は検討中」「提携先の仕様はこれから確認する」のように、わかっている範囲で正直に書いておきます。
制約条件
守るべき条件も、同じ資料に書いておきます。
- 公開したい時期や、社内で判断が必要な時期
- 守りたい法令やルール、取り扱う個人情報の有無（新規事業の個人情報とシステム設計｜設計前に確認する点も参考になります）
- サーバーやアカウントの名義についての希望（システム開発のサーバー名義は誰にする？外注前の決め方を参照）
- 既存の技術環境や、使いたい・避けたいツール
提案してほしい内容と進め方
最後に、提案書に何を書いてほしいかを指定します。各社の提案の形がばらばらだと、比べる作業そのものが大変になるためです。
- 見積もりの前提と、含まない範囲
- 開発の進め方と、発注側が確認できる場面
- 開発体制と、発注側に求める役割
- 納品物一覧（システム開発の納品物一覧｜ソースコード以外に受け取る成果物参照）
- ソースコードの権利の扱い（著作権の考え方はソースコードの著作権譲渡｜費用を払っても自動では移らないを参照）
- 納品後の保守の範囲（システム開発の保守契約｜納品後の対応範囲の確認点を参照）
- 提出期限、質問の受付期間、選定の流れ
資料を渡す前の秘密保持
新規事業の資料には、事業アイデアや未公開の計画が含まれます。資料を渡す前に、秘密保持契約（NDA）を結ぶかどうかを決めておきます。確認項目はシステム開発のNDA｜秘密保持で決める8つの項目にまとめています。生成AIを使う開発会社に資料を渡す場合は、生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアも確認しておくと安心です。
仕様が固まっていないときの渡し方
新規事業では、相見積もりを取る段階で仕様が固まっていないのがふつうです。「固まっていないから相見積もりは早い」と考える必要はありません。ただし、固まっていないことを伏せたまま見積もりを頼むと、各社が別々の仮定で見積もりを出します。
未確定部分は「仮定を書いてもらう」
未確定の部分があるときは、次のように依頼します。
- 決まっていないことを、資料にそのまま書く
- 提案では、各社がどんな仮定で見積もったかを明記してもらう
- 仮定が外れたときに、範囲や進め方がどう変わるかも書いてもらう
こうすると、金額の違いが「仮定の違い」なのか「実際の力量の違い」なのかを切り分けやすくなります。仮定を書かない会社には、質問の機会に確認すると、前提のすり合わせ方を見ることもできます。
範囲を幅で示す
「機能は10個」と断定できなくても、「最初に確かめたいのは次の3つ」「それ以外は後の段階で判断したい」のように優先度をつけると、各社が同じ方向を向いて考えられます。仕様が固まらない段階で相談するときの考え方は、仕様が決まってないシステム開発の相談は可能かや要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で整理しています。
契約を段階に分ける提案も比べる
仕様が未確定のまま全体を一括で見積もると、仮定の幅が大きくなり、各社の金額が離れやすくなります。そこで、最初は小さな範囲で動くものを作って確かめ、その結果を見て次に進むかを判断する進め方もあります。依頼資料に「段階に分けた提案も歓迎する」と書いておくと、各社が一括の見積もりだけでなく、段階的な進め方も提示できます。詳しくはシステム開発の契約を段階に分割する方法｜動くものを見て判断を参照してください。
言葉だけの仕様でなく、実物を見ながら認識を合わせる進め方については、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせが参考になります。
質問と回答を公平に扱う進め方
同じ資料を渡しても、その後のやり取りで情報の差が生まれることがあります。ある会社からの質問に答えた内容を、別の会社が知らないままになるケースです。
質問の窓口と期間を決める
次のように、やり取りのルールを最初に決めておきます。
- 質問の受付先を1か所にする
- 質問を受け付ける期間を決める（たとえば資料を渡してから数営業日）
- 回答は、質問した会社だけでなく全社に共有する
- 共有するときは、質問した会社の名前は伏せる
質問への回答も、提案の前提として全社に同じように伝わると、各社の見積もりが同じ条件に近づきます。
個別の打ち合わせをしたとき
提案の前に、各社と個別にヒアリングの場を設ける場合もあります。そこで新しく出た情報（「この機能は優先度が低い」「予算の上限の考え方」など）は、資料の補足として整理し、全社に共有するとよいでしょう。全社に共有できない内容は、そもそも見積もりの前提にしない、と決めておく方法もあります。
窓口の担当者を決める
質問に答える人がその場その場で変わると、回答の内容がぶれます。事業の目的や優先順位について判断できる人を、窓口として決めておきます。発注側の役割は発注側のプロダクトオーナーとは｜役割と判断のしかたで整理しています。
返ってきた提案を比べる軸
提案が届いたら、金額から見る前に、次のような軸で並べます。事前に比較表を作っておくと、見落としが減ります。
| 比べる項目 | 見るポイント |
|---|---|
| 範囲の読み取り | 含むもの・含まないものが明記されているか。資料の意図を正しく読めているか |
| 前提と仮定 | 未確定部分をどう仮定したか。仮定が外れたときの影響が書かれているか |
| 進め方 | 発注側が途中で確認できる場面があるか。実物や画面を見て判断できるか |
| 体制と役割 | 誰が何を担当するか。発注側に求める作業は何か |
| 納品物 | ソースコード、設計書、環境情報など、受け取れるものが明確か |
| 納品後 | 不具合対応や機能追加の範囲、窓口が示されているか |
| 変更への対応 | 仕様変更や追加要望の扱いが決まっているか |
| 金額と内訳 | 何にいくらかかるのか、内訳と条件が読み取れるか |
評価の軸は提案を見る前に決める
提案を見てから評価の軸を決めると、印象に引っ張られやすくなります。何を重視するか（事業への理解、進め方、納品後の支援、金額など）を、提案が届く前に社内で話し合っておきます。この評価の軸は、各社に伝えるかどうかは別として、社内の判断基準として共有しておくとよいでしょう。
見積もりの「単位」にも注意する
見積もりの出し方は、作業量（人月）で積み上げる形もあれば、成果物や段階ごとに区切る形もあります。単位が違うと、金額を単純には比べられません。AIを使った開発では、工数だけでは測りにくい部分もあります。考え方はAI開発で人月の考え方はどう変わる？工数で測れない部分で整理しています。見積もりの単位が違うときは、同じ範囲に揃えて再提示を依頼するか、内訳から読み替えるかを選びます。
提案内容から会社の姿勢も読み取る
資料の読み込み方、質問の中身、未確定部分への向き合い方には、その会社の進め方が表れます。価格の比較とあわせて、会社選びの視点をシステム開発会社の選び方｜新規事業で失敗しない7つの視点で確認しておくと、判断の抜けが減ります。
相見積もりで起こりがちなつまずき
最後に、相見積もりの進め方で起こりやすいつまずきを挙げます。
声をかける会社が多すぎる
会社が増えるほど、質問の対応も、提案の比較も大きな負担になります。社数は、比較できる範囲に絞るのが現実的です。目安としては、提案をしっかり読み込める数にとどめるのがよいでしょう。
依頼資料づくりを各社に任せてしまう
「まず話を聞かせてください」と各社に任せると、各社が聞き取った内容が少しずつ違います。聞き取りから始める場合でも、聞いた内容を発注側で1つの文書にまとめ、全社へ同じものを渡す形にすると、比較しやすくなります。また、判断そのものを手放さない姿勢は、システム開発の丸投げで失敗しやすい理由｜発注側が手放さないことでも触れています。
金額だけで決める
最も安い見積もりが、最も条件が良いとは限りません。範囲や納品物が違えば、あとから追加の費用が発生する場合もあります。追加要望の扱いはシステム開発の仕様変更への対応｜追加要望の扱い方で確認できます。
途中で条件を変えて、一部の会社にしか伝えない
提案を受けたあとに、「やはりこの機能も入れたい」と一部の会社にだけ伝えると、比較の前提が崩れます。条件を変えるときは、全社に同じ内容で再提示を依頼するか、変更の影響を別途整理して比べます。
提出期限が短すぎる
期限が短いと、各社は確認不足のまま仮定を増やして見積もりを出すことになります。質問の期間と提案の作成期間を、無理のない長さで設定したいところです。
まとめ
システム開発の相見積もりで公平に比べるには、各社が同じ情報を持った状態で提案できるようにすることが土台になります。
- 金額の差は、前提や範囲の違いから生まれていることが多い
- 事業の背景、範囲、決まっていないこと、制約条件、提案してほしい内容を1つの資料にまとめ、全社に同じものを渡す
- 仕様が固まっていないときは、未確定部分を明記し、各社に仮定を書いてもらう
- 質問の窓口を1つにして、回答は全社に共有する
- 提案は、範囲、前提、進め方、納品物、納品後を見てから金額を比べる
- 評価の軸は、提案を見る前に社内で決めておく
相見積もりは、金額を比べる場であると同時に、各社の進め方や考え方を知る機会でもあります。比べやすい形に情報をそろえておくことが、その後の開発でのすれ違いを減らすことにもつながります。
私たちJustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、新規事業のアイデアに対して、システムを軸に事業の形まで提案しています。構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる進め方です。仕様が固まっていない段階や、稟議を通す前の段階でも相談できますので、相見積もりの比較対象の1つとして考えるときは、JustFitのサービス紹介もあわせてご覧ください。