読みもの

精肉店の在庫管理、スプレッドシート自作はなぜ挫折するのか

精肉店やスーパーの精肉部門で、ExcelやGoogleスプレッドシートを使った在庫管理に取り組んだものの、

このような問題で悩んでいませんか？

実はこれ、すべて私自身が精肉の現場で経験してきたことです。私が以前働いていた店舗の在庫管理は、 多くの店舗で見られるような、こんな管理方法でした。

• 目視だけで賞味期限を監視する
• 期限が切れていたら社員同士で口頭で指摘する
• 賞味期限が近いものは、とりあえず冷凍庫へ移動させる

なぜ、毎日たくさんの生肉を扱うプロの現場で、このような原始的な管理になってしまうのでしょうか。 その理由を自分なりに分析してみました。

なぜ精肉の現場は「人の注意力」に頼ってしまうのか？

原因は、精肉現場特有の「忙しさと心理的ハードル」にあります。

1. 現場は加工作業だけで手一杯：日々セールの準備やパック詰めに追われ、在庫管理に割ける時間や人手がそもそも残っていません。
2. 専用システムへの心理的ハードル：導入コストが高く、設定や操作も大掛かりに感じられ、「うちの規模には合わない」と思ってしまいます。
3. 「タダで今すぐ始められる」誘惑：目視や社員間の声かけは、お金もかからないし今日から始められます。

だからこそ、一番手軽な「人の注意力」に頼る形に落ち着いてしまうのです。

しかし、これは大きな罠です。賞味期限切れや見落としのリスクを、常に「誰かが気づくかどうか」という属人的な運に賭けている状態です。 管理コストがゼロな代わりに、見落とした時の代償（廃棄コスト、ブランド失墜、最悪の場合は食品事故のリスク）は100%残り続けます。

そこで「この状況を変えなければならない」と考えた私は、現場で使えるツールとして、Googleスプレッドシートを使った 在庫管理システムの構築に挑戦することにしました。（エクセルで管理されている方も多いと思いますが、私が使っていたのは スプレッドシートです。関数が複雑化して崩れていく、属人化する、という課題はExcelでもまったく同じなので、Excelで 管理されている方にもこの先は当てはまる内容だと思います。）

私が構築したスプレッドシート在庫管理の全容

「やるからには完璧なものを」と思い、次のようなシート構成を設計しました。

• 商品マスタ：取り扱う商品の基本情報（コード・名称・部位・単価など）を一元管理
• 入庫履歴：いつ・何を・どれだけ仕入れたかの記録
• 出庫履歴：いつ・何を・どれだけ出荷・販売したかの記録
• 在庫一覧：入庫と出庫の差分から、現在の在庫を自動算出

このほかにも、取引先マスタや設定シート、在庫のアーカイブなど、補助的なシートを複数用意しました。

さらに精肉店ならではのものとして、加工記録シートも作り込みました。 ブロック肉からパーツやパックへ加工するたびに、原料（枝肉・個体識別番号）とできあがった製品の重量を入力すると、 法令遵守（トレーサビリティ）の記録と歩留まり（ぶどまり）計算が 同時にできる仕組みです。

実際、加工記録は以下のようなレイアウトで作成していました。

【挫折】SUMIFSやINDEX・MATCHの限界と、GAS（自動化）という最大の悪手

スプレッドシートで構築を進めるうちに、精肉ならではの大きな壁にぶち当たりました。

それは、「1つの原料（塊肉）から複数の製品（バラ、ロース、ミンチなど）が生まれる」 「個体識別番号の紐付けが必要」という、複雑なデータ構造です。

これをスプレッドシートの関数だけで解決しようとすると、SUMIFS、 INDEX、 MATCH、 さらには配列数式が複雑に絡み合い、少し数式を触っただけでシステム全体が壊れてしまうほどデリケートなものになってしまいました。

「それなら、マクロやGAS（Google Apps Script）でプログラムを組んで自動化しよう！」

そう考えた私は、日中の過酷な加工作業を終えたあと、夜遅くまでパソコンに向かってスクリプトを書き続けました。 夜遅くまでの作業が続くうち、心身の負担は少しずつ積み重なっていきました。今振り返ると、あのペースを長く続けるのは 無理があったと思います。ちょうどそのタイミングで、私はその職場を離れることになりました。

職場を離れて気づいた、自作システムの本当の恐怖

職場を離れて冷静になった時、私は重大な間違いに気づきました。「GASやマクロで解決させる方法こそ、 現場にとって一番の悪手である」ということです。

考えてみてください。この記事を読んでいるみなさんは、なんとかExcelやスプレッドシートで在庫管理を実現しようと、 人一倍熱意を持っている素晴らしい方々だと思います。しかし、私のように現場業務と開発を一人で抱え込んで、 心身に無理を重ねてしまったらどうなるでしょうか？

無理を続けられなくなって、その仕事を離れることになったら、あなたの生活は？ ご家族は？ 言うまでもなく、在庫管理どころではありませんよね。

さらに重要な問題があります。「その自作スクリプトの保守（メンテナンス）は、 あなたが辞めた後、一体誰が担当するのですか？」

あなたが良かれと思って作った複雑なスプレッドシートやプログラムは、あなたがいなくなった瞬間、誰も触れない 「ブラックボックス」と化します。これは私の店舗だけの話ではなく、自作の仕組みで在庫管理をしている現場なら、 どこでも起こりうることです。

• 作った本人にしか、数式やスクリプトの意味が分からない：他の人には「なぜか動いている魔法のシート」にしか見えません。
• 担当者が異動・退職したら、誰も直せない：引き継ぎ資料を作っても、GASや配列数式を読める人が現場にいなければ意味がありません。
• 関数を1セル消しただけで、集計が全部止まる：悪意がなくても、誰かがうっかり触るだけで壊れます。しかも「どこが壊れたのか」を特定できるのは作った本人だけです。
• GoogleやMicrosoftの仕様変更で、ある日突然動かなくなる：自分は何も変えていないのに壊れる。これが自作ツールの一番怖いところです。

つまり自作のスプレッドシート管理は、「作れるかどうか」ではなく 「作った人がいなくなった後も回り続けるかどうか」で失敗するのです。

頑張るあなたを犠牲にしない。精肉店専用システム「MeatShip」

スプレッドシートやExcelで頑張って仕組みを作ろうとすることを、私は絶対に否定しません。その熱意は本当に素晴らしいものです。 ただ、「頑張った先に、あなた自身の身体や生活、核心である現場の持続可能性を 犠牲にする必要は絶対にない」ということだけは、強く伝えたいのです。

そこで私は、スプレッドシートの延長で頑張るのをやめて、最初からデータベースを 前提にした在庫管理システムを自分で作ることにしました。一人の担当者が過度な負担を背負い込まなくても、 誰が抜けてもシステムとして動き続ける。そんな現場の受け皿になることを目指したものです。

それが、精肉店専用の在庫・歩留まり管理システム「MeatShip（ミートシップ）」です。

MeatShipが解決するスプレッドシート自作の限界

• 関数・プログラミングは一切不要：スプレッドシートのように数式が壊れる心配はありません。
• 精肉特有の「加工・歩留まり管理」に標準対応：原料（個体識別番号）から製品へのバラシ、および歩留まり計算が自動で行われます。
• 紙のような使いやすさとクラウド管理：従来の紙の帳票に近い感覚で直感的に入力・印刷でき、データは安全にクラウドへ保存されます。

現場の「誰か」が仕組みを無理に背負い込む時代は、もう終わりにしませんか。 「MeatShip」は、精肉の現場が本来の加工作業と安全な経営に集中できるよう、今もアップデートを続けています。

少しでも現状の在庫管理に不安や限界を感じている方は、ぜひ一度、詳細をご覧いただくか、実際の画面を触ってみてください。