EC-CUBEで構築を進めるとき、プロジェクトの成否を最初に左右するのが「要件定義」と、その前提となるRFP（提案依頼書）の作り込みです。EC-CUBEはオープンソースゆえに「何でも作れる」自由度がありますが、それは裏を返せば「何を作るかを発注側が明確に決めなければ、作るものが定まらない」ということでもあります。ASPやSaaSのように提供された機能から選ぶのではなく、自社の要件をゼロから言語化してベンダーに伝える必要があるため、要件定義とRFPの質が、見積もりの妥当性も、完成後の満足度も決めてしまいます。
本記事は、EC-CUBE構築におけるRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から解説する「要件定義特化」の内容です。要件定義の進め方のステップ、機能要件と非機能要件の整理、RFPに盛り込むべき項目、そして見積もりの妥当性を判断しベンダーを選ぶ視点まで、一次データと失敗事例の教訓を交えて具体的に解説します。読み終えるころには、EC-CUBEの自由度を「コスト爆発」ではなく「自社最適」に変えるための、発注準備の全体像が描けるはずです。なお、EC-CUBE開発の全体像をまだ把握していない方は、まずEC-CUBE開発の完全ガイドから読むことをおすすめします。
EC-CUBE要件定義の進め方ステップ
EC-CUBEの要件定義は、いきなり「欲しい機能」を並べるところから始めると失敗します。正しい順序は、まず事業の目的とKGI（重要目標達成指標）を定め、それを達成するために必要な業務フローを描き、そこから機能要件と非機能要件を導く、という流れです。EC-CUBEは自由に作れる分、目的から逆算しないと「あれもこれも」と機能が膨らみ、見積もりが青天井になりがちだからです。
目的・KGI設定と業務フローの可視化
最初のステップは、「このECで何を達成したいのか」を数値目標まで落とし込むことです。新規売上をいくら作るのか、既存の受発注業務をどれだけ効率化するのか、いつまでに達成するのか。この目的が定まると、優先すべき機能の順位が自ずと決まります。たとえばBtoBの受発注効率化が目的なら、見栄えより得意先別価格や承認フローの機能が優先される、といった判断が可能になります。
次に、現状（AsIs）の業務フローと、システム導入後に目指す姿（ToBe）の業務フローを可視化します。ここで現場へのヒアリングを省略すると、現場の実態に合わないシステムができあがります。実際、現場ヒアリングとToBeモデルの作成を怠ってベンダーへ丸投げした結果、1億円かけたBtoBサイトが現場に使われず2年で廃止された事例も報告されています。EC-CUBEは要件次第で何でも作れるからこそ、「誰がどう使うか」を現場目線で固めることが、要件定義の出発点になります。
標準・プラグイン・カスタマイズの切り分け
EC-CUBE特有の要件定義作業が、洗い出した機能要件を「標準で対応」「プラグインで対応」「カスタマイズが必要」「不要」の4つに振り分けることです。この切り分けが費用を大きく左右します。標準やプラグインで賄える機能をわざわざカスタマイズで作ると過剰投資になり、逆に標準では実現できない独自要件を見落とすと、後から「できません」と判明して手戻りが発生します。
この振り分けには、EC-CUBEの標準機能とプラグインで何ができるかの理解が欠かせません。商品・カート・受注・会員といった基本機能は標準で、決済や定期購入、SEO拡張などはプラグインで、得意先別価格や独自会員施策などの差別化要素はカスタマイズで、というのが一般的な目安です。発注側が自社でこの一次振り分けをしておくと、RFPで要望が明確になり、ベンダーごとの見積もり比較がしやすくなります。EC-CUBEの標準機能とプラグインの全体像は、機能を主題にした関連記事で詳しく整理しています。
機能要件と非機能要件の整理
要件定義書は大きく「機能要件」と「非機能要件」に分かれます。機能要件は「何ができるか」、非機能要件は「どれだけ速く・安全に・止まらず動くか」を定めるものです。EC-CUBEのようなオープンソースでは、非機能要件を発注側が意識しないと、サーバー構成やセキュリティ対策が後回しになり、公開後に重大なトラブルを招きます。両者をバランスよく記述することが、堅牢なECを作る土台になります。
機能要件の洗い出しと優先度付け
機能要件は、フロント（購入者が使う機能）とバックオフィス（運営者が使う機能）、そして外部連携（ERP・在庫・物流など）に分けて洗い出します。それぞれの項目に「必須・あると良い・将来」という優先度を付けることが重要です。EC-CUBEは何でも作れるため、優先度を付けずに要望を並べると、すべてが必須に見えて見積もりが膨張します。優先度を付けておけば、予算に応じてフェーズ分けで段階的に実装する判断ができます。
とくにBtoBや定期購入・D2Cなどビジネスモデル固有の要件は、漏れなく機能要件に落とし込む必要があります。BtoBなら得意先別価格・掛売り・承認フロー・ERP連携、定期購入ならフォーム一体型LP・ステップメール自動化・LTV分析といった固有機能は、標準では賄えずカスタマイズかプラグインが必要です。これらは商習慣そのものを要件化する作業であり、現場の運用ルールを正確にシステム仕様へ翻訳できるかが成否を分けます。BtoB向けに同規模BtoCより30〜100%費用が増えるのも、こうした固有要件が背景にあります。
非機能要件（速度・セキュリティ・可用性）
EC-CUBEはオープンソースで自社サーバー（またはレンタル・クラウド）に設置するため、非機能要件の重要度がASP以上に高まります。表示速度（ページ表示やカートの応答性）、セキュリティ（脆弱性対策・SSL・個人情報やクレジットカード情報の保護）、可用性（セール時のアクセス集中に耐えるか、障害時の復旧体制）といった項目を、要件定義書に具体的な水準で記述する必要があります。これらは普段は見えませんが、トラブル時に事業を直撃します。
とくにセキュリティとバージョンアップ追従は、EC-CUBE構築で最も軽視されやすく、かつ最も重大な非機能要件です。サポート終了（EOL）したバージョンを放置すると脆弱性を突かれ、情報漏えいといった重大事故につながります。要件定義の段階で「誰がバージョンアップを担うのか」「セキュリティパッチの適用体制はどうするのか」を取り決めておくことが欠かせません。あわせて、セキュリティの考え方は公的なガイドラインに準拠する方針を明記しておくと、ベンダー側との認識も揃いやすくなります。これらを怠った失敗の詳細は、後述の関連記事でも触れています。
RFP（提案依頼書）に盛り込む項目
RFP（提案依頼書）は、要件定義で整理した内容をベンダーに提示し、提案と見積もりを求めるための文書です。RFPの精度が高いほど、各ベンダーから比較可能な提案が集まり、見積もりのブラックボックス化を防げます。逆にRFPが曖昧だと、ベンダーごとに前提がバラバラの見積もりが返ってきて、横並び比較ができなくなります。EC-CUBEは作り込みの幅が広いだけに、RFPで前提を揃えることがとくに重要です。
RFPに必須の記載項目
EC-CUBE構築のRFPに盛り込むべき主な項目は次のとおりです。
・プロジェクトの背景と目的、KGI・KPI
・対象範囲（EC-CUBEのバージョン、対応デバイス、対象ビジネスモデル）
・機能要件（標準・プラグイン・カスタマイズの切り分けと優先度）
・非機能要件（速度・セキュリティ・可用性、サーバー構成、保守・バージョンアップの責任分界）
・外部連携要件（ERP・在庫・物流・決済の連携先と方式）
・予算とスケジュール、納品物（ソースコード・設計書・テスト・運用マニュアル）
これらを揃えることで、各社の提案が比較可能になります。
とくに見落とされやすいのが「納品物」と「保守・バージョンアップの責任分界」です。EC-CUBEはオープンソースゆえに、ソースコードや設計ドキュメントの帰属、公開後の保守を誰がどこまで担うかを契約前に明確にしておかないと、後で別ベンダーへ引き継げない、保守費が想定外に膨らむといった揉め事になります。RFPの段階でこれらを質問項目として明記しておくことが、長期運用の安心につながります。
見積もりの妥当性判断とベンダー選定
RFPに対して集まった見積もりは、金額の安さだけで選んではいけません。同じ機能でもA社とB社で費用が倍違うことは珍しくなく、その差は「カスタマイズ範囲の前提」「人月単価」「テスト・デバッグやディレクションの計上方法」によって生まれます。見積もりが「一式」でまとめられている項目は要注意で、内訳を分解させ、ディレクション・PM進行管理費が見積総額の約10%程度に収まっているか、追加要件の単価ルールが明示されているかを確認しましょう。
ベンダー選定では、プレゼンの巧みさに惑わされないことも重要です。エース営業のプレゼンに騙されて発注した結果、実開発部隊の技術力が低くリリース後に障害が多発して泥沼化した事例も報告されています。これを避けるには、提案時に実際に開発を担当する体制図を要求し、担当PMとの面談を必須化することが有効です。riplaは、フルスクラッチ受託と国内開発の知見をもって、要件の言語化からRFP作成、見積もりの妥当性判断までを上流から伴走し、EC-CUBEの自由度を自社最適なコストに収める支援をしています。
まとめ
EC-CUBEの要件定義・RFPは、「目的・KGIの設定→業務フローの可視化→機能要件／非機能要件の洗い出し→標準・プラグイン・カスタマイズの切り分け→RFP作成→見積もりの妥当性判断とベンダー選定」という流れで進めるのが王道です。EC-CUBEは何でも作れる自由度がある分、この要件定義を発注側が主導しないと、見積もりがブラックボックス化し、コストも品質もコントロールできなくなります。現場ヒアリングを怠った1億円サイトの廃止事例が示すように、要件定義の質が投資の成否を直接決めます。
要件定義で大切なのは、「作りたい機能」ではなく「達成したい目的」から逆算することです。目的に直結する機能を優先し、非機能要件（とくにセキュリティとバージョンアップの責任分界）まで明記し、見積もりを内訳に分解して妥当性を判断する。この準備が、EC-CUBEの自由度を自社最適に変えます。riplaはフルスクラッチ受託と国内開発を組み合わせ、要件の言語化からRFP作成、契約面の防衛までを上流から支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。