情シスのためのRFP（提案依頼書）の書き方：テンプレートと評価表の作り方

RFP（提案依頼書、Request for Proposal）とは、システムやサービスを導入する側が背景・目的・要件・評価方法を文書にまとめ、複数のベンダーに提案を依頼するための文書です。「良い提案が来ない」原因のほとんどは、RFPに要件が書かれていないか、評価基準を決めないまま配っているかのどちらかにあります。

情シスが書くRFPは、経営の言葉（目的・予算・期限）とベンダーの言葉（機能・非機能・契約条件）を翻訳する文書です。RFI・RFQとの使い分け、見出しごとの記入例、MUST/WANTの書き分けが提案内容をどう変えるか、重み付き評価表の作り方、Q&Aとデモの運び方まで、実際に案件を回すときの順番で並べています。

RFI・RFP・RFQの違いと使う順番

3つの文書は「発注側がどこまで決まっているか」で使い分けます。製品カテゴリすら固まっていない段階でRFPを出すと、要件が曖昧になり、ベンダーは自社製品に都合のよい解釈で提案してきます。

判断ルールは、候補になる製品カテゴリが2つ以上あるか実現方式が見えないならRFIから始め、要件が書けるならRFPから、製品が決まっていて価格と保守条件だけを比べるならRFQだけ、です。RFIの回答をそのままRFPの要件に写すと、特定ベンダーの機能一覧がそのまま要件になり、他社が辞退します。RFIの回答は「業務課題をどう解決できるか」を学ぶ材料にとどめ、要件は自社の業務から書き起こしてください。

RFPの構成テンプレート：見出しと記入例

見出しは次の12項目で固定し、案件ごとに中身を差し替えます。順番にも意味があり、ベンダーは前半で「自社が取るべき案件か」を判断し、後半で提案の中身を組み立てます。

1. 背景と目的：記入例「販売管理システムの保守期限が来年3月に切れる。在庫の二重入力をなくし、月次締めを5営業日から3営業日に短縮する」。目的は数値で書くと提案の優劣が比べられます。
2. 現状：システム構成図、利用者数と拠点、データ量（レコード数・ファイル容量）、連携している他システム、現状の課題。ベンダーの見積精度はこの章の情報量で決まります。
3. 範囲とスコープ外：記入例「対象は受注・在庫・請求。会計連携はCSV出力まで。会計側の改修は対象外」。書かれていない作業は見積に入らず、後で追加費用になります。
4. 機能要件：MUST/WANTを付けた一覧（次章）。
5. 非機能要件：可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境の6分類で書きます。IPAの非機能要求グレードの項目を参考に、自社に必要な行だけ選びます。
6. 移行・データ：移行対象データの種類と件数、移行の実施主体（誰がクレンジングするか）、並行稼働の有無。
7. 運用・保守・サポート：問い合わせ窓口の時間帯、障害時の初動時間、更新の頻度と作業主体、教育の回数。
8. セキュリティ・コンプライアンス要件：SSO/SCIM対応、監査ログの保持期間、データの保管場所（国内リージョン）、ベンダー側の認証（ISMS等）、再委託の条件。
9. 提案依頼事項：提案書の目次を指定し、費用は「初期・月額・保守・オプション」の区分で内訳を出させます。目次を指定しないと比較できない提案書が届きます。
10. 評価方法とスケジュール：評価項目と重み、提案締切、プレゼン日程、選定通知日、契約予定日。
11. 契約条件：契約形態（請負か準委任か、SaaSなら利用規約の変更可否）、支払条件、SLAと違約条件、解約時のデータ返還形式と期限。
12. Q&A窓口と守秘：質問の受付方法と期限、回答の共有方法、提出資料の取り扱い。

予算は書くべきです。「予算を伏せた方が安い提案が来る」と考えがちですが、実際には各社が想定する規模がばらばらになり、比較できない提案が届きます。上限額か「概ねこの範囲」の帯を示すと、その中で最も価値の高い構成を各社が考えてくれます。契約条件、とくにデータ返還と解約の条項は、契約後に交渉しても通りにくいので、RFPの段階で提示しておきます。詳しくはベンダーロックインとの付き合い方で扱っています。

要件の書き方：MUST/WANTと非機能要件

要件には必ず「MUST（満たさなければ失格）」と「WANT（満たせば加点）」の区分を付けます。区分がないと、ベンダーは全項目に「対応可」と書くしかなく、実態はカスタマイズ費用として見積の後ろに隠れます。MUSTが明確なら、満たせないベンダーは辞退するか代替案を正直に書きますし、WANTは「標準機能で対応」「設定で対応」「開発が必要」と段階をつけて答えてくれます。MUSTは全要件の2割以下に抑えてください。MUSTだらけのRFPは、ベンダーから見れば失格リスクが高く、辞退か高額見積のどちらかになります。

非機能要件で情シスが落としがちなのは移行性とセキュリティです。移行性は「現行データを誰がどの形式で出し、誰が取り込むか」、セキュリティは「SSO/SCIMの対応プランと追加費用」を明示的に聞いてください。SSOが上位プランに限定される製品は多く、見積比較の段階で気づかないと契約後に月額が跳ね上がります。確認項目はSaaSのSSO/SCIM対応チェックリストにまとめています。

非機能要件は6分類ごとに「何を書くか」を固定しておくと、案件ごとにゼロから考えずに済みます。下表は部門の業務システム（利用者50名規模）を想定した記入例で、数値は自社の業務に合わせて置き換えます。

提案書の目次と費用内訳を指定する

提案書の目次を指定しない案件では、A社は50ページの製品カタログ、B社は要件対応表だけ、という届き方になり、同じ土俵で比べられません。目次を「提案概要、要件対応表（MUST/WANTごとに対応区分と補足）、システム構成、移行計画、導入体制とスケジュール、運用・保守、セキュリティ、費用、契約条件への回答、同規模の導入実績」の10章に固定し、要件対応表は発注側が用意したスプレッドシートに記入させます。対応区分は「標準機能」「設定で対応」「カスタマイズで対応（費用は費用章に記載）」「対応不可」の4択にして、自由記述で濁せないようにします。

評価表の作り方：重み付けと採点基準

評価表はRFPを配る前に完成させ、重みは配布後に変えません。後から重みを動かすと、声の大きい評価者の好みに結果が寄ります。項目は「機能適合」「非機能・セキュリティ」「導入体制・スケジュール」「運用・サポート」「費用」の5分類が基本で、それぞれの重みは目的から決めます。下表は重みと採点の計算例です。

加重点は「素点÷5×重み」で計算しています。素点の定義を文章で決めておくことが重要で、機能なら「5＝標準機能で満たす、3＝設定または軽微なカスタマイズで満たす、1＝開発が必要または不可」、体制なら「5＝同規模・同業種の実績が3件以上」のように、評価者が迷わない基準にします。費用は初期費用ではなく5年間の総額（初期＋月額×60か月＋保守＋想定オプション）で比べ、最安を5点、他社は「最安額÷自社額×5」で採点すると恣意性が消えます。たとえば最安のA社の5年総額を100とし、B社が125ならB社の費用点は100÷125×5＝4.0点、C社が150なら3.3点です。評価者は3名以上で、まず個別に採点し、差が2点以上開いた項目だけ合議で理由を突き合わせます。上の例ではA社とB社が1点差で、この差は評価者の主観の範囲内なので、機能デモの結果を再確認してから決める、という判断になります。

費用の重みを40以上にすると、要件を削って安く見せた提案が勝ちます。費用は20〜25に抑え、その代わり「5年総額」で比較してください。初期費用を安くして月額や保守で回収する提案は、この比較で自然に順位が下がります。総額の考え方はITコスト削減の進め方でも扱っています。

ベンダーとのQ&A運用

Q&Aは公平性の要です。運用ルールは4つで、質問は書面（メールまたはフォーム）で期限までに受け付ける、回答は質問者を伏せて全ベンダーに同時に共有する、回答でRFPの内容を変更した場合は改訂版を全社に配る、電話や個別打合せで答えない、です。個別に答えた内容は他社に伝わらず、後で「聞いていない」という争いになります。質問の締切は提案締切の2週間前、回答は締切から3営業日以内が回る目安です。質問は「番号、受付日、質問の要約、回答、RFP改訂の要否」の5列で一覧にし、この一覧そのものを全社に配ると、回答漏れと個別回答の両方を防げます。質問が多いベンダーは案件を真剣に読んでいる証拠で、質問ゼロのベンダーは定型提案を出してくる可能性が高いと見てください。

プレゼン・デモの進め方

デモは営業資料の再演ではなく、自社の業務シナリオを各社に同じ条件で実演してもらう場にします。事前に「受注入力→在庫引当→請求書発行→月次締め」のような3〜5個のシナリオと、サンプルデータ（匿名化した自社データ）を渡し、そのシナリオで操作を見せるよう指定します。時間配分は60分なら会社・体制の説明10分、シナリオデモ35分、質疑15分が目安で、評価者は終了直後にその場で素点を付けます。翌日に回すと印象が混ざります。参加者は情シスだけでなく、実際に画面を使う業務部門の担当者を必ず入れ、「この操作を毎日100回やれるか」という目線で見てもらいます。

デモ環境はベンダーが自社製品向けに最適化したデータと設定で動いています。自社の実データ（匿名化済み）を入れた途端に検索が遅くなる、必要な項目がない、という差が出ることは珍しくありません。契約前にトライアルかPoCで自社データの実物を投入して確認する条項を入れ、その結果で機能適合の素点を見直せるようにしておいてください。

配布から契約までのスケジュール例

中規模の業務システム更新を想定した10週間の進行例です。短縮する場合も、質問受付から回答共有までの3週間と、提案作成の2週間は削らないでください。ここを削ると、体制を組める会社ほど辞退します。

SaaSを選ぶときのRFPの違い

SaaSはカスタマイズせず標準機能に業務を合わせる前提なので、RFPの重心が変わります。機能要件を細かく書いても「標準機能で対応」と返ってくるだけなので、MUSTは「自社の業務シナリオが標準機能で回るか」に絞り、第6〜7週にトライアル環境で業務部門に実際に操作させて判定します。代わりに重くなるのが契約条件で、価格改定の通知期間と改定時の解約権、データエクスポートの形式と範囲、SSO/SCIMが使えるプラン、データの保管リージョン、サービス終了時の猶予期間を要件として書き、回答を評価表の「非機能・セキュリティ」に組み込みます。費用は利用者数の増減に連動するので、3段階の人数での5年総額を出させて比べます。SaaSのRFPは10ページで十分で、その分をトライアルの設計に回す方が、選定の精度は上がります。

つまずきポイント：よくある失敗と対策

• 予算を伏せて提案がばらばらになる：A社は全機能フルパッケージ、B社は最小構成で、比較のしようがなくなります。上限額または帯を示し、「この範囲で最も価値の高い構成」を各社に考えさせます。
• 「現行踏襲」を要件にして課題が残る：現行の帳票やワークフローをそのまま要件にした結果、新システムでも二重入力が残ります。要件は業務の目的（何を何分で終わらせたいか）から書き、現行仕様は参考資料に回します。
• 評価表を提案受領後に作る：提案を見てから項目と重みを決めると、気に入った提案に合わせた評価表になります。配布前に確定し、評価者全員が承認した版を保管します。
• 提案期間が短すぎて有力ベンダーが辞退する：配布から締切まで1週間では、体制を組める会社ほど辞退します。中規模案件なら配布から締切まで3〜4週間、Q&A期間を含めて設計します。

よくある質問

RFPは何ページくらい？

本文10〜30ページ、要件一覧は別紙のスプレッドシートにするのが扱いやすい形です。ページ数より「現状の情報量」と「要件の判定基準」が揃っているかが重要で、部門の業務システム更新なら要件は50〜150行程度に収まります。300行を超えるなら、MUSTが多すぎるか、業務の細部を要件と取り違えている可能性があります。

ベンダーに費用を聞く前に必要なことは？

範囲とスコープ外、利用者数と拠点数、データ量、移行の実施主体、非機能要件（可用性と性能）の5つを確定させることです。この5つが曖昧なまま費用を聞くと、各社が異なる前提で見積もるため比較できず、契約後に「前提が違った」として追加費用が発生します。費用の内訳形式（初期・月額・保守・オプション）も指定しておきます。

評価表は公開すべき？

評価項目と重みはRFPに載せて公開すべきです。ベンダーは重みの高い項目に提案の力を注ぐので、発注側が重視する点に沿った提案が届きます。公開しないのは素点の定義の細部と各社の採点結果で、選定後に落選したベンダーへ「どの項目で差がついたか」を口頭で伝えると、次の案件でも良い提案をもらえます。

まとめ

RFPの品質は、現状の情報量、MUST/WANTの区分、配布前に固定した評価表の3つで決まります。予算と契約条件を伏せず、Q&Aは書面で全社共有、デモは自社シナリオで統一し、採点はその場で行う。この運びにすれば、ベンダーは正直に答える方が有利になり、発注側は比較可能な提案を手にできます。

次に読む

• ベンダーロックインとの付き合い方：回避すべきケースと許容すべきケース
• SaaSのSSO/SCIM対応チェックリスト：情シスが導入前に確認する項目と設定の流れ
• ITコスト削減の進め方：SaaS・クラウド・保守費を見直す手順