「複数社から見積もりを取って比較してほしい」と指示され、見積依頼書のテンプレートをダウンロードしたものの、手が止まっていないでしょうか。多くのテンプレートには「品名」「数量」「単価」といった欄が並んでいますが、システム開発では数量も単価も、依頼する側が事前に決められるものではありません。埋めるべき欄が埋まらないまま、何を書けばいいのか分からなくなってしまいます。
さらに厄介なのは、なんとか書き上げて各社に送ったあとです。届いた見積書の金額が2倍、3倍と開いていて、その差が「どちらが高いのか」なのか「そもそも見ている範囲が違うのか」すら判断できない。そして契約後になって「その機能は見積範囲外です」と追加費用を提示される。システム開発の見積もりで発注者が最も恐れているのは、この2つでしょう。
この問題の原因は、書き方のテクニックではなく、見積依頼書の目的の捉え方にあります。見積依頼書は「金額を教えてもらうための書類」ではなく、各社が同じ前提で計算できるように、条件をこちらから揃えて渡す書類です。前提が揃っていない依頼書に対して、開発会社は不明点をリスクとして金額に上乗せするか、自社に都合のよい前提を置いて安く見せるかのどちらかを選びます。どちらに転んでも、届いた見積書は比較できません。
逆にいえば、要件が完全に固まっていなくても、「何が決まっていて何が未定か」を明示できていれば、比較可能な見積もりは引き出せます。重要なのは情報の完璧さではなく、条件の揃え方です。
本記事では、見積依頼書（RFQ）の定義とRFP・RFIとの違いから、システム開発で記載すべき項目一覧、書きづらい項目の記載例とメール文例、そして見積もりの精度と比較可能性を上げる5つのコツ、相見積もり時の注意点までを順に解説します。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
見積依頼書（RFQ）とは？システム開発で作成する目的とタイミング
RFQ（Request for Quotation）とは何か
見積依頼書とは、発注者が発注先の候補企業に対して、見積書の作成・提出を依頼するための書類です。英語では Request for Quotation と呼ばれ、その頭文字を取って RFQ と表記されます。「Quotation（見積もり）を Request（依頼）する」という名前のとおり、依頼書の主目的は金額と内訳の提示を求めることにあります。
見積依頼書に法律で定められた様式はなく、企業ごとにExcelやWordのフォーマットを用意しているのが一般的です。ただし、様式が自由であることは「何を書いてもよい」という意味ではありません。書かれていない条件は、受け取った側が自分で仮定を置いて計算します。その仮定が各社でバラバラになることが、見積もりを比較できなくする最大の要因です。
なお、見積依頼書は法的な契約書ではないため、これを送っただけで発注義務は発生しません。あくまで「条件を提示して金額の提示を求める」段階の書類です。
システム開発で見積依頼書が重要になる理由
物品の購入であれば、型番と数量を書けば見積もりは一意に決まります。しかしシステム開発は、完成物が発注時点では存在せず、目にも見えません。開発会社が見積もるのは「その機能を作るために何人が何ヶ月かかるか」という工数であり、工数は依頼内容の解像度によって大きく変わります。
たとえば「顧客管理機能」という1行だけが書かれていた場合、A社は「一覧・登録・編集・削除の基本機能」と解釈して200万円と算出し、B社は「権限管理・履歴管理・CSV入出力・外部連携まで含む」と解釈して600万円と算出します。この2社の見積書を並べても、比較しているのは金額ではなく解釈の差です。発注者から見れば「A社が安い」と映りますが、実態は「A社は少ない範囲しか見ていない」だけかもしれません。
つまりシステム開発において、見積依頼書の記載内容がそのまま見積金額の精度を決めます。依頼書の精度を上げることは、届く見積書の精度を上げることと同義です。
見積依頼書を作るタイミングと省略してよいケース
見積依頼書を出すタイミングは、「解決したい業務課題と、実現したい機能の大枠が言語化できた段階」が目安です。要件定義書が完成している必要はありません。むしろ要件定義まで開発会社に依頼するケースも多いため、要件が固まるまで待っていると発注そのものが進みません。
作成タイミングの判断は、おおむね次のように整理できます。
自社の状況 | 見積依頼書の扱い |
|---|---|
課題も実現したい機能も曖昧。技術的に可能かも分からない | まだ早い。情報収集（RFI）や相談から始める |
課題は明確。実現したい機能の大枠は説明できるが、詳細仕様は未定 | 見積依頼書を出す標準的なタイミング。未定項目を明示して依頼する |
要件定義書・画面仕様書がある | 見積依頼書に添付する。最も精度の高い見積もりが得られる |
提案内容そのものを各社から募りたい | 提案依頼書（RFP）を作成し、その中に見積もり提出の指示を含める |
最後の行のとおり、RFPを作る場合は見積依頼書を単独で作らないケースもあります。RFPの中に「概算見積もりを提出すること」という提出要件を含めれば、依頼書を2通に分ける必要はありません。逆に、実現したいことがはっきりしていて提案は求めない場合は、RFPを作らず見積依頼書だけで進めるのが効率的です。
見積依頼書とRFP・RFI・要件定義書の違い
「RFPを作れと言われたが、見積依頼書と何が違うのか」という混乱は、発注担当者が最初につまずくポイントです。3つの依頼文書と要件定義書は、目的・出す相手・出す順番で整理すると区別しやすくなります。
RFI・RFP・RFQの作成順序と使い分け
文書 | 正式名称 | 目的 | 求めるもの | 出すタイミング |
|---|---|---|---|---|
RFI | Request for Information（情報提供依頼書） | 市場・技術・ベンダーの情報収集 | 実績・対応可能領域・技術情報・概算感 | 最初期。候補企業を絞り込む前 |
RFP | Request for Proposal（提案依頼書） | 課題に対する解決方法の提案募集 | 提案内容・体制・スケジュール・概算費用 | 候補企業を数社に絞った後 |
RFQ | Request for Quotation（見積依頼書） | 提示した条件での金額と内訳の提示 | 見積金額・内訳・工数・前提条件 | 依頼内容が固まった後 |
基本の流れは RFI → RFP → RFQ の順です。情報を集めて候補を絞り、提案を募って方向性を決め、最後に確定した条件で金額を出してもらう、という順序になります。
ただし、この3段階をすべて踏むのは大規模な調達の場合です。中小企業の業務システム開発では、RFIを省いてRFPから始める、あるいはRFPも作らず見積依頼書だけで2〜3社に依頼する、といった簡略化が一般的です。文書を増やすこと自体が目的ではないため、自社の規模と検討段階に合わせて選んでください。
RFPの構成要素や書き方については、RFP（提案依頼書）の書き方で詳しく解説しています。提案そのものを各社から募りたい場合は、そちらを参照してください。
要件定義書との違い（見積依頼書は要件定義前でも出せる）
要件定義書は、システムが満たすべき機能・性能・制約を確定させた設計上の文書であり、開発の成果物という性格を持ちます。一方で見積依頼書は、金額提示を求める依頼の文書です。役割がまったく異なります。
ここで押さえておきたいのは、要件定義書がなくても見積依頼書は出せるということです。実務上、要件定義自体を開発会社に有償で依頼するケースは珍しくありません。その場合は、見積依頼書に「本件では要件定義工程から依頼したい」と明記し、要件定義フェーズの費用と、その後の開発フェーズの概算費用を分けて提示するよう求めます。
経済産業省とIPA（情報処理推進機構）が公開している情報システム・モデル取引・契約書（第二版）でも、要件が固まっていない段階では工程ごとに個別契約を結ぶ「多段階契約」という考え方が示されています。要件定義の完了後に見積もりを見直す前提を最初から共有しておけば、不確実性を抱えたまま総額を固定する必要はなくなります。
自社が作るべき文書を判断するフローチャート
どの文書を作るべきかは、次の順で自問すると判断できます。
- 候補となる開発会社を知らない／技術的に実現可能か分からない → まずRFI、または複数社への相談・情報収集から始める
- 課題は明確だが、解決方法（システム構成・機能構成）を各社から提案してほしい → RFPを作成する。見積もりはRFPの提出要件に含める
- 実現したい機能の大枠が自社で説明でき、提案よりも金額を知りたい → 見積依頼書（RFQ）を作成する
- 要件定義書・仕様書がすでにある → 見積依頼書に添付して依頼する。最も比較しやすい見積もりが揃う
多くの中小企業のシステム刷新は、3番目に該当します。以降では、この見積依頼書の書き方を具体的に見ていきます。
見積依頼書の書き方｜記載すべき項目一覧（システム開発版）
見積依頼書の記載項目は、「どの業種でも共通する基本項目」と「システム開発だから追加すべき項目」の2層に分けて考えると、テンプレートの空欄が埋まらない問題を解消できます。
すべての業種に共通する基本の記載項目
まず、業種を問わず必要になる基本項目です。ビジネス文書としての体裁を整え、依頼の窓口を明確にする役割を持ちます。
項目 | 記載内容 | 注意点 |
|---|---|---|
宛先 | 依頼先の会社名・部署名・担当者名 | 会社宛は「御中」、担当者宛は「様」。併用しない |
発行日 | 見積依頼書を発行した日付 | 提出期限との整合を確認する |
発行者情報 | 自社の会社名・部署・担当者名・連絡先 | 質問窓口を兼ねるためメールアドレスは必須 |
件名 | 「〇〇システム開発に関する見積依頼書」 | 案件名を含め、他案件と区別できる表記にする |
挨拶文・依頼文 | 見積提出を依頼する旨の簡潔な本文 | 定型の時候の挨拶は省略して構わない |
依頼内容の概要 | 何に対する見積もりを求めるか | 詳細は別紙に分けてよい |
見積提出期限 | 提出してほしい日付（できれば時刻も） | 後述する目安を参照 |
提出方法・提出形式 | メール添付／PDF／指定様式など | 様式を指定すると比較しやすくなる |
見積有効期限の指定 | 「提出日から〇ヶ月以上」など | 検討期間より短いと再取得が必要になる |
秘密保持の扱い | NDA締結の要否、資料の取扱い | 業務情報を開示する場合は必須 |
問い合わせ窓口 | 質問の受付先と受付期間 | 窓口を一本化して認識齟齬を防ぐ |
システム開発で追加すべき記載項目
ここからが、汎用テンプレートには存在しない項目です。システム開発の見積もりは工数の見積もりであるため、工数を左右する情報を発注者側から先に提示します。
項目 | 記載内容 | 記載がないと起きること |
|---|---|---|
目的・背景 | 何の業務課題を解決したいのか | 手段だけが伝わり、代替案の提案が得られない |
対象業務・利用者 | 対象部署、想定利用者数、同時アクセス数 | 性能要件が読めず、各社が別の規模を想定する |
機能スコープ | 実現したい機能を箇条書きで列挙 | 機能の解釈幅がそのまま金額差になる |
除外範囲 | 今回は依頼しない範囲を明記 | 「含まれると思っていた」の食い違いが生じる |
非機能要件 | 性能・可用性・セキュリティ・運用条件 | 各社が異なる水準を前提に積算する |
既存システム・連携先 | 現行システム、連携が必要な外部サービス | 連携工数が丸ごと抜け落ちる |
データ移行の有無 | 既存データの移行対象・件数・形式 | 移行費用が後から追加費用として発生する |
想定納期・希望時期 | 稼働希望日、譲れない期日の有無 | 短納期対応の体制増強費が見えない |
保守運用の範囲 | 保守を含めるか、含める場合の期間と範囲 | ランニングコストが比較対象から漏れる |
開発体制・関与範囲 | 自社側の担当者と作業分担 | 発注者側の作業まで開発会社が積算する |
見積もりの内訳粒度 | どの単位で内訳を分けてほしいか | 「一式」で届き、比較も交渉もできない |
前提条件の明示要求 | 見積もりの前提を書面化するよう依頼 | 前提が不明のまま契約し、後で認識がずれる |
選定基準 | 金額以外に何を重視するか | 各社が価格だけで勝負し、提案の質が落ちる |
すべてを埋める必要はありません。現時点で決まっていない項目は空欄にせず「未定」と書くことが重要です。理由は後述の「決まっていない項目は『未定』と明示する」で解説します。
テンプレートやフォーマットに決まりはあるか
見積依頼書のフォーマットに、法律上の決まりはありません。ExcelでもWordでも、社内の稟議様式に合わせた形でも問題なく、テンプレート配布サイトの様式をそのまま使っても差し支えありません。
ただし、業種によっては業法が見積条件の提示を求めているケースがあります。代表例が建設業で、建設業法は注文者が請負契約の見積もりを依頼する際に工事内容などの条件を提示することを求め、建設業法施行令第6条では請負代金の額に応じた見積期間（500万円未満は1日以上、500万円以上5,000万円未満は10日以上、5,000万円以上は15日以上）が定められています。システム開発にはこのような法定の様式・期間の定めはありませんが、「金額規模に応じて検討時間を確保する」という考え方自体は参考になります。
また、見積依頼の段階ではなく発注の段階では、法律上の書面明示義務が生じる場合があります。2026年1月に施行された中小受託取引適正化法（旧・下請代金支払遅延等防止法。通称「取適法」）では、委託事業者は発注に際して給付の内容・代金の額・支払期日・支払方法などを、書面または電子メール等の電磁的方法で明示することが義務づけられています（公正取引委員会 リーフレット）。見積依頼書そのものは対象外ですが、発注書の記載事項は見積依頼書の内容と地続きになるため、見積段階から条件を文書化しておくと発注時の作業が楽になります。
結論として、フォーマット選びに時間をかける必要はありません。優先すべきは様式ではなく、前節の項目が漏れなく書かれているかどうかです。
見積依頼書の項目別の書き方と記載例
ここからは、発注者が特に書きづらい項目に絞って、そのまま自社の内容に置き換えられる記載例を示します。
目的・背景の書き方と記載例
目的・背景は、飛ばされがちですが最も費用対効果の高い項目です。ここに業務課題が書かれていると、開発会社は「その課題ならこの機能は不要」「この部分は既製サービスで代替できる」といった提案を返せます。逆に機能一覧だけが書かれていると、書かれたとおりに積算するしかなく、金額は膨らみます。
書き方のコツは、現状 → 課題 → 解決したい状態の3段構成にすることです。
【目的・背景】
現在、受注管理をExcelファイルで運用しており、営業部6名が個別のファイルを
更新しています。月末の集計時にファイルの統合作業が発生し、担当者1名が
毎月2日程度を集計作業に費やしています。また、入力ミスによる数量・金額の
不一致が月に数件発生しています。
本件では、受注情報を一元管理し、集計作業を自動化することで、月末の
集計作業をなくすことを目的としています。営業担当者が外出先からも
受注登録できる状態を目指しています。
「Excelをやめてシステム化したい」という手段ではなく、「月末の集計作業をなくしたい」という達成状態を書いている点がポイントです。
機能スコープと除外範囲の書き方と記載例
機能スコープは、見積金額を最も大きく左右する項目です。粒度が粗いと各社の解釈がばらつくため、機能名だけでなく「その機能で何ができる状態にしたいか」を1行添えます。
そして機能スコープ以上に効くのが、除外範囲です。「今回は依頼しない」と明記された範囲は、各社の見積もりから確実に外れます。書かれていなければ、含める会社と含めない会社に分かれます。
【機能スコープ（今回依頼する範囲）】
1. 受注登録機能
営業担当者が顧客名・商品・数量・金額・納期を登録できる
2. 受注一覧・検索機能
担当者別・期間別・顧客別に受注を絞り込んで表示できる
3. 月次集計機能
月次の受注金額を担当者別・商品別に集計し、CSV出力できる
4. ユーザー管理機能
管理者がユーザーの追加・削除と閲覧権限の設定を行える
【除外範囲（今回は依頼しない範囲）】
・在庫管理機能（次期フェーズで検討）
・会計システムとの自動連携（当面はCSV手動取込で運用）
・顧客向けの外部公開画面
・スマートフォン専用アプリの開発（ブラウザ対応で可）
・既存データの移行（別途相談とし、本見積には含めない）
除外範囲は、思いつくものをすべて書く必要はありません。「あってもおかしくないが今回は不要なもの」を書くのが効果的です。上の例では、受注管理システムに在庫管理や会計連携が含まれると考える会社があり得るため、あえて明記しています。
非機能要件・前提条件の書き方と記載例
非機能要件は、機能そのものではなく「どの程度の品質・性能で動く必要があるか」を指します。専門的に見えますが、発注者が答えられる範囲だけで十分に効果があります。
IPAが公開している非機能要求グレードでは、非機能要求が「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6項目に整理されています。この分類のうち、発注者が答えやすい項目に絞って記載します。
【非機能要件・前提条件】
・利用者数: 社内20名（同時アクセスは最大10名程度を想定）
・データ量: 受注データ 年間約12,000件、5年分の保持を想定
・稼働時間: 平日8:00〜20:00。夜間・休日の停止は許容する
・障害時の復旧: 翌営業日中の復旧で可。24時間対応は不要
・アクセス制限: 社外からのアクセスを許可する。IP制限は不要
・認証方式: ID・パスワード認証で可。多要素認証の要否は未定
・利用端末: Windows PC（Chrome）およびiPhone/Androidのブラウザ
・インフラ: クラウド利用を想定。特定のクラウド指定はなし
・既存システム連携: 現時点で連携先なし
「24時間対応は不要」「多要素認証の要否は未定」のように、要らないものと未定のものを明示している点が重要です。可用性やセキュリティの要求水準は、上げれば上げるほど構成が複雑になり費用が増えます。要らないと書かれていなければ、各社は自社の標準構成で見積もるため、水準の違いがそのまま金額差として現れます。
見積条件（内訳の粒度・工数・有効期限）の指定方法
届いた見積書が「システム開発一式 800万円」の1行だった、という状況を避けるには、依頼書の側で内訳の出し方を指定します。金額そのものは各社の自由ですが、書き方の様式は依頼側が決めてよい項目です。
【見積提出時のお願い】
1. 内訳は下記の単位で分けてご記載ください。
（1）要件定義 （2）設計 （3）開発・実装 （4）テスト
（5）データ移行 （6）導入・教育 （7）保守運用（月額）
2. 各項目について、想定工数（人日または人月）と単価を併記してください。
3. 開発フェーズについては、機能単位の内訳も可能な範囲でご記載ください。
4. 本見積の前提条件（想定している範囲・体制・発注者側の作業分担など）を
明記してください。前提が変わると金額が変動する箇所があれば、
その旨も併せてご記載ください。
5. 保守運用費用は月額と年額を分けてご記載ください。
6. 見積書の有効期限は、提出日から3ヶ月以上としてください。
7. ご不明点がある場合は、〇月〇日までに下記窓口へご連絡ください。
とくに 2 と 4 の効果が大きく、工数と単価が分かれていれば「金額差が単価の差なのか、想定している作業量の差なのか」を判別できます。前提条件が書面化されていれば、契約後の「見積範囲外です」という主張に対して、事前に合意した前提を根拠に議論できます。
届いた見積書をどう読み解くかについては、システム開発の見積もり精度で解説しています。
見積依頼書を送付するメールの文例
見積依頼書は、メールに添付して送るのが一般的です。メール本文には、依頼の要点と期限、質問窓口を簡潔に書けば十分です。
件名: 【見積依頼】受注管理システム開発に関する見積のお願い（株式会社〇〇）
株式会社△△
営業部 〇〇様
お世話になっております。
株式会社〇〇 経営企画部の〇〇と申します。
このたび、当社の受注管理システムの新規開発を検討しており、
貴社にお見積りをお願いしたくご連絡いたしました。
依頼内容の詳細は、添付の見積依頼書をご確認ください。
■ 件名: 受注管理システム開発
■ 見積提出期限: 20XX年〇月〇日（〇）17:00
■ 提出方法: 本メールへの返信にPDFを添付
■ 質問受付期限: 20XX年〇月〇日（〇）17:00
■ 質問窓口: 〇〇（本メールアドレス宛）
なお、本件は複数社にお見積りをお願いしております。
ご検討の結果、ご辞退される場合もその旨ご一報いただけますと幸いです。
ご不明な点がございましたら、お気軽にお問い合わせください。
何卒よろしくお願いいたします。
--
株式会社〇〇 経営企画部
〇〇 〇〇
TEL: 00-0000-0000
Mail: xxx@example.com
複数社に依頼している旨を伝えるかどうかは判断が分かれますが、明記しておくほうが誠実であり、各社も検討の温度感を掴みやすくなります。隠していても、後から分かったときの印象のほうが悪くなります。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
見積依頼書の精度を上げる5つのコツ
ここからが、届く見積もりの質を左右する部分です。項目を埋めるだけでは足りない理由から順に説明します。
開発会社が見積もりにバッファを積む理由
開発会社が見積もりを作るとき、内部では「この依頼内容で、どこまでの作業が発生し得るか」を検討しています。依頼書に書かれていない部分は、次のいずれかの扱いになります。
- リスクとして金額に織り込む: 「連携先が後から出てくるかもしれない」「利用者数がもっと多いかもしれない」といった不確実性を、バッファとして工数に上乗せする
- 自社に都合のよい前提を置いて除外する: 「連携はないものとする」「移行は含まない」と仮定し、金額を抑えて提示する
前者を選べば金額は上振れし、後者を選べば見た目の金額は下がりますが、契約後に「範囲外」として追加費用が発生します。発注者が最も恐れている2つの事象は、どちらも「依頼書に書かれていない項目」から生まれます。
したがって、精度を上げる打ち手は一貫しています。不明点を減らし、残った不明点は「不明である」と明示する。以下の5つはその具体策です。
コツ1 決まっていない項目は「未定」と明示する
空欄と「未定」は、受け取る側にとってまったく別の情報です。空欄は「聞き漏らしたのか、不要なのか、忘れているのか」が分からないため、各社が別々の推測をします。「未定」と書かれていれば、全社が同じ「未定」という条件のもとで見積もります。
さらに一歩進めて、未定の項目には決まる時期と決め方を添えると効果が上がります。
・多要素認証の要否: 未定（要件定義フェーズで決定予定）
・データ移行の対象年数: 未定（現在調査中。〇月中に確定予定）
・利用部署の追加: 未定（初年度は営業部のみ。2年目以降に拡大の可能性あり）
「未定だが、いつ・どう決まるか」まで書かれていれば、開発会社は「決定後に再見積もり」という前提を置けるため、過剰なバッファを積む必要がなくなります。
未定項目が多すぎて依頼書が成立しないと感じる場合は、無理に総額の見積もりを求めず、要件定義フェーズだけを切り出して依頼する方法もあります。前述の多段階契約の考え方です。
コツ2 見積もりの内訳粒度を指定する
内訳の粒度を指定しないと、各社が自社の標準フォーマットで提出してきます。A社は工程別、B社は機能別、C社は「一式」となれば、表を並べても比較になりません。
指定すべき粒度は、次の3点です。
軸 | 指定内容 | 比較で分かること |
|---|---|---|
工程別 | 要件定義／設計／開発／テスト／移行／導入／保守 | どの工程を厚く見ているか、抜けている工程はないか |
機能別 | 機能スコープに列挙した機能ごとの内訳 | どの機能の解釈が各社でずれているか |
数量 | 想定工数（人日・人月）と単価の併記 | 金額差の原因が単価か作業量かの判別 |
とくに「工数と単価の併記」を求めておくと、金額差の分解ができます。総額が2倍違っても、単価が同水準で工数が2倍なら、それは想定している作業範囲の差です。この場合に比較すべきは金額ではなく、なぜ工数が違うのかという中身になります。
コツ3 前提条件と除外範囲を発注者から先に書く
前提条件は、開発会社に書かせるだけでなく、発注者からも先に提示します。順序が重要で、こちらから先に出すことで各社の前提を強制的に揃えられます。
発注者側から書いておきたい前提条件の例を挙げます。
- 発注者側の作業分担: 「テストデータの準備は発注者が行う」「業務ヒアリングには週1回2時間、担当者2名が参加できる」
- 意思決定体制: 「仕様の承認者は経営企画部長。承認には3営業日を見込む」
- 提供資料: 「現行業務フロー図と現行Excelファイルは提供可能」
- 制約: 「社内ネットワークからのアクセスにはVPNが必要」「稼働は〇月末が必達」
発注者側の作業が明記されていないと、開発会社はそれらの作業も自社が担う前提で工数を積むか、逆に発注者が担う前提で積まずに、後から追加費用として提示することになります。どちらも避けたい結果です。
除外範囲についても同様で、「今回は依頼しない」と書かれた範囲は各社の見積もりから確実に外れます。この一手間が、契約後の「それは見積範囲外です」を最も効率よく減らします。
コツ4 予算と優先順位をどこまで開示するか決める
「予算を書くと満額の見積もりが返ってくるのではないか」という懸念から、予算欄を空欄にする発注者は少なくありません。しかし予算を完全に伏せると、実現不可能な提案や、逆に過剰な構成の提案が返ってくるリスクがあります。500万円の予算に対して2,000万円の見積もりが3社から届けば、検討期間をまるごと失うことになります。
現実的な選択肢は3つです。
開示方法 | 記載例 | 向いているケース |
|---|---|---|
上限を明示 | 「予算上限は〇〇万円です」 | 予算が確定しており、その範囲での実現方法を知りたい |
レンジで提示 | 「〇〇万円〜〇〇万円を想定しています」 | 概算感を伝えつつ、提案の幅も残したい |
非開示＋優先順位を提示 | 予算は書かず、機能の優先順位（必須／推奨／任意）を明示 | 相場観がなく、まず金額を知りたい |
3つ目を選ぶ場合でも、機能の優先順位は必ず書いてください。優先順位が示されていれば、開発会社は「必須機能のみの構成」と「推奨機能まで含めた構成」を分けて提示できます。これは予算を伏せたまま、予算調整の余地を作る方法です。
【機能の優先順位】
必須: 受注登録、受注一覧・検索、月次集計
推奨: ユーザー権限管理、CSV出力
任意: ダッシュボード表示、通知メール配信
必須機能のみの構成と、推奨機能まで含めた構成を分けてご提示ください。
コツ5 質問受付期間を設けて回答を全社に共有する
どれだけ丁寧に書いても、依頼書だけで疑問がゼロになることはありません。質問が出ること自体は前提とし、その扱い方を依頼書の中で決めておきます。
依頼書に設定しておきたいのは、次の3つのルールです。
- 質問受付期限: 提出期限の1週間前など、回答してから見積もりを作る時間が残る日程にする
- 質問窓口の一本化: 担当者を1名に絞る。複数の窓口があると回答が食い違う
- 回答の全社共有: 「いただいたご質問と回答は、質問者名を伏せて依頼先全社に共有します」と明記する
3つ目が特に重要です。A社だけが質問して得た情報でA社だけが精度の高い見積もりを出せる状態では、比較の公平性が失われます。回答を全社に共有すれば、全社が同じ情報量で見積もることになり、比較可能性が担保されます。加えて、A社の質問がB社の見落としに気づかせる効果もあります。
質問が1件も来なかった場合は、依頼書が完璧だったのではなく、各社が質問せずに自社の前提で処理した可能性を疑ってください。その場合、見積書の「前提条件」欄を注意深く読み比べる必要があります。
相見積もりで見積依頼書を使うときの注意点
見積依頼書の内容が整っていても、運用の仕方によって比較可能性は簡単に崩れます。複数社へ依頼する際の注意点を整理します。
全社に同じ依頼書を渡す
当然のようでいて、崩れやすいポイントです。ありがちなのは、1社目に送った後で説明不足に気づき、2社目以降には補足を加えた依頼書を送ってしまうケースです。この時点で1社目だけが不利な条件で見積もることになり、比較の前提が壊れます。
依頼書を修正した場合は、すでに送付済みの会社にも必ず改訂版を送り直します。その際は改訂日と変更点を明記し、必要なら提出期限を延長してください。口頭での補足説明も同様で、1社に説明した内容は文書化して全社に共有します。
依頼社数は3社前後が現実的です。2社では比較の軸が作りにくく、5社を超えると質問対応と見積書の読み比べだけで担当者の工数が膨らみます。事前にRFIや簡易的な情報収集で候補を絞り込んでから、3社程度に依頼するのが効率的です。
見積提出期限は何日取るべきか
システム開発の見積提出期限に、法律上の定めはありません。ただし短すぎる期限には明確な弊害があります。
期限が短いと、開発会社は詳細を詰める時間が取れないため、不確実性をバッファとして積んだ安全側の金額を出すか、そもそも辞退します。「急いでいるから3日で」と設定した結果、最も検討してほしかった会社に辞退され、金額も上振れするのでは本末転倒です。
参考になるのが建設業の考え方です。前述の建設業法施行令第6条は、予定価格500万円未満で1日以上、500万円以上5,000万円未満で10日以上、5,000万円以上で15日以上の見積期間を確保するよう定めています。金額規模に応じて検討時間を確保するという発想は、システム開発にもそのまま当てはまります。
これを踏まえた実務的な目安は次のとおりです。
想定規模 | 提出期限の目安 | 備考 |
|---|---|---|
小規模（〜500万円程度） | 1〜2週間 | 要件が明確なら1週間でも可 |
中規模（500万〜3,000万円程度） | 2〜3週間 | 質問受付期間を1週間確保する |
大規模（3,000万円以上） | 3〜4週間以上 | 提案を伴う場合はさらに余裕を持たせる |
なお、期限に日付だけでなく時刻まで書いておくと、当日中の到着遅れをめぐる曖昧さを避けられます。
依頼時・辞退時に守りたいマナー
相見積もりは開発会社にとって、無償で数日から数週間の工数を投じる作業です。この前提を踏まえた対応が、結果的に良い提案を引き出します。
依頼時に守りたい点は次のとおりです。
- 相見積もりであることを事前に伝える: 社数まで開示する必要はありませんが、複数社に依頼している旨は伝えます
- 選定基準を示す: 「金額のみで判断するのか」「保守体制や実績も評価するのか」を書いておくと、価格以外の提案が出てきます
- 選定時期を伝える: 「〇月中旬に選定結果をご連絡します」と書いておけば、各社が社内の要員計画を立てやすくなります
そして最も忘れられがちなのが、不採用の連絡です。選定した1社にだけ連絡し、他社を放置するのは避けてください。不採用の連絡は簡潔で構いませんが、可能な範囲で理由を添えると、次回以降の関係につながります。また、他社の見積金額をそのまま伝えて値下げ交渉に使うことは、信頼を大きく損なうため避けるべきです。
届いた見積書をどの軸で比較し、どう判断するかについては、システム開発の見積もり比較で詳しく解説しています。本記事の内容は、その比較が成立する状態を作るための前工程にあたります。
見積依頼書のよくある失敗例と回避策
作成した見積依頼書を送る前に、次の表で自己点検してください。左端の「症状」に心当たりがある場合、原因は依頼書の記載にあります。
症状 | 原因 | 回避策 |
|---|---|---|
各社の金額が2〜3倍以上開く | 機能スコープの粒度が粗く、各社が別の範囲を想定している | 機能ごとに「何ができる状態か」を1行添える。除外範囲を明記する |
契約後に「見積範囲外」の追加費用が発生する | 除外範囲と前提条件が書かれておらず、各社が都合のよい前提で積算した | 除外範囲を発注者から先に書く。前提条件の書面化を提出要件にする |
見積書が「一式」の1行で届く | 内訳の粒度を指定していない | 工程別・機能別の内訳と、工数・単価の併記を提出要件にする |
提出期限までに見積もりが揃わない／辞退される | 期限が短すぎる、質問窓口がなく確認が取れない | 規模に応じて2〜4週間確保する。質問受付期限と窓口を明記する |
想定より大幅に高い見積もりばかり届く | 未定項目が空欄のままで、各社がリスクバッファを積んでいる | 未定項目は「未定」と明記し、決まる時期と決め方を添える |
提案の中身がなく価格勝負になる | 目的・背景と選定基準が書かれていない | 業務課題を現状→課題→解決したい状態の3段で書く。選定基準を示す |
保守費用が比較できない | 保守運用の範囲・期間の指定がない | 保守範囲と期間を指定し、月額・年額を分けて記載するよう求める |
契約直前に仕様の認識違いが判明する | 発注者側の作業分担が不明で、双方が相手の作業と想定していた | 発注者側の担当作業・意思決定体制・提供資料を前提条件に書く |
検討中に見積もりの有効期限が切れる | 有効期限の指定がなく、1ヶ月で失効した | 「提出日から3ヶ月以上」など、検討期間より長い有効期限を指定する |
すべてに対策できていなくても構いません。ただし上から2つ、「機能スコープの粒度」と「除外範囲・前提条件」は、金額差と追加費用の両方に直結します。この2点だけは、送信前に必ず確認してください。
まとめ｜見積依頼書は「同じ前提で比較できるか」で決まる
見積依頼書（RFQ）は、金額を教えてもらうための書類ではなく、各社が同じ前提で計算できるよう条件を揃えて渡す書類です。この視点に立つと、テンプレートの空欄を埋める作業から、比較可能な状態を設計する作業へと目的が変わります。
本記事の要点を整理します。
- 見積依頼書（RFQ）は金額と内訳の提示を求める文書であり、提案を募るRFP・情報収集のRFIとは目的が異なる。要件定義書がなくても作成できる
- 記載項目は基本項目に加えて、システム開発特有の項目（目的・背景／機能スコープ／除外範囲／非機能要件／既存システム連携／保守範囲／内訳粒度の指定など）を足す
- 目的・背景は「現状→課題→解決したい状態」の3段で書き、機能スコープには各機能で実現したい状態を1行添える
- 決まっていない項目は空欄にせず「未定」と書き、決まる時期と決め方を添える
- 内訳の粒度と、工数・単価の併記を提出要件に含めると、金額差の原因を分解できる
- 前提条件と除外範囲は発注者側から先に提示する。これが追加費用リスクを最も効率よく減らす
- 相見積もりでは全社に同一の依頼書を渡し、質問への回答も全社に共有する。提出期限は規模に応じて2〜4週間を確保する
次のアクションとして、作成中の依頼書を「見積依頼書の書き方｜記載すべき項目一覧（システム開発版）」の2つの表と、「見積依頼書のよくある失敗例と回避策」の症状一覧で点検してみてください。書けていない項目のうち、決まっていないものは「未定」と書き直すだけでも、届く見積もりの前提は揃い始めます。
関連情報
発注前の要件整理や依頼書作成の進め方をまとめた資料を、お役立ち資料ページで公開しています。社内での検討やベンダーとのすり合わせにご活用ください。
見積依頼の内容が固まりきらない段階でも、実現したいことの整理からご相談いただけます。ご検討中の方はお問い合わせフォームからお問い合わせください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 見積依頼書で決まっていない項目はどう書けばいいですか？
空欄にせず「未定」と明記してください。空欄だと各社が「聞き漏らしたのか、不要なのか」を別々に推測しますが、「未定」と書けば全社が同じ前提で見積もれます。さらに決まる時期と決め方を添えると、開発会社は再見積もりを前提にできるため、過剰なリスクバッファを積む必要がなくなります。
- 見積依頼書とRFP（提案依頼書）はどちらを先に作ればよいですか？
実現したい機能の大枠を自社で説明でき、提案より金額を知りたい場合は見積依頼書を直接作成します。解決方法（システム構成・機能構成）の提案自体を募りたい場合はRFPを作成し、「概算見積もりを提出すること」を提出要件に含めれば、依頼書を2通に分ける必要はありません。
- 契約後に「見積範囲外」の追加費用を請求されないためにはどうすればいいですか？
除外範囲と前提条件を発注者側から先に依頼書へ明記し、前提条件の書面化を見積提出時の要件にしてください。除外範囲を明記すれば各社の見積もりから確実に外れ、前提条件が書面化されていれば契約後に「範囲外」と主張された際も、事前に合意した内容を根拠に議論できます。
- 相見積もりは何社くらいに依頼するのが適切ですか？
3社前後が現実的です。2社では比較の軸が作りにくく、5社を超えると質問対応と見積書の読み比べだけで担当者の工数が膨らみます。RFIや簡易的な情報収集であらかじめ候補を絞り込んでから、3社程度に依頼するのが効率的です。
- 見積提出期限は何日くらい確保すればよいですか？
想定規模に応じて小規模で1〜2週間、中規模で2〜3週間、大規模で3〜4週間以上を目安にしてください。期限が短すぎると開発会社は安全側の高い金額を出すか辞退します。日付だけでなく時刻まで指定し、提出期限の1週間前を目安に質問受付期間も確保してください。
