20150220(金) 18:30から開催しました。申し込み案内はこちら
今回は面白いネタでした。40人を超える方にご参加いただきました。ありがとうございました。また毎回無料で会議室をお貸し頂いているJAC Recruitment様には毎回感謝しております。本当にありがとうございます。
1人30分というのは丁度良い感じですので、どなたか続いてされませんか？
今回は飛び入りで住友電工情報システムの池田さんが乱入(笑)されて楽々フレームワークの概要を説明してくれました。T字形ERのモデルをTER-MINEの楽々連携版で入力するとそのまま楽々に渡す事が出来ます。テーブル関連などから自動的に画面を生成する方法論はXEAD Driverそのものです。DOAという設計手法を作られた椿正明さんは「実装独立」を強く主張されていましたが、DOAを使っている人には実装と隣り合わせにある事は自明だったのです。
2次会は前回も利用した魚民でした。広くて座席移動がしやすくて、しかも安いので相当気に入っています。北の方にお住まいの数名が新大阪で飲むと言って帰られました。その後4名がいつものラウンジ。今回は超有名な唐揚げやお寿司などを持ちこんでちょっと宴会チックになってました。帰ったのは4時ごろでした。
＜今回の勉強宴会資料＞
１．花束問題のしおり
http://www.benkyoenkai.org/2015/02/blog-post.html
２．鳥谷部さんハンドノート（佐野抜粋版）
https://drive.google.com/open?id=0BykMR9FfFyLOcC1aQ0FpZjcxNlE&authuser=0
３．鳥谷部さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLORTdEc0QtVFNBY0U&authuser=0
４．渡辺さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLOY21zTXVjYTE4dDA&authuser=0
（参考）SlideShareに公開された鳥谷部さんのハンドノート全文
http://www.slideshare.net/satoshitoriyabe9/ss-43628500
珍しい名字ですが、父親が青森出身です。青森に行くと方言が強くて言葉がわかりません。それどころか青森の中でも北と南で言葉が通じない事もあるそうです。
1993年に外資系アパレルに居ました。当時のボスが様々な本を読んだ後、「これが一番わかりやすい」からとＴ字形ＥＲ手法の本を持ってきました。自分で本を買って勉強した後、佐藤さんに来て頂いて手伝ってもらい、3年半かけて一緒に基幹システムを再構築しました。
様々な方法論がありますが、もし議論が出来ないのなら宗教と同じです。議論のベースにしてもらうために、ハンドノートにまとめました。今から紹介するのはＴ字形ＥＲ手法をきっかけとはしていますが、私の考えです。必ずしも佐藤正美さんの方法と同じではありませんのでその点誤認識下さい。また、今日はあえてＴ字形ＥＲ手法の範囲でお話します。現在はＴＭ１．３と呼ばれています。
※佐野註：セクション１～５はハンドノート抜粋版のセクションに対応しています
リソースとリソースの関係は「対照表（QUASI ENTITY）」を作ります。イベントとイベントの関係で元がNの時は「対応表（MAPPING LIST)」をつくります。エンティティの箱の右上にどういう性質のエンティティかを記号で表します。
エンティティの箱の左側には個体指定子（昔はアイデンティファイヤーと呼んでいました）を書きます。自分以外のエンティティの個体指定子を左側に（Ｒ）として記述することでリレーションシップを表します。（Ｒ）のＲはリユースという意味です。
右側には性質（属性）を羅列します。この性質にも日付やテキストなど様々な種類があります。（Ｄ）と書くと、他のエンティティから導出した事を表します。私は初期値として持ってきて上書きするかどうかの区別を大文字／小文字で書き分けています。
正直バイナリ方式で分析すると箱の数が増えるのですが、間違いなく丁寧な分析が出来る事は事実です。
(1) 「花屋」と聞いて想像出来る単語（イディオム）です。業務のイメージを浮かべます。
(2) 練習問題の中から気になる文章を青字にしました
(3) 先ほど説明したＢＰＥＣの業務階層図です。今回作るかは別にしてこの程度は意識しながらモデリングすべきでしょう。
(4) 小売業というビジネスモデルの「鉄板」は、仕入－加工－販売－回収です。
それぞれの業務ごとに一般的な考慮点はこの程度あります。
(5) 先ほど(2)で抜き出した単語についてそれぞれどう考えるか
(6) モデリングを行う手順を示します。まずコード体系を見つけるところから開始です。
(7) 美しいダイヤグラムを描くコツも書きました。リソースを上下に配置し、イベントは左から右に時系列に配置します。
モデルは時間がないので一部だけ説明します。クレジットカードは国際ブランドごとに扱いを変える事が多いので対照表を作っています。得意先アカウントパスワードだけを分離しているのはセキュリティ上の要求レベルが違う事が予測されるためです。
副資材は一般的には在庫管理が不要ですので、原材料としての花と分けて管理しています。在庫は、仕入予定発注と得意先受注からリアルタイムに計算して表示します。
モデリングセッションをするとき、お客さんからよく「どういう準備が必要ですか？」と聞かれます。そんな時は「実際に業務をされている方が来てもらえるなら何の準備も必要ありません」と答えます。
これは現状システムをおろそかにしているということではありません。まずはおおよそどういうシステムが欲しいのかについて納得感のある叩き台を作る。その後に、抜けている仕様要素がないかチェックするために、現行システムと丁寧に突き合わせます。これを逆にして現行システムの分析から始めると、「最新建材で出来た竪穴式住居」が生み出されます。
(1) カジュアルなまとまりとしての業務フローを描きます。
この練習問題では受注から出荷の流れと、発注から入荷の流れが必要です。これもお喋りしながらです。今回は受注から出荷の流れだけを描きます。
本当は帳簿の絵を書けばわかりやすいのですが、難しいのでドラムの絵でお茶を濁します(笑)
業務の処理は誰かが上から俯瞰して指示しているわけではありません。何かをトリガーにして作業を開始しているはずですので、それを聞いて書きこみます。加工指示なら例えば「11時になった」時に行う事にします。
(2) データフローを見ながらデータモデルを描きます。
3要素分析法だとテーブルの下に実際の値を書いていけますのでわかりやすいです
マスターから描き出します。「商品ってどういう項目あるのですかね？」とか質問しながら次々に描きます。特に管理したい項目があれば落とさないですが、全部描く必要はありません。スピード感が重要です。
(3) 描いていくと、面白い事に気付きます。単品ロットエンティティを作れば、廃棄予定を受払予定として更新出来てしまいます。
(4) 受注明細がありますので、もし花が足らないという事態が起これば、必須でない花を勝手に変更することが出来ます。カーネーションセットでカーネーションがなければダメですが、かすみ草が足らないので他の花に変更するという事が受注明細を更新することで出来てしまいます。
特に「小売業の鉄板」というのは、この程度の事が頭になくてお客様の前に立てないという最低限の話だと私も思います。とは言え経験が少ないと難しいでしょう。
鳥谷部さんのモデルをゆっくり読むと、モデラーがどういう視点でビジネスを捉えているのかが良くわかります。普通なら一つのエンティティに入れる属性でもバイナリ方式で分解する事で「ビジネス分析」を実現している事も良くわかりました。
一方の渡辺さんの方法はビジネスを分析するのではなく、やりたい事を素早くするためのモデルになっていると思います。それにしてもこの程度の複雑な業務をホワイトボードだけでたった30分丁度でモデリングされるとは素晴らしいの一語でした。渡辺さん以外でこれが出来る人には会った事がありません。
ただ、経験がある方が見ると様々な疑問が浮かんでくるはずです。例えば、受注は「商品Ｎｏ（花束の番号）」で行うのですが、受注明細には「単品Ｎｏ（花単体の番号）」が入っています。つまり受注登録する瞬間に所要量展開するというイメージです。加工指示するタイミングで所要量展開していると在庫推移監視方式が使いにくいので省エネの策でこうなっているのだろうと判断しました。2カ月先の受注を受け付けた時、出荷までに季節が変わって商品構成が変わると処理が大変になるでしょう。どなたかから質問が出ないか期待したのですがありませんでした。
また単品マスタに（最初は持っていなかった）在庫数を持った瞬間にマスタではなくなります。私には違和感がありますが、質問がなかった事を見ると皆さん納得されたのでしょうか。
是非様々なモデルをもっと見たいと思います。お二人を踏み台にして（失礼）ぜひどなたか発表して下さい。
以上
今回は面白いネタでした。40人を超える方にご参加いただきました。ありがとうございました。また毎回無料で会議室をお貸し頂いているJAC Recruitment様には毎回感謝しております。本当にありがとうございます。
1人30分というのは丁度良い感じですので、どなたか続いてされませんか？
今回は飛び入りで住友電工情報システムの池田さんが乱入(笑)されて楽々フレームワークの概要を説明してくれました。T字形ERのモデルをTER-MINEの楽々連携版で入力するとそのまま楽々に渡す事が出来ます。テーブル関連などから自動的に画面を生成する方法論はXEAD Driverそのものです。DOAという設計手法を作られた椿正明さんは「実装独立」を強く主張されていましたが、DOAを使っている人には実装と隣り合わせにある事は自明だったのです。
2次会は前回も利用した魚民でした。広くて座席移動がしやすくて、しかも安いので相当気に入っています。北の方にお住まいの数名が新大阪で飲むと言って帰られました。その後4名がいつものラウンジ。今回は超有名な唐揚げやお寿司などを持ちこんでちょっと宴会チックになってました。帰ったのは4時ごろでした。
＜今回の勉強宴会資料＞
１．花束問題のしおり
http://www.benkyoenkai.org/2015/02/blog-post.html
２．鳥谷部さんハンドノート（佐野抜粋版）
https://drive.google.com/open?id=0BykMR9FfFyLOcC1aQ0FpZjcxNlE&authuser=0
３．鳥谷部さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLORTdEc0QtVFNBY0U&authuser=0
４．渡辺さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLOY21zTXVjYTE4dDA&authuser=0
（参考）SlideShareに公開された鳥谷部さんのハンドノート全文
http://www.slideshare.net/satoshitoriyabe9/ss-43628500
＜01:方法論としてのＴ字形ＥＲの説明＞
システムズ・デザイン（株）鳥谷部 聡さん珍しい名字ですが、父親が青森出身です。青森に行くと方言が強くて言葉がわかりません。それどころか青森の中でも北と南で言葉が通じない事もあるそうです。
1993年に外資系アパレルに居ました。当時のボスが様々な本を読んだ後、「これが一番わかりやすい」からとＴ字形ＥＲ手法の本を持ってきました。自分で本を買って勉強した後、佐藤さんに来て頂いて手伝ってもらい、3年半かけて一緒に基幹システムを再構築しました。
様々な方法論がありますが、もし議論が出来ないのなら宗教と同じです。議論のベースにしてもらうために、ハンドノートにまとめました。今から紹介するのはＴ字形ＥＲ手法をきっかけとはしていますが、私の考えです。必ずしも佐藤正美さんの方法と同じではありませんのでその点誤認識下さい。また、今日はあえてＴ字形ＥＲ手法の範囲でお話します。現在はＴＭ１．３と呼ばれています。
※佐野註：セクション１～５はハンドノート抜粋版のセクションに対応しています
セクション１：
Ｔ字形ＥＲ手法でのモデルは単語－イディオムを重視します。単語を厳格に定義することからスタートします。（青森県のように言葉が通じない時は辞書作りからスタート）セクション２：
ヘッダー／明細の関係はスーパーセットとして整理します。業務階層とアプリケーション機能の関係もSuperset/Subsetの関係として捉える事が出来るでしょう。当社は業務を見える化する時には必ず業務階層図を描きます。その手法としてＢＰＥＣ（Business Process Engineering Cycle）という手法を推進しています。ご興味があればWEBサイトをご覧ください。リソースとリソースの関係は「対照表（QUASI ENTITY）」を作ります。イベントとイベントの関係で元がNの時は「対応表（MAPPING LIST)」をつくります。エンティティの箱の右上にどういう性質のエンティティかを記号で表します。
エンティティの箱の左側には個体指定子（昔はアイデンティファイヤーと呼んでいました）を書きます。自分以外のエンティティの個体指定子を左側に（Ｒ）として記述することでリレーションシップを表します。（Ｒ）のＲはリユースという意味です。
右側には性質（属性）を羅列します。この性質にも日付やテキストなど様々な種類があります。（Ｄ）と書くと、他のエンティティから導出した事を表します。私は初期値として持ってきて上書きするかどうかの区別を大文字／小文字で書き分けています。
セクション３：
佐藤さんのコンサルを受けていた時に「正規化とはリンゴはリンゴ、ミカンはミカンで集める事」と何度も言われました。正規化はご存じだと思いますが、Ｔ字形ＥＲで重要なのは、バイナリ方式（２項関係）を基本としていることです。２個からしか対照表を作れません。３項以上の関係を許す事をＮアレイ（n-項関係）と呼びます。正直バイナリ方式で分析すると箱の数が増えるのですが、間違いなく丁寧な分析が出来る事は事実です。
セクション４：
エンティティの切り出しにはコード体系に注目します。コードの中に含まれている意味も分析しながらモデル化します。「取引先コード」が意味ありだという事はその会社がどういうビジネスをやっているかがコード体系に隠されている可能性が高いです。＜02:モデリング発表（Ｔ字形ＥＲ手法）＞
システムズ・デザイン（株）鳥谷部 聡さんセクション５：
実務では頭の中だけでやっていることを勉強会ですので紙に起こしてみました。(1) 「花屋」と聞いて想像出来る単語（イディオム）です。業務のイメージを浮かべます。
(2) 練習問題の中から気になる文章を青字にしました
(3) 先ほど説明したＢＰＥＣの業務階層図です。今回作るかは別にしてこの程度は意識しながらモデリングすべきでしょう。
(4) 小売業というビジネスモデルの「鉄板」は、仕入－加工－販売－回収です。
それぞれの業務ごとに一般的な考慮点はこの程度あります。
(5) 先ほど(2)で抜き出した単語についてそれぞれどう考えるか
(6) モデリングを行う手順を示します。まずコード体系を見つけるところから開始です。
(7) 美しいダイヤグラムを描くコツも書きました。リソースを上下に配置し、イベントは左から右に時系列に配置します。
モデルは時間がないので一部だけ説明します。クレジットカードは国際ブランドごとに扱いを変える事が多いので対照表を作っています。得意先アカウントパスワードだけを分離しているのはセキュリティ上の要求レベルが違う事が予測されるためです。
副資材は一般的には在庫管理が不要ですので、原材料としての花と分けて管理しています。在庫は、仕入予定発注と得意先受注からリアルタイムに計算して表示します。
＜03:モデリング発表（三要素分析法）＞
デービーコンセプト 渡辺幸三さんモデリングセッションをするとき、お客さんからよく「どういう準備が必要ですか？」と聞かれます。そんな時は「実際に業務をされている方が来てもらえるなら何の準備も必要ありません」と答えます。
これは現状システムをおろそかにしているということではありません。まずはおおよそどういうシステムが欲しいのかについて納得感のある叩き台を作る。その後に、抜けている仕様要素がないかチェックするために、現行システムと丁寧に突き合わせます。これを逆にして現行システムの分析から始めると、「最新建材で出来た竪穴式住居」が生み出されます。
(1) カジュアルなまとまりとしての業務フローを描きます。
この練習問題では受注から出荷の流れと、発注から入荷の流れが必要です。これもお喋りしながらです。今回は受注から出荷の流れだけを描きます。
本当は帳簿の絵を書けばわかりやすいのですが、難しいのでドラムの絵でお茶を濁します(笑)
業務の処理は誰かが上から俯瞰して指示しているわけではありません。何かをトリガーにして作業を開始しているはずですので、それを聞いて書きこみます。加工指示なら例えば「11時になった」時に行う事にします。
(2) データフローを見ながらデータモデルを描きます。
3要素分析法だとテーブルの下に実際の値を書いていけますのでわかりやすいです
マスターから描き出します。「商品ってどういう項目あるのですかね？」とか質問しながら次々に描きます。特に管理したい項目があれば落とさないですが、全部描く必要はありません。スピード感が重要です。
(3) 描いていくと、面白い事に気付きます。単品ロットエンティティを作れば、廃棄予定を受払予定として更新出来てしまいます。
(4) 受注明細がありますので、もし花が足らないという事態が起これば、必須でない花を勝手に変更することが出来ます。カーネーションセットでカーネーションがなければダメですが、かすみ草が足らないので他の花に変更するという事が受注明細を更新することで出来てしまいます。
＜所感＞
Ｔ字形ＥＲ手法といえば現状分析のボトムアップからスタートするというイメージでした。でも、本来のコンサルタントとしてどういうアプローチでトップダウン設計をされているのかが良く理解出来ました。普通なら紙に書かない頭の中をよくここまで書いてくれたと思います。特に「小売業の鉄板」というのは、この程度の事が頭になくてお客様の前に立てないという最低限の話だと私も思います。とは言え経験が少ないと難しいでしょう。
鳥谷部さんのモデルをゆっくり読むと、モデラーがどういう視点でビジネスを捉えているのかが良くわかります。普通なら一つのエンティティに入れる属性でもバイナリ方式で分解する事で「ビジネス分析」を実現している事も良くわかりました。
一方の渡辺さんの方法はビジネスを分析するのではなく、やりたい事を素早くするためのモデルになっていると思います。それにしてもこの程度の複雑な業務をホワイトボードだけでたった30分丁度でモデリングされるとは素晴らしいの一語でした。渡辺さん以外でこれが出来る人には会った事がありません。
ただ、経験がある方が見ると様々な疑問が浮かんでくるはずです。例えば、受注は「商品Ｎｏ（花束の番号）」で行うのですが、受注明細には「単品Ｎｏ（花単体の番号）」が入っています。つまり受注登録する瞬間に所要量展開するというイメージです。加工指示するタイミングで所要量展開していると在庫推移監視方式が使いにくいので省エネの策でこうなっているのだろうと判断しました。2カ月先の受注を受け付けた時、出荷までに季節が変わって商品構成が変わると処理が大変になるでしょう。どなたかから質問が出ないか期待したのですがありませんでした。
また単品マスタに（最初は持っていなかった）在庫数を持った瞬間にマスタではなくなります。私には違和感がありますが、質問がなかった事を見ると皆さん納得されたのでしょうか。
是非様々なモデルをもっと見たいと思います。お二人を踏み台にして（失礼）ぜひどなたか発表して下さい。
以上