RFPとは？提案依頼書の中身と会社員が書くときの構成

急に「RFPを作って」と頼まれても、専門用語を並べた資料にすると、提案する会社が同じ条件で比べられません。RFPとは、業務やシステムを外部へ依頼するときに、目的・範囲・条件・選定方法をそろえて伝える提案依頼書です。この記事では、初めて担当する会社員が、何を決め、どこまで書けばよいかを実務の順番で整理します。

RFPとは何か。会社員が最初に押さえる役割

RFPはRequest for Proposalの略で、日本語では提案依頼書と呼ばれます。発注側が候補会社へ、課題をどう解決したいか、どの範囲を提案してほしいかを伝える資料です。単なる仕様書ではなく、提案の前提をそろえるための依頼文書と考えると分かりやすくなります。

IPAの資料でも、RFPは開発を委託する際に、委託元から候補となる委託先へ提案を依頼する文書として説明されています。したがって、担当者が一人で完成させるより、現場・情報システム・法務・経理など、条件を持つ人から確認を集めて作ることが重要です。

仕様書や提案書との違い

文書	主な作成者	役割
RFP	発注側	課題・条件を示し、提案を依頼する
提案書	候補会社	RFPに対する解決策・体制・費用を示す
仕様書	発注側または共同	必要な機能や性能を具体化する

RFPの段階で実装方法を一つに決めすぎると、候補会社の工夫を受け取りにくくなります。一方で、目的だけで条件がなければ、提案の比較ができません。固定する条件と、提案してほしい選択肢を分けて書くのが担当者の仕事です。

RFPを作る前に決める3つの境界

1. 解決したい課題と手段を分ける

「新しい顧客管理システムを導入する」は手段です。「問い合わせ履歴が担当者ごとに分散し、回答までの時間を把握できない」が課題にあたります。課題が曖昧なまま製品名や機能を並べると、導入後に何を改善したかったのか分からなくなります。

2. 今回の対象と対象外を分ける

対象部署、利用者、データ、既存システム、移行範囲を明記します。「将来検討」「今回対象外」を書くと、見積りに含める範囲のズレを減らせます。

3. 必須条件と提案を任せる部分を分ける

法令対応、納期、既存環境との接続など、守らなければならない条件は必須とします。画面の構成、運用の分担、段階導入などは、複数案を求める余地を残します。

RFPの基本構成。迷ったらこの順番で書く

1. 背景と目的：なぜ今、何を改善したいのか
2. 現状と課題：現在の業務、困っている事実、制約
3. 対象範囲：部署、利用者、データ、対象外
4. 要求事項：機能、性能、セキュリティ、運用
5. 前提条件：既存環境、納期、体制、予算の扱い
6. 提案依頼事項：提案書に含めてほしい内容と様式
7. 選定方法：評価軸、質問、プレゼン、決定時期
8. 提出方法：期限、提出先、質問期限、秘密保持

章立ては案件で変えて構いませんが、順番には意味があります。背景と現状を読んでから要求事項へ進むと、候補会社が目的を踏まえた提案をしやすくなります。提出物だけ先に指定すると、形式は整っていても課題に合わない提案が集まることがあります。

各章に何を書くか。会社員が集める情報

背景・目的・現状

経営上の背景、現場の困りごと、改善したい指標を書きます。例えば「月末の集計に3日かかる」「入力漏れを毎週確認している」のように、観察できる事実へ落とします。理想だけでなく、現状の数値や業務時間があると提案の効果を比べやすくなります。

要求事項

機能要求だけでなく、処理速度、利用時間、権限、バックアップ、障害時の連絡、保守の窓口なども確認します。要求の優先度を「必須・望ましい・提案歓迎」に分けると、候補会社が費用と実現方法を調整しやすくなります。

体制・スケジュール・予算

開始希望日、段階導入の可否、社内の意思決定者、作業できる担当者を示します。予算を固定していない場合は「上限」や「初期費用と運用費を分けて提示」など、比較できる出し方を依頼します。金額を伏せる場合でも、想定する規模や期間がなければ提案がばらつきます。

提案を比較できるRFPにする評価表

選定基準は、RFPを配る前に社内で合意しておきます。評価後に都合のよい項目を追加すると、説明責任を果たしにくくなるためです。

評価軸	確認する質問	配点例
課題への適合	現状の課題を理解し、効果を測れるか	30
実現性	体制、工程、既存環境との接続に無理がないか	25
運用性	導入後に社内で回せるか、支援範囲は明確か	20
費用	初期・月額・追加費用の前提が分かるか	15
安全性	権限、データ保護、障害対応を確認できるか	10

初めて書くときの手順と、失敗した場合の戻し方

1. 依頼部門へ、困っている事実と改善したい状態を聞く
2. 現状の業務フロー、利用者、データ、既存環境を一枚にする
3. 必須・希望・提案歓迎へ要求を分類する
4. 情報システム、法務、経理、現場で前提をレビューする
5. 提案書の項目、質問期限、評価表を確定する
6. 候補会社へ説明し、質問と回答を全社へ共有する

レビューで要求が増えすぎたら、すぐ本文へ追記せず、目的に戻って優先度を付け直します。候補会社から「この条件では比較できない」と質問された場合は、回答だけで済ませず、全候補へ同じ情報を配るか、RFPを改訂して版数を更新します。

ありがちな失敗と、RFPを使わない選択肢

失敗	起きること	戻し方
目的が機能名だけ	高機能でも課題が残る	改善したい業務と指標を先に書く
対象範囲が曖昧	見積りと納品範囲がずれる	対象外・前提・追加条件を明記する
評価軸が後付け	選定理由を説明しにくい	配布前に評価表を承認する
質問回答を個別共有	情報の公平性が崩れる	全候補へ同じ回答を送る

案件が小さく、要件が定型で、既存の取引先へ明確な作業を依頼するだけなら、RFPではなく要件確認書や作業依頼書で足りる場合もあります。RFPを作ること自体が目的になりそうなら、規模・リスク・候補会社数を見て、簡易版にするか専門部署へ相談します。

RFPとは？よくある質問

RFPは誰が作るものですか？

発注側が中心になって作りますが、一人で内容を決めるものではありません。現場、情報システム、法務、経理などがそれぞれの条件を確認し、最終的な責任者が承認します。

RFPに予算を書くべきですか？

案件の方針によります。上限や予算帯を示すなら、初期費用・運用費・追加費用の区分も指定します。非公開にする場合でも、規模と期間は示して比較条件をそろえます。

RFPとRFIは同じですか？

同じではありません。RFIは情報提供依頼で、候補や技術の情報を集める段階に使います。RFPは条件を示して、具体的な提案と見積りを依頼する文書です。

まずは目的と対象範囲を一枚にする

RFPとは、立派な資料を作ることではなく、発注側と候補会社が同じ課題を見て提案を比べるための土台です。最初から完璧な要件を書こうとせず、目的、現状、対象範囲、必須条件を一枚にまとめてから、関係者へ確認を回します。

次の一歩は、依頼部門へ「改善したい状態」と「今回対象にしない範囲」をそれぞれ一つずつ聞くことです。答えがそろえば、RFPの章立てへ移し、未確定の点は未確定のまま質問期限と担当者を置いてください。

配布前の社内レビューで確認すること

RFPは、書き終えた時点で完成ではありません。候補会社へ配る前に、実際に提案を受ける人が読んで、同じ条件から見積もれるかを確認します。特に、現場が望む運用と、情報システム部門が守るセキュリティ条件が食い違っていないかを見ます。

• 目的が「導入すること」ではなく、改善したい業務や指標になっているか
• 対象部署・利用者・データ・対象外が、本文と図表で一致しているか
• 必須条件と希望条件が混ざっていないか
• 納期が社内承認やデータ移行の期間を含めて現実的か
• 評価表の点数だけでなく、失格条件や質問方法も決まっているか

レビューで意見が割れたら、担当者の好みで決めず、必須条件・希望条件・今後検討の三つへ分けます。要件を削るのではなく、今回の選定で確定させるものと、提案を受けて決めるものを分けると、候補会社へ伝える情報が整理されます。

版数と変更履歴を残す

質問への回答で条件が変わった場合は、RFPの版数、変更日、変更箇所、承認者を記録します。口頭で一社だけへ伝えた条件は、他社も知るべき内容なら全社へ共有します。回答を配布した日を残しておけば、後から「どの条件で提案したか」を確認できます。

記録する項目	例
版数・変更日	v1.1、2026年9月17日
変更理由	データ移行の対象範囲を明確化
影響する候補	全候補へ同時配布
承認者	依頼部門の責任者

提出後に残す記録と、導入へ渡す情報

提案を受け取ったら、提案書だけでなく、質問回答、見積りの前提、除外項目、追加費用の条件を同じフォルダで管理します。候補会社ごとにファイル名や提出日時をそろえると、比較表へ転記するときの抜けが減ります。

選定後は、採用した提案の内容を契約や要件定義へ引き継ぎます。RFPの表現と提案書の表現が違う部分は、何を採用したのかを確認し、口約束を残しません。特に納期、成果物、保守窓口、データの扱い、追加費用は、契約前に文書へ落とします。

この記録を残すと、選ばなかった会社へ断りを伝えるときにも、評価軸に沿って説明できます。将来、追加発注や別部署への展開をするときも、最初の前提と判断理由を再利用できます。RFPは配布のためだけでなく、プロジェクトの判断履歴として役立つ文書です。