RFP（提案依頼書）とは？書き方・記載項目と発注先選定での使い方

複数の開発会社から見積もりを取っても、対象範囲や前提条件、保守の含まれ方が異なれば、金額だけで妥当性を比べることはできません。Webサービス・スマホアプリ開発の発注では、何を実現したいかだけでなく、何を提案・見積もり・評価の対象にするかをそろえる必要があります。

RFP（提案依頼書）は、その比較条件を整えるための発注準備文書です。この記事では、RFPと関連文書の使い分け、記載項目、配布後の質問管理、見積比較、評価から契約前確認までを解説します。自社でRFPを作るべきか、何を書き、どう比較・選定すべきかを判断できるようになります。

RFPは、依頼条件と評価基準をそろえ、比較可能な提案を集めて選定・契約前確認につなげるための文書です。

01SectionRFPとは？RFI・RFQ・要件定義書との違い

RFPは、発注側の課題、目的、範囲、優先順位、制約を伝え、複数の候補企業から解決策・実行計画・見積もりを含む提案を受けるための文書です。単なる見積依頼ではなく、比較可能な提案を集め、選定理由を関係者へ説明できる状態をつくる役割があります。

米国政府調達のFAR 15.203でも、RFPは要求事項、提案に必要な情報、評価要素を示して提案を求める文書として扱われています。民間の開発発注で同じ手続きが義務になるわけではありませんが、依頼内容と評価方法を対応させる考え方は参考になります。

4文書の使い分け

文書名ではなく、候補企業から何を回答してほしいかで使い分けると、依頼内容と選定方法をそろえやすくなります。

RFI・RFP・RFQ・要件定義書は、似た場面で使われるため混同されがちです。まずは、今の発注準備で何を知りたいのか、候補企業に何を回答してほしいのかで使い分けます。

RFIは情報収集、RFQは明確な要求に対する価格確認、RFPは解決策・能力・価格を含む提案を求めるものとして、GSAの用語解説でも整理されています。ただし、民間取引では呼称や利用順序に組織差があります。「RFP」「RFQ」という名前だけで判断せず、回答してほしい内容、見積対象、提出形式、評価方法を依頼書に明記してください。

要件定義書はRFPの代わりではありません。RFPでは発注判断に必要な目的・範囲・優先順位・制約を示し、選定後に画面やデータ設計の詳細、テストケース、受入れ条件の詳細、責任分界、変更手順を具体化します。詳細は要件定義の解説記事を参照してください。

RFPを充実させるべき案件と、簡略化できる案件

複数社を比較する、実現方法や体制に提案の余地がある、外部連携・データ移行・個人データ・セキュリティ審査が関係する、選定理由を稟議や決裁で説明する必要がある場合は、RFPを充実させる意義が大きくなります。

一方で、既存取引先への影響範囲が限定的な改修であり、対象作業や成果物が明確で、比較選定を行わない場合は、簡易な依頼書やRFQで進められることもあります。その場合でも、対象範囲、成果物、受入れ条件、費用に含む作業は記録しておくことが重要です。

02Section開発RFPに記載する項目と書き方

RFPでは、目的・範囲・制約と、見積・提出・評価の条件をつなげて記載することで、提案の前提差を確認しやすくなります。

RFPは詳細な仕様書を最初から完成させるための文書ではありません。提案先が同じ前提で考え、発注側が比較できるだけの情報を、目的から提出条件まで矛盾なくつなげることが重要です。

記載骨子と短い記入例

以下は、架空の「予約受付Webサービスの利用者向け画面と管理画面の刷新」を想定した例です。文章量をそのまままねるのではなく、自社の業務、対象データ、連携、契約条件に合わせて調整してください。

未確定事項は「提案してほしいこと」に変換する

要件が未確定だからといって、RFPを出せないわけではありません。未確定事項は、決定済みの前提、提案先に求める代替案、概算見積もりへの影響、選定後に詳細化する事項に分けて書きます。

例えば「通知機能が必要だが手段は未決定」であれば、利用者への連絡が必要という前提は確定事項として示し、メール・アプリ通知などの代替案、費用と運用への影響を提案で求めます。そして、詳細な通知設計は選定後の要件定義で決める事項として扱います。未確定事項を隠して各社に異なる仮定を置かせるより、比較しやすくなります。

非機能・連携・運用を後回しにしない

非機能要件は、速度、利用可能時間、セキュリティなどの品質・運用条件です。IPAの非機能要求グレードでは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティといった確認軸が示されています。

全項目をRFP段階で詳細化する必要はありません。ただし、想定利用者数やアクセス集中、停止許容、対応端末、認証・権限・ログ、外部連携、データ移行について、「決定済み」「確認中」「提案を求める」を区別します。これにより、後から大きな前提差が判明する可能性を抑えられます。

03SectionRFPを作成・配布する手順

提出・評価条件を配布前に決め、質問や改訂を全候補へ同じ条件で共有することが、比較可能性の維持につながります。

RFP作成は文書を書く作業ではなく、発注側が比較条件を意思決定するプロセスです。先に課題・目的を固め、その後に成果の考え方、範囲、制約、提出・評価条件を決める順に進めると、後工程での矛盾を見つけやすくなります。

質問回答と改訂は、全候補に同条件で共有する

質問への回答が範囲、費用、提出条件、評価方法に影響する場合、質問者だけへの個別回答では比較条件がそろいません。質問番号、質問内容、回答責任者、影響の有無、回答日、共有先を記録し、必要ならRFP本文または別紙を改訂します。

改訂時は、版番号、改訂日、改訂箇所を明示し、全候補へ同じ改訂版を配信します。提出期限や評価条件に影響する変更であれば、候補各社が同じ条件で確認・回答できる状態かも確認してください。回答・改訂は全候補が同じ条件を参照できるように管理することが重要です。

提案内容と評価基準を対応させ、重要な質問への回答を関係事業者へ通知する考え方は、デジタル庁の標準ガイドライン解説書でも示されています。民間発注では、公平な比較を行うための実務上の参考と捉えるとよいでしょう。

日程は日数ではなく、完了条件と調整要因で管理する

RFP準備から契約協議までの所要期間は、候補企業数、未確定事項の多さ、外部連携、社内稟議、セキュリティ・法務審査、契約条件の調整によって変わります。一律の期間を前提にするのではなく、「課題と範囲が合意済み」「全候補に同一版を配布済み」「選定理由と懸念が記録済み」といった完了条件を置いて管理します。

04Section比較可能な提案・見積もりを集める依頼方法

候補企業を増やすこと自体が目的ではありません。自社の目的・制約に対し、必要な支援を実行でき、情報管理条件にも対応できるかを一次確認したうえで、同じ依頼条件を配布します。

候補企業を絞り込む一次確認

候補企業には、次の5点を確認します。

• 対象プラットフォーム、必要な技術領域、連携・移行条件に対応できるか
• 類似する業務課題、利用者、制約への対応経験を説明できるか
• 要件整理、UX設計、開発、テスト、保守のうち必要な支援範囲に対応できるか
• 希望する進め方に必要な体制を確保できるか
• データ、セキュリティ、再委託、契約条件に関する確認に対応できるか

候補を探す際は、必要な技術領域と支援範囲を先に整理してから、サービス一覧も候補探索の入口として確認できます。

全社で統一する提出・見積条件

提案では、課題理解、実現方針、代替案、体制、工程、主要リスク、保守案を同じ章立てで求めます。見積もりでは、初期・導入時の要件整理、設計、開発、テスト、移行、リリース支援と、リリース後の保守・運用を混同せずに示してもらいます。

特に、工程・成果物、発注側が担う作業、前提条件、除外事項、変動条件、外部サービス費用、保守範囲をそろえることが重要です。外部サービス費用やインフラ費用の扱い、別途費用となる条件を明記してもらうと、金額差の理由を確認しやすくなります。

個人データ・機密情報の扱い

個人データや機密情報を扱う案件では、RFPに何を載せるかだけでなく、誰に、いつ、どの資料まで共有するかを決める必要があります。詳細資料は候補選定後やNDA締結後に段階的に共有する方法も検討します。

個人情報保護委員会のガイドラインでは、個人データの取扱いを委託する場合、委託先の安全管理措置を確認し、再委託を含む取扱状況を確認する考え方が示されています。具体的な確認方法や契約条件は、扱うデータ、案件、社内規程に応じて異なります。

05Section提案を評価し、契約前に差分を確認する方法

選定では、必須条件を満たすかどうかと、優れた提案を加点評価することを分けます。価格が低くても必須連携に対応できない、必要な体制を確保できない、データ取扱いの条件が満たせない場合は、総合点だけで判断できません。

必須条件による一次確認

まず、対象プラットフォーム・必須連携、必要な支援範囲、希望時期における体制、個人データ・機密情報の取扱条件、受け入れられない契約上の前提などを確認します。可否だけでなく、提案書、構成図、体制表、質疑回答などの根拠・証跡と、未確認時に追加で聞く質問を記録します。

必須条件が未達の場合は、選定対象外とするのか、代替案を再評価するのか、社内審査へ回付するのかを決めます。加点評価に進める前に必須条件の扱いを明確にすることで、判断が後からぶれにくくなります。

重み付き5段階評価と質疑

一次確認を通過した提案は、自社の優先順位に応じて重みを置き、5段階で評価します。重みは固定の正解ではありません。利用定着が重要なら課題理解・UXを、個人データを扱うなら品質・セキュリティを、短期の立ち上げが重要なら体制・工程を重くするなど、配布前に調整します。

加重得点は「評点 ÷ 5 × 重み」で算出できます。評点の目安は、5を「対応方法、体制、前提、リスク対応が具体的で根拠がある」、3を「方針はあるが重要な確認事項が残る」、1を「対応可否、根拠、実行体制の記載が乏しい」とする方法があります。2・4もその間の状態として定義し、評価者間で尺度を共有してください。

質疑やプレゼンでは、KPIの計測方法、受入れ条件、見積前提、体制、主要リスク、未確定事項の確定方法を確認します。そこで分かった前提差は、評価根拠だけでなく、見積比較と契約前の確認事項にも反映します。提案で求める内容と評価基準を対応させる考え方は、前述のデジタル庁の標準ガイドライン解説書を参考にできます。

契約前に照合する事項

選定後も、RFPの内容がそのまま契約内容になるとは限りません。契約前には、RFP、提案書、見積書、契約案、要件定義書を並べ、少なくとも次の事項を照合します。

• スコープと対象外が各文書で一致しているか
• 成果物と、発注側・開発側の責任分界が明確か
• 受入れ条件が完成・検収の判断基準として具体化されているか
• 見積の前提、除外事項、外部費用、保守範囲に差がないか
• 仕様変更時の確認・見積・承認の条件が整理されているか

総合点が高くても、必須条件の未達や未解消の重大懸念を点数で相殺してはいけません。未合意事項は、担当者と確認期限を決めて契約協議・要件定義へ引き継ぎます。

06SectionRFP作成・運用で避けたい失敗と提出前確認

RFPで起こりやすい問題は、情報が少なすぎることだけではありません。目的や優先順位が曖昧なまま依頼することと、実現方法まで過剰に固定して代替案を出しにくくすることの両方が、提案の質と比較可能性を下げます。

曖昧さと仕様固定の両方を避ける

「予約機能を作りたい」だけでは、各社が異なる利用者像、業務範囲、データ量、保守範囲を想定するため、見積もりは横並びになりません。一方で、目的に対して必須ではない実装方法まで固定すると、より適した代替案や、費用・運用負荷を抑える選択肢が出にくくなります。

固定すべきなのは、目的、必須条件、対象外、連携やデータに関する制約です。実現方法に余地がある部分は、比較したい代替案、評価観点、概算への影響を示して提案を求めます。

情報共有・データ管理を後回しにしない

質問回答を一部の候補だけに伝える、RFP改訂の履歴を残さない、共有資料のデータ区分や閲覧者を決めないといった状態は、公平な比較や情報管理を難しくします。

Webサイトやアプリの構築・運営を委託する際の委託先選定、契約、取扱状況の把握、再委託先の監督については、個人情報保護委員会の確認資料も参考になります。個人データや機密情報を含む案件では、RFP配布前に確認担当を決め、候補選定・契約協議のどの段階で何を確認するかを整理します。

提出前チェック

RFP作成・ベンダー選定の進め方を相談する

RFPの記載範囲、候補企業の絞り込み、比較・評価の進め方に迷う場合は、必要な支援範囲を整理したうえで相談先を検討できます。

RFP作成・ベンダー選定支援1071社掲載

RFP作成・ベンダー選定支援を見る