# RFPとは

発注先を選ぶために、求める要件と評価の観点を示して提案を求める文書です。仕様を固める前の情報収集とは区別し、提案の前提を共通化するために用います。

## RFPとは

RFP（Request for Proposal）は、発注先の選定にあたり、満たすべき要件と評価の観点を候補企業に提示して提案の提出を求める文書です。
日本語では提案依頼書と呼びます。
見積の依頼が金額の提示を求めるのに対し、RFPは実現方法の提案を求めます。


価格と提案内容の両方で発注先を決定する総合評価落札方式では、[提案依頼書を作成する](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf)ことになっています。
記載する内容は原則として提案の依頼内容・提案手続・評価基準・審査手法の4つです。
政府の方式をそのまま使う必要はありませんが、評価の基準を先に示して提案を求める形は民間でも同じです。


RFI（Request for Information）は情報提供依頼ともいい、仕様を確定する前に市場の情報を収集する依頼です。
市場調査は、[仕様書案を作成する前に行う任意の手続き](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/883b9dc1-3155-4a26-a0cc-c2b5fb0d41d1/9aa88c21/20260916_procurement_manual_01.pdf)です。
RFPはRFIを実施した場合はその結果を反映し、要件と評価基準が確定してから発行します。


![RFIで市場の情報を集め、要件を固めてからRFPを発行し、提案の評価を経て契約に至る流れを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-rfp-e1db0b61ab3aa34f5e415efdfd20e48556b524c6729bd9fbffea4d1c60e82842.png)

## 見積だけでは比較にならない

複数の会社に見積だけを依頼すると、各社が別々の前提で金額を提示します。
作業範囲、要員数、前提条件が異なれば、金額だけでは比較になりません。
低額の見積は作業範囲が限定的なだけのことがあります。


RFPは要件と評価の観点を先に提示することで、提案の前提を共通化する手段です。
発注者が定めるのは満たすべき要件と選定の基準で、実現方法は提案企業が選択します。
要件を口頭で伝達すると契約後に追加費用や仕様変更が生じます。


実務では、要件の決定を事業部門、評価の基準と手続きを情報システム部門が担うことが多いです。
政府の標準では、情報システム部門、制度の所管部門、業務の実施部門で[構成する体制](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf)が提案依頼書を作成します。
どちらの所管かを決定しないまま始めると、要件が技術の都合に左右されます。


![前提が異なる見積は金額だけでは比較できず、要件と評価の観点を先に示すことで前提が揃うことを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-rfp-99f86d36c830614238e29a7c54cba7109f56de2b8cd7cf05802406bd17324db6.png)

## 前提が揃った提案が集まる

- 見積の前提が共通化され、金額と作業範囲を同じ条件で比較できる
- 価格以外の差が評価に反映され、最安値以外の判断材料が得られる
- 要件の欠落や実現性の懸念について、提案の段階で候補企業から指摘が得られる
- 予算と納期の現実性を、契約の前に確認できる
- 選定の理由を社内に説明でき、稟議と監査の記録になる

## 発注側にも数週間の工数がかかる

- 作成、質問への回答、提案の評価に数週間の工数が発生し、見積依頼より発注側の負担が増加する
- 要件定義が不十分だと提案の質も低下し、選定の材料にならない
- 必須要件が過剰だと提案の幅が限定され、応募が減少してリスクの上乗せ分が価格に反映される
- 要件が詳細だと発注者が想定していない代替案が提示されにくくなる
- 評価者の力量と配点の設計が結果を左右する
- 予算、戦略、既存システムの情報を開示するため、秘密保持契約と開示範囲の管理が必要になる
- 提案の作成負荷が候補企業に発生し、小規模な会社の参加を困難にする
- 契約後に要件の変更が必要になると、契約変更と再見積の手続が発生する
- 不採用の連絡と理由の説明に手間が発生し、以後の取引にも影響する

![RFPの作成、提案者の回答待ち、提案の評価にそれぞれ期間がかかり、契約まで数週間を要することを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-rfp-22f7b67fc41dd07bfd82dc59c34919b85335f7c16268bc87fb6b5bfb5b95e720.png)

## RFPを出すか、見積比較で足りるか

金額と候補数だけで決定せず、比較する軸が価格だけかどうかで分類します。
金額と候補数の目安は次のとおりです。


| 条件 | RFPを発行する | 見積比較で十分 |
|---|---|---|
| 発注額 | 数百万円を超える（目安） | 100万円以下で要件が確定している |
| 候補数 | 3社以上で、提案の内容に差が生じる見込みである | 1社のみ |
| 比較する軸 | 価格以外に2つ以上ある | 価格のみ |
| 目的 | 実現方法を比較する | 金額と作業範囲を比較する |

候補が3社以上でも、提案の内容に差が生じない見込みなら見積の比較で十分です。
逆に1社でも比較の軸が多い場合は、要件と評価の観点を文書で提示して前提を統一します。
候補が2社の場合は比較はできますが、1社が辞退すると競争が成立しなくなります。


![発注額と候補数でRFPを発行するか見積比較にとどめるかを分け、候補が1社の場合と継続改修を対象外とする分岐を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-rfp-30e5f11ea1e0c236cf89d7658afd5e3b096008474c49dc9a4a82f887185cd4a1.png)

### 1社しか候補がない場合

比較の相手がいないため、提案を横並びで比較できません。
代わりに、概算見積を項目ごとに分解して単価と工数を確認し、過去の類似案件の実績と比較します。
必要なら第三者に見積の妥当性を確認させます。


候補が1社でも、要件を文書で提示して見積の前提を統一する効果はあります。
口頭の依頼では金額に含まれる範囲が後から問題になります。
既存ベンダーの継続改修は比較の材料を確保しにくいため対象外にすることが多いです。
移管の期間を設ければ他の事業者も提案できます。


### 書く内容

- 要件はMustとWantに分類し、Mustは満たさなければ不合格になる条件、Wantは満たすほど評価が向上する条件にする
- 評価の配点と観点は提案を受領する前に設定し、RFPに記載する
- 質問の受付期間を定め、回答は全候補に同時に共有する
- 提案書の様式、分量、提出期限、提出方法を統一する
- 契約形態、再委託の可否、著作権の帰属、検収の条件を示す

評価は[あらかじめ示した基準に基づいて行う](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf)必要があり、提案に重要な影響がある質問と回答は関係する全ての事業者に通知します。
民間でも配点と質問の扱いを先に示すと、選定の公平性を説明できます。


作成の期間は1〜2週間、提案者の回答に2〜4週間、比較に1〜2週間が目安です。
Must要件が確定する前に発行しません。
実現性の確認はRFIや技術的な対話で先に行います。
提案額は概算なので、契約前に作業範囲、要員数、単価、工程を精査して確定させます。


### 提案の比べ方

- 配点表に基づいて採点し、Mustの不足は減点ではなく不合格にする
- 見積の前提を共通化し、要員数、期間、単価、作業範囲、前提条件を同じ項目で比較する
- 提案書だけでなく、作業計画の案と実現性の説明を求める
- プレゼンテーションと質疑で、提案者の理解度を確認する
- 最安値を選択しない場合に備え、価格と技術の配点を先に設定しておく

評価の観点は要件の理解度、実施体制、作業計画の実現性、過去の実績などで構成します。
案件の特性に応じて、[価格点と技術点の配分](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/883b9dc1-3155-4a26-a0cc-c2b5fb0d41d1/9aa88c21/20260916_procurement_manual_01.pdf)は1対1、1対2以内、1対3以内のいずれかに設定します。
技術点は必須要件の基礎点、超過分の加点、任意要件の得点に区分します。
1対3以内まで広げられるのは、業務の複雑さ、頻繁な改修への対応、連携先の多さの3つを満たす案件です。
1対2以内は、複雑さと改修の2つを満たす場合に限ります。


作業計画の案を求めて実現性を確認するのは、[効果的な方法](https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/0af5ce68/20260715_resources_standard_guidelines_guideline_05.pdf)です。
提案書の章立てを配点に対応させると、評価の欠落が減少します。


![評価点を価格点と技術点に分け、技術点を必須要件の基礎点と加点、任意要件の得点に分けた配点の内訳を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-rfp-67003fb5e9b35246312919e04f8a07d5cf0650b2848588d5ac87d90ac0401f80.png)

## よくある誤解

### RFPを発行すれば良い提案が集まる

提案の質は要件と評価基準の質に左右されます。
要件が曖昧なまま配点だけ詳細にしても、提案は一般論になります。
要件は候補企業との対話やRFIで具体化してから確定します。


### RFPは仕様書の別名

仕様書はシステムに求める機能や性能を定める文書で、RFPは発注先を選択するための文書です。
仕様書をRFPに添付する場合でも、評価の観点と提案の手続は別に示します。


### 見積の提出を求めるためにRFPを発行する

金額だけを比較するなら複数社の概算見積で十分です。
RFPは提案内容を比較するときに使用します。


### 評価の基準を提案の受領後に決める

配点を後から設定すると評価が恣意的だと解釈されます。
配点と観点を先に示すことで、提案企業も重視する項目を把握できます。