システム開発を依頼する会社を選ぶとき、口頭の説明だけで複数社に見積もりを依頼すると、各社の提案の前提がバラバラになり、比較ができなくなります。そこで役に立つのが、RFP（Request for Proposal：提案依頼書）です。RFPは、「何を実現したいか」「どんな条件で提案してほしいか」を文書にまとめ、各社に同じ条件で提案してもらうための資料です。本記事では、RFPに書くべき項目と書き方のコツ、ひな形の構成を紹介します。見積書と提案書の違いについては、見積書と提案書の違いを理解して発注をスムーズに進める方法もご覧ください。
RFPを作るメリット
RFPを作ると、まず、依頼する側の考えが整理されます。目的や要件を文章にする過程で、社内の認識のズレや、決まっていない事項が見えてきます。次に、各社が同じ条件で提案できるため、金額や内容を公平に比較できます。そして、提案が出そろった後で「そこまでは対応していなかった」と食い違うトラブルを、減らせます。小規模なプロジェクトでは、A4で数枚程度の簡易なRFPでも、十分に効果があります。
RFPに記載する主な項目
① 背景と目的
なぜこのシステムが必要なのか、現状どのような課題があるのかを書きます。開発会社が、システムの「目的」を理解することで、単に要件をなぞるだけでなく、より良い提案を考えやすくなります。
② 対象範囲（スコープ）
どの業務を、どこまでシステム化するのかを明確にします。「今回の対象外」とする範囲も書いておくと、認識のズレを防げます。
③ 現状の業務・システムの概要
現在の業務の流れ、利用しているシステムやツール、データの量、利用者の人数などを説明します。既存のシステムとの連携や、データ移行が必要な場合は、必ず記載してください。
④ 要件（機能要件・非機能要件）
機能要件は、システムに必要な機能です。必須のものと、あれば望ましいものを区別して書くと、提案の幅が広がります。非機能要件は、機能以外の条件で、性能（同時利用人数や応答速度）、セキュリティ、可用性（稼働時間）、使いやすさ、対応端末などです。見落とされやすいため、明記しておきましょう。
⑤ スケジュール
希望する稼働開始時期と、その理由（業務の繁忙期、制度の施行日など）を書きます。提案依頼から選定までのスケジュールも、あわせて示します。
⑥ 予算
予算の目安を示すかどうかは悩ましいところですが、上限の目安を伝えておくと、現実的な提案が出やすくなります。示さない場合も、「初期費用と運用費用を分けて見積もってください」と指示しておくと、比較しやすくなります。
⑦ 提案してほしい内容
開発会社に、何を提案してもらいたいのかを具体的に指定します。たとえば、実現方法、開発体制と担当者、スケジュール、見積もり（内訳つき）、リリース後の保守・運用体制、類似の実績、といった項目です。
⑧ 選定の流れと評価基準
提案の提出期限、質問の受付方法、プレゼンテーションの有無、選定結果の通知時期を記載します。どのような基準で評価するのか（提案内容、実績、価格、体制、保守体制など）も、可能な範囲で示します。
⑨ 守秘義務・提出条件
RFPには、業務の詳細や社内の情報が含まれるため、秘密保持契約（NDA）を結んだうえで配布するのが一般的です。提出するファイル形式や、提出先も明記します。
ひな形（章立て）
そのまま使える章立ての例です。各項目を埋めていくだけで、RFPの骨組みができあがります。
- 1. 本書の目的・取り扱い（守秘義務を含む）
- 2. プロジェクトの背景と目的
- 3. 対象範囲（スコープ）と対象外
- 4. 現行の業務・システムの概要（連携・データ移行の有無を含む）
- 5. 要件（機能要件／非機能要件。必須・希望を区別）
- 6. 想定スケジュール（稼働希望時期、提案〜選定の日程）
- 7. 予算の目安（初期費用・運用費用の区別）
- 8. 提案してほしい内容（体制・実績・見積内訳・保守運用）
- 9. 選定方法と評価基準
- 10. 質問の受付方法・提出期限・連絡先
RFPを書くときのコツ
- 完璧を目指さない。決まっていない点は「未定」と明記し、提案してほしい点として整理する
- 目的を重視する。手段（こう作ってほしい）より、実現したい状態を書く
- 必須と希望を区別する。すべてを必須にすると、予算と期間が膨らむ
- 専門用語を使いすぎない。社内用語は説明を添える
- 現場の担当者にも目を通してもらい、業務との食い違いを防ぐ
評価基準の作り方
提案を比較するときは、金額だけで選ばないよう、評価の軸をあらかじめ決めておきます。たとえば、提案内容（要件への適合度、実現方法の妥当性）、開発体制と実績、スケジュールの現実性、保守・運用の体制、価格の5項目に、重みづけをして点数化する方法があります。複数の担当者が独立して採点し、あとで議論すると、特定の人の印象に偏りにくくなります。
RFPを配布してから選定までの流れ
RFPを作成したら、候補の開発会社に配布します。多くの場合、まず秘密保持契約（NDA）を結び、質問を受け付ける期間を設けます。全社に共通の回答を共有することで、情報の差が出ないようにします。提案が出そろったら、書面の評価に加えて、必要に応じてプレゼンテーションや、担当者との面談を行います。このとき、提案書に書かれた担当者が、実際にプロジェクトに参加するのかを確認しておくと安心です。最終的な選定結果は、全社に丁寧に連絡し、採用しなかった会社にも、理由を簡潔に伝えると、今後の関係につながります。
提案を比較するときの視点
- 要件を正しく理解しているか。課題の本質を捉えた提案になっているか
- 実現方法が現実的か。スケジュールや体制に無理がないか
- 見積もりの内訳が明確か。範囲外となる作業が示されているか
- 類似の実績があるか。保守・運用の体制が整っているか
- 質問への対応が丁寧か。担当者とのコミュニケーションが取りやすいか
よくある質問
Q. 小規模なシステムでも、RFPは必要ですか？
A. 厳密な形式でなくても、要件と条件をまとめた簡易な依頼書を用意すると、見積もりの比較がしやすくなります。A4で1〜2枚程度でも効果があります。
Q. 要件が固まっていない段階で、RFPは作れますか？
A. 作れます。決まっていない点は、「提案してほしい事項」として明記する方法があります。要件定義から支援してくれる会社を探す場合は、その旨を書いておきましょう。
まとめ
RFPは、複数の開発会社に同じ条件で提案してもらい、公平に比較するための資料です。背景と目的、範囲、要件、スケジュール、予算、提案してほしい内容、評価基準を整理することで、見積もりの精度が上がり、発注後のトラブルも減らせます。まずは、ひな形の章立てに沿って、書けるところから埋めてみてください。見積もりの金額の目安は、システム開発の見積もり相場感：何にいくらかかるのかも参考になります。
