トランザクションとマスターを意識したエンティティの導出や、関連の多重度や向きを意識したリレーションシップが使いこなせるようになってくると、「自分、結構モデリング上手にできるんじゃないか」と思い始める時期が来ます。システムが小さいうちは割と乗り切れることもあるのですが、システムが大きくなると乗り切れなくこともあります。
ここでは、今まで自分が出会ったモデリングが難しかった事例を紹介していきます。
受注と出荷の関連付け
「あれ、先輩？ なんですか、このへんなキャラクターは？」
「こらこら、変とか言っちゃダメだよ。これは大切なお得意様の社長自らが書かれた、マスコットキャラクターなんだよ。名前は確か、チョロ太郎？ だったかな」
「はあ、で、このチョロだかチュロだかのキャラクターが、なんなんですか？」
「なんでも、このキャラクターの人形がついたキーホルダーを作って売り出すらしく、その受注管理システムの開発を請け負うかもしれないんだ」
「はー、売れるんですかね？」
「ちょうどいい。この商品の受注と出荷を管理するモデルのモデリングを、お願いしても良いかな？」
「はーい」
もう新人とは言えなくなってきた、三年目の元新人くんは上手にモデリングできるでしょうか？
シンプルなモデリング
ここでは、受注した注文を出荷したどうかを管理することにだけ注目して、モデリングを行ってみます。
例えば、一つの注文に対して１ないし複数回の出荷を行うような状況を想定します。この時、次のようなER図が書けるでしょう。
さて、どうでしょうか？
バカ売れ
某ベンチャー企業にて。
「社長！ 超国民的アイドルが、なぜかちゅら太郎キーホルダーを気に入ったらしく、SNSで拡散されてます！」
「なんだと？ 注文はどうなってる？」
「今朝から、じゃんじゃん注文の電話が鳴ってます」
「よし、売りまくるぞ」
「今の所の注文数は？」
「昨日までの段階で3200個。今日さらに300個の追加注文が入る予定です」
「在庫は？」
「昨日入庫があったので、今は2300くらいは出せそうです」
「よし、出荷だ」
モデリングが破綻
こんな修羅場になってくると、現場は受注に対して出荷をするといった丁寧なオペレーションはもはや行えません。受けるだけ受けて、あるだけ出すという自転車操業的な感じになります。受注と出荷の関係も親子関係がなくなり、あえて言えば多対多の関係になってしまいます。
こんな中でも無理やり受注を消し込もうとする場合には、どうすれば良いでしょうか？
解決案
多対多の関係を1対多にするためには、中間テーブルを使う方法が考えられます。
ここで、出庫から見て受注と出荷の多重度が0..1ではなく1であることに注目してください。つまり出荷は、受注と出荷の両方がないと作れないのです。これは、現場のオペレーションとしては、受注残がある程度わかっている状況で、その数を越さないような現場のオペレーションありきで出荷がされた後、受注と出荷を繋ぎ合わせるような出庫を、システム上で計算しながら作り出すという想定となっています。
他にも、受注残に対してとにかくできる範囲で出庫を行い、それに対して出荷業務を行い出荷レコードを作成するというモデリングも存在します。
大切なのは「モデルを現場のオペレーションに合わせる」ということです。リアルに即さないモデルは、意味がなくなるか、激しい非難の的になります。
在庫金額の計算
「ところで、さっきの改良したモデルには『出庫』が出てきたけど、これは『在庫』から出ていったものだよね」
「そうですね」
「在庫を考える時には、在庫金額も考える必要がある」
「在庫金額って、なんですか？」
「平たく言えば、倉庫にある在庫全てが、いくらの価値があるかということだよ」
「その金額は、仕入れ値ですか？」
「そうなるね。じゃあ、在庫金額を考慮した在庫は君ならどうやってモデリングする？」
そう振られた３年目君は、んーと頭を捻ると次のようなモデルを書いてみる。
「なるほど、単品管理ね」
「なんですか、その単品管理っていうのは」
「このモデルだと、在庫一つにつきレコードが１件できることになるね」
「はい」
「そういう管理方法を、単品管理というんだよ」
「わざわざ『単品管理』というからには、そうではない管理方法もあるんですね」
「そうだね。例えば、このチョロ太郎……ちゅら太郎だったかな。そのキーホルダーが保存されている倉庫の状況を保存してみて」
「なんか、箱だか段ボールだかの入れ物に、ごちゃっと入っていそうですね」
「それら一つ一つにIDをつけたとして、特定のIDを持つキーホルダーを探し出すことはできると思うかい？」
「無理ですね」
「だろうね。他にもうなぎのタレのように継ぎ足して混ざってしまう商品だったら、なおさら単品管理は不可能だね」
「そういう時は、どうするんですか」
「色々方法はあるけど、まずはこんなモデルを書いてみようか」
「平均、ということはこれは商品一つにつき一レコードできる感じですか？」
「そうだね」
「確かにこれなら、入った数と出た数で数量を更新すれば良いので、現場もうまく回りそうですね。ただ、平均仕入金額、っていうのはどうすればいいんですか？」
「これはね、色々方法があるんだよ」
在庫金額における単価
ある時点の在庫の単価を得る方法は、次のようなものがあります。
| 計算方法 | 説明 |
|---|---|
| 先入先出法 | 入庫と出庫を記録しておき、最初に入庫したものを出庫したとして、計算する。入庫と出庫の記録を別途管理する必要がある |
| 総平均法 | 前月の在庫金額と、今月入庫した金額と数量から計算する。期末でないと金額が更新できない |
| 移動平均法 | 新たな入庫があった時に、その時点の在庫金額と、入庫した金額と数量から計算する。都度計算するのに手間がかかる |
| 最終仕入原価法 | 一番最後に入庫した商品の仕入れ値を、そのまま使う。計算がとても楽だがあまり正確ではない |
「なんだかよくわからないですね」
「この辺りは私もあまり得意ではないので、ネットで調べた情報をそのまま書き写してみたよ」
「それにして、在庫自体は変わらないのに、計算方法によって在庫金額が変わってしまうのは、何か変な感じがしますね。正しい在庫金額っていうものはないんでしょうか？」
「どの計算方法でも正しい在庫金額になるし、裏を返せば『正しい在庫金額』なんていうものは存在しないのかもしれないね」
「なんか寓話みたいですね」
「そんな高尚なもんじゃないよ。ただ『私たちはこうやって所有している在庫金額を計算しています』と決めておくことが重要だね。同じ指標で計算した値であれば、過去の値を分析として使えるからね」
「なるほど」
「これも、現場に合わせてモデリングをする必要がある例だよ」
財務会計
在庫金額の計算は、『企業会計』という考え方に沿って定義されています。正確な内容を知りたい方は、これをキーワードに検索して見てください。
最後に
モデリングは、たった一つの正解があるというものではないです。
ただ、明らかに間違いがあるという時もあります。
なぜそのようなモデリングに至ったのか、その根拠がぶれなければ、良いモデリングと言えるのではないでしょうか。