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

EC-CUBEは、株式会社イーシーキューブ（旧ロックオン）が開発・提供する国産のオープンソースECパッケージで、PHPで書かれ、バージョン4系以降はSymfonyフレームワークを基盤としています。ソースコードが公開されており自由にカスタマイズできるため、SaaS型のASPカートでは実現できない独自の業務要件や、自社ブランドの世界観を反映したデザインを作り込めるのが最大の魅力です。一方で「ソースを自由にいじれる」ということは、裏を返せば設計・実装・テストといった開発工程を自分たちで（あるいは開発パートナーと）きちんと管理しなければならないということでもあります。だからこそ、EC-CUBEでECサイトの構築を検討する企業の担当者からは「EC-CUBEの開発期間はどのくらいかかるのか」「カスタマイズやプラグイン開発を含めると納期はどう変わるのか」「スケジュールが遅延する原因は何か」といった疑問が必ず挙がります。ShopifyやBASEのようなSaaSの感覚で計画を立ててしまうと、カスタマイズや基幹連携の工数を読み違え、リリースが大幅に遅れるケースが少なくありません。

本記事では、EC-CUBE開発の「開発期間・スケジュール・納期」に焦点を当て、デフォルトテーマ流用の小規模構築からプラグイン開発・基幹連携を伴う大規模構築までの規模別の期間目安、要件定義からリリースまでの工程配分、EC-CUBE特有の期間変数（バージョン選定・プラグイン活用・コア改変回避設計）、納期を短縮する具体的な手法、そして納期遅延の典型要因とその対策までを、具体的な数値とともに体系的に解説します。これから開発パートナーを選定する方はもちろん、社内でリリーススケジュールを策定する立場の方にとっても、現実的な計画を立てるための判断軸が身に付く内容です。最後までお読みいただくことで、EC-CUBEならではの落とし穴を避け、無理のない納期設定を行うためのポイントを押さえられるはずです。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

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

EC-CUBE開発の開発期間は、どのバージョンを選び、デフォルトの状態からどこまでカスタマイズやプラグイン開発を行うか、そして外部システムとの連携をどこまで作り込むかによって大きく変動します。まずは規模別の大まかな目安を把握しておくことが計画の出発点になります。デフォルトテーマを流用し、ロゴの差し替えや軽微なデザイン調整、既存プラグインの導入程度に留める小規模構築であれば、1〜2か月・10万〜100万円程度で立ち上げが可能です。自社ブランドの世界観を表現するオリジナルデザインを施し、オーナーズストアのプラグイン導入や独自機能のカスタマイズ開発を行う中規模構築では、2〜5か月・100万〜500万円程度（オープンソースの相場として200万円以上を見込むケースもあります）を要します。さらに、基幹システム（ERP）や在庫・物流システムとAPIでリアルタイム連携させたり、数万SKUのデータ移行を伴うフルオーダーに近い大規模構築では、4〜8か月（要件によっては半年〜1年以上）・500万〜1,000万円以上が一般的な相場感です。なお、ここで示した金額・期間はEC-CUBEに限らずオープンソースおよびECパッケージ全般の相場をベースにした目安であり、実際の数値は要件定義を経なければ正確には算出できません。

ここで特に意識しておきたいのは、EC-CUBEは「ゼロから作るフルスクラッチ」と「設定だけで完結するSaaS」の中間に位置する構築手法だという点です。すでに動くECシステムの土台（カート・会員・受注管理・管理画面など）が用意されているため、その範囲で済む要件であれば短期間・低コストで立ち上げられます。しかし、標準機能から外れる独自要件を実現しようとした瞬間に、テーマ開発・プラグイン開発・コアの拡張といったエンジニアリングの工数が発生し、期間とコストが一段跳ね上がります。つまりEC-CUBEの開発期間を見積もるうえで最も重要なのは、「自社の要件のうち、どこまでが標準機能・既存プラグインでカバーでき、どこからが独自開発になるのか」という線引きを早い段階で明確にすることです。本記事では、この線引きを踏まえた現実的なスケジュールの立て方を解説していきます。

開発期間を正しく見積もるためには、まずEC-CUBEというパッケージの技術的な特性を理解しておく必要があります。EC-CUBEはPHPで実装された国産のオープンソースECパッケージで、長く使われてきた2系（独自フレームワーク・旧PHP系列に依存）から、3系を経て、現在の主流である4系（Symfonyフレームワークを基盤に採用）へと進化してきました。オープンソースであるためライセンス費用がかからず、ソースコードを自由に改変できる点が、SaaS型カートやクローズドな商用パッケージとの決定的な違いです。この「自由にカスタマイズできる」特性は、開発期間に対して二面的に作用します。プラスの面は、標準機能や公式プラグインで要件を満たせる範囲なら、すでに完成した土台をそのまま使えるため立ち上げが速いこと。マイナスの面は、独自要件を実現するためにテーマ・プラグイン・拡張コードを設計・実装・テストする工程が発生し、その分だけ期間が伸びることです。したがって、EC-CUBEの開発スケジュールは「カスタマイズ密度」にほぼ比例して長くなると理解しておくと、規模感の把握がしやすくなります。

規模別にもう少し具体的に整理しておきましょう。小規模構築は、EC-CUBEのデフォルトテーマやテンプレートをほぼそのまま活用し、ロゴ・カラー・トップ画像といったデザイン要素の差し替えと、決済・配送などの基本設定、必要に応じた無償・軽量プラグインの導入で完結させるパターンです。開発というよりは「設定」が中心となるため、1〜2か月・10万〜100万円程度で立ち上げられ、商品写真や原稿などのコンテンツは発注側で用意することが前提になります。中規模構築は、自社ブランドの世界観を表現するためにオリジナルデザインのUI設計を行い、EC-CUBEのプラグインを導入したり、標準にない機能（独自のポイント制度、定期購入、特定の販促ロジックなど）をカスタマイズ開発したりするパターンで、2〜5か月・100万〜500万円程度が目安です。大規模構築は、ERPや在庫・物流・会計といった基幹システムとAPI連携させ、数万SKUのデータ移行や複雑な業務フローへの対応を行うフルオーダーに近いパターンで、4〜8か月（半年〜1年以上になることもある）・500万〜1,000万円以上が相場です。自社がこの3つのどこに該当するのかを早い段階で見極めることが、現実的なスケジュールの第一歩になります。

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

EC-CUBE構築のスケジュールは、概ね「企画・要件定義（全体の20〜30%）」「設計・実装・開発（40〜50%）」「テスト・リリース（20%）」という配分で進みます。これに並行して「コンテンツ準備・データ移行」が走るのが一般的です。SaaSと違ってEC-CUBEはカスタマイズ前提のパッケージであるため、各工程をどれだけ丁寧に管理できるかが納期を守れるかどうかを左右します。ここでは各フェーズで押さえるべきポイントを解説します。

EC構築において最も重要かつ失敗しやすいのが、この企画・要件定義フェーズです。期間としては1〜3か月、中〜大規模で基幹連携などの複雑な要件がある場合はここだけで2〜3か月以上かかることもあります。このフェーズでまず行うべきは、機能要件（決済方法・配送ルール・会員機能・ポイント・販促・受注管理フローなど）と非機能要件（想定アクセス数に対する可用性、ページ表示速度、セキュリティ要件、PCI DSS等のコンプライアンス）の洗い出しです。EC-CUBE特有の論点として、ここで「どの機能を標準機能・公式プラグインで賄い、どの機能を独自にカスタマイズ開発するか」というスコープの線引きを必ず行います。オーナーズストアにあるプラグインで実現できる機能を独自開発しようとすると無駄な工数が発生しますし、逆に標準では到底実現できない要件を「設定でなんとかなるだろう」と楽観視すると、後工程で大幅な手戻りが生じます。要件定義書とプラグイン・カスタマイズ一覧を成果物として残しておくことが、以降のフェーズでの手戻りを防ぐ最大の予防策です。

要件が固まったら設計・実装フェーズに移ります。期間は規模により1〜4か月が目安です。EC-CUBEの実装は大きく「テーマ（デザインテンプレート）開発」「プラグイン・カスタマイズ開発」「外部システム連携開発」の3つに分かれます。テーマ開発では、ワイヤーフレームをもとにEC-CUBEのテンプレート（Twig）をオーバーライドし、トップページ・商品一覧・商品詳細・カート・会員ページなどのフロント画面を作り込みます。プラグイン・カスタマイズ開発では、標準にない機能をプラグインとして実装するか、SymfonyのEventDispatcher（フック）やDI（依存性注入）を使ってコアの振る舞いを拡張します。ここで決定的に重要なのが、コアファイルを直接書き換えない設計を徹底することです。コアを直接改変すると、後のセキュリティパッチやバージョンアップの際に変更が上書きされたり、膨大なコンフリクト解消の手戻りが発生したりして、「アップデートできない脆弱なシステム」が完成してしまいます。外部システム連携開発では、基幹・在庫・会計などとのAPI連携やCSV連携を実装します。これら3つの作業量がそのまま開発期間に反映されるため、実装フェーズの見積もりは要件定義の精度に大きく依存します。

実装と並行して進めるのがコンテンツ準備・データ移行です。商品マスタのCSV、商品画像、説明文、カテゴリ、送料ルールなどを準備します。既存サイトからのデータ移行を外注する場合、1点につき500〜2,000円程度の費用がかかることもあります。テスト・リリースフェーズの期間は2週間〜1か月が目安で、ここでは仕様通りに動くかの単体テストに加えて、決済処理・在庫減算・注文確認メール通知・会員登録といった実運用を想定した結合テストを入念に行います。EC-CUBEでは導入したプラグイン同士の相互作用や、カスタマイズ部分とコアの整合性も確認すべきポイントです。特に決済は、テスト環境（サンドボックス）で決済代行サービスと正しく連携できるか、エラー時の挙動が適切かを必ず検証します。本番公開前には、実データに近い商品データを使ったリハーサル、SSL証明書の適用確認、リダイレクト設定（旧サイトがある場合）などのチェックリストを潰していきます。コンテンツ準備が遅れるとテストや公開ができないため、着手前から並行して進めて揃えておくことが、工期をブレさせない秘訣です。

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

EC-CUBEの開発期間は、SaaSやフルスクラッチとは異なる、このパッケージならではの変数によって大きく上下します。同じ「ECサイトを作る」という要件でも、バージョンの選び方、プラグインの活用度合い、設計の作法によって期間が倍以上変わることも珍しくありません。ここでは、EC-CUBE開発の納期見積もりで特に注意すべき3つの変数を解説します。

新規構築でまず決めるべきはバージョンの選定です。現在の新規開発はSymfonyを基盤とする4系を選ぶのが主流で、最新のPHPに対応し、保守性・拡張性・セキュリティの面で有利です。一方、まだ稼働している既存サイトの中には、独自フレームワークで作られた2系が残っているケースがあります。2系は古いPHP系列に依存しており、すでにサポートが終了したバージョンも多く、新規でこれを選ぶ理由は基本的にありません。問題は「既存の2系サイトをリニューアルしたい」というケースで、この場合は4系への移行が実質的に「作り直し」に近い工数を伴います。2系と4系ではアーキテクチャが根本的に異なるため、テーマもプラグインもカスタマイズコードもそのままでは流用できず、データ移行に加えて、機能の再設計・再実装が必要になるからです。したがって、自社が「新規構築」なのか「2系からの移行」なのかによって、想定すべき期間とコストはまったく変わってきます。新規であれば前述の規模別目安が当てはまりますが、移行案件では新規構築費の20〜50%程度の追加費用が乗るケースもあるため、見積もりの前提を明確にしておく必要があります。

EC-CUBEの開発期間を左右する2つ目の変数が、プラグインの活用度合いと拡張設計の作法です。EC-CUBEには「オーナーズストア」というマーケットプレイスがあり、決済・配送・SEO・帳票・会計連携・販促など、多様な機能を有償・無償のプラグインとして導入できます。要件に合うプラグインが存在すれば、それを導入・設定するだけで済むため、独自開発に比べて期間を大幅に短縮できます。逆に、要件に合うプラグインがなければ、独自にプラグインを開発するか、カスタマイズで実装する必要があり、その分だけ工数が増えます。ここで開発期間と将来の保守期間の両方に効いてくるのが「コア改変を避け、拡張ポイントを使って実装する」という設計原則です。具体的には、SymfonyのEventDispatcher（フック）を使ってコア処理の前後に独自ロジックを割り込ませる、DIコンテナの設定を上書きして自作の継承クラスを注入する、テンプレートのオーバーライド機能で独自画面を読み込ませる、といった作法を徹底します。初期の設計工数は多少増えますが、これを守ることで後のバージョンアップ工数が劇的に下がり、システムの寿命を延ばせます。逆にコアを直接いじる「やっつけ実装」をすると、目先の納期は守れても、次のアップデートで破綻するため、結果的にトータルの開発・保守期間が長くなります。

3つ目の変数が、外部システム連携の有無と複雑さです。EC-CUBEを単体のECサイトとして運用するだけなら期間は読みやすいのですが、ERP・在庫管理・物流（WMS）・会計・受注管理などの基幹システムとデータ連携させる場合、ここが開発期間の最大の山場になります。受注データを基幹へ流す、在庫数を双方向で同期する、商品マスタを基幹からEC側へ取り込む、といった連携は、API設計・データマッピング・例外処理・再送制御などを丁寧に作り込む必要があり、要件次第では実装フェーズの過半を占めることもあります。さらに、連携先システムの仕様（文字コード、桁数、必須項目、税込・税抜の扱いなど）がEC-CUBE側と食い違っていると、連携テストでエラーが多発し、調整に想定外の時間を要します。これを避けるには、開発に入る前に連携データの粒度とフォーマットを連携先のベンダーと綿密にすり合わせておくことが不可欠です。基幹連携を伴う案件では、この擦り合わせと連携テストの期間をスケジュールに十分に織り込んでおくことが、納期遵守の前提条件になります。

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

EC-CUBE開発の納期を短縮するには、闇雲に開発スピードを上げるのではなく、「作らずに済むものは作らない」「優先度の高いものから出す」という考え方が有効です。ここでは現実的に効果の高い2つのアプローチを紹介します。

最も即効性のある納期短縮策は、EC-CUBEのデフォルトテーマと、オーナーズストアで提供されている既存プラグインを最大限に活用することです。デザインに強いこだわりがある場合でも、初期リリースではデフォルトテーマをベースに必要最小限のカスタマイズに留め、ブランド表現の作り込みは公開後に段階的に行うという判断が有効です。機能面でも、決済・配送・SEO・帳票・レビューといった一般的な機能は、まず公式プラグインで賄えないかを検討します。プラグインで実現できる機能をわざわざ独自開発するのは、期間とコストの両面で大きな無駄です。要件定義の段階で「この機能はオーナーズストアのプラグインで対応」「この機能だけは独自開発が必要」という仕分けを丁寧に行うことで、独自開発の量を最小化でき、結果として全体の開発期間を圧縮できます。なお、有償プラグインを使う場合はライセンス費用や継続費用が発生するため、開発費の削減効果とランニングコストのバランスを見て判断することが大切です。

もう一つの有効な手法が、スモールスタート（段階的リリース）です。最初からすべての機能を盛り込んで一括リリースしようとすると、開発期間が長期化し、その間に市場やビジネス要件が変化するリスクも高まります。そこで、優先度の高い必須機能（MVP＝Minimum Viable Product）に絞って早期に公開し、実際の運用データやユーザーのフィードバックを見ながら、定期購入・ポイント連携・レコメンド・多言語対応といった機能を後から段階的に追加していくアプローチを取ります。EC-CUBEはプラグインアーキテクチャによって機能を後から付け足しやすい構造になっているため、このスモールスタートとの相性が良いのが特長です。第1フェーズでまずECとして売れる状態を作り、収益を上げながら第2フェーズ以降で機能を拡張していけば、初期の開発期間と投資を抑えつつ、ビジネスのスピードを落とさずに済みます。「全部そろってから公開」ではなく「売れる最小構成で早く公開し、育てる」という発想が、結果的に納期遅延とコスト膨張の両方を防ぐ最大のポイントです。

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

EC-CUBE開発でスケジュールが遅延する原因にはいくつかの典型パターンがあります。あらかじめこれらを知っておき、対策を講じておくことで、遅延リスクを大幅に減らせます。ここでは代表的な遅延要因とその対策を整理します。

最も多い遅延要因が、要件の曖昧さに起因する「スコープクリープ（途中での仕様追加・変更）」です。「とりあえずこんな感じで」と曖昧なまま発注し、開発が進んでから決済方法や送料ルール、会員機能、販促ロジックなどを次々に変更・追加していくと、工数が当初の倍以上に膨れ上がり、大幅な納期遅延に直結します。対策の基本は、プロジェクト開始前に必要最低限の機能要件を明確に定めておくことです。そのうえで、開発開始後に仕様変更が発生した場合の「変更管理プロセス」をあらかじめ合意しておきます。具体的には、変更要求が出たら影響範囲を調査し、工数・費用・納期への影響を見積もり、承認を得てから実施するという流れを明文化し、口頭での「ちょっとした追加」が積み重なって予算と納期を超過する事態を防ぎます。前述のスモールスタートと組み合わせ、初期フェーズでは優先度の高い必須機能のみに絞ってリリースする方針を貫くことが、スコープクリープを抑える最も実効的な手段です。

オープンソースならではの遅延要因もあります。第一に、複数のプラグインを導入した際の互換性問題（競合）です。プラグイン同士が同じ拡張ポイントを取り合ったり、想定外の副作用を起こしたりして、調整に時間を要することがあります。対策は、導入するプラグインを事前に精査し、過剰な機能の詰め込みを避けることです。第二に、開発途中で発生するOS・PHP・Symfony・ライブラリのアップデートやセキュリティ脆弱性への対応です。これらは予期せぬタイミングで発生し、想定外の工数を生むことがあります。対策として、ComposerでDependabotや`composer audit`を活用し脆弱性を早期検知する体制を整え、保守費用が見積もりに含まれているかを事前に確認しておきます。第三に、前述の外部システム連携のデータ形式不整合によるトラブルで、これは開発前のフォーマットすり合わせが対策の要です。第四に、発注側のコンテンツ・データ準備の遅れです。システム側の実装は進んでいるのに、商品マスタのCSVや画像、送料ルールが揃わず、実データを用いたテストや公開ができないケースで、これは着手前から並行してデータを準備することで防げます。これらに加えて、プロジェクト全体の予備として全体スケジュールの10%程度のバッファを確保しておくと、不測の事態が起きても納期を守りやすくなります。

まとめ

本記事では、EC-CUBE開発の開発期間・スケジュール・納期について、規模別の期間目安、工程別の配分、EC-CUBE特有の期間変数、納期短縮の手法、そして遅延要因と対策までを体系的に解説しました。開発期間の目安は、デフォルトテーマ流用の小規模で1〜2か月、オリジナルデザイン・プラグイン開発を伴う中規模で2〜5か月、基幹連携・大規模カスタマイズで4〜8か月（半年〜1年以上になることもある）です。要件定義20〜30%・設計実装40〜50%・テスト20%という工程配分を押さえつつ、EC-CUBEではバージョン選定（新規は4系・Symfony基盤、2系からの移行は実質作り直し）、プラグイン活用とコア改変を避ける拡張設計、基幹連携の複雑さが期間を大きく左右する点を理解しておくことが重要です。納期を守るためには、デフォルトテーマと既存プラグインの最大活用、スモールスタートによる段階的リリースが有効であり、要件の曖昧さ・プラグイン競合・脆弱性対応・連携トラブル・データ準備遅れという遅延要因への対策を、変更管理プロセスの合意と10%のバッファ確保とともに講じておくことが欠かせません。オープンソースの柔軟性を活かしつつ無理のない納期を実現するには、まず自社の要件を「標準・プラグインで賄える部分」と「独自開発が必要な部分」に整理したうえで、EC-CUBEの構築実績が豊富な複数の開発会社に要件概要を提示して見積もりを取ることから始めることをお勧めします。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。