「ITベンダーに見積もりを頼んだら、会社ごとに金額が3倍も違った」「何を頼みたいのか言葉にできないまま契約してしまった」。中小企業のDX支援の現場では、こうした声をよく耳にします。原因の多くはベンダーの良し悪しよりも、発注側の「頼み方」にあります。その頼み方を整理する文書がRFP（提案依頼書）です。
この記事では「RFP 書き方 中小企業」をテーマに、項目と記載例、相見積もりの比べ方、ベンダー評価のチェックリスト、契約時の注意、AI時代の注意点を、発注の進め方に絞って解説します。予算の立て方や基幹システム刷新そのものは別記事に譲ります。
RFP（提案依頼書）とは？書き方の6項目と記載例
RFPの意味とRFI・見積依頼との違い
RFPは「Request for Proposal」の略で、発注側が課題・要件・条件をまとめ、複数のベンダーに「この条件でどう解決しますか」と提案を求める文書です。似た言葉との違いは次のとおりです。
- RFI（情報提供依頼書）：どんな製品や会社があるかを広く集める段階の文書
- RFP（提案依頼書）：課題と条件を示し、解決策と見積もりの提案を求める文書
- 見積依頼：仕様がほぼ固まった前提で、金額と納期だけを尋ねる依頼
専任のIT担当者がいない中小企業ほど、A4で2〜4枚程度でも依頼内容を文書にする価値があります。口頭の説明は聞いた人ごとに解釈が変わりますが、文書なら各社の前提がそろい、社内の合意も取りやすくなります。IPAと経済産業省が2020年12月に公表した「情報システム・モデル取引・契約書（第二版）」も、発注側と受注側が認識をすり合わせる重要性を前提に整理された公的資料です。当協会のDX・AI情報サイトでも、DX推進の基本を解説しています。
背景・課題・目的を最初に書く
最も抜けやすいのが「なぜやるのか」です。機能一覧から書き始めると、ベンダーは言われた機能を作る提案しか出せません。次の3点を先頭に置きます。
- 背景：現状の業務の流れと困りごと（例：受注情報を紙とExcelで二重管理し、月末の集計に3日かかる）
- 課題：その結果起きていること（入力ミス、手戻り、属人化）
- 目的：解決後の姿（例：集計を1日以内にし、担当者不在でも回る状態）
現状の数字を「おおむね」でも入れておくと、後で効果を測る基準になります。
要件は「必須・希望・対象外」に分ける
すべてを同じ重さで並べず、3つに分けます。対象外を明記すると「そこも含まれると思っていた」という行き違いを防げます。
- 必須：会計ソフトとのデータ連携、担当者別の権限設定、スマートフォンからの閲覧
- 希望：取引先への自動メール通知、帳票のPDF出力
- 対象外：海外拠点での利用、基幹システムの全面刷新
予算・スケジュール・体制を正直に書く
予算を伏せると各社の前提がばらつき、比較が難しくなります。上限の目安と、初期費用・月額費用の区分を示しましょう。スケジュールには希望時期のほか、決算期や繁忙期など社内の制約も書き、自社の窓口担当者と週に使える時間の目安も明記します。発注側がどれだけ動けるかは、ベンダーにとって進め方を左右する重要情報です。
評価基準と提案依頼事項を明示する
評価項目と重み付け（例：課題理解、実績、費用、保守体制）を事前に示すと、ベンダーは何を重視すべきか分かり、社内への選定理由の説明もしやすくなります。提案書に必ず書いてほしい事項（実施体制、費用内訳、保守内容、類似実績、再委託の有無）も列挙します。
| RFPの項目 | 書く内容の例 | よくある抜け |
|---|---|---|
| 背景・課題・目的 | 現状フロー、困りごと、数字 | 「なぜ今やるのか」 |
| 要件 | 必須／希望／対象外 | 対象外の明記 |
| 予算 | 上限の目安、初期と月額の別 | 運用・保守費の想定 |
| スケジュール・体制 | 希望時期、社内の制約、窓口 | 自社側の作業時間 |
| 評価基準 | 項目と重み、選定の流れ | 重み付けの共有 |
RFP整理の活用事例と支援現場の課題感
見積もりが比べられない・要件が曖昧なまま発注される
当協会の支援現場で繰り返し感じるのは、見積もり比較の難しさです。ある会社は機能を絞った金額、別の会社は運用サポートまで含めた金額なのに、総額だけで比べてしまう。安い見積もりを選んだら「その作業は別料金」と言われた。そんな相談は少なくありません。もう一つ多いのが、「現場の使い勝手を良くしたい」程度の要件のまま発注に進むケースです。完成の基準が決まっていないため、途中で「思っていたものと違う」となり、追加費用や遅れにつながります。ベンダーの力量というより、頼む側がゴールを言葉にできていないことが原因である場合が多いと感じています。
活用事例（当協会の支援現場の傾向を匿名化した例）
以下は当協会の支援現場の傾向を匿名化して再構成した例で、特定企業の実例ではありません。効果は一例で、同様の結果を保証するものではありません。
- 製造業（従業員30名前後）：受発注がExcelと紙に分散。RFPで要件を整理し3社から提案を取得したところ、追加費用の考え方が各社で違うことが見え、内訳が明確な1社を選定。契約後の追加費用の議論が減る傾向が見られました。
- 小売・EC事業者（従業員15名前後）：「在庫と受注を一元管理したい」という漠然とした相談。RFP作成の過程で課題が「在庫の見える化」と「出荷作業の短縮」に絞られ、大規模開発ではなく既存クラウドサービスの設定とGoogle Workspace連携で足りる範囲が明確になりました。
- サービス業（従業員50名前後）：問い合わせ対応へのAI活用を検討。「誤回答時の確認体制」「入力してはいけない情報の範囲」を要件に入れたことで、各社のセキュリティやデータ取り扱いの姿勢の違いが比べやすくなりました。
RFPの効果は、ベンダーの絞り込みだけでなく、自社の課題が整理されることにもあります。
相見積もりの比べ方とベンダー評価チェックリスト
比較表で前提条件までそろえる
総額だけで比べず、前提をそろえた比較表を自社で作りましょう。
| 比較項目 | A社 | B社 | C社 |
|---|---|---|---|
| 初期費用（内訳） | 記入 | 記入 | 記入 |
| 月額・保守費用 | 記入 | 記入 | 記入 |
| 契約形態（準委任／請負） | 記入 | 記入 | 記入 |
| 対象範囲・対象外 | 記入 | 記入 | 記入 |
| 実施体制・再委託の有無 | 記入 | 記入 | 記入 |
| 保守・障害対応の範囲 | 記入 | 記入 | 記入 |
| データ返却・解約条件 | 記入 | 記入 | 記入 |
| 類似実績 | 記入 | 記入 | 記入 |
安すぎる・高すぎる見積もりの見方
金額差が大きいときは「何が含まれていないか」を確認します。安い見積もりには要件定義、テスト、データ移行、研修、保守が含まれていないことがあり、高い見積もりには余裕を持たせた予備費や将来拡張分が入っていることもあります。決めつけず、各社に含まれる作業と含まれない作業を書面で確認するのが確実です。開発費の水準は要件や規模で大きく変わるため、本記事では具体的な相場は示しません。同じRFPへの複数社の提案を比べるのが最も現実的です。
ベンダー評価チェックリスト
- こちらの課題を自社の言葉で言い直して確認してくれたか
- できないことやリスクも率直に説明したか
- 費用の内訳と、追加費用が発生する条件を示したか
- 類似の業種・規模の実績を示したか
- 担当者と再委託の有無を明示したか
- 検収の方法と成果物の範囲を説明したか
- 保守の窓口と対応時間が明確か
- データの扱いと、契約終了時の返却を説明したか
不安な点はそのまま質問しましょう。答え方そのものが、契約後の付き合い方を映します。
契約時の注意点とAI時代のベンダー選び
準委任と請負の違い
請負は完成した成果物に対して報酬を払い、完成責任をベンダーが負います。準委任は業務の遂行自体に報酬を払い、完成は必ずしも約束されません。要件が固まらない段階で請負にすると、仕様変更で揉めやすくなります。IPAのモデル契約書では、要件定義などを先に進めてから開発を契約する、段階を分けた考え方が示されています。どの形態が適切かは案件次第のため、弁護士など専門家に確認してください。
知的財産権・保守・データ返却
成果物の著作権の帰属や利用範囲、ベンダーが元から持つ既存部品の扱い、他社への改修依頼の可否は、契約前に決めておかないと乗り換え時に困ります。保守は対応時間、受付方法、障害時の目標対応時間、費用の内訳を確認し、契約終了時にデータをどの形式でいつまでに返却してもらえるかも定めます。クラウドサービスでは、エクスポート方法と解約後の保管期間も確認しましょう。支払条件など取引全般には下請法（近年改正が進んでいます）が関係する場合もあり、条項は専門家のレビューを受けることをおすすめします。
AIで作るシステムの品質担保と再委託
生成AIで開発を効率化するベンダーが増えています。それ自体は問題ではありませんが、AIが書いたコードを人がどこまでレビューし、どうテストしているかは確認したい点です。安い見積もりの裏に品質確認の薄さがあるかもしれません。「開発にAIを使うか、使うならレビューとテストはどう行うか」「自社の情報をAIサービスに入力することがあるか」「AI出力物の権利関係は契約でどう整理するか」を尋ねましょう。経済産業省は「AI・データの利用に関する契約ガイドライン」や、2025年2月公表の「AIの利用・開発に関する契約チェックリスト」を公開しており、参考になります。
再委託も同様に、誰がどこまで担当し、責任は誰が負い、自社データが再委託先に渡るのかを確認します。提案依頼事項に「再委託の有無と範囲」を入れておくと確実です。
RFPと発注のデメリット・注意点
作成に時間と労力がかかる
社内の現状整理や調整に数週間かかることもあります。まずは課題・目的・必須要件だけの簡易版から始めましょう。この時間は、契約後の手戻りの減少として戻ってきます。
細かく書きすぎると提案が狭まる
機能を固定しすぎると、ベンダーの工夫の余地がなくなります。「何を作るか」より「何を解決するか」を軸に書きましょう。
RFPや提案書の内容が契約の全部ではない
口頭の約束や提案書の記載は、そのまま契約内容になるとは限りません。契約書や仕様書に反映されているかを必ず確認します。
価格だけで選ぶと総コストが膨らむ
初期費用が安くても、保守が高い、追加開発が割高、解約時にデータが取り出せないなどで、結果的に高くつくことがあります。数年間の総コストと乗り換えやすさまで比べましょう。
RFPがあっても丸投げにはできない
要件の確認、画面の確認、受入テストに自社が関与できないと、現場に合わないものが納品されます。担当者の作業時間は事前に確保してください。
よくある失敗パターンと対策
機能一覧から書き始めて課題が抜ける
対策：背景・課題・目的を先頭に置き、現状の数字と目標を書きます。機能は目的のための手段として扱います。
予算を伏せて見積もりがばらつく
対策：上限の目安と初期・月額の区分を示し、保守や研修、データ移行を含めるか明記します。
総額だけで比較して範囲の違いに気づかない
対策：比較表で対象範囲、追加費用の条件、保守内容を同じ軸にそろえます。
契約形態や知財を確認せず署名する
対策：準委任・請負の別、成果物の権利、データ返却、再委託の条件を契約前に確認し、専門家にも相談します。
発注後に任せきりにする
対策：自社の窓口担当者を決め、定例会議と検収の日程を先に設定します。
まとめ
RFPは大企業だけのものではありません。中小企業こそ、背景・課題・目的、要件、予算、スケジュール、評価基準を簡潔に文書化することで、提案が比べやすくなり、契約後のトラブルも減らせます。相見積もりは前提条件をそろえて比べ、契約では準委任と請負、知財、保守、データ返却を確認し、AI時代には品質確認の方法と再委託の範囲にも注意しましょう。まずは「困っていること」と「どうなりたいか」を書き出すところから始めてください。契約条項の最終判断は専門家にご確認ください。