Adobe Commerce と Shopify Plus、どちらが自社に合うか

カタログの構造、価格ロジック、あるいはバックオフィス連携が事業の本当に難しい部分であるなら、Adobe Commerceのほうが強い選択肢です。難しいのが市場に早く出ることと少人数で運営することであり、かつ自社の商習慣がホスティング型プラットフォームのルールに無理なく収まるなら、Shopify Plusのほうが強い選択肢です。

どちらの言い方も目新しくはなく、どちらも正しいものです。難しいのは、その答えに数年分のロードマップを賭ける前に、自社がどちらに当てはまるのかを見極めることです。以下は、アジア各地の小売・FMCGのお客様とこの問いを整理していくときの進め方を、どちらのベンダー目線も抜きにまとめたものです。

先に効いてくる制約はどれか

プラットフォームの選定が機能比較で決まることはめったにありません。まともなプラットフォームであれば、どれも商品ページを表示し、カード決済を受け、領収メールを送れます。決まるのは、最初にぶつかる制約がどれで、その制約を回避するコストがどれだけ高いかです。

あるブランドにとって効いてくる制約はカタログです。カテゴリごとに異なる属性セット、顧客グループやチャネルで動く価格、市場ごとに中身が変わるセット商品。別のブランドにとってはバックオフィスです。ERPが在庫と価格を持ち、財務部門は正となるデータが2つ存在することを認めません。そして正直に言えば、多くのブランドにとって効いてくる制約は時間と社内リソースであり、その場合は作業をいちばん減らせるプラットフォームが勝ちます。

まず制約に名前をつけてください。プラットフォームはそこから決まります。

要点を並べて比較する

最初の本当の試金石はカタログの複雑さ

Adobe Commerceは、単純にモデル化できないカタログのために作られました。商品タイプごとの属性セット、設定可能商品とセット商品、1つの管理画面の下に置かれる複数のウェブサイトとストアビュー、そして顧客グループ・数量階層・カタログ条件で積み重なる価格ルール。売り場づくりの担当チームがすでにこうした言葉で考えているなら、このプラットフォームは自分たちの働き方に合わせて設計されているように感じられるはずです。実際そのとおりだからです。

Shopify Plusも大規模なカタログを問題なく扱いますが、モデル化はより単純です。商品はオプションとバリエーションを持ち、商品あたりのバリエーション数には上限があります。変わった構成は通常、アプリを使うか商品を分割することで解決します。これは欠点ではありません。多くの小売カタログにとってはこれでちょうど十分であり、単純なモデルのほうが、開発の支援なしに売り場担当が運用するにははるかに楽です。

試されるのはカタログの規模ではなく、カタログの形です。非常に大きくても構造が一貫しているカタログを持つブランドは、Shopify Plusで快適に運用できます。逆に、はるかに小さなカタログでも、商品ごとに固有の属性、チャネル別の価格、市場別のセット構成が必要なブランドは、四半期ごとにプラットフォームと格闘することになります。

バックエンドの拡張：アプリかソースコードか

両者のアーキテクチャ上の違いが最もはっきり出るのがここです。

Adobe Commerceはソースコードを渡してくれます。コアの挙動を上書きし、受注・在庫・価格の動き方そのものを変えるモジュールを書き、どのサードパーティも販売していないロジックを構築できます。これは本物の力であり、同時に本物の責任でもあります。すべてのカスタマイズは、自社が所有し、テストし、バージョンアップのたびに引き継いでいくコードです。

Shopify Plusはサーバを渡しません。アプリ、Shopify Functions、プラットフォームのAPIを通じて拡張し、フロント側はテーマかヘッドレス構成でカスタマイズします。購入手続きは任意のコードに開かれているのではなく、定義された拡張ポイントの範囲内で設定します。その代わりに、サーバへのパッチ適用も、インフラ移行の計画も、金曜の午後に週末までに適用すべきセキュリティリリースを見つけることもありません。

エンジニアは本能的に開かれたシステムを好みます。事業を回す側は、多くの場合そうすべきではありません。問うべきは、自社に必要なロジックがShopifyの拡張モデルの中では本当に実現できないのか、それとも単に無制限の制御という考え方が好みなだけなのか、です。前者はAdobe Commerceを選ぶ正当な理由になります。後者は、必要のない開発を買い込む正当な方法です。

SAPとERPの連携

ERPが在庫、価格、会計記録を持っているなら、連携こそがプロジェクトの本体です。店舗側は簡単なほうの半分です。

Adobe Commerceが深いERP案件に向いているのは、ERPの土俵に合わせにいけるからです。独自のキュー、アプリケーションの内側に置く変換ロジック、そしてドキュメントに書かれた挙動ではなくERPの実際の挙動に合わせて書いた再送と突合の処理。当社のMagento-SAP案件は財務・在庫・倉庫の各モジュールにまたがりますが、難しいのはAPI呼び出しであったためしがほとんどありません。難しいのは、項目ごとにどちらのシステムが正なのかを決めること、そして両者が食い違ったときに何が起きるのかを決めることです。

Shopify PlusもERPと問題なく連携でき、多くの場合はコネクタかミドルウェア層を経由します。マッピングがおおむね標準的であれば、これはきれいに機能します。厄介になるのは、ERPが10年かけてカスタマイズされている場合、在庫引当のロジックが特殊な場合、あるいは財務がコネクタの想定していない伝票フローを要求する場合です。その時点でどのみちミドルウェアを作ることになり、両プラットフォームの柔軟性の差はかなり縮まります。

総保有コストが実際に意味するもの

コスト比較が失敗するのは、たいてい比べているものが違うからです。表向きの金額はいったん脇に置いて、支出の形を比べてください。

Shopify Plusは、コストを予測しやすいプラットフォーム契約とアプリの利用料に集約します。決済手数料の条件は、Shopify自身の決済基盤を使うかどうかで変わります。インフラ、セキュリティパッチ、可用性、プラットフォームのバージョンアップはベンダーが吸収します。開発予算は、灯りをつけ続けるためではなく、店舗、連携、成長のための施策に向かいます。

Adobe Commerceは、そのコストをホスティング、開発、そして自社で計画し予算化するバージョンアップのサイクルへと移します。バージョンアップは週末の作業ではなくプロジェクトです。プラットフォームが、代替手段では実現できない商業的価値のあることをしているなら、これはまったく妥当な取引です。そうでないなら、非常に割の悪い買い物になります。

決断の前にやっておくと有効な作業があります。今後3年で事業に必要になるもののうち、Shopify Plusでは本当に実現できないものをすべて書き出してみてください。そのリストが短い場合、あるいはそこに並んだ項目がどれも要件ではなく好みだと分かった場合、軽いほうのプラットフォームを選ぶのが商業的にはまず正解です。

アジアで売ると、問題の形が変わる

マレーシアおよび周辺地域で事業を営むブランドにとって、自社ECだけがチャネルのすべてであることはまれです。Shopee、Lazada、TikTok Shopは実際の売上を担っており、自社サイトでは正確なのにマーケットプレイスでは古いままの在庫は、どんなプラットフォーム選定の節約額より高くつく売り越しを生みます。

当社は、まさにその問題のために自社のマーケットプレイス同期技術WOW Syncを開発しました。Adobe Commerce、Shopify Plus、WooCommerceのいずれの構築とも並行して動きます。プラットフォーム選定にとって重要なのは、マーケットプレイス層がその外側にあるという点です。マーケットプレイス対応だけでコマースプラットフォームを選ばないでください。中核の選択がどちらに転んでも、その層は意識して解くべきものです。

モバイルも同じです。Android、Apple、Huawei向けのアプリは、それぞれ独自のリリースサイクルと採算を持つ別個のプロダクト判断です。MR.DIYはローンチから最初の1週間で10万ダウンロードを超えましたが、それは下に敷かれたコマースプラットフォームよりも、小売ブランドの力とローンチ計画によるところがはるかに大きいものでした。

Shopify Plusのほうが良い答えになるとき

間違った選択を前提に人員を組むくらいなら、早い段階でこう申し上げます。

• カタログは大きいが、構造は一貫している。
• 少人数の社内体制で、早く立ち上げたい、あるいは早く移行したい。
• 社内に開発リソースがなく、今後も持つつもりがない。
• ERP連携がおおむね標準的である、あるいはそもそもERPがない。
• 新しい市場に参入予定で、独立した店舗を近いうちに稼働させる必要がある。
• やりたいことの大半が、よく保守されたアプリとしてすでに存在する。

このうちいくつかが自社に当てはまるなら、Adobe Commerceを選ぶことは、決して行使しない選択肢に対して支払うことを意味します。当社のShopify Plus支援は、まさにそうした状況のために存在しており、これをお勧めすることで当社が失うものは何もありません。

Adobe Commerceがその価値に見合うとき

• ホスティング型のモデルでは素直に表現できないカタログと価格のロジック。
• 変換処理、再送、突合を自分たちで制御する必要がある深いERP連携。
• BtoBとBtoCが、共通の基盤の上で異なるルールのもとに動いている。
• 別々の店舗としてではなく、カタログと在庫を共有しなければならない複数ブランド・複数市場の運営。
• 設定するのではなく作り続けることを見込んだ、長い時間軸。

14年にわたるAdobe Commerce・Magentoの実務から学んだのは、このプラットフォームは腰を据えた投資に報い、中途半端な取り組みには罰を与えるということです。長期的なプロダクト投資として扱うブランドは、その上でうまくいきます。Guardian Malaysiaとの取り組みは8年以上続いており、サイトのパフォーマンスを200%改善し、売上を10%押し上げました。これはプラットフォームの選択そのものではなく、継続的な作業から生まれたものです。

判断の進め方

4つの問いを、この順番で。

1. 自社の事業の難しい部分はどこか。 カタログと価格か、バックオフィスか、スピードとリソースか。実際に人手を取られているのはどれなのか、正直に。
2. 3年後に真であるべきで、今日は真でないことは何か。 新しい市場、新しいチャネル、BtoB事業、商習慣の変更。
3. 誰が保守するのか。 実在するチームの名前を挙げてください。社内に持ち主がいないなら、ホスティング型に大きく傾けるべきです。
4. 軽いほうのプラットフォームでは、最初に何が壊れるのか。 名前のついた要件として具体的に答えられないなら、軽いほうがおそらく正解です。

そのうえで、ロードマップを確定させる前に、いちばんリスクの高い部分を試作してください。それはたいていERP連携か、扱いにくい価格ルールの1つであり、店舗側であることはほとんどありません。難所を2週間かけて検証するほうが、1年かけて発見するよりずっと安く済みます。

自社がその線のどちら側にいるのか、第三者の意見が必要でしたら、プロジェクトについてお聞かせください。小さいほうの道具が正解である場合も含めて、率直にお答えします。