「複数の開発会社に相見積もりを取りたいので、RFPを作って」と言われたものの、RFP（提案依頼書）に何を書けばいいのか分からない。情シスを兼任している総務や管理部門の方から、よく聞く悩みです。
「RFP（提案依頼書）を書けと言われたけど、何を書けばいいのか分からない…」
先に結論をお伝えします。RFPは立派な仕様書ではなく、「どの会社にも同じ前提で、同じ形式の提案を出してもらうための依頼書」です。書く項目はおおむね決まっていて、小さな会社ならA4で3〜5枚程度の「簡易版RFP」から始めて構いません。大切なのは、細かさよりも「目的・範囲・予算感・提案の出し方・評価の仕方」を全社にそろえて伝えることです。
この記事では、RFPの書き方を、項目一覧の表、提案を比べやすくするための指定のしかた、そのまま使える簡易版RFPのひな形、チェックリスト、開発会社への質問例とあわせて解説します。
RFP（提案依頼書）とは？発注メモとの違いと必要になる場面
RFP（Request For Proposal＝提案依頼書）は、発注者が開発会社に「こういうシステムを、こういう条件で提案してください」とお願いするための文書です。開発会社はRFPを読んで、作り方・体制・スケジュール・費用を考え、提案書と見積書を返します。
IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」でも、RFPは契約の土台となる文書として位置づけられています。
同書のモデル契約書では、発注者が示したRFPと、開発会社の提案書・見積書を基礎にして個別契約の条件を定める形になっています。一方で、RFPに書いてあっても契約書に盛り込まれなかった内容は契約内容にならない、という整理も示されています。RFPは「言った・言わない」を防ぐ最初の記録であると同時に、大事な条件は最終的に契約書へ移す必要がある、と覚えておきましょう。
「発注メモ」とRFPの違い
最初の相談で使う「発注メモ」とRFPは、目的が少し違います。発注メモの作り方は作りたいシステムを開発会社にどう伝える？初めての発注で準備したい5つのことで解説しているので、ここでは違いだけを整理します。
| 比べる点 | 発注メモ | RFP（提案依頼書） |
|---|---|---|
| 目的 | 相談のきっかけ。要望を伝えて意見をもらう | 複数社から比べられる提案・見積もりをもらう |
| 渡す相手 | 1〜数社（相談相手） | 候補として選んだ複数社（同じものを渡す） |
| 分量の目安 | A4で1〜2枚 | 簡易版でA4で3〜5枚程度、大きな案件ではそれ以上 |
| 主な中身 | 目的・現状・使う人・必須機能・予算・時期 | 発注メモの内容＋対象範囲・非機能要件・提案に含めてほしい事項・評価方法・提出方法 |
| 返ってくるもの | アドバイス、ざっくりした費用感 | 提案書・見積書（選定の判断材料） |
つまり、RFPは発注メモを土台にして、「提案の出し方」と「選び方」のルールを足したものです。発注メモがすでにあるなら、半分以上はできていると考えて大丈夫です。
小さな会社でRFPが必要になる場面
すべての発注にRFPが必要なわけではありません。次のような場面では、RFPを作る価値が高くなります。
- 3社以上に相見積もりを取り、社内で比較・説明する必要がある
- 金額が大きく、社長や役員会の承認に「なぜこの会社か」の根拠が要る
- 既存システムの入れ替えで、今のシステムの作り手以外の会社にも提案してもらいたい
- 補助金の申請などで、選定の経緯を残しておきたい
反対に、小さな改修や1社にじっくり相談したい段階なら、発注メモで十分なことも多いです。
RFPに何を書けばいいか分からなくなる3つの理由
理由1：「何を作るか」が社内でまだ固まっていない
RFPが書けない一番の原因は、文章力ではなく、社内で目的や範囲が決まっていないことです。IPAのモデル取引・契約書の解説では、要件定義の後に出すRFPについて、発注者がどんなシステムを作りたいかを明確にする必要があり、RFPに表現されていない要件はシステムとして実現されない、と述べています。
逆に言えば、未確定の部分は「未定」「提案してほしい」と正直に書けばよいのです。同書でも、企画の早い段階で出すRFPには未確定の事項があり得るとしています。
理由2：開発会社が「何を知りたいか」が見えない
発注者は「欲しい機能」を書きがちですが、開発会社が見積もりで知りたいのは、使う人数、既存システムとのつながり、データの量、止まってよい時間、発注者側で担える作業など、費用を左右する前提です。これが書かれていないと、各社が別々の前提で見積もるため、金額がばらばらになります。
理由3：「開発会社に書いてもらう」選択肢で迷う
IPAのモデル取引・契約書では、特に中小企業の場合、発注者にRFPを作る余力がなく、コンサルタントや既存システムを作ったベンダがRFPを代わりに作ることが多いと指摘しています。そのうえで、作成したベンダにしか分からない部分が残ると、別の会社が開発を請け負ったときに遅れや費用増につながることがある、としています。
外部の支援を受けること自体は問題ありません。ただし、最終的に「何を求めるか」は発注者が理解し、自分の言葉で説明できる状態にしておくことが大切です。
RFPの項目一覧：11項目で何を書くか
IPAのモデル取引・契約書の別紙「提案依頼書（RFP）の詳細」では、RFPの基本項目として、システムの概要（基本方針）、提案依頼手続き、依頼事項（機能要件・非機能要件）、開発体制・開発環境、保証要件、契約事項、その他が挙げられています。これは大規模な企業システムを想定した詳しい一覧なので、以下では中小企業の発注で使いやすいように11項目へ組み直しました。
| 項目 | 書くこと | 小さな会社での書き方の例 |
|---|---|---|
| 1. 背景・目的 | なぜ今作るのか、何が良くなれば成功か | 「受注入力に1件15分かかっている。5分以内にしたい」 |
| 2. 現状と課題 | 今の業務の流れ、使っている道具、困っている点 | 業務の流れを箇条書き、使っているExcelや帳票の見本（個人情報は伏せる） |
| 3. 対象範囲 | 今回お願いする範囲と、お願いしない範囲 | 「受注〜出荷指示まで。会計ソフトへの連携は今回は対象外」 |
| 4. 機能要件の概要 | システムでできるようにしたいこと | 必須／あれば嬉しいに分けた一覧（20〜30行程度でも可） |
| 5. 非機能要件 | 速さ・止まりにくさ・セキュリティ・利用環境・保守など | 利用者数、利用時間帯、スマホ対応の要否、扱う個人情報、バックアップ |
| 6. スケジュール | 提案締切、選定時期、稼働希望時期とその理由 | 「来年4月の新年度から使いたい（年度替わりの繁忙期を避けるため）」 |
| 7. 予算感 | 予算の上限や幅、初期費用と月額費用の考え方 | 「初期費用◯◯万〜◯◯万円、月額費用は◯万円程度まで」 |
| 8. 体制・前提 | 社内の窓口・決める人、発注者側で担える作業、既存システム | 「窓口は総務1名。テストは現場2名が週半日協力可能」 |
| 9. 提案に含めてほしい事項 | 提案書・見積書に必ず書いてほしい内容と形式 | 次の章の一覧を参照 |
| 10. 評価方法 | 何を重視して選ぶか、選定の流れ | 「提案内容・体制・費用・保守を総合評価。書類選考後に2社と面談」 |
| 11. 提出方法 | 締切、提出先、形式、質問の受付方法、秘密保持 | 「◯月◯日までにPDFでメール提出。質問は◯日までメールで受付、回答は全社に共有」 |
いくつかの項目は、書き方に少しコツがあります。
「対象範囲」は、やらないことこそ書く
対象範囲では、「やってほしいこと」以上に「今回は対象外のこと」をはっきり書きましょう。データ移行、既存システムとの連携、操作説明会、公開後の保守などは、書き方しだいで見積もりに入ったり入らなかったりする代表例です。対象外なのか、見積もりを別に出してほしいのかを明記すると、比べやすくなります。
「非機能要件」は、言葉で書ければ十分
非機能要件（＝機能以外の品質。速さ、止まりにくさ、安全性など）は、専門知識がないと書きにくい項目です。
📰 出典：IPA「非機能要求グレード」
IPAは、非機能要件についての発注者と開発者の認識の行き違いを防ぐことを目的に「非機能要求グレード」という道具を公開しています。
本格的に使うのは開発会社側でも構いません。発注者は「何人が同時に使うか」「夜間や休日も使うか」「止まったら業務にどれくらい影響するか」「個人情報を扱うか」を、業務の言葉で書いておけば十分な手がかりになります。
公的機関のひな形も参考になる
デジタル庁は、政府情報システムの整備・管理の共通ルールとして「デジタル社会推進標準ガイドライン」を公開しています。同じページでは、実践ガイドブック（DS-120）の関連資料として、調達仕様書と要件定義書の標準テンプレートも配布されています（2026年7月更新）。行政機関向けで分量も多いため、そのまま使うものではありませんが、「どんな項目があるか」を眺める参考資料になります。
提案を比べやすくする「提案に含めてほしい事項」の書き方
相見積もりで一番困るのは、各社の提案の書き方がばらばらで比べられないことです。これを防ぐには、RFPの「提案に含めてほしい事項」で、答えてほしい項目と形式を指定します。
- 課題の理解：当社の目的・課題をどう理解したか（要約）
- 実現方法：作り方（ゼロから開発／パッケージやSaaSの活用など）と、その理由
- 機能の対応表：RFPの機能一覧の各行に「対応する／一部対応／対応しない／別見積」を記入したもの
- スケジュール：主な工程と、発注者側の作業・確認が必要な時期
- 体制：担当予定者の役割と経験、再委託（下請け）の予定の有無
- 見積もり：工程別（要件定義・設計・開発・テスト・移行など）の内訳、初期費用と月額費用の区別
- 前提条件と対象外：見積もりの前提にしたこと、含まれていない作業
- 運用・保守：公開後の保守の範囲、月額の目安、問い合わせ対応の時間帯
- 契約条件の考え方：契約の種類（請負・準委任）、検収・支払いの条件、著作権などの権利の扱い
- リスクと提案：実現が難しそうな点、費用を抑える代替案
見積もりの内訳の書式（工程ごとの行を並べた表など）をRFPに添えて「この形式で記入してください」と依頼すると、比較の手間が大きく減ります。IPAのモデル取引・契約書の解説でも、契約類型、再委託、損害賠償責任、知的財産権の帰属、検収・支払い条件などを、提案依頼の段階であらかじめ明らかにしておく必要があるとしています。契約条件は一般的な考え方にとどまるため、具体的な条項は弁護士などの専門家に確認してください。
RFPを書いて提案を受け取るまでの5ステップ
- 発注メモを作り、社内で目的と範囲を合意する：決める人（社長・部門長）と現場の代表に、目的・範囲・予算感を確認してもらいます
- 11項目に沿ってRFPを書く：分からない項目は「未定」「提案を求む」と書き、空欄のまま放置しないようにします
- 候補の会社に同じRFPを同時に渡す：秘密保持契約（NDA）が必要な資料は、締結してから渡します
- 質問を受け付け、回答を全社に共有する：ある会社だけが追加情報を知っている状態をつくらないためです
- 評価方法どおりに比べ、選定理由を記録する：落選した会社にも、差し支えない範囲で結果を伝えると関係が保てます
提案書づくりには開発会社側にも相応の手間がかかります。提案の締切は案件の規模に合わせて余裕を持って設定し、候補の会社に「この期間で検討できるか」を事前に聞いておくと、各社が落ち着いて検討できます。
小さな会社向け「簡易版RFP」のひな形
最初から完璧なRFPを目指す必要はありません。まずは次のひな形を埋めて、候補の会社に渡してみてください。
- 1. 背景・目的：なぜ作るのか／成功の基準（できれば数字で）
- 2. 現状と課題：今の業務の流れ／使っているExcel・帳票など（見本を添付）／困っている点
- 3. 対象範囲：今回お願いすること／今回は対象外のこと／別見積もりにしてほしいこと
- 4. 機能の一覧：必須の機能／あれば嬉しい機能（表にして、各社に対応可否を記入してもらう）
- 5. 使い方と品質の条件：利用者数・同時に使う人数／利用時間帯／端末（PC・スマホ）／扱う個人情報／止まった場合の業務への影響
- 6. 既存システム・データ：連携したいもの／移行したいデータの種類と件数
- 7. スケジュール：提案締切／選定時期／稼働希望時期とその理由
- 8. 予算感：初期費用の幅／月額費用の上限の目安
- 9. 当社の体制：窓口担当者／最終的に決める人／テストや確認に協力できる人と時間
- 10. 提案に含めてほしい事項：前章の10項目から必要なものを選び、見積もりの内訳の書式を添付
- 11. 評価方法と提出方法：重視する点／選定の流れ（書類→面談など）／締切・提出先・形式／質問の受付期限と回答方法／提案にかかる費用は各社負担であること、提供資料の取り扱い
「まだ決まっていないこと」も、ひな形のどこかに書いておきましょう。未確定の部分をどう扱うかについての提案も、会社ごとの違いが見えやすいところです。
RFPでやりがちな失敗
- 分量を増やせば伝わると考える：大量の要望を並べるより、目的と優先順位が伝わるほうが良い提案につながります
- 機能だけ書いて前提を書かない：利用者数・既存システム・発注者側の作業が書かれていないと、各社の見積もりの前提がそろいません
- 会社ごとに違う説明をする：打ち合わせで口頭補足した内容は、全社に文書で共有しましょう
- 評価方法を決めずに提案を集める：「安い会社」に流れやすくなり、社内で選定理由を説明できなくなります
- RFPを出したら終わりにする：大事な条件は、提案・見積もりの内容とあわせて契約書に反映されているか確認します
- 1社に書いてもらったRFPをそのまま使う：その会社に有利・不利な書き方になっていないか、内容を理解してから使いましょう
発注者がやることチェックリスト
- ☐ RFPの前に、目的・範囲・予算感を決める人と合意した
- ☐ 「今回は対象外のこと」「別見積もりにしてほしいこと」を書いた
- ☐ 利用者数・利用時間帯・扱う個人情報など、非機能要件を業務の言葉で書いた
- ☐ 予算を幅で示し、初期費用と月額費用を分けて書いた
- ☐ 提案に含めてほしい事項と、見積もりの内訳の書式を指定した
- ☐ 評価方法と選定の流れを、提案を集める前に決めた
- ☐ 質問の受付方法と、回答を全社に共有するルールを決めた
- ☐ 秘密保持が必要な資料と、渡す前の手続きを確認した
開発会社への質問例
RFPを渡すときや、提案の説明を受ける場で使える質問です。
- 「このRFPで、見積もりの精度を上げるために足りない情報はありますか？」
- 「見積もりの前提にした条件と、含まれていない作業を一覧で教えてください」
- 「機能の一覧のうち、費用や期間に特に大きく影響するものはどれですか？」
- 「当社側で担当する作業や、確認が必要な時期はいつ頃になりそうですか？」
- 「予算内に収めるとしたら、どの機能を後回しにする案が考えられますか？」
回答の中身だけでなく、分からない点を率直に聞き返してくれるかどうかも、相性を見る手がかりになります。
まとめ：RFPは「同じ前提で比べるための依頼書」
RFP（提案依頼書）の書き方で押さえたいポイントは次のとおりです。
- RFPは仕様書ではなく、複数社に同じ前提・同じ形式で提案してもらうための依頼書
- 発注メモを土台に、対象範囲・非機能要件・提案に含めてほしい事項・評価方法・提出方法を足す
- 「対象外のこと」「予算の幅」「発注者側の体制」を書くと、見積もりの前提がそろう
- 小さな会社は、11項目の簡易版RFPから始めればよい
- 大事な条件は、最終的に契約書に反映されているか確認する
最初のRFPは、うまく書けなくて当然です。まずは簡易版のひな形を埋め、開発会社からの質問を受けながら少しずつ補っていけば、比べやすい提案が集まるようになります。
あわせて読みたい関連記事
