EC RFPの書き方｜テンプレ項目・送付先選定・落とし穴を徹底解説

はじめに

「ECサイト構築のRFP（提案依頼書）を作ることになったが、社内に過去のサンプルがなく、どの項目をどの粒度で書けばよいか迷う」
「RFPを送ってもベンダーから的外れな提案が返ってきて、選定の判断材料にならない」
「そもそもRFPと要件定義書はどう違うのか、線引きが社内で揃っていない」

ECサイトの新規構築・リプレイスを検討する事業担当者・EC責任者・情シス担当者から、RFP作成の入り口でよく聞かれる悩みです。

RFP（Request For Proposal、提案依頼書）は、ベンダー候補に「うちはこういう要件のECを作りたい。どう実現するか、いくらでやれるか、提案してほしい」と依頼する文書で、要件定義の初期に作成し、ベンダー選定の出発点になります。
RFPの精度が高ければ、提案の質も比較のしやすさも大きく上がり、選定後の手戻りも減ります。

逆に、目的・スコープ・予算・スケジュールが曖昧なRFPを送ると、提案の前提条件がベンダーごとにズレ、横並びで比較しづらくなります。

結果として、選定が「総額の安さ」「営業の印象」のような表層的な判断軸に流れ、後工程で「想定と違う」が連発する典型パターンに陥ります。

本記事では、EC RFPの位置づけと要件定義書・仕様書との違い、RFPの標準的なテンプレ項目、章ごとの記述例、ベンダー送付先の選び方、回収後の提案評価方法、よくある落とし穴とその回避策、Shopify構築を視野に入れる場合のRFP記載のポイントまで、実務でそのまま使える形で解説します。

目次

1. EC RFPとは｜要件定義書・仕様書との違い

2. RFPを作成する目的とECならではの特殊性

3. EC RFPの標準的な章立てとテンプレ全体像

4. プロジェクト概要・背景・目的の書き方

5. 現状・課題・スコープの書き方

6. 想定要件（業務・機能・非機能）の書き方

7. 予算・スケジュール・体制の書き方

8. 提案依頼事項と評価基準の書き方

9. RFP送付先ベンダーの選び方

10. 提案回収後の評価とベンダー選定プロセス

11. Shopify構築を視野に入れる場合のRFP記載のポイント

12. EC RFPでよくある落とし穴と回避策

13. まとめ

---

【無料相談】EC RFP作成・ベンダー選定をご支援します ECサイト構築・リプレイスのRFP作成、ベンダー送付先の選定、提案評価のフレームについて、Shopifyの専門家が無料でご相談に乗ります。社内テンプレートの叩き台作成から、提案回収後の選定支援まで対応可能です。 
 [無料で相談する]　[資料をダウンロード]

---

1. EC RFPとは｜要件定義書・仕様書との違い

EC RFP（Request For Proposal、提案依頼書）は、ECサイトを構築・リプレイスする際に、ベンダー候補に対して「自社の要件」「依頼したい提案内容」「評価基準」を提示する文書です。

ベンダー側はRFPを読み取り、「自社で実現可能か」「概算費用はいくらか」「どんな体制・スケジュールで対応できるか」を提案書としてまとめ、発注側に返送します。

実務では「RFP」「要件定義書」「仕様書」がしばしば混在して語られますが、目的・粒度・タイミングが異なるドキュメントです。

1-1. RFP・要件定義書・仕様書の違い

3つのドキュメントの違いを整理します。

実務の流れは、RFP（要件のたたき台と提案依頼）→ 要件定義書（要件の合意）→ 仕様書（実装設計）と段階的に粒度が深まります。

1-2. RFPに盛り込む要件の粒度

RFPの段階で、要件定義書並みの詳細な機能要件を書き込もうとすると、作成だけで数ヶ月かかり、ベンダー選定が遅れます。

一方で、要件が薄すぎるRFPを送ると、ベンダーは提案の前提を自社の想像で埋めるため、提案内容も見積もりもバラついて比較できなくなります。

RFPに盛り込むべきは「ベンダーが提案書を組み立てるために必要な最小限の情報」です。
具体的には、プロジェクトの目的・背景、対象とする業務領域・スコープ、必須機能と任意機能の区別、概算予算とスケジュールの希望、選定基準と提案フォーマット。

詳細な画面遷移や非機能の数値要件は、ベンダー選定後の要件定義フェーズで詰めれば十分です。

1-3. RFI・RFQとの違い

RFPの周辺には、RFI（Request For Information、情報提供依頼書）とRFQ（Request For Quotation、見積依頼書）という関連ドキュメントもあります。

中小規模のECプロジェクトでは、RFIを省略してRFPから入るパターンが一般的です。本記事は中堅以上のECサイト構築を想定し、RFPに焦点を絞って解説します。

2. RFPを作成する目的とECならではの特殊性

2-1. RFPが果たす3つの役割

1つ目は、ベンダー比較の土台作りです。複数ベンダーから提案を受けるとき、各社が異なる前提で提案書を作ると、提案内容も見積もりも横並びにできません。
RFPで前提条件・要件・選定基準を統一しておくことで、各社の提案を同じ物差しで評価できます。

2つ目は、社内の意思統一です。RFPを書く過程で、事業部・情シス・経営層が「何を作るか」「なぜ作るか」「どこまでやるか」を文書で擦り合わせます。
RFP作成自体が社内合意形成のプロセスとして機能します。

3つ目は、提案責任の明確化です。RFPに「この前提で提案してください」と明記すれば、ベンダーは前提を踏まえた提案を返す責任を負います。
後の契約交渉で、提案書とRFPが矛盾していないかを照合できる根拠資料にもなります。

2-2. ECサイトRFPならではの特殊性

ECサイト構築のRFPは、一般的な業務システムのRFPと比べて特殊な要素が複数あります。

これらの要素は、ベンダー側の得意・不得意がはっきり分かれます。
RFPの段階で「決済はどのサービスとつなぐ想定か」「基幹システムは何で、どの粒度で同期したいか」「マーケティングツールは何を使う予定か」を明示しておくと、ベンダー側は自社の実績と照らし合わせて、適合度の高い提案を返しやすくなります。

2-3. RFPを作らないリスク

ECサイトは構築後に運用が長く続く資産です。RFPなしで進めると、次のリスクが顕在化しやすくなります。

• 各社の見積もりの前提が揃わず、横並び比較ができない

• 「何を依頼したか」が口頭ベースになり、契約後の認識齟齬の温床になる

• 社内の合意形成プロセスが省略され、稟議・承認の段階で差し戻される

• 後工程で要件追加が発生したとき、契約スコープか追加発注かの線引きが曖昧になる

総額300万円程度までの小規模構築であれば省略可能なケースもありますが、500万円以上の規模、もしくは複数ベンダーから提案を取るプロジェクトでは、RFPを整備してから動くほうが結果的に安く・速く・トラブルなく進みます。

3. EC RFPの標準的な章立てとテンプレ全体像

EC RFPの章立ては、業界で広く使われている標準パターンがあります。社内テンプレートを作るときも、このベースを土台にすると外しません。

3-1. 標準的なRFPの章立て（13章構成）

EC RFPに必要な章を、目的別に整理した一覧です。

この13章は、規模によって膨らんだり省略されたりしますが、骨格としては共通です。中小規模のECなら30〜50ページ、中堅〜大規模で50〜100ページ程度に収まるのが一般的です。

3-2. 章ごとの分量配分の考え方

ボリューム配分で大事なのは、機能要件と現状・スコープに分量を厚く配分することです。ここが曖昧だと、ベンダーは前提を埋めるために独自解釈を始めます。逆に、目的や予算は冗長に書かなくても伝わります。

3-3. RFPテンプレートの入手元

社内に過去のRFPサンプルがない場合、実務でよく使われるテンプレートの入手元には、IPA（情報処理推進機構）が公開している政府調達向けRFPテンプレート、大手SI企業が公開している業界別RFPサンプル、ECコンサルティング会社が提供する業界特化のRFPひな形などがあります。

特にIPAの『情報システム・モデル取引・契約書』『非機能要求グレード』は、項目立て・記述粒度の参考として無料で公開されており、業務システム全般のRFP・要件定義のベースラインとして広く参照されています（出典：IPA『情報システム・モデル取引・契約書』『非機能要求グレード』）。このベースを土台にして、EC固有の要素（決済・物流・マーケ・SEO等）を追加カスタマイズする進め方が、最も効率的です。

4. プロジェクト概要・背景・目的の書き方

RFPの冒頭に置くプロジェクト概要・背景・目的は、ベンダーが「自社で取れる案件か」「どんなチームで対応すべきか」を判断する最初の入口です。
ここが曖昧だと、ベンダーは「何のために作るのか分からない」状態で提案を組み立てることになり、提案の方向性がズレます。

4-1. プロジェクト概要の書き方

プロジェクト概要では、対象サイト（新規構築／既存サイトのリプレイス／追加開発）、対象事業（BtoC、BtoB、越境）、想定リリース時期、想定予算規模、提案ベンダー数の想定をコンパクトに記載します。
「当社のBtoC向け既存ECサイトを、現行のオープンソース基盤からクラウドSaaS型のECプラットフォームへリプレイスする取り組み」のような書き出しから、上記の主要パラメータを箇条書きで添える形式が読みやすくなります。

4-2. 背景・目的の書き方

背景・目的セクションでは、「なぜこのリプレイスが必要なのか」を定量・定性の両面で示します。

たとえば背景として「スマホ経由のCVRがPCの約半分」「直販サイトの売上構成比が伸び悩み」「機能追加のたびに開発期間が長期化」「基幹システム連携が手動運用に依存」を挙げ、目的・KPIとして「スマホCVRを現状比1.5倍」「直販EC売上構成比を25%から40%へ」「新機能リリースサイクルを四半期から月次へ」「リリース後12ヶ月以内に直販EC売上15億円達成」のように落とし込みます。

定量目標が明示されていると、ベンダーは「その目標達成のために、こういう技術構成・体制で提案する」というロジックを組み立てやすくなります。提案の質は、目標の解像度に強く影響されます。

5. 現状・課題・スコープの書き方

現状・課題・スコープのセクションは、ベンダー側の見積もり精度を最も左右する章です。
ここを曖昧にすると、ベンダーは「現状把握のためのヒアリングを別途実施する」前提で提案してきて、結果として「ヒアリング工数」が見積もりに乗り、総額が膨らみます。

5-1. 現状システムの記載項目

現行ECサイトの状況を、ベンダーが提案するために必要な粒度で開示します。

これらは社内のシステム担当者からヒアリングして数字を埋めます。公開してよい数字とNGの数字（特にピーク時アクセス・月商の規模）の線引きは、事前に経営層と擦り合わせておきます。

NDA締結後の追加開示でもよい項目は「別途NDA締結後に開示」と明示すれば問題ありません。

5-2. スコープ（対象範囲）の書き方

スコープは、「今回のプロジェクトで作るもの」と「今回は作らないもの」を明確に分けます。

これが曖昧だと、ベンダーは念のため広めに見積もりに含め、総額が膨らみます。

「今回は対象外だが将来拡張を前提とした設計」を明示しておくと、ベンダーは将来を見据えたアーキテクチャを提案しやすくなります。

5-3. 課題感の書き方

現状の課題は、「業務課題」「技術課題」「データ課題」「組織課題」の4分類で整理すると、ベンダー側にとって読み取りやすくなります。

たとえば業務課題なら「受注後の手動オペレーションが多くピーク時に処理が滞る」「商品マスタ登録に平均15分かかる」、技術課題なら「現行ECのコードに長年のカスタマイズが積層し影響範囲特定が困難」「セキュリティパッチ適用のたびにリグレッションが発生」というように、現場で起きている事象レベルで記載します。

事象ベースで記載すると、ベンダー側は「自社のソリューションで何を解消できるか」を提案書に落とし込みやすくなります。
抽象的な「DX推進」「業務効率化」だけでは、具体的な打ち手は提案できません。

---

【無料相談】EC RFPの現状整理・スコープ設計をご支援します RFPに記載する現行システム情報の整理、スコープ範囲の線引き、課題感の言語化について、Shopifyの専門家が無料でご相談に乗ります。社内ヒアリングの叩き台作成から、ベンダー送付前のレビューまで対応可能です。
 [無料で相談する]　[資料をダウンロード]

---

6. 想定要件（業務・機能・非機能）の書き方

RFPの中で最もボリュームが大きい章が、想定要件のセクションです。
要件定義書の段階で詰める「詳細レベル」までは書き込まず、ベンダーが提案を組み立てるために必要な「優先度付きの要件リスト」までを記載するのがRFP段階の基本姿勢です。

6-1. 業務要件の書き方

業務要件は、「誰が」「どんな業務で」「何を」やるかを、業務の流れに沿って整理します。
受注管理業務であれば、担当部門と人員、月間業務量（注文件数・ピーク時件数）、主な業務フロー（注文→受注連携→在庫確認→出荷指示→WMS連携→出荷完了通知）を記載します。

ECサイトの業務要件は、決済直後から出荷・返品まで「お金と商品の動き」を伴うため、業務フロー図とセットでベンダーに渡すと提案の精度が上がります。

6-2. 機能要件の書き方（優先度付き一覧）

機能要件には、優先度を付けるのがおすすめです。
優先度の表記は、MoSCoW法（Must / Should / Could / Won’t）が広く使われています。

たとえば商品管理機能なら「商品マスタ登録・編集・削除：Must」「バリエーション管理：Must」「予約販売：Should」「レビュー・口コミ：Could」、受注・決済機能なら「カート機能：Must」「決済代行連携（カード・コンビニ）：Must」「後払い決済：Should」「サブスク課金：Could」というように、機能カテゴリごとに優先度をセットで提示します。

優先度の明示は、ベンダーが「Mustだけで構築する案」「Shouldまで含めた案」を出し分ける根拠になります。
優先度なしの長い機能リストを渡すと、ベンダー側は「すべてを実装する前提」で見積もりを膨らませがちです。

6-3. 非機能要件の書き方

非機能要件は、性能・可用性・セキュリティ・運用・保守の各分野で、最低限の基準を示します。
詳細な数値の確定は要件定義フェーズに譲りますが、RFP段階で「どの分野を重視するか」のレベル感は提示します。

ページ表示速度・ピーク時の同時接続数・可用性は、ECサイトでは売上に直結する非機能のため、業界の常識的な数字を盛り込みます。

参考までに、ページ表示速度が1秒遅れるごとにコンバージョン率が約7%低下するというGoogleの調査もあり、性能要件は売上への影響を意識した数字に設定する価値があります（出典：Google『The Need for Mobile Speed』2018年）。

6-4. 外部連携・データ要件の書き方

外部連携・データ要件は、ECサイトの見積もりが膨らむ大きな要因です。
連携先・連携データ・連携方式・連携頻度を、できる限り具体的に書き出します。

連携先のシステム名・バージョン、想定する連携方式（API、CSV、FTP等）が分かっている範囲で記載すると、ベンダー側は連携工数を見積もりやすくなります。
データ移行についても、移行対象、想定レコード数、移行のタイミング、データクレンジングの責任分担を明示しておきます。

7. 予算・スケジュール・体制の書き方

予算とスケジュールは、ベンダー側が「自社で取れる案件か」「どの規模のチームで対応するか」を判断する重要情報です。

7-1. 予算の書き方

予算は、上限額の具体値ではなく、レンジで示すのが実務的です。

「予算非開示」もNGではありませんが、その場合はベンダーから複数パターンの提案を依頼することになります。
複数提案は比較が難しくなるため、社内で予算合意ができている場合はレンジで開示するほうが、選定プロセスがスムーズです。

予算には「初期構築費用」「運用保守費用」「ライセンス・利用料」を分けて記載すると、ベンダーは見積もりを項目別に分解しやすくなります。

7-2. スケジュールの書き方

スケジュールは、希望リリース時期と主要マイルストーン（RFP発行→提案受領→一次選考→二次選考→内定→要件定義→設計・開発→テスト→リリース）を、月単位で示します。

リリース時期の希望理由（繁忙期・新事業立ち上げ・既存契約終了等）を一言添えると、ベンダー側はスケジュール調整の優先順位を理解できます。

7-3. 体制と役割分担の書き方

体制は、発注側の体制とベンダー側に期待する体制の両方を明示します。

【発注側体制】
- プロジェクトオーナー：事業部長（最終意思決定者）
- プロジェクトマネージャー：EC事業推進部 課長（専任）
- 業務側担当：CS部門・物流部門の各リーダー（兼務）
- システム側担当：情報システム部 部長・課長（兼務）

【ベンダー側に期待する体制】
- プロジェクトマネージャー：週1回の定例参加（常駐不要）
- 業務分析担当：要件定義フェーズで業務ヒアリングを実施
- 開発リード：技術選定・設計の責任者
- 運用保守担当：リリース後の運用引き継ぎ

発注側体制を開示すると、ベンダー側は「どの工程に発注側を巻き込むか」「どこまで内製で巻き取れるか」を提案書に反映できます。

ベンダー側に期待する体制も、「PMの稼働率」「業務分析の有無」など、関与の濃淡を明示しておくと、提案の人月構成と単価がブレません。

8. 提案依頼事項と評価基準の書き方

RFPの後半に置く提案依頼事項と評価基準は、ベンダーが提案書をどう構成し、何を強調すべきかを伝える章です。
ここが空白だと、ベンダーは各社独自のフォーマットで提案書を作り、横並び比較がしづらくなります。

8-1. 提案依頼事項の書き方

提案書に含めてほしい記載項目を、章単位で指定します。

1. 会社概要・実績：EC構築・運用実績（規模・業種別に5件以上）、同業界での実績の有無

2. 提案ソリューション：採用するECプラットフォーム・技術スタック、採用理由、標準機能と独自開発の切り分け

3. 業務適合性：主要業務フローに対する適合方法、業務改善の提案ポイント

4. 概算見積もり：初期構築費用（項目別内訳）、月額運用費用（項目別内訳）、ライセンス・利用料、5年間の総保有コスト（TCO）試算

5. プロジェクト体制とスケジュール：提案チーム編成（役割・経験・稼働率）、全体スケジュール（マイルストーン付き）

6. リスクと前提条件：提案の前提条件、想定リスクと対応方針

7. 採用後の運用保守体制：運用体制、障害対応、改善サイクル

このレベルで指定しておけば、各社の提案書は構成が揃い、評価がスムーズに進みます。

8-2. 評価基準と配点

評価基準は、提案を点数化するための観点と配点を提示します。

配点は、自社で重視する軸に重みを置きます。価格重視のプロジェクトなら「見積もり」を30点に、品質重視なら「提案ソリューションの適合性」を40点に、というように調整します。

評価基準を事前に開示すると、ベンダー側は重点項目を強化した提案書を作ってきます。逆に隠すと、ベンダーは万遍なく書くしかなくなり、各社の差別化が見えづらくなります。

8-3. 選定プロセスの書き方

選定プロセスは、ベンダーが「いつ何が起きるか」を把握できるように、3ステップで明示します。

• ステップ1：書類審査（一次選考）：提案書のみで評価。実績・体制・提案ソリューションを中心に3〜5社を選定

• ステップ2：プレゼンテーション（二次選考）：選定された3〜5社にプレゼン（60分／社）を実施。重点確認事項は事前開示

• ステップ3：最終調整・内定：最終候補1〜2社と契約条件・スコープ・体制を擦り合わせ、内定

選定の透明性が高いほど、優良ベンダーから提案を取りやすくなります。

逆に「選定プロセス非開示」「決定理由非開示」のRFPは、ベンダー側にとってリスクが大きい案件と映り、有力ベンダーが辞退するケースもあります。

9. RFP送付先ベンダーの選び方

RFPを作っても、送付するベンダーの選定が雑だと、返ってくる提案の質が安定しません。ベンダー候補は、「実績軸」「規模軸」「特性軸」の3つで絞り込みます。

9-1. 候補ベンダーの母集団作り

ECサイト構築のベンダー母集団は、大きく次の4タイプに分かれます。

自社の要件にマッチするタイプを2〜3つ絞り、それぞれから2〜3社ずつ候補を選ぶと、6〜8社の母集団が作れます。そこから書類審査でRFPを送る3〜5社まで絞り込むのが、一般的な進め方です。

9-2. ベンダー選定の評価軸

候補ベンダーを母集団から絞り込む段階で、次の評価軸でスクリーニングします。

• 同業界での実績：自社業界（アパレル、コスメ、食品、BtoB等）での構築実績の有無

• 同規模の実績：月商・PV・SKU数で同規模のECを構築した実績

• 技術スタックの適合：自社が想定するプラットフォーム・連携先への対応経験

• 体制の安定性：継続的に対応できる組織規模、エース担当者の集中リスク

• 運用保守の体制：構築後の運用引き継ぎ体制、改善サポート

これらを公開情報（公式サイト、事例ページ、IR資料）と、業界内のリファレンスチェック（取引先・同業他社からの非公式ヒアリング）で確認します。

9-3. プラットフォームの絞り込みと並行

ベンダー選定とプラットフォーム選定は、2パターンあります。

1つ目は、プラットフォームを先に絞ってからベンダーを選ぶパターンです。

「Shopify Plusで作る」「ecbeingで作る」のように技術選定を先行させ、各プラットフォームの認定パートナーから候補を選びます。プラットフォームの強みが要件に直結する場合に向いています。

2つ目は、プラットフォーム選定をベンダー提案に委ねるパターンです。

RFPでは要件のみを示し、各ベンダーが「最適なプラットフォーム」を提案する形式で、ベンダーの技術選定スキルを見極めるパターンとして使えます。

中堅以上のEC構築では、後者（ベンダー提案型）を採用するケースが増えています。プラットフォームごとに得意・不得意があり、要件次第で最適解が変わるためです。

9-4. 送付先の社数と送付方法

送付先の社数は、3〜5社が実務的にバランスがよい範囲です。2社以下では競争原理が働かず、6社以上は提案評価の工数が膨大になります。

送付方法は、各ベンダーの担当者宛に同タイミングで送付し、提案書の提出締切も全社統一します。
質問受付の窓口も統一し、寄せられた質問と回答は全候補ベンダーに共有することで、情報の非対称性をなくします（質問受付期間と回答公開のスケジュールはRFP内に明記します）。

10. 提案回収後の評価とベンダー選定プロセス

提案を回収したあとは、評価軸に沿って点数化し、書類審査・プレゼン・最終調整の3段階で絞り込みます。
このプロセスを社内で明文化しておくと、選定後の「なぜこのベンダーを選んだのか」の説明責任を果たしやすくなります。

10-1. 書類審査の進め方

書類審査では、RFPで明示した評価基準に沿って各社の提案書を点数化します。
評価者は3〜5名のチームで実施するのが理想で、事業部・情シス・PMの3部署の代表者を入れると観点が偏りません。

各評価者が個別に点数を付け、合議でズレを擦り合わせます。

点数の差が大きい項目（評価者間で20点以上の差がある等）は、評価軸の解釈がズレている可能性が高いため、合議で観点を統一します。
書類審査を通過する3〜5社は、合計点数とともに「強み・懸念点」をセットで残しておくと、二次選考のプレゼンで重点的に確認すべき事項が明確になります。

10-2. プレゼンテーションの進め方

二次選考のプレゼンは、各社60〜90分の枠で実施するのが標準です。

質疑応答では、書類審査で出てきた「懸念点」を重点的に確認します。

たとえば「提案のソリューションは魅力的だが、当社の在庫連携の複雑さに対応できるか心配」という懸念があれば、「過去に類似の連携を実装した事例」「想定するアーキテクチャ」を具体的に質問します。

プレゼン後は、評価者全員でその場で振り返りを実施し、印象を記録します。
複数社のプレゼンが終わってから振り返ると、各社の印象が混ざって判別がつきにくくなります。

10-3. 最終調整・内定の進め方

最終候補1〜2社まで絞ったあとは、契約条件・スコープ・体制の最終調整に入ります。このフェーズで詰めるべき事項は、契約スコープと追加発注の方針、主要メンバーのアサイン保証、マイルストーンと検収基準、支払い条件、知的財産権、機密保持、検収後の瑕疵担保・運用保守の引き継ぎなどです。

最終調整で大きな前提変更（スコープ縮小・予算減額等）が必要になった場合は、いったん書類審査の点数を再評価し、第2位ベンダーとも条件を擦り合わせる選択肢を持っておきます。

10-4. 落選ベンダーへのフィードバック

落選ベンダーには、簡潔な落選理由をフィードバックする慣習があります。
提案にかけた工数への敬意であるとともに、次回以降のRFPに同じベンダーが応募する可能性を考えると、関係性の維持に意味があります。

具体的すぎる落選理由は守秘義務やトラブルの原因になるため、抽象度のバランスを取ります。
「実績・体制・提案内容で高く評価したが、最終的に業務適合度／予算／スケジュールの観点で別社が優位となった」というような簡潔な伝え方が一般的です。

---

【無料相談】RFP回収後のベンダー評価・選定をご支援します 受領した提案書の評価、プレゼン質疑の設計、最終候補との契約条件調整について、Shopifyの専門家が無料でご相談に乗ります。社内の選定基準の明文化、評価者間の合議運営まで対応可能です。
 [無料で相談する]　[資料をダウンロード]

---

11. Shopify構築を視野に入れる場合のRFP記載のポイント

Shopify、特に中堅以上のEC事業者が活用するShopify Plusを視野に入れる場合、RFPに次のような項目を盛り込んでおくと、認定パートナーから精度の高い提案を引き出しやすくなります。

11-1. プラットフォームを指定するか・選定をベンダーに委ねるか

ShopifyをRFPで指定する場合は「Shopify認定パートナー、もしくはShopify Plusパートナーの認定を保有する企業からの提案をお願いします」と明記し、その採用前提を共有します。

ベンダー提案に委ねる場合は「プラットフォームの指定はありません。本プロジェクトの要件に最も適したプラットフォームを、推奨理由・主要候補（2〜3案）との比較・適合度・5年間のTCO比較をセットで提案してください」と書きます。

ベンダー提案型のRFPでも、社内で想定しているプラットフォームの候補（Shopify Plus、ecbeing、futureshop、Magento等）を「検討対象として候補に挙げているプラットフォーム」として一覧で開示すると、ベンダーは比較対象を絞った提案を作りやすくなります。

11-2. Shopify Plus特有の要件記載

Shopify PlusでEC構築を進める場合、RFPに盛り込むと精度が上がる項目があります。

• Shopify Functions/Shopify Flow活用範囲：標準アプリで足りない業務ロジックをどこまで実装したいか

• チェックアウトのカスタマイズ範囲：Checkout Extensibilityでどこまでカスタマイズする想定か

• B2B機能の活用：Shopify PlusのB2B機能（カタログ・支払い条件等）を使う想定か

• 多通貨・多言語：Shopify Markets活用の想定範囲

• ヘッドレス構成：Storefront API・Hydrogen等の活用前提か

• アプリ・連携：Shopifyアプリストアからの選定方針、独自アプリ開発の必要性

これらは認定パートナーの提案力を引き出すための切り口になります。
標準対応できる部分と、追加開発・アプリ導入が必要な部分の切り分けが、提案書のクオリティに直結します。

11-3. Shopify Plusのライセンス・利用料の扱い

Shopify Plusの利用料は、月額利用料・GMV連動の料率・追加サービス費用の組み合わせで構成されます。
詳細な金額は商談ベースで決まるため、RFP段階では「ライセンス費用は別途お問い合わせください」と明記し、概算費用の中で「Shopify Plusライセンス（推定）」として枠を取る形が実務的です。

ベンダー側の開発・実装費用と、Shopify本体のライセンス料は別計上で見積もりしてもらうと、TCOの比較がしやすくなります。

11-4. Shopify構築の体制特性

Shopifyの認定パートナーは、フルスクラッチや大規模パッケージ構築と比べて、少人数・短期間で動けるチームが多い傾向があります。

RFPでは、主要メンバー（PM、テックリード）の継続稼働保証、並行プロジェクトの状況とアサイン優先度、想定外のスコープ拡張への増員対応、リリース後の運用保守体制（一次対応窓口、改善サイクル）を確認しておくと、長期パートナーシップの判断材料になります。

12. EC RFPでよくある落とし穴と回避策

12-1. 目的・KPIが曖昧で「DXを推進したい」だけになる

目的セクションが「DX推進」「業務効率化」「売上拡大」だけで終わるケースです。抽象的な目的だけでは、ベンダーは具体的な打ち手を提案できません。「売上を○億円増やしたい」「CVRを△%改善したい」「リリースサイクルを月次にしたい」というように、定量的なKPIまで落とし込みます。

KPIが社内で固まっていない場合は、RFP作成と並行してKPI整備を進めるか、いったんRFI（情報提供依頼書）でベンダーから「業界平均のKPI」を情報収集してからRFP本番に進む選択肢もあります。

12-2. スコープが曖昧で「フルスクラッチで全部やる」前提になる

「ECサイトを作る」とだけ書いてあるRFPは、ベンダーから「フルスクラッチで全部含む」前提の見積もりが返ってきます。
回避策は、5章で示したように「対象範囲」「対象外」を明示的に区切ることです。とくにアプリ開発、越境EC、店舗POS連携、広告運用、カスタマーサポートの5領域は、「今回はスコープ外」と明記しないと自動的に含まれがちです。

12-3. 機能要件の優先度がなく、すべてMust扱いになる

機能要件の一覧を作ったものの優先度を付けないと、ベンダー側は「すべて実装する前提」で見積もりを作ります。
回避策は、MoSCoW法（Must/Should/Could/Won’t）で優先度をきちんと付けることです。

最初は粗くてもよいので、「Mustは20項目、Shouldは30項目、Couldは20項目」のように分量バランスで仮置きし、それを叩き台にして社内で議論を回します。

12-4. 予算非開示で各社が手探りで見積もる

予算を完全に隠したRFPに対して、各社は「自社が取りやすい価格」で見積もりを作ります。

結果として、提示額のレンジが3倍以上ブレるケースもあります。
回避策は、レンジで予算を開示することです。「初期費用2,000万円〜3,000万円、月額運用50万円〜80万円」というように、上下幅をつけて開示すれば、ベンダーはそのレンジ内で提案を最適化します。

12-5. 評価基準が後出しで、選定が恣意的に映る

RFPに評価基準を載せず、提案受領後に「総合的に判断する」とだけ伝えるケースがあります。

このRFPは、選定後に「なぜこのベンダーを選んだのか」を社内・社外に説明しづらく、コンプライアンスリスクにもつながります。回避策は、評価軸と配点をRFP内で明示することです。

12-6. スケジュールがタイトすぎてベンダーが辞退する

「RFP発行から提案書提出まで2週間」のような短期スケジュールを設定すると、有力ベンダーは「真剣に取り組めない」と辞退する可能性があります。

EC構築のRFPに対して質の高い提案を作るには、ベンダー側で社内ヒアリング・技術検討・体制調整・見積もり作成の工数がかかります。標準的には4〜6週間の提案準備期間を確保するのが、提案の質を保つ条件です。

12-7. RFPの社内合意なしに発行してしまう

RFPを社内合意なしに発行すると、選定後の契約段階で「経営層がOKを出さない」「予算が承認されない」というケースが起きます。
RFP発行前に、事業部・情シス・経営層・購買部・法務の合意を取り、特に予算・スコープ・スケジュールについては書面で承認を得ておきます。

まとめ

EC RFPは、ベンダー選定の出発点となる重要なドキュメントです。
書き方が甘いと、提案の質も比較のしやすさも落ち、選定後の手戻りが頻発します。

逆に、目的・スコープ・要件・予算・スケジュール・評価基準が整理されたRFPは、ベンダーから精度の高い提案を引き出し、選定プロセス全体を加速させます。

EC RFP作成成功の7つのポイント

1. 要件定義書・仕様書との違いを意識する：詳細な機能要件は要件定義フェーズに譲り、RFPでは提案を組み立てるための最小限の情報を整理する

2. 目的・KPIを定量で示す：売上・CVR・リリースサイクル等の定量目標まで落とし込む

3. スコープを「対象範囲」と「対象外」で明示する：アプリ開発・越境EC・POS連携・広告運用・CSの5領域は、スコープ外を明示しないと自動的に見積もりに含まれがち

4. 機能要件にMoSCoW法で優先度を付ける：Must/Should/Could/Won’tの分類で、ベンダーが提案の幅を出し分けられるようにする

5. 予算をレンジで開示する：社内で合意したレンジを公開し、ベンダーの提案を最適化させる

6. 評価軸と配点をRFPに記載する：評価の透明性は、ベンダー側の提案クオリティと選定の説明責任を両立させる

7. 提案期間は4〜6週間を確保する：タイトすぎるスケジュールは有力ベンダーの辞退を招く

最初の一歩を踏み出そう

「完璧なRFPを作ろう」と気負うと、社内調整に半年かかり、プロジェクト全体が遅延します。

最初は、本記事の13章構成をベースに、社内の現状把握と目的整理から取り組むことが現実的です。

30〜50ページのドラフトを2週間で書き起こし、社内レビューと業務側ヒアリングで2週間かけて磨き込み、合計4〜6週間でRFP発行まで持っていく進め方が、多くのプロジェクトで採られています。

RFPは「正解を書き切る」ものではなく、「ベンダーから良い提案を引き出すための投げかけ」と捉えると、肩の力を抜いて書き始められます。
完璧を目指すより、まず叩き台を発行し、提案とフィードバックの往復で精度を上げていく姿勢が、EC構築プロジェクトを前に進めます。

---

【無料相談】貴社のEC RFP作成・ベンダー選定をトータルでご支援します Shopifyの専門家が、貴社の事業規模・要件・選定状況に合わせて、RFP作成のたたき台、Shopify構築を視野に入れた要件整理、ベンダー送付先の選定、提案評価のフレームまで、無料でご相談に対応します。社内のRFPテンプレート整備、ベンダー送付前のレビュー、回収後の選定支援、どの段階からでもご相談いただけます。
 [無料で相談する]　[資料をダウンロード]

---

参考文献

1. IPA（情報処理推進機構）『情報システム・モデル取引・契約書（第二版）』2020年

2. IPA（情報処理推進機構）『非機能要求グレード』2018年改訂版

3. 経済産業省『令和5年度 電子商取引に関する市場調査』2024年

4. Google『The Need for Mobile Speed』2018年