最初に結論を言います。WMS や OMS のアップグレードがこじれたとき、問題はシステム自体にあることはまずありません。問題は、プロジェクト計画に誰も入れなかったサードパーティ連携です。
2024 年、私は California 州 Ontario の 120,000 平方フィートの 3PL 施設で、教科書通りのアップグレード惨事が展開する様子を見ていました。その倉庫は、ほぼ 10 年間使い続けた WMS のバージョンから移行しようとしていました。プロジェクトチームは 3 か月をかけて準備しました。データ移行のリハーサル、ユーザー教育、ピッキングパスのウォークスルー、すべて揃えました。稼働日は月曜の 8 a.m.。9 時までには電話が鳴りやまなくなりました。運送業者のラベル発行 API が一斉に停止し、何千枚もの出荷ラベルが印刷キューに詰まり、ピッカーたちは RF スキャナーを手にしたまま何もできずに立ち尽くしていました。原因が分かってみれば、ほとんど馬鹿馬鹿しいものでした。新リリースで、出荷確定ペイロードのある項目が任意から必須に変わっていたのです。そして、運送業者の電子ラベルサービスと通信するミドルウェアは、5 年前にすでに退職したエンジニアが書いたものでした。アップグレード計画の誰も、そのコードの存在を知りませんでした。
どこを見ればいいか知っていれば、10 分で直せたはずです。
何かに触る前に棚卸しを作る
アップグレードが始まる前に、私はチームにまず一つだけやってもらいます。すべてのサードパーティ連携を、例外なく一枚の棚卸しシートに落とすことです。列はシンプルです。連携名、相手（どの運送業者か、どのマーケットプレイスか、どの ERP・TMS か）、プロトコル、コードの責任者、最後に正常に呼び出された日時、そして壊れたときに呼び出す相手。
「最後の正常呼び出し」の列こそ、死体が埋まっている場所です。書類上は生きているように見えて、実質死んでいる連携は山ほどあります。3 年前の小規模運送業者の返品コールバック、誰も見ていない財務向け夜間突合ファイル。アップグレード時に最も危険なのは、毎分動いている連携ではなく、半ば忘れ去られた連携です。誰も覚えていない、テスト計画にも入っていない、なのに午前 2 時のどこかの cron ジョブが今も呼び出しているのです。
この棚卸しを作る粗いが残酷なほど効くコツがあります。本番ログから過去 90 日間のアウトバウンド連携呼び出しを抜き出し、手作りの一覧と突き合わせるのです。突き合わないものは、ほぼ確実に見落としていたものです。Ontario の倉庫がポストモーテムでこの作業をやったところ、誰も覚えていない連携がさらに 3 件出てきました。
次に文書の問題があります。ベンダーの API 文書が実際の稼働コードと一致するのは、運が良くても半分くらいです。文書を信じず、パケットキャプチャを信じてください。アップグレード前に、核となる連携（ラベル発行、出荷確定コールバック、在庫同期）を選び、それぞれの本物のリクエスト・レスポンスを 1 サイクル、項目単位で記録します。丸一日もかからず、「文書には動くと書いてあったのに」という驚きの大部分を消せます。
単発切替に倉庫を賭けない
連携互換性について、私の立場はシンプルです。一斉切替（big-bang cutover）は絶対に信用しない。いちばん成熟した WMS でも、メジャーリリースで項目ルールや認証方式、レスポンス形式を変えることがあります。リリースノートに「後方互換性あり」と書いてあっても、自分でテストするまでは営業文句とみなします。
信頼できるやり方は三つあり、どれを抜かしてもトラブルのもとです。サンドボックスでの連携テスト、段階的ロールアウト、そして本当に動くロールバック計画です。
サンドボックスでのテストとは、テスト環境を 2 回クリックすることではありません。本物の業務トラフィックを再生する必要があります。本番の注文を取り、機密データを取り除き、丸一日の業務量をサンドボックスに流し込むのです。ラベルが印刷されるか、ERP コールバックが成功するか、追跡番号がマーケットプレイスに同期されるかを見ます。トラフィック量が少なすぎると、問題は隠れたままです。私は少なくとも丸一日分の再生量を求めます。ピークシーズンの倉庫ならその 2 倍です。
段階的ロールアウトは、神経と忍耐の試しです。注文量の 10% を新バージョンに流し、半日様子を見てから増やしていきます。のろいのが嫌いな人もいます。「一晩の切り替えウィンドウで全部切替えたほうがすっきりする」って。すっきりするのは、連携が壊れて建物全体が止まるまでです。段階的ロールアウトの余分な手間は、施設全体の全面停止 1 回に比べれば何でもありません。
そして、ほとんどのロールバック計画は絵に描いた餅です。本物は三つの問いに答えます。データはどう戻すのか（新バージョンが作った文書を旧バージョンが受け入れるのか）、連携はどう戻すのか（切り戻したときに相手方がコールバックを二重発射しないか）、誰がそれを決められるのか（午前 3 時に何かがおかしいと気づいたとき、三つの承認レイヤーを経ずに「ロールバック」と言える権限は誰にあるのか）。三つとも答えられなければ、その計画は紙です。
稼働当日は、サーバーの CPU を見るな。連携のバイタルサインを見てください。核となる連携ごとの成功率、応答時間、エラーコード分布です。成功率のシンプルなアラート一つで、連携障害の 10 件中 9 件は、最初のユーザー苦情が届くよりずっと前に検知できます。
そして、ほとんどのチームが飛ばす部分が来ます。稼働後の 1 週間の観察ウィンドウです。連携障害の半分は遅れてやってきます。月末の財務突合バッチは月に 1 回しか走りません。アップグレードの数週間後まで発火せず、アップグレード後初回で失敗するかもしれない。マーケットプレイスの在庫同期は通常量では問題なく見えて、プロモーションでトラフィックが急増したときだけ壊れる。私のルールはシンプルです。稼働後の最初の 1 週間は、毎朝 10 分だけ連携成功率レポートを確認し、頻度の低いジョブに特に注意する。ちゃんと走ったか、エラーしなかったか。2 週目は隔日に緩めます。問題のない月を過ぎて初めて、そのアップグレードを本当に完了と呼びます。
受入基準はアップグレードの後にではなく、前に書きなさい。私の基準は三つの厳しいラインです。核となる連携の成功率がアップグレード前週の平均以上であること、ラベル印刷から出荷確定までのエンドツーエンドの流れに目立った遅延がないこと、そして最初の 1 週間で連携障害による手作業のやり直しがゼロであること。どれか一つでも外れたら、まだ片付いていないことがある。シャンパンはまだ抜くな。
最後に、言っておく価値のあるトレードオフがもう一つあります。一部のレガシー連携は、また継ぎ接ぎするのではなく、アップグレードのときに書き直すべきです。歴史的修正が七重に積まれたミドルウェアは、誰も触りたがりません。アップグレードは、その技術的負債を一括で返済する、めったにない正当な言い訳です。プロジェクトのスケジュールに 2〜3 週間余分にかかりますが、安眠できる夜を何年も買えます。長期の視点で計算してください。
明日からできることを一つ。WMS の管理コンソールにログインし、過去 90 日間に呼び出された外部連携をすべてエクスポートしてください。手元の連携文書と突き合わせます。一致しないものが、次のアップグレードで爆発する可能性がいちばん高いポイントです。名前を書き留めてください。それがあなたの互換性チェックリストの第 1 行です。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
