EC新規事業の開発｜既製カートと独自開発の分け方
ECを新規事業で始めるとき、すべてを自作する必要はありません。かといって、すべてを既製のカートに合わせればよいとも限りません。この記事では、既製のカートで足りる部分と、独自に開発する価値が出やすい部分の分け方を整理します。
私たちJustFit編集部は、新規事業とシステムの組み合わせを日々考えています。ここで扱うのは、特定のサービスの優劣ではなく、「事業の差がどこで生まれるか」から開発の範囲を決める考え方です。
ECの新規事業で「開発」が必要になる場面と、ならない場面
ECの新規事業を考えるとき、最初に出てくる疑問は「システムを作るべきか、既製のカートで始めるべきか」です。結論から言うと、この二択で考えると判断を誤りやすくなります。多くの場合、答えは「一部は借りて、一部は作る」になります。
既製のカートとは何か
ここでいう既製のカートは、商品登録、カート、決済、注文管理、配送連絡といったECの標準的な機能をまとめて提供するサービスやパッケージを指します。月ごとの利用契約で使うクラウド型もあれば、ソフトウェアを自社のサーバーに入れて使う型もあります。細かい仕様はサービスごとに違うため、検討するときは各サービスの公式情報で確認することが前提になります。
既製のカートの強みは、ECに共通して必要な機能が最初から揃っていることです。商品を並べて注文を受け、決済して発送する。この流れが標準的な事業であれば、ゼロから作る理由はあまりありません。
開発が必要になりやすいのは「売り方そのものが新しい」場合
一方で、開発の検討が必要になるのは、次のような場面です。
- 商品を選ぶ前の体験に事業の価値がある（診断、見積り、仕様の組み立てなど）
- 価格や納期が、注文ごとの条件で決まる
- 売る側と買う側の間に、独自の確認や承認のフローがある
- 注文後の運用（製造、手配、継続利用）まで含めて事業になっている
- 他の事業や他のシステムとつないで初めて成り立つ
これらは、標準的なカートの「商品を選んで買う」という前提から外れる部分です。外れる度合いが大きいほど、カートの設定や追加機能だけでは吸収しにくくなります。
逆に、売るものが既存の商品で、売り方も一般的なECと変わらないなら、新規事業の検証はまず既製のカートで始めるほうが現実的です。「作らない」という判断も、立派な開発の判断の一つです。
分け方の基本は「事業の差が生まれる部分だけ作る」
分け方の軸は、とてもシンプルです。事業の差が生まれる部分は自分たちで持ち、差が生まれない部分は借りる。この軸で、ECの機能を三つに分けて考えます。
借りる部分：どの競合も同じ機能を持つところ
商品の一覧表示、カート、基本的な注文処理、メール通知、一般的な決済など、ECを営む上で「あって当たり前」の部分です。ここで独自性を出しても、利用者にはほとんど伝わりません。作るほど保守の負担だけが増えます。
特に決済は、扱うデータの重さや安全面の責任が大きい領域です。外部のサービスを使うか自作するかの考え方は、新規事業の決済システム開発｜外部サービスと自作の分け方で詳しく整理しています。
作る部分：利用者が「この事業ならでは」と感じるところ
利用者が価値を感じる場面を思い浮かべると、見つけやすくなります。例えば次のような場面です。
- 購入前に、自分に合うものが分かる体験
- 注文内容を細かく指定でき、その結果がすぐ価格に反映される
- 継続して使うほど、提案や条件が変わっていく
- 売り手と買い手の間で、独自のやり取りが進む
差別化の中身を機能に落とし込む考え方は、新規事業の差別化を機能に落とし込む最初の設計も参考になります。
つなぐ部分：借りるものと作るものの境目
もう一つ見落としやすいのが、借りる部分と作る部分をつなぐ領域です。独自に作った画面から注文が発生したとき、その情報を既製のカートの注文管理にどう渡すのか。顧客情報はどちらが持つのか。この境目の設計が、後の使いやすさと変更のしやすさを左右します。
判断に使う五つの質問
どの機能が「借りる」で、どれが「作る」かを決めるために、機能ごとに次の質問を当てはめます。
- その機能が他と同じでも、利用者は事業の価値を感じるか
- その機能の違いが、利用者の購入や継続の理由になっているか
- 既製のカートの設定や標準の拡張で、その動きを再現できるか
- 再現できても、運用で人手が大きく増えないか
- 将来、その機能の変更を自分たちで素早く行いたいか
1と2が「いいえ」なら、借りる側です。2が「はい」で3が「いいえ」なら、作る側の候補になります。3が「はい」でも4で人手が増えるなら、運用の負担と開発の負担を比べて決めます。5は、事業を育てるうえで機能の変更頻度が高いかどうかを見る質問です。
既製カートで足りやすい部分と、独自に作る価値が出やすい部分
具体的な機能に当てはめて整理します。ここで挙げるのは一般的な傾向であり、実際にはカートのサービスや事業の中身によって変わります。
既製カートで足りやすい部分
- 商品登録、在庫の基本管理、商品ページの表示
- 会員登録、ログイン、基本的な注文履歴
- 一般的な決済手段への対応
- 注文確認メールや発送通知
- 特定商取引法に基づく表記などの基本的なページ
- 基本的な売上・注文の集計
これらは、多くのECで共通して必要です。標準機能で動かして、実際の注文が入るかを見ながら調整するほうが、早く事業の手応えを確かめられます。
独自に作る価値が出やすい部分
- 購入前の診断、提案、見積りなどの独自の体験
- 条件ごとに価格や納期が変わる仕組み
- 定期利用や継続課金に独自のルールがある場合の管理
- 注文後に社内外の複数の関係者が動く独自のフロー
- 他の事業システムや外部サービスとの独自の連携
- 売り手側の独自の管理機能
継続課金を伴う事業の場合は、先に決める項目が多くなります。サブスク新規事業のシステム開発｜先に決める6つのことが参考になります。また、売り手側の管理機能は、最初から作り込みすぎると負担が大きくなります。新規事業の管理画面開発｜最初に作る範囲の見極め方も合わせて確認してください。
迷いやすい中間の部分
実際には、どちらとも言い切れない部分が出てきます。例えば、会員ランクによる価格の出し分けや、独自のクーポン条件、特殊な送料の計算などです。こうした部分は、まず既製のカートの設定や拡張機能でどこまで再現できるかを確認します。再現できるなら、最初はそれで始めます。再現できない、または運用が破綻するなら、その部分だけを独自に作る候補にします。
大切なのは、迷う部分を「最初から全部作る」か「全部諦める」かで決めないことです。
分け方で失敗しやすいパターン
ここからは、判断を誤りやすいパターンを整理します。どれも一般的に起こりやすい傾向であり、特定の会社や開発のやり方を指したものではありません。
全部を自作しようとして、事業の検証が遅れる
新規事業では、事業が成り立つかの確認が最優先です。ところが、ECの標準機能まで含めて作ろうとすると、本来確かめたい「事業ならではの部分」に着手する前に、時間と判断の力を使い果たします。
標準機能は、借りたほうが早く、検証したいことに集中できます。「自分たちらしいシステムにしたい」という思いは大切ですが、利用者が価値を感じる部分に絞ったほうが事業の検証には向いています。最初の機能範囲の絞り方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準にまとめています。
既製の枠に無理に事業を合わせてしまう
逆の失敗もあります。既製のカートの仕様に合わせて、事業のほうを変えてしまうケースです。本当に価値の源泉になる部分まで「カートでできる範囲」に丸めてしまうと、他と変わらないECになり、始める意味が薄れます。
「できることに事業を合わせる」のか「事業に必要だから作る」のか。この線引きを、機能ごとに言葉にしておくことが重要です。
データの出口を考えていない
既製のカートに顧客情報や注文データが蓄積されていくとき、そのデータを後から取り出し、別のシステムで使えるかどうかは、事前に確認しておきたい点です。カートを入れ替える、独自のシステムとつなぐ、分析に使うといった場面で、データの持ち出しやすさが効いてきます。
どのデータが事業の資産になるのか、誰が管理するのか、どんな形で取り出せるのか。データの持ち方は、新規事業のデータ設計｜最初に決めたい5つの持ち方で整理しています。個人情報を扱うEC事業では、新規事業の個人情報とシステム設計｜設計前に確認する点も事前に目を通しておくと安心です。
拡張の余地を確かめずに選んでしまう
既製のカートは、最初は便利でも、事業が育つと「ここだけ変えたい」という要望が出てきます。そのとき、標準の拡張機能やAPI（他のシステムとつなぐための窓口）が用意されているか、どの範囲まで変更できるのかを、選ぶ前に公式情報で確認しておくことが大切です。利用者の増加に備えどこまで作り込むかについては、新規事業のシステムの拡張性｜利用者増への備えはどこまでが参考になります。
事業の検証と運用の準備を混同する
最後に、事業の検証と運用の準備を同じものとして扱うケースです。検証の段階では、手作業を多めに残しても構いません。注文が入ってから人が手動で調整する、といった運用でも、事業の可否は確かめられます。最初から運用の自動化まで作り込もうとすると、検証の前に負担が膨らみます。
プロトタイプで「分け方」そのものを確かめる
ここまでの判断は、頭の中だけで進めると、どうしても仮説にとどまります。「この部分は既製のカートで足りるはず」「ここは独自に作らないと価値が出ないはず」という判断が合っているかは、実物を触ってはじめて分かります。
差が出る部分だけをプロトタイプにする
分け方を確かめるには、事業の差が出ると考えている部分だけを、動く形にして見るのが近道です。標準的な商品一覧やカートまで作る必要はありません。例えば、購入前の診断体験や、条件ごとの価格の出し方など、事業の核だと考える部分だけを試作します。
プロトタイプの種類や使い分けは、プロトタイプとモックアップ・MVPの違い｜新規事業の使い分けで整理しています。小さく作って確かめる考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方も参考になります。
確かめたいことを先に決める
プロトタイプは、作ること自体が目的ではありません。次のような問いに答えるための道具です。
- その独自の体験は、利用者にとって分かりやすいか
- 独自に作る部分がなくても、事業の価値は伝わらないか
- 既製のカートと組み合わせたとき、注文や顧客情報の受け渡しは無理なく動くか
- 売り手側の運用は、現実的な手間に収まるか
指標の決め方は、MVP検証の指標を先に決める方法｜判断基準の作り方が参考になります。「何が確認できたら次に進むか」「何が見えたら見直すか」を先に決めておくと、結果を判断しやすくなります。
動く実物を見ながら、関係者で話す
ECの新規事業では、決裁者、現場の担当者、運用に関わる人など、関係者の見ている景色が違います。言葉や企画書の説明だけでは、独自に作る部分の意味が伝わりにくいことがあります。
動くものを前にして「この診断は不要では」「ここは既製のカートの画面のままでいい」と話せると、分け方の議論が具体的になります。実物を使った確認の進め方は、新規事業のアイデア検証方法｜動くシステムで確かめる手順で紹介しています。また、AIを使った開発で短期間に試作しやすくなる理由は、AIでプロトタイプを短期間で作れる理由｜工程ごとの仕組みにまとめています。
「作らない」「やめる」の判断も含める
プロトタイプで確かめた結果、「独自に作る部分は思ったほど価値にならない」と分かることもあります。その場合は、既製のカートだけで始める判断をしても構いません。事業そのものを見直すという判断もありえます。撤退や縮小の判断の基準は、新規事業の撤退判断｜プロトタイプで「やめる」と決める基準で扱っています。
作る前に「作らなくてよいと分かる」ことも、プロトタイプの大きな成果の一つです。
後から入れ替えられるよう、境目を決めて作る
分け方は、一度決めたら変わらないものではありません。事業が育つと、既製のカートで足りていた部分に独自の要望が出てきたり、逆に独自に作った部分を標準機能に戻したくなったりします。変更しやすい形にしておくことが、長く続けるうえでの備えになります。
境目を明文化しておく
どの機能をどこが担うのか、どのデータをどちらが持つのかを、文書や図で残しておきます。誰が見ても分かる形にしておくと、担当者が変わっても判断がぶれにくくなります。
他のシステムとのつなぎ方を最小限にする
独自に作る部分と既製のカートをつなぐ点は、できるだけ少なく、単純にしておきます。受け渡すデータの種類を絞っておけば、片方を入れ替えるときの影響範囲も小さくなります。
既存の事業システムがある会社では、新規事業側のシステムを切り離しておく考え方も有効です。詳しくは、新規事業は既存システムと切り離して作る理由と進め方を参照してください。
プロトタイプの後の道筋も考えておく
プロトタイプで確かめた後、本格的な開発に進むときに、どこまでを引き継ぎ、どこを見直すのか。この点は、MVPから本開発は作り直し？引き継げる部分と見直す点で整理しています。事業の1年先までの流れは、新規事業の開発ロードマップの描き方｜プロトタイプ後の1年も参考になります。
ノーコードやAI開発との比較も視野に入れる
既製のカートに加えて、ノーコードのツールで独自部分を補う選択肢もあります。どこまでノーコードで足りて、どこから開発が必要になるかは、事業の中身によって変わります。AI駆動開発とノーコードの違い｜新規事業に合うのはどちらで、判断の目安をまとめています。
まとめ
ECを新規事業で始めるときは、「作るか、借りるか」の二択にせず、機能ごとに分けて考えます。ポイントは次の通りです。
- 事業の差が生まれる部分は独自に作る候補、どの競合も同じ機能を持つ部分は既製のカートで借りる候補にする
- 借りる部分と作る部分の「つなぎ」（データや注文の受け渡し）を、最初に設計しておく
- 全部自作する、既製の枠に事業を合わせすぎる、データの出口を考えないといった失敗に気をつける
- 分け方は仮説なので、差が出る部分だけをプロトタイプにして、実物で確かめる
- 作らなくてよいと分かることも、検証の成果として扱う
- 後から入れ替えられるように、境目とデータの持ち方を明文化しておく
私たちJustFitは、システムが事業そのものになるような新規事業を得意としており、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく進め方をとっています。ECで「ここだけは独自に作りたい」という部分があるものの、仕様が固まっていない段階でも、考え方の整理からご相談いただけます。サービスの詳細はJustFitのサービス紹介をご覧ください。