モデ 家の TMD の 「event （受注と納品）」 を検討しました。
なお、本文で記載した 「板書の写真」 は、文字が読めないように意図的に縮小されていますが、tm-net 上 （「ＴＭの会」 の ホームページ） では、文字を読める大きさの撮影になっていますので、会員は、本文を読んだあとで、tm-net の写真を参照して下さい （あるいは、tm-net の写真を ダウンロード して、それらの写真を参照しながら、本文を読んで下さい）。
● TMD の読みかた
TMD の読みかたを確認しました。
たとえば、私は 2週間ごとに ユーザ を訪れますが、最初の レビュー では、TMD はいちぶの 「情報 （帳票、画面など）」 を対象にした部分図で始まります。そして、ユーザ は、レビュー の回を重ねるにつれて、次第に、「情報 （帳票、画面など）」 を増やして、TMD を拡張し充実してゆきます。したがって、私が ユーザ を次に訪れる日までに、TMD が変わるのが ふつうの現象です。そのために、ユーザ を訪れるつど、TMD （の全体） を改めて読まなければならない。すなわち、TMD が変更されるつど、TMD を読まなければならない。その読みかたを実演しました。
TMD の読みかたは、以下の手順でおこないます。
（1） 「event」 の構成を読む。
（2） 「resource」 の構成を読む。
（3） 「resource」 が 「event」 に対して、どのように関与しているかを読む。
「構成」 を読むときに注意してほしい点は、「『箱 （entity）』 ではなくて、『線 （relation）』を読みなさい」 という点です。
● 「event」 の構成を読む
モデ 家の TMD では、（まず、「event」 の構成を読んだときに、） 「契約」 と 「受注」 の関係は、部分関数になっています。すなわち、リレーションシップ 上、「（リレーションシップ の） ゼロ の cardinality」 が記述されています。 → 板書写真 （1）
まず、この点 （ゼロ の cardinality） が起こる事態とは どういう事態なのかを ユーザ に確認します──この確認で以下の点が明らかになりました。
（1） 「ゼロ の cardinality」 とされている事態のほうが、「受注 （の件数）」 に較べて多い。
（「契約」 していながら、「受注」 として認知されない事態が多い。）
（2） 今後、益々、この傾向は強くなる。
（3） 事業の やりかた として、なんらかの対応をしなければならないのではないか。
（新たな ビジネス・モデル を考えなければならないのではないか。）
「受注」 において、「ゼロ の cardinality」 は、重大な 「意味」 を示しています。
ここで注意してほしい点は、「補集合 （A に対する ¬A） の意味を つねに問いなさい」 （ここでは、「受注」 の 「ゼロ の cardinality」 のこと） という点です──この点も、いままで、いくども強調してきたことを思い起こして下さい。「献本」（今回、新たに追記された entity） においても 「ゼロ の cardinality」 が記述されています。なお、「献本」 の 「ゼロ の cardinality」 は、「受注」 の場合ほどに （事業上、） 重大な 「意味」 はなかった。
「受注」 と 「納品」 の関係を読んだ際、「納品」 には、「受注」 と同じ アトリビュート がいくつか記述されています──たとえば、納品日、請求日、注文先名など。そして、ふたつの entity のなかで同じ アトリビュート は、「受注」 のそれらを 「納品」 に 「複写」 していることが明らかになりました──「納品」 のほうに在る （「受注」 と同じ） アトリビュート は、形式的構成では、（D） が付与されるべき項です。そして、「納品」 の構造は、或る数を計算するための多値関数 （MAND） 構成であることが明らかになりました。したがって、コンピュータ の 「技術」 上、「納品」 は、entity とする意味が薄いのですが──納品番号として個体指定子を付与する意味が薄いのですが──、「監査」 上、証跡の ひとつになるので a must とした次第です。
→ 板書写真 （2）
● 「resource」 の構成を読む
「resource」 の構成は、前回と同じだったので、レビュー を省きました。
● 「resource」 が 「event」 に対して どのように関与しているのか
この点を確認するには、「event」 群と 「resource」 群を接続している 「線」 を観れば良い。
モデ 家の TMD では、その 「線」 上に、「取引先. 取引先種別. 対照表」 （以下、A と略称） が接点になっているのが一目で見て取れます。さらに、その対照表から 「線」 が延びて、「取引先. 取引先種別. 得意先. 対照表」 （以下、B と略称） が構成されています。しかも、その 2種類の対照表は、「event」 に対して、関与のしかたが相違しています。 → 板書写真 （3）
（1） A は、「契約」 に関与している。
（2） B は、「受注」 および 「納品」 に関与している。
当然、ここで、A の 「意味」 と B の 「意味」 を確認します。その確認で明らかになった点は、「得意先」 は、（個々の instance が） 「F-真」 を満たさないという点でした──「得意先」 の値 （instance） が 「F-真」 を満たすこともあれば、「集合」 （いくつかの instance を総括して付与した認知番号 [ psuedo、phantom のこと ]） のこともあるとのこと。そして、この混在形態は、「受注」 のなかの 「受注先氏名 1 （会社名）」 「受注先氏名 2 （担当者名）」 に対応していることが明らかになりました──ただ、「得意先」 と 「受注先氏名」 との対応において、「受注先氏名」 が どのように扱われるかは、ここでは、説明を省略します。
ちなみに、「受注」 のなかで、「企画 コード」 と 「倉庫 コード」 は、（ここ [ 「受注」 の領域 ] では、） 使われないことが明らかになりました。なお、「データ は、どのようにして使われるか （データ の使用法）」 を つねに確認して下さい──すなわち、「かくかくの データ （すなわち、「ことば」） は、しかじかの使いかたがある」 という点を つねに注意していて下さい。文脈のなかで使われない [ 関与しない ] ということは、「無意味」 ということです。 → 板書写真 （4）
この構成で明らかになった点は、「受注」 および 「納品」 では、（「契約」 と同じように、「取引先」 を使いたいのだけれど、） 従来から 「得意先 コード」 を使ってきているので──しかも、「得意先 コード」 の値は、前述したように、「個体 （instance）」 に対して付与されていることもあれば、（いくつかの instance を まとめて） 「集合」 に対して付与されていることもあり [ 言い換えれば、周延的性質と集合的性質が混在していて ]──、「取引先」 と 「得意先」 とを対応するために、「取引先. 取引先種別. 得意先. 対照表」 を用意している次第です。
● まとめ
以上を まとめれば、 → 板書写真 （5）
（1） 「『文法』 どおりに TMD を読みなさい」
（記述されている事態がすべてである。憶測で深読みしないこと。）
（2） 「箱 （entity）」 ではなくて、「線 （relation）」 を読みなさい。
（3） 補集合 （A に対する ¬A） を つねに確認しなさい。
今回 実演した 「TMD の読みかた （「構成」 の読みかた）」 は、モデ 家の TMD で記述されている箱の数なら、実戦 （実際の コンサルテーション） では、15分くらいで おこなわなければ プロフェッショナル な コンサルタント ではない。ただ、TML の文法を習得して直ぐに こういう 「読みかた」 ができる訳ではないので──私も、コンサルタント になった当初では、そういうふうに 「速く、的確に」 読めた訳ではない──、習い始めの頃は、じっくりと [ 丁寧に ] 読む技術を習得して、とにもかくにも、「構成を読む」 基礎技術を確実に習得して、実戦の場数を重ねるにつれて、読む速度を向上すれば良いでしょう [ 読む速度は、自然に向上してゆくでしょう ]。コンサルタント （practitioner） は、実戦のなかで TMD を レビュー しながら コンサルタント になってゆく、という 当たり前のことを外さなければ宜しい。とにかく、技術は実際に使用していなければ──技術を頭のなかで いくら理解したとしても──、実用に耐えないでしょう。「頭の動きと手の動きが一致している」 というのが システム・エンジニア （および、コンサルタント） の性質でなければならない。
次回から、モデ 家の TMD を対象にして、「アトリビュート・リスト」 の作成指導に入ります。
モデル は、以下の 2点を アウトプット にしています。
（1） 「妥当な」 構成 （TMD で記述される）
（2） 「真とされる」 値 （アトリビュート・リスト で記述される）
この ふたつをごっちゃにしてはいけない。というのは、「妥当な」 構成を統制しているのは 「論理法則」 ですが、「真とされる値」 を実現するのは 「制約・束縛」 です。しかも、「制約・束縛」 は、事業の しかた に依存します。したがって、アトリビュート・リスト を作成している途上で──「真とされる値」 を実現するために導入されている 「（データ のあいだの） 制約・束縛」 を確認している途上で── 、TMD を修正することも起こります。TMD と アトリビュート・リスト は、モデル の両輪ですので、相互作用しながら、かつ、補完関係にあります。DA （Data Analyst） のなかには、TMD ばかりに興味をしめして、アトリビュート・リスト を軽視しがちな人たちもいますが、アトリビュート・リスト は （TMD と同等の） 大切な ドキュメント である点に注意していて下さい。