RFP（提案依頼書）は、システム開発の目的・依頼範囲・予算・納期・選定基準を候補会社へ同じ条件で伝える資料です。完成仕様を作る必要はなく、未確定事項を明示し、各社の見積もり前提をそろえることが重要です。
RFPとは？要件定義書との違い
RFPとは「Request for Proposal」の略で、開発会社へ提案と見積もりを依頼するための文書です。発注者が解決したい課題や制約条件を示し、候補会社から実現方法、開発範囲、体制、費用、スケジュールなどの提案を受けます。
RFPの主な役割は、次の3つです。
- 候補会社へ同じ情報を渡し、提案条件をそろえる
- 価格だけでなく、課題理解や実現方法、体制も比較できるようにする
- 発注後の「依頼したつもり」「見積もりに含まれていない」という認識差を減らす
発注者が混同しやすい資料として、要件定義書と仕様書があります。要件定義（＝作るものと満たす条件を決める工程）は、通常、開発会社の選定後に発注者と開発会社が共同で進めます。RFPは、その開発会社を選ぶために、選定前の情報を整理する資料です。
| 比較項目 | RFP | 要件定義書 | 仕様書 |
|---|---|---|---|
| 主な目的 | 提案と見積もりを依頼する | 開発対象と条件を合意する | システムの具体的な動作や構造を定める |
| 作成時期 | 開発会社の選定前 | 選定後から設計前 | 要件定義後から設計・開発時 |
| 主な作成者 | 発注者。必要に応じて外部支援 | 発注者と開発会社 | 主に開発会社 |
| 情報の細かさ | 目的、範囲、制約、優先順位 | 機能、業務ルール、データ、品質条件 | 画面、処理、データ項目などの詳細 |
| 未確定事項 | 残っていてもよい | 開発前に合意していく | 原則として具体化する |
RFPの段階で画面や機能を細部まで確定する必要はありません。むしろ、実現方法を必要以上に指定すると、開発会社が持つ知見や代替案を引き出しにくくなります。「何を作るか」だけでなく、「誰のどの課題を、なぜ解決するのか」を伝えることが大切です。
RFPを作成したほうがよい案件
RFPは必須ではありませんが、次の案件では作成する効果が大きくなります。
- 複数の開発会社から提案や相見積もりを受ける
- 予算が大きく、経営会議や稟議で選定理由の説明が必要になる
- 経営、営業、現場、情報システムなど複数部門が関係する
- 既存システム、決済、会計、社内認証などとの連携がある
- データ移行やセキュリティに注意が必要である
- 新規サービスのため、実現方法も含めて提案してほしい
一方、数画面程度の小規模な改修や依頼先が決まっている案件では、数十ページのRFPは不要です。目的、対象範囲、必須要件、予算、希望時期を2〜5ページ程度にまとめるだけでも、依頼条件を整理できます。
RFPに記載する項目と実用テンプレート
良いRFPとは、ページ数が多い資料ではなく、候補会社が「何を前提に、どこまで見積もればよいか」を判断できる資料です。次の項目を基本テンプレートとして利用できます。
| 記載項目 | 主な内容 | 発注者が明確にしたいこと |
|---|---|---|
| プロジェクト概要 | 案件名、背景、実施目的 | なぜ今取り組むのか |
| 現状の課題 | 現行業務、困りごと、発生頻度 | 解決対象は何か |
| 目標・評価指標 | 時間削減、利用率、申込数など | 導入後に何をもって成功とするか |
| 利用者 | 利用者の種類、人数、端末、場所 | 誰がどのように使うか |
| 対象範囲 | 今回依頼する工程、対象業務 | 見積もりに含める境界はどこか |
| 機能要件 | 必要な操作や業務機能 | 初回リリースに何が必要か |
| 非機能要件 | 性能、セキュリティ、バックアップなど | 機能以外に満たす品質は何か |
| 外部連携 | 連携先、方式、担当窓口 | 調査や調整が必要な相手は誰か |
| データ移行 | データの種類、量、形式、品質 | 誰がどこまで整備・移行するか |
| プロジェクト条件 | 予算、納期、社内体制 | 提案上の制約は何か |
| 提案依頼事項 | 提案書の章立て、見積形式 | 各社から何を回答してほしいか |
| 選定方法 | 評価項目、日程、質疑方法 | 何を基準に選ぶか |
| 契約・運用条件 | 契約形態、検収、保守の要否 | 開発後までどこを依頼するか |
1. 背景・課題・目的
最初に、システムを導入する背景と解決したい課題を書きます。「顧客管理システムを作りたい」のような手段だけでは、開発会社は適切な提案をしにくくなります。
例えば、次のように現状と目標をセットで記載します。
- 現状：営業担当者が表計算ソフトへ個別に入力しており、案件状況を管理者が把握できない
- 課題：同じ情報の二重入力があり、月末の集計にも時間がかかる
- 目的：案件情報を一元化し、担当者と管理者が最新状況を確認できるようにする
- 評価方法：入力作業時間、集計時間、入力漏れ件数を導入前後で確認する
目標値が決まっていない場合は、無理に数値を作る必要はありません。「導入後にどの指標を測るか」まで決めておけば、提案の方向性をそろえやすくなります。
2. 利用者・業務フロー・権限
管理者、一般社員、取引先、一般消費者では、必要な画面、権限、セキュリティが異なります。利用者ごとに、人数、利用端末、利用場所、利用頻度を整理してください。
現行業務が複雑な場合は、文章だけでなく、次の流れが分かる簡単な業務フローを添付します。
- 誰が情報を受け取るか
- どの情報を入力・確認するか
- 誰が承認するか
- 次にどの部署やシステムへ渡すか
- 例外が起きたときに誰が処理するか
発注のご相談を受ける開発会社の立場では、抽象的な機能一覧より、実際に使用している帳票、入力ファイル、申請書、管理表があるほうが業務を具体的に理解できます。機密情報や個人情報は削除したうえで、サンプルを用意すると効果的です。
3. 機能の優先順位と対象外
機能は、少なくとも次の3段階に分けます。
- 必須：初回リリースに欠かせない
- 希望：予算や期間とのバランスで採用を判断する
- 将来：初回開発には含めず、後から追加する可能性がある
機能名だけでなく、「誰が、いつ、何をするための機能か」を添えてください。例えば「通知機能」だけでは、メールなのかアプリ内通知なのか、誰にどのタイミングで送るのかが分かりません。
あわせて、「今回の対象外」を明記することも重要です。例えば、データの手作業による補正、社内マニュアル作成、端末調達、既存システムの改修などが対象外であれば記載します。対象外が曖昧だと、候補会社ごとに見積範囲が変わってしまいます。
4. 非機能要件・外部連携・データ移行
非機能要件とは、画面上の機能以外に求める品質や運用条件のことです。発注者だけで数値を決めにくい項目もありますが、少なくとも利用状況と制約は伝えてください。
- 想定する利用者数と同時利用者数
- 繁忙時間帯やアクセスが集中するイベント
- 利用可能時間とメンテナンス可能時間
- 個人情報、決済情報、営業秘密などの取り扱い
- ログ（＝操作や処理の記録）の保存要否
- バックアップと復旧に関する希望
- 利用端末、OS、ブラウザ
- 社内のセキュリティ基準や監査条件
技術的な基準が分からない場合は、空欄にせず「想定同時利用者は100人。必要な構成と費用を提案希望」のように記載します。根拠のない性能値を指定するより、利用状況を示して提案を求めるほうが現実的です。
外部連携については、連携するシステム名だけでなく、仕様書の有無、契約状況、管理会社、問い合わせ窓口を整理します。データ移行では、件数だけでなく、データ形式、重複や欠損の有無、画像・添付ファイルの量も見積もりに影響します。
5. 予算・納期・契約条件
予算は可能な限り開示します。「500万〜800万円」「初年度は1,000万円以内」のように幅や上限を示すと、候補会社は予算内の優先順位を考えられます。
予算を伏せれば安い見積もりが出るとは限りません。各社が異なる完成像を想定し、300万円の最小構成と1,500万円の拡張構成が並ぶなど、比較できない提案が集まる可能性があります。予算が未確定なら、必須要件を満たす最小案、推奨案、将来拡張案の3案を依頼する方法があります。
納期は、次のように分けて伝えます。
- 絶対条件：法改正、イベント、既存契約終了など変更できない期限
- 希望条件：可能であれば実現したい公開時期
- 段階公開の可否：一部機能を先に公開できるか
契約については、請負契約（＝合意した成果物の完成を目的とする契約）か準委任契約（＝専門的な業務の遂行を依頼する契約）かという名称だけで判断せず、対象工程、成果物、変更時の手続き、検収条件を確認します。要件が固まっていない段階から全工程を固定価格にすると、開発会社がリスク分を見込むか、契約後の追加費用が増えることがあります。
配布前のRFPチェックリスト
- 開発の目的と現状の課題が書かれている
- 利用者、対象業務、対象範囲が分かる
- 必須、希望、将来の優先順位が分かれている
- 今回依頼しない対象が明記されている
- 外部連携先とデータ移行の前提が書かれている
- 予算の目安または上限が示されている
- 必須の納期と調整可能な希望時期が分かれている
- 候補会社へ回答してほしい項目が指定されている
- 見積もりに含める費用と含めない費用が指定されている
- 質問方法、提出期限、選定日程が書かれている
- 社内の決裁者と候補会社への回答担当者が決まっている
RFPの作り方と開発会社選定までの手順
RFP作成から開発会社の決定までは、一般的に4〜10週間程度が目安です。小規模で意思決定者が少なければ短縮できますが、関係部署や候補会社が多い案件では、社内調整と質疑に時間がかかります。
| 工程 | 期間の一般的な目安 | 主な作業 |
|---|---|---|
| 社内ヒアリング・資料収集 | 1〜3週間 | 課題、業務、要望、制約の整理 |
| RFP作成・社内承認 | 1〜3週間 | 優先順位、予算、評価基準の確定 |
| 候補会社選定・資料配布 | 数日〜1週間 | NDA締結、説明会、資料共有 |
| 質疑・提案書作成 | 2〜4週間 | 質問回答、提案、見積もり作成 |
| 評価・面談・決裁 | 1〜2週間 | 比較、追加確認、発注先決定 |
各工程は並行して進められるため、単純な合計とは限りません。大規模案件や社内審査が必要な案件では、2〜3カ月以上かかる場合もあります。
ステップ1：関係者から課題を集める
経営層、現場担当者、情報システム部門、経理、法務など、影響を受ける関係者へヒアリングします。要望をそのまま機能に置き換えるのではなく、次の順番で確認します。
- 現在どのような業務をしているか
- どこで時間、ミス、待ち時間が発生しているか
- どの程度の頻度で発生するか
- 現在はどのように回避しているか
- 改善した場合、誰にどのような効果があるか
部署ごとの要望が矛盾した場合は、RFPへ併記して候補会社に判断を委ねるのではなく、プロジェクト責任者が優先順位を決めます。
ステップ2：依頼範囲と社内分担を決める
企画、要件定義、デザイン、開発、テスト、データ移行、公開、保守運用のうち、どこからどこまで外注するかを決めます。
特に抜けやすいのが、データの整備、外部サービスの契約、利用規約やプライバシーポリシーの作成、社内マニュアル、利用者への案内です。開発会社へ依頼する作業と自社で行う作業を分け、担当者と期限を設定してください。
ステップ3：RFPと添付資料を作成する
RFP本体には判断に必要な要点をまとめ、詳細情報は添付資料に分けると読みやすくなります。添付資料の例は次のとおりです。
- 現行業務フロー
- 使用中の帳票や管理表のサンプル
- 機能要望一覧
- 既存システムの構成図や連携仕様書
- データ項目一覧と移行サンプル
- 社内セキュリティチェックシート
- 提案書と見積書の指定フォーマット
RFP内の未確定事項は隠さず、「要件定義で決定予定」「代替案を提案希望」「現行ベンダーへ確認中」と状態を明記します。候補会社が不確定要素を把握できれば、見積もりの前提やリスクを説明しやすくなります。
ステップ4：候補会社へ同条件で配布する
候補会社には同じRFP、添付資料、提出期限を渡します。機密資料を共有する場合は、NDA（＝秘密保持契約）を締結したうえで、閲覧者や保管方法を決めます。
候補会社から出た質問と回答は、特定企業の提案内容や機密情報を除き、原則として全社へ共有します。一社だけに補足説明をすると、見積もり条件が変わり、公平な比較が難しくなるためです。
提案期間は、一般的な案件で2〜4週間程度を確保します。複雑な連携やデータ移行があるのに数営業日で回答を求めると、十分な調査を行う会社ほど参加を見送る可能性があります。
ステップ5：提案書・見積書・担当者を評価する
評価項目と配点は、提案を受け取る前に決めます。以下は配点例であり、案件の目的に合わせて調整してください。
| 評価項目 | 配点例 | 確認内容 |
|---|---|---|
| 課題・目的への理解 | 20点 | 機能の説明だけでなく、課題を理解しているか |
| 提案内容の妥当性 | 20点 | 優先順位、代替案、将来拡張が適切か |
| 体制・担当者 | 20点 | 責任者、実務担当者、連絡方法が明確か |
| 見積もり・総費用 | 20点 | 前提、対象外、保守費用まで比較できるか |
| リスク・品質管理 | 10点 | 不確実性と対処方法を説明しているか |
| 保守・運用支援 | 10点 | 公開後の対応範囲や条件が明確か |
個人情報の取り扱いや必須納期など、満たさなければ採用できない条件は、点数評価ではなく必須条件として先に確認します。
また、提案書の完成度だけでなく、実際にプロジェクトへ参加する責任者や担当者との面談が重要です。営業担当者だけでなく、プロジェクト管理を担当する予定者に、要件変更時の対応、報告方法、想定リスクを質問してください。
複数社の見積もり条件をそろえる方法は、システム開発の相見積もり｜取り方と比較方法でも詳しく解説しています。
RFP作成の費用相場と失敗を防ぐポイント
RFP作成費用は、資料の作成だけを依頼するか、社内ヒアリングや候補会社選定まで支援してもらうかで変わります。以下は一般的な目安であり、開発規模、会議回数、対象部門、既存資料の状態によって増減します。
| 作成・支援方法 | 外部費用の一般的な目安 | 期間の目安 | 向いているケース |
|---|---|---|---|
| 自社で作成 | 原則0円 | 1〜4週間 | 課題、予算、依頼範囲が明確 |
| 外部によるレビュー・助言 | 10万〜50万円程度 | 1〜3週間 | 原案はあるが抜け漏れを確認したい |
| ヒアリングを含むRFP作成支援 | 30万〜150万円程度 | 1〜2カ月 | 技術整理や部門間調整が必要 |
| 選定・評価まで含む支援 | 80万〜300万円程度以上 | 2〜3カ月以上 | 大規模案件、複数部門、客観的な選定支援が必要 |
自社作成でも外部費用がかからないだけで、担当者のヒアリング、資料作成、会議、決裁には社内工数が必要です。外注する場合は、納品される文書のページ数ではなく、次の支援範囲を確認してください。
- 関係者へのヒアリングは含まれるか
- 現行業務や既存システムの調査は含まれるか
- 概算予算とスケジュールの検討は含まれるか
- 候補会社からの質問対応は含まれるか
- 提案書や見積書の評価支援は含まれるか
- 成果物を自社が自由に利用・修正できるか
開発も受注する会社へRFP作成を依頼すること自体は問題ではありません。ただし、複数社を公平に比較する場合は、特定の製品や開発方法を前提にしていないか、選定条件が一社に有利になっていないかを確認します。
見積書でそろえるべき条件
見積金額だけを横に並べても、対象範囲が異なれば比較できません。候補会社には、少なくとも次の内訳を求めます。
- 要件定義、設計、デザイン、開発、テストの工程別費用
- プロジェクト管理費用
- クラウド、外部サービス、ライセンスなどの利用料
- データ移行、操作研修、マニュアル作成の費用
- 公開後の保守運用費用
- 見積もりに含まれない作業
- 見積もりの前提となる機能、画面数、連携数
- 仕様変更時の追加費用の算定方法
初期開発費だけでなく、公開後に継続して発生するクラウド利用料、ライセンス、保守費用まで含めて比較します。最安値の提案が、長期的にも最も安いとは限りません。
よくある失敗と回避策
| よくある失敗 | 起こりやすい問題 | 回避策 |
|---|---|---|
| 目的より機能を細かく指定する | より良い代替案が出にくい | 課題と達成したい状態を先に書く |
| 予算を完全に伏せる | 規模の異なる提案が集まる | 幅、上限、段階案のいずれかを示す |
| すべてを必須にする | 費用と期間を調整できない | 必須、希望、将来に分ける |
| 対象外を書かない | 見積もり範囲が会社ごとに変わる | 自社対応と外注範囲を明記する |
| 未確定事項を記載しない | 契約後に追加費用や遅延が発生する | 未定、確認中、提案希望と明記する |
| 提案期限が短すぎる | 調査や担当者確保が不十分になる | 原則として2〜4週間程度を確保する |
| 価格だけで選定する | 品質、体制、保守条件を見落とす | 評価表と必須条件を事前に決める |
| 営業担当者だけと面談する | 開発開始後に対応の印象が変わる | 実際の責任者・担当予定者を確認する |
発注実務では、RFPが詳細すぎることより、「資料同士の数字が違う」「必須機能と予算が釣り合っていない」「誰が最終判断するか決まっていない」ことのほうが提案を難しくします。完成度を上げ続けるより、矛盾をなくし、未確定事項の決め方を示すことを優先してください。
RFPの作成段階から、依頼範囲、概算費用、実現方法を整理したい場合は、開発のご相談はこちらからご相談いただけます。
まとめ
- RFPは、候補会社へ同じ条件で提案と見積もりを依頼するための資料です
- 要件定義書や詳細仕様書ではないため、すべての機能や画面を確定する必要はありません
- 背景、課題、利用者、対象範囲、優先順位、予算、納期、選定基準を記載します
- 未確定事項は隠さず、「未定」「確認中」「提案希望」として判断方法を示します
- RFP作成から会社選定までは、一般的に4〜10週間程度が目安です
- 外部へ作成支援を依頼する費用は、レビューで10万〜50万円程度、作成支援で30万〜150万円程度が一つの目安です
- 見積もりは初期費用だけでなく、対象外、変更条件、保守運用費まで比較します
- 価格だけでなく、課題理解、提案内容、担当体制、リスク説明を評価することが重要です
よくある質問
RFPは必ず作成する必要がありますか？
必須ではありません。小規模な開発や依頼先が決まっている案件では、目的、対象範囲、必須機能、予算、希望時期を2〜5ページ程度に整理する方法でも進められます。複数社を比較する場合や、関係部署、外部連携、データ移行が多い場合は、RFPを作成したほうが条件を統一しやすくなります。
予算が決まっていなくてもRFPを出せますか？
RFPは出せますが、予算の上限や想定範囲を示したほうが、比較可能な提案を受けやすくなります。予算を決められない場合は、必須要件を満たす最小案、推奨案、将来拡張案に分けて、費用と期間の提示を依頼してください。
RFP作成前に画面や機能をすべて決めるべきですか？
すべて決める必要はありません。利用者、解決したい課題、必須業務、対象範囲、制約条件を優先して整理します。具体的な画面構成や実現方法は候補会社から提案を受け、選定後の要件定義で確定できます。
RFPを開発会社に作ってもらうことはできますか？
可能です。ただし、その会社が開発も受注する場合は、特定の製品や実現方法に偏っていないかを確認してください。複数社を公平に比較するなら、作成支援の範囲、成果物の利用権、候補会社への質疑対応、選定への関与を事前に決めることが重要です。