在庫管理エクセルテンプレート、業種によって「使える設計」はこんなに違う——小売・製造・卸売・EC、4業種の現場から見る選び方と限界点 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

小売業：「売れ筋と死に筋」を日次で追える設計が要る

アパレルや雑貨店、日用品の小売業では、在庫管理の中心課題は「どの商品がいつ、どのくらい売れるか」の把握だ。品番・サイズ・カラーといったSKU単位の管理が必要になるため、テンプレートの行数と列数はすぐに膨れ上がる。

実際に300SKUを超えたあたりから、エクセルでの日次管理は現実的でなくなってくる。渡辺さんという雑貨チェーンの店長が経験したケースでは、100SKUまでは手入力で回せていたが、新シーズンの仕入れで150SKUを超えた時点で「どの商品の在庫が足りていないか」を確認するだけで30分以上かかるようになった、という。

小売向けテンプレートで最低限必要な項目は以下の通りだ。

• SKU単位の現在庫数・発注点・最大在庫数
• 日次入出庫の記録欄（日付・数量・担当者）
• 売上実績との照合列（POSデータ連携がないなら手入力）
• 棚番や保管ロケーション

テンプレートが「使えなくなるサイン」は、在庫の差異（帳簿在庫と実在庫の乖離）が常態化し始めたときだ。月1回の棚卸しで毎回10件以上の差異が出るなら、入力タイミングや更新頻度の問題ではなく、テンプレートの構造自体に無理が来ている。

各業種のテンプレート要件と、エクセル管理の現実的な上限の目安

製造業：ロット・工程・原材料の「紐付け」がないテンプレートは機能しない

製造業の在庫管理が他業種と大きく異なるのは、「原材料→仕掛品→完成品」という工程の流れが在庫の動きに直結している点だ。完成品の在庫だけを記録するテンプレートでは、どの工程でどの部品が何個使われたかが追えない。

金属部品メーカーで製造管理を担当する伊藤さんは、「ロット番号と使用工程を結びつける列がないテンプレートは、うちでは使い物にならない」と話す。品質不良が起きたとき、該当ロットを追跡できなければ影響範囲が特定できないからだ。

製造業向けテンプレートで押さえるべき設計条件は次のとおりだ。

• ロット番号・製造日・有効期限の管理列
• 原材料・仕掛品・完成品を別シートで管理し、相互参照できる構造
• 生産計画数と実績数の対比（差異の見える化）
• 使用工程や出荷先との紐付けフィールド

こうした構造を1枚のエクセルファイルで実現しようとすると、シート間のVLOOKUPが複雑に絡み合い、ちょっとした変更がどこかで計算式を壊す事態になる。品番が80を超えたあたりから、このリスクは急上昇する傾向がある。

なお、エクセルやシステムへの移行を検討する前に、在庫管理の基本要件——管理単位・更新タイミング・差異許容範囲——を整理しておくことが導入成功率を高める。導入前の確認フェーズで必要な要件整理についてはこちらの記事も参考になる。

卸売業：取引先ごとの「価格・リードタイム・最小発注量」がテンプレートに入るか

卸売業の在庫管理テンプレートは、品番管理だけでなく「どの取引先から・いくらで・何日で届くか」という仕入れ条件の管理が組み込まれていないと、発注判断に使えない。

食品卸を営む会社で在庫担当をしている小林さんのケースでは、取引先が40社を超えた時点で「仕入先コード×品番」の組み合わせが1,000行を超え、エクセルのフィルタ操作だけで発注準備に1日かかるようになったという。テンプレートを使い続けていたのではなく、気づいたらテンプレートの奴隷になっていた、という表現が印象的だった。

卸売業特有の項目として以下を押さえておきたい。

• 取引先コード・仕入単価・リードタイム日数
• 最小発注量（MOQ）と発注ロット単位
• 商品コードと取引先品番の対照表（同一商品でも取引先ごとに品番が違う場合が多い）
• 在庫回転日数の算出列

卸売業のエクセル管理が詰まるのは「発注タイミングの判断」だ。安全在庫の考え方を正しくテンプレートに組み込まないと、欠品リスクを抱えたまま日々の業務を回すことになる。発注点の設計方法については、e-Stat（政府統計ポータル）の流通・卸売業の流通構造統計なども、業界標準の数値感をつかむ参考になる。

EC事業者：モール別の在庫連動がないテンプレートは「過剰販売」を招く

楽天・Amazon・Yahoo!ショッピングなど複数モールで販売するEC事業者にとって、在庫管理の最大の課題はリアルタイムの在庫同期だ。モールごとに在庫数を手動で書き換えていると、どこかのタイミングで「実際には1個しかないのに、3モールで各1個売れた」という過剰販売（オーバーセル）が発生する。

アクセサリーのEC事業者を立ち上げた中村さんのケースでは、SKUが20点程度のうちはエクセルで何とかなっていた。しかし50SKUを超えてAmazonを追加した時点で、土日の注文が週明けにまとめて確認される構造に気づかず、複数の過剰販売トラブルが発生した。キャンセル対応と評価への影響で、その週の作業時間のほぼ半日が後処理に消えた。

EC向けテンプレートに求められる設計は次のとおりだ。

• モール別の在庫欄を横並びで持ち、実在庫との差分を一目で確認できる構造
• 受注CSVの貼り付けで在庫数が自動更新されるマクロ（手入力ではリアルタイム性が追いつかない）
• 返品・キャンセル時の在庫戻し処理の記録
• モール別の発送期限ルールの記録欄

ただし、複数モール×50SKU超の規模では、エクセルのマクロ管理はかなり属人的な構造になる。担当者が変わると誰も触れないファイルになるリスクが高い。こうした課題に対しては、ネクストエンジンとの連携機能を使った受注・在庫の一元管理が選択肢のひとつとして挙げられる。モール別の受注を自動で取得し、在庫数を連動させる仕組みは、小規模EC事業者でも導入実績がある。気になる場合はまずどんな規模から相談できるか確認してみるのが早い。

テンプレートからシステムへの移行を判断する共通の起点

業種に関係なく、以下の状態が重なったときは「テンプレートの設計問題」ではなく「管理の仕組み自体を変える」タイミングと考えてよい。

• 月次棚卸しのたびに帳簿在庫と実在庫の差異が10件以上出る
• 在庫確認に毎日30分以上かけているのに、発注ミスや欠品が月1回以上起きる
• ファイルを触れる担当者が1〜2名に限定され、その人が休むと在庫が見えなくなる
• 新しいシートや列を追加するたびに、既存の計算式が壊れるリスクを感じている

こうした現象は「使い方の問題」ではなく、構造的な限界のサインであることが多い。現場責任者が在庫管理の属人化を解消するための具体的なステップを整理した記事も、移行を考える前の整理として参考になる。

Spesはバーコード・ハンディ連携から複数拠点の一元管理まで対応したクラウド型の在庫・受発注管理ツールで、エクセルからの移行を想定した設計になっている。業種や現場の状況に応じた使い方については、機能一覧ページで確認できる。

よくある質問

無料のエクセルテンプレートと有料テンプレートは何が違うのか？

無料テンプレートの多くは汎用的な設計で、業種固有の項目（ロット番号・取引先コード・モール別在庫欄など）が省かれていることが多い。有料テンプレートや業種特化型テンプレートは、これらの項目が最初から組み込まれている分、ゼロからのカスタマイズ工数が少なくて済む。ただし、品番数や取引先数が一定規模を超えると、テンプレートの種類に関係なくエクセルの構造的な限界に達する点は変わらない。

エクセルからシステムに移行するとき、既存データはどうなるか？

多くのクラウド型在庫管理システムはCSVインポートに対応しており、エクセルで管理していた品番・在庫数・取引先情報を移行できる。ただし、列名やデータ形式を合わせる作業が発生するため、移行前に「現在のエクセルのどの列をどの項目に対応させるか」を整理しておくとスムーズに進む。移行支援をサービスとして提供しているベンダーも多いため、自社で抱え込まず相談するのが現実的だ。