EC-CUBEの構築では、自社の要件をゼロから言語化してベンダーに伝える必要があるため、要件定義とRFP（提案依頼書）の作り込みが、プロジェクトの成否を左右します。
進め方は、目的とKGIの設定から要件を固め、RFPを作って見積もりとベンダーを比べる流れです。全体像がまだ掴めていない方は、EC-CUBE開発の完全ガイドからご覧ください。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC-CUBE要件定義の進め方ステップ
EC-CUBEの要件定義は、いきなり「欲しい機能」を並べ始めると失敗しやすくなります。EC-CUBEは自由に作れる分、目的から逆算しないと「あれもこれも」と機能が膨らみ、見積もりが青天井になりがちだからです。そのため、まず事業の目的とKGI（重要目標達成指標）を定め、それを達成するための業務フローを描き、そこから機能要件と非機能要件を導く順で進めます。
目的・KGI設定と業務フローの可視化
最初のステップは、このECで何を達成したいのかを数値目標まで落とし込むことです。その目的が定まると、優先すべき機能の順位が自ずと決まります。
次に、現状（AsIs）と、システム導入後に目指す姿（ToBe）の業務フローを描きます。ここで現場へのヒアリングを省くと、現場の実態に合わないシステムができあがります。
実際、現場ヒアリングとToBeモデルの作成を怠ってベンダーへ丸投げした結果、1億円かけたBtoBサイトが現場に使われず2年で廃止された事例も報告されています。EC-CUBEは要件次第で何でも作れるからこそ、「誰がどう使うか」を現場目線で固めることが、要件定義の出発点になります。
数値目標は、新規売上や受発注業務の効率化の度合いをKGIとして定め、達成時期まで決めておきます。
- KGI：新規売上の目標と、受発注業務の効率化の度合い
- 達成時期：いつまでに達成するかの期限
BtoBの受発注効率化が目的なら、見栄えより得意先別価格や承認フローの機能が優先される、といった判断が可能になります。
標準・プラグイン・カスタマイズの切り分け
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以上に高まります。
表示速度やセキュリティ、可用性は、普段は見えませんが、トラブル時に事業を直撃します。
とくにセキュリティとバージョンアップへの追従は、EC-CUBE構築で最も軽視されやすく、かつ最も重大な非機能要件です。たとえば、サポート終了（EOL）したバージョンを放置すると脆弱性を突かれ、情報漏えいといった重大事故につながります。
要件定義の段階で、「誰がバージョンアップを担うのか」「セキュリティパッチの適用体制はどうするのか」を取り決めておくことが欠かせません。さらに、セキュリティの考え方は公的なガイドラインに準拠すると明記しておけば、ベンダーとの認識も揃いやすくなります。これらを怠った場合の失敗については、後述の関連記事でも触れています。
非機能要件は、次の観点で具体的な水準を決めておきます。
- 速度・可用性：表示速度と、アクセス集中時に耐えられる範囲
- 保守・バージョンアップ：担当の線引きと、セキュリティパッチの適用体制
表示速度はページ表示やカートの応答性、セキュリティは脆弱性対策・SSL・個人情報やクレジットカード情報の保護が対象です。可用性の対象には、障害時の復旧体制も含まれます。
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作成、契約面のリスク対策までを上流から支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。