倉庫が消化できる速度より速く作業をリリースしたらどうなるか？良いことは何も起きない。それなのに、私が訪ねたWES導入現場の半分は、立ち上げ時に設定したリリースレートのまま、時には何年も一度も見直されていないと推測される。
タスクリリースは倉庫のスロットルだ。積極的すぎると通路が仕掛品であふれ、臆病すぎるとピッカーは手待ちになる。正解は一度きりの設定ではない。チューニングという規律である。
3種類の詰まり、3種類の対処
リリースが過熱すると3つのものが詰まる——そしてほとんどのチームは区別できていない。
1つ目は通路の物理的キャパシティだ。ピッキング通路は、人と設備が互いに邪魔し始める前に収容できるカートやパレットの数に限りがある。2つ目は下流のキャパシティだ。ピッキングが梱包・検品ステーションを上回り、滞留が通路出口に積み上がってピッキングゾーンへ逆流する。3つ目は補充ペースだ。リリースが速すぎると補充がスロットを満たし続けられず、システムが在庫ありと主張する中でピッカーは空スロットに到着する。これが3つの中で最も士気を下げる詰まりだ。
パラメータに1つも触れる前に、診断せよ。詰まったとき、通路入口で並ぶカートなのか、梱包で積み上がるパレットなのか、空スロットを見つめるピッカーなのか？それぞれが指し示す設定は違う。間違った方を直せば悪化する。
私の診断法は驚くほどローテクだ：ピーク時に現場に30分立つ。通路入口、梱包の行列、ピッキングフェイスを観察する。見たものを携帯にメモする。30分の観察は、ダッシュボードを1週間眺めるより勝る。システムのデータは嘘をつくが、現場はつかない。
日常レートの出発点となる式
私は日常のリリースレートを3つの入力から組み立てる。
通路スループット：メイン通路1本が競合なく収容できるピッキングカートの数（たとえば6台）と、カート1台が通路を占有する時間（たとえば20分）を数える。その通路の上限は1時間あたり18カートサイクルだ。リリースは、下流の最も狭いリンクを絶対に超えてはならない。
人員ペース：ピッカーが1時間に実際に完了する数を測定し（測定値であって、ベンダーの理論値ではない）、現場の人数を掛ける。リリースはその能力の85〜90％に設定し、問題オーダー用のバッファを残す。
設備ペース：コンベア、AMR、ソーターを運用している場合、ボトルネックは人ではなく機械にあることが多い。定格3,000ユニット/時のソーターは、リリースをその数に制限する。それ以上流しても、消化できない行列を作るだけだ。
私の日常の出発点：リリースレート = min(通路上限, 人員能力 × 0.9, 設備能力 × 0.85)。1週間運用し、3つの指標——通路の詰まりインシデント、ピッカーの手待ち時間、定時出荷率——を観察して調整する。そして最低でも四半期ごとに見直す。事業が変われば、パラメータも追随しなければならない。
昨年チューニングしたeコマース現場の具体例：メインのピッキング通路4本、各5台のカートで1台あたり15分、つまり通路1本あたり1時間80カートサイクル；測定で1時間45ラインのピッカー30人、つまり人員1,350ライン/時；梱包は1,100ユニット/時。リリースは950ライン/時に設定した——制約は梱包で、15％のバッファを取った。通路の詰まりはゼロになり、ピッカーの手待ち時間は1人1日40分から10分未満に減った。数字は本質ではない。「最小を取る」というロジックこそ本質だ。
繁忙期には第2のスロットルが必要
繁忙期——ほとんどのeコマースでは10月から12月——は、日常パラメータに係数を掛けただけでは回せない。「1.5xでリリースしよう」と誰かが決めて、繁忙期の第1週に溶ける現場を何度も見てきた。
繁忙期は方程式を変える。まず人員から：季節労働者のピッキングペースはベテランの60〜70％なので、人員能力の数字は実際の体制から作り直さなければならない。次にボトルネックの移動を見よ。通常期はピッキングにあるかもしれないが、繁忙期は梱包と出荷に移るのが普通だ。オーダープロファイルが小口・シングルライン中心に変わるからだ。
私のやり方は2つのパラメータセット——日常用と繁忙期用——をWESの設定テンプレートとして保存し、繁忙期の2週間前に切り替え、3日間の実績データで微調整する。切り替え当日は必ず現場にいる。パラメータ変更の日に何かが壊れる確率は、通常の桁違いに高い。
繁忙期にもう1つ必須なのは自動ブレーキだ。通路の混雑がしきい値を超えたら——たとえば3本以上の通路が15分連続で行列したら——人が気づくのを待たず、WESが自らリリースを絞るべきだ。機械は人より反応が速い。大事なところではシステムにブレーキを踏ませよう。
至るところで見る3つのチューニングミス
1つ目、リリースレートを「高いほど良い」KPIとして扱うことだ。速くリリースしても速く生産できるわけではない——現場に仕掛品を押し出すだけだ。未リリースの作業はキューで待ち、過剰リリースの作業は通路で待つ。同じ待ち時間で、混雑は悪化する。
2つ目、すべてのゾーンに1つのリリースレートを使うことだ。通路は幅もSKU密度も人員も違う。単一レートでは、最も狭い通路が全員を律速する。ほとんどのWESプラットフォームはゾーン別のリリースポリシーをサポートしている——使っていなければ、機能の半分を捨てているのと同じだ。
3つ目、ログなしでチューニングすることだ。誰が変えたか、なぜか、以前の値は何だったか、その後何が起きたか——この4つの質問に答えられなければ、すべてのインシデントはゼロからのスタートになる。私はクライアントにパラメータ変更ログを付けさせる。共有スプレッドシートで十分だ。大事なのは記録だ。
インディアナからの午前2時の電話に話を戻そう。その3PLはやがて変更プロセスを整え、リリースレートの権限をオペレーションマネージャーに戻し、私に夜中電話するのをやめた。スロットルのチューニングは難しくない。難しいのは、建物内の全員に理解させることだ：アクセルをどれだけ踏み込むかは道の広さで決まるのであって、ドライバーの焦りで決まるのではない。あなたの現場で、最後にリリース設定を見たのはいつですか？
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
