「わたし」はリラックスしようと思い、冷蔵庫からジュースの1Lパックを取り出し、コップについだ。無意識のうちに、このジュースはいつ買ったかなと、パックの賞味期限を確認した。そのとき、ふと自分が大事なことを一つ見落としていたことに気がついた。在庫量というのは、日々、変動しているではないか。このリンゴジュースも、自分が買ったときには1リットルあったが、飲んでいくうちに少しずつ減っていく。それを毎日まさか測ったり確認したりはできない。手間がかかりすぎるもの。いうことは、在庫数量のデータを台帳に登録したら、その登録日も同時に記録しないとまずいのだ。なると、あるべき台帳の姿は(4)の「保管場所別在庫テーブル・登録日付き」みたいなイメージになりそうだ。なんだか「わたし」は少し自信がなくなってきた。そもそも、部の備品を管理したいんだったよな。庶務係がまとめて注文を出す。それを部のキャビネにしまう。各人が、たとえば「わたし」が、ペンを必要なときに、庶務係に伝票を書いてペンを1本払い出してもらう・・。キャビネの中にペンが何本はいっているのかを登録するのは、ペンが文具屋さんから到着したときなのか、それとも各人に払い出すときなのか・・。「わたし」は急に、驚くべき真理に気がついた。いや、革命的なアイデアと呼ぼうか。業務のプロセスを考えてみると、実際に人が把握しているのは、保管場所にモノが出入りする数なのだ。保管場所にいくつモノが入っているか、ではない。表(5a)の入出庫テーブルを見てほしい。家の食べ物の例で行くと、たとえば8月12日に玉ネギを1個、冷蔵庫に入れました。結果、冷蔵庫の中の在庫量は1個になりました。14日に、八百屋から6個、玉ネギを買ってきてストッカーに置きました。結果、ストッカーの在庫は6個になりました。ところが翌日、冷蔵庫から1個、出して料理に使いました。自分たちが把握し、きちんと登録すべき実体は、入出庫のデータであって、在庫量はそこから計算で導出されるデータなのだ。入出庫の種類は、供給による入庫、消費のための出庫が基本だが、ある保管場所から別の保管場所に移動するための入庫と出庫もある。移動の場合、全体の在庫量は変化しない。考えてみると、部の備品在庫量も、月単位の記録が必要になりそうだ。そのためには(5b)のような「月別在庫サマリーテーブル」を、(5a)から計算して作成すればいい。表には月初材料量と、最新の在庫量を、それぞれ日単位で集計して更新する。過去の月については、最新在庫量=月末在庫量、ということになる。じつにスマートじゃないか。ああ、自分はなんて優秀で頭が良いんだろう!「わたし」は仕事の進み具合に満足した。見落としていることはないか?慎重な「わたし」は、もう一晩だけよく考えてみることにした。夕食のために豚肉の玉ネギ炒めを作っているときだった。冷蔵庫に玉ネギが見当たらないのだ。残っていたはずなのに。わたしは冷蔵庫の中をひっくり返し、中身をほとんど空っぽに出して探したところ、ようやくケースの後ろに引っかかって、つぶれかかった玉ネギが見つかった。あーあ、これじゃ食べられないや。自分が研修のために工場見学をしたときのことを思い出した。その工場では、ちょうど資材倉庫で「棚卸し作業」というのをやっていた。半期に1回の作業ということだった。部品類を全部棚から出して、数を数え直すのだ。なんでそんなことをやるのですか?とたずねたところ、「帳簿の数と現物の数が合っているか確認しているのさ」、という答えだった。「そして、傷んだり古くなって使えない部材は捨てるんだ」と。部の備品キャビネでも、同じ作業をやらなければいけないかもしれない。そのデータは、どう扱うんだろうな。「わたし」は(6)のような「棚卸しテーブル」を想像した。品番と、保管場所ごとに、棚卸し作業日を決めて、確認できた在庫量、そのうち廃棄すべき数量を入力する。結果として現在庫数量が導出される。したら棚卸しというのは、入出庫の一種として扱うこともできるかもしれないな。作業のサイクルが別だから、別の表にした方が便利かもしれない・・。夕方に感じた自信と高揚感が、夜のうちに傾きかけたばかりではない。翌朝、「わたし」はもっと面倒なことに気がついた。工場では確か、「ロット管理」というのをやっていた。工場でなぜロット管理が行われているかは、一緒に見学に行った同僚の質問に、工場の人がこう答えていた。「不良が見つかったとき、それがロット固有の不良ならば、そのロットだけを破棄すればいい。ロット管理していなかったら、全品を検査して破棄しなければいけない可能性が高まる」と。ペンやノートにロット管理が必要だとは思わないけれど。ロット管理が必要だったら、(7)のような「ロット別受払テーブル」がいるんだろうか。それを集計サマリーして在庫量のデータを作るのかな。ロットがいつもひとまとめで扱われるとは限らない。ロットの中から一部だけ払い出したら、それはどうするんだろう。・・というのは、むろんフィクションである(最初から分かっていたと思うけど^^;)。この例を通して、在庫のデータモデルについて、いくつか教訓を学ぶことはできる。在庫は実体データではない。入出庫から導出されるデータである。在庫管理には棚卸し業務が必須である。在庫をロット管理する場合もある。よる減損やロットアウト、倉庫間移動などなど、数々の業務要件があるのが普通だ。例に挙げたテーブルだって、まだまだ改良すべき余地もある(長くなるからもう書かないが)。たかが在庫管理システム、などとあなどると、結構痛い目にあうこともある。在庫管理は奥が深いのだ。世間で言うモノの管理(わたしの用語では、マテリアル・マネジメントないしマテリアル・コントロール)というのは、なぜか会社の中で単純業務と軽んじられるケースがある。モノを設計したり加工したりする方が本質だ、と思う人々や、お金の管理の方がずっと大切だと信じる人々などに囲まれて、仕事をしている。在庫量は見えて当たり前、在庫はちゃんと管理できて当たり前、みたいに扱われたりする。このような風潮は、少しは反省されてしかるべきだと考える。いったマインドセットのまま、自社のサプライチェーンが国境を超えて広がると、あっという間に仕事のプロセスが混乱してくるのは目に見えている。それと同時に、在庫データを扱うシステムについて、システム屋さんたちももう少し腕を磨いたらどうかと思うことがある。上の例でも分かるとおり、ちょっとした在庫管理でも、それなりのエンティティとリレーションの組立が必要になるのだ。したデータ構造の問題に決まった『正解』はない。データ・モデリングという仕事は、客観的・科学的な面もある半面、どうすればエレガントで美しく作れるかという、技芸(英語で言うArt)の面も併せ持っているからだ。この両面を磨くのに、在庫のデータモデルほど、格好の例題はないと思うのである。23:32はじめまして。22:20退路を断つことです。17:48本当にその通りですね。メッセージを入力してください。