マレーシアでAdobe Commerceストアをより早く公開する方法

Adobe Commerceの公開が遅れる原因が開発速度であることは、めったにありません。遅らせているのは、初日から決められたのに3か月目に決まった判断です。どの決済手段を載せるのか、在庫は誰が持つのか、カタログは二言語なのか、ERPにとっての「完了」とは何か。

標準的なBtoCの再構築は、連携の複雑さにより3〜5か月です。独自の見積機能と価格ロジックを伴うBtoB構築はさらに長くなります。この幅の短いほうに着地するチームは、コードを速く書いているわけではありません。遅い判断が少ないのです。以下では、時間が実際にどこへ消えるのか、そして翌年をほどく作業に費やすことなく期間を縮めるものは何かを扱います。

速さは、速く働くことではなくスコープから生まれる

最初のリリースは、実在する顧客から実際の注文を受けられ、実在する自社のチームが運用できる最小のものであるべきです。試作ではありません。ロードマップが止まったとしても、半年そのまま運用して構わないと思える店舗です。

この捉え方は、どんなツールの選択よりも期間に効きます。優先順位の議論を、たった1つの試験に変えるからです。それは顧客が買うことを妨げるか、運用担当が出荷することを妨げるか。最初のリリースを膨らませるものの大半は、この試験に落ちます。

右の列は永久に後回しになるわけではありません。その多くは公開後8週間の予定に入ります。そのときには、狙いを定めるための実データが手に入っています。公開前の推測より、ずっと良い入力です。

計画に書き込む価値のあるスコープのルールが2つあります。属性モデルとストアビューの構造は、コンテンツがそうでなくても初回リリースの判断です。 この2つだけは、後から変えるのが本当に高くつくからです。そして第三者の協力が必要なものは、最初に着手します。 決済ゲートウェイのアカウント開設や配送業者との連携は、自社チームがどれだけ速く動こうと、他社の順番待ちで何週間も止まりうるからです。

プラットフォームがすでに持っているものを使う

Adobe Commerceは大量の標準機能を備えて届きます。そして初回構築における独自開発のかなりの割合は、誰も確認しなかったために、プラットフォームがすでに持っているものを少し違うかたちで作り直しているだけです。

標準の顧客グループ、階層価格とカタログ価格のルール、カートの価格ルール、そしてBtoB向けの機能群は、大半の商習慣をコードなしでカバーします。規律とは、独自モジュールの要件を固める前に「これは設定で実現できるか」を必ず問うこと、そして要望どおりぴったりの作り込みより、要望の9割を満たす設定を受け入れることです。初回リリースにおいては、この取引はほぼ常に正解です。

拡張機能については逆の勘が要ります。1つ入れるごとに、他社のリリース時期とバージョンアップの規律に依存することになります。急いで組み上げた拡張機能の積み重ねは、1年半後にやってくるバージョンアップの痛みの最も一般的な原因です。数を絞り、よく保守され、本当に必要なものだけを。

インフラについては、実務上の問いは、構築期間中にホスティング、スケーリング、環境管理を誰が担うかです。Adobeのマネージドクラウドは、商業的なコストと引き換えにその作業をクリティカルパスから外します。自社管理のインフラは費用が安く、環境構築、CI/CD、スケーリング設定を自分たちの時間軸に載せます。どちらも速くなりえます。確実に遅いのは、決めるのが遅いことです。

フロントエンドの方針も同じ論理です。ヘッドレスやPWAのフロントエンドは、実際の利点を持つ正当なアーキテクチャであり、そして初回リリースを長くします。市場投入の速さが本当に効いてくる制約なら、それは第2フェーズの判断です。

ローカライズはUATではなく、最初に決める

以下の項目はどれも、2週目には安く、3か月目には高くつきます。まとめて、マレーシアでの公開が遅れる最も一般的な原因です。

決済。 銀行振込のFPX、GrabPayやTouch 'n Goを含む電子ウォレット、そしてカード。並行して2つが走ります。技術的な連携と、加盟店審査です。後者はあなたの予定表の上にはありません。構築より先に書類を出してください。表示順は意識して決めてください。レイアウトではなく、コンバージョンの判断です。

税。 SSTの扱いが、価格を税込で表示するか税別で表示するか、請求書をどう発行するか、注文合計がどう見えるかを決めます。これはカタログ、カート、ERPのマッピング、財務の帳票へと波及するので、後から切り替える設定項目ではありません。

データ保護。 2010年個人データ保護法は、同意、収集、保管、開示請求を定めています。アカウント作成、マーケティングのオプトインの文言、Cookieと解析の扱い、そしてプライバシー関連の文書のかたちを決めます。公開後に同意の仕組みを作り直すことは、1か月かけて設定したばかりの解析をやり直すことを意味します。

言語。 英語とマレー語の二言語対応は、翻訳作業である前にデータモデルの判断です。第2言語の公開が後になるとしても、ストアビューと翻訳可能な属性は初回リリースで構造化してください。逆の順序でやると、カタログの移行が発生します。

配送。 配送業者の選定、料金体系、東マレーシアのカバー範囲とリードタイム、そして購入手続きでサイトが約束する内容。不正確なお届けの約束は、初日からの問い合わせコストです。

モバイル。 マレーシアの人々の64%がモバイル端末で購入している以上、リリースが評価されるのはモバイル上です。これは最後の確認工程ではなく、作業の順序そのものを決めるべき事実です。

現実の制約下でも、判断が済んでいれば速く動けます。当社はクリック&コレクト型のドライブスルー店舗Mydin Expressを、マレーシアの活動制限令（MCO）下で1週間で構築・公開しました。オンラインで注文し、選んだ店舗で2〜3時間後に受け取れる仕組みです。これは上記のどれかを飛ばした結果ではありません。異例なほど絞ったスコープと、即座に下された判断の結果です。

クリティカルパスは連携

Adobe Commerceの構築の多くにおいて、リスクは店舗側ではありません。ERP、POS、マーケットプレイスとの接続がリスクであり、しかもそれは最も遅くに発見されがちな作業です。

連携を先に検証してください。最初の数週間で、端から端まで通る細い1本を通す。ERPで作成した1商品が店舗に正しく現れ、1件の注文が正しい伝票として着地する。これで、本当に高くつく驚きが、まだ設計で回避できる時期に表に出ます。店舗を先に作って最後に連携するのは、公開日が遅れる最も一般的な原因です。

早めに固めるべき判断は次のとおりです。どれも波及するからです。

• ERPとプラットフォームの間の、項目ごとの所有権を文書化する。
• 販売可能在庫を明示的な計算式とし、倉庫の生の数量ではなくERP側で算出する。
• 1つの価格項目に書き込むのは1つだけとし、販促はプラットフォーム側で計算して書き戻さない。
• 安定した参照番号をキーとする冪等な受注送信により、再送で受注伝票が重複しないようにする。
• オブジェクトごとの連携頻度。受注と在庫移動はイベント、カタログと価格の全件ロードはスケジュール実行。

標準コネクタがマッピングに本当に適合するなら、そのほうが速く、使う価値があります。ERPが10年カスタマイズされてきた場合、コネクタはたいてい7割まで運んでくれて、そこから先が専用の連携を作るより高くつきます。自分がどちらの状況にいるのかは、UATではなく要件定義の段階で判断してください。詳細はERP連携のベストプラクティスに、具体的な失敗のパターンはMagentoとSAPの連携で、実際に壊れるのはどこかにあります。

マーケットプレイスは別の層であり、初回リリースを膨らませることを許すべきではありません。Shopee、Lazada、TikTok Shopが重要なら、自社ECの後ろに順序づけて、意識して解いてください。Bridziaのマーケットプレイス同期技術WOW Syncは、まさにそのために存在します。

分割して出す

ステージング環境を用意し、節目ごとにレビューするスプリント方式の進行は、ここでは手法の好みではありません。3か月の構築が11週目に問題を露呈するのを防ぐためのものです。当社の4段階モデル——要件定義とアーキテクチャ、構築、公開、そして運用と拡張——は、最後ではなく全期間を通じてレビュー可能な成果物をお客様の前に置きます。

実際に数週間を節約する実務は次のとおりです。

• 環境とデプロイ自動化を初日に。 手作業のデプロイは毎週数時間を奪い、最も緊張度の高い公開日を生みます。
• カタログデータの実質的な締め切り日を、売り場担当と合意すること。カタログの準備は、コードより多くの公開日を遅らせます。
• 担当者を指名し、期間を固定したUAT。 期限を切らないUATは、残った時間をすべて使い切ります。
• 段階的な公開と切り戻し計画。 トラフィックの性質が許すなら、限定的な対象へのソフトローンチも。
• 誰かが見ていられる日に公開する。 金曜は避け、キャンペーン前日も避けます。

よくある質問

Adobe Commerceストアの公開にはどれくらいかかるのか。

標準的なBtoCの再構築は、連携の複雑さにより3〜5か月です。独自の見積機能と価格ロジックを伴うBtoB構築はさらに長くなります。ばらつきはほぼすべて、連携の範囲とカタログの準備状況にあり、店舗側の開発にはありません。

後悔せずに最も早く公開する方法は。

初回リリースを、顧客が買えて運用担当が出荷できる範囲に絞る。ただし、後から変えるのが高くつく判断——属性モデル、ストアビュー、ERPとの項目ごとの所有権、税の扱い——はきちんと前倒しで決める。速さはコンテンツと機能を先送りすることから生まれるのであって、アーキテクチャを先送りすることからは決して生まれません。

早く公開するためにAdobe Commerce Cloudを使うべきか。

ホスティング、スケーリング、環境管理をクリティカルパスから外してくれるので、そうでなければ自社チームが担うことになる場合には有効です。ただし、カタログの準備、連携、各種審査は短くなりません。期間の大半が消えているのはそこです。

Adobe Commerceの公開が遅れる最も多い原因は。

当社の経験では、連携の発見が遅いこと、カタログデータが準備できていないこと、決済ゲートウェイの審査着手が遅すぎること、そして税・言語・お届けの約束といったローカライズの判断をUATまで先送りすることです。

先に公開して、マーケットプレイスは後から追加できるか。

できますし、たいていそうすべきです。マーケットプレイスの同期はそれ自体が1つの層であり、固有の失敗のパターンを持ちます。初回リリースに加えることは、1か月後にも取れる売上のために、スコープとリスクの両方を膨らませることです。

要点

早く決め、狭く絞り、連携を先に検証し、レビュー可能な単位で出す。早く公開するチームは、アーキテクチャで手を抜いたチームではありません。決着した問いを蒸し返すのをやめたチームです。

BridziaはクアラルンプールからAdobe Commerce（Magento）に14年取り組み、アジア各地の小売・FMCGブランド向けに100件を超えるプロジェクトを納めてきました。Adobe Commerce（Magento）の公開日が決まっていて、それが到達可能かどうかの率直な見立てがほしい方は、プロジェクトについてお聞かせください。