まず結論から言います。新倉庫の立ち上げでは、連携テストの時間はいくらあっても足りません。問題は、その時間を本番移行の前に使うか、後に使うかだけです。後に使うとは、カスタマーサービスの電話が鳴りやまない中で使うということです。滑走路の8割をスロット配置のレイアウトや設備の試運転に使い、連携テストに残されたのはたった1週間、というプロジェクトを私は何度も見てきました。そして移行当日、WMSベンダーも運送会社もマーケットプレイスも責任をなすりつけ合う中、数百個の荷物が配送ラベルのないまま梱包ステーションに滞留します。
サンドボックスは飾りではない：テストの前に環境を整合させよ
2024年、私は本番移行の1週間前に連携テストのレビューのため、カリフォルニア州オンタリオにある120,000平方フィートのグリーンフィールド（新規立地）倉庫に足を運びました。サンドボックスは素晴らしく見えました。注文を入れればラベルが出て、出荷が確定する——経営陣向けの完璧なデモでした。本番当日は違う物語が語られました。サンドボックスのラベルテンプレートは、本番に設定されたものと同じではありませんでした。本番のテンプレートには追跡番号フィールドに余分なチェックデジット（検査数字）のルールが入っていたのです。ラベルは印刷されるものの、スキャナーはそれを拒否。ソーターの投入口に荷物が山積みになり、30分間ライン全体が停止しました。
教訓は地味で具体的です。サンドボックスと本番の設定は、項目ごとに一致させなければなりません。ラベルテンプレート、プリンターの機種とドライバー、運送会社の契約、サーバーのタイムゾーンです。特に運送会社の契約に注意してください。テスト用と本番用の認証情報は、権限が異なることがよくあります。料金比較とラベル印刷はできるが、追跡イベントは取得できないテスト用アカウントを見たことがあります。その結果、追跡Webhookの経路は移行当日まで一度もテストされないままになっていました。不一致はすべて、移行当日の事故として待機しています。テスト開始前に、サンドボックス対本番の2列のチェックリストを作り、すべての行にチェックが入るまで開始しないでください。
サンドボックスについてもう一つ。おもちゃのようなデータではなく、本番に近い形のデータを投入してください。1個ずつの5 SKUでは何も見つかりません。数千SKU、実際の容積重量、実際に使う運送会社のサービスコード、アパートの部屋番号・私書箱・たまに誤字のある住所をロードしてください。私が見てきた連携バグの多くはロジックの誤りではなく、データ形状の誤りでした。おもちゃのデータはそれらをすべて隠してしまいます。
そしてテスト初日には、関係3者がそれぞれ実行中のAPIバージョンを書き出してもらってください。運送会社のAPIドキュメントは年に3〜4回改訂され、フィールドは予告なく変更されます。サンドボックスでテストしたバージョンが、本番で動いているバージョンと同じとは限りません。私はキックオフの場で全員に本番のバージョン番号を書面で確認させています。後々の責任のなすりつけ合いを1週間分、節約できます。
ハッピーパスではなく、厄介なケースをテストせよ
正常な注文は誰でもテストします。あなたを殺すのは例外の注文です。だからテスト計画は例外を中心に組み立ててください。住所の欠落や形式不正、重量超過・サイズ超過の荷物、存在しないSKU、マイナス在庫、ピッキング開始後のキャンセル、複数のカートンに分割される1注文、1つにまとめられる複数注文です。それぞれ最低3回ずつ実行し、3つのシステム（WMS・マーケットプレイス・運送会社）すべてで注文ステータスが一致することを確認してください。典型的な失敗は3者間の食い違いです。マーケットプレイスは「出荷済み」、WMSはまだ「ピッキング待ち」、カスタマーサービスは怒りのメールで初めて知る、というパターンです。
ERPも忘れないでください。購買発注の受領フロー（ASN受信、入庫計上、在庫スナップショットの逆方向同期）には専用のテストパスが必要です。万年不動の典型例は、期首と期末の在庫の不一致です。ERPは500個を受領したと思っているのに、WMSは480個しか数えていない。月末締めが法医学的な作業になるまで、誰も突合しません。サンドボックスで受領から棚卸までの一連のサイクルを回し、移行の「後」ではなく「前」に数値を突合してください。
ほぼ毎回スキップされるカテゴリーが2つあります。1つ目はピーク時のボリュームの注文です。ブラックフライデーの1週間前に、1日20,000件の注文をスクリプトでサンドボックスに流し込み、レート制限とメッセージキューが耐えるか見てください。テストでは1秒10件は問題なく見えますが、ピーク時の1秒200件は、準備不足のAPIをなぎ倒します。私はこれを何度も見てきました。2つ目は返品です。10件中9件の新規倉庫は、移行前にサンドボックスで完全な返品を通していません。返品の経路はまったく別のチェーンです。マーケットプレイスの返品承認、WMSでの受領、検品、プットアウェイ、在庫のマーケットプレイスへの書き戻しです。1つでもリンクが壊れれば、返品は宙ぶらりんになります。移行後の最初の1週間の返品が、テストしなかったすべての隙間を暴き出すでしょう。
テストの各日は突合で締めくくってください。3つのシステム（マーケットプレイス・WMS・運送会社）から注文ステータスをエクスポートし、同じ注文番号のバッチがすべての場所で一貫した状態を示すことを確認します。突合スクリプトは初日に書き、自動で実行してください。目視で確認してはいけません。不一致はすべて、明日の最優先バグです。
切り替え当日：進む計画の前に、戻る計画を立てよ
移行前に、ロールバックのラインを書面で定義してください。切り替えから2時間以内に出庫精度が設定した下限を下回った場合、またはAPIのエラー率がしきい値を超えた場合は、直ちに旧システムまたは手動受注に戻します。作戦室の壁に貼り出してください。「様子を見ましょう」などと曖昧にしてはいけません。その場では、その判断を下す余裕は誰にもありません。事前に書いたルールを実行するだけです。
切り替え当日は旧システムを温存してください。旧と新を半日〜1日並行稼働させます。注文は両方に流れ、出庫は旧システムから行い、新システムはシャドー検証を回します。具体的には、新システムが印刷する最初の50枚のラベルを、旧システムの出力と1行ずつ比較します。住所、サービスレベル、追跡番号です。本番ボリュームを任せる前に、です。並行稼働は1日分の労力を倍にします。並行稼働を省くということは、移行当日の数千件の注文を「希望」に賭けるということです。割に合わない賭けです。
そして夜勤の人員を配置してください。連携障害は、切り替え後の最初の深夜時間帯に集中します。開発、倉庫スーパーバイザー、カスタマーサービスのそれぞれに、現地か待機の担当者を1名ずつ、1つのグループチャットに集め、連絡先をピン留めします。障害が起きてから人を探して電話をかけ回してはいけません。
あなたのサンドボックスが完全な返品（マーケットプレイスでの返品開始、WMSでの受領、検品、プットアウェイ、在庫の書き戻し）をエンドツーエンドで回したのはいつですか？日付を答えられないなら、切り替えを1週間延期してください。連携テストに「ほぼ十分」はありません。本番は、あなたが手を抜いた隅々を、移行当日に1つずつ見つけ出します。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
