マレーシアで売上を伸ばすAdobe Commerceパートナーの条件

売上を伸ばしてくれるAdobe Commerceパートナーは、きちんとした店舗を作ってくれるパートナーとは違って見えます。どちらも良いコードを書きます。しかし、見積もりを出す前にカタログのモデル設計について議論を挑んでくるのは片方だけです。FPXの失敗率が購入完了数にどう効くかを知っているのも、いただいた要件のどれが元を取れないかを言えるのも、片方だけです。

厄介なのは、提案資料からその2つを見分けるのがほぼ不可能だという点です。この市場のどの会社も、プラットフォームの専門性、エンタープライズでの実績、成長への注力を掲げます。以下は、そうした主張が実務上何を意味していなければならないのか、そして実際にやってきた相手と読んで知っているだけの相手を分ける具体的な質問です。

5つの能力と、それぞれの実際の価値

この記事で役に立つのは右端の列です。残りは、その質問がなぜ効くのかの説明です。

プラットフォームの深さ：「Magentoが分かる」が意味すべきこと

Adobe Commerceは、軽量なプラットフォームにはない形で深さに報います。このプラットフォーム上の重大な誤りは、ほぼすべてが数か月にわたって目に見えないからです。属性セットの設計を誤ったカタログは、公開時点では問題なく動き、3つめの市場で立ち行かなくなります。コアの挙動の周りではなく上に書かれた独自コードは、テストを通過し、その後のすべてのバージョンアップを止めます。

したがって有用な信号は、管理画面への慣れではありません。そのパートナーが、痛みを伴う部分をくぐり抜けてプラットフォームを運んできたかどうかです。メジャーバージョンアップ、実トラフィック下でのインデクサとキャッシュの調整、稼働中の店舗でのカタログ再設計、そして1つの機能のために入れたのに今では3つを支配している拡張機能の長い列。

Bridziaはこのプラットフォームに14年を費やしてきました。初期のバージョンから、その後のすべてのメジャーリリースまでです。その正直な価値は機能の一覧ではありません。パターン認識です。新しいチームならあなたのプロジェクトで発見することになるパフォーマンス、連携、拡張の問題の大半に、他社のスケジュールと他社の予算のもとですでに出会っているということです。

バージョンアップの話を聞いてください。Adobe Commerceを本当に規模のある環境で運用してきたパートナーは、必ず1つ持っています。そしてそれが全面的に自慢話であることは、決してありません。

納品だけでなく、商業的な判断力

支援会社の最も高くつく失敗は、悪いコードではありません。依頼されたすべてを忠実に作ることです。

要件定義書は、証拠が出そろう前に書かれた「何がお金になるか」という仮説です。商業的な勘が働いているパートナーは、その一部に異議を唱えます。まだ存在しないトラフィックを必要とするパーソナライズ機能、2段階で足りるのに4段階あるロイヤルティ階層、競合にあるという理由で存在する独自の購入手続きステップ。

これは実際に試せる資質です。候補となるパートナーに、私たちの要件のうち何を削るかと尋ねてください。「何も。どれも妥当に見えます」と答える会社は、注意深く読んでいないか、契約金額を最大化しているかのどちらかです。ほしい答えは、具体的な項目を2つか3つ挙げ、それぞれの構築費と維持費を説明し、後から正当化するには何が必要かを述べるものです。

同じ理屈がプラットフォームの選択そのものにも当てはまります。カタログの構造、価格ロジック、バックオフィス連携が事業の本当に難しい部分であるとき、Adobe Commerceは正解です。そうでないなら、軽量なプラットフォームのほうが商業的に良い判断であり、それを口に出せないパートナーは助言をしていません。このトレードオフについてはAdobe Commerce と Shopify Plus、どちらが自社に合うかで、小さいほうの道具が勝つ場合も含めて詳しく書いています。

コンバージョンを左右するマレーシア固有の事情

現地での運用経験がないパートナーが、静かに売上を削っていくのがここです。何も壊れて見えないからです。店舗は動きます。ただ、本来の水準より低いコンバージョンしか出ません。しかもその理由は、不具合報告に現れることがありません。

最大のものは決済構成です。 マレーシアの買い物客は、銀行振込にはFPXを、カードと並んでGrabPayやTouch 'n Goを含む電子ウォレットを期待します。他市場から持ち込んだカード前提の購入手続きは、顧客の大半が求める選択肢をもう1クリック奥に置きます。そして、決済手段別にファネルを見ている人がいない限り、その離脱は見えません。Bridziaはこれらを標準で組み込んでいますが、理由は網羅性ではありません。決済手段の並び順そのものがコンバージョンの判断だからです。

モバイルは副次的な画面ではなく主戦場です。 マレーシアの人々の64%がモバイル端末でオンライン購入をしています。この数字は、構築の順序そのものを規定すべきものであり、レスポンシブなテーマを作って最後にスマートフォンで確認することとは違います。購入手続きで何を優先するか、画像にどれだけの容量を割り当てるか、そして買い物アプリがロードマップに入るのか後付けなのかが変わります。

物流と返品は現地の論理で動きます。 配送業者のカバー範囲、料金体系、東マレーシアへの配送に対する期待値は、配送ルール、約束するお届け日、返品フローを形づくる運用上の現実です。1社としか連携したことのないパートナーは、面白いケースにまだ出会っていません。

コンプライアンスは法務の後付けではありません。 SSTの扱いは価格表示と請求に影響します。2010年個人データ保護法（PDPA）は顧客データの収集、保管、同意取得のあり方を定めており、アカウント作成、マーケティングのオプトイン、そしてすべての解析の判断に関わります。これらは後から作り直すより、最初から設計に織り込むほうが安く済みます。

言語はカタログの設計判断です。 英語とマレー語の二言語コンテンツは、商品属性とストアビューをどう構造化するかというデータモデルの問題であり、最初に決めるか、二度払うかのどちらかです。

成長に耐える連携とアーキテクチャ

この規模のブランドの多くにとって、連携こそがプロジェクトの本体であり、店舗側は簡単なほうの半分です。ERPが在庫、価格、会計記録を持っているなら、その連携の品質が、サイトが顧客に真実を伝えられるかどうかを決めます。

重要な問いはコネクタについてではありません。所有権と失敗についてです。

• どのシステムがどの項目を持ち、両者が食い違ったときに何が起きるのか。
• 販売可能在庫は、サプライチェーン部門と合意した明示的な計算式なのか、それとも倉庫の生の数字なのか。
• 受注送信は冪等か。判然としないタイムアウトの後に再送しても、受注伝票が重複しないか。
• 販促期間中にERPが使えなくなったとき、何が動くのか。
• 突合レポートを誰が読んでいて、それが空である頻度はどれくらいか。

これらによどみなく答えるパートナーは、壊れた連携を直した経験があります。コネクタの製品名を持ち出すパートナーが説明しているのは、購買であってアーキテクチャではありません。具体的な失敗のパターンはMagentoとSAPの連携で、実際に壊れるのはどこかに、より広い設計判断はERP連携のベストプラクティスにまとめています。

同じ規律が規模の問題にも当てはまります。マレーシアの小売にとってのピークは1年を通じて均等ではありません。キャンペーン日と祝祭シーズンに集中し、そのときトラフィックとカタログ更新の量が同時にやってきます。耐えるアーキテクチャとは、店舗だけでなく連携も含めて負荷テストされたアーキテクチャのことです。

公開後に起きることが、価値の大半

公開は、計測できる部分の始まりです。その後まったく手を入れられないプラットフォームは劣化します。拡張機能は古くなり、セキュリティリリースは積み上がり、カタログはモデル設計時の前提を超えて育ち、パフォーマンスは誰も気づかない速度で落ちていきます。気づくのは、コンバージョンが動いた後です。

これは買う価値が最も高く、事前に評価するのが最も難しい能力です。どの会社もサポートを提供すると言うからです。違いは、こちらのチケットに応答する列と、自分たちのロードマップを持つパートナー——来四半期に何を変えるべきかについての見解を持って現れる相手——の間にあります。

求めるべき証拠は継続年数です。当社のGuardian Malaysiaとの取り組みは8年以上続いており、サイトのパフォーマンスを200%改善し、売上を10%押し上げました。どちらの数字も構築から生まれたものではありません。公開後もずっとプラットフォームに手を入れ続けたことから生まれたものであり、この種の結果はそれ以外の方法では起こりません。

1つのプロジェクトを超えて顧客を保持したことのないパートナーは、サポート等級に何と書いてあろうと、これを示せていません。

よくある質問

パートナーにはAdobe Commerceの経験が何年必要か。

年数だけでは弱い代理指標です。重要なのは、初回構築の繰り返しではなく、メジャーバージョンの移行と稼働中のカタログ再設計を含んでいるかどうかです。BridziaはAdobe Commerceに14年、Eコマースとデジタル全体では20年以上、100件を超えるプロジェクトの経験があります。

現地のパートナーと海外のパートナー、どちらを選ぶべきか。

判断はたいてい、難所がどこにあるかで決まります。決済、配送業者、SST、PDPA、二言語カタログといった現地の運用知識は、遠隔で身につけるのが難しく、間違えると高くつきます。深いプラットフォーム技術のほうが移転しやすい性質です。市場に拠点を持ちながら本物のプラットフォームの深さも備えたパートナーであれば、この二択は消えます。Bridziaはクアラルンプールを拠点にアジア全域で仕事をしています。

Adobe Commerceの構築にはどれくらいかかるのか。

標準的なBtoCの再構築で、連携の複雑さにより3〜5か月です。独自の見積機能や価格ロジックを伴うBtoB構築はさらに長くなります。連携の範囲を理解する前に期間を提示するパートナーは、店舗側だけを見積もって祈っています。

提案書には何を求めるべきか。

明記された前提、スコープ外の明示的な一覧、議論できる程度に詳しい連携の方針、そして公開後最初の90日に何が入るか。除外事項のない提案書は、考えられていません。

パートナーは認定を持っている必要があるか。

認定は個人のプラットフォーム知識を示すもので、フィルターとしては妥当ですが、納品実績の代わりにはなりません。誰がどの資格を持っているのか、その人たちが自社のプロジェクトに入るのかを尋ね、その答えを1年以上続いた案件からの推薦と組み合わせてください。

選定の進め方

提案の出来ではなく、証拠で候補を絞ってください。上の表にある5つの質問を各社に投げ、どれが具体的な答えを生み、どれが安心させるだけの答えを生むかを記録します。そのうえで、2年以上取引が続いている顧客からの推薦と、うまくいかなかったプロジェクトからの推薦を1件ずつ求めてください。有益なのは2本目の電話です。

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

Bridziaはクアラルンプールを拠点に、アジア各地の小売・FMCGブランド向けにAdobe Commerce（Magento）プラットフォームを構築・運用しています。選定を進めていて、本当の複雑さがどこにあるのかについて率直な評価がほしい方は、プロジェクトについてお聞かせください。