RFPの書き方｜中小企業向けの8項目と例文

「システム開発を外に頼みたいが、RFPを書いたことがない」「何をどこまで書けば、開発会社に伝わるのか分からない」「テンプレートを埋めてみたものの、機能の一覧にしかならない」。初めてシステム開発やAI開発を発注する中小企業から、こうした声をよく聞きます。この記事では、RFP（提案依頼書）に載せる8つの項目と、項目ごとの例文、AI開発を含む場合に追加で書くこと、届いた提案の比べ方までをお伝えします。

結論：RFPは「解きたい課題」と「選ぶ基準」を伝える文書です

RFP（Request for Proposal、提案依頼書）は、発注側が開発会社に提案を依頼するための文書です。中小企業のRFPで大事なのは、作りたい機能を細かく並べることではありません。何に困っていて、何がどう変われば成功なのか（課題と効果の目標）と、どの提案をどう選ぶのか（判断基準）を伝えることです。

この2つが書いてあれば、開発会社は自社の得意な方法で解き方を考えられます。逆に機能の一覧だけを渡すと、各社はその一覧の見積もりを返すだけになり、「もっとよいやり方」が提案に出てきません。

分量は、A4で数枚から始めてかまいません。最低限、次の8項目があれば提案は集まります。

背景と目的
現状の業務とシステム
解決したい課題と効果の目標
依頼する範囲
制約（期限・予算の考え方・既存システム・セキュリティ）
提案してほしい内容
選定の基準と進め方
質問の受付

似た言葉に RFI と RFQ があります。目的が違うため、今どの段階にいるかで使い分けます。

文書	目的	使う場面
RFI（情報提供依頼書）	開発会社の得意分野や、取り得る方法の情報を集めます	解き方の見当が付かず、候補の会社を絞りたい場合
RFP（提案依頼書）	課題に対する解き方と体制、進め方の提案を求めます	課題と目的が固まり、発注先を選ぶ場合
RFQ（見積依頼書）	決まった仕様に対する金額と納期を求めます	作るものがすでに決まっている場合

RFPを書かないと起きること

RFPを書かずに、打ち合わせの口頭説明だけで提案を依頼すると、次のようなことが起きやすくなります。

各社が聞き取った内容がばらばらで、提案の前提がそろわず、比べられません。
見積もりの範囲（データ移行やマニュアル作成、運用を含むか）が会社ごとに違い、金額の差の理由が分かりません。
「何ができれば成功か」が決まっていないため、完成後に「思っていたものと違う」となります。
社内でも目的の認識がそろわず、選定の段階で意見が割れます。

要件を言葉にするのは、大企業でも簡単ではありません。JUAS（日本情報システム・ユーザー協会）の企業IT動向調査2026では、東証上場企業とそれに準じる企業のIT部門（回収957社）に聞いた人材の課題で、育成面で課題感が高い担当業務の2位に「上流工程担当（業務分析・システム要件定義等）」が挙がっています（46.6%）。専任の担当者がいない中小企業なら、なおさら最初から完璧な要件はまとまりません。だからこそ、細かな要件より先に「課題と判断基準」を書く形のRFPが向いています。

また、経済産業省のレガシーシステムモダン化委員会総括レポートは、ユーザー企業がベンダー企業へ依存し、ITに対する自律性が低下している（いわゆる丸投げ体質）と指摘しています。RFPを自社で書くことは、発注先に任せきりにせず、目的と判断を自社の手元に残すための第一歩でもあります。

DXの担当を任されたばかりで、そもそもどの課題から手を付けるべきか迷っている場合は、DX担当を任されたら最初にやることから整理すると、RFPの「背景と目的」が書きやすくなります。

RFPに載せる8項目

8項目それぞれで書くことと、書くときのコツを表にまとめます。

項目	書くこと	書くときのコツ
1. 背景と目的	なぜ今この取り組みをするのか、会社として何を目指すのか	経営の言葉で1〜2段落にします
2. 現状の業務とシステム	対象業務の流れ、関わる人数、使っているシステムやExcel	図や画面のコピーがあれば添付します
3. 課題と効果の目標	困っていることと、何がどれだけ変われば成功か	時間・件数・ミスの数など、数字で書きます
4. 依頼する範囲	対象の業務・部署・機能、含めない範囲	「含めないもの」も明記します
5. 制約	期限、予算の考え方、既存システム、セキュリティの条件	動かせない条件と、相談できる条件を分けます
6. 提案してほしい内容	解き方、体制、進め方、スケジュール、費用の内訳	提案書の目次を指定すると比べやすくなります
7. 選定の基準と進め方	何を重視して選ぶか、日程、選定の手順	評価の項目と重みを先に示します
8. 質問の受付	質問の期限、窓口、回答の共有方法	回答は全社に同じ内容で共有します

項目ごとの書き方と例文

ここからは、架空の会社「A社」（従業員80名ほどの部品の専門商社。受注をメールとFAXで受け、Excelで管理している）を例に、各項目の短い例文を示します。数字はすべて説明のための架空の値です。

1. 背景と目的

背景には「システムを入れたい理由」ではなく「会社として解決したいこと」を書きます。

当社は受注件数が増える一方で、受注入力を担う人員は増やせていません。受注業務の手間を減らし、営業担当が顧客対応に使える時間を増やすことを目的に、受注管理の仕組みを見直します。

2. 現状の業務とシステム

業務の流れを、誰が・何を見て・何をするかの順に書きます。ここが薄いと、各社が想像で補うため提案がずれます。

受注はメール（約6割）とFAX（約4割）で届き、業務担当3名が内容を確認してExcelの受注台帳に転記しています。在庫は販売管理パッケージで確認し、出荷指示は台帳から手作業で作成しています。

使っているシステムの名前、データの件数、Excelの台帳の項目などは、分かる範囲で添えます。仕様書や担当者がいなくなり中身が分からないシステムがある場合は、その旨も正直に書いておきます。中身の把握から相談したい場合の進め方は、ブラックボックス化したシステムの引き継ぎ方で説明しています。

3. 解決したい課題と効果の目標

RFPの中心です。課題を書いたら、効果の目標を数字で置きます。業務を分解し、「手間×頻度×価値」で重い作業から順に並べると、書く内容が絞れます。

受注1件の転記と確認に平均10分かかり、1日の受注は約60件あります。転記ミスによる誤出荷も月に数件起きています。転記と確認の時間を半分にし、誤出荷をなくすことを目標とします。

どの作業を優先すべきか迷う場合は、AI化する業務の洗い出し方の評価表がそのまま使えます。

4. 依頼する範囲

対象と対象外の両方を書きます。対象外を書いておくと、見積もりの範囲が各社でそろいます。

対象：受注の受付から出荷指示の作成まで。対象外：請求・会計の処理（現行の会計ソフトを継続して使います）。要相談：既存の受注データ（約3年分）の移行。

5. 制約（期限・予算の考え方・既存システム・セキュリティ）

動かせない条件と、提案次第で相談できる条件を分けて書きます。

期限：繁忙期の前までに、受注入力の部分だけでも使い始めたいと考えています。予算：今期の投資枠の中で判断します。段階的に進める案や、効果が大きい部分から始める案も歓迎します。既存システム：販売管理パッケージは当面継続し、在庫データを連携したいと考えています。セキュリティ：取引先の情報を扱うため、データの保管場所とアクセス管理の方法を提案に含めてください。

予算は、金額を書けない場合でも「判断の考え方」は書きます。上限の目安、投資を回収したい期間、段階的に進めたいかどうかが分かるだけでも、提案の現実味は大きく変わります。

6. 提案してほしい内容

提案書に入れてほしい項目を指定します。目次をそろえておくと、比べるときに迷いません。

次の順で提案してください。①課題の理解と解き方、②システムの構成と、既存システムとの連携方法、③進め方とスケジュール、④体制と担当者の経験、⑤費用の内訳（初期と運用を分けて）、⑥稼働後の保守・改善の方法。

解き方を一つに決めつけず、「パッケージやSaaSの活用、必要な部分だけの開発、AIの活用など、方法は問いません」と書いておくと、各社の工夫が出やすくなります。

7. 選定の基準と進め方

何を重視して選ぶかを、提案を依頼する時点で示します。後述する評価表の項目と重みを、そのまま載せてかまいません。

選定では、課題の理解と解き方、効果の実現性、運用のしやすさ、体制、費用の妥当性の順に重視します。提案書の受領後、上位の2〜3社にプレゼンテーションをお願いし、社内で決定します。

日程（RFPの配布、質問の締め切り、提案の締め切り、プレゼン、決定）も表にして書きます。

8. 質問の受付

質問はメールで、所定の締め切りまでにお送りください。いただいた質問と回答は、質問者の名前を伏せて全社に共有します。

全社に同じ回答を返すと、情報の差による提案のずれを防げます。

AI開発を含む場合に追加で書く4項目

AIを使う仕組みは、作る前に結果が読み切れない部分があります。RFPにも、通常のシステム開発とは別に次の4項目を足します。

項目	書くこと	例（架空のA社）
使えるデータ	どんなデータが、どこに、どれだけあるか。社外に出してよいか	過去の受注メールとFAXの画像、受注台帳。個人情報を含むため、扱いの条件も提案に含めてもらいます
精度の考え方	どこまで当たればよいか。外れたときに誰がどう直すか	読み取り結果は担当者が確認してから確定する前提です。確認の手間がどれだけ減るかを効果として見ます
検証から本番への段階	小さく試す段階と、本番に進む判断の基準	まず過去データで読み取りを試し、目標を満たしたら本番の開発に進みます
運用・改善	稼働後に精度をどう保ち、誰が改善するか	読み取りの誤りを集めて定期的に見直す方法と、その体制を提案してもらいます

AIの仕組みは、試してみてから本番に進むかを決める進め方が向いています。RFPの段階で「検証の段階で何が確かめられたら次に進むか」を書いておくと、試作だけで終わる事態を避けやすくなります。止まりやすい理由と本番に進む条件は、AIのPoC止まりの原因と本番移行の条件で詳しく説明しています。

AIを使う予定がなくても、「AIで代替や補助ができる作業があれば提案してください」と一文入れておくことをおすすめします。業務の一部をAIに任せる前提で考えると、システムで作る範囲が小さくなる場合があるためです。AIの利用料や開発費の考え方は、生成AIの導入費用の内訳が参考になります。

提案の比べ方：評価表を先に作る

提案が届いてから比べ方を考えると、資料の見栄えやプレゼンの印象に引っ張られます。評価表はRFPと同時に作り、選定基準として先に開示します。

評価項目	重み（例）	見るポイント
課題の理解	25%	自社の業務と課題を、自分の言葉で言い直せているか
解き方と効果の実現性	25%	効果の目標にどう届くか、根拠が示されているか
運用のしやすさ	15%	現場が使い続けられるか、稼働後の改善の方法があるか
体制と経験	15%	担当者の経験、窓口、社内との役割分担が明確か
費用の妥当性	20%	内訳が分かるか、範囲と前提がRFPとそろっているか

点数は複数人で別々に付け、差が大きい項目だけ話し合うと、声の大きい人の意見に寄りにくくなります。見積もり金額の比べ方は、システム開発の見積もりの妥当性の確かめ方で、範囲や前提のそろえ方を含めて説明しています。

重みは会社によって違ってかまいません。大事なのは、「安い会社を選ぶ」でも「有名な会社を選ぶ」でもなく、「自社の課題を解き、使われ続ける提案を選ぶ」ための基準を先に決めておくことです。

RFPでよくある失敗4つ

機能の一覧だけになっている

「検索機能」「CSV出力」「権限管理」のように機能を並べただけのRFPは、なぜその機能が要るのかが伝わりません。各社は一覧どおりの見積もりを返すだけになり、業務の流れを変えるような提案が出ません。機能を書くなら、その機能で解きたい課題を必ず隣に書きます。

予算を伏せすぎている

予算を一切書かないと、各社の想定する規模がばらばらになり、提案が比べられません。金額を書けない場合でも、上限の目安や回収したい期間、段階的に進めたいかどうかといった「判断の考え方」は示します。

選定の基準があいまい

「総合的に判断します」だけでは、各社は何に力を入れて提案すべきか分かりません。社内でも、決定の直前になって重視する点が人によって違うことに気づきます。評価表の項目と重みを先に示します。

現状の資料が足りない

業務の流れや既存システムの情報が無いと、各社は推測で見積もるため、余裕を見た前提が入ったり、稼働後に想定外の作業が見つかったりします。完璧な資料でなくてかまいません。業務の流れの手書きの図、Excelの台帳の項目、画面のコピーでも十分に役立ちます。

RFPを書く前の準備と進め方

RFPを書く前に、社内で次の3つをそろえておきます。

目的と効果の目標について、経営者と現場の責任者が合意していること
最終的に誰が決めるか（決裁者）と、いつまでに決めるか
現場の担当者から、業務の流れと困りごとを聞き取っていること

私たちがRFPづくりのご相談を受けるときも、最初に時間をかけるのは機能の一覧ではなく、業務の流れと困りごとの整理です。ここが固まれば、RFPの半分は書けたようなものです。

配布先は、得意分野の違う数社に絞ると、比べやすく、各社も丁寧に提案できます。配布から決定までの流れは、おおむね次のとおりです。

RFPの配布と説明（必要に応じて説明会を開きます）
質問の受付と、全社への回答の共有
提案書の受領と、評価表での採点
上位の会社によるプレゼンテーションと質疑
決定と、契約内容のすり合わせ

契約の段階では、システムの仕様、プロジェクトの進め方、検収の方法について双方の理解をそろえておくことが大切です。考え方の参考として、IPAが情報システム・モデル取引・契約書を公開しています。実際の契約内容は、必要に応じて弁護士などの専門家に確認してください。

基幹システムの入れ替えのように範囲が広い案件では、RFPの前に移行の方式やパッケージかスクラッチかの方針を決めておくと、提案の方向がそろいます。その進め方は基幹システムリプレイスの進め方で説明しています。

まとめ：機能より課題と判断基準を書く

RFPは、作りたい機能より「解きたい課題と効果の目標」と「選ぶ基準」を伝える文書です。A4数枚から始めてかまいません。
載せる項目は、背景と目的、現状の業務とシステム、課題と効果の目標、範囲、制約、提案してほしい内容、選定の基準と進め方、質問の受付の8つです。
効果の目標は、時間・件数・ミスの数など数字で書き、対象外の範囲や予算の考え方も示すと、提案の前提がそろいます。
AI開発を含む場合は、使えるデータ、精度の考え方、検証から本番への段階、運用・改善の4項目を足します。AIを使う予定がなくても、AIで補える作業の提案を求めておくと選択肢が広がります。
評価表はRFPと同時に作って開示し、複数人で採点します。

発注の前の課題の整理や、提案の比べ方についてもご相談いただけます。進め方はコンサルティングの支援内容をご覧ください。