第39回IT勉強宴会に参加してきた。
大阪にDOAの一流モデラーが集まり、お互いのモデルを見せて、議論するというイベント。
聞いた内容を元に、感想をラフなメモ書き。
間違っていたら後で直す。
【参考】
第39回IT勉強宴会in大阪 : ATND
花束問題のしおり
花束問題V1.2
[#benkyoenkai] WHATとHOWの溝をモデルでつなぐ - 三要素分析法を考える -: ソフトウェアさかば
競演モデリング発表会＜第39回ＩＴ勉強宴会in大阪＞ | ＩＴ勉強宴会blog
PHPメンターズ -> IT勉強宴会「競演モデリング」の感想
nmrmsysさんはTwitterを使っています: "今回もエコまっしぐら省エネ感想ブログをキメたw ”第39回IT勉強宴会in大阪 競演モデリング発表会” http://t.co/YNoSvkkT7x #benkyoenkai"
【0】花束を作る花屋の業務モデルの意図
【0-1】上記のリンクに花束を作る花屋の業務用件が詳しく記載されている。
その問題は、佐野さんと渡辺さんが10年前に、MRPの初歩的事例として作ったものらしい。
つまり、BOM(部品表)を元に製造計画を作り、その計画を元にいつどれだけのモノが必要なのか、そしてモノの在庫はどのように管理すれば良いのか、を提示する問題として作った、とのこと。
すなわち、渡辺さんが提唱する在庫管理推移方式の事例として問題を作ったらしい。
その観点で花束を作る花屋の問題を読むと、実はこの花屋は第2次産業である製造業のカテゴリに含まれるように思える。
実際、業務要件のストーリーは、カーネーションやバラという品目(BOM)に対し、見込生産するために発注計画(MRPの元ネタとなる計画)を作り、受注のタイミングで、カーネーションやバラを選択して花束を作る加工指示が発生し、出荷され、送り状と一緒に花束が送付される。
【0-2】勝手な憶測では、この花屋は、ユニクロやナイキのような製造小売業(SPA：第5次産業)に近い。
つまり、原材料は調達するが、中国などのオフショアで安く衣料を開発し、その衣料を自社の直販店で販売する方式に近い。
もし、この花屋が、近くの畑で花を自家栽培していれば、農業・製造業・小売業のプロセスも自社で持つなら、いわゆる第6次産業になる。
製造小売業 - Wikipedia
第六次産業 - Wikipedia
最近のビジネスを見渡せば、卸売だけのような単なる小売業では、利益率が低い事例が多いと聞く。
だから、小売業を本業に持つ大企業は、自社ブランド製品(NBなど)を自社の工場で生産して販売するという製造小売業(SPA)のビジネスを持ち込もうとしている。
あるいは、日本の農業も6次産業化すべきだ、そのためにも農業に株式会社の発想を持ち込もうとする動きもある。
つまり、自分たちが販売する商品に付加価値をつける手法なわけだ。
もちろん、従来の小売業の業務しか知らない会社が製造業に手を出せば、すぐに在庫の山が作られて、逆に利益が出ない場合が多いだろう。
そんな流れの中で考えると、奥が深いと思う。
【0-3】花束を販売する花屋の在庫管理は意外に複雑だ、と鳥谷部さんが話されていたことから以下を連想した。
花は品目であり、部品表に相当する。
部品表であるからには、花のデータには、原価があり、発注時の最小ロット数もあり、調達期間や配送期間というリードタイムも設定されている。
花の種類は、カーネーションやバラもあれば、サイズも色も違う。
すなわち、花の部品表から、花束の見込生産の発注計画を自動作成することは原理的に可能だ。
それがMRPになるのだろう。
花束は、レシピという花の組合せで作られる。
受注時に、顧客から注文された花束がどのレシピなのか、が特定され、必要な花が特定の期間に特定の数量だけ在庫引当される。
お花という在庫は結構厄介だ。
お花はなまものなので、大量にお花を発注して在庫に持ちすぎると、腐ってしまう。
つまり、必要なタイミングで、特定の種類の花と本数を発注して、すぐに販売しなければならない。
すなわち、発注日と入荷日、出荷日というタイミング、リードタイムの制約が強すぎる。
一方、在庫にあるお花が少ない場合、せっかく受注しても、お花をすぐに出荷できなければ売上機会を失う。
本来、在庫があれば売上を確保できたのに、みすみす売上を失ってしまったわけだ。
例えば、お花は、誕生日や母の日、送別会など、特定の日に届けなければ無意味だから。
ちなみに、日本でお花が一番売れる日は、5月の母の日だと聞いたことはある。
母の日だけで売上の大半を稼ぐわけだから、賞味期間が短いお花の在庫管理は、売上にまさに直結する。
【1】T字形ERのモデル
T字形ERの生のモデルを見れたのが一番の収穫だった。
鳥谷部さんから聞いた話から理解したことを書く。
以下、T字形ERの理解で間違っていたら、後で直す。
【1-1】リソース重視
T字形ERでは、コード体系からエンティティを洗い出す。
例えば、ABC123というコードがあれば、顧客からヒヤリングして、ABCは顧客コードで、123は店番コードと意味付けを聞き出す。
例えば、商品コード、製番コード、製品コード、顧客コード、会員番号などは、普通は意味有りコードだ。
つまり、ユーザキーは人間が判断しやすいコードにしている。
そこから、アイデンティファイアを洗い出し、事実をエンティティにマッピングする。
T字形ERで面白いのは、イベントよりもリソースを重視すること。
その理由は、コード体系に基づくユーザキーを洗い出すことはリソースの主キーを明確に定義することと同じだから。
リソースを整理する作業を「リソース叩き」と呼んでいるらしい。
逆に、イベントのキーはシーケンスが多い。
例えば、受注番号、発注番号、請求番号など。
リソースとイベントの違いは、業務に関する日付があるか否か。
テーブル名に「～する」を当てはめると、違和感がないテーブルがイベント。
但し、在庫だけは例外。
リソースを重視するもう一つの理由は、リソースの組合せから対照表というイベントを生成する手法を使うことで、新規ビジネスの可能性を探ることができる点。
リソースの数よりもイベントの数が少ない場合、リソースの組合せで発生する可能性のある対照表というイベントは、その会社の業務として存在していない事実がある。
すなわち、新しい業務を生成することで、新規ビジネスを作り出す根拠になりうる。
逆に言えば、会社がどれだけリソースというマスタないしコード体系を保持しているか、で、業務やビジネスのスコープが確定されてしまう。
新しい業務を生み出すには、新たなリソースを保守し育てていく必要があるわけだ。
【1-2】エンティティを分類
T字形ERがデータベース設計技法として優れている点は、データベース設計の手順が確立されていること。
リソースとイベントの組合せで、対照表や対応表が作られ、それらを要件に応じてそのエンティティが必要かどうか、精査していく。
手順に従うだけで、概念的なデータベース設計はできる。
T字形ERで設計すると、列数は10個以下のテーブルがたくさん生成される。
リソースの組合せからイベントが生成されるから、N個のリソースがあれば、理論的にはN(N-1)/2個のイベントを生成できる。
そんなにたくさんのテーブルをER図に書くのは大変だし、意味のないテーブルもあれば、業務や要件として存在しないテーブルもたくさんあるだろう。
実際、鳥谷部さんのER図を見たところ、花束の花屋モデルでは、100個くらいのテーブルが出てきたらしい。
但し、T字形ERは、リレーショナルデータベースへの実装は意識していない。
つまり、全てのエンティティ(特にたくさん生成される対照表や対応表)をリレーショナル・データベースへマッピングする必要はない。
不要なら削除してよい。
【1-2-1】僕がT字形ERをまだ理解できていない部分は、VEやERなどの概念。
EntityRole：状態遷移と繰返項目
VirtualEntity：VE の （R） 継承
VEは、あるエンティティの中に別のエンティティ候補のデータが含まれているので、別のエンティティ候補を排除した疑似エンティティ。
例えば、従業員テーブルから、入社日や退社日を分離した従業員属性テーブルみたいなもの。
僕の理解では、「従業員△--従業員属性」というテーブルの派生関係で関連付けるはず。
だから、従業員属性テーブルの主キーである「従業員No」はリユース(「R」)と書かれている。
EntityRoleは、繰返項目を排除したエンティティ。
鳥谷部さんは、製品に関する品質管理を事例として説明してくれた。
例えば、製品の品質管理は、品質評価の色々な基準、品質管理の担当者の観点など、いろんな観点で品質評価がされる。
製品の色、大きさ、サイズ、中身、耐障害性、安全性など、色んな観点でその製品の評価基準が必要になる。
僕の理解では、「製品△--製品属性、製品△--品質評価基準」などというテーブルの派生関係で関連付けるはず。
【1-2-2】その他に、ターボファイルはサマリテーブルと同じと言われて、ようやく納得した。
つまり、ターボファイルは、リソースやエンティティを元に、夜間バッチで生成されるサマリテーブルに過ぎない。
ターボファイルの呼称は、サマリテーブル無しでデータを集計表示すると時間がかかる場合に、画面でターボボタンを押すと、すぐに結果が出てきますよ、という経緯から発生したらしい。
【1-3】帳票というモノは重視しない
帳票に惑わされ過ぎないように、帳票の分析にこだわり過ぎないように、という鳥谷部さんの指摘が興味深かった。
事実をエンティティにするのがT字形ER。
【1-4】楽々フレームワーク
鳥谷部さんが作った花屋モデルのER図を元に、住友電工の楽々フレームワークで生成した画面のデモがあった。
楽々フレームワークはT字形ERと相性が良いらしい。
確かに、T字形ERでテーブル設計をきちんと確定できれば、そのテーブルからロジックや画面を生成すればいい。
【1-5】T字形ERのモデルで面白かったのは、在庫というテーブルが明示的になくて、仮想在庫というビューでしか表現されなかったこと。
渡辺さんのモデルでは、在庫を実現するテーブルとそのリレーションシップがデータベース設計の観点で重要であるから、ちょっと肩すかしみたいな気分だった。
【2】渡辺さんの三要素分析法のモデル
【2-1】ホワイトボードの前で、お客さんと話しながらモデルを描く
プレゼンターは関係なく、ホワイトボードの前で、DFDを書きながらプロセスやイベント、担当者を洗い出し、そこからER図を作っていく。
ER図は、渡辺さん流では、カラム名を横に並べていくので、データの例が書きやすい。
見ていて楽しそう。
渡辺さんのようなモデリング技法、そして要件定義は、正直真似できないけど、身に付けてみたいと思わせてしまうものがある。
【2-2】在庫管理推移方式は受払テーブルの派生関係で実現する
渡辺さんの在庫モデルでは、受払予定テーブルで在庫の過去から未来までを管理・監視するように実現しているのが肝だと思う。
僕の理解では、「受払予定△--発注」という派生関係で在庫の過去、「受払予定△--受注」という派生関係で在庫の未来を管理しようとしている。
実際、花束を見込み生産すると想定すれば、発注計画で在庫がいつ作られるか分かり、受注時に在庫引当することで、いつ在庫が予約されるか、が分かる。
つまり、在庫の生成と引当が過去から未来まで時系列に並んだグラフが作られるので、在庫の推移を画面からチェックすることができるようになる。
【2-2-1】しかし、発注テーブルの主キーは発注No、受注テーブルの主キーは受注Noなのに、どうやって受払予定テーブルと派生関係を関連づけるのか？
その仕組みは、受払予定テーブルの主キーである予定Noを、発注・受注テーブルの2次識別子として持たせて、一意制約を課すことで実現しているのがミソ。
ホワイトボードの絵では、「{予定No}」と表現されている箇所が、2次識別子を意味している。
すなわち、発注計画を立てた時に発注Noが作られるのと同時に、予定Noも生成される。
同様に、受注Noの生成時に予定Noも生成される。
そして、発注テーブルと受注テーブルは、受払い予定テーブルのサブセット(サブクラスみたいなもの)であり、互いに排他関係(XOR)にある。
渡辺さんのデータモデリングでは、二次識別子による一意制約を上手く使うパターンや、動的参照(継承属性、または、暗黙的なリレーションシップ)など、データモデリング特有のテクニックが出てくるので、とても面白いと思う。
業務ロジックをデータモデリングはどこまで表現できるか？: プログラマの思索
候補キーと2次識別子に関する概念: プログラマの思索
2次識別子を使ったデータモデリング: プログラマの思索
「動的参照関係」を手なづける: 設計者の発言
更に面白い点は、「受払予定△--単品ロット」という派生関係も持たせている点。
渡辺さんのお話を僕なりに理解すると、お花の廃棄予定日も考慮するために、単品ロットも在庫管理推移方式の対象として入れた、という事だと思う。
【2-2-2】在庫管理推移方式を実現する「受払テーブル」は渡辺さんのモデリングではよく出てくるパターン。
おそらく、渡辺さんの過去の事例で、とてもうまく成功したモデリングパターンなのだろうと思う。
すなわち、在庫の過去や未来が分かるだけでなく、在庫を積極的にコントロールすることで、売上の見通しを立てやすくしたわけだ。
しかし、@sugimoto_keiさんの話を聞くと、こんな話があった。
発注テーブルの保守は、購買担当者。
受注テーブルの保守は、営業。
でも、受払テーブルの保守は、購買担当者や営業などの現場の組織の一つ上の組織の階層の在庫管理者になる。
それはズルいね笑、と。
つまり、「管理層-->業務層」で言えば、管理層に当たる人であり、レイヤが違う。
在庫管理推移方式を実現するには、組織構造を変革する必要があるし、それはレイヤが違うので、現場からそんな声は出てこないだろう笑、とのこと。
【3】感想
【3-1】渡辺さんのXEADといい、楽々フレームワークといい、超高速開発といい、DOAなどの手法で作ったモデルからロジックや画面を自動生成する手法は、日本の製造業に近い人達は本当に好きなんだな、と思う。
ソフトウェア工場、ソフトウェアクリーンルームという発想に近いからだろうと思う。
ソフトウェアファクトリー - Wikipedia
ソフトウェアクリーンルーム - Wikipedia
個人的には、モデルを作ったらソースが自動生成されておしまい、というやり方はあまり好きではない。
【3-2】しかし、上記の僕の理解は間違っている部分がある。
@sakaba37さんに教わったけれど、渡辺さんや他のDOAのモデラーは、モデルと実装が一致する前提で話をしている。
その実装の泥臭い部分を見せずにモデルの話をしているから、そう見えるのでは、と。
実際、渡辺さんがホワイトボードにDFDやER図を書いている時、画面ではこうなるでしょう、というフレーズが時々出てくる。
つまり、ER図から画面のレイアウトやUIはある程度決まっているという前提になっている。
すなわち、モデルと実装された画面は表裏一体として、彼らは既にイメージを持っている。
その意味では、ドメイン駆動設計と同じ発想。
少なくとも、関西IT勉強会に来ておられるモデラーの方は、モデリングもプログラミングも双方に詳しく、実装できないモデルは無意味だと主張されている。
それは同意見。
【3-3】僕の妄想としては、日本人が生み出したデータモデリングの技法と、Railsフレームワークを組合せて、アジャイルな開発ができないか、ということ。
業務要件を満たすテーブル設計さえできれば、Railsという優れたフレームワークのおかげで、画面やロジックはある程度自動生成される。
また、Railsで作られた画面やWebシステムは、ユーザインタフェースも現代風で使いやすい。
RailsはJQueryなど、各種のJavaScriptのフレームワークと相性が良いから。
さらに、Railsでは、テーブルのカラム追加や変更も、履歴を残すので、テーブル設計もアジャイルに設計しやすい。
つまり、プログラミングもテーブル設計もアジャイル開発の一プロセスに含んでしまえばいいのだ。
そのアイデアを試してみたいと思う。
最近のコメント