スプレッドシートは、在庫管理を行う上で非常に合理的な手段ですが、それも限界を迎えるまでの話です。
その転換点に気づくことは稀です。通常、スプレッドシートは1年間はうまく機能し、事業が成長するにつれて、ファイルは静かに信頼性を失っていきます。しかし、常にそこにあり、誰もがその使い方を知っているため、ソフトウェアを導入するコストよりもエラーによる損失の方が大きくなっても、使い続けられてしまうのです。
本ガイドでは、機能するスプレッドシートの構築方法と、同様に重要な「限界点」の見極め方について解説します。
スプレッドシートが適している場合
以下の項目のほとんどが当てはまるなら、スプレッドシートは適したツールです。
- 管理者が1人であること。 2人が同じファイルを編集した瞬間、バージョンに乖離が生じます。
- 販売チャネルが1つであること。 マルチチャネル販売では、1つの在庫数を複数の場所で共有する必要があります。スプレッドシートでは、Webサイトで商品が売れた際に、マーケットプレイスの出品情報を自動更新することはできません。
- SKUが数百点以下であること。 それを超えると、行の検索と更新だけで業務が終わってしまいます。
- 在庫の動きが手作業で数えられる範囲であること。 1日数百件ではなく、数十件程度である場合です。
- ロット、シリアル番号、有効期限の管理が不要であること。 これらを正確に手動管理することはほぼ不可能です。
- エラーの影響が許容範囲内であること。 在庫エラーが「お詫び」で済むなら問題ありませんが、コンプライアンス違反につながる場合は適していません。
また、実際に何が必要かを検討する際にも、スプレッドシートは適切なツールです。スプレッドシートを構築することで、何を追跡すべきかを決断せざるを得なくなり、その明確さが後のソフトウェア選定をより的確なものにします。
スプレッドシートに必要な列
まずは以下の項目から始めましょう。1ヶ月間使いこなすまでは、項目を増やさないようにしてください。
識別情報
- SKU — 独自のコード。販売可能なバリエーションごとに1つ設定します。すべてのデータの基点となるため、運用開始前にフォーマットを決定し、後から変更しなくて済むようにします。
- 商品名 — 人間が読んで理解できる説明。
- カテゴリ — グループ化やフィルタリング用。
- バーコード — 商品に付いている場合、スキャンによる検索が可能になります。
- ロケーション — 保管場所。小さなストックルームであっても、「棚C3」と記載する方が「奥のどこか」よりも優れています。
数量
- 手持在庫数 — 現在の物理的な在庫数。
- 引当在庫数 — 出荷待ちの注文に割り当てられている数。
- 有効在庫数 — 手持在庫数から引当在庫数を引いた数。販売において最も重要な数値であり、多くのスプレッドシートで欠落している項目です。
- 発注残数 — サプライヤーに発注済みで、未入荷の数。
再発注
- 発注点 — 新たな発注を行うトリガーとなる在庫レベル。
- 発注数量 — 発注する際の数量。
- リードタイム（日数） — 推定値ではなく、実測値。
- サプライヤー — 仕入先。
金額
- 単価 — 請求書価格だけでなく、運賃や関税を含めた仕入原価。
- 販売価格。
- 在庫金額 — 手持在庫数に単価を掛けたもの。
管理
- 最終棚卸日 — 最近確認されていない在庫を把握するため。
- 最終移動日 — 死蔵在庫を特定するため。
- 備考 — 他の項目に当てはまらない情報用。
役立つ2つの計算式
数値を記録するだけでは、スプレッドシートは単なるリストに過ぎません。以下の2つの式で、ツールへと進化させます。
有効在庫数：
= [手持在庫数] – [引当在庫数]
シンプルですが、最も有用な計算列です。有効在庫数ではなく手持在庫数に基づいて販売を行うと、すでに他者に割り当て済みの在庫を販売してしまうことになります。
低在庫フラグ：
= IF([有効在庫数] + [発注残数] <= [発注点], "ORDER", "")
発注残数を加えることで、先週発注したばかりの商品に対して再発注を促すミスを防げます。この項がないと、納品されるまでフラグが消えず、現場はフラグを無視するようになります。
基本が機能し始めたら、以下の2つも追加する価値があります。
在庫金額：
= [手持在庫数] * [単価]
シート全体で合計すれば、在庫投資額が算出されます。これは多くの中小企業がこれまで計算したことのない数値です。
在庫回転日数：
= [有効在庫数] / [平均日次出荷数]
単なる数量よりも有益です。40個という数字は、週に2個売れる商品と1日に20個売れる商品では意味が全く異なるからです。
条件付き書式を設定して低在庫の行に色を付け、フラグが立った行が一番上に表示されるように並べ替えやフィルタリングを行いましょう。誰の目にも触れないフラグは、フラグではありません。
正確性を保つ方法
この部分が、スプレッドシートが有用か、あるいは誤解を招くものかを決定づけます。
移動のタイミングで更新する。 一日の終わりやメモ帳から転記するのではなく、その都度更新します。遅延するほどエラーが増え、記憶を頼りに一日の終わりに更新することが、スプレッドシート在庫管理における最大の不正確さの原因です。
管理者を1人にする。 複数人で更新する必要がある場合は、ファイルをメールでやり取りするのではなく、クラウドベースのシートでリアルタイムの共同編集機能を使用してください。異なる受信トレイに在庫ファイルの別バージョンが存在する状態は、典型的な失敗パターンです。
定期的に棚卸しする。 一度にすべてを行うのではなく、毎週棚卸しの一部（特定の棚やカテゴリ）を行うサイクルカウントを実施しましょう。最終棚卸日を記録し、確認漏れがないようにします。
調整記録を別シートに残す。 すべての修正内容を日付と理由とともに記録する2つ目のタブを作成します。その理由のパターンにこそ業務上の欠陥が隠されています。セルを上書きすると、その情報は永久に失われてしまいます。
数式セルを保護する。 スプレッドシートが壊れる最も一般的な原因は、誰かが数式の上に数値を入力してしまうことです。数式セルはロックしましょう。
自動バックアップを取る。 バージョン履歴のあるクラウドストレージを使用し、誤削除や誤った貼り付けを元に戻せるようにします。履歴のないローカルファイルは、1年分の作業が消える原因となります。
すべてを選択せずに並べ替えを行わない。 1つの列だけを並べ替えて他の列をそのままにすると、すべての行がバラバラになります。これは気づかないうちに発生しやすく、非常に危険です。
適切なファイル構造
ほとんどのスプレッドシートは、数式の誤りではなく構造的な失敗によって機能しなくなります。それぞれ役割を持たせた4つのタブで、ほぼすべての問題を回避できます。
タブ1 — 商品： SKUごとに1行。めったに変更されない情報（名前、カテゴリ、バーコード、サプライヤー、単価、販売価格、発注点、発注数量、リードタイム）を保持します。これは参照データであり、日常業務で編集すべきではありません。
タブ2 — 在庫： SKUごとの現在の状況（手持在庫数、引当在庫数、有効在庫数、発注残数、ロケーション、最終棚卸日）。これが日常的に確認するタブです。
タブ3 — 移動履歴： 入庫、販売、調整、移動のすべてを1行ずつ記録。日付、SKU、数量、方向、理由を記載します。追記専用とし、行の編集や削除は絶対に行いません。
タブ4 — サプライヤー： 連絡先、リードタイム、MOQ、支払条件。
移動履歴タブは省略されがちですが、最も価値のあるタブです。これがないと、現在の在庫状況しか分からず、数値が間違っている場合に調査する術がありません。これがあれば、数値がどのように変化したかを追跡でき、誰かの感覚ではなく実際のデータに基づいて発注点のための平均使用量を計算できます。
また、在庫タブの仕組みも変わります。移動のたびに数量を手入力するのではなく、手持在庫数は計算式で算出します：
= SUMIF(Movements[SKU], [@SKU], Movements[Quantity])
入庫をプラス、販売をマイナスとして計算します。誰も何も上書きせず、すべての変更が記録され、現在の状況は維持されるのではなく算出されます。この構造的な決断こそが、スプレッドシート在庫管理が信頼できなくなる最も一般的な原因を排除します。
2つの推奨習慣：行が追加されても数式が機能するように、生のセル範囲ではなく「テーブル」機能を使用すること。また、移動履歴タブのSKU列にデータの入力規則を設定し、タイプミスによって存在しない商品が作成されるのを防ぐことです。
具体例
ある製品の在庫状況が以下の通りであるとします：
- 手持在庫数：240
- 未出荷注文への引当数：55
- サプライヤーへの発注残：0
- 1日あたりの平均出荷数：12
- 測定済みのサプライヤーリードタイム：9日
- 安全在庫：45
有効在庫は 240 − 55 = 185個です。実際に販売可能なのは240個ではなく、この数となります。
発注点は (12 × 9) + 45 = 153個です。
在庫カバー日数は 185 ÷ 12 = 約15日です。
この場合、発注点を上回っており約2週間分の在庫があるため、在庫不足フラグはオフのままです。ここで40個販売すると、有効在庫は145個に減り、発注点の153個を下回るためフラグが作動します。発注数量分を注文書（PO）として作成し、発注残の列に入力すればフラグは消えます。計算式に発注残を含めているため、配送中の間も警告が出続けることはありません。
この例のポイントは、4つの列が相互に作用している点です。手持在庫数のみを管理している場合、240個あると見て問題なしと判断してしまいますが、そのうち55個はすでに販売済みであり、実態は見た目よりもはるかに逼迫しています。
シンプルな棚卸しと計数のワークフロー
スプレッドシートの精度を保つには、定期的に棚卸しと照合を行う必要があります。週に1時間以内で完了し、ほぼすべての差異を捕捉できるワークフローを紹介します。
シートに3つの列を追加します： 実在庫数、棚卸日、差異（計算式：実在庫数 − シート上の在庫数）。
今週カウントする対象を選びます。 すべてをカウントする必要はありません。金額または売上高の上位20品目を毎週カウントします。残りの品目はローテーションでカウントします。10分の1ずつ毎週カウントすれば、約四半期ですべての在庫が確認できることになり、動きの遅い在庫には十分です。
ブラインドカウント用のシートを印刷します。 カウント対象の行でフィルタリングし、製品名、説明、ロケーションのみを印刷またはエクスポートします。期待在庫数は決して表示させないでください。人は表示された数字を確認しようとする傾向があるため、ブラインドカウントはコストをかけずに精度を向上させる最も効果的な方法です。
製品ごとではなく、ロケーションごとにカウントします。 棚の順序通りに歩き、各場所にあるものをカウントします。1つの製品が2か所に保管されている場合は、2行に分けて記録します。製品単位でカウントすると、数字が一致した時点で確認をやめてしまう恐れがあります。
カウントを入力し、差異列を確認します。 その都度調整するのではなく、まずは差異を確認してください。
大きな差異がある場合は再カウントします。 数値を変更する前に再カウントしてください。最初のカウントと2回目のカウントが異なることはよくあるため、1回のカウントで調整を行うと、誤りを修正するどころか逆にエラーを書き込んでしまうことになります。
調整前に調査します。 隣の棚、返品置き場、梱包台、直近の取引履歴を確認してください。明らかな損失の多くは、単に場所が間違っているだけというケースがほとんどです。
その後、数量を更新し、理由をメモ列に記録します。 誤ピッキング、受入ミス、破損、未記録の販売、または不明などです。理由コードを2週間分集めれば、修正すべきプロセスが明確になります。
日付をスタンプします。 「棚卸日」列があれば、何ヶ月もチェックされていない場所が一目で分かり、そこに次のエラーが潜んでいる可能性が高いことが分かります。
年1〜2回の全品棚卸しは会計上依然として必要ですが、週次のルーチンはそれまでの期間の数値を信頼できる状態に保ち、大きな驚きを事前に発見できるため、年次棚卸しの負担を大幅に軽減します。
スプレッドシートで在庫管理を行うメリットとデメリット
スプレッドシートは過大評価されることもあれば、不当に軽視されることもあるため、公平に評価します。
メリット
- コストがかからず、使い方もすでに習得済みであること。
- 完全に柔軟であること。 必要な列や計算式を自由に追加でき、機能追加のためにサプライヤーを待つ必要がありません。
- 即時性。 ソフトウェア導入には数週間かかりますが、スプレッドシートなら今日の午後には在庫管理を開始できます。
- 自社の数値を深く理解できること。 発注計算式を自分で構築することで、どんなダッシュボードよりも在庫について深く学べます。
- ポータビリティ。 データは自社のものであり、汎用的な形式で保存されるため、契約や移行の手間を気にせず利用できます。
- 小規模なら十分に対応可能。 数百行、1拠点、1〜2名体制であれば、適切に管理されたシートで十分に運用できます。
デメリット
- 実質的に1人での作業に限られること。 クラウド共有シートは便利ですが、繁忙期に複数人が同じ行を編集するとデータ損失が発生します。
- 監査証跡がないこと。 数値が変更されたことは分かりますが、誰がいつ変更したのか、変更前は何だったのかを確認できません。
- サイレントエラー。 計算式の範囲が1行足りない、列を並べ替えた際に隣の列がずれた、計算式の上に値を上書きしてしまったなど。警告は一切なく、シートは自信満々に間違った答えを出し続けます。
- 販売チャネルとの連携がないこと。 すべての販売を手入力する必要があり、常にわずかに情報が古くなるため、いずれ過剰販売が発生します。
- 拡張性がないこと。 パフォーマンスが低下するだけでなく、注文量に比例して手入力の負担が増大します。これは成長の形として最悪です。
- 移動時のバーコードスキャンがないこと。 在庫エラーのほとんどは、移動時の記録ミスによって発生します。
- 規律に完全に依存すること。 シートの精度は、全員が毎回必ず更新を行う場合にのみ保たれますが、最も忙しい週こそ、それが守られなくなる時です。
公平なまとめ：スプレッドシートは初期段階では適切なツールですが、ある時点を過ぎると負債となります。その転換点は多くの人が予想するよりも早く訪れます。通常は、販売チャネルを増やした時や、同じ数値を参照する必要がある2人目のスタッフが加わった時です。
スプレッドシートの限界
限界に達する前に知っておくべきこと：
リアルタイムのマルチチャネル同期ができない。 自社サイトとマーケットプレイスで併売している場合、片方で売れてももう片方の在庫は更新されず、過剰販売につながります。
取引履歴がない。 セルには現在の数値が表示されるだけで、その数値に至った経緯は分かりません。数値が間違っている場合、いつ、なぜ間違ったのかを確認できません。
バーコードスキャンがない。 すべての移動を手入力する必要があり、入力こそがエラーの発生源です。
ユーザー権限や監査証跡がない。 ファイルにアクセスできる人は誰でも変更でき、誰が行ったかの記録も残りません。
自動アラートがない。 在庫不足フラグは、誰かがファイルを開いて確認しない限り機能しません。
規模拡大に弱い。 計算式が多い大きなシートは動作が重くなり、並べ替えミスや計算式の上書きリスクが、規模や関与する人数に応じて高まります。
バッチ、シリアル、有効期限の追跡ができない。 信頼できる形での管理は不可能です。
ソフトウェアへの移行時期
移行のサイン（概ね発生順）：
- 複数のチャネルで販売している。 手動同期では少数の出品数しか対応できないため、これが通常、決定的な要因となります。
- 複数の担当者が在庫を更新する必要がある。
- 過剰販売が発生した。 特に複数回発生している場合。
- スプレッドシートの管理に1日1時間以上費やしている。 その時点ですでに、サブスクリプション料金の方があなたの時間よりも安価です。
- 「先週火曜日の在庫は？」という問いに答えられない。 履歴がないためです。
- 規制上の理由でバッチや有効期限の追跡が必要。
- 取り扱い品目が増え、棚卸しが大きな負担になっている。
移行してもスプレッドシートでの作業が無駄になるわけではありません。整理された構造化済みのシートは移行作業に不可欠であり、それを維持してきた規律があれば、何をなぜ追跡すべきかをすでに理解しているため、新しいシステムの構築はより容易になります。
ソフトウェアへの移行を成功させるために
スプレッドシートでの管理が限界に達した際、これまで適切にメンテナンスされていれば移行はスムーズに進みます。逆に、管理が不十分であれば、誤ったデータがそのままシステムにインポートされるため、移行は困難を極めます。
移行前にデータをクレンジングする。 重複したSKU、2年前に廃番となった製品、コストやサプライヤー情報が欠落した行、一貫性のないカテゴリ名など、これらをそのまま移行すれば、せっかく導入したシステム内でも同じ問題が再現されます。この作業には時間がかかりますが、避けては通れないステップです。
まずSKUの形式を標準化する。 コードの命名規則が場当たり的で、ハイフンがあったりスペースが混在していたり、理由不明の末尾文字が付いていたりする場合は、インポート後ではなく、検索・置換が容易なスプレッドシートの段階で修正してください。
寸法と重量を入力する。 多くのシステムでこれらの項目が求められますが、スプレッドシートには含まれていないことが多く、後から収集するのは手間がかかります。システム選定前に準備しておくことで、導入遅延の典型的な原因を排除できます。
カットオーバー直前に棚卸しを行う。 信頼できない在庫数量をインポートすると、初日からシステムが誤った状態になり、現場は「ソフトウェアの欠陥」と判断してしまいます。
移行後1ヶ月間はスプレッドシートを読み取り専用で保持する。 並行運用（二重入力やデータの乖離を招くため）ではなく、新システムで異常値が見つかった際の照合用リファレンスとして活用してください。
可能であれば移動履歴をインポートする。 多くのシステムはトランザクションのインポートに対応しています。過去12ヶ月分の利用履歴があれば、再発注点や予測機能が初日から有効に機能し、1年分のデータを蓄積するのを待つ必要がありません。
適切に管理されたスプレッドシートは、優れた移行ソースとなります。このガイドの列項目は、あらゆる在庫システムで求められるフィールドとほぼ一致しています。これは偶然ではなく、どちらの管理手法でも必要な情報は同じであり、違いは「誰が計算を管理するか」という点にあります。
詳細はこちら
- 在庫管理の方法 — スプレッドシートが支えるプロセス。
- 中小企業向けの在庫管理 — この規模における全体像。
- クラウド在庫管理 — 一般的な次のステップ。
- 再発注点とは — アラートの背後にある計算式。
- 在庫追跡の方法 — スプレッドシートを超えた手法。
- SKUとは — 構築前に識別子を正しく設定する。
要点まとめ
スプレッドシートは、数百SKU程度で、1人の担当者が管理するシングルチャネルの運用には適しています。手元在庫ではなく有効在庫を中心に構成し、移動の都度更新を行い、販売チャネルを増やしたタイミングでソフトウェアへ移行しましょう。
よくある質問
スプレッドシートで在庫管理はできますか？ はい。小規模な商品ラインナップで、1人の担当者がファイルを管理するシングルチャネルのビジネスであれば可能です。しかし、複数の販売チャネル、複数の編集者、あるいは法規制による追跡要件が発生した時点で、その運用は限界を迎えます。
在庫管理スプレッドシートには何を含めるべきですか？ SKU、製品名、カテゴリ、ロケーション、手元在庫数、引当在庫数、有効在庫数、発注残数、再発注点、発注量、リードタイム、サプライヤー、単価、販売価格、在庫金額、そして最終棚卸日と最終移動日が必要です。
低在庫アラートの計算式は？ =IF([有効在庫] + [発注残] <= [再発注点], "発注", "") です。発注残を含めることで、すでに発注済みの商品に対してアラートが出るのを防ぎます。これがアラートへの信頼を維持する鍵です。
スプレッドシートの精度低下を防ぐには？ 後回しにせず移動の都度更新すること、管理者を1人に絞ること、毎週サイクルカウントを行うこと、調整理由を別タブに記録すること、数式セルを保護すること、そしてバージョン履歴でバックアップを取ることが重要です。
スプレッドシートから在庫管理ソフトウェアへ移行すべきタイミングは？ 複数の販売チャネルで販売を開始したとき、複数の担当者が在庫を更新する必要があるとき、過剰販売（オーバーセル）が発生したとき、あるいはシートのメンテナンスに1日1時間以上かかるようになったときです。
在庫管理にはExcelとGoogle Sheetsのどちらが良いですか？ Google Sheetsは本格的な複数人編集と自動バージョン履歴に優れており、主な失敗要因の2つを解決できます。Excelは大規模データセットの処理が速く、数式やマクロの機能が強力です。小規模な在庫管理では、コラボレーションの利点が勝ります。
スプレッドシートは何SKUまで対応できますか？ 技術的には数千SKUですが、実務上は数百SKUを超えると、管理そのものが業務の大部分を占めるようになります。制約となるのはソフトウェアの性能ではなく、行を探す時間、並べ替えミスが発生するリスク、そして手作業でカウントする難しさです。
スプレッドシートで複数の倉庫ロケーションを管理できますか？ 技術的にはロケーション列を追加したり、拠点ごとにタブを分けたりすれば可能ですが、すぐに管理が煩雑になり、監査証跡を残しながら拠点間で在庫を移動させる手段がありません。複数拠点での運用は、スプレッドシートの限界を超えたサインです。
Warehouse Wiseは、在庫管理、倉庫業務、フルフィルメントに関するガイドを無料で提供する独立系ライブラリです。現場で働く方々、つまり倉庫や在庫管理の新人スタッフ、成長中の小規模小売・EC事業者、そして在庫を適切に管理したいすべての方に向けて書かれています。各ガイドでは用語を解説し、必要に応じて具体的な数値を用いた実例を提示する、というシンプルな構成を徹底しています。私たちは完全に独立しており、ソフトウェアや機器の販売、紹介料の受け取りは一切行っておらず、ガイドの掲載順位に広告料が影響することもありません。