Go-Live ウォールーム：初週に備えて用意すべきもの

私が見た中で最悪の WMS ゴーライブはこうでした：立ち上げ当日の正午、ピッカーの RF ガンがタスクリストを取得できず、40人が棚の前で手持ち無沙汰になっていました。オーナーは机を叩き、IT は会議室で責任の押し付け合い —— 問題が起きたときに誰が最終判断を下すのか、誰も決めていなかったからです。

その後、私は教訓を得ました：どんなシステム立ち上げでも、初週に倉庫が必要とするのはウォールームです。会議室ではなく —— 指揮所です。誰が座るのか、どんなツールを持ち込むのか、どんなリズムで回すのか、すべてゴーライブ前に決めます。以下は、何度かの立ち上げで磨き上げたプレイブックです。このまま使ってください。

私が見た失敗した3つの立ち上げ —— 共通点は「誰も決められなかった」

まずは3つの実話から。ウォールームが交渉の余地なしに必要な理由が分かるはずです。

ラベル用紙。 2日目、すべてのプリンターが止まりました —— システム障害ではありません。ラベル用紙が切れたのです。管理部門は旧システムの使用量を基に在庫していましたが、新しい印刷フォーマットでは消費量が2倍になりました。倉庫スタッフ30人が午前中ずっと宅配業者の配送を待ちました。それ以来、ウォールームのチェックリストにはこの1行が載っています：消耗品は3日分備蓄する。

インターフェースは午前2時に死んだ。 ERP の受注連携が午前2時に途切れ、WMS が受注を受け取らなくなりました。オンコールの IT は新入りで、インターフェース再起動の権限が誰にあるのか知らず、グループチャットで @everyone をメンションして、適切な担当者を見つけるのに 40 分かかりました。その 40 分の間に、午前 6 時の波動計画は崩れました。それ以来、シフト表には名前と電話番号を載せ、ウォールームの壁に貼っています。

オーナー自ら指揮を執った。 3日目に S2 が発生：IT は修正に 4 時間必要でしたが、現場は待てませんでした。オーナーはフロアに乗り込み、ウォールームを無視して自ら作業フローの指示を出し始めました —— それがシステムのロジックと衝突し、その日だけで 200 件の例外が発生しました。それ以来、私は鉄則を設けました：初週は、フロアはたった1つの声 —— ウォールームからの指示だけに従う。意見のあるオーナーはウォールームの中で言ってください。

3つの失敗、3つの死に方、根本原因は1つ：肝心なときに誰も決められなかった —— あるいは決めるべきでない人が決めた。

部屋にいなければならない5人

人選を間違えると、ウォールームはただの言い争いの場になります。この5つの役割は交渉の余地なしです：

フロア司令官（1人、最終決定権）。 IT ではなく、業務を知るオペレーションのリーダーでなければなりません。与えられる権限はただ1つ：インシデント発生から 5 分以内に「続行」か「停止」かを決める。初週は会議方式の決定では生き残れません。

WMS 導入担当者、常駐で。 設定不具合が発生したとき、その場で直せるのは彼らだけです。ゴーライブ週の常駐サポートは契約書に明記してください —— リモートのみのサポートが失敗するのを私は見てきました。

IT / 連携リード。 WMS は島ではありません：ERP 受注連携、運送会社のラベル API、請求インターフェースのいずれが止まっても倉庫は止まります。この人はすべてのインターフェースの監視と再起動の権限を持ちます。

フロアのシフトリード。 ピッキング、入荷、監査から各1人。彼らはシステムの人間センサーです —— 画面のもたつきや使いにくいワークフローを最初に感じ取ります。単なる伝達役ではなく、直接報告できるチャンネルを与えてください。

記録係とエスカレーション管理者。 すべての問題をチケット化し、深刻度を付け、クローズまで追跡します。明日に回すものと今すぐエスカレーションするものを決めるのはこの人です —— 部屋の秩序は彼らにかかっています。

一言で言えば：ウォールームが満席なら、フロアは落ち着いている。

立ち上げ前48時間のチェックリスト

ウォールームは立ち上げ当日の朝ではなく、2日前に構築します。1つずつチェックしてください：

• データフリーズ： 旧システムが入力を受け付けなくなる正確な時刻を、全社で同期します。フリーズ前に3つを検証してください：SKU マスタデータ、ロケーション、在庫残高。この3つのいずれかが合わなければ、立ち上げはしません。
• 印刷消耗品： 出荷ラベル、バーコードラベル、リボン —— 3日分を備蓄します。笑いたければ笑ってください；2日目にラベル用紙の配送を待って倉庫が止まったのを私は見たことがあります。
• ロールバック訓練： ロールバックとは「まずくなったら旧システムに戻す」ではありません。書き出してください：発動条件、発動を命じる人、データの戻し方、旧システムの復旧に必要な時間。立ち上げ前に少なくとも1回、机上で通してください。
• シフト表： 初週は1日2つの 12 時間シフト（昼夜休みなしで）、7日間連続です。名前と電話番号を紙に。午前 3 時には、誰に電話すべきかが正確に分からなければなりません —— グループチャットの @everyone ではありません。
• 部屋そのもの： リアルタイムの受注充足率、バックログ量、インターフェース状態を表示する大画面；その日のトップ 3 リスクを書くホワイトボード；お菓子と水の備蓄。初週は誰もまともに食事できません。

初週のリズム：1日3回のスタンドアップ + 深刻度レベル

1日3回のスタンドアップ、例外なし。 朝（シフト開始の 30 分前）：昨日の残りを片付け、当日の波動計画を確認。正午のチェック：午前のバックログと例外を確認し、午後の増員が必要か判断。夜の振り返り（終業後）：その日の問題リストを歩き、深刻度を付け、担当者と期限を割り当て。各回最大 30 分。立ったまま。

深刻度とエスカレーションのマトリクス —— 壁に印刷して貼ってください：

撤退の判断：ロールバックのレッドライン

一番難しい判断はバグ修正ではありません —— 「今日は立ち上げられない」と認めることです。レッドラインは事前に書き出し、立ち上げ計画に載せ、オーナーの署名をもらいます：

• 受注充足率が 80% を下回り、2 時間にわたって改善傾向がない；
• バックログが日次処理能力の 1.5× を超え、増え続けている；
• 主力インターフェース（ERP 受注 / 運送会社ラベル）が 4 時間以上停止し、回復の見込みがない；
• 在庫差異が広範囲に広がり、実査数が収束しない。

いずれか1つが発動条件です：フロア司令官が停止を宣言し、ロールバックを開始します。覚えておいてください：ロールバックは失敗ではありません —— 損失管理です。 3 日間耐え抜いて全顧客を失うのが真の失敗です。私が手がけた立ち上げの中で、決断よくロールバックしたものは 2 週間後にクリーンに稼働しました；無理に押し切ったものは 1 か月の苦痛を味わいました。

ウォールームを解散するとき

それにも基準があります —— 「もう大丈夫そう」ではありません：S1/S2 の問題が 3 日連続ゼロ、充足率が立ち上げ前のベースラインに回復、バックログがゼロ。それから最後の振り返り：問題ログをアーカイブし、バックログを日常オペレーションに引き継ぎ、シフト表をオンコール体制に縮小。ホワイトボードを消す。解散。

立ち上げの初週はテクノロジーではなく組織力で勝ちます。最安定のシステムも、誰の言うことを聞けばいいか分からない 40 人には耐えられません。ウォールームを構築し、ルールを定めれば、初週はスムーズに着地します —— 何度かの徹夜で払った代償の教訓です。

英語版からの翻訳。内容に相違がある場合は英語版を優先します。