自動化倉庫のプロジェクトで、ここ数年何度も目にしてきた奇妙な儀式がある。WMSベンダーとWESベンダーが同じ会議テーブルを囲む。インターフェースの話、ハードウェアの話、何もかも和やか——誰かが「タスク割り当て」と言うまでは。その瞬間、両者は互いに見つめ合い、目の奥の考えは読み取れる。それはお前の仕事だ。
会議の後、クライアントは必ず私を脇に引っ張る。「老米、これって結局誰の責任なんだ？」私はたいてい自分の質問で返す。「契約書に書いてありますか？」十中八九、答えはノーだ。その沈黙こそがまさに問題なのだ。ウェーブリリース、ホットピック、例外処理——誰も引き受けたがらない三つの仕事であり、自動化プロジェクトが議論の場と化す三つの場所だ。
ウェーブリリース：WMSが曲を書き、WESがテンポを握る
教科書通りの話はきれいだ。WMSは優先度とキャリアのカットオフ時刻に基づいて受注をウェーブにまとめ、ひとつずつリリースし、WESが実行する。片方が戦略を立て、片方が作業をする。
だがAMRやシャトルが登場し、話はややこしくなった。WESベンダーは言う。各ロボットのリアルタイムの状態も、各通路の混雑も見えるのだから、ウェーブを動的に組み立ててリリースでき、WMSの硬直的な定時リリースよりずっと効率的だと。WMSベンダーの反論はこうだ。ウェーブは受注戦略であり、フルフィルメントの約束だ。設備ベンダーが決めていいものではない。
このケンカを、私は2023年に目の当たりにした。南カリフォルニアのインランド・エンパイアにあるEコマースのフルフィルメントセンターだ——200,000平方フィートを超える建物で、現場には40〜50台のAMR。WMSはキャリアのカットオフに合わせて20分ごとにウェーブをリリースした。WESは追いつけない。ロボットが前のウェーブをまだ噛み砕いているところに次のウェーブが落ちてくる。作業者は通路でタスクを待って立ち尽くし、ロボットは空走りする。WMSチームは自分たちのウェーブロジックは正しいと言い、WESチームはリリースのペースが無理だと言う。クライアントは間に座り——どちらももっともに聞こえる。
私の結論はこうだ。ウェーブ戦略はWMSのもの——グルーピングのルール、優先度のロジック、それは受注管理とフルフィルメントだ。だがリリースのペースはWESと共有しなければならない。設備が実際にどれだけ飲み込めるかを知っているのは実行層だけだからだ。実務ではここに単独の所有者はいない、共同所有だけがあり、両方の契約書に書かなければならない。WMSがウェーブ戦略の設定を所有し、WESがリリースのペースを所有し、インターフェース契約には「WMSはウェーブを公開し、WESは作業を受け入れるリアルタイムのキャパシティを公開する」と書く。誰のフィールドか、誰のロジックか——紙の上に。
ホットピック：現場で一番熱いジャガイモ
ホットピックほど激しく争われるものはない。カスタマーサービスから電話が入り、キーアカウントの緊急受注だ、2時間で出荷しなければならない。WMSは最優先フラグを立ててWESに押し込む。WESの営業はデモで動的な優先付けを約束した。稼働してみると、シーケンス済みのタスク計画に1件の受注を差し込むにはルートを再計算しなければならず、現場全体の効率が落ちる。WMSは言う。「優先度は付けた、あとはお前の仕事だ」。WESは言う。「付けたのはあんただが、実行できない」。
2024年、オハイオの3PL拠点では、ピークシーズンにホットピックが1日数十件、最悪の時間帯はほぼ1時間に1件のペースで来た。掘り下げてみると、WESには緊急タスク専用のレーンがまったくなかった。すべてのホットピックが通常の再シーケンスキューを通り、ソルバーはどんどん遅くなり、通常の受注まで引きずられた。クライアントは激怒した。「売った話と違うじゃないか」。
解決策を三つの譲れない条件に煮詰めた。ホットピックの権限はWMSにある——誰が前倒しできるのか、1日に何回までか。クォータがなければならないし、クォータ超過は手動承認を通す。クォータなしの前倒しは確実な惨事だ。WESは無制限の割り込みに溺れ、それは物理であってソフトウェアのバグではない。ホットピックの実行はWESにある——キャパシティを予約するか専用レーンを作り、緊急タスクが全体のシーケンスを壊さないようにする。そしてSLAは契約書に入れる——ホットピックの発行から実行開始まで、合意した分数以内にする。数字は交渉できる。数字を持つこと自体は交渉できない。
例外処理：賢いシステムがとぼけるところ
三つ目は例外だ。ロボットが立ち往生する、ラベルが読めない、重量チェックが落ちる——タスクは途中で死ぬ。誰が拾うのか。誰が決めるのか。リトライするのか、人間に回すのか。WMSベンダーの言い分は「我々は上位システムだ。WESがまず例外を処理し、無理なものをエスカレーションすべきだ」。WESベンダーの言い分は「設備を動かすのは我々だ。受注そのものの異常みたいなビジネス例外——それはWMSの判断だ」。
どちらももっともに聞こえる。実際には、どちらも引き受けない例外はシステムの中でただ消えてなくなる。あるプロジェクトでは、稼働後最初の3か月間、WESは例外を報告したつもりで、WMSは受け取った覚えがなかった。根本原因の特定に1週間以上かかり、原因は恥ずかしいほど単純だった。WESが送っていた例外コードがWMSの辞書に存在せず、インターフェースが黙って捨てていたのだ。段ボールがコンベアの上で2日間放置された。誰も知らなかった。
だから例外は二層に分けなければならない。設備層の例外——立ち往生したロボット、切れた接続、読めないスキャン——はWESのものだ。まず自己修復を試みなければならない。リトライし、リルートし、それでもダメならエスカレーションする。ビジネス層の例外——キャンセルされた受注、在庫の不一致——はWMSのものだ。そして二層の間には、例外コードの対応表がひとつだけなければならない。両ベンダーが署名し、統合テストで1行ずつテストする。ほとんどのプロジェクトにこの表はない。インターフェースがつながったことをテストして勝利宣言する。覚えておいてほしい。インターフェースがつながることと、例外フローが動くことは別物だ。
真の根本原因——そしてそれを存在しなくする方法
ここまでくれば根本原因はおそらく明らかだろう。だが名前を挙げさせてほしい。名前を挙げることこそが、それを契約可能にするのだから。
まず、WESとは実際何なのかを誰も定義したことがないという事実から始めよう。10年前はWMSがすべてを動かし、設備は愚鈍だった。その後AMRやシャトルが頭脳を持ち、それらを管理するためにWESが生まれた。だが業界はWESの境界を標準化しなかった——あるベンダーのWESは実質小さなWMSであり、別のベンダーのそれはかろうじてデバイススケジューラだ。選定のときは全入札者から同じものを買っているつもりになる。違うのだ。デモはどれも同じに見えるが、契約書は二つの異なる生き物を描いている。
そしてさらに深い問題がある。両者とも「最適化」しているが、最適化しているものが違うのだ。WMSはフルフィルメントを最適化する——定時出荷率、カットオフ遵守。WESは設備効率を最適化する——ロボット稼働率、通路スループット。フルフィルメントは速さを求め、設備は滑らかさを求める。本質的に緊張関係にあり、ウェーブもホットピックも例外も、まさにその二つの目的が衝突する場所だ。だから指の差し合いは態度の問題ではない。目的関数が本当に食い違っているのだ。
そして最も害が大きいのは、契約書に書いていないことだ。WMSの作業明細書（SOW）には「ベンダーはタスク割り当てモジュールの責任を負う」と書いてある。WESの作業明細書にも同じ一文が書いてある。重なる境界＋曖昧な文言＝議論への常時招待状だ。
ではどうやって契約書に書き込むのか。私がクライアントに渡すテンプレートはシンプルな三列の表だ。項目、所有者、共同所有者。少なくとも八つの項目をカバーする。ウェーブ戦略の定義、ウェーブリリースのペース、ホットピックの権限とクォータ、ホットピックの実行レーン、設備例外の自己修復、ビジネス例外の裁定、例外コード辞書の保守、インターフェースフィールドの所有権。各項目に所有者はちょうど一人。「支援」や「協力」は割り当てとして認めない。
さらにいくつかの厳しい条項も入れさせる。受け入れ基準の明文化——例外コード表を1行ずつテストして合格率100％、ホットピックの発行から実行開始まで5分以内（数字は交渉できるが、数字を持つことは交渉できない）。例外辞書の保守責任を名指しの人物に割り当て、新しいコードは48時間以内に相手側へ同期する。そして何度か痛い目に遭ってから加え、一度も外したことのない切り分け条項。境界紛争はクライアントが48時間以内に裁定し、議論中もどちらの側も作業を止めない。
あの会議室に戻ろう。次にWMSベンダーとWESベンダーが同席してタスク割り当てをめぐって互いに見つめ合ったら、私はたいてい遮って言う。見つめ合うのはやめて、契約書を開いて、そのページとその行を探して。境界は会議で議論して決まるものではない。書くことで決まるのだ。書き下せば両者は自分の仕事がわかる。曖昧なままにすれば、例外ひとつひとつ、ホットピックひとつひとつが新たな議論になる。そしてその議論の代価は、毎回、クライアントに降りかかる。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
