RFP は「発注側の意思と前提を、社外に共通言語で伝える書類」

「複数の開発会社から提案をもらいたいが、何を渡せばいいのかわからない」——初めてシステム開発を発注する担当者が、最初にぶつかる壁が RFP (提案依頼書) です。RFP は単なる仕様の一覧ではなく、発注側の意思と前提を、社外に共通言語で伝える書類です。ここが曖昧なまま相見積を取ると、各社バラバラな前提で見積が返ってきて、比較できなくなります。

この記事では、非エンジニアの発注担当者でも書ける RFP の構造と、最低限盛り込むべき 10 項目、そして「開発会社が見積しやすい」RFP に共通する書き方のコツを、NG 例と OK 例をつけて整理します。社内ヒアリングからドラフト、レビューまでの進め方と、そのまま流用できる目次サンプルも掲載しています。

1. RFP と RFI・RFQ の違いと使い分け

RFP は「提案依頼書 (Request For Proposal)」の略ですが、実務では RFI や RFQ と混同されがちです。まず役割を整理しておきます。

略称正式名称目的発注側が知りたいこと
RFIRequest For Information情報提供依頼どんな会社があるか、実績と体制
RFPRequest For Proposal提案依頼どう実現するか、体制と概算費用
RFQRequest For Quotation見積依頼確定した要件に対する正式見積
  • RFI は、まだ発注先候補が絞れていない段階で「御社は何ができますか」を聞くもの
  • RFP は、候補を数社に絞り「この課題をどう解きますか、いくらでできますか」を提案してもらうもの
  • RFQ は、要件がほぼ確定した状態で「この仕様どおりに作るといくらか」を金額提示してもらうもの

多くの発注案件では、RFI と RFP を 1 つにまとめて「RFP と呼ぶ」実務が一般的です。まずは RFP で各社の提案スタイルと概算を把握し、フェーズが進んでから RFQ で金額を確定させる二段構えが安全です。概算と本見積の違いは 概算見積と本見積の違い でも解説しています。

2. RFP に盛り込むべき 10 項目

過剰に詳細な仕様書は不要ですが、次の 10 項目が抜けている RFP は、開発会社側で見積の前提を作れず、返ってくる金額の精度が大きく下がります。

(1) 目的・ゴール

このプロジェクトで何を達成したいかを、事業側のゴールで表現します。売上、業務工数削減、顧客満足度など、事業指標を最初に置きます。

(2) 背景・現状の課題

なぜ今このシステムが必要なのかを、現状の業務フローや既存システムの問題点とともに、時系列で簡潔にまとめます。

(3) スコープ (対象範囲)

作るもの・作らないもの、対象ユーザー、対象業務を書きます。範囲外を明示することが特に重要です。

(4) 機能要件

必要な機能の一覧を、画面単位・業務単位で列挙し、優先度 (必須・推奨・将来) をつけます。

(5) 非機能要件

同時利用ユーザー数、応答速度、稼働時間、セキュリティ水準、対応ブラウザなどです。詳細は 非機能要件が見積に与える影響 でも扱っています。

(6) 想定体制・役割分担

発注側の窓口担当、意思決定者、レビュー体制、開発会社側に期待する役割 (要件定義から任せるのか、設計から任せるのか) を書きます。

(7) スケジュール・マイルストーン

希望リリース時期、途中のレビュータイミング、社内イベントとの関係を書きます。

(8) 予算感 (レンジで可)

「1,000〜2,000 万円で検討中」のようにレンジで示せると、開発会社は現実的な提案を組みやすくなります。予算を隠すと、逆に前提の合わない提案が量産されます。

(9) 成果物

要件定義書・設計書・ソースコード・テストレポート・運用マニュアルなど、納品物として何を求めるかを書きます。

(10) 評価基準・選定プロセス

何を基準に決めるか (提案内容・実績・体制・金額)、いつまでに回答が欲しいか、面談は行うかを書きます。

3. 各項目の書き方のコツ (NG 例・OK 例)

RFP の巧拙は、抽象度のコントロールで決まります。「使いやすいシステム」は書いてはいけない典型ワードです。

目的・ゴールの書き方

  • NG: 「業務効率化のためのシステムを開発したい」
  • OK: 「現状月 40 時間かかっている受発注入力を、月 10 時間に短縮する」

数字を 1 つ入れるだけで、開発会社は工数の当てどころが変わります。

スコープの書き方

  • NG: 「販売管理システム全般」
  • OK: 「対象は受注入力・出荷指示・請求書発行。対象外は会計連携 (既存 freee に手動連携のまま)」

「対象外」を書ける RFP は、それだけで発注担当者の解像度が高いと見なされます。

機能要件の書き方

  • NG: 「顧客管理機能」
  • OK: 「顧客一覧・詳細・登録・編集の 4 画面。CSV インポート 1 万件対応。担当者ごとの閲覧制限あり」

画面数と条件を明示するだけで、見積工数が具体化します。

非機能要件の書き方

  • NG: 「サクサク動くこと」
  • OK: 「同時利用 200 人、主要画面の表示 3 秒以内、平日 9〜18 時稼働保証」

数値化できないものは書かない、というルールでも問題ありません。

予算感の書き方

  • NG: 「予算は特に決めていません」
  • OK: 「初期開発 1,500 万円 ±20%、保守年額 300 万円 ±20% を想定」

予算を書けない場合でも、「上限」や「稟議通過ライン」だけでも示すと、提案の質が上がります。

FIXITFIXIT

RFP に予算書くと、そこまで積んで請求されそうで不安なんだけど。

ShioriShiori

実際は逆で、書かないほうが「安全側」に振った高い見積が返ってきます。

FIXITFIXIT
じゃあレンジで書けばいいの？
ShioriShiori

はい。上限だけでも示せれば、その中で最適解を出す提案競争に持ち込めます。

FIXITFIXIT
「稟議通過ライン」って書き方でもいい？
ShioriShiori

十分です。数字が 1 つ入るだけで、返ってくる提案の解像度が変わります。

4. 「見積しやすい RFP」に共通する 4 つの特徴

これまで開発会社が受け取ってきた RFP を俯瞰すると、「これは見積しやすい」と評価される書類には共通点があります。

(1) 前提と制約が最初に書かれている

「既存の基幹システムには手を入れない」「社内 SSO は必須」など、動かせない条件が冒頭にあることです。

(2) やらないことが書いてある

やることの一覧より、やらないことの明示のほうが、見積精度に効きます。

(3) 優先度が 3 段階で示されている

「必須・推奨・将来」の 3 段階だけで十分です。全部「必須」の RFP は、スコープ調整の余地がなく、結果として高額になります。

(4) 意思決定者と締切が明記されている

「◯月◯日までに書面提出、翌週プレゼン、翌々週内示」のように、選定プロセスが読めることです。

これらを満たす RFP には、開発会社から「精度の高い概算」と「代替案付きの提案」が返ってきやすくなります。

5. RFP 作成の進め方 (社内ヒアリング → ドラフト → レビュー)

RFP は 1 人で書き切るものではありません。実務では次の 3 ステップで進めるのが安全です。

ステップ 1: 社内ヒアリング (2〜3 週間)

  • 現場責任者: 業務フローと現状の困りごと
  • 情シス: 既存システムと連携要件、セキュリティポリシー
  • 経営・管理部門: 予算枠、投資判断の基準

このフェーズで業務フロー図と画面遷移案の下書きまで作れると、後の工程が格段に楽になります。作り方は 業務フロー・画面遷移案の作り方 で解説しています。

ステップ 2: ドラフト作成 (1〜2 週間)

前述の 10 項目テンプレに沿って埋めます。この時点では 8 割の粒度で構いません。空欄には「未確定」と明記しておくと、レビュー時に議論の焦点になります。

ステップ 3: 社内レビュー・調整 (1〜2 週間)

情シス・法務・経営層のレビューを受けます。ここで「予算レンジをどこまで開示するか」「知的財産権の帰属をどう書くか」などの論点が出るため、事前の想定質問リストがあると効率的です。

準備の全体像は 発注前に整理すべきこと にまとめています。

6. RFP テンプレの目次サンプル

そのまま流用できる、A4 で 10〜20 ページ規模の RFP 目次サンプルです。

1. プロジェクト概要
   1.1 目的・ゴール
   1.2 背景・現状の課題
   1.3 スコープ (対象・対象外)
2. 要件
   2.1 機能要件 (画面一覧・優先度)
   2.2 非機能要件
   2.3 データ・既存システム連携要件
3. 体制・スケジュール
   3.1 発注側体制
   3.2 開発会社に期待する役割
   3.3 マイルストーンとリリース希望時期
4. 予算・契約条件
   4.1 想定予算レンジ
   4.2 契約形態の希望 (請負・準委任)
   4.3 知的財産権・機密保持
5. 提案依頼事項
   5.1 提案内容 (アプローチ・体制・見積)
   5.2 会社概要・実績
   5.3 見積内訳の粒度
6. 選定プロセス
   6.1 スケジュール (提出→プレゼン→内示)
   6.2 評価基準
   6.3 問い合わせ窓口

そのまま A4 に落とすと 10 ページ前後、詳細を書き込むと 20 ページ程度になります。中規模案件 (1,000〜3,000 万円) ではこの粒度が実用的です。

コツ

RFP は「発注担当者が要件を完璧に固める書類」ではなく、「発注側の意思と制約を、社外に読みやすく渡す書類」です。空欄には「未確定」と明記し、優先度と対象外を書き切ることを、細部の完璧さより優先してください。

まとめ

RFP は「発注側の意思と前提を、社外に共通言語で伝える書類」です。10 項目のうち、目的・スコープ・非機能要件・予算レンジ・意思決定プロセスが特に効きます。「やらないこと」と「優先度」を書ける RFP は、見積精度が跳ね上がります。1 人で書くのではなく、社内ヒアリング → ドラフト → レビューの 3 ステップで、社内の関係者を巻き込みながら進めるのが安全です。

AI 駆動開発のクリエイティブスタジオである FIXIT では、RFP 作成の段階から発注担当者と一緒にドラフトを整理し、社内レビュー用のたたき台までご提供する形で相談を受けています。「RFP をどう書き始めるかから相談したい」という方は 無料相談 からお気軽にご連絡ください。進め方の全体像は AI 駆動開発サービス もあわせてご覧ください。