開発会社に見積もりを依頼したら、会社によって金額が大きく違った、あるいは「もう少し詳しく教えてください」と何度も聞き返された、という経験を持つ方は多いはずです。見積もりの精度と比較のしやすさは、依頼する側が最初に渡す情報の質で大きく変わります。情報が少なければ、開発会社は推測で範囲を決めるしかなく、推測の幅がそのまま金額の幅になります。
結論から言うと、見積もりを依頼する前に準備すべき情報は、目的、利用者、業務の流れ、必要な機能、既存システムやデータ、予算感、スケジュール、そして決まっていないことの八つです。すべてを完璧に整える必要はありません。むしろ、決まっていることと決まっていないことを分けて正直に伝えることが、概算見積もりの精度を上げる一番の近道です。
この記事は、初めてシステム開発の見積もりを依頼する事業責任者や、社内の要望をまとめて開発会社に伝える担当者に向けて書いています。依頼前に準備する資料、それぞれの書き方の要点、予算感の伝え方、依頼から比較までの手順、よくある失敗を、すぐに使えるチェックリストとともに整理します。
なぜ見積もり依頼の準備が大切なのか
システム開発の見積もりは、「どれだけの作業が必要か」を予想して金額にしたものです。作業の量は、作る機能の数と複雑さ、連携やデータ移行の有無、品質への要求などによって決まります。依頼の段階でこれらが分からないと、開発会社は次のどれかの対応を取ることになります。
- 不確かな部分を、安全側に大きめに見積もる
- 不確かな部分を、自社の解釈で小さく定義して見積もる
- 見積もりの前提条件を多く付けて、「前提が変われば金額も変わる」とする
- 詳しい情報が出るまで見積もりを保留する
どの対応でも、発注側にとっては比較が難しくなります。大きめに見積もった会社は高く見え、小さく定義した会社は安く見えますが、実際の範囲が同じとは限りません。前提条件の多い見積もりは、後から金額が変わる可能性が高くなります。
準備をして情報をそろえれば、各社が同じ前提で見積もることができ、金額の違いが「やり方や体制の違い」から来ているのかを比較できるようになります。見積もりを受け取った後の比べ方は、システム開発の見積もり比較のコツで詳しく説明しています。
準備にかける時間は、決して無駄にはなりません。依頼資料をまとめる過程で、社内の関係者の間で目的や優先度の認識がそろい、開発が始まってからの手戻りも減ります。見積もりの準備は、プロジェクトそのものの準備でもあるのです。
概算見積もりと詳細見積もりの違い
見積もりには、大きく分けて概算見積もりと詳細見積もりがあります。概算見積もりは、要件が固まる前の段階で、おおよその規模と金額の幅をつかむためのものです。詳細見積もりは、要件定義を経て、作る範囲が具体的になった段階で出すものです。
この記事で扱う準備は、主に概算見積もりの精度を上げるためのものです。概算見積もりの段階で範囲の認識をそろえておけば、詳細見積もりで金額が大きく変わる事態を防げます。用語の違いは概算見積もり・詳細見積もりの解説も参考にしてください。
見積もり依頼前に準備する8つの情報
見積もり依頼の前に準備する情報を、一覧にまとめます。
| 情報 | 伝える内容 | 見積もりへの影響 |
|---|---|---|
| 目的 | 何のために作るのか、何が解決されれば成功か | 必要な機能の範囲と優先順位が決まる |
| 利用者 | 誰が使うのか、人数、利用する場面と端末 | 画面の作り、性能、セキュリティの水準が決まる |
| 業務の流れ | 現在の業務の進め方と、システム化した後の流れ | 機能の数と複雑さが分かる |
| 必要な機能 | 機能の一覧と、それぞれの優先度 | 作業量の見積もりの土台になる |
| 既存システム・データ | 連携するシステム、移行するデータ | 連携と移行の作業量が分かる |
| 予算感 | おおよその予算の範囲 | 提案の方向性と範囲の調整に使われる |
| スケジュール | 希望する公開時期と、その理由 | 体制の組み方と、段階的な公開の要否が決まる |
| 決まっていないこと | 未確定の事項と、決まる見込みの時期 | 前提条件の置き方と見積もりの幅に影響する |
ここからは、それぞれの情報の書き方の要点を説明します。
目的と利用者の伝え方
目的は「解決したいこと」で書く
目的は、「顧客管理システムを作りたい」のように作るものを書くのではなく、「営業担当ごとにバラバラに管理している顧客情報を一か所にまとめ、担当が変わっても過去のやり取りが分かるようにしたい」のように、解決したいことを書きます。目的が分かれば、開発会社は既存のサービスの活用や、より小さな範囲での実現など、作り方の選択肢を提案できるようになります。
あわせて、何ができれば成功とするかも書いておくと、範囲の判断がしやすくなります。たとえば「問い合わせの対応状況を、誰でも一覧で確認できるようになること」のように、具体的な状態で書きます。
利用者は種類と人数と場面で書く
利用者については、次の点を伝えます。
- 利用者の種類（社内の担当者、管理者、顧客、取引先など）
- それぞれのおおよその人数と、同時に使う人数の見込み
- 使う場面（事務所のパソコン、外出先のスマートフォン、店舗のタブレットなど）
- ITへの慣れの程度（操作の分かりやすさをどれだけ重視するか）
社外の人が使うシステムか、社内の人だけが使うシステムかによって、画面の作り込み、セキュリティ、問い合わせ対応の考え方が大きく変わります。
業務の流れと必要な機能の伝え方
業務の流れは図か箇条書きで
業務の流れは、誰が、何をきっかけに、どんな作業をして、次に誰に渡すのか、を順番に書きます。きれいな図である必要はなく、手書きのメモや箇条書きでも十分です。大切なのは、通常の流れに加えて、例外の流れ（キャンセル、差し戻し、承認の却下など）も書くことです。例外の流れは機能の複雑さに直結するため、見積もりの精度に大きく影響します。書き方は、業務フロー図の解説も参考にしてください。
機能は一覧にして優先度をつける
必要な機能は、一覧にして優先度をつけます。優先度は、「必ず必要」「あると助かる」「将来でよい」の三段階程度で十分です。優先度があれば、開発会社は「必ず必要な機能だけならこの金額、すべて含めるとこの金額」という段階的な見積もりを出しやすくなり、予算に合わせた範囲の調整ができるようになります。
機能一覧の作り方と、見積もりに適した粒度の考え方は、機能一覧表の作り方で詳しく説明しています。
あわせて、参考になる既存のサービスや画面があれば、名前や画面の写真を添えます。「このサービスの予約画面のような流れ」と伝えるだけで、文章よりも正確に意図が伝わることがよくあります。
既存システム・予算感・スケジュールの伝え方
既存システムとデータ
既存のシステムやツールと連携する場合、またはデータを移行する場合は、次の情報を準備します。
- 連携するシステムやサービスの名前と、連携したい内容（何のデータを、どちらからどちらへ、どのくらいの頻度で）
- 連携先のシステムに、外部からデータをやり取りする仕組みがあるか（分からなければ、分からないと書く）
- 移行するデータの種類、件数のおおよその規模、現在の保存形式（表計算ソフト、旧システムなど）
- データの状態（重複や表記の揺れが多いか、整理されているか）
連携と移行は、見積もりの中で不確かさが大きくなりやすい部分です。分からないことは分からないと伝え、開発会社に確認の方法を相談しましょう。
予算感の伝え方
予算を伝えると足元を見られるのではないか、と心配して伝えない方もいます。しかし、予算感が分からないと、開発会社は理想的な構成で見積もるか、最低限の構成で見積もるかの判断ができず、提案の方向性がばらばらになります。
予算感は、「この範囲で検討している」という幅で伝えるのが現実的です。そのうえで、予算の中で何を優先するかを伝えれば、開発会社は範囲を調整した提案を出せます。予算が決まっていない場合は、「まずは規模感を知りたい」と目的を伝えたうえで、機能の優先度ごとの見積もりを依頼するとよいでしょう。
スケジュールの伝え方
希望する公開時期だけでなく、その理由も伝えます。「展示会で発表するため」「新年度の業務開始に合わせるため」など、動かせない理由があれば、開発会社はそれに合わせて範囲を絞る、段階的に公開する、といった提案ができます。動かせる時期であれば、そのことも伝えておくと、無理のない計画を提案してもらえます。
公開後の運用についての希望
見積もりの依頼では開発のことばかりに目が向きがちですが、公開後の運用についての希望も伝えておくと、提案の比較がしやすくなります。障害が起きたときにどの時間帯まで対応してほしいか、ソフトウェアの更新や小さな改修を継続的に頼みたいか、サーバーやクラウドの管理を任せたいか、といった点です。開発費が安くても、運用の費用や体制が自社に合わなければ、長い目で見て負担が大きくなります。開発の見積もりとは別に、運用の費用の考え方もあわせて提示してもらいましょう。
「決まっていないこと」を正直に伝える
見積もり依頼で意外に大切なのが、決まっていないことを明示することです。決まっていないことを隠したり、仮の内容を確定事項のように書いたりすると、後で変更が生じたときに追加費用の原因になります。
決まっていないことは、次のように書いておきます。
- 何が決まっていないか（例：会員の料金プランの数、管理者の権限の分け方）
- いつ頃に決まる見込みか
- 現時点での仮の想定（例：料金プランは三種類程度を想定）
こうしておけば、開発会社は仮の想定を前提に見積もり、前提が変わった場合の影響も説明できます。要件をどこまで固めてから依頼すべきか迷う場合は、要件定義書の書き方も参考にしてください。
見積もりを依頼してから比較するまでの手順
準備が整ったら、次の手順で見積もりを依頼し、比較します。
- 依頼資料をまとめる：八つの情報を数ページの資料にまとめます。規模が大きい場合や、複数社を正式に比較したい場合は、提案依頼書（RFP）の形にします。
- 依頼先を選ぶ：作りたいものに近い開発の経験がある会社を、数社選びます。多すぎると比較と対応の負担が大きくなります。
- 同じ資料を同じタイミングで渡す：比較のために、すべての会社に同じ資料を渡し、回答の期限をそろえます。
- 質問の機会を設ける：開発会社からの質問を受け付け、回答はすべての会社に共有します。打ち合わせの場を設けると、意図が伝わりやすくなります。
- 見積もりの形式をそろえてもらう：工程ごと、機能ごとの内訳、前提条件、含まれないものを書いてもらうよう依頼します。
- 内訳と前提条件で比較する：総額だけでなく、どの機能にどれだけの工数を見込んでいるか、何が含まれていないかを比べます。
- 不明点を確認して絞り込む：金額が大きく違う部分の理由を確認し、提案の内容と体制を含めて判断します。
正式な提案依頼書の書き方は、RFP（提案依頼書）の書き方で詳しく扱っています。
見積もり依頼前の準備チェックリスト
依頼資料を渡す前に、次の項目を確認しましょう。
- 目的が、作るものではなく解決したいことで書かれているか
- 何ができれば成功かが、具体的な状態で書かれているか
- 利用者の種類、人数、使う場面と端末が書かれているか
- 業務の流れが、例外の流れも含めて書かれているか
- 機能の一覧に、優先度がついているか
- 参考になるサービスや画面があれば、添えられているか
- 連携するシステムと、移行するデータの情報が書かれているか
- 予算感が、幅で伝えられているか
- 希望する公開時期と、その理由が書かれているか
- 決まっていないことと、その仮の想定が書かれているか
- 公開後の運用（保守、問い合わせ対応、改修）についての希望が書かれているか
- 見積もりに含めてほしい内訳と、回答の期限が書かれているか
- 秘密保持の扱いを、資料を渡す前に確認したか
架空の例：問い合わせ管理システムの見積もり依頼
ここでは架空の例で、見積もり依頼の準備を見てみます。
ある住宅設備の販売会社が、メールと電話で受けている顧客からの問い合わせを一元管理するシステムを作ろうとしていました。最初は「問い合わせ管理システムの見積もりがほしい」とだけ伝えたところ、開発会社によって金額に大きな差が出て、比較できませんでした。
そこで担当者は、依頼資料を作り直しました。目的を「問い合わせへの対応漏れをなくし、担当者が不在でも状況が分かるようにすること」とし、利用者は社内の対応担当と管理者であること、問い合わせの受付から対応完了までの流れと、他部署への転送や保留などの例外を書き出しました。機能は優先度をつけて一覧にし、既存の顧客台帳からのデータ移行、メールの自動取り込みの希望、予算の幅、繁忙期の前に使い始めたいという希望とその理由を添えました。顧客への自動返信の文面をどこまで作り込むかは未定であることも明記しました。
同じ資料を三社に渡した結果、各社の見積もりは同じ前提でそろい、ある会社は既存の問い合わせ管理サービスを活用する案を、別の会社は独自に開発する案を出してきました。担当者は、それぞれの長所と運用の費用を比較し、自社に合う案を選ぶことができました。
よくある失敗と避け方
「とりあえず概算を」と口頭だけで依頼する
打ち合わせで口頭で概要を伝え、概算の見積もりを依頼するケースです。会社ごとに受け取った情報がばらばらになり、比較ができません。短くてもよいので、資料にまとめて同じものを渡しましょう。
要望をすべて「必須」として伝える
社内から集めた要望を、優先度をつけずにすべて必須として伝えるケースです。見積もりは大きくなり、予算に合わせた調整もしにくくなります。社内で優先度を議論し、絞り込んでから依頼します。
金額の安さだけで選ぶ
最も安い見積もりを選んだ結果、必要な機能や作業が含まれておらず、後から追加費用が積み重なるケースです。前提条件と含まれないものを必ず確認し、他社の見積もりと範囲がそろっているかを確かめます。
依頼先が多すぎる
できるだけ多くの会社から見積もりを取ろうとして、十社以上に依頼するケースです。質問への回答や打ち合わせの負担が大きくなり、一社ごとの検討が浅くなります。経験や得意分野で事前に絞り込み、数社に依頼する方が、結果的に良い比較ができます。
秘密保持を確認せずに詳しい資料を渡す
精度の高い見積もりのために、顧客データの見本や社内の業務資料をそのまま渡してしまうケースです。見積もりの段階では、個人情報や機密情報を含まない形に加工した資料で十分なことがほとんどです。詳しい資料が必要な場合は、秘密保持の取り決めを結んでから渡しましょう。
よくある質問
Q. 見積もりを依頼する段階で、要件定義書は必要ですか？
概算見積もりの段階では、要件定義書がなくても構いません。本記事の八つの情報を数ページにまとめれば、精度の高い概算を出してもらえます。要件定義そのものを開発会社に依頼し、その成果をもとに詳細見積もりを出してもらう進め方も一般的です。
Q. 見積もりは無料で依頼できますか？
概算見積もりは無料で対応する開発会社が多いですが、要件の整理や詳細な調査を伴う見積もりは、有償となる場合もあります。依頼の前に、見積もりの範囲と費用の有無を確認しておきましょう。
Q. 予算を伝えると、その金額いっぱいの見積もりが出てきませんか？
その可能性を心配する場合は、予算の幅に加えて、機能の優先度ごとの見積もりを依頼するとよいでしょう。優先度ごとの内訳があれば、どこまで含めるかを発注側が判断できます。予算を伝えないことで提案の方向がばらばらになる不利益の方が、多くの場合は大きくなります。
Q. 見積もりの依頼資料は、どれくらいの分量が適切ですか？
概算見積もりであれば、数ページ程度にまとまっていれば十分です。分量よりも、八つの情報が漏れなく書かれていること、決まっていないことが明示されていることの方が重要です。詳細は打ち合わせで補足する前提で、まずは要点をそろえることを優先しましょう。
Otsumuに相談できること
作りたいものがある程度はっきりしていて、本記事の八つの情報を社内でまとめられるなら、見積もりの依頼は自社で十分に進められます。チェックリストを使って依頼資料を作り、同じ資料を数社に渡して比較してみてください。
一方で、目的は明確でも何を作ればよいかが分からない、社内の要望が多すぎて優先度がつけられない、そもそもシステムを作るべきか既存のサービスで足りるのかを判断したい、という場合は、見積もりを依頼する前の整理に外部の力を借りると、遠回りを避けられます。
Otsumuは、目的から逆算して必要な機能に絞り込み、構想から開発・運用・改善まで一気通貫で支援しています。開発全般はシステム開発、事業の構想段階からの整理は新規事業開発コンサルティングをご覧ください。計画を短期間で見直したい場合は、新規事業レビュー Sprint（48万円、1〜2週間、税別・参考価格）もご用意しています。それ以外の範囲は個別見積もりです。
「この内容で見積もりを依頼して大丈夫か」という確認だけでも構いません。30分の無料相談で、準備中の資料や状況をお聞かせください。秘密保持や契約条件は、相談時に確認のうえ合意して進めます。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01