2年前、フォンタナにあるeコマース倉庫を訪ねた——SKU数は5,000超。オーナーの悩みはこうだ：月に一度の棚卸し全面実施で2日間は出荷停止、それでも在庫精度は94%で停滞している。カウントのスケジュールはどう組んでいるのかと聞くと、空いているゾーンから倉庫全体を一気に数えるという。それが問題だと私は言った——ほとんど動かないスロームーバーを、1日に数百個出荷するSKUと同じ頻度で月1回数えている。チームが疲弊するのも無理はない。
サイクルカウントの要点は一文で言い切れる：速いものは頻繁に、遅いものは稀に数える。 ABC分析はまさにそのためにある。名前に臆することはない——出荷頻度や出荷金額でSKUをランキングして3段階に分けるだけだ。
当てずっぽうをやめたABCの作り方
標準の分け方：クラスAは出荷量ベースの上位15–20%のSKUで、通常オーダーラインの70–80%を占める。クラスBは中間の~30%で15–20%、クラスCは残りの50–60%で10%未満。数字は絶対ではない——大事なのはデータを引っ張ることだ。WMSから90日分の出荷オーダーラインをエクスポートし（WMSがなければ出荷明細で）、SKU別に集計して降順に並べ、累積の切り分けポイントで切る。半日仕事だ。
分類の成否を分けるポイントが二つある。一つ、新SKUはデフォルトでBに入れる。 新商品には実績がない——Cに入れると3か月間誰も数えず、もしヒットしたら帳簿はすでに間違っている。Aに入れるとカウント人手の無駄だ。Bが安全な居場所であり、1か月の実績が出たら再分類する。二つ、高額の小物は直接Aに入れる。 動きは速くないが、1個が高額で紛失しやすいSKUがある——スマホアクセサリー、化粧品サンプルだ。1個なくすだけで数十ドルの損失になる。金額オーバーライドを設ける：単価$50超は動きに関わらずAに振り分ける。
分類は「設定して終わり」ではない。eコマースのSKUの動きは常に変わる——四半期ごとに分類を再実行し、ピークシーズン前には必ず再実行する。売れ筋と死に筋はシーズンごとに入れ替わる。再実行は簡単——エクスポートして並べ替え、30分で終わる——それでも多くの倉庫は一度も再実行せず、クラスは形骸化する。
頻度スケジュールと、その背後にある人手の計算
実証済みの基準：Aは週次（ピーク時は週2回）、Bは月次、Cは四半期。この組み合わせで在庫精度97–98%が通常の結果として維持できる。
なぜ人手が節約できるか、計算が示している。SKU数5,000の倉庫：週次で数えるAのSKUが800、月次のBが1,500で週あたり~375、四半期のCが2,700で週あたり~225。週の合計は~1,400SKU。慣れたカウンターは1時間に40–60ロケーションを数える（小物エリアは遅く、フルパレットゾーンは速い）——50としよう。週28人時、つまり2.5人日だ。
全面カウント方式と比べてみよう：月1回5,000SKU、2日間、8–10人を本業から引っこ抜き、出荷は停止する。サイクルカウントは作業を毎日分散させる——ダウンタイムはゼロ、2人で1日3時間だ。高頻度のAカウントは差異を早期に捉える：今日見つけて、明日調査する。月次の全面カウントでは、差異が29日間も見つからないままになることもあり、その頃には原因の手がかりは冷めきっている。
スケジュールはどう組むか？4列だ：SKU、ABCクラス、今週数えるか（はい/いいえ）、担当カウンター。WMSにサイクルカウントモジュールがあれば、クラス別に頻度を設定して日次タスクを自動生成させる。モジュールがなければExcelで十分だ：AのSKUを4つの週次バッチに、Bを4つの月次バッチに、Cを12の四半期バッチに分ける。3つのリストを結合すれば、その日のカウントシートが出来上がる。肝心なのは：タスクは「人」「日」「ゾーン」に落ちなければならない。 「今週はAを数えて」と名前なしでは何も数えられない。
差異の調査：勘ではなく固定の分類を使う
私は6つの固定差異原因を推奨する。カウントシート上のチェックボックスとして使い、月次で集計すれば、壊れたプロセスが自ずと浮かび上がる：受領差異（数量と伝票の不一致）、格納ミス（Aに置かれ、システムはBと言う）、ピックの過不足、システム転記の遅れ（品物は動いたが取引が転記されていない）、破損/廃棄の未記録、そして数え間違い。3か月後には、差異の~80%が2つのバケツに集中していることに気づくだろう：格納ミスとピックミスだ。どちらも「何も失われていない、記録と置き場が食い違っているだけ」を意味する——そしてどちらにも直接の対策がある：格納時にスキャン確認を加える、AのSKUのピックに検証を加える。
ここが直感に反する部分だ：差異率が一番高いのは通常CではなくAだ。 AのSKUが一番動き、各受領・格納・ピックはエラーを生む機会だ。だからこそ高頻度カウントが報われる——週次のAカウントは若いうちにエラーを潰す。四半期のサイクルでは、3か月間複利的に膨らみ、調査不能になる。私はある倉庫で、AのSKUの月次差異率3%に対しCは0.5%というのを見た。オーナーはスケジュールを逆にしたがった。私は止めた：Cの低さは「動いていない」だけの意味で、Aの3%に物量を掛けると、絶対金額ではCの数十倍になる。
ツールも大事だが、順番が大事だ。バーコードスキャン付きハンディターミナルが基準——速く、直接アップロードし、エラーが少ない。紙のカウントシートは500SKU未満の現場向きだ：投資ゼロだが、二重入力がエラーを生む。音声指示カウントはバルクエリア向きで両手が空く。ツールに投資しすぎるな——ABCもやらずにカウントモジュールに数万ドルを注ぎ込む小さな倉庫を見てきた。プロセスの欠落を救うツールはない。順序は：まずABCと頻度、次にツールの強化だ。
4ステップで展開——そして3つの定番の罠
ステップ1：データを引いてABCクラスを作る——半日。ステップ2：頻度を設定し、初週のタスクリストを生成して、Aだけで2週間パイロットし、チームにリズムを覚えさせる。ステップ3：BとCを展開し、差異プロセスを立ち上げる——差異が出たら当日ブラインド再カウント、確定から24時間以内に根本原因を調査（受領か、格納ミスか、未転記の取引か？）、原因はカテゴリ別に記録する。ステップ4：差異原因の分布を月次でレビューし、支配的な原因があれば翌月にそのプロセスを直す。数えること自体は何の価値も生まない——数えることで見つかる根本原因がプロセス改善を駆動する、その根本原因こそが価値だ。
3つの罠。一つ目：ブラインドで数えない。 カウンターにシステム数量を渡すと、脳は「その数字を探し」に走る——システムが10と言えば、9を数え、10を見つけるまで数え直し、終わりだ。ブラインドカウントは数量なしのロケーションだけを渡し、照合は後からする。私の比較では、ブラインドカウントは30%+多くの差異を掘り起こす。チームは最初抵抗する——遅く感じる——が、2週間で慣れる。
二つ目：調査せずに帳簿を調整する。 多くの倉庫は差異を見つけると調整を転記して終わりだ。翌月、同じロケーションがまたずれている。調整は出血を止める、調査は治癒する。私のルール：Aの差異は必ず根本原因を追う、Bは50%サンプリング、Cは記録のみ。有限の労力は報われる所に投じる。
三つ目：サイクルカウントと年次棚卸しを敵対視する。 サイクルカウントが軌道に乗っても、経理と監査は年次の全面カウントを求める。戦うな——二人は別の主人に仕えている：サイクルカウントは管理ツール、年次カウントはコンプライアンスイベントだ。サイクルカウントで精度98%を維持する倉庫にとって、年次カウントは1日の儀式にすぎない。サイクルカウントなしの倉庫は3日間停止してもまだ大混乱を見つける。
明日からできること：今夜WMSから90日分の出荷データをエクスポートし、SKU別に集計して並べ替え、本当のクラスAがどの20%のSKUかを見てみよう。たぶん、チームがカウント労力の80%を、ほとんど動かない80%のSKUに費やしていることに気づくはずだ。頻度を逆転させれば、最初の1か月で差異検知の速さの違いが分かるはずだ。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
