在庫管理はスプレッドシートのままでいい？｜改修・SaaS・連携の判断基準

先に決めるのは「会社が信頼する在庫数」

在庫表には、実際に数えた数量、入庫予定、発注済み、出庫予定など、時点の異なる数字が並びます。これらを一つの「在庫」にまとめると、同じ商品でも見る人によって答えが変わります。

最初に、次の三つを決めます。

1. 何を同じ品目として数えるか 品名だけでなく、図番、規格、寸法、保管単位など、取り違えない識別条件を決めます。

2. いつ数量を増減させるか 入荷した時、検品が終わった時、現場へ払い出した時など、更新する出来事を一つにそろえます。予定と実績は別の欄にします。

3. 差異を誰が直すか 棚卸しで数が合わなくても、現在数を直接上書きして終わりにしません。差異の数量、理由、確認者、修正日を残し、誰が確定できるかを決めます。

この三つが決まると、スプレッドシートで足りない機能が見えてきます。決まらないまま道具だけ替えると、新しい画面でも同じ数字の食い違いが続きます。

スプレッドシートを続けるか判断する表

一律の品目数や人数ではなく、実際の更新と責任で比べます。

右側の条件が一つあれば、すぐ全面移行するという意味ではありません。その条件が、在庫判断を誤らせるのか、毎回の確認で吸収できるのかを見ます。たとえば複数拠点でも、拠点ごとに在庫が完全に分かれ、移動時だけ決めた担当が更新できるなら、一つの表を続けられる場合があります。逆に一拠点でも、複数人が頻繁に持ち出し、変更履歴が必要なら、標準機能のあるSaaSを試す理由になります。

五つの進め方を、順番に比べる

1. 重複した管理を止める

担当者別の控え、部署ごとの集計表、会議用の転記表が同じ在庫数を持っているなら、先に減らします。残すのは基準となる記録と、そこから作る表示です。複数の表を自動で同期する前に、そもそも同じ数字を何度も持つ必要があるかを確かめます。

2. スプレッドシートを標準化して続ける

利用範囲が限られ、更新担当と時点をそろえられるなら、有力な選択肢です。品目一覧と入出庫履歴を分け、現在数は履歴から確認できる形にします。入力欄、計算欄、閲覧用の集計を分け、差異修正も履歴として残します。

続ける条件は「今、動いている」ことではありません。担当者が替わっても、何を入力し、どの数字を確認し、異常時にどこへ戻るかを説明できることです。

3. 在庫管理SaaSを限定範囲で試す

複数人・複数場所での更新、変更履歴、権限、棚卸し支援などが必要なら、在庫管理SaaSを比べます。最初から全品目を移さず、動きが多い材料群や、差異の原因を追いたい商品群に絞ります。

試用時は、画面の使いやすさだけでなく、同じ入出庫を旧表と新しい仕組みの両方で確認します。通常の入庫・出庫に加え、返品、破損、単位換算、棚卸し差異を処理できるかを見ます。試用後に旧表を止められないなら、二重入力が新しい負担として残ります。

4. 必要な境界だけ連携する

受注、発注、倉庫などに別の基準記録がある場合、在庫表へすべてを移すより、必要な出来事だけつなぐ方が適することがあります。たとえば、入荷確定を在庫へ渡す、出庫確定を受注へ返す、といった境界です。

連携では、成功した処理だけでなく、取込失敗、重複、送信結果不明を誰が見つけ、再開するかまで決めます。つながることと、正しい在庫になることは同じではありません。

5. 固有条件だけ個別開発する

独自の寸法・重量換算、複数単位、固有帳票、承認条件を標準機能や限定連携で扱えない場合に、残った部分だけを開発候補にします。在庫管理全体を作り直す前に、標準機能で扱える範囲と、固有条件の範囲を分けます。

個別開発を選ぶなら、完成時の画面だけでなく、変更担当、確認方法、データの戻し方、開発者が不在でも続ける条件まで投資範囲に含めます。

架空例：材料在庫の表を、どこまで残すか

以下は判断方法を示すための架空例です。

金属加工会社が、材料を図番、材質、寸法、枚数、換算重量、保管場所で管理しているとします。当初は保管場所が一つで、入庫と払出しを記録する担当も限られていました。この段階なら、一つのスプレッドシートに品目一覧と入出庫履歴を分け、差異修正の責任者を決めて続ける案が考えられます。

その後、第二倉庫を使い始め、製造担当も材料を払い出すようになりました。倉庫間移動が後から入力され、棚卸し時には現在数が直接書き換えられています。さらに、発注表と倉庫から届くデータにも同じ数量があります。

この会社には、少なくとも二つの選択肢があります。

• 更新担当を絞り、倉庫間移動と差異修正を履歴に残せるなら、スプレッドシートを標準化して続ける。
• 複数場所からの更新、履歴、権限が日常的に必要なら、一部の材料で在庫管理SaaSを試し、発注・倉庫との転記が残る箇所だけ連携を比べる。

重量換算だけが標準機能に合わない場合も、すぐ全体を個別開発しません。換算部分だけを追加する案と、運用で補う案を比較します。最終的に経営者が承認するのは、どの在庫数で発注や顧客回答を行うか、誰に修正権限を持たせるか、移行と維持へどこまで費用と社内時間を使うかです。

最初の一枚に書くこと

方式を比較する前に、対象を一つの材料群・商品群へ絞り、次の内容を一枚にします。

• 使う判断：発注、製造、出庫、顧客への在庫回答のどれに使うか
• 対象：品目、保管場所、単位、対象外
• 更新：入庫・出庫・返品・移動を、いつ誰が記録するか
• 差異：誰が数え、理由を確認し、修正を確定するか
• 基準記録：どの表・システムの数字を信頼するか
• 維持：担当者不在や停止時に、何で業務を続けるか
• 見直し：利用者、場所、転記、例外がどう増えたら方式を変えるか

この一枚を埋めると、「スプレッドシートだから古い」「SaaSだから安心」といった選び方を避けられます。必要なのは、在庫判断を支えられる最小の仕組みです。条件が変わったときに初めて、次の方式へ進みます。

在庫数を発注へ使い、数量案・承認・送信の範囲も見直す場合は、次に「発注の自動化はどこまで任せる？」で人に残す判断を整理できます。