Shopify Plus で大規模ECを動かし続けるために、
私たちが積み上げてきたこと

大規模ECでは、Shopify、ERP、WMS、OMS、決済、店舗システムが噛み合って動くため、注文から在庫引当、決済、出荷までのデータ整合性が崩れやすくなります。重要なのは、すべてをShopifyへ集約することではなく、各システムが持つ責任範囲と処理順序を決めることです。フラッグシップは、Shopify Plusの標準機能と独自開発の境界を定め、基幹・在庫・決済を含むシステム全体を設計します。

既存システムの機能をそのままShopifyへ移すことが目的ではありません。業務上必要な要件を見極めながら、Shopify標準に任せる部分と、独自に設計・開発する部分を分けます。旧システムの仕様をすべて持ち込めばShopifyの利点を損ない、逆に標準機能へ寄せすぎれば現場の業務が成立しないことがあります。この境界を設計することが、大規模ECのアーキテクチャ設計の起点です。

独自開発する領域では、注文・在庫・決済の処理順序とデータ整合性を設計します。注文が作成され、在庫が引き当てられ、決済が出荷へ連携されるまでを、複数システムをまたいでもデータが矛盾しない構成が必要です。WMS・OMS・ERP・販売管理システムとの連携についても、データ連携の設計からコネクタ開発まで自社で行います。

全国に実店舗を展開するアパレルブランドの Shopify Plus 構築では、店舗在庫のリアルタイム表示と店舗受取（BOPIS）を Shopify の公式提供に先行して独自実装し、デザイン着手からリリースまで4ヶ月で完了しました。

対応領域

• Shopify Plusのアーキテクチャ設計と、標準機能・独自開発の役割分担
• 注文・在庫・決済のシーケンス設計とデータ整合性の担保
• WMS・OMS・ERP・販売管理システムとのデータ連携・コネクタ開発
• 店舗在庫のリアルタイム表示・店舗受取（BOPIS）の実装
• 大規模セール・アクセス集中を想定した負荷試験と耐性設計

大規模ECの移行が難しいのは、画面や商品データだけでなく、受注後の業務、基幹連携、顧客アカウント、既存URLを引き継ぐ必要があるからです。フラッグシップは、現行システムをそのまま再現するのではなく、止められない業務を特定し、Shopify Plusの標準機能を活かした構成へ再設計します。

ECサイトのリニューアルやカート乗り換えでは、まず現行業務を棚卸しし、事業を止められない処理や連携を特定します。ecbeing、Salesforce Commerce Cloud（SFCC）、EC-CUBE などの既存ECプラットフォームからの移行に加え、Microsoft Access に依存していた業務の再設計・移行にも対応してきました。

移行は一度にすべてを切り替えるとは限りません。商品閲覧、カート、チェックアウト、決済、注文作成といった取引の根幹を先に成立させる一方、ロイヤルティや高度なマーケティング連携などは段階的に移行することがあります。何を初回リリースに含め、何を後続フェーズへ回すかを決めることが、移行設計の重要な判断です。

顧客・注文・商品などのデータ移行と、既存の基幹システム連携も同じプロジェクトの中で扱います。画面だけShopifyへ置き換えても、受注後の業務やデータ連携が維持できなければ移行は完了しません。

近年は、従来型のお客様アカウントから新カスタマーアカウントへの移行が増えています。ログイン方式がパスワードからメールで受け取るワンタイムコードへ変わるため、旧アカウントの廃止を含めた切り替え設計が必要です。実際に、深夜のメンテナンスを設けず、アクセスが落ち着く日中にサービスを止めず切り替えた案件もあります。

対応領域

• 現行業務の棚卸しとShopify Plusに合わせたECアーキテクチャの再設計
• 商品閲覧・カート・チェックアウト・決済・注文作成を優先する段階的な移行計画
• 顧客・注文・商品データの移行
• ecbeing・Salesforce Commerce Cloud・EC-CUBE など既存ECからの Shopify 移行
• 従来型のお客様アカウントから新カスタマーアカウントへの切り替え

フラッグシップは、エンタープライズITの進め方（要件定義、セキュリティ審査、複数ベンダーとの並行作業、カットオーバー）を理解し、大規模ソフトウェア開発をプロジェクトとして止めずに進める体制を持つ組織です。

特定の担当者に依存しないプロジェクトマネジメントの仕組みで進めます。要件と判断の記録を残し、担当が替わっても前提を引き継げるようにしています。

保守運用とエンハンス開発を、受注から6年以上続けている共創体制があります。基幹システムやPOSのリプレイスと複数ベンダーの作業が並行するプロジェクトでも、周辺システムとの調整を含めてカットオーバーまで支援します。

向き合ってきたのは、エンドユーザー向けのサービスではなく、事業会社のお客様です。ブランドと製品、業務を理解し、開発に着手する前に「何を作るべきか」を一緒に決めることを起点にしています。一度頓挫した案件を、業務理解ベースで仕切り直し、段階的にローンチした実績もあります。

対応領域

• エンタープライズ案件の要件定義・セキュリティ審査への対応
• 複数ベンダーと並行するプロジェクトの進行管理とカットオーバー
• 特定の担当者に依存しないプロジェクトマネジメント
• リリース後の保守運用・エンハンス開発（スクラム型の伴走）
• 開発前のビジネス理解・業務理解

越境ECは、多言語・多通貨に対応するだけでは成立しません。商品のHSコードや原産国に基づく関税・輸入税の計算、購入時の表示・徴収、配送会社との連携、出荷拠点、在庫、返品までが、一つの取引の中でつながっています。フラッグシップは、Shopify Markets や Global-e を活用し、DDP（Delivered Duty Paid：関税・輸入税を購入時に提示・徴収し、販売者側の責任で納付・配送する方式）を含む関税対応、海外配送、複数拠点在庫までを一体で設計します。

設計の起点は、関税と配送の責任をどこで持つかを決めることです。DDPで購入時に徴収するのか、着荷時に受取人が支払う方式にするのか。どの拠点の在庫から出荷し、返品はどこへ戻すのか。この判断が、チェックアウトの表示、配送会社との連携、在庫の引き当て順序、会計処理まで決めます。Shopify Markets による国別のローカライズ（言語・通貨・税率）と、Global-e などの越境ECサービスとの連携は、その判断のうえに載せます。

海外本社が管理するグローバル展開システムの上に、日本固有の業務要件を実装する案件も同じ考え方で進めます。裾上げ、ギフトラッピング、割引制約、フリガナといった要件を、展開基盤を壊さずに載せる設計と、保守ベンダーへのナレッジ移管・技術リードまで担います。フラッグシップ社内の公用語は英語で、海外本社との要件定義・プロジェクト推進には直接対応します。

海外向けに販売する大手音楽会社の越境ECでは国別ローカライズと複数拠点在庫の一元管理・自動出荷を、海外販売を展開する日本発のモードブランドでは在庫システムと連携した多言語・多通貨対応の越境ECを、それぞれ構築しました。

対応領域

• Shopify Markets による国別ローカライズ（言語・通貨・税率）の設計
• HSコード・原産国に基づく関税・輸入税の計算と、DDPによる購入時徴収・海外配送の設計
• 複数拠点在庫の一元管理と自動出荷、返品を含む物流フローの設計
• Global-e など越境ECサービスとの連携
• グローバル展開システム上での日本固有要件の実装と、海外本社との英語での要件定義