15年間の運転経験から学んだことをお伝えしよう。倉庫のドックで最も激しい争いは、ドライバーとフォークリフトの間ではない。受入担当者とPDAスキャナーの間だ。「スキャンしたよ！音も鳴った！なのになぜシステムにないの？」WMSのPDAスキャナー連携の仕事で、私はこの光景を何度も見てきた。そして言えるのは、スキャナーが本当の犯人であることはほとんどないということだ。
フォンタナでのあの夜：どこにも届かなかった14個のカートン
昨年の秋、ピークシーズンの直前だった。フォンタナの3PL倉庫で集荷を待っているとき、受入ドックの近くで時間をつぶしていた。若い男性がパレットを受け入れていた——40個ほどのカートンだ。彼はプロのようにPDAを操った。ピッ、ピッ、ピッ、カートンを次々と。すると画面をタップして顔が青ざめた。WMSに届いたのはカートンの約3分の2だけだった。
彼の最初の直感は？「ガンが壊れた」。新しいバッテリー、再起動、再スキャン——それでも不足したままだった。上司がしかめ面で歩み寄った。「別のスキャナーを持ってこい」。新しいユニットに交換して再スキャンすると、すべて通った。問題解決？30分後、別のスキャナーもスキャンを落とし始めた。
私は脇から見ていて、何かがおかしいと感じた。同じ夜に2台のスキャナーが故障する確率はいくらだろう？喫煙休憩中に彼らのIT担当者と話すと、ひと言で謎が解けた。「スキャナーは正常です。その角にWi-Fiのデッドゾーンがあるんです」。受入エリアは2つのアクセスポイントの間の隙間にあった。PDAはスキャンし、画面に「スキャン済み」と表示したが、その後データはガンとサーバーの間のどこかで消え、誰も気づかなかった。
つまり、これがパターンだ。WMS-PDA連携でスキャンが消えると、現場の誰もがまずガンを責める。しかしガンは音が鳴った瞬間に仕事を果たした。その音とWMSの記録の間で、データはいくつものリンクからなるチェーンを渡る。破断はそのいずれにも起こり得るし、スキャナーはどれか教えてくれない。
もっと奇妙な事例：30秒遅れて届いたスキャン
別のとき、アリゾナ州チャンドラー近くで、逆の問題を見た——損失ではなく遅延だ。担当者がカートンをスキャンしたが、画面に何も起こらなかったので、もう一度スキャンした。するとシステムが目覚めて同じカートンを2回記録した。在庫は一晩で2倍になった。彼らは一晩中棚卸しをして解きほぐす羽目になった。
ITは原因をミドルウェア——PDAとWMSの間に座る収集サービス——まで追跡した。スキャンは直接送られていなかった。バッチ化され、グループで転送されていた。その日ネットワークが不調になり、バッチが詰まり、やがてすべてが一度に、30秒遅れで流れ出した。ドックでフィードバックなしに待っていた担当者は再スキャンしていた。そしてWMSは重複を一切疑わずにすべて受け入れた——重複排除のロジックがまったくなかったのだ。
これらの話が教えてくれるのは、WMS連携におけるスキャナーデータの損失、遅延、重複は、めったに「スキャナー」の問題ではないということだ。チェーンの問題なのだ。スキャンヘッドからシステムまで、データは4つのリンクを旅する。デバイス自体、倉庫の無線ネットワーク、中間の収集層、そしてWMSのエンドポイントだ。どのリンクも壊れ得るし、現場の症状はいつも同じに見える——「スキャンしたのに、システムにない」。
トラブルシューティングのチェーン：4つのリンクを順番に確認する
断言するが、推測でトラブルシューティングしてはいけない。チェーンをリンクごとに、正しい順番でたどるのだ。何をするにせよ、スキャナーの交換から始めてはいけない。スキャナーは最後に確認するものだ。
**リンク1：道路——倉庫のWi-Fi。**これがスキャン損失の最大の原因だ。PDAは無線で生きており、鋼製ラックだらけの倉庫はデッドゾーンの地雷原だ。対策はローテクだが効果がある。問題のエリアをPDAを持って歩き、信号を観察するか、ITにデバイスの切断ログを出してもらう。ほとんどの倉庫は実際の作業動線ではなく「カバーエリア」基準でアクセスポイントを設置している——そしてスキャナーが最も酷使される受入・格納ゾーンが、往々にして最も弱い場所なのだ。
**リンク2：ガンとそれを持つ人。**バッテリーが少なくなると、一部のPDAは無線を絞り、まずWi-Fiを落とす。汚れたスキャンヘッドはデコードが遅く、作業者は確認音を聞く前に先へ進む。一部のユニットはキーボードウェッジモードで動作し、スキャンデータをフォーカスのある入力欄に投げ込む——フォーカスがずれると、データは空中に打ち込まれる。小さなことだが、「音が鳴るから動いているはずだ」と誰もが思い込んでいるため、トラブルシューティングでは見落とされる。
**リンク3：中間の収集層。**ITに3つの質問をしよう。データはリアルタイムで送られるのか、それともバッチか？ネットワークが落ちた場合、データはどこにキャッシュされ、再接続時に補完されるのか？繰り返しスキャンに対する重複排除はあるのか？多くの「スキャン紛失」事例はここで終わる——スキャンは行われ、ネットワークも正常だったのに、データは一度もフラッシュされなかったミドルウェアのキューに残ったか、WMSが確認応答を送らなかったために2回フラッシュされた。損失と重複は、しばしば同じ根本原因の裏表なのだ。
**リンク4：WMSのエンドポイント。**受入APIは冪等か——短い時間内に同じバーコードを2回スキャンしても1回だけ登録されるか？タイムスタンプは一致しているか？WMSのログで各スキャンの到着時刻をすべて見つけられるか？完全なログを持つシステムなら、トラブルシューティングは記録を読むだけの作業になる。ログのないシステムでは推測するしかない。
この順番を経験則として覚えておこう。**まずネットワーク、次に作業者の習慣、次にミドルウェア、そして最後にスキャナーとシステムだ。**この順番でたどれば、たいてい午前中に問題を特定できる。逆向きにやる倉庫も見てきた——ガンを交換し、ソフトウェアを交換し、数日後にようやくアクセスポイントの位置が間違っていたことに気づくのだ。
直感に反する判断：リアルタイムが常に良いとは限らない
これは常識に反することだ。多くの人はスキャンデータはリアルタイムでWMSに流れるべきだと考える——速いほど良い、バッチは旧式だ。間違いだ。
リアルタイムアップロードとは、ネットワークの不調がそのままスキャン損失になるということだ——しかも最悪の種類の損失、作業者がまったく気づかない無言の損失だ。バッチアップロード（データをデバイスに保存し、数分ごと、またはバッチ完了後に同期する）はネットワーク障害に耐える。データはガンの中に残り、遅れるだけで、黙って消えることは決してない。バッチの代償はレイテンシだ——WMSは常に数分前の世界の姿を示し、ピーク時に急ぎの注文や緊急転送を急いでいるときには痛い。
だから万能の答えはない。仕事次第だ。受入と格納——「スキャンして先へ進む」作業——はバッチ＋補完の方が安全だ。仕分けと検証——「スキャンして即座にフィードバックを得る」作業——はリアルタイムが必要だが、その場合は無線ネットワークを実際の作業動線に合わせて設計しなければならない。これがテーブル上のトレードオフだ。速度が欲しければネットワークに投資する。耐性が欲しければ数分の遅延を受け入れる。どちらも支払わずに両方欲しがるのが最悪の結果だ。
率直な助言：スキャナーデータ損失を止める3つのこと
荷主の立場なら、貨物がドックに着いたときに荷下ろしの速さだけを見てはいけない。倉庫にいくつか質問しよう——スキャンで受け入れるのか、手入力か？スキャンデータを失ったことはあるか？スキャンデータを保証できない倉庫は、信頼できる在庫精度もくれないだろう。受入データ精度条項を契約に入れること。事後で言い争うより、毎回ずっと良い。
倉庫を運営する立場なら、3つのことだ。第一に、スキャナーを持って受入・格納ゾーンを歩き、デッドゾーンを地図化する——アクセスポイントで埋めること。そのお金は必須だ。第二に、PDAでオフラインキャッシュと自動補完を有効にする——スキャンデータを無防備なまま送らせてはいけない。第三に、WMSインターフェースにスキャンの重複排除をさせる——同じバーコードが短い時間内に2回入ってきたら、システムがそれを知るべきだ。この3つをやれば、10回中9回、「スキャンしたのにシステムにない」は永遠に消える。
15年間の路上経験が教えてくれたのは、倉庫の「機器の問題」のほとんどは、目に見えないもの——信号、ソフトウェア、プロセス——の問題だということだ。スキャナーは無実だ。ただ音を鳴らすだけなのだ。
私の故郷に古い諺がある。木を切る前に斧を研げ。スキャンが消えたら、ガンの交換に急いではいけない——4つのリンクをひとつずつたどるのだ。道路が開ければ、データは届く。
Shifu Zhao（ベテラントラックドライバー、15年）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
