「RFPを作っておいて」と言われたものの、社内に前例がない。テンプレートを探して開いてみたが、項目は分かっても自社の内容が埋まらない。そもそも要件が固まっていないのに、書けるものなのか——システム開発の発注が決まった直後に、こうした状態で止まってしまう方は多いと思います。
先に結論を書きます。RFPの出来を決めるのは文章力ではありません。目的・予算・評価基準の3点を先に決めたかどうかです。この3つが決まっていれば、残りの項目は現状の説明にすぎず、時間をかければ書けます。逆にこの3つが空欄のままテンプレートを埋めると、各社の提案は前提がばらばらになり、比較できない資料が何通も届くことになります。
もうひとつ、安心していただきたいことがあります。要件が固まっていないのは、まったく問題ではありません。むしろ、決まっていない範囲を正直に明示してあるRFPのほうが、提案の精度は上がります。曖昧なまま伏せられるより、「ここは未確定なので、仮にこの前提で提案してください」と書かれているほうが、提案する側は具体的に考えられるからです。
私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、2018年以降、約100社のご相談を受けてきました。当社は提案を受け取る側でもあります。届くRFPを見ていると、提案しやすいものには共通点があります。現状の業務フローが1枚で共有されていること、予算の上限と評価の配点が書かれていること、決まっていない範囲が明示されていること、質疑の窓口と期間が決まっていること。当社は実務3年1,500USD、5年2,000USD、ブリッジSE3,000USD(1USD=150円換算が目安)と単価を公開しているため、予算が書かれていれば体制と工数をその場で組み立てられます。
この記事では、RFPとRFI・RFQ・要件定義書の違い、書く前に決める3点、記載する9項目の「書くこと」と「書かないこと」、そのまま使える目次の形、そして配布後の評価基準と提案の比べ方を順に整理します。読み終えたら、まず目次だけ作ってみてください。関係者に確認するのは、目的・予算の上限・評価基準の3点だけで足ります。
目次
- RFPを書く前に決める3つ
- RFP・RFI・RFQ・要件定義書の違い
- 先に決める3点と、決まっていなくてよいこと
- 提案する側から見た、答えやすいRFP
- RFPに書く9項目
- 9項目に何を書くか
- 解き方まで書かない
- そのまま使える目次の形
- 配布後——評価基準の作り方と、提案の比べ方
- 評価基準と配点を先に決める
- 提案を同じ土俵に載せる
- よくある失敗と避け方
- よくある質問
- Q1. RFPは何ページくらいが適切ですか
- Q2. 何社に配ればよいですか
- Q3. 提案までどのくらいの期間を見るべきですか
- Q4. RFPの作成そのものを相談できますか
- Q5. 要件が固まらないまま提案を依頼してもよいですか
- まとめ: RFPは文章力ではなく、目的・予算・評価基準の3点で決まる
RFPを書く前に決める3つ——目的・予算・評価基準

RFPは提案依頼書です。ベンダーに「こういう状況なので、解き方を提案してください」と伝える文書であり、仕様を確定させる文書ではありません。ここを取り違えると、書けるはずのないものを書こうとして手が止まります。
RFP・RFI・RFQ・要件定義書の違い
似た用語が並ぶので、先に整理します。
文書 | タイミング | 目的 | 誰が書くか |
|---|---|---|---|
RFI(情報提供依頼書) | 候補を探す段階 | 各社の実績・得意領域・概算感を集める | 発注者 |
RFP(提案依頼書) | 候補を絞った段階 | 解決策・体制・金額の提案を求める | 発注者 |
RFQ(見積依頼書) | 仕様が固まった段階 | 決まった内容の価格を求める | 発注者 |
要件定義書 | 受注後の最初の工程 | 作るものを確定させる | 受注者(発注者が確認) |
要件定義は受注後の工程です。RFPの段階で要件が固まっていないのは当たり前だと考えてください。
先に決める3点と、決まっていなくてよいこと
RFPの質を決めるのは、次の3点です。
ひとつ、目的。何のためにシステムを作るのか、どうなれば成功なのかを1文か2文で書きます。「受注入力の二重手間をなくし、月次の締めを3営業日短縮する」といった粒度で十分です。ふたつ、予算。上限額と、超える場合の判断の仕方を書きます。みっつ、評価基準。何を重視して選ぶのかと、その配点です。
一方で、決まっていなくてよいものもあります。細かい画面仕様、データ項目の定義、使用する技術、細部の業務ルール。これらは提案と要件定義の中で固めるものです。決まっていない部分は「未確定。仮に○○という前提で提案してください」と書けば、提案する側は具体的に考えられます。
提案する側から見た、答えやすいRFP
当社も提案を受け取る側です。2018年以降、約100社のご相談を受けてきましたが、提案しやすいRFPには共通点があります。現状の業務フローが1枚で共有されていること。予算の上限と評価の配点が書かれていること。決まっていない範囲が明示されていること。質疑応答の窓口と期間が決められていること。
逆に、機能一覧だけが200行並んでいて目的が書かれていないRFPだと、提案は無難な内容に寄ります。目的が分からなければ、優先順位もつけられないからです。3点が決まったら、あとは項目を埋めていく作業になります。
RFPに書く9項目——「書くこと」と「書かないこと」

ここからは中身です。項目は9つで足ります。大事なのは、それぞれに「書かないこと」があるという点です。書きすぎたRFPは、提案を引き出す文書ではなく、指示書になってしまいます。
9項目に何を書くか
項目 | 書くこと | 書かないこと |
|---|---|---|
1. 背景 | 会社と事業の概要、なぜ今このプロジェクトなのか | 社内の政治的な事情、他部門への不満 |
2. 目的とゴール | 解決したい課題、成功の状態(数値があればなお良い) | 手段の指定(「◯◯というツールを使って」) |
3. 現状の課題と業務 | 業務フロー1枚、現行システムと連携先、データ量 | 詳細な業務マニュアルの全文 |
4. 対象範囲(スコープ) | 今回作る範囲、将来やる範囲、対象外 | 曖昧な「など」「等」での拡張余地 |
5. 機能要求 | 必須機能と、あれば嬉しい機能の区別 | 画面レイアウトやDB設計の指定 |
6. 非機能要求 | 想定ユーザー数、同時接続、稼働時間、セキュリティ要件 | 具体的なサーバー構成の指定 |
7. 予算 | 上限額、予算の期(いつの予算か)、超過時の判断 | 「応相談」だけの記載 |
8. スケジュール | 提案の締切、選定時期、開始と公開の希望時期 | 根拠のない短納期 |
9. 提案依頼事項と選定基準 | 提案してほしい内容、評価軸と配点、契約形態の希望、機密保持 | 評価基準を伏せること |

7番の予算は、伏せると損をします。上限が分かれば、提案する側はその範囲で最大の構成を組みます。当社は実務3年1,500USD、5年2,000USD、ブリッジSE3,000USD(1USD=150円換算が目安)と単価を公開しているので、予算が書かれていればその場で体制と工数を組み立てられます。予算を伏せたまま提案を求めると、各社が想定する規模がばらつき、比較の土俵が崩れます。
9番には、契約形態の希望も書いてください。ただし決め打ちにせず、「請負・準委任のいずれが適切かも含めて提案してください」と書くのがおすすめです。要件の固まり具合によって、適した形は変わるからです。機密保持については、NDAの締結時期と、再委託を認めるかどうかの方針も触れておくと、提案の前提がそろいます。なお、契約形態についての本記事の記述は一般的な整理であり、法的助言ではありません。個別の契約の判断は弁護士にご確認ください。
解き方まで書かない——提案の幅を残す線引き
ここが最も差がつくところです。目的と課題を書き、解き方は提案してもらう。この線を守ると、各社の考え方の違いが提案に表れます。逆に手段まで指定すると、全社が同じ構成を出してきて、結局は総額の比較になります。せっかく複数社に声をかける意味がなくなってしまう。
たとえば「在庫の引き当てを自動化したい」は目的です。「バッチ処理を毎晩2時に実行して在庫テーブルを更新する」は解き方です。後者を書いた瞬間、より良い設計を提案する余地は消えます。判断に迷ったら、その記述が業務の要求か技術の手段かを自問してください。手段なら、書かずに残す。
そのまま使える目次の形
目次はこの形で十分です。1.はじめに(背景・目的) 2.現状(業務フロー・システム構成・課題) 3.本プロジェクトの範囲 4.要求事項(機能・非機能) 5.制約条件(環境・法令・社内規程) 6.予算とスケジュール 7.提案依頼事項 8.評価基準と選定プロセス 9.提出要領と問い合わせ窓口 10.機密保持と契約に関する事項。
未確定の項目は、空欄にせず「未確定」と書きます。書き方の例を挙げると、「対象拠点は3拠点を想定していますが、5拠点への拡張可能性があります。3拠点を前提とした提案に加え、拡張時の追加費用の考え方をご提示ください」。これで提案する側は動けます。書かないことを決めるのも、RFPの設計のうちです。
配布後——評価基準の作り方と、提案の比べ方

RFPを配って終わりではありません。むしろ、ここからが選定の本番です。提案を読む前に評価表を作っておくこと、そして提案を同じ土俵に載せることの2つが要になります。
評価基準と配点を先に決める
私は人材業界の出身で、採用の選考設計にも携わってきました。採用でもシステム調達でも、評価軸を後から作ると、印象の良かった候補に合う軸を無意識に選んでしまいます。これを避ける方法はひとつで、提案を読む前に配点を決めることです。
配点の例を挙げます。
評価軸 | 配点 | 見るポイント |
|---|---|---|
課題の理解度 | 25点 | 自社の業務と課題を正しく捉えているか。質問の質 |
解決策の妥当性 | 25点 | 目的に対する手段が適切か。段階的に進める設計か |
体制と進め方 | 20点 | 誰がアサインされるか。PMの経験。会議と報告の設計 |
実績 | 10点 | 類似の業務領域・規模の経験 |
費用 | 15点 | 総額と、前提条件の明確さ |
保守と拡張性 | 5点 | 稼働後の体制、引き継ぎのしやすさ |

費用の配点を100点中15点程度に抑えているのは意図的です。費用は分かりやすいため、比重を上げすぎると実質的に価格競争になります。当社の場合、提案の段階で契約前の面談を設定し、実際にアサインするメンバーと話していただくようにしています。1名から最短2週間で開始でき、増員は約1週間という体制も、この段階で具体的にお伝えします。
提案を同じ土俵に載せる
質疑応答は、個別回答ではなく全社共有にしてください。1社からの良い質問への回答を全社に配ると、提案の前提がそろいます。逆に個別に答えると、情報量の差がそのまま提案の差になり、比較の公平さが崩れます。
提案が出そろったら、総額の前に前提条件を確認します。データ移行は含まれるか、外部連携の調査は範囲内か、受入テストの支援はあるか、保守は別見積もりか。抜けがある提案は安く見えます。範囲をそろえて再見積もりを依頼すると、当初は倍に見えた差が大きく縮むことは珍しくありません。
当社も、伺った内容から体制が合わないと判断すれば、その旨を率直にお伝えします。提案の辞退も含めて、早く伝えることが発注者の時間を守ることだと考えているからです。
よくある失敗と避け方
最後に、つまずきやすい点を4つ挙げます。ひとつ、機能一覧だけを送ること。目的がないと優先順位が提案に反映されません。ふたつ、予算を伏せること。規模の前提がばらつきます。みっつ、評価基準を後から作ること。印象で決まります。よっつ、質疑を個別に返すこと。公平さが崩れます。
いずれも、RFPを書く前の3点——目的・予算・評価基準——を決めていれば避けられるものばかりです。あなたの評価表は、提案を読む前に作れていますか。
よくある質問

RFPの作成について、実務でよく届く質問に答えます。いずれも、初めて提案依頼書を作る担当者から繰り返し聞かれる内容です。
Q1. RFPは何ページくらいが適切ですか
適切なページ数を示した公的な基準はありません。分量よりも、目的・予算・評価基準が明記されているかが重要です。業務フローや現行システムの構成は、図か別紙にすると読みやすくなります。
Q2. 何社に配ればよいですか
配布先の数に決まった正解はありません。提案の作成には各社とも相応の工数がかかるため、やみくもに数を増やすと一社あたりの作り込みが浅くなり、読み比べる側の負担も増えます。事前にRFIで候補を絞り、本当に依頼したい会社だけに配るのが現実的です。当社では、候補を絞る段階の要件整理からご相談をお受けしています。
Q3. 提案までどのくらいの期間を見るべきですか
一律の目安はありません。要件の量と、既存システムの調査がどこまで必要かで変わります。提案に何を書いてほしいかを先に固め、その作業量から逆算して期限を切ってください。あわせて質疑応答の期間を別に設け、回答は全社に共有します。期間が短すぎると、提案が既存の型の流用になり、比較する意味が薄れます。
Q4. RFPの作成そのものを相談できますか
当社は日本人PMがフロントに立ち、要件の整理や仕様の文書化を担っています。RFP段階の壁打ちにも対応しています。最小構成は日本人PM+2〜3人月で月額約80万円からですが、初回のご相談と概算のご提示は無料です。
Q5. 要件が固まらないまま提案を依頼してもよいですか
問題ありません。未確定の範囲を明示し、仮の前提を置いて提案を求めてください。曖昧なまま伏せるより、提案の精度が上がります。決まっていないことを書く勇気。
まとめ: RFPは文章力ではなく、目的・予算・評価基準の3点で決まる
RFP(提案依頼書)は、仕様を確定させる文書ではありません。現状と課題を渡し、解き方を提案してもらうための依頼書です。要件定義は受注後の工程ですから、RFPの段階で要件が固まっていないのは当たり前だと考えてください。決まっていない範囲は「未確定。仮にこの前提で提案してください」と明示するほうが、提案の精度は上がります。
書く前に決めるのは3点です。目的(何のために作り、どうなれば成功か)、予算(上限額と超過時の判断)、評価基準(何を重視し、どう配点するか)。この3つが決まれば、残りは現状の説明です。記載する項目は9つ。背景、目的とゴール、現状の課題と業務、対象範囲、機能要求、非機能要求、予算、スケジュール、提案依頼事項と選定基準。それぞれに「書かないこと」があり、とくに解き方の指定は避けてください。手段まで書くと各社の提案が横並びになり、複数社に声をかけた意味が薄れます。
配布後は、提案を読む前に配点を固めます。課題の理解度25点、解決策の妥当性25点、体制と進め方20点、実績10点、費用15点、保守と拡張性5点といった配分が一例です。費用の比重を上げすぎると価格競争になります。質疑応答は個別ではなく全社共有にし、提案が出そろったらデータ移行・外部連携・受入テスト支援・保守が含まれるかを確認してから比べてください。見積書の読み方はシステム開発の見積もりの内訳、契約形態の選び方はラボ型開発とSESの違いもあわせてご覧ください。当社は単価を公開しており、予算が書かれていれば体制と工数をその場で組み立てられます。最小構成は日本人PM+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。RFPの段階からご相談いただけますので、現在の体制と要件をお聞かせください。合わない案件にはその旨も率直にお伝えします。