「ベンダー 3 社から見積をもらったが、金額が 2,000 万円から 8,000 万円までバラついた」「機能要件を口頭で伝えたら、納品物が想定と違っていた」「発注書を交わしたが、追加費用の根拠を巡って揉めた」――中堅企業（300-3,000 名規模）の情シス・経営企画から最も多い相談です。
原因の多くは「RFP（Request for Proposal、提案依頼書）と発注書が中堅企業の規模感に合っていない」ことに集約されます。中小企業向けの簡易テンプレでは情報量が不足し、大企業向けの分厚いテンプレでは情シス 1-3 人体制では運用しきれません。
本記事では、中堅企業に最適化した RFP 必須 12 セクション、発注書のサンプル、ベンダー選定 6 基準、評価マトリクス を提示します。Word 版 RFP テンプレートと Excel 版評価表の無料ダウンロードを記事中盤で配布しています。
RFP 不在で起きる典型的な失敗 5 つ
中堅企業がシステム開発を外注する際、RFP を整備せずに進めると以下の問題が高確率で起こります。
- 相見積もりが成立しない。要件が口頭ベースだと、ベンダーごとに前提条件の解釈が異なり、見積金額の比較ができません。実際、独立行政法人情報処理推進機構（IPA）の「ソフトウェア開発分析データ集」でも、要件定義の精度が見積精度に直結すると報告されています（参考:
- ベンダー比較ができない。提案書のフォーマットが各社バラバラだと、機能の有無や運用体制を横並びで比較できず「印象」で選定することになります。
- 機能漏れが発覚する。要件をリスト化していないため、開発フェーズの後半で「あの機能が無い」と発覚し、追加見積が発生します。
- 予算オーバーが常態化する。日本情報システム・ユーザー協会（JUAS）の「企業 IT 動向調査」では、システム開発プロジェクトの 4 割超で予算超過が発生していると報告されています（参考:
- 工期遅延が連鎖する。要件未確定のまま開発に入り、要件定義フェーズに想定の 1.5-2 倍の期間がかかります。
これら 5 つは「ベンダーの問題」ではなく「発注側の準備不足の問題」です。RFP と発注書の整備は、発注側の最重要タスクと言えます。
目次
- RFP とは何か / なぜ中堅企業の発注で必須か
- RFP に必須の 12 セクション
- 中堅向け RFP テンプレート（具体的セクション例 + サンプル文）
- ベンダー選定 6 基準
- 提案書受領後の評価マトリクス（重み付き採点表サンプル）
- 典型的な落とし穴 4 つ
- よくある質問（FAQ）
- 関連記事
- 参考資料
RFP とは何か / なぜ中堅企業の発注で必須か
RFP の定義
RFP（Request for Proposal、提案依頼書）は、システム開発の発注側がベンダーに対して「こういう課題があり、こういうシステムを作りたい。提案と見積を出してください」と依頼する文書です。RFI（Request for Information、情報提供依頼）と RFQ（Request for Quotation、見積依頼）の中間に位置し、ベンダーから提案書（Proposal）と見積を引き出すための「仕様書のたたき台」になります。
経済産業省の「システム発注者向け契約モデル」や独立行政法人情報処理推進機構（IPA）の「非機能要求グレード」も、RFP 段階での要件整理を強く推奨しています（参考:
中堅企業に RFP が特に必要な 3 つの理由
中堅企業（300-3,000 名）は、中小企業と大企業のはざまで RFP の重要性が最も高い層です。
- 情シス 1-3 人体制で属人化リスクが高い。RFP を文書化しないと、担当者の異動や退職でプロジェクト要件が失われます。
- 発注金額が 1,000 万円-1 億円規模になる。中小企業の数百万円規模と違い、稟議に経営会議や監査役チェックが入るため、文書化された根拠が必要です。
- 複数部門が利用するシステムが多い。経営企画、営業、製造、人事など複数部門の要件を統合する必要があり、RFP がない状態では要件衝突が発覚しません。
つまり、中堅企業で RFP を作らずに発注するのは、稟議リスク・属人化リスク・要件衝突リスクの 3 点で危険です。
RFP に必須の 12 セクション
中堅企業向け RFP の必須 12 セクションは以下の通りです。これは IPA の「非機能要求グレード」、JISA（情報サービス産業協会）の「RFP / 提案書のひな形」、JEITA（電子情報技術産業協会）の「ソフトウェア取引のあり方」を統合し、中堅企業の発注実務に合わせて整理したものです。
| # | セクション | 目的 | 想定ページ数 |
|---|---|---|---|
| 1 | 経営課題と背景 | プロジェクトの上位目的を共有 | 1-2 |
| 2 | 業務要件 | 現状業務（As-Is）と目指す業務（To-Be） | 2-4 |
| 3 | 機能要件 | 必須機能 / 望ましい機能 / 対象外機能 | 3-6 |
| 4 | 非機能要件 | 性能、可用性、セキュリティ、運用 | 2-4 |
| 5 | 制約条件 | 既存システム連携、技術スタック、規制 | 1-2 |
| 6 | 開発体制要望 | 体制図、PM 経験、稼働率、契約形態 | 1 |
| 7 | 納期とマイルストーン | フェーズ区切り、検収条件 | 1 |
| 8 | 予算レンジ | 上限額、フェーズ別配分の目安 | 0.5-1 |
| 9 | 評価基準 | 評価軸と重み付け | 1 |
| 10 | 提案書フォーマット | 章立て、ページ数、提出物一覧 | 1 |
| 11 | 質疑応答プロセス | Q&A 締切、回答方式、横展開ポリシー | 0.5 |
| 12 | 契約条件 | 契約形態、支払条件、知財、撤退条件 | 1-2 |
なぜ 12 セクションなのか
これより少ないと「機能要件のみ」「機能 + 非機能のみ」になり、運用・契約・評価が抜けます。これより多いと、中小企業向け簡易テンプレや、大企業向けの 50-100 ページ大全になり、中堅企業の情シス 1-3 人体制では運用できません。12 セクションは、中堅企業の規模感における 必要十分 の境界線です。
中堅向け RFP テンプレート（具体的セクション例 + サンプル文）
ここでは 12 セクションのうち、特に書き方で迷いやすい 6 つのサンプル文を抜粋します。Word 版テンプレ全文は無料 DL でご提供します（記事下部のリンクから）。
セクション 1: 経営課題と背景（サンプル文）
当社は従業員 800 名規模の精密機器製造業で、創業から 32 年経過した基幹系システムを使用している。2026 年に法定耐用年数を迎えるサーバー群、および 2027 年に EOL を迎えるミドルウェアにより、現行システムの継続運用は困難である。本プロジェクトでは、生産管理・購買・在庫・出荷の 4 業務領域を再構築し、(1) 月次決算の早期化（現状 12 営業日 → 5 営業日）、(2) 在庫精度の向上（現状 92% → 99%）、(3) システム運用コストの 30% 削減 を達成することを目的とする。
ポイントは「現状値」と「目標値」を数字で明記することです。「業務効率化」「DX 推進」のような抽象表現は提案精度を下げます。
セクション 3: 機能要件（サンプル）
機能要件は 必須 / 望ましい / 対象外 の 3 階層で整理します。
| 機能カテゴリ | 機能名 | 区分 | 備考 |
|---|---|---|---|
| 受注管理 | EDI 受注自動取込 | 必須 | 主要顧客 12 社 |
| 受注管理 | 与信限度額自動チェック | 望ましい | Phase 2 でも可 |
| 在庫管理 | 倉庫間移動指示 | 必須 | 3 拠点 |
| 在庫管理 | 自動発注（適正在庫アラート） | 望ましい | AI 不要 |
| 出荷管理 | TMS 連携 | 対象外 | 別プロジェクト |
セクション 4: 非機能要件（サンプル）
非機能要件は IPA の「非機能要求グレード」のレベル区分（レベル 0-5）を流用すると、ベンダー間の解釈差が縮みます。
- 可用性: レベル 3（24 時間 365 日、計画停止月 1 回 4 時間以内、目標稼働率 99.9%）
- 性能: 同時接続 200 セッション、応答時間 3 秒以内（95 パーセンタイル）
- 拡張性: 5 年後にデータ量 3 倍、ユーザー数 1.5 倍を前提
- セキュリティ: ISMS 準拠、IPA「Web アプリケーション セキュリティ要件書」準拠
- 運用: 障害一次切り分けは社内、二次対応はベンダー、SLA は別紙
セクション 6: 開発体制要望（サンプル）
- PM: PMP 保有 or 同等案件 5 件以上経験者を専任で
- アーキテクト: 提案技術スタックでの実案件 3 件以上を専任 50% 以上で
- 開発メンバー: オフショア活用可、ただし日本人 BSE が 1 人以上常駐
- ベンダー側体制図と各メンバーの稼働率（%）を提案書に明記すること
セクション 8: 予算レンジ（サンプル）
- 上限予算: 6,000 万円（要件定義 + 開発 + 初期運用 6 ヶ月込）
- 想定フェーズ配分: 要件定義 15% / 設計 20% / 開発 45% / テスト 15% / 移行・初期運用 5%
- 予算超過の可能性がある場合、提案時に明示し、削減可能な機能候補を提示すること
予算を伏せる発注は提案精度を下げます。中堅企業は上限を提示し、その中での最適解をベンダーに考えさせる方が成功率が高い傾向にあります。
セクション 12: 契約条件（サンプル）
- 契約形態: 要件定義 → 準委任 / 設計以降 → 請負（多段階契約）
- 支払条件: 月次精算（準委任） / マイルストーン払い 30% + 30% + 40%（請負）
- 知財: 業務委託成果物の著作権は当社に帰属、ただし汎用ライブラリは除く
- 撤退条件: 要件定義完了時点での解約権を双方に付与（違約金は実費分のみ）
撤退条件はベンダー側に嫌がられますが、要件定義段階での齟齬を発見したときの保険として中堅企業は明記推奨です。経済産業省「情報システム・モデル取引・契約書」も多段階契約と中途解約権を中堅・大企業案件で推奨しています。
発注書（注文書）サンプルの構成
RFP 後にベンダーを決定したら、発注書を取り交わします。中堅企業の発注書は以下 8 項目の構成が標準です。
| # | 発注書項目 | 内容 | 備考 |
|---|---|---|---|
| 1 | 件名 | プロジェクト名と契約フェーズ | 例: 基幹系再構築 / 要件定義フェーズ |
| 2 | 発注金額 | 税抜・税込・消費税の内訳 | 多段階契約は各フェーズ別に発行 |
| 3 | 納期 | 開始日 / 完了日 / 検収期限 | カレンダー日基準で明記 |
| 4 | 検収条件 | 検収成果物リスト / 検収基準 | RFP の評価基準と紐付け |
| 5 | 支払条件 | 支払時期 / 支払方法 / 振込手数料 | マイルストーン払いが標準 |
| 6 | 仕様書（別紙） | RFP + 提案書 + 合意事項を統合 | 発注書の本質はここ |
| 7 | 変更管理（CR） | 変更要求の手続きと費用算定式 | 後日の追加費用交渉で必須 |
| 8 | 解除条件 | 中途解約権 / 違約金 / 損害賠償上限 | RFP セクション 12 の合意を反映 |
>### この場で動ける資料を無料 DL
>上記 12 セクションの Word 版 RFP テンプレート と、後述する Excel 版ベンダー評価表（重み付き採点シート） をワンセットで配布しています。社内回覧・カスタマイズ・テンプレ流用すべて自由です。
ベンダー選定 6 基準
中堅企業のベンダー選定で重視すべき 6 基準を提示します。中小企業向けの「3 基準」「5 基準」では取りこぼしが出る領域です。
基準 1: 実績（同規模・同業界の本番稼働）
確認するのは「事例ページの掲載数」ではなく「自社規模（300-3,000 名）かつ自社業界での本番稼働実績」です。実績の少ない領域は、開発期間が 1.3-1.5 倍に伸びる傾向があります。
基準 2: 体制（PM 専任 + 日本人窓口の確保）
中堅企業の発注金額（1,000 万-1 億円）では、PM が他案件と兼任しているとコミュニケーション遅延が頻発します。専任 PM を契約書に明記できるかが境界線です。
基準 3: 価格透明性（人月単価と工数の根拠）
合計金額だけでなく、職種別人月単価（PM、アーキテクト、開発、テスト）と工数（人月数）の内訳を提示できるベンダーが望ましいです。「一式」表記のベンダーは、追加費用交渉で揉める可能性が高くなります。
基準 4: コミュニケーション（質問応答の速さと深さ）
RFP 段階の質疑応答で「48 時間以内に質問が返ってくるか」「質問の意図を踏まえた回答か」を観察します。提案フェーズで遅いベンダーは、開発フェーズではさらに遅くなります。
基準 5: 撤退条件（フェーズ区切りでの解約権）
要件定義完了時点での双方解約権を契約で認めるベンダーは、自社の見積精度に自信がある証左です。逆に、初期から大型一括契約のみを提示するベンダーは要注意です。
基準 6: 運用体制（保守 / インシデント対応 / 改善提案）
開発完了後の運用フェーズが 5-10 年続く中堅企業のシステムでは、運用体制の評価が最重要です。SLA、インシデント対応の一次窓口、改善提案の頻度（四半期 / 半期 / 年次）まで RFP 段階で確認します。
提案書受領後の評価マトリクス（重み付き採点表サンプル）
ベンダー 3-5 社から提案を受けた後、以下のような重み付き採点表で評価します。「印象点」を「定量点」に変換するのがゴールです。
| 評価軸 | 重み | A 社得点 | A 社加重点 | B 社得点 | B 社加重点 | C 社得点 | C 社加重点 |
|---|---|---|---|---|---|---|---|
| 機能適合度 | 25% | 4 | 1.00 | 5 | 1.25 | 3 | 0.75 |
| 価格適正性 | 20% | 3 | 0.60 | 4 | 0.80 | 5 | 1.00 |
| 実装力（実績） | 15% | 5 | 0.75 | 3 | 0.45 | 4 | 0.60 |
| 体制と PM | 15% | 4 | 0.60 | 4 | 0.60 | 3 | 0.45 |
| 運用継続性 | 15% | 3 | 0.45 | 5 | 0.75 | 4 | 0.60 |
| リスクと撤退条件 | 10% | 4 | 0.40 | 3 | 0.30 | 5 | 0.50 |
| 合計 | 100% | 3.80 | 4.15 | 3.90 |
評価会議は 2-3 名の合議制 が推奨です。1 人だと「印象」が混入し、5 人以上だと収束しません。情シス、経営企画、業務側部門代表の 3 名構成が中堅企業の実務でうまく回るパターンです。
典型的な落とし穴 4 つ
RFP 作成時に陥りやすい 4 つの落とし穴を整理します。
落とし穴 1: 過度に詳細にしてしまう
100 ページ超の RFP を作ると、ベンダー営業が読み切れず、提案精度が下がります。中堅企業の RFP は 15-25 ページ が適正範囲です。
落とし穴 2: 機能リストを羅列するだけ
機能だけ書いて、なぜその機能が必要か（業務上の目的）を書かないと、ベンダー側で代替案が提案されにくくなります。「業務要件 → 機能要件」の順で書き、機能の上位目的を必ず示します。
落とし穴 3: 評価基準が曖昧
「総合的に判断」と書くと、選定後に「なぜ A 社にしたのか」を説明できなくなり、稟議差戻しや経営層からの追及につながります。重み付き評価マトリクスを RFP 段階で公開する方が、ベンダー側も提案を最適化できます。
落とし穴 4: 質疑応答プロセスを省略する
「質問は随時メールで」とすると、A 社の質問への回答が B 社に共有されず、提案条件が不公平になります。Q&A 締切日を設定し、全社の質問と回答を全社に横展開 が公平性の標準です。
よくある質問（FAQ）
Q1. RFP は何ページが適正ですか？
中堅企業（300-3,000 名）の場合、15-25 ページが標準です。10 ページ未満だと情報不足、30 ページ超だと読み切れないため提案精度が落ちます。
Q2. RFP テンプレートの作成期間はどれくらいですか？
ゼロから作る場合、情シス 1 人の専任で 4-6 週間、業務側ヒアリング含めて 6-10 週間が中堅企業の標準です。Word テンプレ流用なら 2-3 週間に短縮可能です。
Q3. RFP と発注書（注文書）の関係は？
RFP は「提案を依頼する文書」、発注書は「採用後に契約を確定する文書」です。RFP の内容と提案書の合意事項が、発注書の別紙仕様書として組み込まれます。RFP の質が低いと、発注書の仕様書も曖昧になり、追加費用交渉の火種になります。
Q4. 何社に RFP を出すべきですか？
3-5 社が中堅企業の標準です。3 社未満だと比較が難しく、6 社以上だと評価作業が破綻します。事前に RFI（情報提供依頼）で 8-15 社のロングリストから 3-5 社のショートリストに絞り込むのが理想です。
Q5. 発注後の追加費用を抑えるコツは？
(1) RFP 段階で「望ましい機能」と「対象外機能」を明記する、(2) 多段階契約（要件定義 = 準委任、設計以降 = 請負）にする、(3) 変更管理プロセス（CR: Change Request）を契約書に明記する、の 3 点です。
Q6. 内製と外注のどちらが向いていますか？
中堅企業の基幹系再構築は外注が標準（内製化リソース不足のため）、業務システムの拡張開発は内製比率を上げる傾向にあります。判断軸は「5 年運用するか」「業務改修頻度が高いか」の 2 軸です。
Q7. RFP に予算を書くべきか書かないべきか？
書く方が提案精度が上がります。「上限額」+ 「フェーズ別配分の目安」を書くことで、ベンダー側は予算内での最適解を提案できます。伏せると、過大見積か低めの釣り見積のどちらかに振れます。
関連記事
- システム開発のRFPテンプレート｜稟議を一発で通す10章構成と書き方【2026年版】 — 稟議突破に特化した 10 章構成
- 業界別 RFP テンプレート＋ベンダー評価マトリクス｜製造・小売・物流・医療 — 業界固有要件と 5 軸スコアリング
- RFP 評価マトリクス 数値化テンプレート 5 軸 2026 — 100 点満点の定量評価
- RFI / RFP / RFQ の違いと使い分け 中堅企業 2026 年版 — 3 文書の使い分け
- 中堅企業 1 人情シスのための AI エージェント RFP テンプレート 2026 — 100-300 名規模の AI エージェント特化版
- IT 開発ベンダーの選び方｜失敗しない 5 つの判断基準と RFP テンプレート — 中小企業向け 5 基準
- システム開発 要件定義テンプレート — RFP の前段階となる要件定義
参考資料
- 独立行政法人情報処理推進機構（IPA）「非機能要求グレード 2018」
- 独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集 2024」
- 経済産業省「情報システム・モデル取引・契約書」
- 日本情報システム・ユーザー協会（JUAS）「企業 IT 動向調査」
- 情報サービス産業協会（JISA）「RFP / 提案書のひな形」
- 電子情報技術産業協会（JEITA）「ソフトウェア取引のあり方」
中堅企業の RFP 作成・ベンダー選定をサポートします
GXO 株式会社では、中堅企業（300-3,000 名）のシステム開発発注における RFP 作成支援、ベンダーロングリスト・ショートリスト作成、提案書評価支援、契約書レビューを伴走型で提供しています。情シス 1-3 人体制で RFP を 4-6 週間で仕上げる必要がある中堅企業から、ご相談を多くいただいています。