WESタスクログ：ピッキング効率が落ちた？3ステップでボトルネックを見つける

まず結論から。ピッキング効率が突然落ちたとき、人の問題を話し合う会議を開くのではなく、まずWESタスクログを開くこと。私はこの罠にちょうど3回はまっているのを見てきた。 そのたびに管理職は、作業者が怠けたのかどうかを3日間議論したが、答えは毎回ログに白黒はっきり書かれており、人とはまったく無関係だった。

ログが現場の目より常に優れている理由はこうだ。30回以上のWMS導入を経て学んだこと。現場管理者は結果を見るが、タスクログはプロセスを見る。作業者は「ずっと働きっぱなしだった」と言い、上司は「忙しそうに見えた」と言う。すべて主観だ。ログにはタイムスタンプ、ステップ遷移、中断記録がある。効率が落ちるとき、原因は常に3つのうちどれか。タスクがキューに長く滞留した（割当て問題）、タスクの実行に長くかかった（現場問題）、タスクが繰り返し中断された（手戻り問題）だ。それぞれログに異なる痕跡を残し、重なることは決してない。だから以下の3ステップ法が機能する。

10分クイックトリアージの枠組み（詳細は後述）：

作成から割当てまでが5分超（自分のベースライン比）→ 割当て戦略またはシステム性能。
割当てから完了までがベースラインより20%以上遅い → 現場の実行問題。
中断、キャンセル、再割当てが通常の2倍 → 例外処理プロセスの破綻。

注：5分と20%は私の経験からの参考値だ。本当の比較対象は、私の数字ではなくあなた自身の4週間のベースラインである。

ステップ1：WESタスクログで待ち時間をチェックする——ボトルネックは割当てか？

WESタスクログを開くが、個別タスクから始めてはいけない。まず集計から始める。タスクは作成から割当てまでの間にキューにどれだけ滞留したか。これを私は「待ち時間」と呼ぶ。

正確な手順、4ステップ：

過去14日分のタスクログを出力する。待ち時間の日次中央値とP90（90パーセンタイル。平均は決して使わない。外れ値に引っ張られる）を計算する。
効率が落ちた日を見つける。2週間の待ち時間カーブを描く。前後7日ずつだ。
効率が落ちた日と同じ日に待ち時間が急増していたら、ボトルネックは割当てにあり、作業者ではない。人の調査は丸ごと飛ばす。
待ち時間が横ばいなら、割当ては無実だ。ステップ2へ進む。

プロジェクトの話。 2024年秋、中国東部の3PL倉庫。1日あたり約8,000オーダー。ピッキング効率が1週間でほぼ30%落ちた。管理職の判断は「季節の臨時作業者が使えない」というもので、ある一団の人員を入れ替えようとしていた。私はタスクログを開いた。待ち時間は2分強から10分超へ跳ね上がっていた。タスクはシステム内で詰まっており、人に届いていなかった。割当て記録を掘ると、「最寄りゾーン割当て」ルールが新しい販促ウェーブ戦略に上書きされており、システムはより大きなウェーブを作るためにタスクを保留していた。自動ウェーブ生成ロジックを切ると、待ち時間はその日のうちに2分に戻り、誰も入れ替える必要はなくなった。臨時作業者はソフトウェアの判断の濡れ衣を着せられるところだった。

これを覚えておこう。人がタスクに触れる前に効率が落ちていたなら、作業者は決して問題ではなかった。

ステップ2：割当てから完了までの時間を比較する——ボトルネックは現場か？

待ち時間が正常で、タスクが人に問題なく届いているなら、次の区間を見る。割当てから完了までの時間は長くなったか。

倉庫の通路でハンディターミナルを使って商品をスキャンする作業者

正確な手順、3ステップ：

同じゾーンの同じSKUのタスクを取り、効率低下の前後で割当てから完了までの時間を比較する。
ゾーン別、SKUプロファイル別（かさばるもの対小さいもの、単品対ケース）に必ずグループ化する。グループ化しないとデータはぐちゃぐちゃだ。かさばるゾーンは常に遅く、それと比較しても意味がない。
系統的に遅くなったグループがあれば、そのグループを現場で見に行き、ステップ3の中断記録と突き合わせる。

もう一つの話。 2023年後半、北部のEC倉庫。単品ピッキングの完了時間は約40分から60分超へ延びたが、待ち時間は完全に正常だった。上司は新入社員が遅いせいだと責めた。私は通路別にタスクログをグループ化させた。通路Aは問題なかったが、通路BとCのタスクはすべて遅かった。現場を歩くと、通路BとCはラック補強工事中で、フォークリフトと資材が通路の半分を塞ぎ、作業者はシフト中ずっと迂回していた。答えはずっとログにあった。通路別にグループ化すれば一目瞭然だった。

このステップ最大の罠は「平均の罠」だ。倉庫全体の平均完了時間は10%しか上がっていないかもしれない。軽微に見える。しかしゾーン別に分解すると、あるゾーンは60%上がり、他は横ばいだ。平均が問題を隠していた。私の導入前夜チェックリストには必ずこの一文が入る。すべての効率指標はゾーン別、ウェーブ別、シフト別に掘り下げられなければならない。そうでなければ報告書は飾りにすぎない。

ステップ3：タスクログの中断記録を読む——ボトルネックは手戻りか？

キャンセル、再割当て、タイムアウトしたタスクは、最も目立たない効率キラーだ。作業者は一日中忙しそうに見える。ただ、やり直しで忙しいだけだ。

正確な手順、3ステップ：

日次の「タスク中断」イベントを数える。キャンセル、再割当て、タイムアウト自動解放、異常終了だ。
中断率＝中断タスク÷全タスクを計算し、4週間の平均と比較する。
率が2倍以上になったら、まず中断の理由分布を見る。在庫切れによる再割当てが多いか。ロケーション例外か。システムのタイムアウト解放か。分布が根本原因をまっすぐ指し示す。

3つ目の話、そして私が見た中で最も高くついたもの。 2025年初頭、美容製品の倉庫。効率は20%ダウン、中断率は通常の3倍。理由分布を見ると、80%が「在庫切れによる再割当て」だった。作業者に割り当てられたタスク、作業者がロケーションに到着するも在庫なし、タスクは跳ね返って再割当て。根本原因は、入荷から格納までが遅れており、システム在庫と実在庫が一致していなかった。倉庫は2週間にわたり全数実地棚卸を実施した。在庫精度が回復すると、中断率はその日のうちに下がり、効率も続いて回復した。現場の全員が何週間も火消しに追われていたのに、誰も中断理由分布を見ようと思わなかった。消防隊と放火犯が同じプロセスだったのだ。

ボトルネック早見表：ログの症状とまず確認すること

ログの症状	考えられるボトルネック	まず確認すること
待ち時間の増加、人が仕事待ち	ウェーブ／販促戦略に上書きされた割当てルール	ウェーブ規則、割当て優先度設定
待ち時間の増加、タスク量は変わらず	システム性能またはインターフェース遅延	タスクエンジンの応答、WMSインターフェース
あるゾーンの完了時間が系統的に遅い	現場の物理的障害またはロケーション例外	通路の閉塞、ロケーション精度
全体的に完了時間がやや遅い	人員／シフトの変更	シフト表、新入社員の割合
中断率が2倍、主に在庫切れ再割当て	在庫精度の低下	循環棚卸記録、入荷から格納までの適時性
中断率が2倍、主にタイムアウト解放	タイムアウト閾値が厳しすぎる、またはタスク過負荷	タイムアウトパラメータ、タスク量が能力を超えていないか

直感に反する判断：効率が落ちたら、研修するな——WESタスクログを読め

ほとんどの倉庫の反射行動はこうだ。効率低下→会議→再研修→増員。私の判断は逆だ。効率の急落は、ほぼ決して人の問題ではない。プロセスかシステムの問題だ。 人は徐々に遅くなるもので、一晩で30%遅くなることはない。急落は何かが変わったことを意味する。戦略が変わった、現場が変わった、在庫が変わった。WESタスクログは「何が変わったか」の記録装置だ。

正直にトレードオフを述べる。この方法はタスクログが完全であることを前提とする。一部のWES実装はタスクの作成と完了しか記録しない。中間ステップも中断理由もない。そうしたログは欠陥品で、そこから診断はできない。私の導入前夜チェックリストはこれを要求する。タスクログは作成時刻、割当て時刻、開始時刻、完了時刻、中断イベント、理由を記録しなければならない。欠けたフィールドは、事後分析における盲目を一つ増やす。