RFPは「ベンダー向けの依頼書」であり「自社の意思決定書」である
RFP（Request For Proposal、提案依頼書）は、システム発注や業務改革プロジェクトでベンダーに提案を依頼する文書です。表向きは「ベンダーに条件を伝えるための書類」ですが、実態はそれだけではありません。発注者である自社が、何を、なぜ、いくらで、どう実現したいのかを社内で言語化する文書でもあります。
RFPの質は、その後のベンダー選定・要件定義・受入のすべての品質を決めます。逆にRFPが曖昧なまま発注に進むと、ベンダーから返ってくる提案も曖昧になり、選定の判断軸が揺れ、要件定義で揉め、最後は「思ったものと違う」で受入が荒れます。
本記事では、中堅企業の発注者が初めてRFPを書く／前回失敗したプロジェクトの轍を踏まないために、RFPの骨格テンプレート（10章構成）と発注者がハマる9つの落とし穴、そして評価基準の作り方までを実務ベースで整理します。
RFPとは何か、何のために書くのか
RFI / RFP / RFQ の違い
発注前後で混同されがちな3つの文書の違いを整理します。
- RFI（Request For Information、情報提供依頼書）：ベンダーの実績や対応可能領域を事前に知るための文書。発注検討の初期、ロングリスト作成段階で使う。
- RFP（Request For Proposal、提案依頼書）：要件・予算感・スケジュール感を伝え、解決策の提案を依頼する文書。ショートリストに対して送る。
- RFQ（Request For Quotation、見積依頼書）：仕様が固まった後に、価格を比較するための文書。要件確定後の最終局面で使う。
中堅企業の発注実務では、RFIを省略して最初からRFPに進むケースも多いです。ただし候補ベンダーが3社以上あり、それぞれの得意領域が読みきれない場合は、軽いRFIを先に挟むと選定の精度が上がります。
RFPを書かない発注の何が危険か
「面識のあるベンダーだから」「前にお願いしたことがあるから」という理由でRFPを省略する発注は珍しくありません。しかしRFP不在の発注では、次のような事象が起きます。
- ベンダーが「察して」見積もる結果、提案内容が発注者の想定と微妙にずれる
- 追加要望が出るたびに「それは別途お見積もり」となり、最終的に予算が膨らむ
- 社内稟議で「なぜこのベンダーなのか」を説明する根拠がない
- プロジェクト後半で揉めても、契約書に立ち戻ったときの判断軸が薄い
RFPは「比較のため」だけの文書ではありません。発注者の意思を文字にして残すことで、後工程の判断基準を作る役割があります。
RFPは依頼書であり、意思決定書である
良いRFPは、書き終えた段階で社内の経営層・事業部・情シスのあいだで「このプロジェクトは何のためにやるのか」が揃っています。逆に、書きながら社内で意見が割れる項目があれば、そこは発注前に決着させるべき論点です。
RFPは、社内の意思を整える装置として機能します。この視点で書くと、RFPの章立ては自然と決まります。
RFPの骨格テンプレート（10章構成）
業界・規模を問わず通用する、汎用的なRFPの骨格は以下の10章です。各章で「最低限ここを書く」というポイントを併記します。
① 背景・目的（KGI / KPI）
- なぜこのプロジェクトをやるのか（経営課題・事業課題）
- 達成したい状態（KGI：売上・コスト・リードタイム等の数値）
- 達成度を測る指標（KPI）
「DXのため」「業務効率化のため」では足りません。「何が、いくら、いつまでに、どうなったら成功か」を数値で書きます。
② 現状業務（AsIs）と課題
- 現在の業務フロー（部門・役割・システム・帳票・手作業の発生箇所）
- 現状で発生している課題（具体的な事象、頻度、影響）
- 関連する既存システム・周辺システムの一覧
AsIsを書かずに「あるべき姿」だけ書くと、ベンダーは現状制約を読みきれず、提案が空中戦になります。
③ ToBe像／達成したいこと
- 新システム・新業務の到達イメージ
- 業務フローがどう変わるか（責任分担含む）
- 現状の課題のうち、どれを解決対象にするか／対象外にするか
すべてを解決しようとせず、「やらないこと」を明示するのがコツです。
④ 機能要件
- 必須機能と「あれば嬉しい」機能の区別
- 業務シナリオごとの操作フロー
- 連携が必要な外部システム・データ
機能要件は、システム言葉でなく業務シナリオの言葉で書きます。「マスタ管理機能」より「営業担当が顧客情報を1分以内で更新できる」のほうが伝わります。
⑤ 非機能要件
- 性能（同時利用者数、処理量、レスポンス目標）
- 可用性（稼働時間、メンテナンス窓、復旧目標）
- セキュリティ（認証、暗号化、ログ、監査要件）
- 運用・保守（保守時間、サポート窓口、SLA）
非機能要件は手薄になりがちですが、ここがコストとリスクの大半を決めます。IPA「非機能要求グレード」を参考にすると抜け漏れが減ります。
⑥ システム構成・技術的制約
- クラウド／オンプレ／ハイブリッドの方針
- 既存インフラ・ネットワークとの整合
- 採用済み・採用禁止の技術スタック（あれば）
⑦ プロジェクト体制と役割分担
- 発注側のプロジェクトオーナー・プロジェクトマネージャー・現場代表者
- 受注側に期待する体制（PM、SE、PMO、運用、サポート）
- 意思決定の権限と承認フロー
発注側の体制を書かないRFPは、ベンダーから「丸投げ案件」と読まれます。良いベンダーほど降りやすくなります。
⑧ スケジュール
- キックオフ希望時期、リリース希望時期
- 主要マイルストーン（要件定義完了、設計完了、テスト開始、本番リリース）
- 制約条件（決算期、繁忙期、関連システムの更新タイミング）
⑨ 予算感
- 初期費用と運用費用の年間レンジ
- 含む費用／含まない費用の切り分け（ライセンス・ハードウェア・教育費）
予算を伏せるRFPは、提案がブレます。レンジでよいので示すのが結果的に効率的です（理由は後述「落とし穴⑤」）。
⑩ 提案要件と評価基準
- 提案書のフォーマット・章立て指定
- 提示価格の内訳・前提条件の明記要求
- 提案期限、質疑応答期間、提案プレゼンの有無
- 評価基準とその重み付け
評価基準を事前に開示しておくと、提案の質が揃い、選定後の説明責任も果たしやすくなります。
発注者が必ずハマる9つの落とし穴
骨格を真面目に書いても、9つの典型的な落とし穴があります。Beekleがプロジェクト支援で繰り返し見てきた失敗パターンです。
落とし穴① 目的が「DXのため」で止まる
「DXのため」「業務効率化のため」「経営からの指示」という目的記述では、ベンダーは何を提案していいか分かりません。提案は抽象論になり、評価もできません。
処方箋：KGI（達成すべき数値）とKPI（途中で測る数値）を書く。「年間100時間の手作業削減」「受注リードタイムを3営業日から1営業日に」のように、動詞と数字で書きます。
落とし穴② 現状（AsIs）を書かずToBeだけ書く
「こんなシステムが欲しい」だけのRFPは、ベンダー側で現状の業務制約を勝手に推測して提案してきます。結果、要件定義に入ってから「現状ではそれは無理」と判明し、手戻りが発生します。
処方箋：現状の業務フロー・関連システム・帳票を、簡略でいいので添付する。完璧な業務フロー図は不要、A4一枚のスケッチで足ります。
落とし穴③ 機能要件をシステム言葉で書く
「マスタ管理機能」「ワークフロー機能」「ダッシュボード機能」というシステム名詞の羅列では、業務文脈が伝わりません。同じ「マスタ管理」でも、誰が何のために使うかで実装は全く変わります。
処方箋：業務シナリオで書く。「営業担当が外出先からスマートフォンで顧客情報を更新でき、その更新が10秒以内に他のメンバーの画面に反映される」のように、主語・場所・動作・期待をセットにします。
落とし穴④ 非機能要件を空欄にする
「非機能要件は分からないからベンダー任せ」というRFPでは、提案価格が大きくブレます。可用性99%と99.9%では、必要なインフラ構成が桁違いに違うからです。
処方箋：IPA「非機能要求グレード」のグレード表を参照し、レベル感で記述する。完璧でなくとも「同時利用50人、平日9〜18時の稼働、夜間バッチ可」のレベルで書けば提案がそろいます。
落とし穴⑤ 予算を伏せる
「予算は提案を見て判断します」というRFPは、ベンダーから見ると射程が読めません。結果、本気の提案ではなく無難なミドルレンジ提案になりがちです。さらに、提案後に「想定より高い」となって再提案を依頼すると、ベンダーの工数が無駄になり、関係も冷えます。
処方箋：レンジでよいので予算を開示する。「初期費用3,000〜5,000万円、年間運用1,000万円程度」のレンジでも、ベンダー側は提案の射程を絞れます。
落とし穴⑥ 評価基準なし＝値段勝負になる
評価基準を決めずに提案を集めると、最終的に経営層から「結局どこが一番安い？」と聞かれて値段勝負になります。安いベンダーは安いなりの理由があり、選定後に苦労します。
処方箋：評価項目（機能適合度／実績／体制／価格／運用品質など）と重み付け（合計100点）を事前に決めて、RFPに記載する。後述の「評価基準の作り方」で詳述します。
落とし穴⑦ スケジュールが現実離れで良いベンダーが降りる
「3ヶ月後に本番稼働」のような無理筋のスケジュールは、力量のあるベンダーから順に提案辞退します。残るのは「とりあえず受けます」のベンダーだけになり、結果プロジェクトが破綻します。
処方箋：希望スケジュールと「絶対譲れない期日」を分けて書く。期日に幅があるなら、ベンダー側に「貴社が考える現実的なスケジュールも併記してください」と依頼するのも有効です。
落とし穴⑧ 発注側の役割分担を書かない＝丸投げ案件と読まれる
RFPに「発注側の体制」を書かないと、ベンダーは「全部お任せでいいんだな」と解釈します。結果、要件定義の主役までベンダーがやることになり、発注者の意図と乖離した仕様が出来上がります。
処方箋：プロジェクトオーナー、プロジェクトマネージャー、業務側のキーパーソンを明記する。少なくとも誰がどの判断をするのか、責任分担表（RACI 等）の素案を入れます。
落とし穴⑨ 質疑応答プロセスを設計せず提案品質が落ちる
RFPを送付した後、ベンダー側からは必ず質問が来ます。これを個別メールで対応していると、回答内容がベンダーごとにブレ、提案の比較可能性が失われます。
処方箋：質疑応答の窓口を一本化し、受付期間・回答期日を明示する。質問と回答は全候補ベンダーに一斉共有するのが原則です（質問者を伏せる形でOK）。
Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。
評価基準の作り方（落とし穴⑥の深掘り）
評価基準は「点数を付けるルール」であると同時に「何を重視する会社なのか」を示す宣言でもあります。曖昧な評価基準は、選定会議を恣意的にします。
重み付け評価表のサンプル
典型的な評価項目と重み付けの例です。プロジェクトの性格に合わせて配分を変えます。
評価項目 | 重み | 主な観点 |
|---|---|---|
機能適合度 | 25 | 必須機能の充足度、業務シナリオへの整合 |
非機能適合度 | 15 | 性能・可用性・セキュリティ要件の充足 |
実績・経験 | 15 | 類似業界・類似規模での導入実績、PM経験 |
プロジェクト体制 | 15 | キーパーソンのアサイン、PM/SEのスキル、サポート体制 |
価格 | 20 | 初期費用、運用費用、内訳の妥当性 |
運用・保守品質 | 10 | SLA、サポート対応時間、ナレッジ移管 |
注意点として、価格の重みは20〜30%程度に抑えるのが定石です。価格を50%以上にすると、機能と品質が劣るベンダーが勝ってしまうリスクがあります。
価格と提案内容のバランスを取る式
価格を相対点で評価する場合、最安提示を満点とする単純比例ではなく、「想定予算に対する妥当性」で評価する方法が有効です。たとえば想定予算の80〜120%レンジで満点、それ以下は安すぎ（実装品質懸念）、それ以上は予算超過、と段階的に減点します。
これにより、極端な低価格提案で「実装品質が伴わない」ベンダーを自動的に除外できます。
評価会議で恣意性を排除する進め方
- 各評価者が独立して採点する（合議の前に個別採点）
- 採点理由を1〜2行で記録する
- 評価者間で点差が大きい項目だけ、議論で擦り合わせる
- 最終点数と選定理由を文書化し、稟議資料の根拠とする
合議で雰囲気で決めると、後で経営層から「なぜこのベンダー？」と問われたときに説明できなくなります。個別採点の記録が判断の根拠になります。
RFP公開後のプロセス設計
質疑応答（Q&A）の運用
- 受付窓口：発注側の特定担当者一人に集約
- 受付期間：RFP送付後1〜2週間
- 回答方式：質問と回答を整理して全ベンダーに一斉共有（質問者は伏せる）
- 回答期限：質疑締切から1週間以内が目安
提案プレゼンの聞き方
提案書を読むだけでは、ベンダーの実力やキーパーソンの相性が分かりません。プレゼン会では以下を確認します。
- 提案書の作成者と当日のプレゼン担当者は同じか（実装担当のPMが出てくるか）
- 難しい質問への対応の仕方（即答するか、持ち帰って正確に答えるか）
- 自社の業務理解度（「うちの業界では」が腹落ちしているか）
- リスクの率直な開示（リスクを正直に話すベンダーは信頼に足ります）
最終選定までの意思決定フロー
選定会議は、評価採点 → 経営層レビュー → 内示 → 契約交渉、の順で進めます。内示と契約は別物です。内示後の契約交渉で条件が大きく変わるなら再評価が必要、というルールを事前に決めておきます。
RFPテンプレート（章ごとの雛形）
本記事の骨格テンプレートを、Wordや表計算で使える章立てとして整理します。発注者の現場で使いやすいように、Beekleが提供している/tools/story-builderでは、業務シナリオを発注者の言葉で構造化できます。/tools/flow-mapperではAsIs/ToBeの業務フロー図を作成できます。/tools/scope-managerでは、評価軸の重み付けやテーマの優先順位整理に使えます。
必要に応じて、ブラウザ上でこれらのツールを使ってRFPの素材を作り、Word/Excelに貼り付けて整える運用を推奨します。
よくある質問
Q. RFPは何ページくらいが適切ですか？
A. プロジェクト規模によりますが、中堅企業の標準的なシステム発注で20〜40ページ程度です。短すぎるとベンダー側の解釈の余地が増え、長すぎると読まれません。本文20ページ＋別添資料（業務フロー、現行帳票サンプル）の構成が読みやすいです。
Q. RFPに「予算」を書くと、ベンダーがその金額に寄せてくるのでは？
A. その懸念はもっともですが、実務では逆効果のほうが多いです。予算を伏せると、ベンダーは「下振れリスクを織り込んだ高め見積もり」を出すか、「無難なミドルレンジ提案」をします。レンジで開示するほうが、提案内容の比較可能性が高まります。
Q. RFPは何社くらいに送るのが適切ですか？
A. 3〜5社が標準です。少なすぎると比較にならず、多すぎると提案を読む発注側の負荷が高すぎて、評価がおざなりになります。
Q. 提案期限はどのくらい取ればいいですか？
A. RFP送付から提案提出まで、3〜4週間が標準です。これより短いと良いベンダーが提案を辞退します。質疑応答期間（1〜2週間）と提案執筆期間（2週間以上）を確保します。
Q. 提案後に「やっぱり別のベンダーがいい」となったらどうすべき？
A. 評価採点の記録に立ち戻ります。記録上の点差が小さければ再評価は妥当ですが、感覚で覆すのは避けるべきです。覆す場合は新しい評価軸が出てきた等の理由を文書化し、稟議で説明できる状態を作ります。
Q. RFPと契約書の関係は？
A. RFPは契約書ではありませんが、契約書の前提資料として位置付けられます。契約書では「本件の業務範囲はRFPおよび提案書に基づく」と参照されることが多いため、RFPは契約後も有効な文書として残ります。
Q. 自社にIT知識がなく、RFPが書けません。どうすればいいですか？
A. すべてを社内で書く必要はありません。第三者の発注支援（PMOコンサル、要件定義支援）を入れることで、業界相場や落とし穴を踏まえたRFPを短期間で作れます。Beekleでは発注者の側に立ったRFP作成支援を提供しています。
Q. RFPを書く時間がなく、ベンダーに「先に提案してもらう」のは？
A. アンチパターンです。ベンダーが書いた「自社にとって都合のいい提案」をRFPの代わりにすると、その後の比較や交渉で発注者側が不利になります。最低限の骨格RFPだけでも自社で書くべきです。
まとめ：RFPは自社の意思の明文化である
RFPはベンダー向けの依頼書という以上に、発注者である自社が、何を、なぜ、いくらで、どう実現したいのかを社内で言語化する文書です。RFPの質は、その後のベンダー選定・要件定義・受入のすべての品質を決めます。
本記事で紹介した10章の骨格と9つの落とし穴は、初めての発注でも前回の失敗を繰り返さないための実務ベースの指針です。完璧なRFPを最初から書く必要はありません。骨格を埋め、落とし穴を意識し、社内で議論を重ねることで、RFPは育ちます。そしてRFPが育つほど、プロジェクトの成功確率は上がります。
もし自社のRFPに不安がある、評価基準の作り方で迷っている、ベンダー選定の進め方を相談したい、という場合は、発注者の側に立つBeekleにお気軽にご相談ください。
Beekleでは、生成AI／CDP／業務システムの企画・要件定義・開発・運用までワンストップで支援しています。「何を作れば成功か」の整理、検証フェーズの設計、本番化判断まで、発注側の判断材料が揃うように伴走します。費用感の概算だけでも歓迎です。
関連記事
- ベンダー比較表の作り方｜評価軸の重み付け実例（公開予定）
- IPA非機能要求グレードを中堅企業の発注で実際に使う方法（公開予定）
- 準委任と請負の違い｜発注者が選ぶ判断軸（公開予定）
- 提案書を読む観点｜引っかかる人と引っかからない人の差（公開予定）
- 評価会議の進め方｜恣意性を排除する仕組み（公開予定）
- RFP配布後の質疑応答（Q&A）運用ガイド（公開予定）