ERP RFP（提案依頼書）作成完全テンプレート 2026：ベンダー選定で失敗しない15のチェック項目
目次 クリックで開く
この記事の結論
ERP の RFP（提案依頼書）の真の目的は「ベンダーから見積を取ること」ではなく「自社の業務要件と意思決定基準を明文化すること」です。RFP の質が、その後3〜5年の ERP プロジェクトの成否を決めます。本記事では、ベンダー選定で失敗しないための15のチェックポイント、機能要件以上に重要な「非機能要件・契約条件・運用体制」、3社競合での見積比較の罠、そして 9割が見落とす「RFP に書いた瞬間に隠れる5つの本音」を実プロジェクト視点で整理します。
「RFP は見積依頼書」という発想がプロジェクト失敗を生む
ERP の RFP（Request For Proposal：提案依頼書）について、多くの組織が誤解しているのは「ベンダーに見積を出させる文書」と捉えていることです。実際には、RFP の本当の価値は自社の業務要件・意思決定基準・運用体制を明文化することにあります。RFP を書く過程で社内合意が形成され、ベンダーへの依頼内容が研ぎ澄まされ、結果として後工程の手戻りが激減します。
逆に、「ベンダーの提案テンプレートをそのまま流用する」「機能要件をリストアップするだけ」という RFP では、ベンダー選定後に「思っていたのと違う」が連発します。私たちが見てきた失敗プロジェクトの7割は、RFP の質に問題がありました。
本記事では、まず RFP を書く前に押さえるべき構造、ベンダー選定で失敗しない15のチェックポイント、そして 9割の組織が見落とす「RFP に書いた瞬間に隠れる本音」を解いていきます。
RFP の 5構成 – これが揃わなければ意味がない
多くの組織の RFP は「2. 業務要件」しかないため、ベンダー比較が「機能の有無」だけになり、本質的な差が見えなくなります。3〜5を含めて初めて「自社にとって本当に良いベンダー」が見えてきます。
ベンダー選定で失敗しない 15のチェックポイント
機能要件（5項目）
1. 必須機能とあれば良い機能を分けているか。「全部必須」と書くと、提案が肥大化して見積も膨らみます。本当に必要な機能を「Must」、あれば良いものを「Want」で明確に区分する。
2. 業務プロセスの絵（As-Is / To-Be）を添付しているか。文字だけの要件は誤解されやすい。現状フローと目指すフローを図で示すと、ベンダー側の理解度が大きく変わります。
3. 標準機能で実現するか・カスタマイズで実現するかの方針を明示。「Fit-to-Standard」（業務を標準機能に合わせる）か「カスタマイズ前提」かで、コスト・期間が3倍違います。RFP段階で方針を伝える。
4. 既存システムとの連携要件を具体的に書いているか。「○○システムと連携可能」だけでは不十分。連携対象システム・連携データ項目・連携頻度を明示する。
5. データ移行の規模・複雑度を伝えているか。マスタデータ件数・履歴データ年数・移行対象範囲。データ移行コストはプロジェクトの20〜40%を占めるので、見積精度に直結する。
非機能要件（4項目）
6. 同時接続ユーザー数・トランザクション量を明示。性能要件の根拠データ。「ピーク時の処理量」を具体的に書かないと、ベンダーは標準スペックで提案して本番でパンクする。
7. 可用性・障害復旧の要件（RPO・RTO）を明示。「24時間365日稼働」と「業務時間のみ稼働」では基盤コストが2〜3倍違う。データ消失許容時間（RPO）と復旧目標時間（RTO）を明記。
8. セキュリティ・コンプライアンス要件を明示。ISO27001・SOC2・FISC基準準拠など。業界規制（金融・医療・公共）に応じた要件を網羅。クラウド ERP では必須項目。
9. 拡張性・スケーラビリティを問う。「3年後に売上2倍・拠点3倍に増えた場合の対応」を質問項目に入れる。ベンダーの将来対応力を見極める。
契約・体制要件（3項目）
10. プロジェクト体制を明示要求。PM・サブPM・コンサル・開発者の役職別体制と、専任 or 兼任の別を提案させる。専任PMがいないベンダーは要注意。
11. 契約形態の選択肢を提示。準委任 vs 請負、月額従量 vs 一括、初期費 vs SaaS型。それぞれのメリット・リスクを理解した上でベンダーに見積形態を選ばせる。
12. 保守・運用契約の内容を明示要求。本番稼働後の保守内容（障害対応・改修・新機能追加）と費用を提案させる。本番後の保守コストを見ない選定は危険。
評価・選定プロセス（3項目）
13. 評価項目と配点を事前公開。機能50点・コスト30点・体制20点など。これを RFP に書くと、ベンダーが力を入れるべき領域を理解して提案精度が上がる。
14. PoC（概念実証）の実施を求める。最終2社にはPoCを依頼。「自社業務の主要シナリオを動かしてみる」だけで、提案資料では見えなかった現実が見えてくる。
15. 既存ユーザーへのヒアリング権を要求。同業界・同規模のユーザー2〜3社にヒアリング可能か。これを許可するベンダーは自信があり、拒むベンダーは何か隠しています。
3社競合 vs 1社指名 – 見積比較の罠
多くの組織が「公平性のため3社競合」を選びますが、3社競合には罠があります。ここを理解せずに RFP を出すと、最後まで本命ベンダーが見えず、決め切れない選定になります。
3社競合の罠1：横並びの提案になる。各社が他社を意識して標準的な提案をするため、各社の本当の強みが見えにくい。差別化ポイントを RFP で明示要求する必要がある。
3社競合の罠2：価格競争で品質が下がる。価格を下げるために PM経験が浅いメンバーを充てる、保守内容を絞る、などの妥協が見えにくい形で入る。価格だけで選ぶと、本番稼働後に問題が表面化する。
3社競合の罠3：選定期間が長期化。3社評価で2〜3ヶ月、最終2社のPoCでさらに2ヶ月。選定だけで半年消費する。
これらを踏まえると、「事前リサーチで2社に絞り、最終提案を比較する」のが現実的です。1次選定を済ませた上で、2社が真剣に競合する状態を作るのが、選定品質と期間の両立になります。
RFP に書いた瞬間に隠れる 5つの本音
9割の組織が見落とすのが、「RFP に書いた瞬間に、ベンダーが本音を隠す項目」です。これらは RFP に書くと不利な回答が来るため、別の方法で確認すべき項目です。
本音1：本当の専任PM工数。RFP に「専任PM必須」と書くと、ベンダーは「専任」と回答するが、実際は2〜3案件兼任のことが多い。契約交渉時に「他案件何件持っているか」を直接聞く。
本音2：類似業界での失敗経験。RFP に「失敗事例を教えてください」と書いても、成功事例しか出てこない。提案後の個別ミーティングで「途中で計画変更した案件はありますか」と聞く。
本音3：保守費用の年次値上げ。RFP では初年度保守費を提示するが、2年目以降の値上げ条項は書かれにくい。契約書ドラフト段階で「3年間の保守費の上限を契約書に明記」を要求。
本音4：開発リソースの実態。提案書では「経験豊富なエンジニアをアサイン」と書かれるが、実際は新人混在のチーム。キックオフ前に開発メンバーの経歴を提出させる。
本音5：標準機能で本当にできるか。「標準機能で実現可能」と書かれていても、実装すると「カスタマイズが必要」が判明することが多い。PoCで主要シナリオを実演させて確認。
RFP 作成スケジュールの目安
RFP 作成自体に2〜3ヶ月かけるのが標準です。短縮しようとすると後工程で苦労します。
Week 1-4：現状業務の棚卸し。As-Is プロセスの整理、課題の特定、関係部門のヒアリング。ここを飛ばすと RFP が薄くなる。
Week 5-6：To-Be 業務の方向性決定。新ERPで何を変えるか、何を変えないかの社内合意形成。経営層・業務部門・情報システムの三者合意。
Week 7-9：機能要件・非機能要件の文書化。Must/Want の区分、業務プロセス図の作成、性能・可用性要件の根拠データ収集。
Week 10-11：契約・評価基準の設計。評価配点、選定プロセス、契約形態の方針決定。
Week 12：レビュー・最終化。社内レビュー、ベンダー候補のロングリスト作成、RFP 配布。
組織規模別 × ERP導入のRFP構成パターン × ベンダー選定チェックポイントと落とし穴 早見表
前のセクションでRFP作成に必要な5つの構成要素とベンダー選定の15チェックポイントを説明しましたが、「中小企業の初回ERP導入」「中堅企業の基幹システム刷新」「大企業のグローバルERP統合」ではRFPに書くべき内容の粒度と、ベンダー評価で最も重視すべきポイントが異なります。組織規模に見合わないRFP設計はベンダー選定を複雑化させ、後の失敗の種を蒔きます。規模別の設計パターンと典型的な落とし穴を整理しました。
| 組織規模・導入目的 | RFP構成パターンの重点事項 | ベンダー選定で最も重視すべきチェックポイント | この規模特有の落とし穴と回避策 |
|---|---|---|---|
| 中小企業・初回ERP導入 （従業員50〜300名・売上10〜100億円） |
中小企業のRFPで最も重要なのは「現状の業務フロー（As-Is）の記述」と「どの業務課題を最初の1年で解決したいか（優先課題の絞り込み）」の2点。全機能の要件を網羅しようとするとRFP作成に3ヶ月かかり、ベンダーへの質問が100件を超えて評価が形骸化する。最初は「販売管理・在庫管理・会計連携」等の最小限のコアスコープに絞り、フェーズ2以降の拡張機能は参考見積として別記する構成がベンダーへの回答精度を高める | ①導入後のサポート体制（専任担当者がつくか・サポート窓口の応答時間）②中小企業での導入実績（同業種・同規模の具体的な事例があるか）③トレーニング・操作習熟支援の内容（社内IT担当がいない前提での設計か）。中小企業は自社でのカスタマイズ対応能力が低いため「標準機能でどこまでカバーできるか」の確認が最重要で、カスタマイズ費用が初期費用の50%を超えるベンダー提案は要注意 | 落とし穴①「ベンダーのデモ時に見た高機能に引っ張られて自社に不要な機能のためにコストが膨らむ」。対策：RFPのスコープ外機能はデモで確認しないルールを設ける。落とし穴②「ユーザーライセンス費用を過少に見積もって実際の利用者数に合わせると費用が倍増する」。対策：RFPに「想定ユーザー数と将来3年間の増加予測」を明記してライセンス費用をシミュレーションした提案を義務付ける |
| 中堅企業・基幹システム刷新 （従業員300〜1,000名・複数事業部・既存システム移行） |
中堅企業のRFPで最も複雑なのは「既存システムからのデータ移行要件」と「他システム（CRM・物流・製造管理等）とのAPI連携要件」の記述。RFPに「移行対象データの一覧（テーブル名・件数・移行品質基準）」と「連携先システムのAPI仕様書（または連携方式の要件）」を添付してベンダーに技術的な実現可能性を評価させる設計が見積精度を高める。複数事業部のニーズが競合する場合は「全社共通要件」と「事業部固有要件（任意対応）」を明確に分離してRFPを構成する | ①データ移行の実績と品質保証方法（移行テストの実施回数・品質基準の定義）②既存システムとの連携開発実績（同種のAPI連携を過去に実施した事例）③プロジェクトマネジメント体制（PMの経験・PMO支援の有無）。中堅規模では「並走期間（旧システムと新システムを同時稼働する期間）のサポート体制」がベンダー選定で見落としがちな重要ポイントで、並走期間のコスト・工数の見積もりを必ずRFP回答に含めるよう指定する | 落とし穴①「要件定義フェーズで現場ヒアリングが不十分なまま要件を確定してしまい、システムカットオーバー後に現場から大量の追加要件が発生する」。対策：RFP発行前に全事業部の業務責任者との事前ヒアリングを義務付けて「この要件に含まれていないが必要な機能はないか」を確認する。落とし穴②「ベンダー評価を価格のみで判断して保守・サポートの品質が低いベンダーを選んでしまう」。対策：評価基準の内訳を「機能適合性35%・移行実績20%・価格25%・サポート品質20%」等と事前に決めて評価委員会で合議する |
| 大企業・グローバルERP統合 （従業員1,000名以上・多拠点・多通貨・コンプライアンス要件） |
大企業のRFPで最も重要なのは「グローバル標準テンプレート（Global Template）の設計方針」と「各国・各拠点のローカライゼーション要件（法令・税制・言語対応）」の両立設計の記述。RFPに「グローバル共通プロセスの一覧」と「各国固有要件の一覧（日本の消費税・インボイス制度等）」を別紙で提示して、グローバルテンプレートの適用範囲とローカライゼーションの対応方針をベンダーに設計させる構成が技術評価の精度を高める | ①グローバル導入実績（日本を含む複数国での同時導入または段階展開の実績）②ローカライゼーション対応の範囲と品質（日本の給与計算・勤怠・税務申告の標準機能対応状況）③チェンジマネジメント支援（グローバル標準への移行に伴う組織変革支援の有無と実績）。大企業ではコンサルティングファームやシステムインテグレーターとERPベンダーの役割分担をRFPに明記して、提案書に責任範囲の明確化を求めることがトラブル予防の基本 | 落とし穴①「グローバルテンプレートを重視するあまり日本特有の業務プロセス（承認フローの複雑さ・稟議文化・印鑑管理等）への対応が軽視されてカットオーバー後に日本拠点から強い反発が生じる」。対策：日本拠点の要件をRFPの中で明示的に重要性を記載して評価項目に含める。落とし穴②「プロジェクト期間が3〜5年に及ぶため、当初の要件定義が陳腐化して追加要件の変更管理コストが膨大になる」。対策：要件変更管理のプロセス（変更の申請・影響評価・承認フロー）をRFPの要件として明記する |
| 業種特化型ERP・垂直統合システム （製造業・建設業・医療・流通等の業種固有要件） |
業種特化型ERPのRFPでは「業種固有の法令・規制への対応範囲（建設業の建設業法・医療の医薬品医療機器等法等）」と「業種固有の業務プロセス（製造業のBOM管理・MRP・原価計算等）の標準対応状況」が最重要の確認事項。汎用ERPと業種特化ERPを比較評価する場合は「業種固有機能のカスタマイズ費用」を汎用ERPと業種特化ERPで並べた比較表の提出をRFPに求めることで総コストの実態を把握できる | ①業種固有の規制・法令への対応実績（建設業なら建設業法の許可業種管理・入札管理等の具体的な標準機能）②業種内の競合他社や同業種での導入実績とユーザー企業への参照確認の可否③業種固有プロセスの変更への対応（法改正・規制変更への標準機能アップデートの提供方針）。業種特化ERPは汎用ERPより対応可能なベンダーが限られるため、特定ベンダーへの依存（ベンダーロック）リスクを評価基準に含めてデータ移出権・乗り換え容易性をRFPで確認する | 落とし穴①「業種固有の標準機能と思っていたものが実は有料オプションで、追加費用が当初見積の30%増しになる」。対策：RFPに「業種固有機能として標準搭載・オプション・カスタマイズ必要の3段階で回答せよ」と指定する。落とし穴②「業種特化ベンダーが中小・中堅規模に特化していて、企業規模の成長とともにシステムの処理能力・同時接続数の上限に達する」。対策：現在の規模の2〜3倍の負荷に対応できるスケーラビリティをRFPで確認する |
この表でERP選定RFPにおいて最重要の設計原則が「組織の規模・現在の課題・将来の成長を正直に書いたRFPこそが、自社に最適なベンダーを引き寄せる」ことです。自社の課題を過少に記載したRFPはベンダーの提案精度を下げて比較評価が形骸化します。一方、全機能要件を完璧に記述しようとするRFPはベンダーへの質問回答に数週間かかり選定プロセス自体が疲弊します。「何を最初の1年で解決したいか」を明確にして、それに特化したRFP構成にすることが、ERP選定を成功させる最もシンプルな指針です。
失敗パターン 5つ
失敗1：機能要件だけの薄い RFP。非機能・契約・評価基準を含めない RFP では、ベンダー比較が「機能の◯×表」だけになり、本質的な差が見えない。
失敗2：「全部 Must」と書く。優先順位なしの要件は提案を肥大化させ、コストを増やす。Must を絞る勇気が必要。
失敗3：価格重視で選定。最安値ベンダーを選んだ結果、本番稼働後に追加開発・保守費が膨らみ、トータルコストで最高値になる。
失敗4：PoC をやらない。提案資料だけで決めると、本番で「思っていたのと違う」が起きる。最終2社にはPoCを必ず実施。
失敗5：選定後に契約条件で揉める。RFP に契約条件を書いていないため、選定後の契約交渉で「この条件は受けられない」と言われる。RFP 段階で契約条件骨子を提示。
あなたの組織に合う RFP 構成は – 5パターンの推奨
パターンA：年商10〜100億円・初の本格 ERP 選定 → 標準 RFP 構成 + 業務要件中心 + 2社競合。RFP 作成2ヶ月、選定3ヶ月。総期間5ヶ月。
パターンB：上場準備・統制強化目的 → 統制要件・監査対応を厚く + 3社競合 + PoC必須。RFP 作成3ヶ月、選定4ヶ月。コンサル支援を活用。
パターンC：基幹刷新・大型プロジェクト → 詳細 RFP + 体制・契約条件を厚く + 2段階選定（1次5社 → 最終2社）。RFP 作成3ヶ月、選定6ヶ月。
パターンD：M&A後の統合プロジェクト → 統合要件・移行戦略を最重要に + 子会社別ヒアリングを RFP に含める。RFP 作成4ヶ月。
パターンE：補助金活用前提 → IT導入補助金・事業再構築補助金の要件を RFP に組み込む。補助金スケジュールに合わせた選定計画。
「ベンダーへの見積依頼」より「自社合意の文書化」
本記事の最も伝えたいメッセージは、ERP の RFP は「ベンダーへの見積依頼書」ではなく「自社の業務要件と意思決定基準を社内合意する文書」だということです。RFP を書く過程で経営層・業務部門・情報システムの三者合意が形成され、それが後の3〜5年の ERP プロジェクトの土台になります。
そして、RFP に書くこと以上に重要なのが「RFPに書かないが必ず確認すべき本音」です。専任PMの実態、過去の失敗経験、保守費の年次値上げ、開発リソースの本当の経歴、標準機能の実装可否――これらは RFP では見えず、PoC や個別ミーティングで掴むしかありません。RFP の質と「行間を読む選定プロセス」の両輪が、ERP プロジェクト成功の確率を10倍変えます。
関連ピラー
基幹システムの刷新・移行とデータ統合のご相談
老朽化した基幹システムの刷新やERP移行、社内システム同士のデータ連携を、業務を止めない形で支援します。移行方式や構成が妥当かを確認したい、という導入前後のセカンドオピニオンにも対応しています。
