エクセル在庫管理「このまま続けて大丈夫か」を5分で確かめる——今すぐ使える崩壊前チェックリストと、次の行動地図 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

まず確かめる——エクセル在庫管理「崩壊前チェックリスト」12項目

以下の12項目を読み、自社の状況に当てはまるものを数える。正直に確認することが重要で、「まあ何とかなっている」という主観は一旦置いておく。

• ✅ ファイルの更新担当者が1名しかいない（担当者の休暇・退職で即座に止まる構造）
• ✅ 月末や棚卸し期間中は、他の業務が実質止まる
• ✅ 在庫数の「正」がどのファイルにあるか、担当者以外は即答できない
• ✅ ファイルを誰かが開いたまま別の人が更新できず、待つことがある
• ✅ 在庫データと実際の棚の数が月1回以上ズレている
• ✅ 過去3か月で欠品や過剰発注が1件以上発生した
• ✅ 取扱SKUが増えたときに既存フォーマットで対応できず、列や行を継ぎ足した
• ✅ 倉庫・拠点が2か所以上あり、それぞれ別のエクセルで管理している
• ✅ 販売チャネル（実店舗・EC・卸）が複数あり、在庫情報の同期を手作業で行っている
• ✅ ファイルが重くなり、開くまでに10秒以上かかることがある
• ✅ 過去バージョンのファイルがフォルダに複数残っており、最新版がどれか迷う
• ✅ 「在庫が合わない原因」を追うのに30分以上かかったことがある

チェックリストで見えてくる「3つの崩壊経路」

12項目は見た目は別々だが、崩れ方のパターンは大きく3つに収束する。自社がどの経路に近いかを把握しておくと、次の行動が絞りやすくなる。

崩れ方のパターンによって「最初に手をつける場所」が変わる

経路A：担当者依存崩壊

「あのファイルは鈴木さんしか触れない」という状態が典型。鈴木さんが有給を取った週に棚卸しが重なって初めて、依存の深さが露わになる。表面的にはデータの問題ではなく、「誰がどのルールでファイルを更新しているか」を文書化していないことが根本にある。ここへの対策は、まずルールと手順の明文化から入る。システム移行の前に整えておく作業でもある。

経路B：規模拡大による破綻

創業期に作ったフォーマットを、SKU数が10倍・20倍になっても使い続けているケース。300行だったシートが3,000行になり、条件付き書式が複雑に絡み合って「開けるが使えない」状態になる。この経路の特徴は、問題が突然ではなく少しずつ悪化していくため、担当者が慣れてしまうことだ。ある日急に「作り直す時間がない」という状況に陥る。

経路C：多拠点・多チャネル分散

実店舗の在庫ファイルとEC倉庫のファイルが別々に存在し、担当者が手動で突き合わせている。チャネルが増えるたびにファイルが増え、「どれが最新か」だけでなく「どれが正しいか」まで分からなくなる。物理的な分散が情報の分断を生む構造で、エクセルの問題というより「在庫情報の一元化」の問題だ。

崩壊経路別「最初にやること」行動リスト

チェックリストの結果と崩壊経路が把握できたら、次は具体的な行動に落とす。「システムを入れる前に何をするか」と「システムを選ぶときに何を基準にするか」の2段階で整理する。

「システムを入れれば解決する」という順序では動かない。移行前に整える作業を先に進めないと、エクセルの問題をそのままクラウドに持ち込むことになる。上の表はその準備の起点として使ってほしい。

エクセル運用を「続けるか・変えるか」の判断軸

チェックリストで6項目以上に該当したとしても、即座に高額なシステム投資が正解とは限らない。判断に使える軸を3点だけ整理する。

①「修正コスト」と「移行コスト」を比べる。エクセルの運用を整備し直すコスト（担当者の工数・ルール整備の時間）と、クラウドシステムの導入・運用コストを並べたとき、どちらが現実的か。SKU数が100以下で拠点が1か所なら、エクセルの整備で十分なケースもある。

②「次の成長」でどちらが詰まるかを見る。半年後に新チャネルを開く、拠点を増やす、スタッフを2倍にするなど、事業側の変化が決まっているなら、エクセル整備では早晩追いつかない。移行のタイミングは「今困っているか」より「次の変化に耐えられるか」で決まることが多い。

③「何が一番痛いか」から入る。欠品による機会損失が最も痛いなら在庫連動が先決で、棚卸し工数が最も痛いならハンディ連携が先決だ。「在庫管理システムを入れる」という大きな括りではなく、「今最も摩擦を生んでいる業務はどこか」を起点にすると、機能要件が絞りやすくなる。

クラウド型の在庫・受発注管理ツールでは、バーコード・ハンディ連携や複数倉庫・複数チャネルの一元管理に対応したサービスが増えている。Spesもそうした機能を持つ中小企業向けのSaaSのひとつだ。「自社の経路がCで、EC在庫の一元化が最も急ぎ」という場合のような、具体的な課題が固まった段階で比較検討に入るのが現実的なステップだ。

どの選択肢が自社に合うか迷う段階であれば、Spesへの相談・お問い合わせから状況を伝えてみるのも一つの方法だ。機能の説明より先に、現状の課題を整理する話から始めることができる。

よくある質問

エクセルが重くて遅いだけで、データ自体は合っている場合でも移行を検討すべきですか？

動作の遅さ自体は直接の実害ではないが、「開くのが億劫になる→更新頻度が下がる→データの鮮度が落ちる」という連鎖が起きやすい。また、ファイルサイズが大きくなった原因（SKU増・履歴蓄積・複雑な数式）は、今後さらに悪化する一方だ。データが今は合っていても、運用の持続可能性として考えると早めに移行の検討に入る理由がある。

チェックリストで3〜5項目に該当しました。今すぐシステムを入れるより先にやるべきことはありますか？

この段階では、まず「更新ルールと担当者の明文化」「SKU・品目マスタの整理」を進めることを勧める。これらはシステム移行時にも必要な作業なので、今やっておけば移行コストも下がる。並行してシステムの情報収集・デモ確認を始める時期としては適切だ。

倉庫が2か所あり、現在は別々のエクセルで管理しています。統合はシステムなしでもできますか？

共有ファイルやGoogle スプレッドシートで一本化する方法はあるが、同時編集時の競合や更新漏れのリスクが残る。拠点数が2か所・SKU数が数百以内・関わる人数が3名以下であれば、スプレッドシートでの一本化が現実的な選択肢になりうる。ただし、拠点や取扱量が今後増える見込みがあるなら、その段階での移行コストの方が大きくなる可能性が高い。

在庫管理の「限界」は、ある日突然来るより、チェックリストで確認できる変化の積み重なりとして現れることが多い。今の運用が「まだ動いている」段階で現状を確かめ、次の行動を決める参考にしてほしい。

参考：政府統計・産業動向データは政府統計の総合窓口（e-Stat）でも確認できる。在庫回転率や業種別の出荷動向データを判断材料として活用したい場合に役立つ。