RFP（提案依頼書）の書き方：開発会社から比較できる提案を引き出す

RFP（提案依頼書）は、開発会社に「この条件で提案してください」と依頼するための文書です。RFPで最も大切なのは、要件を細かく書き込むことではなく、各社が同じ前提で考え、同じ形式で答えられるようにすることです。前提条件・評価基準・回答フォーマットの3つがそろっていれば、提案の違いがそのまま会社の違いとして見えるようになり、比較と選定が格段に楽になります。

逆に、RFPを作らずに口頭で説明したり、会社ごとに違う資料を渡したりすると、返ってくる提案は範囲も形式もばらばらになります。ある会社は機能を広く見込み、ある会社は最小限で見積もり、金額も体制も比べようがない。そうなると、結局は印象や金額の大小で決めることになり、選定の失敗につながります。

この記事は、システム開発の依頼先を複数社から選ぼうとしている事業責任者や担当者に向けて書いています。RFPに入れるべき項目、項目ごとの書き方、評価表の作り方、配布から選定までの進め方、よくある失敗までを、そのまま使える形で整理します。

RFP（提案依頼書）とは何か、RFIや要件定義書との違い

RFPはRequest for Proposalの略で、発注側が開発会社に対して、提案と見積もりを依頼するために作る文書です。システムで実現したいこと、前提となる条件、提案に含めてほしい内容、選定のスケジュールと評価の方法などをまとめます。

似た文書にRFI（情報提供依頼書）があります。RFIは、提案を依頼する前の段階で、各社の得意分野や対応できる範囲、おおまかな進め方などの情報を集めるためのものです。候補が多すぎる場合や、何ができるのかがまだ分からない場合に、RFIで情報を集めてから候補を絞り、RFPを出すという順序をとることもあります。

要件定義書との違いも整理しておきましょう。要件定義書は、開発会社が決まった後に、作るものの条件を詳細に合意するための文書です。一方のRFPは、開発会社を選ぶための文書であり、要件はまだ固まりきっていない段階で作ります。RFPに要件定義書並みの詳細を求める必要はありません。むしろ、実現方法を各社に提案してもらう余地を残しておくほうが、良い提案を引き出せます。

RFPに入れる項目一覧

システム開発のRFPに入れる項目を、大きく4つのまとまりで整理します。すべてを長く書く必要はなく、案件の規模に合わせて分量を調整します。

1. 背景と目的

• 会社と事業の概要
• システムを作る背景と、現在の課題
• システムで実現したいこと、成功の基準
• 対象となる利用者と業務の範囲

2. 提案してほしい内容の前提

• 必要な機能の一覧と優先度（必須・望ましい・将来）
• 非機能要件の目安（利用者数、利用時間帯、扱う情報、セキュリティの要求）
• 既存システムや外部サービスとの関係
• 予算の目安と、公開の希望時期
• 範囲外とするもの

3. 回答してほしい項目と形式

• 提案の概要と、課題に対する考え方
• 実現方法と技術の選び方、その理由
• 体制と担当者の役割、経験
• スケジュールと工程ごとの成果物
• 見積もり（工程別・機能別の内訳、前提条件、除外事項）
• テストの考え方と、受入テストで発注側に求めること
• 公開後の保守・運用の方針と費用の考え方
• ソースコードなどの権利と、納品物の範囲

回答項目のうち、体制、テスト、保守、権利の4つは、提案書の中で省かれやすい部分です。開発会社にとっては受注が決まってから詰めればよい話に見えるためですが、発注側にとっては契約後の負担や将来の選択肢を左右する重要な情報です。RFPで明示的に回答を求めておけば、選定の段階で各社の考え方を比べられます。

4. 選定の進め方

• スケジュール（質問の受付期限、提案の提出期限、面談の日程、決定の時期）
• 評価の観点と、それぞれの重み
• 提出の形式と提出先
• 秘密保持の扱い

選定のスケジュールには、社内の決裁に必要な日数も含めておきます。提案を受け取ってから決裁までに想定以上の時間がかかると、各社が見込んでいた体制や開始時期が変わってしまうことがあります。決定の時期と開発開始の希望時期をRFPに明記しておけば、各社は担当者の確保を前提に提案できます。

項目ごとの書き方のポイント

背景と目的は「なぜ今か」まで書く

背景には、課題の内容だけでなく、なぜ今取り組むのかを書きます。「来期から取引先が倍増する見込みで、現在の手作業では受注処理が追いつかない」のように、理由が分かると各社は優先すべき点を判断できます。成功の基準も、可能な範囲で具体的に書きます。

機能は「何をしたいか」で書き、実現方法は委ねる

機能の一覧は、「どんな画面を作るか」より「利用者が何をできるようにしたいか」で書くのがコツです。「取引先が自分で注文履歴を確認できるようにしたい」と書けば、各社は既製のサービスを使う案、管理画面を拡張する案など、それぞれの実現方法を提案できます。実現方法まで指定してしまうと、各社の工夫の余地がなくなり、提案の差が見えにくくなります。

予算の目安は書いたほうがよい

予算を伝えると足元を見られるのではと心配する人もいますが、予算の目安がないと、各社は範囲の見込み方がばらばらになり、比較しにくい提案が返ってきます。目安を伝えたうえで、「この予算で実現できる範囲と、範囲を広げる場合の追加分を分けて提示してください」と依頼すると、比較しやすく判断の幅も広がる提案が得られます。

回答フォーマットを指定する

最も効果が大きいのが、回答の形式をそろえることです。見積もりは指定の表に工程別・機能別で記入してもらう、提案の概要は決まった分量で書いてもらう、といった指定をしておくと、比較表への転記が簡単になり、各社の違いがはっきり見えます。見積もりの読み方はシステム開発の見積もり比較のコツも参考になります。

評価の観点を開示する

評価の観点と重みをRFPに書いておくと、各社は何を重視して提案すればよいかが分かります。たとえば「公開後の改善体制を重視する」と書けば、その点に力を入れた提案が返ってきます。評価の観点の選び方はシステム開発会社の選び方で紹介している8つの確認点が使えます。

非機能要件は「困ること」から書く

性能やセキュリティなどの非機能要件は、専門用語で書こうとすると手が止まります。RFPの段階では、「予約が集中する月初の朝に画面が遅くなると困る」「会員の氏名と連絡先を扱うため、取引先の監査に耐えられる管理が必要」のように、業務上の困りごとで書けば十分です。各社はそれをもとに構成や対策を提案し、その提案の具体性自体が評価の材料になります。

現状の資料は添付で渡す

既存システムの画面のスクリーンショット、現在使っている帳票やExcelの様式、業務の流れを描いた図、取引先から求められているセキュリティの基準などは、本文で説明しようとせず、そのまま添付資料として渡すのが効率的です。実物を見れば、開発会社は文章で読むより正確に状況をつかめます。機密性の高い資料は、秘密保持契約を結んだ会社にだけ渡す、個人情報を伏せた見本に差し替えるなどの配慮をしておきます。

分量は「読み手が1時間で理解できる」程度に

RFPの分量に決まりはありませんが、開発会社の担当者が1時間ほどで全体を理解できる程度を目安にすると、読み込まれた提案が返ってきやすくなります。本文は要点を絞り、詳細は添付資料に回します。分厚いRFPは丁寧に見えますが、重要な条件が埋もれてしまい、読み落としの原因にもなります。冒頭に「特に重視する点」を3つほど箇条書きで示しておくと、各社が提案の力点を誤りにくくなります。

RFPを作成し、配布から選定までを進める手順

1. 社内で目的と優先順位を合意する：決裁者、利用部門、情報システム担当など関係者と、目的、予算の目安、期限、重視する点を合意します。ここが曖昧だと、選定の終盤で判断が覆ります。
2. 要件の素案と機能一覧を作る：必要な機能を一覧にして優先度を付けます。要件定義書の作り方は要件定義書の書き方も参考にしてください。
3. RFPの本文と回答フォーマットを作る：この記事の項目一覧に沿って本文を書き、見積もりの記入表や回答の様式を用意します。
4. 評価表と重みを先に決める：提案を見る前に、評価の観点と重みを決めておきます。提案を見てから基準を変えると、公平な比較ができません。
5. 候補を選び、秘密保持を確認して配布する：3〜5社程度に絞り、必要に応じて秘密保持契約を結んでからRFPを渡します。全社に同じ資料を同じ日に渡します。
6. 質問を受け付け、回答を全社に共有する：各社からの質問とその回答は、質問した会社だけでなく全社に共有します。前提をそろえるためです。
7. 提案を受け取り、評価表で採点する：評価者ごとに採点し、評価の根拠も記録します。
8. 面談で疑問点を確認する：提案の内容について、評価表で判断できなかった点を中心に質問します。
9. 決定し、結果を全社に連絡する：選んだ会社と条件を詰め、選ばなかった会社にも結果を伝えます。

手順の中で軽く見られがちなのが、6番目の質問対応です。RFPをどれだけ丁寧に書いても、各社からは必ず質問が届きます。質問の受付期限を設け、届いた質問と回答を一覧にまとめて全社に同時に送ると、前提のずれを防げます。質問の中には「この点はまだ決めていなかった」と気づかされるものも多く、社内で判断が必要な場合は、回答の期限を見込んで日程を組んでおくと慌てずに済みます。質問の数や内容そのものも、各社がどれだけRFPを読み込んでいるかを測る材料になります。

評価表の作り方

評価表は、縦に評価の観点、横に候補の会社を並べ、各欄に点数と根拠を書く形が基本です。観点ごとに重みを付け、重み付きの合計で比較します。

観点の例としては、課題の理解度、提案の具体性、実現方法の妥当性、体制と担当者、スケジュールの現実性、見積もりの明確さ、品質の考え方、保守・運用の方針などがあります。何を重視するかは案件によって変わります。新規事業で早く市場に出したいなら、スケジュールと提案の具体性の重みを大きくし、長く使う業務システムなら保守・運用の方針の重みを大きくします。

採点は、複数の評価者がそれぞれ行ってから突き合わせるのがおすすめです。一人で採点すると、その人の関心に偏った評価になりがちです。評価が分かれた観点は、面談で重点的に確認すべき点でもあります。採点の際は、点数だけでなく「なぜその点数にしたのか」を一言ずつ書き添えてもらうようにします。根拠が書かれていれば、評価者の間で点数が分かれたときにも、どの記述をどう読んだかの違いが分かり、議論が建設的になります。選定の結果を決裁者に説明するときにも、根拠の一覧はそのまま説明資料として使えます。選ばなかった会社に理由を伝える際にも役立ちます。

面談は、評価表で判断がつかなかった点を確かめる場として使います。全社に共通の質問と、各社の提案内容に応じた個別の質問を事前に準備し、開発の担当者にも同席してもらいましょう。面談後は、評価表の該当欄に根拠を書き足して点数を見直します。

金額は観点の一つとして点数化する方法もありますが、別の欄で扱い、内容の評価で絞り込んだ後に照らし合わせる方法もあります。後者のほうが、金額の印象に他の評価が引きずられにくくなります。

架空の例：RFPの有無で提案の質が変わったケース

ここで、仕組みを理解するための架空の例を紹介します。ある会社が会員向けの予約サイトを作ろうとして、最初は打ち合わせで口頭説明だけをして4社から提案を受けました。返ってきた提案は、ある会社は会員管理と決済まで含めた大きな構成、ある会社は予約受付だけの小さな構成で、金額にも大きな開きがありました。比べようがなく、判断は止まってしまいました。

そこでこの会社は、RFPを作り直しました。目的と成功の基準、必須機能と将来の機能の区別、予算の目安、範囲外とするもの、回答フォーマットを明記し、見積もりは指定の表に機能別で記入してもらうことにしました。評価の観点として、公開後の改善体制を重視することも書きました。

改めて提案を受けると、各社の提案は同じ範囲を前提にしたものになり、違いは実現方法と体制、公開後の進め方に集約されました。ある会社は決済を既製のサービスで実現して工数を減らす案を出し、別の会社は管理画面の作り込みを重視する案を出すなど、比較の焦点がはっきりしました。RFPを作る手間はかかりましたが、選定の判断はかえって早くなったといいます。

作り直しの過程で、社内にも変化がありました。範囲外とするものを書こうとしたとき、会員ランクに応じた割引を初回に入れるかどうかで、営業部門と運営部門の意見が分かれていることが初めて表に出たのです。RFPを書く作業は、開発会社に伝えるためだけでなく、社内で決めきれていないことを洗い出す作業でもあったわけです。この会社は割引を将来の機能に回すと決め、その判断をRFPに明記しました。

RFPでよくある失敗と避け方

• 要件を細かく書きすぎる：実現方法まで指定すると、各社の工夫を引き出せません。何をしたいかを書き、どう作るかは提案に委ねます。
• 逆に、目的と範囲が曖昧すぎる：「良い提案をください」だけでは、各社の解釈がばらばらになります。目的、必須機能、範囲外は必ず書きます。
• 回答フォーマットを指定しない：形式がばらばらだと、比較表への転記に手間がかかり、比べたい項目が抜けている提案も出てきます。
• 質問への回答を一部の会社にだけ伝える：前提がそろわなくなり、公平な比較ができません。回答は全社に共有します。
• 提案期間を短くしすぎる：準備期間が短いと、各社は一般的な内容で提案せざるを得ません。案件の規模に応じた期間を確保します。
• 評価基準を後から決める：提案を見てから基準を決めると、印象の良い会社に合わせた基準になりがちです。評価表は配布前に決めます。
• 既存の取引先にだけ事前に情報を渡す：付き合いのある会社に先に相談していると、その会社だけが詳しい前提を知った状態で提案することになります。事前の相談で得た情報は、RFPに反映して全社に共有しましょう。

RFP配布前のチェックリスト

• 目的と成功の基準が、関係者で合意された内容で書かれているか
• 必須機能、望ましい機能、将来の機能が区別されているか
• 範囲外とするものが明記されているか
• 利用規模、扱う情報、セキュリティの要求など、非機能の目安が書かれているか
• 予算の目安と、希望時期、その理由が書かれているか
• 見積もりの記入表など、回答フォーマットが用意されているか
• 体制、テスト、保守、権利について回答を求めているか
• 評価の観点と重みが決まっており、RFPに記載されているか
• 質問の受付方法と、回答を全社に共有する方法が決まっているか
• 選定のスケジュールが各社に無理のない日程になっているか

よくある質問

Q. 小規模な開発でもRFPは必要ですか？

規模が小さくても、複数社を比較するなら簡易なRFPを作る価値はあります。目的、必須機能、予算の目安、回答してほしい項目を数ページにまとめるだけでも、提案の比較がしやすくなります。1社にしか依頼しない場合でも、同じ内容を文書にしておけば、認識のずれを早い段階で見つけられます。

Q. RFPのテンプレートを使ってもよいですか？

使ってかまいません。ただし、大規模案件向けの項目をすべて埋めようとすると、かえって要点がぼやけます。自社に関係のある項目を選び、目的と範囲の部分は自社の言葉で具体的に書きましょう。

Q. RFPを作る時間がない場合はどうすればよいですか？

最低限、目的、必須機能、予算の目安、希望時期、範囲外、見積もりの記入表の6点を1〜2枚にまとめて全社に渡すだけでも、提案のばらつきは大きく減ります。不足している情報は、質問対応の場で補えば十分です。

Q. 提案を依頼した会社にお金を払う必要はありますか？

提案は無償で行われることが多いですが、要件の整理や詳細な調査を伴う場合は有償になることもあります。事前に条件を確認しておくと行き違いがありません。

Otsumuに相談できること

目的と必須機能がはっきりしていて、社内で評価表を作って選定を進められる場合は、この記事の項目一覧とチェックリストに沿ってRFPを作れば、比較しやすい提案を十分に引き出せます。小規模な案件なら、数ページの簡易なRFPで足ります。

一方で、目的は決まっているものの何を範囲に含めるべきか決めきれない、予算の目安が立てられない、新規事業で要件そのものが仮説の段階にある、といった場合は、RFPを作る前に事業と開発の両面から範囲を整理しておくと、その後の選定がスムーズになります。

Otsumuは、自ら事業を手がける立場から、目的に照らして必要な機能を絞り込み、構想から開発・運用・改善までを一気通貫で支援しています。システム開発では種類別の進め方を紹介しており、構想段階の事業であれば新規事業開発コンサルティングとして、検証すべき仮説と必要な範囲の整理から伴走することもできます。新規事業のレビューを短期間で行う新規事業レビュー Sprint は48万円（税別・参考価格、1〜2週間）です。RFPを受け取る側の一社として提案に参加することもできます。

まずは30分の無料相談で、検討中の内容をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01