Excelの在庫管理をシステム化する判断基準 ｜ 限界の見分け方と移行の5ステップ

Excelの在庫表をシステムに移すべきか迷ったら、品目数だけで判断せず、出荷に必要な時点まで記録がそろうか、差異の理由を追えるか、担当者が変わっても運用できるかを確認します。この記事では、判断のチェック項目から移行先の比較、データを移す手順まで整理します。

1. Excelで続けられるかは「数」より運用で判断する

品目が少なくても、同じ商品を複数の拠点で出荷し、販売サイトの注文と在庫をすぐ連動させる必要があるなら、管理は複雑になります。一方、品目が多くても、更新のタイミングがそろい、履歴を残して確認できる業務なら、Excelの改善で対応できる場合があります。

「何品目からシステム化」「何人以上ならExcelは使えない」といった線引きではなく、現場で求められる正確さと速さに、今の運用が追いついているかを見ます。例えば、出荷の判断に使う表なのに前日分までしか反映されていないなら、ファイルが軽くても見直す理由になります。

Excelのワークシートは最大1,048,576行ですが、これは在庫管理に適した品目数の保証ではありません。一つの品目にも入出庫の履歴は積み重なり、数式や利用環境によって処理の負担も変わります。出典：Microsoft公式のExcelの仕様と制限。

まずは、困った場面を一つ記録してください。「棚卸が大変」だけでなく、「どの品番で差異が出たか」「原因確認に何を調べたか」「出荷にどんな影響があったか」まで残すと、改善すべき箇所が絞れます。システムの選定前に、Excelの入力ルールを直すだけで解消する問題も分かります。

Excelの改善から始める場合は、在庫表の自作方法とSUMIFS・記録ルールの解説をご覧ください。在庫以外を含めた比較は、Excel管理の限界と、改善・SaaS・開発を選ぶ判断基準にまとめています。

2. 続けるか見直すかを整理する10のチェック

次の10項目は、困っている箇所を洗い出すための確認表です。該当数でシステム化の必要性を判定するものではありません。一つでも出荷停止や情報の不適切な共有につながる問題なら優先して対応し、軽い不便はExcelの改善で解消できるかを先に確かめます。

1. 出荷や発注を判断する時点までに、入出庫の記録がそろうか。
2. 正本の在庫表が一つに決まり、全員が同じものを見ているか。
3. 品番・場所・数量の単位を、担当者が変わっても同じ意味で使えるか。
4. 返品・破損・移動・引当・棚卸調整の記録方法が決まっているか。
5. 同じ取引の二重登録や、記録漏れを見つける手順があるか。
6. 在庫差異の原因を調べるための伝票や履歴が残っているか。
7. 見せてよい情報と編集してよい情報を、必要な範囲に分けられるか。
8. 作成者以外が数式・マクロの変更や復旧を担当できるか。
9. 受注・出荷・会計などへの転記が、必要なタイミングに間に合うか。
10. 繁忙時の件数でも、入力・確認・保存を業務に支障なく行えるか。

各項目には「問題が起きた場面」「頻度」「影響」「現在の対処」「見直す担当者」を添えます。改善前後で同じ項目を見れば、操作が速くなっただけでなく、確認の負担が減ったかも比べられます。日々の入力時間、棚卸差異を調べる時間、訂正件数など、今測れるものから記録すれば十分です。

例えば、二重登録が主因なら、取引番号の採番と重複確認を先に整えます。必要な時点まで記録が届かないことが主因なら、入力場所と連携を見直します。改善を試しても必要な条件を満たせない部分が、移行先に求める要件になります。

3. 自作・ノーコード・パッケージ・個別開発を比べる

選択肢は大きく4つあります。Excelの改善を含めて同じ業務を試し、できることと運用の負担を比べます。ノーコードとSaaSは分類が重なる場合もあるため、ここでは「自社でアプリを組み立てる方法」と「在庫管理向けの既製品を利用する方法」に分けています。

製品名だけで対応可否は決まりません。例えば「在庫管理ができる」と案内されていても、自社で必要なロット別の引当、返品時の検品、締め後の訂正まで同じ方法で扱えるとは限りません。普段の伝票を匿名化したサンプルで、入庫から棚卸まで操作して確認します。

比較時は、月額料金や開発費だけでなく、初期設定、データの整備、端末、教育、追加機能、連携、保守にかかる費用を同じ期間で並べます。Excelも、既にライセンスがあれば追加購入が不要な場合はありますが、作成・確認・引き継ぎに使う人の時間は必要です。「無料」と「負担がない」は分けて考えます。

将来、別の仕組みに移る場合のデータ出力も確認します。商品マスタだけでなく、入出庫履歴、ロット、添付資料、権限などのうち、何をどの形式で取り出せるかを確かめます。使い始めるときに出口も確認しておくと、担当者や取引先が変わったときの備えになります。

見積もりを比較するときの確認項目は、次の記事にまとめています。（システム開発の見積書で確かめる項目と比べ方）

4. システム化の前に整理する5つのこと

① どの単位で在庫を追うか

品番だけで足りるか、保管場所、ロット、シリアル番号、使用期限まで必要かを書き出します。また、実物の数、出荷可能な数、検品待ちの数など、業務で使う「在庫」の意味をそろえます。画面に一つの数字を出す前に、その数字に含めるものを決める作業です。

② 誰が、どこで、いつ記録するか

入荷、検品、棚入れ、出庫、返品、棚卸の順に、担当者・端末・記録のタイミングを整理します。通信が届きにくい場所、手袋をしている作業、紙の伝票が必要な場面も記します。事務所のPCだけで使える画面を作っても、現場で記録できなければ入力待ちは残ります。

③ 発注と在庫調整を誰が判断するか

発注点は単に色を付ける数値ではなく、誰が見て何をするかまで決めます。補充にかかる期間や需要の変動をどう確認するか、誰が基準を更新するかを整理してください。棚卸調整や廃棄についても、入力者と確認者を分ける必要があるかを確かめます。

④ どのシステムと何を受け渡すか

受注、販売サイト、配送、会計などに対し、渡すデータと受け取るデータを書きます。連携方法を先に決めるより、「注文確定後、いつまでに引当に反映するか」「キャンセルをどう戻すか」「同じデータを再送したらどう扱うか」を明らかにする方が、必要な仕組みを選びやすくなります。

⑤ 今のExcelの何を残し、何を移すか

列ごとに、入力元、使う人、必要な期間を確認します。現在庫だけ移せばよいのか、過去の入出庫まで必要なのかも決めます。古い品番の重複や空欄を新しいシステムへそのまま移すと、新しい画面でも同じ確認作業が続きます。データを整理する担当と、判断できない項目の相談先も用意します。

5. 小さく試して移す5ステップ

1. 現状を棚卸しする。 使っているファイル、伝票、担当者、更新の流れを一覧にし、困っている場面を具体化します。Excelだけでなく、紙や別システムを含めて確認します。
2. 試す対象と合格条件を決める。 一つの倉庫、一つの商品群など、日常業務を試せる範囲を選びます。入力が間に合う、差異を追える、別の担当者でも処理できるなど、業務に必要な条件を先に定めます。
3. 項目とルールを整理する。 品番や単位をそろえ、返品・移動・訂正の方法を決めます。必要な権限、確認者、履歴の保存方法もここで整理します。
4. 実際の取引の流れで試す。 通常の入出庫だけでなく、取消、返品、二重登録、通信中断なども確認します。入力者だけでなく、出荷や発注の判断をする人にも結果を見てもらいます。
5. 残高を照合して切り替え、定着を確認する。 基準日時の在庫を照合し、移行中に起きた取引も反映します。正本を切り替える日、旧Excelを参照用にする日、問題が起きた場合の戻し方を決めます。

並行運用は、長く続けるほど安心というわけではありません。どちらを正本にするか曖昧なまま二重入力を続けると、違いが出たときに判断できなくなります。比較する対象、担当者、終了条件を決め、確認が終わった範囲から切り替えます。

切り替え後も、最初の棚卸や繁忙期など、通常と異なる条件で確かめます。操作方法を覚えたかだけでなく、訂正が特定の担当者に集中していないか、Excelへの転記が増えていないかを見ます。現場の困りごとは、原因と対応を記録して次の改善に回します。

6. 在庫表の見直しを相談するときに用意するもの

仕様書を完成させてから相談する必要はありません。今の在庫表の項目、入出庫の流れ、困っている場面が分かれば、検討を始める材料になります。実データを渡す前には、取引先名や原価などの扱いを確認し、必要に応じて匿名化したサンプルを用意してください。

Ouverは、Excelや紙で管理している業務のシステム化を、業務の整理から開発、運用保守まで支援しています。新しく作ることを前提にせず、既存の仕組みを活かす方法や市販サービスも比較します。対応内容と相談の進め方は、受託開発ページでご確認いただけます。

既にシステムがある場合は、部分改修や再構築も候補になります。PHP 5の在庫・受発注管理システムを再構築した事例では、既存業務を調べて必要な機能を引き継いだ進め方を紹介しています。Excelからの移行事例ではありません。

業務システム開発の対応内容・進め方を見る