Excelで在庫管理を続けるリスクと移行先の選択肢

月末になると、必ず在庫数が合わない。棚には確かにあるはずの部品が、Excelの在庫表では「0」になっている。逆に、表の上では十分な数があるはずなのに、いざ出荷しようとしたら現物が足りない。担当者は毎回、倉庫と事務所を往復しながら数字を突き合わせ、原因を探すことに時間を溶かしています。

そこに追い打ちをかけるのが、二重出荷です。同じ注文を別の担当者がそれぞれ処理してしまい、同じ商品を2回発送してしまった。あるいは、すでに引き当て済みの在庫を知らずに別の注文に割り当ててしまい、片方の顧客に「欠品」と伝えなければならなくなった。原因を辿ると、たいてい「Excelの在庫表を複数人が同時に見ていて、更新のタイミングがずれていた」という話に行き着きます。

そして年に一度、あるいは四半期に一度の棚卸し。実際の在庫数とExcel上の数字を突き合わせる作業に、丸一日、あるいは二日がかりで人手を割いている会社も少なくありません。数字が合わなければ、どこかの入力ミスや二重入力を延々と探すことになり、担当者の疲弊は毎回のことながら軽くなりません。

この記事は、在庫管理をExcelで行っており、在庫数のズレ・二重出荷・棚卸しの手間に悩んでいる担当者に向けて書きました。情報システム部門の専門教育を受けておらず、総務や経理と兼任で在庫管理を担っている方を想定しています。専門用語は初出時に言い換え、Excelの限界がなぜ起きるのかという構造の説明から、移行先の選択肢の比較、移行時の注意点までを順に整理します。

この記事で分かること

結論を先に言うと、Excelでの在庫管理には「同時編集に弱い」「入力ミスを防ぐ仕組みがない」「関連する情報(受注・出荷・仕入れ)と自動で連動しない」という3つの構造的な弱点があります。在庫数のズレ・二重出荷・棚卸しの手間は、担当者の不注意ではなく、この3つの弱点から生じている症状であることがほとんどです。

この記事では、次の流れで解説します。

• Excelでの在庫管理で、なぜズレ・二重出荷・棚卸しの手間が起きるのかという構造
• 自社がどの程度深刻な状態にあるかをその場で確認するチェック項目
• 在庫管理の移行先として検討されることが多い選択肢の比較(kintoneなどのノーコードツール、在庫管理専用SaaS、フルスクラッチ開発)
• 移行を検討する際に、最初に押さえておくべき手順と注意点

一つ断っておきたいのは、この記事は「今すぐExcelをやめてシステムに移行すべき」と煽ることを目的にしていません。取り扱う品目数が少なく、担当者が1人で完結している状態であれば、Excelのままでも十分に業務が回るケースは実際にあります。まずは自社の在庫管理が、どの程度Excelの限界に近づいているのかを客観的に見極めることから始めましょう。

なぜExcelの在庫管理は「ズレる」のか。3つの構造的な弱点

在庫数がズレる原因を「入力ミス」の一言で片づけてしまうと、対策を誤ります。実際には、Excelというツールの仕組み自体に、在庫管理という業務と相性の悪い部分があります。ここでは3つの構造的な弱点に分けて整理します。

• 弱点1: 同時編集に弱い — 複数人が同じ在庫表を同時に更新すると、片方の変更が消える、または反映のタイミングがずれる
• 弱点2: 入力ミスを防ぐ仕組みがない — 手入力である以上、数量の入力ミス・二重入力・削除忘れが構造的に発生する
• 弱点3: 関連する情報と自動で連動しない — 受注・出荷・仕入れのデータが在庫表と別々に管理されているため、どこかの更新が漏れるとズレが生まれる

この3つは互いに独立した問題ではなく、組み合わさることで被害が大きくなります。次の章から、それぞれを具体的に見ていきます。

弱点1: 同時編集に弱い。「開いたもの勝ち」の構造

在庫表を複数人で更新する運用は、倉庫の担当者・営業事務・出荷担当など、規模の大小を問わず多くの会社で発生します。ところが、共有フォルダに置いたExcelファイルは、そもそも複数人が同時に書き込むことを想定した仕組みになっていません。

共有フォルダ上のExcelファイルを誰かが開くと、そのファイルには排他ロック(マクロなどの特殊な仕組みではなく、Excel自体が標準で持つ「自分以外の書き込みを禁止する仕組み」)がかかります。後から別の人が開こうとすると、「読み取り専用で開く」か「コピーとして別ファイルで開く」かの選択を迫られます。

• 最初に開いた人: 通常どおり在庫数を更新・保存できる
• 後から開いた人: 読み取り専用で開くか、コピーとして編集するかの二択になる
• コピーとして編集してしまった場合: 元のファイルとは別の実体になり、後で手作業によるマージ(統合)が必要になる

この「コピーとして編集」を選んでしまうと、事故が起きます。倉庫担当者が出荷処理で在庫を減らした直後、営業事務が別のコピーで入荷分を反映して上書き保存すると、倉庫担当者が減らしたはずの出荷分が復活してしまう、というようなことが起こります。どちらの操作にも誤りはないのに、保存の順番だけで数字が食い違う――これが「原因不明の在庫ズレ」の典型的な発生源です。

ある卸売業の在庫担当者は、朝一番に前日分の出荷を在庫表に反映していました。ところが別の担当者が同じ時間帯に入荷分を別のコピーで更新しており、後から保存した側の内容だけが残ってしまいました。結果、実在庫より20個近く多い数字が表示され続け、欠品に気づいたのは顧客からのクレーム電話でした。

さらに厄介なのが、「編集中です」の表示が出ないまま起きる事故です。Aさんがファイルを開いたまま離席し、Bさんが別のタイミングで開いて編集・保存し、その後Aさんが何も気づかずに保存すると、Bさんの変更はAさんの保存によって静かに消えます。ロックの仕組みは「今まさに開かれている」ことしか検知できず、開きっぱなしのまま放置された時間までは考慮してくれません。

このメカニズムそのものと、OneDriveやSharePointの共同編集機能を使った回避策については、別記事「Excelの同時編集ロック・上書き事故を防ぐ方法」で詳しく解説しています。在庫表の同時編集に心当たりがある方は、あわせてご確認ください。

弱点2: 入力ミスを防ぐ仕組みがない

Excelはあくまで汎用的な表計算ソフトであり、在庫管理専用に作られたツールではありません。そのため、入力ミスを未然に防ぐ仕組みが標準では備わっておらず、入力規則(VBAマクロやマクロを組んで独自に作り込むことは可能な、入力値を制限する機能)を細かく設定しない限り、次のようなミスが起こり得ます。

これらのミスは、1件1件は小さくても、月次・年次で積み重なると在庫数と実数の乖離が無視できない規模になります。しかも厄介なのは、ミスが起きた瞬間には誰も気づかないという点です。エラーメッセージも警告も出ないまま、次の集計や棚卸しのタイミングで初めて「合わない」ことが発覚します。

入力規則やマクロを使えば、ある程度はミスを減らせます。たとえば「入力できる数値の範囲を制限する」「マイナスの在庫数を入力できないようにする」といった対策です。ただし、これらは担当者自身か、社内に詳しい人がいなければ組めません。作った人が異動・退職すると、誰にも保守できない属人化した仕組みになりがちです。

さらに見落とされがちなのが、ミスが発覚するタイミングの遅さです。会計ソフトへの入力であれば、多くの場合は貸借が合わないという形で比較的早くミスに気づけます。ところが在庫表の数量入力ミスは、「見た目上は正常に保存できてしまう」ため、次に誰かがその数字を根拠に判断するとき(受注可否の確認、発注量の決定など)まで発覚しません。発覚が遅れるほど、そのミスを起点にした誤った判断の連鎖(在庫があると思って受注する、逆に在庫がないと思って余分に発注してしまう、など)が積み重なり、原因の特定にかかる手間も比例して増えていきます。

弱点3: 受注・出荷・仕入れと自動で連動しない

3つ目の弱点は、在庫表が単独のファイルとして存在し、受注データ・出荷データ・仕入れデータと自動的につながっていないことです。多くの会社では、次のような分断が起きています。

• 受注は受注管理システムまたは別のExcelファイルに入力する
• 出荷は倉庫の担当者が紙の伝票、または別のExcelファイルに記録する
• 仕入れは発注担当者がまた別のExcelファイルやメールで管理する
• 在庫表は、これらすべての結果を「誰かが手作業で転記」して初めて更新される

この転記作業のどこか一箇所でも漏れる、遅れる、間違えると、在庫表の数字は実態からズレ始めます。そして一度ズレると、次にどのタイミングでズレたのかを特定することが非常に困難です。すべてが手作業の転記に依存しているため、原因の追跡にはログも履歴も残っていないことがほとんどだからです。

二重出荷が起きる典型的なパターンも、この分断から生まれます。

1. 顧客Aから注文が入り、営業担当が在庫を確認して「引き当て済み」のつもりでメモする
2. しかし在庫表にはまだ反映されておらず、表上は在庫が残っているように見える
3. 別の営業担当が顧客Bからの注文を受け、表を見て「在庫がある」と判断し受注する
4. 実際には顧客A向けにすでに引き当てられていた在庫であり、出荷できるのは1件分だけ
5. どちらかの顧客に欠品を詫びる連絡をすることになる

この一連の流れは、担当者個人の確認不足というより、「在庫の引き当て状態をリアルタイムで共有する仕組みがない」という構造上の問題です。Excelファイルを開いて確認するという行為自体に、必ずタイムラグが生じるためです。

棚卸しがつらいのも、同じ構造が原因

年次・四半期ごとの棚卸しが重労働になる理由も、ここまで説明してきた3つの弱点の延長線上にあります。実在庫とExcel上の数字にズレが蓄積していればいるほど、棚卸しで発見される差異の件数が増え、その一つひとつについて「いつ、どの操作でズレたのか」を遡って調査する必要が出てくるからです。

棚卸し作業が重くなる典型的な流れを整理すると、次のようになります。

• 実地棚卸しで数えた数量と、Excel上の在庫数を突き合わせる
• 差異が出た商品について、過去の出荷・入荷記録を遡って原因を探す
• 原因が特定できない場合、実地の数量を「正」としてExcelを手作業で修正する
• 修正した内容が正しいかどうかを、誰も検証できないまま次の期に持ち越す

このプロセスの根本的な問題は、「差異の原因を追跡する手段がExcelには備わっていない」ことです。誰が、いつ、どの数字を、どのように変更したかという変更履歴は、Excelでは標準的には残りません。結果として、棚卸しは「差異を見つけて、なんとなく実数に合わせる」作業になりがちで、根本原因の解消にはつながらないまま、次の棚卸しでも同じ苦労を繰り返すことになります。

自社の危険度をセルフチェックする

ここまで説明した弱点が、自社にどの程度当てはまるかをチェックしてみましょう。以下の項目のうち、いくつ当てはまるか数えてください。

• [ ] 在庫表を2人以上で更新しており、「編集中です」の表示や上書きによるトラブルを経験したことがある
• [ ] 過去1年以内に、Excel上の在庫数と実物の数量が食い違っていたことがある
• [ ] 過去1年以内に、在庫があると思って受注したら実は欠品だった(二重出荷を含む)ことがある
• [ ] 受注・出荷・仕入れのデータが別々のファイルや紙で管理されており、在庫表への反映は手作業の転記に頼っている
• [ ] 棚卸しのたびに、差異の原因が分からないまま実数に合わせて修正している
• [ ] 在庫表を作った人・詳しい人が1人しかおらず、その人が不在だと更新が止まる
• [ ] 取扱商品(SKU)の数が増え続けており、Excelの行数・シート数がすでに管理しづらくなっている

3つ以上当てはまる場合は、Excelの限界が業務に実害を及ぼし始めている可能性が高い状態です。5つ以上当てはまる場合は、システム化の検討を先送りするほど、ズレの蓄積や事故のリスクが大きくなっていく段階にあると考えたほうがよいでしょう。

移行先の選択肢を比較する

Excelでの在庫管理に限界を感じた場合、移行先としてよく検討されるのは大きく3つの方向性です。それぞれの特徴を整理します。

kintoneなどのノーコードツールを検討する場合

kintoneに代表されるノーコード・ローコードツールは、プログラミングの知識がなくても、画面上の操作でアプリ(在庫台帳や受注管理の仕組み)を作成できる点が特徴です。在庫数のフィールドに入力規則を設定したり、受注アプリと在庫アプリを連携させて自動的に在庫数を増減させたりすることも、標準機能の範囲で実現できる場合があります。

サイボウズの公式サイトによれば、kintoneには30日間の無料お試し期間があり、試用期間終了後30日以内に本契約を申し込めば、試用中に登録したデータをそのまま引き継げます。まずは実際の在庫データの一部を使って試し、自社の業務に合う設計ができるかどうかを確認してから本契約を判断する進め方が現実的です。

kintoneでの移行の具体的な手順・費用感については、別記事「kintoneでExcel台帳を置き換える手順と費用感」で詳しく解説しています。

在庫管理専用SaaSを検討する場合

ロット管理・賞味期限管理・複数倉庫間の在庫移動・バーコードやハンディターミナルとの連携など、在庫管理に特化した機能があらかじめ用意されている点が、専用SaaSの強みです。業種や取扱商品の特性(食品、アパレル、部品など)に応じた専用SaaSも存在するため、自社の業種に近い実績を持つサービスを探すことが選定の第一歩になります。

一方で、専用SaaSは「在庫管理」という枠の中での柔軟性は高いものの、在庫管理以外の業務(たとえば案件管理や顧客とのやり取りの記録)まで含めて一元化したい場合には、複数のツールを併用する必要が出てくることがあります。導入前に、自社が本当に必要としている機能範囲を洗い出しておくことが重要です。

また、専用SaaSは月額利用料が発生する継続課金型のサービスが一般的です。導入時の初期費用だけでなく、取扱商品数や利用ユーザー数に応じて料金が変動するプランが多いため、自社の事業規模で運用した場合のランニングコストを事前に試算しておくことをおすすめします。無料プランやトライアル期間を設けているサービスも多いため、契約前に実際のデータで試せるかどうかを確認しておくと、導入後のミスマッチを避けやすくなります。

フルスクラッチ開発を検討する場合

既存のノーコードツールや専用SaaSでは表現しきれない、独自性の高い在庫引き当てロジックや、他の基幹システムとの複雑な連携が必要な場合は、フルスクラッチ開発(既存のパッケージやテンプレートを使わず、要件に合わせてゼロからシステムを構築すること)が選択肢に入ります。

ただし、フルスクラッチ開発は初期費用・開発期間ともに、ノーコードツールや専用SaaSより大きくなるのが一般的です。何を作るかを固める要件定義の精度が低いまま発注してしまうと、完成後に「業務に合わない」というミスマッチが起きやすく、手戻りのコストも大きくなります。いきなりフルスクラッチに踏み切る前に、まずはノーコードツールや専用SaaSで運用してみて、それでも解決しない要件が残った場合に検討する、という順番のほうが、リスクを抑えやすいでしょう。

移行を始める前に押さえておきたい3つの手順

どの移行先を選ぶにせよ、いきなりツールの契約から始めるのは避けたほうが安全です。まず押さえておきたい手順を整理します。

1. 現状の在庫管理フローを棚卸しする: 受注・出荷・仕入れ・在庫確認が、それぞれ誰が、どのファイルや紙で、どのタイミングで行っているかを一度すべて書き出す
2. 移行前にデータをクレンジングする: 表記ゆれ(同じ商品名なのに表記が異なる)、重複、不要な列・行が残ったままシステムに移行すると、新しいシステムでも同じ混乱が再発する
3. 小さく試してから本格移行する: 全商品を一気に移行するのではなく、まずは一部の商品カテゴリだけで試験運用し、問題点を洗い出してから全体へ広げる

このうち特にデータクレンジングは見落とされがちですが、非常に重要な工程です。Excelの在庫表には、長年の運用の中で蓄積された表記ゆれや重複が想像以上に多く残っています。この点については、別記事「Excelデータ移行で失敗しないためのデータクレンジング入門」で具体的な進め方を解説しています。

実務上の注意点として、移行作業中は「今まで使っていたExcelファイル」と「移行先の新しいシステム」の両方が一時的に並行稼働する期間が必ず発生します。この期間にどちらが正となるデータかを曖昧にしたまま運用すると、移行中にも二重出荷やズレが発生しかねません。並行稼働の期間と、切り替えのタイミングは、事前に社内で明確に決めておくことをおすすめします。

どこまでExcelで粘ってよいか。判断の目安

すべての在庫管理をシステム化すべきというわけではありません。次のような状態であれば、Excelのままでも当面は問題が起きにくいと考えられます。

• 取扱商品(SKU)の数が少なく、在庫表を更新する担当者が実質1人で完結している
• 受注から出荷までのリードタイムに余裕があり、リアルタイムでの在庫共有が求められていない
• 過去1年間、在庫ズレや二重出荷といった実害のあるトラブルが発生していない

逆に、この記事のセルフチェックで複数当てはまり、かつ取扱商品数や関わる人数が増加傾向にある場合は、Excelでの運用を続けるほど、ズレの蓄積・事故のリスク・棚卸しの手間が比例して大きくなっていく段階にあります。どこまでExcelで粘り、どこからシステム化すべきかという判断基準全体については、別記事「脱Excelの判断フロー」でより広い視点から整理していますので、あわせてご参照ください。

まとめ:ズレ・二重出荷・棚卸しの手間は、Excelの構造的な弱点から生まれている

最後に、この記事の要点を整理します。

• Excelでの在庫管理が抱える弱点は、「同時編集に弱い」「入力ミスを防ぐ仕組みがない」「受注・出荷・仕入れと自動で連動しない」の3つに整理できる
• 在庫数のズレ・二重出荷・棚卸しの手間は、担当者個人の不注意ではなく、この3つの構造的な弱点から生じている症状であることが多い
• 自社の危険度は、セルフチェック項目でいくつ当てはまるかを確認することで、客観的に見極められる
• 移行先には、kintoneなどのノーコードツール・在庫管理専用SaaS・フルスクラッチ開発という3つの方向性があり、業務の独自性や求める機能範囲によって向き不向きが分かれる
• 移行を始める前に、現状フローの棚卸し・データクレンジング・小規模での試験運用という3つの手順を踏むことで、手戻りのリスクを抑えられる

在庫管理のズレや事故は、一つひとつは小さな出来事に見えても、積み重なると顧客対応や資金繰りにまで影響が及ぶ、決して軽視できない業務課題です。「気をつける」という精神論だけに頼らず、ツールの構造そのものに向き合うことが、長期的に見て最も確実な解決策になります。

次に読んでほしい記事について

この記事では、Excelでの在庫管理が抱える構造的な弱点と、移行先の選択肢の比較を紹介しました。ここから先、Excel運用全体の見直しに関心がある方には、次の記事もあわせておすすめします。

• 在庫表の同時編集トラブルに心当たりがある方は、ロック・上書き事故を防ぐ方法を扱った記事
• 移行前のデータ整理に関心がある方は、データクレンジング入門の記事
• kintoneへの移行を具体的に検討している方は、手順と費用感をまとめた記事
• どこまでExcelで粘るべきか判断に迷っている方は、脱Excelの判断フローを扱った記事

それぞれの記事もあわせてご覧ください。まずはこの記事で紹介したセルフチェックを使って、自社の在庫管理がどの段階にあるのかを確認することから始めてみてください。