在庫のシステム化は、何から決めますか？
最初に決めるのは、在庫を数える単位と、在庫が増減する時点です。この2つが決まらないと、画面も帳票も設計できません。
外注の相談をする前に決めておくことは、次の3点です。
- 在庫を数える単位（所要時間の目安: 商品マスタを見ながら2時間程度）
- 在庫が増減する時点（同: 倉庫と営業の担当者を含めて2時間程度）
- 置き場所をどこまで細かく持つか（同: 倉庫の確認を含めて半日程度）
この3点は仕様の前提になります。決まっていないまま見積もりを取ると、後から設計のやり直しが発生します。
在庫を数える単位を決める
同じ商品を、ばら、ケース、パレットのどの単位で数えるかを決めます。複数の単位を使う場合は、1ケースが何個かという入数をマスタに持たせ、内部ではばらの数で持つ形が扱いやすくなります。
つまずきやすい点は、入数が途中で変わる商品です。仕入先の仕様変更で1ケースの入数が変わると、過去の在庫数と換算が合わなくなります。入数はマスタに履歴を持たせるか、入荷の時点の入数を伝票側に記録する形にしてください。
増減が起きる時点を決める
在庫が減るのは、受注した時点か、出荷指示を出した時点か、実際に出荷した時点かを決めます。3つのうちどれを選ぶかで、画面に表示される在庫の意味が変わります。
実務では、実際に出荷した時点で在庫を減らし、受注済みで未出荷の数量を別に持つ形が多く使われます。こうすると、手元にある数量と、引き当て済みで動かせない数量の両方が見えます。
同じ考え方は入荷側にも当てはまります。発注済みで未入荷の数量を持つかどうかを決めてください。
置き場所をどこまで細かく持つか決める
倉庫が1つで棚の指定も無いなら、置き場所を持たない設計で足ります。複数の倉庫があるか、棚の番号で探している運用があるなら、置き場所を項目として持ちます。
つまずきやすい点は、最初から細かく持ちすぎることです。棚の番号まで持たせると、入出庫のたびに場所の入力が必要になり、現場の手間が増えます。いま紙の上で管理していない粒度は、システムでも持たない判断から始めてください。
なぜ表計算ソフトの在庫表は合わなくなるのですか？
入力の時点と実際の出入りの時点がずれ、そのずれを誰も検証できないからです。記録が残っていても、どこで合わなくなったかを追えません。
この状態が長く続く背景もあります。IPAの「DX動向2025」では、DXに取り組んでいると回答した中小企業の割合は大企業と比較して依然として低い水準にあり、人材不足、予算不足、経営層の理解不足が主な障壁として挙げられています。
出典: IPA「DX動向2025」
在庫表が合わないことは分かっていても、直す担い手がいないまま運用が続きます。
入力の時点がずれる仕組み
倉庫で商品が出た時刻と、事務所で在庫表を更新した時刻は一致しません。その間に別の受注が入れば、担当者は古い数量を見て回答します。
1日の終わりにまとめて入力する運用では、日中の在庫表は実態と違う数字を表示していることになります。在庫表の数字を信じて回答できないため、結果として倉庫に電話で確認する作業が残ります。
複数人で同時に触れない
表計算ソフトのファイルは、1人が開いている間は他の人が編集できません。営業が在庫を確認したいときに事務所が更新中だと、読み取り専用で開くか、待つことになります。
この制約を避けるために、担当者ごとにファイルを分ける運用が生まれます。分かれたファイルはいずれ突き合わせが必要になり、突き合わせの作業自体が新しい工数になります。
差異の原因を追えない
最も重い問題はここです。棚卸で数量が合わなかったとき、表計算ソフトの在庫表には現在の数量しか残っていません。いつ、どの伝票で、誰が変更したかが残らないためです。
セルの数字を直接書き換える運用では、書き換えた履歴も残りません。差異が出るたびに実地の数量で上書きし、原因の追究をあきらめることになります。次のセクションで、履歴を持つ設計を整理します。
つまずきやすい点は、この問題を入力の精度の問題だと考えることです。原因は担当者の不注意ではなく、履歴を持たないデータの持ち方にあります。
在庫の記録に持たせる項目は何ですか？
商品、置き場所、数量、単位、入出庫の区分、発生日時、伝票の番号、担当者を持たせます。現在の数量そのものではなく、入出庫の履歴を持つのが要点です。
| 項目 | 持たせ方 |
|---|---|
| 商品 | 商品マスタから選択。商品コードで持つ |
| 置き場所 | 倉庫マスタから選択。棚まで持つかは前述の判断による |
| 数量 | 数値。増加と減少を符号で持つか区分で持つかを決める |
| 単位 | 商品マスタ側に持ち、内部は最小単位に換算する |
| 入出庫の区分 | 選択式。入荷、出荷、返品、廃棄、棚卸調整など |
| 発生日時 | 実際に出入りした日時。入力した日時とは別に持つ |
| 伝票の番号 | 発注書や出荷指示書の番号。外部の伝票と突き合わせる鍵になる |
| 担当者 | 作業者マスタから選択 |
この表をそのまま開発会社に渡せば、データ設計の出発点になります。
現在庫は履歴から計算する
在庫の数量を1つの欄に持ち、入出庫のたびに上書きする設計は避けてください。上書きすると、その数字がどう作られたかが失われます。
入出庫を1件ずつ記録し、現在庫はその合計として計算します。こうすると、棚卸で差異が出たときに、どの入出庫まで遡れば辻褄が合うかを追えます。
つまずきやすい点は、件数が増えたときの表示の速さです。毎回すべての履歴を合計すると、数年分が溜まった時点で画面が遅くなります。対策として、一定の時点の数量を確定させて保持し、それ以降の履歴だけを足す設計にします。この仕組みは後から入れると影響が広いため、最初の要件に含めてください。
入出庫の区分を確定させる
区分は選択式にし、選択肢を最初に確定させます。入荷、出荷、返品、廃棄、棚卸調整、倉庫間の移動が基本の候補です。
区分を自由記述にすると、同じ意味の言葉が複数現れ、後から集計できません。廃棄と返品を区別しておくと、原価の把握にもそのまま使えます。
単位と入数の扱いを決める
単位は商品マスタ側に持ち、入出庫の記録は最小単位に換算した数で持ちます。画面ではケース単位で入力し、内部ではばらの数で保存する形です。
換算は必ず記録の時点で行い、換算前の入力値も残してください。入数が後から変わった場合に、当時の入力が何ケースだったかを確認できます。
棚卸の差異はどう扱いますか？
差異を消すのではなく、差異として記録します。実地の数量と帳簿の数量、その差、原因の区分を残す設計にします。
差異をそのまま上書きすると、翌期も同じ差異が同じ商品で発生していることに気づけません。記録として残せば、差異が特定の商品や担当者、特定の工程に偏っているかを確認できます。
差異を記録として残す
棚卸の記録には、次の4つを持たせます。
- 実地で数えた数量
- その時点の帳簿上の数量
- 差（実地の数量から帳簿の数量を引いた値）
- 原因の区分
在庫を実地の数量に合わせる調整は、前述の入出庫の履歴に「棚卸調整」の区分で1件追加する形にします。こうすれば、在庫が動いた理由が履歴の中に残ります。
つまずきやすい点は、調整を帳簿側の数字の書き換えで行う設計です。書き換えにすると、なぜその数量になったのかが履歴から消えます。
実地棚卸の入力を分けて持つ
実地で数えた数量は、通常の入出庫とは別の入力として持ちます。棚卸の作業は、対象を決めて一斉に数える性質があるためです。
棚卸の単位は、棚卸の回（実施日と対象範囲）で持ちます。1回の棚卸に複数の担当者が関わる場合は、誰がどの範囲を数えたかも残してください。差異の原因を追うときに、数え間違いの可能性を切り分けられます。
全商品を一度に数える方法と、区分を分けて順に数える方法があります。どちらの運用かで画面の作りが変わるため、要件として明記してください。
原因の区分を決めておく
原因の区分は選択式にし、選択肢を最初に決めます。数え間違い、入力漏れ、破損、紛失、原因不明が基本の候補です。
「原因不明」を必ず選択肢に入れてください。無理に原因を当てはめさせると、集計が実態と離れます。原因不明の件数が多い商品が見つかれば、そこに運用上の問題があると判断できます。
区分ごとの件数と数量を集計できるようにしておくと、翌期の棚卸の前に対策を打つ材料になります。
既存の仕組みと情報源をどう切り分けますか？
在庫の数量を持つ場所を1つに決めます。販売管理や会計、店舗の販売時点情報管理の仕組みが別にある場合、どちらを正とするかを先に決めます。
2か所で在庫の数量を持つと、必ず片方がずれます。ずれたときにどちらを信じるかが決まっていなければ、現場は両方を見て人手で突き合わせます。
情報源を1つに決める
決め方は単純です。在庫の増減が最も多く発生する場所を、正にします。卸売業では出荷と入荷が在庫の増減の大半を占めるため、それを記録する仕組みを正にするのが自然です。
会計側は、期末の在庫金額を出すために数量を必要とします。ただし会計側が日々の在庫を持つ必要はありません。正とした側から期末の数量を渡す形で足ります。
外部サービスから取り出せる範囲を確認する
既存の外部サービスを情報源にしたい場合は、そのサービスから何が取り出せるかを先に調べてください。取り出せる範囲が、そのまま設計の制約になります。
当社で、小規模店舗に広く使われている販売時点情報管理サービスを在庫や売上の情報源の正として扱う設計を検討し、公式情報で仕様を裏取りした際の結果をお伝えします。外部から参照できるAPIは読み取り専用で、取得できるのは限られたカテゴリの日次集計にとどまり、商品単品の粒度では取れず、書き込みのAPIも提供されていませんでした。
この場合、そのサービス側へ在庫数を書き戻す運用は成立しません。CSVの受け渡しを前提に設計するほかない、という結論になります。
実装者としてつまずきやすい点
上のような制約が分かった後に問題になるのが、在庫更新の並行性です。CSVを全件上書きする方式にすると、ファイルを書き出してから取り込むまでの間に発生した売上が、警告もなく消えます。
当社ではこの設計を差分のみを反映する方式に変更し、取り込みは営業時間外のバッチに寄せ、送信済みかどうかのフラグを持たせて二重反映を防ぐ形にしました。
外部サービスの仕様の制約は設計を縛りますが、縛られ方を先に調べておけば、後から気づく整合性の事故は避けられます。要件を決める段階で、連携したい相手の仕様を確認してください。連携の設計そのものは論点が多いため、詳しくは情報源の一元化を扱った記事を参照してください。