ECサイトのフルスクラッチとは、ECパッケージやカートサービスを使わず、商品管理・カート・決済・受注管理までを自社の要件に合わせてゼロから設計・開発する構築方法です。自由度が最も高い反面、費用と期間は3つの構築方法のなかで最も重くなります。
この記事では、フルスクラッチECの費用と期間の目安、どんなECがフルスクラッチになりやすいのか、デメリットへの対処、そしてすでにフルスクラッチで作ったECを乗り換えるときの考え方までを整理します。書き手はフルスクラッチ開発とEC-CUBEのカスタマイズの両方を請け負っている開発会社です。どちらかに誘導するのではなく、自社に合う方式を決めるための材料として読んでください。
ECサイトのフルスクラッチとは｜パッケージ・SaaSとの違い
ECサイトの作り方は大きく3つに分かれます。フルスクラッチ、ECパッケージ（EC-CUBEなど）のカスタマイズ、SaaS型のカートサービスの利用です。違いを表にまとめました。
| フルスクラッチ | ECパッケージ | SaaS・ASP | |
|---|---|---|---|
| 作り方 | ゼロから設計・開発 | 既存製品を拡張・改修 | 提供される機能を設定して使う |
| 自由度 | 制約なし | 製品の設計思想の範囲内 | 用意された範囲のみ |
| 初期費用と期間 | 最も重い | 中程度 | 軽い |
| 基幹システム連携 | 要件どおりに作れる | 製品の仕様に左右される | 難しい場合が多い |
| 保守の担い手 | 開発会社または自社 | 開発会社または自社 | 提供元 |
フルスクラッチは、自由度と引き換えに初期費用と期間を払う方法です。この交換が自社にとって割に合うかどうかが、判断の軸になります。
フルスクラッチECの費用と期間の目安
当社がWebシステム開発で実際に提示している費用レンジは次のとおりです。ECの見積もりもこの範囲が基準です。
| 規模 | 費用の目安 | 期間 | 想定するEC |
|---|---|---|---|
| 小規模 | 200〜500万円 | 1〜3ヶ月 | 商品数が限られ、決済と受注管理が中心 |
| 中規模 | 500〜1,500万円 | 3〜6ヶ月 | 会員管理や在庫連携を含む本格的なEC |
| 大規模 | 1,500〜5,000万円以上 | 6ヶ月〜1年以上 | 基幹システム連携や複数ブランドの統合 |
開発費は「工数×人月単価」で決まります。当社のシステム開発の人月単価は95〜120万円で、PM・SE・エンジニアのどの職種が担当するかによって変わります。つまり費用の差は、ほぼ工数の差です。工数を押し上げやすい要件は次のとおりです。
- 在庫・受注・顧客を基幹システムと双方向に同期する
- 予約やレンタルなど、売り切りではない販売形態を扱う
- 法人と個人で価格や支払い条件を分ける
- 既存ECから会員や受注のデータを移行する
見落とされやすいのが公開後の費用です。フルスクラッチのECは、作った側が保守しなければ動かし続けられません。開発費だけでなく、保守を含めた数年分で比べてください。
フルスクラッチになりやすいECの具体例
「標準的なECの機能では業務が回らない」場面が、フルスクラッチを検討するきっかけになります。ただし、独自要件があるからといって必ずゼロから作る必要はありません。当社ではパッケージの拡張で対応した例も多くあります。
| 独自要件の例 | 標準的なECで困ること | 当社での対応例 |
|---|---|---|
| 日付・席・人数を指定して売る | 物販前提で予約を扱えない | EC-CUBEに予約商品の拡張機能を実装 |
| 貸して返ってくるまでを管理する | 売買しか想定していない | EC-CUBEにレンタル商品の拡張機能を実装／自社パッケージ「EC Rent」を開発 |
| 法人と個人で会員を分け、ランクで割引する | 会員区分と価格ルールが足りない | EC-CUBEに会員区分と会員ランク別割引を追加 |
| 基幹システムと在庫・受注を同期する | 連携の仕様が製品に縛られる | 要件次第でフルスクラッチを含めて検討 |
上の3行はパッケージの拡張で実現しています。フルスクラッチが本当に必要になるのは、こうした拡張を重ねても業務の流れに合わない場合や、連携の要件が製品の枠を超える場合です。
フルスクラッチECのメリット
業務に合わせて作れる
パッケージでは「製品の考え方に業務を寄せる」場面が出てきます。フルスクラッチならその逆ができ、独自の価格ルールや配送条件、特殊な販売形態もそのまま形にできます。
事業の変化に合わせて拡張できる
機能を足すたびに製品側の制約やアップデートへの影響を確かめる必要がありません。必要なものを必要な順に追加していけます。
購入体験で差をつけられる
同じパッケージを使う競合とは、画面も動きも似てきます。購入までの体験そのものを差別化の材料にできるのは、ゼロから作る方式ならではです。
フルスクラッチECのデメリットと現実的な対処
| デメリット | 現実的な対処 |
|---|---|
| 初期費用が高い | 最初から全機能を作らず、核となる機能で公開して順に足す |
| 構築期間が長い | 同上。優先順位を一緒に決められる開発会社を選ぶ |
| 保守が欠かせない | 開発したチームがそのまま保守を担う体制にする |
| 開発会社に依存しやすい | ソースコードの権利と仕様書の納品範囲を契約時に確かめる |
最後の項目は発注前に必ず確認してください。ソースコードが手元に残らず、仕様書も納品されない状態では、後から別の会社へ引き継げなくなります。
フルスクラッチで作ったECを乗り換える・引き継ぐとき
すでにフルスクラッチで作ったECを抱えていて、保守の担当がいなくなった、改修のたびに時間がかかるといった理由で乗り換えを検討する例も少なくありません。選択肢は、今のシステムを引き継いで改修を続けるか、ECパッケージなどへ移すかの二つです。
どちらを選ぶにしても、最初に今のシステムの中身を把握する必要があります。他社が作ったシステムでも、仕様書かサーバーのログイン情報があれば当社で解析して改修や保守を引き継げます。仕様書がない場合は解析に時間がかかることがあります。移行先の選び方と進め方はECプラットフォームのリプレイスで失敗しないためにで詳しく整理しています。
フルスクラッチかパッケージか、判断の順序
- 自社にしかない要件を3つ書き出す。挙がらなければパッケージかSaaSで足りる
- その要件がパッケージの拡張で実現できるか、開発会社に確認する
- 拡張費用とフルスクラッチ費用を、保守を含めた数年分で比べる
- 公開後に誰が保守するかを決める。決まるまでは着手しない
当社はフルスクラッチとEC-CUBEカスタマイズの両方を手がけているため、どちらかに寄せる理由がありません。パッケージで足りる案件には、そうお伝えしています。
当社のEC開発について
C-limberは2013年の設立から13年目、累計1,000件以上のプロジェクトに携わってきました。ECについては、フルスクラッチ、EC-CUBEのカスタマイズ、自社ECパッケージの開発と運営という3つの立場を経験しています。
業務用家具メーカーの株式会社アダル様では、EC-CUBEで運営中のオンラインショップのリニューアルを担当し、会員ランクの仕組みや法人・個人を分けた登録機能を追加しながら改修を続けてきました。お客様からは「オンラインショップの売上が2年で約10倍」という声をいただいています。インサイドセールスで案件化した後の成約率も18%から45%になりました。
レンタルやサブスクのECを検討している場合は、自社で開発・運営しているレンタルEC構築パッケージ「EC Rent」という選択肢もあります。関西電力様に導入いただいています。EC-CUBEをベースにした構築はEC-CUBEカスタマイズのページで紹介しています。
まとめ
ECサイトのフルスクラッチは、自由度と引き換えに初期費用と期間を払う構築方法です。独自の業務フローがある、基幹システムと深く連携する、ECが事業の中核である。こうした条件がそろうときに効果を発揮します。
一方で、予約・レンタル・会員区分のような独自要件の多くは、パッケージの拡張でも実現できます。ゼロから作るかどうかは、要件を書き出し、拡張で届くかを確かめてから決めても遅くありません。
要件が固まっていない段階のご相談でも構いません。概算見積もりは無料です。Webシステム開発のページとあわせて、お問い合わせからご連絡ください。