「新しい業務システムを作りたい」「既存システムを刷新したい」「Webサービスを立ち上げたい」——方向性が見えてきても、初めての発注では次の壁にぶつかります。
ここで使うのがRFP（Request for Proposal／提案依頼書）です。「当社はこういう課題を抱えていて、こういうシステムを検討しています。どう実現できるか提案してください」と依頼するための資料で、複数社に同じ条件を渡せるため、提案と見積を横並びで比較できるようになります。
この記事では、初めてシステム開発を発注する経営者・事業責任者の方に向けて、RFPの役割、RFI・要件定義書との違い、記載する16項目、そのまま使えるテンプレート、届いた提案の比較・評価方法までを図解で解説します。
目次
RFPとは？ 発注プロセスでの位置づけ
RFPとは「Request for Proposal」の略で、日本語では提案依頼書と呼びます。システム開発を検討している企業が、開発会社やITベンダーに対して次の情報を伝えたうえで、具体的な提案を依頼するための資料です。
- どのようなシステムを作りたいのか
- 何を解決したいのか
- どのような機能が必要か
- 予算はどの程度か
- いつまでに導入したいのか
ひとことで言えば、RFPは「この条件で、どう実現できるか提案してください」と聞くための資料です。発注プロセス全体では、開発会社を選ぶ直前に位置します。
- システム化したい課題が見つかる「Excel管理が限界」「紙の申請をやめたい」など、困りごとの発見
- RFIで情報を集める（任意）実現手段・実績・概算費用を複数社から収集し、選択肢を広げる
- 方針・予算・優先順位を社内で固める何を優先し、いくらまで使うのかを決める
- RFPで提案と見積を依頼する同じ条件を2〜3社に提示し、実現方法・体制・費用を提案してもらう
- 提案・見積を比較し、開発会社を選定する評価基準にもとづき、プロジェクトを任せられる会社を選ぶ
- 要件定義選定後、実際に作るものを具体的に決めていく
- 設計・開発・テスト・本番稼働ここまでの準備の質が、費用・期間・品質を左右する
RFPは「開発会社を選ぶための資料」であり、「作るものを確定させる資料」ではありません。確定は次の要件定義で行います。
RFPは単なる見積依頼ではない
RFPは「見積を取るための資料」と誤解されることがあります。しかし目的は価格の確認だけではありません。同じ課題でも、開発会社によって提案は変わります。
- 既存のSaaSを利用する
- パッケージ製品をカスタマイズする
- ノーコードを活用する
- スクラッチで開発する
- 段階的に機能を追加していく
だからこそRFPでは、「いくらで作れますか」だけでなく「どのような方法で実現しますか」まで提案してもらうことが重要です。実現方法の違いこそが、各社の実力と考え方が表れる部分です。
なぜRFPがないと比較できないのか
伝える情報が曖昧なままだと、会社ごとに違う前提で提案と見積が作られます。たとえば「営業管理システムを作りたい」とだけ3社に伝えると、こうなります。
- A社300万円想定した範囲：顧客登録と案件一覧のみ。PC利用が前提
- B社600万円想定した範囲：上記＋売上分析・レポート機能まで
- C社900万円想定した範囲：上記＋スマホ対応・基幹システム連携まで
安い見積は「対応範囲が狭い」だけかもしれず、高い見積は「必要なものを漏れなく含めている」だけかもしれません。
RFPを作る4つのメリット
1. 開発会社へ同じ条件を伝えられる
複数社に同じRFPを渡せば、各社が同じ前提で提案を作ります。比較の土台がそろうため、発注先の判断がしやすくなります。
2. 見積金額を比較できるようになる
対応範囲を明示しておくと、「A社の見積には含まれているが、B社には含まれていない」といった差分を確認できます。金額の差ではなく、範囲の差を見つけられるのがポイントです。
3. 自社の考えを整理できる
RFPを作る過程で、なぜシステムを作るのか、何を優先するのか、いくら使えるのかを社内で整理することになります。RFPは開発会社に渡す資料であると同時に、自社のプロジェクトを固めるための資料でもあります。
4. 認識のズレとトラブルを減らせる
口頭だけで依頼すると、「そこまで対応してもらえると思っていた」「その機能は見積に含まれていない」といった食い違いが起こりがちです。書面で残しておけば、契約後のトラブルを減らせます。
RFI・RFP・要件定義書の違い
RFPと混同されやすいのが、RFI（情報提供依頼書）と要件定義書です。3つは目的も作るタイミングも違います。
- いつ
- 検討の初期
- 目的
- 選択肢を広げる
- 相手に求めるもの
- 製品・技術・実績などの情報
- ひとことで
- 「何ができるのか教えてください」
- いつ
- 開発会社を選ぶ前
- 目的
- 候補を絞り込む
- 相手に求めるもの
- 実現方法・体制・見積の提案
- ひとことで
- 「この条件で、どう実現しますか」
- いつ
- 開発会社の決定後
- 目的
- 作るものを確定させる
- 相手と行うこと
- 機能・画面・データの詳細を詰める
- ひとことで
- 「実際にこう作ります」
要件定義は通常、開発会社と一緒に進めます。RFPの段階で要件定義書レベルまで書き込む必要はありません。
| 項目 | RFI | RFP |
|---|---|---|
| 日本語 | 情報提供依頼書 | 提案依頼書 |
| 目的 | 情報を集める | 具体的な提案を受ける |
| 利用時期 | 検討初期 | 方針が固まった後 |
| 相手に求めるもの | 製品・技術・実績などの情報 | 実現方法・体制・見積などの提案 |
| 自社の状態 | 選択肢を調査している | 要望や条件が整理されている |
| 送付社数の目安 | 3〜5社 | 2〜3社 |
いきなりRFPを作らず、RFIで情報収集から始める方法もあります。詳しくは関連記事「RFIとは？システム開発を初めて依頼する企業向けにRFPとの違い・書き方を解説」をご覧ください。
RFPを作る前に整理したい6つのこと
RFPは、いきなり機能一覧から書き始める資料ではありません。まず次の6つを整理すると、驚くほど書きやすくなります。
- WHYなぜシステムを作るのか業務時間の削減、入力ミスの防止、顧客情報の一元化など。「作ること」を目的にしない
- PROBLEMいま何に困っているのか二重入力、情報の分散、集計に毎月3日、属人化など。事実と数字で書く
- WHO誰が使うのか社員のみか、顧客や取引先も使うか。利用人数と権限の種類も添える
- WHAT何を実現したいのか必要な機能を大まかに。画面仕様まで決める必要はない
- HOW MUCH予算はいくらか「300〜500万円程度」など幅を持たせてよい。伝えないと比較できる提案が来ない
- WHENいつまでに必要か本番稼働の希望時期。実現可能かも含めて提案してもらう
この6つが埋まっていれば、RFPの骨格はほぼ完成しています。あとは形式に落とし込むだけです。
予算は伝えるべきか
「予算を伝えると、その金額いっぱいの見積が出てくるのでは」と心配される方は少なくありません。しかし、予算を伝えないほうがリスクは大きくなります。予算300万円のプロジェクトに1,500万円の提案が届いても、比較対象にすらならないからです。
実務上は、金額そのものより「その範囲で何ができるか」を提案してもらうのが目的だと考えてください。「500〜700万円程度を想定。この範囲で実現できる構成をご提案ください」といった伝え方であれば、各社は優先順位のつけ方まで含めて提案できます。
RFPに記載する16項目（4グループで整理）
RFPに決まった形式はありませんが、一般的には次の項目を記載します。16項目と聞くと多く感じますが、4つのグループに分けて考えると迷いません。
A｜なぜやるのか背景と目的
- プロジェクト概要
- 開発の背景
- 現在抱えている課題
- システム導入の目的
B｜何を作るのかシステムの中身
- 対象業務（対象外も明記）
- 利用者・利用環境
- 必要な機能
- 非機能要件
- 既存システムとの連携
- セキュリティ要件
C｜どんな制約があるのか条件
- 開発体制への要望
- スケジュール
- 予算
D｜どう答えてほしいのか提案・選定のルール
- 提案してほしい内容
- 見積の提示方法
- 選定方法・評価基準
Dのグループは省略されがちですが、ここを書くかどうかで回答の比較しやすさが大きく変わります。
A｜なぜやるのか（1〜4）
プロジェクト名、対象部署、想定利用者などの概要に加えて、背景と課題、そして導入の目的を書きます。課題は事実で、目的は数字で書くのがコツです。
- 課題の例：顧客情報が複数のExcelに分散し、月次集計に3営業日かかっている
- 目的の例：入力作業を50％削減する／営業状況をリアルタイムに把握する
B｜何を作るのか（5〜10）
ここで大切なのが、対象業務と同時に「対象外」も書くことです。範囲が曖昧だと、見積の前提もぶれます。
- 対象：顧客管理／営業案件管理／売上見込み管理
- 対象外：会計処理／給与計算
利用者・利用環境は、利用人数、部署、管理者数、PC／スマートフォンの別、社外からの利用有無を記載します。非機能要件（セキュリティ、表示速度、バックアップ、同時アクセス数、稼働時間、障害対応、データ保存期間など）が分からない場合は、無理に決めず「最適な方法をご提案ください」と書いて問題ありません。
既存システムとの連携（Salesforce、kintone、会計ソフト、基幹システム、Google Workspace、Microsoft 365、決済サービスなど）と、セキュリティ要件（個人情報の有無、IP制限、多要素認証、操作ログの保存など）も、該当があれば必ず記載します。ここは後から発覚すると費用が大きく変わる部分です。
C｜どんな制約があるのか（11〜13）
開発体制については、プロジェクトマネージャー、エンジニア、デザイナー、テスト担当者などの構成を提案してもらいます。あわせて自社で開発するのか、協力会社に再委託するのかも確認しておくと、後の進めやすさが見えてきます。
スケジュールと予算は、次のように幅で示す形で構いません。
- スケジュール例：9月に開発会社決定／10月要件定義／11〜2月開発／3月テスト／4月本番稼働
- 予算例：初期開発費500〜700万円程度、保守費は月額10万円以内を希望
D｜どう答えてほしいのか（14〜16）
提案してほしい内容を番号付きで指定します。これがそのまま提案書の目次になるため、比較が一気に楽になります。
- システム構成
- 実現方法（SaaS／パッケージ／スクラッチの選定理由）
- 使用技術
- 開発体制
- スケジュール
- 見積
- 保守・運用方法
- 類似開発実績
- 想定されるリスクと対策
- その他の提案
見積は、比較しやすいよう工程ごとの内訳で提示してもらいます。要件定義／設計／開発／テスト／インフラ／保守／ライセンスといった区分です。総額だけの見積は、後から範囲の認識違いが起きやすくなります。
選定方法を先に書いておく
「何を重視して選ぶのか」をRFPに明記すると、各社はその軸に沿って提案してきます。提案内容、技術力、実績、開発体制、スケジュール、費用、保守運用、コミュニケーションのうち、自社が重視するものを示しておきましょう。評価が公平になり、社内での説明もしやすくなります。
機能一覧は「優先度」をつけて書く
必要な機能は一覧にします。このとき、すべてを同列に並べるのではなく優先度を分けると、予算内に収める提案を引き出せます。
| 機能 | 内容 | 優先度 |
|---|---|---|
| ログイン | ID・パスワードによる認証 | 必須 |
| 顧客管理 | 顧客情報の登録・編集・検索 | 必須 |
| 案件管理 | 商談状況・進捗の管理 | 必須 |
| 対応履歴 | 電話・メールなどの履歴登録と共有 | 必須 |
| 集計 | 売上見込み・案件数の集計 | 推奨 |
| 権限管理 | 管理者・一般ユーザーの権限設定 | 推奨 |
| CSV出力 | データの一括出力 | 任意 |
| メール送信 | システムからの一斉送信 | 任意 |
優先度をつけておくと、予算が合わないときに「任意の機能を第2フェーズへ回す」といった調整ができます。開発会社側も、段階的な導入を提案しやすくなります。
そのまま使える簡易RFPテンプレート
初めてなら、A4で3〜5枚程度から始めれば十分です。次の内容が埋まっていれば、開発会社から具体的な提案を受けられます。オレンジ字の部分を自社の内容に置き換えてお使いください。
1. プロジェクト概要
- プロジェクト名：顧客管理システム導入プロジェクト
- 会社名：株式会社〇〇／事業内容：〇〇の製造・販売
- 対象部署：営業部・営業管理部
- 担当窓口：〇〇部 〇〇（メールアドレス）
2. 背景
現在、顧客情報および営業案件をExcelで管理していますが、担当者ごとにファイルが分かれており、情報共有と集計に時間がかかっています。営業体制の拡大にともない、情報を一元管理できるシステムの導入を検討しています。
3. 現在の課題
- 担当者ごとにExcelファイルが分かれ、最新版が分からなくなることがある
- 顧客への対応履歴が個人に閉じており、引き継ぎに時間がかかる
- 営業案件の進捗をリアルタイムに把握できない
- 月次の売上見込み集計に3営業日かかっている
4. 導入の目的
- 顧客情報の一元管理と、部署をまたいだ共有
- 営業案件の進捗のリアルタイム把握
- 月次集計作業の自動化（50％以上の時間削減を目標）
5. 対象業務
- 対象：顧客管理／営業案件管理／対応履歴管理／売上見込み集計
- 対象外：会計処理／請求書発行／給与計算
6. 利用者・利用環境
- 営業担当者：約30名／管理者：約5名
- 利用環境：社内PC、および外出先からのスマートフォン利用
- 社外（顧客・取引先）の利用：なし
7. 必要な機能
ログイン／顧客登録・検索／案件管理／対応履歴／売上集計／権限管理（必須）、CSV出力／メール送信（任意）。※詳細は前掲の機能一覧のとおり、優先度を付けて記載します。
8. 非機能要件・セキュリティ
- 取り扱う情報：顧客の会社情報・担当者名・連絡先（個人情報を含む）
- 希望する要件：操作ログの保存、権限に応じた閲覧制限
- その他の非機能要件は、当社の規模・用途に適した構成をご提案ください
9. 既存システムとの連携
Microsoft 365（メール・カレンダー）との連携を希望します。基幹システムとの連携は将来的な検討事項です。
10. スケジュール・予算
- 本番稼働の希望時期：契約から約6か月以内
- 初期費用：500〜700万円程度を想定
- 保守費用：月額10万円以内を希望
11. ご提案いただきたい内容
- 推奨するシステム構成
- SaaS・パッケージ・スクラッチ開発の比較と、推奨する理由
- 使用技術
- 開発・導入スケジュール
- プロジェクト体制（役割・人数・再委託の有無）
- 類似案件の開発実績
- 見積（要件定義／設計／開発／テスト／インフラ／保守の内訳）
- 導入後の保守・サポート内容
- 想定されるリスクと対策
12. 提案の進め方
- 質問受付期限：〇月〇日（メールにて受付）
- 提案書・見積書の提出期限：〇月〇日
- プレゼンテーション：〇月中旬に1社60分程度を予定
- 選定結果の通知：〇月末
- 重視する評価軸：提案内容、類似実績、体制、保守、費用
送付時のメール文例
RFPはどこまで詳しく書けばよい？
「詳細な仕様まで決めなければならないのでは」と考える方もいますが、そこまでの必要はありません。むしろ、システムに詳しくない状態で決めすぎると、より良い提案を受ける機会を失います。
技術的な理由があるなら問題ありませんが、理由がないまま指定すると、より安く早い選択肢が提案されなくなります。
目的と制約だけを示し、実現方法は提案してもらいます。
初めての発注では、「どう作るか」より「何を実現したいか」を明確にするほうが、良い提案につながります。
ただし、譲れない条件は明確に書いてください。個人情報を扱う、既存システムと連携が必要、社外からアクセスする——こうした条件は後から判明すると費用と期間に大きく影響します。「決めるべき制約」と「任せるべき手段」を分けるのが、RFPを書くうえでの勘所です。
送付から選定までの進め方
RFPを作成したら、候補企業に提案を依頼します。一般的な流れとスケジュール感は次のとおりです。
- STEP 1候補企業を選ぶ2〜3社が目安。実績・得意分野・体制を確認して絞る
- STEP 2同じRFPを送付条件をそろえるため、内容は各社共通にする
- STEP 3質問受付期間1週間程度。回答は全社へ共有すると公平になる
- STEP 4提案書・見積の提出送付から3〜4週間の猶予を確保する
- STEP 5プレゼン・面談実際の担当者に会う。書面では見えない部分を確認
- STEP 6評価・選定・通知評価表で採点し、不採用の会社にも結果を連絡する
提案作成には各社とも相応の工数がかかります。期限が短すぎると、力のある会社ほど辞退しやすくなります。
質問の回答は全社に共有する
質問受付期間を設けると、RFPに書き漏れていた前提が浮かび上がります。ある会社からの質問と回答は、匿名化したうえで全社に共有しましょう。条件がそろい、提案の比較精度が上がります。
プレゼンでは「実際の担当者」に会う
提案書だけでは分からないことがあります。プレゼンの場では、営業担当ではなく実際にプロジェクトを担当するマネージャーが同席しているかを確認してください。開発は数か月から年単位の共同作業です。話しやすさや、こちらの業務を理解しようとする姿勢も、重要な判断材料になります。
送付前に確認したい2点
- 機密情報の扱い：業務フローや顧客データの詳細を含む場合は、送付前にNDA（秘密保持契約）を締結します。
- 提案は無償である前提の明記：提案作成にかかる費用の負担有無、提出物の著作権の扱い、本件が発注を確約するものではないことを1行ずつ記載しておくと、後の行き違いを防げます。
提案を比較する7つの視点と評価表
提案が届いたら、価格だけでなく複数の視点で比較します。
- 提案内容／自社の課題に対して適切な解決策になっているか。課題を正しく理解した提案か
- 類似開発実績／同じ業界・似た規模のシステムを手がけた経験があるか
- 技術力／必要な技術を持っているか。そしてなぜその技術を選ぶのか説明できているか
- プロジェクト体制／誰が管理し、どんなエンジニアが担当するか。再委託の有無も含めて
- スケジュール／希望時期に間に合うか。無理のない計画になっているか
- 保守・運用／障害対応、セキュリティ更新、機能追加、問い合わせ対応の体制
- 費用／初期費用だけでなく、月額・保守・ライセンス・クラウド費・将来の改修費まで
これらを100点満点の評価表に落とすと、社内での合意形成がしやすくなります。
| 評価項目 | 配点 | 見るポイント |
|---|---|---|
| 提案内容 | 25点 | 課題を正しく理解し、実現方法に根拠があるか |
| 類似開発実績 | 15点 | 同業種・同規模の経験。具体的な事例を出せるか |
| 技術・開発方法 | 15点 | 技術選定の理由を説明できているか |
| プロジェクト体制 | 15点 | 担当者が明確か。再委託の割合は妥当か |
| スケジュール | 10点 | 希望時期に間に合うか。バッファがあるか |
| 保守・運用 | 10点 | 稼働後の対応範囲と対応時間 |
| 費用 | 10点 | 総保有コスト（初期＋5年分の運用費）で見る |
| 合計 | 100点 |
費用の配点を最大にしないのがポイントです。「プロジェクト全体を成功させられる会社か」という視点で評価します。
評価表は、RFPを送る前に作っておくのが理想です。提案を見てから配点を決めると、無意識に特定の会社に有利な基準を作ってしまいます。
RFPでよくある6つの失敗
1. 機能だけを書いてしまう
「ログイン機能」「顧客管理」「検索機能」といった一覧だけでは、開発会社はなぜその機能が必要なのか分かりません。背景と目的があって初めて、代替案や、より良い方法を提案できます。
2. 目的が書かれていない
「顧客管理システムを作りたい」ではなく、「営業担当者ごとに分散している顧客情報を一元化し、引き継ぎ時間を削減したい」のように、達成したい状態を書きます。
3. 予算をまったく伝えない
予算が未確定でも、「500〜1,000万円程度を想定」といった目安は伝えましょう。伝えないと、検討にすら使えない提案が届きます。
4. 会社ごとに違う条件を伝える
A社には機能Aまで、B社には機能Bも伝えた——これでは見積を比較できません。基本条件は必ず同一にし、追加でやり取りした内容は全社に共有します。
5. 専門用語を無理に使う
RFPを書くのに高度なIT知識は必要ありません。分からない部分を無理に決めるより、「この部分については最適な方法をご提案ください」と書くほうが適切です。
6. 最初から仕様を細かく決めすぎる
開発会社は多くの案件を経験しています。自社だけで仕様を固めすぎると、より安く・早く・使いやすい方法があっても提案されません。目的・課題・譲れない条件を明確にし、実現方法には提案の余地を残すことが重要です。
RFPの作成が難しい場合はどうすればよい？
初めての発注では、次のような状態も珍しくありません。
- 課題は分かっているが、必要な機能に落とし込めない
- どこまでRFPに書けばよいか判断できない
- 見積が届いても、その金額が妥当か分からない
その場合は、開発会社に問い合わせる前に第三者へ相談する方法があります。業務課題の整理、システム化範囲の切り分け、RFI・RFPの作成、候補企業の選定、提案・見積の比較、開発会社との打ち合わせ支援などをサポートしてもらえます。
システム開発では、開発会社を決めてから考えるのではなく、発注する前に「何を実現したいのか」を整理しておくことが、費用にも品質にも効いてきます。
よくある質問
RFPは何ページくらい必要ですか？
初めての中小規模プロジェクトなら、A4で3〜5枚程度から始めて問題ありません。重要なのは分量ではなく、背景・目的・対象範囲・条件・提案してほしい内容が過不足なく書かれているかどうかです。
RFPは何社に送るのが適切ですか？
2〜3社が目安です。提案の受領、質問対応、プレゼン、評価にはそれなりの工数がかかるため、社数を増やしすぎると比較が雑になります。候補が絞れていない場合は、先にRFIで情報収集してから絞り込むのがおすすめです。
提案の提出期限はどのくらい設定すべきですか？
RFP送付から3〜4週間が目安です。提案書と見積の作成には調査や社内調整が必要なため、期限が短すぎると内容の薄い提案が集まったり、辞退されたりします。
RFPを作らずに発注することはできますか？
可能です。小規模な改修や、依頼先が決まっている場合は口頭やメールでの依頼でも進められます。ただし複数社を比較したい場合や、金額が大きい場合は、条件をそろえるためにRFPを作ることをおすすめします。
要件定義書はRFPの後に作るのですか？
はい。要件定義は開発会社を決めた後、その会社と一緒に進めるのが一般的です。RFPの段階で要件定義書レベルまで書き込む必要はありません。
採用しなかった会社にも連絡は必要ですか？
必要です。提案作成には工数がかかっているため、選定結果は早めに連絡しましょう。可能であれば、選ばなかった理由を簡潔に添えると誠実な対応になります。将来別の案件で依頼する可能性もあります。
まとめ｜RFPは開発会社から具体的な提案を受けるための資料
RFPは、システム開発会社に具体的な提案を依頼するための提案依頼書です。作成することで、次のメリットが得られます。
- 自社の課題と目的を整理できる
- 複数の開発会社へ同じ条件を伝えられる
- 提案内容と見積金額を比較できる
- 発注後の認識違いとトラブルを減らせる
初めてのシステム開発、進め方の全体像
- RFIで「選択肢を知る」／3〜5社から実現手段・実績・概算費用を集める（任意）
- 方針・予算・優先順位を固める／社内で何を優先するかを決める
- RFPで「条件を伝えて提案を受ける」／2〜3社に同じ条件を提示する
- 提案・見積を比較する／評価表で採点し、費用だけで判断しない
- 開発会社を決め、要件定義へ進む
「どんなシステムにすべきか分からない」「どんな開発方法があるのか分からない」という段階であれば、いきなりRFPを作らず、RFIによる情報収集から始める方法もあります。
システム開発は、開発会社を決める前の準備によって、その後の費用・期間・完成するシステムの品質が大きく変わります。RFPは単なる発注資料ではなく、プロジェクトを成功させるために自社の目的と条件を整理する資料として活用してください。
