RFPを受け取ったとき、提案書をすぐ書き始める前に、依頼された事項と、自社が回答する内容を一対一で追える状態にすると、抜けや前提の違いを確認しやすくなります。
この記事では、IT営業や提案取りまとめ担当者に向けて、RFPへの回答を整理する方法を説明します。発注側が指定した書式や提出手順がある場合はそれを優先し、ここで紹介する対応表は社内確認用の補助として使ってください。
RFPの要求と、提案の魅力を分けて整理する
RFPは提案を依頼するための文書です。デジタル庁の政府調達向け解説書でも、提案を求める内容や評価方法・基準を明確にする考え方が示されています。政府向けの手続を民間のすべての案件へ義務として当てはめるものではありません。標準ガイドライン解説書・第6章3
提案では、魅力的な追加機能を説明するだけでなく、求められた機能や体制、制約にどう答えているかが必要です。「対応可能」の一言では、標準機能でできるのか、追加開発が必要なのか、条件付きなのかが読み取れません。
まずRFPの要求を分解し、原文の項番を残します。複数の条件が一文に含まれているなら、社内確認用に枝番を付けても構いません。ただし、元の依頼との関係が分からなくなるような書き換えは避けましょう。
対応表には、回答と根拠を同じ行で置く
以下は社内確認用の項目例です。発注者の評価基準を代わりに定めるものではありません。
| 項目 | 記入内容 |
|---|---|
| 要求ID・参照箇所 | RFPの項番、版、該当ページ |
| 要求の要点 | 何を、どの条件で求められているか |
| 対応方針 | 標準対応、追加対応、条件付き、非対応、確認中など |
| 実現方法 | 利用する機能や作業、担当する範囲 |
| 根拠・提案の参照先 | 確認資料と、提案書のどこに回答したか |
| 前提・未決事項 | 顧客側の準備、外部サービス、追加費用、回答待ち |
| 確認担当 | 技術・運用・営業など、回答を確かめる担当 |
社内用の分類を、そのまま相手に通じる定義と思わないことが大切です。「標準対応」は、追加設定を含むのか、追加費用がないのかを別に確認します。言葉の印象だけで判断されないよう、実現方法と前提を文章で補います。
仮例：「既存データを移行できる」への回答
既存の顧客データを新しいシステムへ移したい、という要求を想定します。以下は実際の案件ではなく、回答を具体化するための仮例です。
曖昧な回答は「データ移行に対応します」です。これだけでは、どのデータ形式・件数・品質を前提としているかが分かりません。
対応表では、対象データ、変換が必要な項目、移行前の整理、移行後の照合、対象外のデータを分けます。技術担当がまだ確認していない箇所は「確認中」とし、確認に必要な資料と判断予定を記します。
提案書には、たとえば「指定形式のデータを対象とし、項目対応表を確認後に移行方法を確定する。欠損や重複の修正範囲は別途確認する」のように、現時点で答えられる範囲を表現します。具体的な条件は実際の調査結果に置き換えてください。
ここで未知の件数や処理時間を埋めてしまうと、後続の見積もりや計画にも未確認の前提が入ります。未決事項を見える形にして、質問へつなげる方が判断に使える回答になります。
質問は「不明です」で終えず、影響まで添える
RFPの内容が曖昧なときは、該当項番と確認したい点を特定します。可能なら、回答によって何が変わるかも添えましょう。
- 対象データの範囲が決まれば、移行対象と見積範囲を確定できる。
- 必要な利用時間帯が分かれば、運用体制の案を比較できる。
- 既存連携の仕様が確認できれば、追加開発の要否を判断できる。
質問の受付方法・期限・回答の扱いは依頼側の指定に従います。社内だけで解釈を確定させず、確認できなかった条件は、回答の前提として明確に残してください。
提出前は、提案書と見積もりを横断して確認する
対応表が埋まっていても、提案書に転記されていなければ相手には伝わりません。要求IDから提案の該当箇所へたどれるか、条件付き回答の条件が省略されていないかを確認します。
また、提案で実施すると書いた作業が見積範囲に含まれるか、体制図の担当と説明が一致するかも点検します。提出直前に要求や提案が変わった場合は、関連する行と参照先を更新しましょう。
初回の要望整理はIT営業のヒアリング項目で扱っています。RFP回答の段階では、その情報を要求・対応・根拠・前提へ結び付け、技術担当と同じ論点を確認できる状態を目指してください。