Ｔ字形 ER手法が クラス 概念を使わない理由は、（事業のなかで実地に使われてきた データ を解析するという前提では） クラス 図を信用していないからです。

　クラス と セット の違いについては、「ベーシックス」 のなかで、すでに記述しているので──同じことを繰り返して言いたくないので──、「ベーシックス」 を参照されたい （32 ページ と 36 ページ）。

　事業のなかで実地に使われた データ を対象として データ 構造を構成する やりかた には以下の特徴がある。

　（1） 日常言語 （自然言語） を使っている。
　（2） データ は コード 化される （コード 体系）。
　（3） データ は （伝票会計を前提にしているので） 同一 フォーマット の くり返し構造 になる。

　（1） および （2） が 「分析工程」 のなかで解析対象とされ──いわゆる 「業務分析」 の対象とされ──、（3） が 「設計工程」 のなかで データ 構造および プロセス 構成の対象とされる。そして、分析工程と設計工程では べつべつの 「方法」 が使われていて、分析工程の アウトプット を システム・エンジニア が 「翻訳」 して設計工程の インプット として変形しなければならない。

　つまり、解析の精度は システム・エンジニア の力量次第ということになる。網羅性と検証可能性が保証されていない杜撰な やりかた に陥っているので、そういう やりかた が、はたして、工学技法と言えるのかどうか、、、。言い換えれば、「書きっぱなし」 という、およそ、工学技法とは程遠い やりかた である。

　Ｔ字形 ER手法が、最初に狙った点は、一人の システム・エンジニア の価値観に左右されないで、全員が 「合意する」 構造を構成することであった。そのために、Ｔ字形 ER手法は、以下の 5つの ルール （規約） を導入した。

　（1） データ の認知 （データ 集合を生成するための判断規準）
　（2） データ の類別 （データ 集合のなかに帰属する性質の判断規準）
　（3） データ の関係 （網羅性と検証可能性を保証する リレーションシップ の判断規準）
　（4） データ の周延 （生成された データ 集合が正しい正規形かどうかを判断する規準）
　（5） データ の多義 （データ──アトリビュート──の多義を排除する規準）

　事業のなかで実地に使われている データ は日常言語を使い コード 化されているので、Ｔ字形 ER手法は、コード を解析しながら データ 構造を構成する 「言語の形態論」 として完成した。

　次に、Ｔ字形 ER手法が狙った点は 「分析工程と設計工程の溝を埋めて、事業戦略 （事業の 『環境適応能力』） を思考する」 ということであった。事業戦略の検討は以下の 2つの段階から構成される。

　（1） 現状の調査 （「事実」 を記述する。）
　（2） 改善案の提言 （代替案を提示する。）

　Ｔ字形 ER手法は 「言語の形態論」 として、前述した 5つの ルール を前提にして、まず、事業を記述して データ 構造を生成する。そして、データ 構造を解析しながら、コード 化の良し悪しや データ （「resource」 と 「event」） の アトリビュート の是非を検討する。さらには、「resource」 間の リレーションシップ を変更して、新たな対照表 （「event」） を生成することもできる。つまり、「事業解析 ⇔ データ 構造」 （事業を解析しながら、そのまま、データ 構造を生成すること） ができる。とすれば、現時点の データ 構造が環境の変化に対して即応できるのかどうかも判断できる。

　実地に使われている データ を言語の形態論の観点に立って解析して、生成された データ 集合が正しい集合かどうか （周延しているかどうか） という点は集合論 （セット 概念） を使って検証できる。

　数学的な正しさというのは、（無矛盾性と完全性を備えている） 「統一的な モデル」 を構成することにあるが、エンジニアリング 的な正しさというのは、「それぞれの目的に合う」　技術を組み合わせて 1つの システム を構成するという点にある。

　1つの システム は 「モジュール」 を単位として編成されるが、「モジュール」 として編成する理由は、環境の変化に対応することと 「再利用」 することの 2つだと思う。

　「モジュール」 を編成するときに注意しなければならない点は、「類似性」 を対象とするのではなくて「相違点」 を対象にしたほうが良いという点である。
　クラス は 「類似性」 を前提にして類を形成するが、「類似性」 を判断するときに、選んだ 「述語」 が曖昧 （広い概念） であれば、概念の一般化が曖昧になる。

　たとえば、正社員と パート は 「従業員」 という クラス になるのは正しいが、正社員と パート では 「相違点」 があるので適用される アルゴリズム が違う。ところが、「類似性」 を使って 1つの クラス として包括してしまうと、その クラス が使う アルゴリズム が多岐になる。この時点で、「アルゴリズム の再利用」 が怪しくなる。
　述語論理には 「一般的な検証手続き」 はない。1つの 1つの論理を証明しなければならない。したがって、「アルゴリズム の クラス」 を生成するというのは非常にむずかしい。

　逆に、「従業員」 という セット を形成してから、「相違点」 を意識して、サブセット にしたほうが、1つの セット のなかで、アルゴリズム の適用が違うことを判断することができる。

　クラス は概念を整理する （再体系化） には最適なのだが、「事実」 を記述するには危険である。クラス というのは エンジニア の教養として習得しておけばよいのであって、クラス を使って事実を記述してはいけない。

　小生 （佐藤正美） は体系化すること （モデル を構成すること） を嫌っているので、「事実の記述」 を主眼として物事を観る気質だから、「クラス」 を扱うことを躊躇っている。小生が クラス 概念を使うのは、せいぜい、「概念的 スーパーセット」 として、描かれた （事実を記述した） Ｔ字形 ER図を解析するときぐらいだから。

　たとえば、新人教育と社員教育と セカンド・キャリア 教育という 3つの 「event」 があったら、「概念的 スーパーセット」 として 「教育」 を考えて、「教育」 という観点から判断して、その 3つの 「event」 でよいのか、という使いかたをするが、それ以上の使いかた （再利用を目的とした クラス の生成） をやらない。

　小生が使う クラス は、あくまで、概念の整理 （再体系化） であって、再利用ではないから、Ｔ字形 ER手法が クラス を対象にすることは、まず、あり得ない。

　技術的に言っても、Ｔ字形 ER手法は、認知番号 （××番号、××コード） を使って セット （集合） を限定 （措定） してから、区分 コード を使って サブセット （部分集合） を検証している。Ｔ字形 ER手法が セット 概念を使っているといっても、けっして、「述定」 している （述語を使って外延を生成している） 訳ではない。

[ 参考 ]
　クラス 図では、Ｔ字形 ER手法の特徴点である 「アルゴリズム の I/O 化 （一撃必殺の I/O）」 を使うことができない。ただし、Ｔ字形 ER手法は データ 構造を対象とした手法であって、データ 構造が吸収できる アルゴリズム は （コード 体系が効果的・効率的に用意されていても） 70 ％程度である。アルゴリズム を作成することを対象にしている技法ではない。つまり、Ｔ字形 ER手法を使っても、「アルゴリズム の 30 ％以上」 を作成しなければならない。

　生産性を高めるために 「再利用」 することを狙って アルゴリズム の クラス を生成しようとしているのなら、生産性を高める最大のやり方は非常に単純であって、アルゴリズム を I/O 化してしまって アルゴリズム を作成しないようにすればよい。