EC-CUBE開発の開発期間・スケジュール・納期について

EC-CUBE開発の期間は、規模・独自開発・外部連携の範囲で決まり、1〜2か月から4〜8か月(要件により半年〜1年以上)かかります。

発注先選びや社内の計画、落とし穴を避けた納期設定には、工程ごとの期間配分と納期を左右する要因が役立ちます。全体像は完全ガイドで確認できます。

▼全体ガイドの記事
・EC-CUBE開発の完全ガイド

EC-CUBE開発の開発期間の全体像

EC-CUBE開発の小規模・中規模・大規模について、期間と費用の目安を3枚のカードで示した図。
規模が上がるにつれて、期間と費用の目安も大きくなります。

EC-CUBEの期間は、選ぶバージョン、カスタマイズ、プラグイン開発、外部連携の範囲によって変わります。まずは規模別の目安をつかんでおくことが、計画の出発点になります。

EC-CUBEというパッケージの特性と開発期間の関係

開発期間を見積もるときは、EC-CUBEの技術構成と拡張の自由度を押さえておく必要があります。

  • 技術基盤:PHP製の国産オープンソースで、2系は独自フレームワークと旧PHP系列に依存しています。3系を経て、4系はSymfonyを基盤としています。
  • 構築方式:フルスクラッチと設定だけのSaaSの中間に位置し、カート・会員・受注管理・管理画面の土台を備えています。
  • カスタマイズ:ライセンス費用がかからず、ソースコードを自由に改変できます。SaaS型カートや商用パッケージとは、この点が異なります。
  • 標準機能の活用:既存の機能や公式プラグインで要件を満たせれば、土台を使って短期間・低コストで立ち上げられます。
  • 独自要件への対応:テーマやプラグインの設計・実装・テストが必要で、期間は改修の密度にほぼ比例します。

規模・カスタマイズ度合い別の開発期間と費用

期間と費用は構築規模によって変わるため、早い段階で自社がどの規模に当たるかを見極めておくと、現実的な計画を立てやすくなります。

  • 小規模:デフォルトテーマを中心に構築し、1〜2か月・10万〜100万円程度です。
  • 中規模:独自デザインや機能開発を行い、2〜5か月・100万〜500万円程度です。オープンソースの相場として、200万円以上を見込むケースもあります。
  • 大規模:基幹連携や数万SKUの移行を伴い、4〜8か月・500万〜1,000万円以上です。

小規模ではロゴ、カラー、トップ画像を替え、決済と配送を基本設定します。必要に応じて、無償・軽量のプラグインを導入します。

中規模ではブランドに合わせたUIを設計したうえで、オーナーズストアのプラグインや独自ポイント、定期購入、販促機能などを開発します。

大規模はフルオーダーに近く、ERPや在庫・物流システムとAPIでリアルタイム連携します。また、複雑な業務フローにも対応します。

小規模は設定が中心で、商品写真や原稿は発注側が用意する前提です。一方、大規模は要件によって半年〜1年以上かかることもあります。

ここに示した金額と期間は、EC-CUBEに限らずオープンソースやECパッケージ全般の相場を基にした目安です。正確な数値は要件定義後に算出します。

標準機能を超える要件では、テーマ・プラグイン開発やコア拡張の工数が発生し、期間と費用が大きく増えます。そのため、標準機能・既存プラグインで賄える範囲と独自開発の範囲は、早い段階で分けておくことが見積もりとスケジュール作成で重要です。

ポイント

期間は規模で大きく変わるため、まず自社がどの規模に当たるかを決めることが出発点です。見積もりを比べる際も、規模をそろえてから金額や期間を見るとずれにくくなります。

工程別スケジュールと期間配分

EC-CUBE構築の企画・要件定義、設計・実装・開発、テスト・リリースの順序と、全体に占める期間配分を示した図。
設計・実装・開発に最も大きな配分が置かれています。

スケジュールは、企画・要件定義に20〜30%、設計・実装・開発に40〜50%、テスト・リリースに20%を配分するのが目安です。コンテンツ準備とデータ移行は、この流れと並行して進めます。

SaaSと異なりEC-CUBEはカスタマイズを前提とするため、工程を丁寧に管理できるかどうかが納期を左右します。各フェーズで確認すべき点を押さえておきます。

企画・要件定義フェーズ(全体の約20〜30%)

企画・要件定義は、EC構築で最も重要で、かつ失敗しやすい工程です。要件定義は1〜3か月が目安です。ただし、中〜大規模で基幹連携などがある場合は、この工程だけで2〜3か月以上かかることもあります。要件定義では、必要な機能と品質の条件、実装する範囲を明確にします。

  1. 決済方法や配送ルール、会員機能、受注管理フローといった機能要件を洗い出し、可用性・表示速度・セキュリティ・PCI DSS等も確認します。
  2. 標準機能と公式プラグインで対応する範囲と、独自開発する範囲を分けます。

プラグインで実現できる機能を独自開発すると、工数が無駄になります。また、標準では難しい要件を設定で済ませようとすると、後工程で手戻りが生じます。

要件定義書とプラグイン・カスタマイズの一覧を成果物として残しておくと、後の工程での手戻りを防ぎやすくなります。

設計・実装・開発フェーズ(全体の約40〜50%)

設計・実装は規模によって1〜4か月が目安です。作業は、テーマ開発、プラグイン・カスタマイズ開発、外部システム連携開発に分かれます。

  • テーマ開発:EC-CUBE上にフロント画面を組み立てます。
  • 機能開発:プラグインやSymfonyのEventDispatcher(フック)、DI(依存性注入)で機能を拡張します。
  • 外部連携:基幹・在庫・会計などのシステムとAPIまたはCSVでつなぎます。

ワイヤーフレームをもとにTwigテンプレートを上書きし、トップ、商品一覧・詳細、カート、会員ページなどを作ります。

コアファイルを直接変更すると、セキュリティパッチや更新で変更が上書きされ、競合の解消に手戻りが起きます。その結果、更新できない脆弱なシステムになるため、コアを改変しない設計が重要です。

これらの作業量は開発期間に反映されます。特に、実装期間の見積もりは要件定義の精度に大きく左右されます。

コンテンツ準備・テスト・リリースフェーズ(全体の約20%)

テスト・リリースは2週間〜1か月が目安です。単体テストに加え、決済処理・在庫減算・注文確認メール・会員登録の結合テストを行います。テストは実運用を想定し、公開前には商品データや環境設定も確認します。

  • 商品データの準備:必要な商品情報を揃えます。
  • テスト:単体と結合の両面で、動作を確かめます。
  • 公開前の確認:リハーサルと環境設定を確認します。

プラグイン同士や、カスタマイズとコアの整合性も確かめます。特に決済は、サンドボックスで代行サービスとの連携やエラー時の挙動を検証します。

商品マスタのCSVと画像、説明文などを用意し、カテゴリや送料ルールも揃えます。なお、既存サイトからのデータ移行を外注する場合は、1点につき500〜2,000円程度かかることもあります。

実データに近い商品でリハーサルを行い、SSL証明書と、旧サイトがある場合のリダイレクト設定を確認します。データは着手前から並行して揃えておきます。

ポイント

工程ごとの配分は目安として使い、要件定義の精度によって後の工程の見積もりが大きく変わる点に注意が必要です。

EC-CUBE特有の開発期間を左右する変数

EC-CUBEの開発期間を左右するバージョン選定と移行、プラグイン活用、基幹・外部システム連携の3項目を示した図。
見積もりでは、構築や移行の前提と連携範囲をそろえて確認します。

EC-CUBEの期間は、SaaSやフルスクラッチとは異なる固有の要因で変わります。バージョン、プラグイン、設計の違いによって、倍以上の差が出ることもあります。

納期の見積もりで特に確かめたいのは、バージョン、プラグインの活用、外部連携の3点です。

バージョン選定(2系・4系・Symfony基盤)

新規構築か、既存2系からの移行かによって、選ぶバージョンと必要な作業が変わります。

  • 新規構築:Symfony基盤で最新PHPに対応する4系が主流です。保守性、拡張性、セキュリティの面で有利です。
  • 既存2系:独自フレームワークで、古いPHP系列に依存しています。サポート終了済みの版も多く、新規に選ぶ理由は基本的にありません。
  • 2系から4系への移行:作り直しに近い工数が必要になります。

両系はアーキテクチャが異なるため、テーマやプラグイン、カスタマイズのコードはそのまま流用できません。移行では、データ移行に加えて、機能の再設計と再実装も必要になります。

そのため、移行では新規構築費の20〜50%程度が追加されるケースもあります。見積もりでは、新規構築か移行かという前提を先に明確にしておく必要があります。

プラグイン活用とコア改変回避設計

プラグインの活用度と拡張設計は、開発期間を左右する2つ目の要因です。

オーナーズストアには、決済・配送・SEO・帳票・会計連携・販促などの有償・無償プラグインがあります。要件に合うものを導入・設定できれば、独自開発より期間を短縮できます。

合うプラグインがなければ、独自プラグインやカスタマイズが必要になり、工数が増えます。そこで、開発と保守の両方を見据え、コアを改変せず拡張ポイントを使います。

  • 処理の拡張:EventDispatcher(フック)でコア処理の前後に独自ロジックを加えます。
  • クラスの拡張:DIコンテナの設定を上書きし、自作の継承クラスを注入します。
  • 画面の拡張:テンプレートのオーバーライドで独自画面を読み込みます。

拡張ポイントを使うと、初期設計の工数は多少増えます。一方で、更新時の工数を下げ、システムの寿命を延ばせます。

逆に、コアを直接変更すると、目先の納期は守れても、次の更新で破綻し、開発・保守期間が長くなるおそれがあります。

基幹・外部システム連携の有無と複雑さ

外部連携の有無と複雑さ、連携対象や仕様調整の範囲は、期間を左右する3つ目の要因です。

  1. ERP・在庫管理・物流(WMS)・会計・受注管理など、連携先を確認します。単体運用より期間を見積もりにくく、連携は開発期間を左右する大きな要因です。
  2. 受注送信や在庫同期、商品取り込みには、連携の設計と例外処理が必要になります。
  3. 連携先とデータ仕様を、事前にすり合わせておきます。

受注送信や在庫の双方向同期、商品マスタの取り込みには、API設計とデータの対応付けが必要です。さらに、例外処理と再送制御も欠かせず、要件によっては実装フェーズの過半を占めることもあります。

データの文字コードや桁数、必須項目が異なると、テスト時のエラーや調整が増えます。税込・税抜の扱いが違う場合も、同じ問題が起きやすくなります。そのため、データの粒度と形式を確認し、事前調整と連携テストの期間を計画に含めます。

ポイント

期間を左右する要因は、バージョン、プラグインの活用、外部連携の3つです。見積もりを依頼する前に、新規構築か移行か、既存機能で賄えるかを整理しておくことが大切です。

納期を短縮する具体的な方法

納期を縮めるには、作らずに済むものは作らず、優先度の高い機能から出していく方法が有効です。

デフォルトテーマと既存プラグインの最大活用

初期公開ではデフォルトテーマを使い、変更を必要最小限に留める方法があります。ブランドらしい表現は、公開後に段階的に作り込めます。

決済・配送・SEO・帳票・レビューなどは、公式プラグインで対応できるかを先に確認します。そのため、要件定義の段階でプラグイン対応と独自開発を分けておくと、独自開発を減らせます。

一方で、有償プラグインにはライセンス費用や継続費用が発生します。そこで、開発費の削減効果とランニングコストを比べて判断します。

スモールスタート(段階的リリース)による期間短縮

全機能を一度にリリースすると期間が延び、その間に市場や要件が変わるリスクも高まります。そこで、MVP(Minimum Viable Product)に絞った早期公開が選択肢になります。

公開後は運用データや利用者の反応を見ながら、定期購入・ポイント連携・レコメンド・多言語対応を段階的に追加します。EC-CUBEはプラグインで機能を後から追加しやすい構造のため、こうした進め方に向いています。

第1フェーズで販売できる状態を作り、第2フェーズ以降で機能を広げていけば、初期の開発期間と投資を抑えながら事業を進められます。

ポイント

納期を縮める方法は、独自開発を減らすことと、初期公開の範囲を絞ることの2つが基本です。ただし、有償プラグインのランニングコストも含めて判断します。

納期遅延の典型要因と対策

遅延の典型的な要因を把握し、先に対策を決めておけば、リスクを下げられます。

要件の曖昧さとスコープクリープ

要件の曖昧さが原因で起きるスコープクリープ(途中での仕様追加・変更)は、遅延の主な要因です。「とりあえずこんな感じで」と発注し、決済や送料などを後から変えると、工数が当初の倍以上に膨らむことがあります。

  1. 開始前に、必要最低限の機能要件を決めておきます。
  2. 変更の要求が出たら、影響範囲を調べ、工数・費用・納期を見積もったうえで、承認後に実施します。
  3. 変更管理の手順を書面にまとめ、口頭での追加による予算・納期の超過を防ぎます。
  4. 初期機能を優先度の高いものに絞り、スモールスタートで遅延を抑えます。

プラグイン競合・脆弱性対応・連携トラブル・データ準備遅れ

遅延につながる要因は、開発前の確認や監視によって備えられます。

  • プラグイン競合:互換性や予期しない副作用で、調整が必要になる場合があります。導入前に精査し、機能を詰め込みすぎないようにします。
  • 更新・脆弱性:環境の更新や脆弱性への対応で、予期せぬ工数がかさむことがあります。
  • 連携形式の不一致:開発前に連携先とデータ形式をすり合わせておけば、食い違いを防げます。
  • データ準備の遅れ:商品マスタのCSVや画像、送料ルールは、着手前から揃えておきます。

OS・PHP・Symfony・ライブラリの更新に備えて、ComposerのDependabotやcomposer auditを使い、早期に検知します。保守費用が見積もりに含まれているかも確認します。

不測の事態に備えて、プロジェクト全体の予備としてスケジュールの10%程度のバッファを確保しておくと、納期を守りやすくなります。

ポイント

遅延の多くは、要件の曖昧さによる仕様変更と、プラグイン・連携・データ準備の遅れから起きます。変更は影響範囲と納期を示して承認を得てから進め、データは着手前に揃えます。

まとめ

EC-CUBEの開発期間は、小規模で1〜2か月、中規模で2〜5か月、大規模で4〜8か月が目安です。大規模案件は半年〜1年以上になることもあります。

計画では、要件定義を20〜30%、設計・実装を40〜50%、テストを20%の目安で配分します。期間を左右するのは、バージョンとプラグインの活用、コアを改変しない設計、基幹連携です。

デフォルトテーマや既存プラグインの活用、段階的なリリースは、納期短縮に役立ちます。また、計画には要件変更の管理、データ準備、連携確認を含め、10%程度のバッファも確保しておきましょう。

まずは要件を、標準機能やプラグインで賄う部分と独自開発が必要な部分に分けます。そのうえで、EC-CUBEの構築実績が豊富な複数社に概要を示し、見積もりを依頼します。

▼全体ガイドの記事
・EC-CUBE開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。