RFPの書き方｜中小企業はA4 7枚で足りる。12項目テンプレートと「見積もれないRFP」の5つの穴

「同じ内容で3社に見積もりを頼んだのに、320万円・780万円・1,500万円と返ってきた」——中小企業のシステム発注では、珍しくない話です。

これはベンダーの価格差ではありません。3社が別々の前提で見積もったから起きます。その前提を揃えるための文書が、RFP（提案依頼書）です。

そして、RFPの出来は完成後の結果にまで響きます。JUAS（日本情報システム・ユーザー協会）の『企業IT動向調査2026』（2026年4月公開・2025年度調査）で、システム開発が予定どおりに終わらなかった企業に理由を聞いたところ、品質・予算・工期のすべてで「計画時の考慮不足」が最多水準でした（品質48.8%、予算51.0%、工期52.5%）。

開発が始まってからの頑張りではなく、発注する前の準備で結果の大半が決まっているということです。

ただ、中小企業にとって悪い話ばかりではありません。同じ調査では、プロジェクト規模が小さいほど結果が良好でした。

プロジェクト規模	品質に「不満」	予算「超過」	工期「遅延」
10人月未満	5.4%	6.0%	9.6%
50〜100人月未満	15.6%	19.6%	25.4%
500人月以上	29.6%	42.2%	47.8%

なお「人月」は、エンジニア1人が1か月かけて行う作業量を表す単位です。単価は発注先や技術者の経験によって幅がありますが、おおむね1人月80万〜150万円程度。つまり最も成績のよい「10人月未満」とは、おおよそ800万〜1,500万円を下回る規模の案件を指します。たとえば300万円規模の案件なら2〜4人月ほどで、この最も失敗の少ない帯にすっぽり収まります。

小さく区切って発注できる会社は、構造的に有利な位置にいます。RFPは、その有利さを実際の成果に変えるための道具です。

この記事では、開発を受注する側——実際にRFPを受け取って見積もりを出す立場から、①中小企業に必要なRFPの分量と12項目、②そのままコピーして使えるひな形、③受け取った側が見積もりを出せなくなる5つの穴、を解説します。

RFPとは？RFI・要件定義書との違い

RFP（Request For Proposal＝提案依頼書）とは、発注側が「解決したい課題」と「実現したい状態」を示し、ベンダーに解決策の提案を求める文書です。

混同されやすい3つの文書を並べると、役割の違いがはっきりします。

	RFI（情報提供依頼書）	RFP（提案依頼書）	要件定義書
書く人	発注側	発注側	発注側とベンダーが共同で
タイミング	ベンダーを探す段階	提案・見積もりを依頼する段階	契約後、開発の直前
目的	市場や各社の情報を集める	比較可能な提案を集める	作るものを確定させる
書く内容	「こんな課題があるが、御社は何ができますか」	「この課題をこう解決したい。方法を提案してください」	「この画面に、この項目を、この条件で」
分量の目安	A4 1〜3枚	A4 5〜10枚	数十〜数百ページ

ここでいちばん重要なのは、RFPは要件定義書ではないということです。

RFPに書くのは「何に困っていて、どうなりたいか」です。「どう作るか」はベンダーが提案する側であり、発注側が書く必要はありません。「画面の項目まで決めないと書けない」と思い込むと、いつまでも着手できません。

実際、作るものを確定させる作業（要件定義）はRFPの後、契約してからベンダーと一緒に行う工程です。IPA（情報処理推進機構）も発注者向けに『ユーザのための要件定義ガイド 第2版』を公開していますが、これはRFPを出した後の話だと理解しておいてください。

中小企業のRFPは何枚必要か｜結論：A4 5〜10枚

RFPで挫折する中小企業の多くは、大企業向けのテンプレートをダウンロードしたところから躓いています。数十ページの様式を前にして、「ここまで書けない」と手が止まる。あるいは、埋めるために当たり障りのない文章を並べて、中身のない分厚い文書ができあがる。

分量の判断基準はひとつだけです。

ベンダーが、追加のヒアリングなしで概算見積もりを出せるだけの情報が揃っているか。

この基準を満たすなら、A4で5枚でも構いません。目安は次のとおりです。

想定予算	RFPの分量	力を入れる項目
〜100万円程度	A4 2〜3枚（メール本文でも可）	課題・やりたいこと・予算・時期
100〜500万円程度	A4 5〜7枚	上記＋業務量・スコープの線引き・非機能要件
500〜2,000万円程度	A4 8〜15枚	上記＋現行システム構成・移行・体制・評価基準
2,000万円以上	A4 20枚〜	上記＋段階分けの計画、外部の支援も検討

厚さは品質と関係ありません。3枚のRFPでも見積もれるものは見積もれますし、30枚あっても肝心の情報が抜けていれば見積もれません。何が「肝心の情報」かは、後半の「見積もれない5つの穴」で具体的に挙げます。

RFPに書く12項目｜そのまま使えるテンプレート

中小企業のRFPは、次の12項目で足ります。それぞれ「何を書くか」と、実際に受け取ってよくある悪い例・良い例を並べます。

#	項目	書くこと
1	提案依頼の趣旨・自社概要	会社概要（業種・従業員数・拠点数）、今回何を依頼したいのか
2	現状と課題	いま業務がどう回っていて、何が問題か。実際に困っている場面
3	目的・達成したい状態	導入後にどうなっていたいか。可能なら数字で
4	対象範囲（スコープ）	対象の業務・部署・拠点。今回やらないことも明記
5	現行の業務と システム	業務の流れ、使用中のソフト・機器、データの持ち方
6	実現したいこと（機能要求）	やりたいことを箇条書き。必須／できればを分ける
7	非機能要件	性能・可用性・セキュリティ・保守など（後述の6項目）
8	制約条件	既存システムとの連携、社内ルール、法規制、使用端末
9	予算	初期費用と年間の運用費。レンジで開示する
10	スケジュール	稼働希望時期と、そこから逆算した提案・選定の日程
11	体制・役割分担	自社の窓口・決裁者、自社側が出せる工数
12	提案依頼事項・評価基準・提出要領	提案書に何を書いてほしいか、何で選ぶか、提出先と期限

コピーして使えるRFPひな形

以下をWordなどに貼り付けて、〔　〕の中を自社の内容に置き換えてください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
〔システム名〕構築に関する提案依頼書（RFP）
〔会社名〕　〔作成日〕
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 提案依頼の趣旨
　当社は〔業種〕を営む従業員〔　〕名の企業です。
　このたび〔対象業務〕の〔刷新／新規導入〕を検討しており、
　貴社に提案と概算見積もりをお願いいたします。

2. 現状と課題
　(1) 現在の進め方：〔誰が・何を使って・どう処理しているか〕
　(2) 課題：
　　・〔例〕受注データを基幹システムとExcelに二重入力しており、
　　　　　 月あたり約〔　〕時間を要している
　　・〔例〕在庫数がリアルタイムで見えず、月〔　〕件の欠品が発生している

3. 目的・達成したい状態
　・〔例〕二重入力をなくし、受注処理の作業時間を月〔　〕時間削減する
　・〔例〕在庫を当日中に把握できる状態にする
　※ 導入後、上記をどう測るかも記載

4. 対象範囲（スコープ）
　(1) 今回の対象：〔対象業務・部署・拠点・利用者数〕
　(2) 今回は対象外：〔例〕会計システムの刷新、〔例〕店舗向けPOS連携
　(3) 将来的に検討：〔例〕モバイル対応（次フェーズ）

5. 現行の業務とシステム
　(1) 業務の流れ：〔受注→出荷指示→在庫引当→請求 など〕
　(2) 現行システム：〔製品名・バージョン・導入年・保守の有無〕
　(3) データ：〔件数／年、保有年数、形式（Excel・CSV・DB）〕
　(4) 利用環境：〔PC台数・OS・ネットワーク・拠点〕

6. 実現したいこと（機能要求）
　【必須】
　　・〔例〕受注情報を1回の入力で在庫・請求に反映できること
　　・〔例〕〔既存システム名〕とデータ連携できること
　【できれば】
　　・〔例〕スマートフォンから在庫を照会できること

7. 非機能要件
　(1) 可用性：〔例〕平日8:00〜20:00は稼働。停止は月次で30分以内
　(2) 性能・拡張性：同時利用〔　〕名、月間処理〔　〕件、3年後は〔　〕件想定
　(3) 運用・保守：〔誰が運用するか／障害連絡の受付時間／バックアップ〕
　(4) 移行：〔既存データを何年分・どの範囲で移行するか〕
　(5) セキュリティ：〔個人情報の有無／権限区分の数／社外アクセスの有無〕
　(6) システム環境：〔クラウド希望／自社設置／制約となる既存機器〕

8. 制約条件
　・〔例〕〔既存システム名〕は継続利用するため、連携が必須
　・〔例〕〔業界〕の〔法規制・取引先要求〕に準拠すること

9. 予算
　・初期費用：〔　〕万円〜〔　〕万円を想定
　・運用費：年間〔　〕万円程度を想定
　※ この範囲で実現可能な構成の提案を希望します

10. スケジュール
　・RFP配布：〔　年　月　日〕
　・質問受付期限：〔　年　月　日〕
　・提案書提出期限：〔　年　月　日〕
　・提案説明会：〔　年　月　日〕
　・選定・内示：〔　年　月　日〕
　・稼働希望：〔　年　月〕

11. 体制・役割分担
　・窓口担当：〔部署・氏名・連絡先〕
　・決裁者：〔役職・氏名〕
　・当社が対応可能な工数：〔例〕窓口1名が週〔　〕時間程度

12. 提案依頼事項・評価基準・提出要領
　(1) 提案書に記載いただきたい事項
　　　① 課題に対する解決方針　② 実現方式・システム構成
　　　③ 機能一覧と実現方法（標準機能／カスタマイズの別）
　　　④ 概算見積（初期費用・運用費の内訳、5年間の総額）
　　　⑤ スケジュールと当社側に必要な作業・工数
　　　⑥ 体制（担当者の経験・稼働率）　⑦ 類似実績
　　　⑧ 保守・サポート内容と費用
　(2) 評価基準：〔課題理解／実現方式／実績・体制／運用保守／費用／日程〕
　(3) 提出先・形式：〔メールアドレス〕宛にPDFで
　(4) 提出期限：〔　年　月　日　　時〕
　(5) 提案書作成費用は貴社負担とさせていただきます
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

開発会社が「見積もれない」RFPの5つの穴

ここからが、受け取る側からしか見えない話です。

RFPを受け取ったベンダーは、まず「これで金額を出せるか」を判断します。出せないと感じたとき、ベンダーが取る行動は3つのどれかです。

• ヒアリングを申し入れる（＝選定期間が延びる）
• リスク分を上乗せして高く見積もる（＝高い提案が返ってくる）
• 前提を都合よく置いて安く出す（＝着工後に追加費用で揉める）

3社の見積もりが300万〜1,500万に散らばるのは、たいていこれが原因です。以下の5つの穴が、その引き金になります。

穴1：業務の「量」が書かれていない

もっとも多い穴です。「受注管理をシステム化したい」と書かれていても、月に何件の受注があるのかが書かれていない。10件と10万件では、必要なシステムがまったく違います。

次の4つの数字だけは必ず入れてください。見積もりの精度が一段変わります。

• 利用者数（全体で何人、同時に使うのは何人）
• 処理件数（月あたり・繁忙期のピーク）
• データ量（既存データが何年分・何件あるか）
• 拠点数（何拠点から使うか、拠点ごとに業務は違うか）

穴2：「既存システムと連携」で終わっている

この一文は、見積もり幅が数十万円から数百万円まで開きます。連携は、相手側の作りによって難易度が桁で変わるためです。最低限、次の3点を書いてください。

• 相手システムの製品名とバージョン（自社開発なら「自社開発・〇年導入」と）
• 連携方式の有無（API・CSV出力・データベース直接参照のどれが使えるか。わからなければ「不明」と書く）
• 仕様書があるか、ベンダーに問い合わせられるか

「不明」と書くこと自体は問題ありません。不明だと書いてあれば、ベンダーは調査工数を見積もりに入れられます。困るのは、書かれていないので「連携できる前提」で見積もってしまうことです。

穴3：スコープの「外側」が書かれていない

やりたいことは書かれているのに、やらないことが書かれていないRFPは非常に多いです。

受け取った側は「在庫管理」と書かれていたら、それが倉庫だけなのか店舗在庫も含むのか、判断できません。安全側に倒せば高くなり、狭く読めば後で「入っていると思っていた」となります。

RFPには3つの箱を用意してください。①今回やること ②今回はやらないこと ③将来やるかもしれないこと。③を書いておくと、ベンダーは将来の拡張を邪魔しない設計を選べます。これは中小企業にとって効きます。

穴4：誰が決めるのかが書かれていない

見積もりに乗るのは開発工数だけではありません。意思決定の速度も金額に乗ります。確認事項に返答が来ない期間は、ベンダー側の人員が空転し、その分は最終的に価格か納期に反映されます。

「窓口担当」と「決裁者」を明記し、自社側が出せる工数（週に何時間、誰が対応できるか）まで書いてください。「担当者は通常業務と兼務で、週2時間程度」と正直に書いてあるRFPは、むしろ良い提案を引き出します。ベンダー側で巻き取る作業を織り込んだ現実的な計画が返ってくるからです。

穴5：予算が書かれていない

「予算を書くと足元を見られる」——よく聞く懸念ですが、実務上は逆効果です。次の節で詳しく説明します。

予算は書くべきか？｜結論：レンジで書くべき

この論点はよく迷われるので、独立して説明します。結論は「書くべき」です。ただし1点の金額ではなく、幅（レンジ）で書きます。

理由は3つあります。

1. 予算がないと、各社が別々の規模で提案する。フルスクラッチで1,500万円の提案と、SaaS設定で300万円の提案が並び、比較しようがなくなります。比較可能にすることがRFPの目的なので、これは本末転倒です。
2. 提案の中身が「予算内で何ができるか」に変わる。予算を伝えると、ベンダーは限られた枠でどう優先順位をつけるかを提案します。これは発注側にとって最も価値のある情報です。
3. そもそも足元は見られない。相見積もりであることを明記していれば、予算上限ぎりぎりを出した会社は他社に負けます。競争環境が価格を規律します。

書き方の例です。

初期費用は500万〜800万円、運用費は年間100万円程度を想定しています。この範囲で実現可能な構成をご提案ください。範囲を超える提案も、費用対効果が明確であれば併記してご提案いただいて構いません。

最後の一文があると、「予算内の案」と「もう少し出せばここまでできる案」の2案が返ってくることがあります。判断材料としては、こちらのほうが有用です。

なお、社内でまだ予算が固まっていない場合でも、「300万円規模か、1,000万円規模か」の桁だけは示してください。桁が違うと、提案する解決策そのものが変わります。

非機能要件は、この6項目に1問ずつ答えれば足りる

RFPで最も抜けやすく、最も追加費用の原因になるのが非機能要件です。「動くかどうか」ではなく「どう動くべきか」を定める要件で、性能・停止時間・セキュリティ・保守などが該当します。

IPAは『非機能要求グレード2018』として、非機能要件を6大項目に整理した資料を公開しています。ただし、その下には100を超える検討項目が並んでおり、中小企業がこれを全部埋めるのは現実的ではありません。

そこで、6大項目それぞれについて「最低限これだけ答える」形に圧縮したのが次の表です。RFPにはこの6行があれば足ります。

IPAの6大項目	最低限これに答える	書かないと起きること
可用性	止まったら何時間まで許容できるか。夜間・休日も使うか	24時間365日前提の冗長構成で高額になる。逆に、必要な時間帯に止まる
性能・拡張性	同時に何人が使うか。月間の処理件数と、3年後の想定	動くが遅く、現場で使われなくなる
運用・保守性	日常の運用は誰がやるか。障害時の連絡受付は何時から何時か	保守契約が後から別見積もりで出てくる
移行性	既存データを何年分、どこまで移すか	最も揉める。移行費用が丸ごと追加になる
セキュリティ	個人情報を扱うか。権限は何種類必要か。社外から使うか	取引先の監査や情報セキュリティ要求で作り直しになる
システム環境	クラウドか自社設置か。既存の端末・OS・回線に制約はあるか	自社環境で動かないものが納品される

特に移行性は強調しておきます。「既存データは移せますよね」という前提のまま契約し、着工後に「10年分・50万件・表記ゆれあり」と判明して数百万円の追加、という展開は実際に起こります。データの年数と件数は、RFPの段階で必ず書いてください。

RFP作成の4ステップ

ステップ1：現状を1枚に棚卸しする（所要2〜4時間）

いきなりRFPを書き始めないでください。まず現在の業務の流れと、そこに乗っている数字を1枚にまとめます。

「受注（月400件・営業2名）→ Excelに入力 → 基幹システムに再入力（1件3分）→ 出荷指示（倉庫1名）」のように、作業・担当者・件数・時間を書き出すだけで構いません。この1枚がRFPの2〜6項目の材料になり、同時に、後で効果を測るためのベースラインにもなります。

ステップ2：目的と「成功の測り方」を決める

「業務効率化」は目的になりません。何が、どれだけ、どうなったら成功なのかを決めます。「受注処理の月20時間を5時間にする」「欠品を月10件から2件にする」といった粒度です。

ここが決まっていると、ベンダーの提案が「機能の羅列」ではなく「その数字をどう達成するか」に変わります。提案の質を上げる効果がいちばん大きいのがこのステップです。

ステップ3：スコープの線を引く

前述の3つの箱（やる／やらない／将来）に振り分けます。迷ったものはいったん「やらない」に置いてください。1つのプロジェクトを小さく保つことが、冒頭のデータ（10人月未満なら不良は10%未満）が示す最も確実な打ち手です。

ステップ4：書いて配る

配布先と日程の目安です。

• 配布は3〜5社。10社に配ると各社の本気度が下がり、比較の手間だけが増えます
• 提案期間は2〜3週間。1週間では、テンプレートを流用した提案しか返ってきません
• 質問受付期限を設ける（提出期限の1週間前など）。質問と回答は全社に共有すると、条件が揃って比較しやすくなります

やりがちな失敗5つ

1. 機能一覧だけを書く。課題が書かれていないと、提案は製品カタログの引き写しになります。ベンダーが提案力を発揮できるのは、課題が書かれているときだけです
2. 大企業向けテンプレートを埋めようとして止まる。書けない欄は「該当なし」「不明」で構いません。空欄より「不明」のほうが情報量があります
3. 10社に配る。3〜5社が適正です
4. 評価基準を決めずに提案を受ける。基準がないと、最後は金額だけで決めることになります。それならRFPを作る意味がありません
5. RFPを要件定義書だと思っている。RFPは「課題と要望」、要件定義は契約後に一緒に固める工程です。混同すると、RFPの段階で作れないものを作ろうとして止まります

提案の評価基準｜費用の配点を半分以上にしない

提案を受け取る前に、評価基準と配点を決めておきます。中小企業向けの配点例です。

評価項目	配点例	見るポイント
課題の理解度	20	RFPに書いた課題を、自社の言葉で言い換えられているか。丸写しは理解していない兆候
実現方式の妥当性	20	なぜその方式なのか理由があるか。標準機能とカスタマイズの別が明示されているか
実績・体制	15	同業種・同規模の実績。担当者が何人・どれだけの稼働で入るか
運用・保守	15	納品後の窓口、費用、改修の進め方
費用	20	初期費用だけでなく5年間の総額で比較
スケジュール	10	自社側の作業がいつ・何時間必要かが書かれているか

費用の配点は20点程度に抑えます。金額で決めるならRFPは不要で、相見積もりだけで済むからです。

実務上、最も差が出るのは「課題の理解度」です。RFPの文言をそのまま引き写している提案書と、自社の言葉で課題を整理し直したうえで「ここは認識が違うかもしれません」と指摘してくる提案書とでは、着工後の進み方がまったく違います。RFPに書いた内容へ疑問を投げてくるベンダーは、多くの場合、良い兆候です。

よくある質問（FAQ）

Q. RFPを作らずに発注してはいけませんか？

金額次第です。100万円未満で、機能も明確な小規模案件なら、メール本文に課題・やりたいこと・予算・時期を書けば足りることが多いです。一方、300万円を超える、または複数部署にまたがる案件では、RFPを作らない不利益のほうが大きくなります。比較ができず、後の認識違いも防げないためです。

Q. 技術がわからないのですが、書けますか？

書けます。RFPに必要なのは技術知識ではなく、自社の業務を説明できることと、数字を出せることです。むしろ、発注側が技術方式を指定してしまうと、より良い選択肢をベンダーが提案できなくなります。「〇〇を使って作ってください」ではなく「〇〇を実現したい」と書くのが正解です。

Q. 何社に出すのが適切ですか？

3〜5社です。RFI（情報提供依頼）で候補を7〜8社まで広げ、そこから絞ってRFPを出す進め方も有効です。1社だけに出すのは、RFPというより要望整理と考えてください。それでも認識合わせの効果はあるので、無駄にはなりません。

Q. パッケージやSaaSの導入でもRFPは必要ですか？

必要です。というより、この場合こそ効果があります。パッケージ導入の費用差は、製品価格よりも「どこまでカスタマイズするか」「既存データをどう移すか」「どこまで初期設定を任せるか」で生まれます。RFPでスコープと移行範囲を示しておくと、各社の見積もりが同じ土俵に乗ります。

Q. 補助金を使う場合、RFPは役に立ちますか？

役に立ちます。補助金の申請書では、現状の課題・導入の目的・期待される効果を求められることが多く、RFPの2〜3項目がほぼそのまま流用できます。なお、従来の「IT導入補助金」は令和7年度補正予算事業から「デジタル化・AI導入補助金」に名称が変わりました。枠ごとに補助率や対象が異なるため、条件は必ず公式サイト（中小企業庁・公式ポータル）で最新のものをご確認ください。

Q. RFPの内容は契約に含まれますか？

そのままでは含まれません。通常は、RFPと提案書をもとに要件定義を行い、その成果物が契約上の作るべきものの基準になります。契約の進め方に不安がある場合は、IPAが公開している『情報システム・モデル取引・契約書（第二版）』が参考になります。工程を分けて発注する形にも対応しており、中小企業の案件でも考え方は流用できます。

まとめ

• RFPは「何に困っていて、どうなりたいか」を書く文書。「どう作るか」はベンダーが提案する側で、発注側が書く必要はない
• 中小企業のRFPはA4 5〜10枚で足りる。判断基準は「ベンダーが追加ヒアリングなしで概算を出せるか」の一点
• 見積もりが割れる原因は、業務量・連携先・スコープの外側・決裁者・予算の5つが書かれていないこと
• 予算はレンジで開示する。伏せると比較不能な提案が並ぶ
• 非機能要件はIPAの6大項目に1問ずつ答えれば足りる。特に移行（データの年数と件数）は必ず書く
• JUASの調査では、予定どおりに終わらなかった要因の最多は「計画時の考慮不足」（品質48.8%・予算51.0%・工期52.5%）。一方で10人月未満の案件は不良が10%未満。小さく区切って、発注前に準備することの効果は数字にも表れている

RFPは、ベンダーのための書類ではありません。書く過程で、自社の業務と課題が初めて言語化されます。実際、RFPを作る途中で「そもそもこの作業は必要なのか」に気づき、システム化する前に業務そのものを見直したほうが早い、という結論に至るケースもあります。それも十分に価値のある成果です。