システム開発を外部に発注するとき、「何をどこまで書いて渡せばいいのか」で止まる担当者は多い。RFP（提案依頼書）はそのための文書だが、世の中の解説の大半は「発注側がどう書くか」の視点で書かれている。この記事は、RFPを受け取って提案書と見積書を返す側（受託開発会社）から見て、どう書かれたRFPが良い提案を引き出すのかを軸に整理する。
この記事でわかること
- RFP・RFI・RFQの違いと、どの順番で出すべきか
- RFPに必ず書くべき11項目と、書かなくてよい項目
- 受注側が「見積もれない」と判断するRFPの共通点
- RFPを出す場合と出さない場合で、見積もりの精度がどう変わるか
- 提案を比較するための評価表の作り方
結論：RFPは「発注者の要望リスト」ではなく「提案の採点条件」
Photo by Scott Graham on Unsplash
先に結論を書く。RFPの目的は、要望を漏れなく伝えることではない。複数社から返ってくる提案を、同じ土俵で比べられる状態にすることである。
同じ課題を投げても、A社は「パッケージ導入で3か月」、B社は「スクラッチで9か月」と返してくることがある。どちらが正しいかは、発注側が「何を重視するか」を先に示していない限り決められない。RFPが担うのはそこであり、機能の羅列ではない。
したがって、RFPの良し悪しは次の1点で決まる。
提案を受け取ったとき、そのRFPだけを根拠に優劣を説明できるか。
説明できないなら、その項目はRFPに書く必要がなかったか、逆に必要な項目が抜けている。
RFPとは何か（提案依頼書の定義と目的）
Photo by Rodeo Project Management Software on Unsplash
RFPは Request For Proposal の略で、日本語では提案依頼書という。システムやサービスの導入にあたり、発注側が候補となるベンダーに対して「こういう課題があるので、解決策と費用を提案してほしい」と依頼する文書である。
RFPが果たす役割は3つある。
- 前提を揃える — 全社に同じ情報を渡すことで、提案の差が「解釈の差」ではなく「実力と方針の差」になる。
- 評価軸を先に決める — 提案が出てから評価軸を作ると、最初に読んだ提案に引きずられる。
- 社内の合意を作る — RFPを書く過程で、情報システム部門と業務部門の認識のズレが表面化する。実務ではこの効果が一番大きい。
3つ目は軽視されやすいが重要である。RFPを書き始めると「その業務、今は誰がどうやっているのか」が必ず問われる。ここで詰まる場合、ベンダーを探す前に社内整理が必要という信号になる。業務の現状整理から入るなら、業務フロー図の作り方を手順・記号・テンプレートから解説した記事が実務の入口になる。
RFP・RFI・RFQの違いと出す順番
Photo by Carrie Allen www.carrieallen.com on Unsplash
混同されやすい3つを整理する。
| 文書 | 正式名称 | 目的 | 出すタイミング | 相手から返ってくるもの |
|---|---|---|---|---|
| RFI | Request For Information（情報提供依頼書） | 市場・製品・ベンダーの情報収集 | 構想段階。何ができるか分からない時 | 会社概要、製品資料、実績、概算レンジ |
| RFP | Request For Proposal（提案依頼書） | 課題に対する解決策と費用の提案依頼 | 課題と予算感が固まった後 | 提案書、体制、スケジュール、見積書 |
| RFQ | Request For Quotation（見積依頼書） | 仕様が確定したものの価格提示依頼 | 仕様がほぼ固まった後 | 見積書（価格が主） |
順番は RFI → RFP → RFQ が原則
「RFPとRFIはどちらが先か」という問いへの答えは、RFIが先である。ただし、これは必ず3段構えにするという意味ではない。
- RFIを飛ばしてよい場合：候補ベンダーが既に3〜5社に絞れている。業界の相場観がある。過去に類似案件の経験がある。
- RFIを挟むべき場合：解決策の形が決まっていない（パッケージなのかスクラッチなのかSaaSなのかも未定）。初めての領域。候補が10社以上ある。
- RFQまで進む場合：仕様が確定していて、あとは価格と納期の比較だけ。システム開発では、RFQ単独で成立することは少ない。要件が動く前提の案件だからである。
実務では RFI → RFP の2段階、あるいは RFPのみ が大半になる。RFQはハードウェア調達やライセンス購入のように、モノが確定している調達で使われる。
RFP・RFI・RFQの順番を決める簡易判定
次の3問に答えると、どこから始めるべきかが決まる。
- 解決策の方式（スクラッチ／パッケージ／SaaS）を1つに絞れるか → 絞れない：RFIから
- 候補ベンダーを5社以内に挙げられるか → 挙げられない：RFIから
- 機能一覧と非機能要件が文書になっているか → なっている：RFQでも可／なっていない：RFPから
RFPには何を書くべきか｜必須11項目
上位の解説記事は項目を列挙して終わることが多い。ここでは各項目が「提案のどこに効くか」を併記する。効かない項目は書かなくてよい、という判断がつくようにするためである。
| # | 項目 | 内容 | 提案のどこに効くか |
|---|---|---|---|
| 1 | 背景・目的 | なぜ今やるのか。経営上の位置づけ | 提案の方向性そのもの。ここが薄いと全社が無難な提案になる |
| 2 | 現状の課題 | 業務・システムの具体的な困りごと | 解決策の妥当性。数値があると提案の精度が上がる |
| 3 | 対象範囲（スコープ） | 対象業務・部署・拠点。対象外も書く | 見積金額。最も差が出る項目 |
| 4 | 要求機能 | 実現したいこと（機能仕様ではない） | 工数見積もり |
| 5 | 非機能要件 | 性能・可用性・セキュリティ・運用時間 | インフラ構成と保守費用 |
| 6 | 現行システム情報 | 使用技術、データ量、連携先 | 移行工数。抜けると見積もりが崩れる |
| 7 | 予算 | 上限または想定レンジ | 提案の実現方式。書かないと比較不能な提案が集まる |
| 8 | スケジュール | 稼働希望日と、その理由 | 体制規模と実現可否 |
| 9 | 体制・役割分担 | 発注側が出せる人員と権限 | プロジェクトの成立性 |
| 10 | 評価基準 | 何を重視して選ぶか（配点があると尚可） | 提案の力点 |
| 11 | 提出要領 | 提出期限、様式、質問受付方法、選定スケジュール | 参加可否の判断 |
予算を書くべきか、という論点
「予算を書くと上限まで積まれる」という理由で伏せる発注側は多い。受注側の立場から言うと、これは逆効果になりやすい。
予算が示されないと、受注側は「外されない金額」を出すか、「実現可能な最小構成」を出すかの二択になる。前者は高く、後者は要望を満たさない。結果として、比較すべき提案の粒度が揃わない。
現実的な折衷案は次のとおりである。
- 上限額そのものではなく、レンジで示す（例：初期費用3,000万〜5,000万円を想定）
- 初期費用と年間運用費を分けて示す
- 「この範囲を超える提案は、超える理由と効果を明記すること」と条件を付ける
費用感がそもそも掴めていない場合は、システム開発の費用相場と内訳、見積もりの妥当性を判断する方法とシステム開発の人月単価の職種別相場で、レンジの根拠を先に持っておくとよい。
書かなくてよい項目
逆に、RFPに書くと提案の質を下げるものもある。
- 画面レイアウトの詳細指定 — 提案段階で固めると、より良い設計案が出てこなくなる。
- 特定製品・特定技術の指名（正当な理由がある場合を除く） — 指名した時点で提案ではなく見積依頼になる。
- 社内用語のままの業務名 — 用語集を添えるか、一般名詞に直す。
- 実現手段の細かい指定 — 「〜すること」ではなく「〜できること」で書く。
受注側が「これは見積もれない」と判断するRFPの共通点
ここが、この記事で最も伝えたい部分である。提案を辞退する、あるいは高いバッファを積むRFPには、はっきりした共通点がある。受託開発の現場で繰り返し見てきたパターンを挙げる。
1. スコープの「対象外」が書かれていない
対象業務は書いてあるが、対象外が書かれていない。受注側は「書かれていないものは含まれるかもしれない」と読む。結果、リスク分の金額が上乗せされる。対象外リストは、対象リストと同じくらい金額に効く。
2. 現行システムの情報が「ヒアリングで開示」になっている
データ量、テーブル数、連携先の本数、使用しているミドルウェアのバージョン。これらが提案時点で不明だと、移行工数が見積もれない。移行はプロジェクト全体の工数を大きく振らせる要素であり、ここが空欄のRFPは、金額の信頼度がそもそも低い提案しか集められない。
3. 稼働希望日に理由がない
「4月稼働希望」とだけ書かれている場合と、「4月に法改正が施行されるため、3月末までに本番切替が必要」と書かれている場合では、提案が変わる。理由があれば、受注側は期日から逆算して削れる範囲を提案できる。理由がなければ、期日を守るための人員追加＝金額増でしか答えられない。
4. 発注側の体制が書かれていない
システム開発は、発注側の意思決定の速さでスケジュールが決まる部分が大きい。誰が要件を決めるのか、その人はどれくらいの時間を割けるのか、決裁は何営業日かかるのか。ここが不明な案件は、受注側から見るとリスクが高い。役割分担の考え方は要件定義は誰がやるのか、発注者と受注者の役割分担を実務目線で解説した記事に整理してある。
5. 質問の受付期間が短すぎる、または質問を受け付けない
提案期間が2週間で、質問受付が最初の3日だけ、というRFPは珍しくない。前提が確認できないまま提案を書くと、受注側は安全側に倒す。質問受付とその回答の全社共有は、提案の質を上げるうえで最も費用対効果が高い工程である。
受け取ったRFPで良い提案が集まるか、第三者に確認したい方へ
シンシアでは、システム開発の受託側としてRFPを日常的に読んでいる立場から、RFPドラフトのレビューや、提案・見積もりのセカンドオピニオンを無料で承っています。要件が固まっていない段階でも構いません。
RFPは誰が書くのか
「RFPは誰が書きますか」という質問への実務的な答えは、情報システム部門が事務局、業務部門が内容の主、経営層が目的と予算の承認という三者分担である。
| 担当 | 書く部分 |
|---|---|
| 業務部門 | 背景・現状の課題・要求機能・対象範囲 |
| 情報システム部門 | 現行システム情報・非機能要件・提出要領・評価基準の設計 |
| 経営層／決裁者 | 目的の位置づけ・予算レンジ・稼働希望日の妥当性承認 |
| 外部（コンサル／開発会社） | 書き方の型、非機能要件の抜け確認、相場観の提供 |
外部の支援を入れる場合、提案に参加する会社にRFP作成を依頼すると公平性が崩れる。RFP作成を支援した会社は選定から外すか、支援内容を全候補に開示するのが原則である。
情シス部門が存在しない、あるいは1〜2名という中小企業では、この分担が成り立たないことが多い。その場合は、RFPを完璧に作ろうとせず、RFIで数社から情報を集めてからRFPの骨格を作る方が現実的である。
RFPの作成手順（6ステップ）
STEP1：目的と、達成したときの状態を1文で書く
「在庫管理システムを刷新する」ではなく、「棚卸の作業時間を月40時間から10時間に減らす」と書く。前者は手段、後者は目的である。ここが手段のまま進むと、提案も手段の比較になる。
STEP2：現状を数字で押さえる
処理件数、対象人数、データ量、現行システムの年間費用、業務にかかっている時間。数字がないと課題の大きさが伝わらず、投資額の妥当性も説明できない。
STEP3：対象範囲と対象外を確定する
このステップに最も時間をかける。対象外を書く作業は、実質的に「今回はやらないこと」を社内で合意する作業であり、後の追加要望を抑える効果もある。
STEP4：要求を「〜できること」の形で列挙する
機能仕様（どう作るか）ではなく、要求（何ができればよいか）で書く。優先度を必須・推奨・任意の3段階で付ける。すべて必須のRFPは、優先度を付けていないのと同じである。
STEP5：評価基準と配点を決める
提案を受け取る前に決めるのが要点である。例として次のような形になる。
| 評価項目 | 配点 | 見るポイント |
|---|---|---|
| 課題理解・提案内容 | 30 | 課題を自社の言葉で言い直せているか |
| 実現方式の妥当性 | 20 | なぜその方式かの説明があるか |
| 費用 | 20 | 内訳の粒度、前提条件の明記 |
| 体制・要員 | 15 | 実際に参画する人の経歴か（会社の実績ではなく） |
| スケジュール | 10 | 期日から逆算されているか |
| 保守・運用 | 5 | 稼働後の費用と体制が示されているか |
配点は案件ごとに変わってよいが、「費用」の配点を50点以上にすると、実質的に価格入札になる点は意識しておきたい。開発会社の見極め方についてはシステム開発会社の選び方と7つのポイントに、提案時の確認事項をまとめてある。
STEP6：提出要領とスケジュールを固める
- 提案書の提出期限（3週間以上を推奨。2週間を切ると、体制を組める会社が限られる）
- 質問受付期間と回答方法（全社に一斉開示）
- プレゼンの有無、時間、参加者
- 選定結果の通知時期
- 契約予定時期と着手希望日
RFPを出す場合と出さない場合で、何が変わるか
RFPなしで口頭とメールだけで見積もりを取ることもできる。実際に多い。両者の違いを、受注側から見た形で整理する。
| 観点 | RFPあり | RFPなし（口頭・メール） |
|---|---|---|
| 見積もりの前提 | 文書で共有されるため各社共通 | 各社が独自に想定。前提がバラバラ |
| 金額の比較 | 同条件で比較できる | 比較しても意味が薄い |
| リスクバッファ | 小さくできる | 不明点分が上乗せされる |
| 契約後の追加費用 | 「RFPに書いてあるか」で判断できる | 言った言わないになりやすい |
| 発注側の工数 | 作成に2週間〜1か月 | ほぼゼロ |
| 向く案件 | 予算が大きい、複数社比較する、社内調整が必要 | 小規模、既存取引先への追加開発 |
判断の目安としては、概算で1,000万円を超える案件、または3社以上を比較する案件ではRFPを作る価値がある。それ未満の追加開発であれば、要件メモと現行資料の共有で足りることが多い。
契約形態をどう選ぶかは、RFPの段階で方針を示しておくと提案がぶれない。請負と準委任の違いを責任・報酬・選び方から比較した記事を参照してほしい。要件定義フェーズについては要件定義が準委任契約になる理由と契約書の必須条項にまとめている。
RFPの記載例（抜粋）
実際の書き方が掴みにくい部分を、抜粋の形で示す。
悪い例（要求）
在庫データをリアルタイムに参照できるようにすること。
「リアルタイム」の定義がなく、受注側は最悪ケース（秒単位の同期）を想定して見積もる。
良い例（要求）
【必須】倉庫の入出庫実績を、営業部門が在庫照会画面から参照できること。 反映の遅延は15分以内を許容する。同時利用は最大30名を想定。
悪い例（スコープ）
販売管理業務全般を対象とする。
良い例（スコープ）
対象：受注登録、出荷指示、売上計上、請求書発行（本社および東日本倉庫） 対象外：与信管理、債権回収、西日本倉庫（第2フェーズで検討）、会計システムの改修
対象外を明記することが、金額と納期の両方を安定させる。
RFPを出したあとにやること
RFPは出して終わりではない。提案の質は、出したあとの運用でも変わる。
- 質問への回答は全社に同じ内容で開示する — 個別回答は情報格差を生み、比較の前提を壊す。
- 提案説明の場を設ける — 文書だけでは、体制の実在性やプロジェクトマネージャーの力量が判断できない。
- 提案してくれた会社には結果を必ず通知する — 提案作成には数十万円相当の工数がかかっている。通知がない発注者は業界内で共有され、次回の提案参加率が下がる。
- 選定後、RFPと提案書を契約書の一部として扱うか決める — 「RFPおよび提案書を契約の前提とする」と明記しておくと、後の解釈違いを減らせる。
提案を受けた後に要件を固めていく工程については、要件定義の進め方と5ステップの手順・成果物を参照してほしい。
よくある誤解
「RFPは分厚いほどよい」 — 誤り。読まれない分量のRFPは、結果として読み飛ばされる。重要なのは分量ではなく、対象外・予算・評価基準・現行情報の4点が明記されていることである。
「RFPを出せば要件定義は不要になる」 — 誤り。RFPは要求のレベルであり、要件定義は仕様のレベルである。RFPで書くのは「何ができればよいか」、要件定義で決めるのは「どう実現するか」。工程としては別物である。
「RFPを出せば金額が下がる」 — 半分正しい。比較が働くことで不当に高い提案は落ちるが、前提が明確になった結果、当初の想定より金額が上がることもある。RFPの効果は「安くすること」ではなく「金額の根拠が説明できるようになること」である。
FAQ：RFP（提案依頼書）に関するよくある質問
RFPには何を書くべきですか？
背景・目的、現状の課題、対象範囲（対象外を含む）、要求機能、非機能要件、現行システム情報、予算、スケジュール、体制・役割分担、評価基準、提出要領の11項目が基本です。このうち、金額に最も影響するのは対象範囲（特に対象外）と現行システム情報です。この2つが空欄だと、各社の見積もりが比較できなくなります。
RFPは誰が書きますか？
事務局は情報システム部門、内容の主は業務部門、目的と予算の承認は経営層、という分担が実務的です。外部の支援を受ける場合、提案に参加する会社にRFP作成を任せると選定の公平性が崩れるため、その会社を選定対象から外すか、支援内容を全候補に開示します。
RFPとRFIはどちらが先ですか？
RFIが先です。ただし必須ではありません。実現方式（スクラッチ／パッケージ／SaaS）が絞れており、候補ベンダーが5社以内に決まっているなら、RFIを飛ばしてRFPから始めて問題ありません。
RFP、RFI、RFQの順番は？
RFI（情報収集）→ RFP（提案依頼）→ RFQ（見積依頼）の順です。ただしシステム開発では、仕様が確定してから価格だけを比べるRFQ単独の調達はあまり成立しません。要件が動く前提の取引だからです。ハードウェア調達やライセンス購入ではRFQが主になります。
RFPに予算を書くべきですか？
書くことを勧めます。伏せると、受注側は「外されない金額」か「最小構成」のどちらかに寄り、提案の粒度が揃わなくなります。上限額そのものを出すのが不安であれば、レンジで示す、初期費用と年間運用費を分ける、超過提案には理由と効果の明記を条件にする、という形で調整できます。
RFPの作成期間はどのくらいかかりますか？
社内の情報がある程度そろっている場合で2週間〜1か月が目安です。時間がかかるのは文書を書く作業ではなく、対象範囲と対象外を社内で合意する工程です。ここが決まらないまま出すと、提案を受け取ってから振り出しに戻ります。
RFPのテンプレートをそのまま使ってよいですか？
骨格として使うのは有効です。ただし、テンプレートの項目をすべて埋めようとすると、自社に関係のない項目まで書くことになり、読み手が要点を掴めなくなります。埋まらない項目は「該当なし」と書いて残すか、削る判断をしてください。空欄のまま出すのが最も誤解を生みます。
提案を1社からしか受けない場合もRFPは必要ですか？
比較の目的はなくなりますが、契約後の解釈違いを防ぐ目的では有効です。特に対象外の明記と評価基準は、1社随意契約でも意味があります。分量は絞り、対象範囲・現行情報・予算・スケジュールの4点に集約する形で構いません。
RFPと要件定義書の違いは何ですか？
RFPは発注前に「何ができればよいか（要求）」を書く文書、要件定義書は契約後に「どう実現するか（仕様）」を確定させる文書です。作成者も異なり、RFPは発注側、要件定義書は発注側と受注側の共同作業で作ります。要件定義書の中身は要件定義書の書き方と必須項目・構成・作成手順にまとめています。
提案が横並びで差がつかないときはどうすればよいですか？
多くの場合、RFPで評価基準を示していないか、要求の優先度を付けていないことが原因です。追加で確認するなら、実際に参画する要員の経歴（会社実績ではなく個人の経歴）、類似案件で想定される最大のリスクとその対処、要件が増えたときの費用の決め方の3点を各社に質問すると差が出ます。
まとめ：RFPの質は「対象外」と「評価基準」で決まる
RFPで悩む時間の大半は、要求機能の書き方に費やされがちである。しかし受注側から見て提案の質を左右するのは、対象外が明記されているかと評価基準が先に示されているかの2点である。この2つが書かれたRFPは、それ以外の項目が多少荒くても、比較可能な提案が集まる。
逆に、機能一覧が詳細でも対象外と評価基準がなければ、各社が異なる前提で見積もり、比較のしようがない提案が並ぶ。RFPを書く時間の配分を、この2点に寄せてほしい。
次に読むべき記事
参考にした一次情報・出典
- 経済産業省・独立行政法人情報処理推進機構（IPA）「共通フレーム2013」（発注者と受注者の作業範囲・用語定義の参照）
- 本記事の「受注側が見積もれないと判断するRFPの共通点」「評価配点の目安」は、株式会社シンシアが受託開発の提案・見積もり業務で蓄積した実務知見に基づく。金額・配点は案件により変動するため、目安として扱ってほしい。
