モデルを作るときに悩ましい点は、（意味論と構文論との兼ねあいのほかに、） 「演繹的」視点と「帰納的」視点を、どのように融合か、という点にある。

　モデルは「仮説」にすぎない。
　「仮説」に似た用語として、「理論」や「法則」があるが、--科学的な専門領域では、これらの用語は、それぞれ、違う意味として使われているかもしれないけれど--、ここでは、３つとも、同じ意味として扱う。すなわち、３つとも、以下の意味で使う。

　（１） 或る立言 （文、あるいは文の集合） を前提とする。
　（２） その前提から導出された帰結を、事実と対比して、真・偽を判断できる。

　以上が成立するとき、前提となる立言を「仮説」ということにする。
　もし、（「仮説」から導出された） 帰結が「真」であれば、帰結のことを「確認例」という。
　もし、帰結が「偽」であれば、帰結のことを「否認例」という。

　たとえば、以下の立言は、普遍的一般化であり、演繹的な「仮説」である。

　（１） 認知番号を付与されたモノを「entity」とする。
　（２） 「entity」は、「resource」と「event」の２つのサブセットから構成される。
　（３） 「resource」と「resource」を結べば、「対照表」を生成する。
　（４） 「対照表」は「event」の原型である。
　　　　　（「対照表」に対して、認知番号を付与すれば、「event」になる。）

　（１） および （２） は、「初期条件を述べた立言」であり、演繹的ルールは、（３） と （４） である。（４） に対して、同じ帰結として、ほかの解釈が成り立つ仮説があるのではないか、という余地がある。

　たとえば、「従業員」と「部門」があって、「従業員. 部門. 対照表」が成立するとき、対照表は、「配属」という「event」を示すと同時に、「どの従業員が、どの部門に対して配属されているか」という構成も示す。

　Ｔ字形ＥＲ手法では、作図された構成と対比される事実は、「情報 （データベース化の対象となっている情報）」であって、現実の世界のなかで生起した事実のことではない。
　もし、現実の世界のなかで生起した事実として、「辞令」のドキュメントが作成されていても、「辞令」が、コンピュータ化の対象になっていなければ--配属日を記述したドキュメントが、コンピュータ化の対象になっていなければ--、「従業員. 部門. 対照表」は、「event」として認知されない。

　「モノと関係」に対して、関係の論理（ａＲｂ）を演繹的に適用する際、関係の論理を、論理的な「関数」として使うか、それとも、２つの個体のあいだに成立する記述的な「関連」として考えるか、さらに、記述的な「関連」のなかで、ルールを作ることができるかどうか、という点は、「仮説」を作る中核の論点である。
　さらに、「仮説」を適用する際、帰納的な事実として、否認例が、もし、出てきたら、否認例が、際だった例外なのか、それとも、「仮説」そのものを見直さなければならないのか、という点を、つねに、検討しなければならない。

　「仮説」を作ること自体が、労力を費やす作業であるが、さらに、「仮説」を検証し続ける作業も、労力を費やす。単純なルールとしてまとめた「仮説」は、エレガントであればあるほど、うっかりすると、事実を、すべて、言い尽くしたかのような錯覚に陥るが--そして、ルールのみを、いつも、語っていれば、たやすいことだが--、経営環境が変化すれば、事実も変化するので、つねに、事実と対比して、モデルの検証を怠ってはならない。
　小生は、ときどき、そういうことが厭わしくなって、Ｔ字形ＥＲ手法など作らなければ良かったとさえ、思うことがある。ことさように、モデルを検証するというのは、辛い作業である。
　ただ、エンジニアとして幸いだった点は、日々、仕事のなかで、膨大な事実 （材料） と向き合うことができる、という点である。

　
　（2004年8月1日）