BtoB-ECのパッケージ型とフルスクラッチの違い｜変更範囲・開発体制・保守で比較

この記事でわかること
「BtoB-ECを作るとき、EC-CUBEのようなパッケージを使うか、ゼロから開発（フルスクラッチ）するか」——どちらにするか、迷うことがあります。この記事では、どちらが優れているかではなく、変更できる範囲・開発と保守の体制・コスト構造という観点で、両者を中立に比較します。ポイントは、「ゼロから作る必要が、本当にあるか」を考えることです。
なお、この記事では、パッケージ型とフルスクラッチを比較します。SaaS型（Shopifyなど）とパッケージ型の違いについては、SaaS型とパッケージ型の違いで解説しています。

パッケージ型とフルスクラッチの違い

まず、用語を整理します。

パッケージ型は、基本的な機能が最初から用意されており、それを土台に、足りない部分を追加していきます。フルスクラッチは、土台から作るため、要件に合わせた設計の自由度が高い一方、その分、開発する範囲が広くなります。以下、この2つを、いくつかの観点で比較していきます。

変更できる範囲

パッケージ型は、基盤となる製品の構造を活かしつつ、カスタマイズやプラグイン、個別開発で、要件に合わせていきます。EC-CUBEのようにソースコードを扱える製品では、変更できる範囲は広いですが、基盤の構造を踏まえた設計になります。フルスクラッチは、土台から設計するため、変更できる範囲は広くなります。ただし、フルスクラッチであっても、使用する技術や、外部サービス、予算といった制約はあります。「完全に自由」というより、「基盤の制約が少ない分、設計する範囲が広い」と捉えるのが実際に近いです。

開発・保守を、誰が担うか

どちらの方式でも、開発と保守を、誰がどこまで担うかが論点になります。パッケージ型は、基盤部分のアップデートは製品側で提供されることがあり、その分、自社や開発会社が担う範囲は、フルスクラッチより狭くなることがあります。フルスクラッチは、基盤を含めてすべてが独自の実装になるため、保守や改修も、その独自実装に対して行う必要があります。保守を、自社で担うのか、開発会社に委託するのかは、どちらの方式でも検討する部分です。

バージョンアップと技術の保守

パッケージ型は、基盤となる製品のバージョンアップに対応する必要がありますが、その手順は製品側で提供されます。一方、独自にカスタマイズした部分は、バージョンアップ時に確認が必要になることがあります。フルスクラッチは、製品のバージョンアップという概念はありませんが、使用しているフレームワークや言語のバージョン、セキュリティ対応などを、自分たちで管理していく必要があります。どちらも、公開後に技術面の保守が続くという点は共通です。EC-CUBEのバージョンアップについては、バージョンアップで確認したい6つのポイントで解説しています。

コスト構造の違い

コストは、「どちらが安いか」ではなく、何にコストがかかるかの構造が異なる、と捉えるのが実際に近いです。

初期開発、カスタマイズ、保守、バージョンアップ、内製の人員、外部委託など、何を、どこで負担するかによって、総額は変わります。初期費用だけでなく、運用する期間を含めて比較することが大切です。費用の考え方は、EC-CUBE構築の費用の内訳もご覧ください。

フルスクラッチを検討する条件

次のような場合は、フルスクラッチも検討の対象になります。

• 既存のパッケージの変更範囲では、要件を満たしにくい
• 独自の処理や、データ構造が、システムの中核になる
• 開発・保守を担う体制がある（内製、または継続的に委託できる）

フルスクラッチは、要件に合わせて設計できる自由度がある一方、開発の範囲が広く、保守も独自実装に対して続きます。この体制とコストを見込めるかが、検討のポイントになります。

パッケージ型を検討する条件

次のような場合は、パッケージ型が現実的な選択肢になります。

• 受注の構造が、パッケージの機能やカスタマイズで対応できる範囲にある
• 基幹連携などが、パッケージの仕組みで整理できる
• 初期開発の範囲や、保守の負担を、抑えて始めたい

EC-CUBEのようなパッケージは、基本機能を土台にできるため、初期開発の範囲を、フルスクラッチより絞りやすいという特徴があります。ただし、パッケージの構造に合わない要件がある場合は、その部分の設計を検討することになります。

判断するときに確認したいこと

パッケージ型とフルスクラッチのどちらを選ぶかは、次のような点を確認して考えます。

• 要件が、既存のパッケージの変更範囲で満たせるか
• 独自の処理やデータ構造が、どこまで中核になるか
• 開発・保守を担う体制があるか
• 初期開発と、その後の運用を含めた、コスト構造

大切なのは、「どちらが優れているか」ではなく、「自社の要件に、どちらが合うか」で考えることです。まず、要件を整理することが、判断の出発点になります。

まとめ

BtoB-ECのパッケージ型とフルスクラッチは、どちらが優れているというものではなく、変更できる範囲・開発と保守の体制・コスト構造という点で、違いがあります。大切なのは、「ゼロから作る必要が、本当にあるか」を、要件から考えることです。既存のパッケージの変更範囲で満たせるなら、パッケージ型が現実的な選択肢になりますし、独自の処理やデータ構造が中核になり、体制も見込めるなら、フルスクラッチも検討の対象になります。

私たちサンクユーは、EC-CUBE（パッケージ型）を中心に、BtoB-ECの構築を手がけています。要件を伺ったうえで、パッケージで対応できるか、それとも別の方法が合うかも含めて、ご提案します。構築方法の選定で迷っている方は、お気軽にご相談ください。