今日も「#REF!」のエラー修正に追われていませんか？
行を追加しただけで数式が壊れる。ファイルが重くて開かない。触った瞬間にレイアウトが崩れる。
そのストレス、痛いほど分かります。
そして多くの人が、「もっとマクロを勉強すれば直せるはず」と考えがちです。
でも、ここが落とし穴です。
エクセル在庫管理が崩壊しやすい原因は、関数やVBAの技術不足というより、「設計図（モデリング）」がないまま家を建てていることにあります。
システム開発で本当に効くのは、コードを書く前の「設計」です。
本記事では、現場で効いた考え方を、プロの用語を振り回さずに、料理に例えて噛み砕きます。
※実話ベースの内容を含みますが、社名・個人・具体的な内部事情が特定されないよう、状況は一般化して記載します。
小規模の現場で「Excel運用が限界を迎える相談」を見ていると、壊れるExcelには共通点があります。
その共通点と、直すときに最初に手を付けるポイントを、実例ベースでまとめます。
この記事の結論（先に要点だけ）
- 崩壊の原因は「マクロ」より構造（設計）にあることが多い
- 在庫管理は「モノ（マスタ）」と「コト（履歴）」を混ぜると破綻しやすい
- 最小の再出発は入力／履歴（データ）／出力を分けること
この記事で得られること
- 「どこから崩れるのか」を構造で説明できるようになる
- Excelでも通用する「設計の型（最小3シート構成）」が手に入る
- 紙に書くべき要件定義のテンプレが手に入る
エクセル在庫管理の自作が失敗しやすい理由
「とりあえず」で作った表が招く悲劇
結論：「データ」と「集計・見た目」が同じシートに同居した瞬間から、Excel在庫管理は“壊れやすい設計”になりやすいです。
理由：在庫管理は、運用を始めたその日から要望が増える前提の業務だからです。
最初は「品目名・在庫数」だけで回っていても、現場はだいたいこう言い出します。
- 入庫・出庫の履歴を残したい（いつ、誰が、どれだけ動かしたか）
- 棚卸し差異を記録したい（帳簿と現物がズレた理由も）
- ロット番号・賞味期限・保管場所を持たせたい
- 返品・破損・社内移動など「例外」を管理したい
- 担当者別の操作ログが欲しい（誰がいつ触ったか）
この要望を、同じシートに「列追加」「行追加」「別枠の集計表追加」で継ぎ足すと、見た目はExcelでも中身はスパゲッティになります。
参照が増殖し、どこを直せばいいのか分からない状態に落ちやすいんですよね。
現場でよく見る典型パターン：
従業員数名の会社で、在庫をExcelで管理していました。
最初は「在庫一覧」だけだったのに、短期間で「入出庫履歴」「棚卸し差異」「発注点」「担当者メモ」を同じシートに増築。
結果、在庫一覧の途中に履歴用の行が割り込んで、SUM範囲がズレて在庫がマイナス表示。
焦って直そうとして行を挿入した瞬間、別の参照も壊れて連鎖し、最後は「触った人が悪い」みたいな空気になりました。
ポイント：「誰が悪い」ではなく、壊れる構造の上で運用していただけです。
具体例：「とりあえずExcel」の末期症状は、驚くほどパターンが固定です。
- 1行追加しただけで計算結果が変わる（原因が追えない）
- 前月は合っていたのに今月だけ合わない（参照範囲ズレ）
- 環境によってはファイルを開くだけで長時間かかる（計算式・条件付き書式・リンクが増えすぎ）
- 「ここは触らないで」が増える（運用で守る前提の設計）
- 担当者が休むと止まる（秘伝のタレ化）
ここで重要なのは、原因が「Excelの機能不足」だけではない点です。
混在しているから壊れる。壊れやすい構造の上で、みんなが必死に運用でカバーしているだけです。
自社のファイルが危険かどうか、セルフ診断：
- 同じシートに「入力欄」と「集計表」と「印刷用レイアウト」がある
- 途中に小計行・見出し行・空白行が入り、1行＝1件になっていない
- 式の参照先が別シートだけでなく、あちこちのセルに飛びまくる
- 「この列は触らないで」というルールが口伝になっている
2つ以上当てはまるなら、構造の見直しで改善余地が大きいです。
まとめ：「とりあえず」で作った表は、機能追加を重ねるほど絡まり、やがて誰も触れない爆弾になります。
この状態から抜ける一番シンプルな処方箋が「入力とデータを分ける」です。
図（挿入予定）：スパゲッティExcel vs 整理された構成
- 左：1シートに入力・データ・集計・印刷が混在（矢印だらけ）
- 右：入力／データ蓄積／出力が分離（線が少ない）
失敗の原因は「マクロの腕」ではなく「モデリング不足」
結論：Excelが崩壊しやすい根っこは「How（どう作るか）」ではなく、「What（何をデータとして持つか）」の設計＝モデリングが甘いことです。
理由：関数やVBAは道具です。
道具の前に「現実の業務を、どんな“型”で切り出すか」を決めないと、道具が増えるほど破綻しやすくなります。
在庫管理でよくあるのが、“在庫”と“履歴”をごちゃ混ぜにしてしまうケースです。
在庫は「今いくつあるか」。履歴は「いつ何が起きたか」。別物です。
モデリング不足で起きる“地味に致命傷”なズレ：
- 「品目」と「SKU（規格・色サイズ単位）」が曖昧で、担当者ごとに意味が違う
- 「入庫」「出庫」「返品」「破損」「移動」を全部同じ“入出庫”扱いにして理由が追えない
- 保管場所が複数なのに、在庫数を1つのセルに押し込めて棚別が崩れる
- 日付が「入庫日」なのか「伝票日」なのか混ざり、集計が信用されなくなる
具体例：現場では、だいたい犯人探しが始まります。
- 「関数が複雑だから壊れた」
- 「マクロが悪さをしている」
- 「Excelのバージョン差だ」
ただ、同じ関数・同じVBAでも壊れにくいファイルは壊れにくいです。
差が出るのは、土台（設計図）があるかの一点だったりします。
| 技術不足で詰まるケース（比較的わかりやすい） | 設計不足で詰まるケース（後から効いてくる） |
|---|---|
|
|
まとめ：マクロや関数を責める前に、現実の業務をどうデータ化するかを決める必要があります。
壊れにくい仕組みに近づける「入力／データ／出力」分離（MVCの考え方）
システム開発は「料理の下ごしらえ」と同じだ
結論：Excelでも「入力（画面）」「データ（蓄積）」「出力（集計・帳票）」を分けるだけで、壊れ方がかなり局所化します。
理由：壊れやすい在庫表の多くは、1枚のシートに全部を詰め込んでいるからです。
入力しやすいレイアウトの横で計算や集計を回し、さらに印刷用の見た目まで作る。
料理でいうと「まな板の上で、冷蔵保存も盛り付けも全部やる」みたいな状態です。
具体例（考え方を料理に翻訳）：
- データ（Model）：冷蔵庫の食材。同じ型で、黙って貯める場所
- 画面（View）：お皿。見やすく整える場所
- 処理（Controller）：調理。チェック、転記、計算、整形の担当
ここで言うMVCは「プログラミングの厳密な話」ではなく、Excel設計の考え方です。
難しい話は抜きにして、シート構成を次の3つに分けるだけでOKです。
- 入力シート（入力フォーム）
- データベースシート（履歴の蓄積）
- 出力・集計シート（在庫一覧、帳票、グラフ）
現場で起きがちな話：
入力欄のすぐ右に「月次集計」「棚卸差異」「発注点アラート」が並んでいるExcelをよく見ます。
担当者さんが「列を1本増やした」だけで、集計側の参照がズレて棚卸差異が全部狂う。
原因は関数の腕ではなく、“入力の都合”と“集計の都合”が同じ面に同居していたことでした。
そのとき私がやったのは、VBAを組み直すことではありません。
構造の引っ越しです。入力と蓄積を分けて、集計は別シートへ逃がしました。
すると「列追加＝全体崩壊」ではなくなり、修正が“局所対応”で済むようになりました。
| 役割 | シート例 | 置くもの／置かないもの |
|---|---|---|
| 入力（画面） | 入力フォーム |
|
| データ（蓄積） | DB_入出庫履歴 |
|
| 出力（集計） | 集計_在庫一覧／帳票 |
|
まとめ：入力とデータを分けるだけで、行追加・列追加の影響範囲が狭くなります。
壊れ方が「全体崩壊」から「局所の修正」に変わる。これが大きいです。
小さく始めるなら、ここだけ守ればOK（最低ライン）
- データ蓄積シートは「履歴専用」にする（現在庫を直接書き換えない）
- データ蓄積シートは「同じ列構成」を崩さない（途中に表を増設しない）
- 集計・印刷は別シートへ（データの横に作らない）
- ID（連番）を持たせる（後から紐づけが必要になった時に効く）
現実社会をそのまま「型」にする（モデリングの極意）
結論：設計で一番大事なのは、現実の業務と言葉を、そのままデータの型に落とすことです。
理由：現実とズレた型（シート構造）は、運用でムリが出ます。
ムリが出ると「例外対応」が増えます。
例外対応が増えると、Excelはだんだん“継ぎ足しの怪物”になって壊れやすくなります。
具体例（在庫管理でズレが起きやすいポイント）：
| 現実の言葉（現場の感覚） | Excelで持つべきデータ（型） |
|---|---|
| 品目（同じ名前でも規格が違う） | 品目マスタ（品目ID、名称、規格、単位、仕入先など） |
| 在庫（いま何個ある？） | 現在庫は「計算結果」で出す（履歴から算出） |
| 入庫／出庫（いつ、誰が、何を、いくつ動かした？） | 入出庫履歴（ID、日付、品目ID、数量、区分、担当者、理由など） |
| 保管場所（倉庫A、棚B-3 みたいな実態） | ロケーションマスタ＋履歴にロケーションID（必要なら） |
ここで大事なのは、「正解のテーブル設計」みたいな話ではありません。
現実の単位で分けることです。
現場の人が「それ別物だよね」と感じるものは、データでも別物として扱った方が後でラクになります。
ありがちな失敗：「現在庫」と「入出庫履歴」を同じ表で管理する
- 今日の在庫数を書き換える（＝過去が消える）
- あとから「いつ減った？」が追えない
- 棚卸差異を入れた瞬間、数字の意味が崩れる
この状態になると、関数を頑張るほど矛盾が増えやすくなります。
【実話】「承認フロー」の失敗から学ぶモデリングの重要性
結論：Excelでもシステムでも、現実の世界で「別物」なのに、データ上で混ぜると、後から詰まりやすくなります。
この章では、私が実際にやらかした「承認フロー」の失敗談を、在庫管理の設計にも転用できる形で解剖します。
失敗事例：書類管理テーブルに「承認印」を入れてしまった話
結論：「書類（モノ）」の中に「承認（コト）」を埋め込むと、運用が伸びた瞬間に袋小路に入りやすいです。
理由：現実世界でハンコが押されるのは「紙」ですが、ハンコ自体が紙から生えているわけじゃありません。
人間が「この書類は承認済み」と結び付けているだけです。
つまりモデルとしては、書類と承認は別の存在なのです。
当時の状況（リアルな流れ）
- 対象：従業員10名ほどの社内向け「書類管理＋承認フロー」
- 取り扱い：稟議・申請書など「承認が必要な書類」だけ
- 判断：スピード優先で、書類テーブルに承認ステータスを直で追加
- 結果：リリース直後は「問題なし」に見えた
具体例（破綻の瞬間）：運用が落ち着いた数か月後、要望が増えました。
- 承認不要の「手順書」「議事録」「共有資料」も同じ棚で管理したい
- 書類によって承認ルート（部長→役員など）を変えたい
- 「差し戻し理由」「承認コメント」も残したい
ここで一気に詰みやすくなります。
なぜなら、書類テーブルに承認項目を埋め込んだ時点で、データ構造がこういう思想になってしまうからです。
「書類＝承認を持っているもの」
でも現実は違いますよね。
承認は「書類に対して発生するイベント」であって、書類そのものの属性ではありません。
| × 悪い例：書類テーブルに承認を混ぜる | ○ 良い例：書類と承認を分ける |
|---|---|
|
書類テーブル（Documents）
起きること：
|
書類テーブル（Documents）
承認テーブル（Approvals）
得られること：
|
まとめ：「書類（モノ）」と「承認（コト）」は別物として設計する。
この分離ができると、承認が関係ない書類が増えても、設計が揺れません。
Excel在庫管理に置き換えると、同じ地雷がある
在庫表でよくある「混ぜるな危険」はこのパターンです。
- 商品マスタ（モノ）に、棚卸しの結果（コト）や差異原因（コト）を直で持たせる
- 現在庫（状態）と入出庫履歴（イベント）を同じ表でぐちゃっと管理する
「今は回っている」状態ほど危ないです。運用が伸びた瞬間に修正が地獄になりがちです。
PCを閉じて整理する。「要件定義」からの再出発
いきなりエクセルを開くと、設計ではなく“修理”が始まる
結論：Excelを開いた瞬間、あなたは「設計」ではなく「修理」を始めやすいです。だから崩れやすくなります。
理由：Excelは手が動く分、思考より先に“形”ができてしまうからです。
見た目が整う。関数も動く。マクロも書ける。
でもその時点で、頭の中にしかないルールが増殖します。
結果、後から社員が触った瞬間に壊れて「誰も触れないファイル」になりやすいです。
要件定義メモ：この5つだけは書き出してください
- 誰が操作する？（社長／総務／現場担当／パート）
- いつ入力する？（入荷時／出荷時／棚卸し時／月末締め）
- 何を記録する？（品目／数量／単位／場所／ロット／期限）
- 例外は何がある？（返品／破損／棚卸差異／移動／セット品ばらし）
- 最終的に何が見たい？（在庫一覧／欠品候補／月次推移／棚卸差異表）
今日やること（10分）
- 今のExcelから「入力している項目」を全部書き出す（列名でOK）
- その中で「モノ（マスタ）」と「コト（履歴）」に分ける
- 「履歴に残すべき例外（返品・破損など）」を3つ書く
- 最後に「見たい出力（在庫一覧／差異表など）」を1つ決める
これをやるだけで、次に作るシート構成がブレにくくなります。
そのまま使えるテンプレ：次の表をコピペして埋めるだけでも、整理の精度が上がります。
| 業務シーン | 入力者 | 入力項目 | ルール（単位/桁/必須） | 見たい出力 |
|---|---|---|---|---|
| 入庫 | 現場 | 品目、数量、入庫日 | 数量は整数、必須 | 在庫が増える |
| 出庫 | 現場 | 品目、数量、出庫先 | 数量は整数、マイナス不可 | 在庫が減る |
| 棚卸 | 総務 | 品目、実在庫、メモ | 差異理由は任意 | 差異表 |
拡張性を持たせるための「余白」の作り方
結論：少人数で作るなら、最初から完璧を狙わず、“壊れにくい余白”だけ確保してください。
理由：小さく作るのは正解です。
失敗しやすいのは、小さく作ったものを「変更できない形」で固めてしまうからです。
余白の正体は、豪華な機能ではありません。変更が来た時に“差し替え可能”な構造です。
- データ蓄積シートは「1行＝1レコード」を死守する
見出し行や小計行を途中に入れない。並べ替え・抽出・集計が安定します。
- 入力フォームは別シートに分ける
見た目を整えるのはフォーム側だけ。データ側は“素のまま”保管します。
- 集計は出力（レポート）シートに寄せる
データに集計表を置くと、追加のたびに参照が崩れやすいです。
- ID（連番）を持たせる
後から履歴や関連付けが必要になった時、設計変更がラクになります。
ここ、かなり重要です：
「画面（入力フォーム・帳票）」は壊れても直せます。
でも「データ」が壊れたら、復旧は一気に高額・高難度になります。
だから最初に守るのは、関数でもマクロでもなく、データの置き場所です。
まとめ
結論の再提示：エクセル在庫管理の失敗は「技術」だけではなく「設計（考え方）」で起きることが多いです。
マクロや関数を強化しても、設計図がないままでは、追加要望が来た瞬間に崩れやすくなります。
補足・注意点：今日紹介した考え方は、一晩で身につく魔法ではありません。
ただ、意識するだけで「壊れにくいファイル」に近づきます。
特に「入力」「データ」「出力」を分けるだけで、修正の地獄から距離が取れます。
コメント