発注の準備執筆:林部(株式会社リベライズ 代表)

RFP(提案依頼書)の書き方|テンプレートと記入例

システム開発のRFP(提案依頼書)の書き方を、標準構成と記入例で解説。評価基準を先に示すと提案の質が上がる理由や、小規模案件向けの簡易版RFPの作り方も紹介します。

複数の開発会社から提案を受けるとき、各社に同じ条件を伝えるための書類がRFP(提案依頼書)です。この記事では、システム開発のRFPの書き方を、標準的な構成と記入例で解説します。評価基準を先に示すと提案の質が上がる理由や、小規模な案件向けの簡易版RFPの作り方も紹介します。

RFPの書き方の前に:RFPの目的と、なくても発注できるかの判断

RFP(Request for Proposal)は、発注者が開発会社に「この条件で提案してください」と依頼する書類です。目的は次の3つです。

  • 条件をそろえる: 全社に同じ情報を渡し、提案と見積を比べられるようにする
  • 抜け漏れを防ぐ: 書く過程で、社内で決まっていないことが見つかる
  • 記録を残す: 何を依頼したかが文書で残り、後の行き違いを減らす

官公庁の情報システム調達では、デジタル庁がデジタル・ガバメント推進標準ガイドラインで調達の手順やひな形を公開しています。民間企業にそこまでの形式は必要ありませんが、「同じ条件で比べる」という考え方は共通です。

RFPがなくても発注はできます。目安は次のとおりです。

状況RFPの必要性
3社以上に相見積をとる作った方がよい(条件がそろわないと比較できない)
社内の複数部門が関わる、決裁者が多い作った方がよい(合意の記録になる)
1社に相談し、一緒に要件を固めたい簡易版で足りる
作りたいものがまだ固まっていないRFPの前に構想の整理や事前調査を行う

RFPの標準構成

RFPの標準的な構成と、それぞれに書く内容です。

章書く内容記入例
1. 会社概要業種、事業規模、顧客数、利用者の規模従業員120名、店舗20、会員約30,000人
2. 背景と目的現状の課題、システム化の目的、成功の基準予約を電話で受けており、繁忙期に取りこぼしがある。予約のWeb化で電話対応を半減したい
3. 対象範囲と利用者対象業務、利用者、主な使い方顧客がスマートフォンで予約し、店舗スタッフが管理画面で確認する
4. 機能要件必要な機能と優先度予約受付(必須)、リマインド通知(必須)、ポイント(第2期)
5. 非機能要件セキュリティ、性能、可用性、他システムとの連携既存の顧客管理システムと日次で連携する
6. 技術・運用の条件指定の技術や環境、保守体制、問い合わせ対応社内に技術者がいないため、更新作業を減らせる構成を希望
7. スケジュール提案期限、選定日、着手希望日、稼働希望日稼働希望は来年4月
8. 提案に含めてほしい項目体制、担当者の経験、進め方、見積の内訳初期費用と月額費用を分けて記載
9. 評価基準何を重視して選ぶか、その配分下記を参照
10. 契約条件契約形態、支払い条件、知的財産、秘密保持準委任・請負の希望、ソースコードの権利

数字や固有の情報は例です。自社の状況に置き換えてください。

書くときのコツ

背景と目的は、機能の一覧より先に、具体的に書きます。目的が分かれば、開発会社は「その機能でなくても目的を果たせる方法」を提案できます。機能要件には優先度を付け、必須と第2期以降を分けます。契約形態や権利の考え方は請負と準委任の違いを参考にしてください。

評価基準を事前に開示すると提案の質が上がる理由

評価基準を伏せたままRFPを出す例は少なくありません。しかし、評価基準は先に示した方が、発注者にとって得です。理由は3つあります。

  1. 各社が重点を合わせられる: 費用重視か、提案内容重視かが分かれば、各社はそこに力を入れる
  2. 比較しやすくなる: 同じ観点で書かれた提案が集まり、点数を付けやすい
  3. 選定理由を社内で説明できる: 基準と点数が残るので、稟議や監査で説明しやすい

評価基準の例を示します。

評価項目見るポイント配分の例
提案の具体性と実現性目的に合っているか、進め方が具体的か30%
技術力と実績類似案件の経験、担当者のスキル20%
費用初期費用と月額費用、前提条件の明確さ25%
体制とサポート窓口、定例の頻度、保守の内容15%
セキュリティ情報管理の体制、認証の取得状況10%

配分は自社の優先順位で決めてください。費用の配分を大きくしすぎると、前提を削った見積が有利になる点に注意が必要です。提案の比べ方は提案書の評価方法で詳しく解説しています。

小規模案件向けの簡易版RFP

小規模な案件で、10章すべてを書く必要はありません。A4で1〜2枚の簡易版でも、条件をそろえる効果は十分にあります。簡易版で押さえる項目は次の7つです。

  1. 会社と事業の概要(3行程度)
  2. 解決したい課題と目的
  3. 利用者と主な使い方
  4. 必須の機能と、後回しにできる機能
  5. 予算の上限(初期・月額)
  6. 稼働希望日とその理由
  7. 重視する評価のポイント

簡易版でも、質問を受け付ける期間と回答の方法は決めておきます。ある会社からの質問と回答を全社に共有すれば、条件の公平さを保てます。

予算の上限を書くかどうかは迷うところです。書けば各社は範囲内で最も効果の高い案を考えます。書かなければ、構成の大きさが各社でばらばらになり、比較が難しくなります。

受託開発の現場から

RFPを受けて提案する立場と、発注者のRFP作りを支援する立場の両方を経験してきた受託開発の現場から、RFPについての考え方を紹介します。

書き込みすぎたRFPは見積を大きくする

請負を前提に細部まで書き込んだRFPをすべて満たそうとすると、見積は大きくなりがちです。画面やAPIの設計まで含めて書くと、プロジェクト全体の「ほぼ真ん中まで」進んだ状態を前提にすることになるためです。RFPにどこまで書くかが、要件定義の費用を左右します。

RFPの前に「同じ条件」を作る工程を置く

作りたいものがまだ固まっていない場合は、事前調査(フェーズゼロ)を先に切り出す進め方が有効です。目的は、複数の開発会社をフラットに比べるときに、各社に同じ条件を示せる状態を作ることです。その成果物は発注者のものとし、他社に見せることも自由にしています。

骨子は「評価基準」と「提案に含めてほしい項目」まで書く

ある受託開発会社が発注者のRFP作りを支援したときの骨子には、目的・背景・スケジュール、機能要件と非機能要件、技術要件、保守体制に加え、提案に含めてほしい項目、担当メンバーのスキル、評価基準、質問期間、知的財産と秘密保持まで含めています。

条件が変わったら対比表で整理し直す

提案の途中でRFPの条件が変わることもあります。そのときは、「従来の依頼」と「今回の依頼」を対比表にして、開発対象、担当範囲、運用、保守のどこが変わったかを整理してから提案し直すのが有効です。

まとめ

  • RFPの目的は、各社に同じ条件を渡し、提案と見積を比べられるようにすること
  • 標準構成は、会社概要、背景と目的、要件、評価基準、スケジュール、契約条件
  • 評価基準は先に示した方が、提案の質が上がり、選定理由も説明しやすい
  • 小規模案件はA4で1〜2枚の簡易版で十分。書き込みすぎると見積が膨らむ

本記事は一般的な情報提供を目的としたもので、個別の契約や法的判断については弁護士などの専門家にご相談ください。

RFPを書く前に要点を整理したい場合は、FastProposal の無料AI相談が使えます。質問に答えるだけで案件の整理と費用の目安を数分で確認でき、そのまま開発会社3社の提案を受け取ることもできます。