在庫のデータ構造を考える

「わたし」は新米のエンジニアである。最近、先輩からオフィス備品類の在庫管理を手伝うようにいわれた。ペンだとかノートだとかフォルダとかいった文具類が中心である。これまである意味、ルーズな管理だったが、経費節減の折、きちんと在庫数量を管理した方がいい、と部長が方針を出したとのことだ。今まで、各人が勝手にネットからモノを注文して取り寄せ、請求伝票だけが部の庶務係に回される。これをやめて、部で必要数量を考え、集中的に購入し、部のキャビネに保管しておく。そして各人が必要時に庶務係に申請して受け取る、という管理方式にかえることになった。その、キャビネの在庫管理の仕組み作りが、「わたし」の仕事だ。

在庫管理の仕事ははじめてだ。だからいきなり部の仕組みを作り始める前に、たとえば自分の家のモノを在庫管理するとしたらどうするかを考えてみることにした。題材は何でも良いが、出入りの多い食べ物にしてみよう。

在庫管理というのだから、何よりもまず、「在庫の表」が必要なはずだ。何が何個ある、そういう台帳のようなものだ。そのイメージは、表(1)のようにするのが良さそうだ。まず、品番がある。次に品名が来る。そして在庫数量と、数量単位だ。ここでは、いろいろなモノに品番をふって管理するのがポイントだ。たとえば「玉ネギ」ならば品番A12がといった風だ。こうすると、いかにも“プロが管理してる”っぽい感じがするではないか。うん、これがいい。

ところで、この表の中では、品番と品名は一対一に対応している。していないとこまる。同じA12が、ある行では「玉ネギ」で、別の行では「ほうれん草」では何が何だか分からなくなる。ということは、品番と品名の関係は、別の表で管理して、両者を関係づけるのが良さそうだ。つまり、在庫量のデータを表す(2a)「在庫テーブル」と、品名を登録する(2b)「品目マスタ」である。こういう風に、依存関係が混乱しないように独立させるやり方を、『正規化』と呼ぶんだと先輩が言っていたな。ま、この程度は初歩だよ、ワトソン君。

ん？　でも、ちょっと待てよ。考えてみると、同じ食べ物でも、家の中の置き場所はいくつかあるな。まず、冷蔵庫。それと冷凍庫か。一方、物置に近い場所にストッカーもあって、腐りにくい野菜類はそちらに置いたりもしている。うーん。じゃ、在庫テーブルには、保管場所の欄も必要らしい。同じ品番が、複数の保管場所に存在することもあるからな。となると、本当は台帳は(3)の「保管場所別在庫テーブル」みたいな形をしているべきなのか。そして、(2a)の「在庫テーブル」は、それを集計サマリーした結果の表ということになりそうだ。うむ。これでいいだろう。

「わたし」はリラックスしようと思い、冷蔵庫からジュースの1Lパックを取り出し、コップについだ。そして無意識のうちに、このジュースはいつ買ったかなと、パックの賞味期限を確認した。そのとき、ふと自分が大事なことを一つ見落としていたことに気がついた。

在庫量というのは、日々、変動しているではないか。たとえばこのリンゴジュースも、自分が買ったときには1リットルあったが、飲んでいくうちに少しずつ減っていく。ただ、それを毎日まさか測ったり確認したりはできない。だって手間がかかりすぎるもの。ということは、在庫数量のデータを台帳に登録したら、その登録日も同時に記録しないとまずいのだ。となると、あるべき台帳の姿は(4)の「保管場所別在庫テーブル・登録日付き」みたいなイメージになりそうだ。

これでいいのだろうか？　なんだか「わたし」は少し自信がなくなってきた。そもそも、部の備品を管理したいんだったよな。庶務係がまとめて注文を出す。文具が会社に届く。それを部のキャビネにしまう。各人が、たとえば「わたし」が、ペンを必要なときに、庶務係に伝票を書いてペンを1本払い出してもらう・・。

そうすると、ペンの在庫量のデータというのは、いつの時点で登録するんだろう？　キャビネの中にペンが何本はいっているのかを登録するのは、ペンが文具屋さんから到着したときなのか、それとも各人に払い出すときなのか・・。

「わたし」は急に、驚くべき真理に気がついた。いや、革命的なアイデアと呼ぼうか。「在庫は登録すべきデータではない！」

業務のプロセスを考えてみると、実際に人が把握しているのは、保管場所にモノが出入りする数なのだ。保管場所にいくつモノが入っているか、ではない。表(5a)の入出庫テーブルを見てほしい。家の食べ物の例で行くと、たとえば8月12日に玉ネギを1個、冷蔵庫に入れました。結果、冷蔵庫の中の在庫量は1個になりました。さらに14日に、八百屋から6個、玉ネギを買ってきてストッカーに置きました。結果、ストッカーの在庫は6個になりました。ところが翌日、冷蔵庫から1個、出して料理に使いました。すると冷蔵庫の中はゼロ個になり、今度は20日にストッカーから1個、玉ネギを取り出して冷蔵庫に移しました・・

自分たちが把握し、きちんと登録すべき実体は、入出庫のデータであって、在庫量はそこから計算で導出されるデータなのだ。そして入出庫の種類は、供給による入庫、消費のための出庫が基本だが、ある保管場所から別の保管場所に移動するための入庫と出庫もある。移動の場合、全体の在庫量は変化しない。

そして、考えてみると、部の備品在庫量も、月単位の記録が必要になりそうだ。そのためには(5b)のような「月別在庫サマリーテーブル」を、(5a)から計算して作成すればいい。表には月初材料量と、最新の在庫量を、それぞれ日単位で集計して更新する。過去の月については、最新在庫量＝月末在庫量、ということになる。じつにスマートじゃないか。ああ、自分はなんて優秀で頭が良いんだろう！「わたし」は仕事の進み具合に満足した。

これで完璧だろうか？　もう、見落としていることはないか？

慎重な「わたし」は、もう一晩だけよく考えてみることにした。そして夕食のために豚肉の玉ネギ炒めを作っているときだった。なぜか冷蔵庫に玉ネギが見当たらないのだ。たしか残っていたはずなのに。わたしは冷蔵庫の中をひっくり返し、中身をほとんど空っぽに出して探したところ、ようやくケースの後ろに引っかかって、つぶれかかった玉ネギが見つかった。あーあ、これじゃ食べられないや。

そしてなぜかふと、自分が研修のために工場見学をしたときのことを思い出した。その工場では、ちょうど資材倉庫で「棚卸し作業」というのをやっていた。半期に1回の作業ということだった。部品類を全部棚から出して、数を数え直すのだ。なんでそんなことをやるのですか？とたずねたところ、「帳簿の数と現物の数が合っているか確認しているのさ」、という答えだった。「そして、傷んだり古くなって使えない部材は捨てるんだ」と。

部の備品キャビネでも、同じ作業をやらなければいけないかもしれない。棚卸しかあ。そのデータは、どう扱うんだろうな。「わたし」は(6)のような「棚卸しテーブル」を想像した。品番と、保管場所ごとに、棚卸し作業日を決めて、確認できた在庫量、そのうち廃棄すべき数量を入力する。結果として現在庫数量が導出される。

でも、もしかしたら棚卸しというのは、入出庫の一種として扱うこともできるかもしれないな。でもまあ、作業のサイクルが別だから、別の表にした方が便利かもしれない・・。

せっかく夕方に感じた自信と高揚感が、夜のうちに傾きかけたばかりではない。翌朝、「わたし」はもっと面倒なことに気がついた。工場では確か、「ロット管理」というのをやっていた。これ、部の備品でも必要になるだろうか？　工場でなぜロット管理が行われているかは、一緒に見学に行った同僚の質問に、工場の人がこう答えていた。「不良が見つかったとき、それがロット固有の不良ならば、そのロットだけを破棄すればいい。もしロット管理していなかったら、全品を検査して破棄しなければいけない可能性が高まる」と。

まさかペンやノートにロット管理が必要だとは思わないけれど。でも、もしロット管理が必要だったら、(7)のような「ロット別受払テーブル」がいるんだろうか。それを集計サマリーして在庫量のデータを作るのかな。でも、ロットがいつもひとまとめで扱われるとは限らない。ロットの中から一部だけ払い出したら、それはどうするんだろう。それと、もしかりにロット不良が出たら、それは在庫量のデータとしてはどう扱うんだろう・・「わたし」は頭がくらくらしてきた・・

・・というのは、むろんフィクションである（最初から分かっていたと思うけど^^;）。ただ、この例を通して、在庫のデータモデルについて、いくつか教訓を学ぶことはできる。

(1) 在庫は実体データではない。入出庫から導出されるデータである。

(2) 在庫量は日時と紐づいてはじめて意味を持ち、通常はその履歴も必要だ

(3) 在庫管理には棚卸し業務が必須である。（棚卸し業務を経てはじめて実在庫量が確定し、それが収支決算のベースになる場合も少なくない）

(4) 在庫をロット管理する場合もある。

そして、この新米君のケースでは省略したけれども、在庫金額（＝単価×数量）、消費期限、シリアル番号、引当処理と有効在庫、品質検査結果による減損やロットアウト、倉庫間移動などなど、数々の業務要件があるのが普通だ。また、例に挙げたテーブルだって、まだまだ改良すべき余地もある（長くなるからもう書かないが）。だから、たかが在庫管理システム、などとあなどると、結構痛い目にあうこともある。在庫管理は奥が深いのだ。

世間で言うモノの管理（わたしの用語では、マテリアル・マネジメントないしマテリアル・コントロール）というのは、なぜか会社の中で単純業務と軽んじられるケースがある。モノを設計したり加工したりする方が本質だ、と思う人々や、お金の管理の方がずっと大切だと信じる人々などに囲まれて、仕事をしている。そして、在庫量は見えて当たり前、在庫はちゃんと管理できて当たり前、みたいに扱われたりする。このような風潮は、少しは反省されてしかるべきだと考える。そういったマインドセットのまま、自社のサプライチェーンが国境を超えて広がると、あっという間に仕事のプロセスが混乱してくるのは目に見えている。

それと同時に、在庫データを扱うシステムについて、システム屋さんたちももう少し腕を磨いたらどうかと思うことがある。上の例でも分かるとおり、ちょっとした在庫管理でも、それなりのエンティティとリレーションの組立が必要になるのだ。むろん、こうしたデータ構造の問題に決まった『正解』はない。データ・モデリングという仕事は、客観的・科学的な面もある半面、どうすればエレガントで美しく作れるかという、技芸（英語で言うArt）の面も併せ持っているからだ。そして、この両面を磨くのに、在庫のデータモデルほど、格好の例題はないと思うのである。