在庫管理データベースの作り方。最小構成のテーブルとER図の3段階【FileMaker】

こんにちは。リナークのニシザワです。

在庫を持って製造や販売をしている会社では、紙やExcelで在庫表をつくっていることが多いと思います。ところが、担当者が増えたり品目が増えたりすると、「どれが最新の在庫表か分からない」「数字が合わない理由を誰も説明できない」という状態になりがちです。

この記事では、在庫管理をデータベースにするときの設計を、できるだけシンプルに説明します。最小構成のテーブルから始めて、発注やロケーションへ広げていく3段階のER図と、FileMakerで試せるデモファイルも用意しています。

※在庫管理に必要な設計は、管理したいレベルや、材料在庫か製品在庫かによって変わります。ここでは主要なテーブルと項目だけを簡略化して示します。

在庫管理をデータベースにすると何が変わるか

Excelの在庫表とデータベースのいちばん大きな違いは、「在庫数そのもの」ではなく「在庫が動いた記録」を残すところにあります。

• 複数人で同時に使える：ファイルのコピーが増えず、全員が同じ数字を見られます。
• 数字の理由をたどれる：いつ・何個入れたか出したかが残るので、在庫が合わないときに原因を調べられます。
• ほかの業務とつながる：発注、出荷、棚卸などのデータと結びつけられます。

在庫管理データベースの最小構成

最初に用意するテーブルは、次の3つで十分です。

1. 商品マスタ：品番、品名、単価など、商品そのものの情報
2. 取引先マスタ：仕入先の情報
3. 移動履歴：入庫・出庫の記録。日付、商品、数量、移動種別（入庫・出庫・調整）

在庫数は「移動の合計」で求める

設計でいちばん大切なのは、在庫数を直接書き換えないことです。

在庫数は、移動履歴テーブルの「入庫の合計 − 出庫の合計 ± 調整」で求めます。Excelのように在庫数のセルを上書きすると、数字が変わった理由が残りません。移動を1件ずつ記録しておけば、在庫が合わないときに、どの記録がおかしいのかを後からたどれます。

後で紹介する段階1のER図では、商品マスタに「数量_在庫」という項目があります。これは移動履歴から計算した在庫数を、一覧や検索で使いやすいように商品マスタ側にも表示しているものです。人が直接書き換える項目ではありません。

ER図とは

ER図（エンティティ・リレーションシップ図）は、データベースの中にどんな情報の塊（エンティティ）があり、それぞれがどうつながっているか（リレーションシップ）を表した図です。FileMakerでは、エンティティは「テーブル」と考えると分かりやすいです。

たとえば「商品マスタ」と「移動履歴」は、「1つの商品に、たくさんの移動履歴がある」という関係（1対多）になります。テーブルをつくる前にER図を描いておくと、何をどこに記録するかが整理でき、後から作り直す手間を減らせます。

在庫管理のER図：3つの段階

最初から全部入りの仕組みをつくる必要はありません。今の困りごとに合わせて、段階的に広げていくのがおすすめです。

段階1：シンプルな在庫管理

商品マスタ・取引先マスタ・移動履歴の3つだけの構成です。在庫数は移動履歴から計算し、移動種別で入庫と出庫を見分けます。

紙やExcelから最初に移るときの第一歩として、まずは「全員が同じ在庫数を見られる」状態をつくることが目的です。発注と連動した入出庫には対応していません。

このER図をもとに、「シンプルな在庫管理」を実際に動かせるFileMakerのデモファイルをつくりました。ダウンロードして、設計と画面の対応を確かめてみてください。

デモファイルのダウンロードと、ファイルを開くときのログイン情報は「「シンプルな在庫管理」を実現するFileMakerデモファイルのご紹介」にまとめています。

段階2：発注から入庫につなげる

発注をデータとして登録し、その発注データから入庫を記録できるようにした構成です。

発注の内容を入庫にそのまま使えるので、同じ情報を二度入力する必要がなくなり、入力ミスが減ります。「発注したのにまだ入っていないもの」も一覧で確認できます。

一方で、この段階ではロケーション（保管場所）を管理できないため、複数の倉庫や拠点の在庫は分けて見られません。また、1つの商品に仕入先を1つしか登録できないので、同じ商品を複数の仕入先から買う場合には対応できません。

段階3：ロケーションと複数の仕入先に対応する

ロケーションのテーブルを加えて、拠点や倉庫ごとに在庫を持てるようにした構成です。あわせて、商品マスタと取引先マスタのあいだに中間テーブル（商品_取引先）を置くことで、1つの商品を複数の仕入先から購入する管理ができるようになります。仕入先ごとの単価や条件も持たせられるので、購買管理の足がかりにもなります。

さらに必要になるもの

段階3でも足りなくなるのは、次のような管理が必要になったときです。

• 棚番の管理：同じ倉庫の中で「どの棚のどこにあるか」まで管理したい
• ロットや期限の管理：製造日・使用期限やトレーサビリティを追いたい
• 棚卸：棚卸時点の理論在庫（システム上の数）と実在庫（数えた数）を両方残し、差を記録したい

このあたりは、管理したい内容に合わせてテーブルを追加していきます。ロケーションの考え方は「在庫管理におけるエリアとロケーションの重要性と実践方法。」でも説明しています。

実例：手書き伝票から、データベースで一元管理するまで

私が前職のメーカーで物流センターを担当していたときも、在庫管理は段階的にデータベース化していきました。

最初の一歩：入庫をバーコードで記録する（2013年）

物流センターでは、入庫した製品を手書きの伝票に記入し、その伝票を見ながら人が基幹システムに入力していました。転記のたびにミスが起き、入庫作業は特定の担当者にしかできない状態でした。

そこで、FileMakerで入庫だけを記録する小さな仕組みを社内でつくり、小型の iOS 端末（iPod touch）とバーコードで入庫を登録できるようにしました。

• 伝票の削減：年139万円
• 作業時間の削減：年133時間
• 入庫業務の属人化を解消

広げる：別々だったシステムを1つにまとめる（2017年）

その後、出荷やピッキングへと仕組みを広げました。2017年には、オーダー品と在庫品で別々に動いていたシステムを、1つの物流管理システムにまとめました。基幹システムとはWeb APIでつなぎ、人が会計の数字を入力し直す作業もなくしました。

• 伝票の削減：年140万円
• 作業時間の削減：年1,960時間

最初から大きな在庫管理システムを入れたわけではありません。「入庫の記録」という1つの業務から始めて、必要になったテーブルを足していったことが、現場に定着した理由だと考えています。

FileMakerで在庫管理データベースをつくる利点

• 業務に合わせて小さくつくり、育てられる：段階1から始めて、段階2・3へテーブルを足していけます。パッケージに業務を合わせる必要がありません。
• 現場の端末で入力できる：iPhoneやiPadでバーコードを読み取り、倉庫の中でその場で記録できます。
• ほかのシステムとつなげられる：基幹システムや会計システムとデータを連携できます。

まとめ

• 在庫管理のデータベースは「商品マスタ」「取引先マスタ」「移動履歴」の3つから始められる
• 在庫数は直接書き換えず、移動履歴の合計で求める
• ER図を描いて、段階1（シンプル）→ 段階2（発注連動）→ 段階3（ロケーション・複数仕入先）と広げる
• 実際の現場でも、入庫の記録という1つの業務から始めて広げていくと定着しやすい

リナークでは、今の在庫表や業務の流れを一緒に整理し、どの段階から始めるのがよいかを考えるところからお手伝いしています。「Excelの在庫表が限界だけど、何から手をつければいいか分からない」という段階でも大丈夫です。お問い合わせから、今の困りごとをお聞かせください。