システム・エンジニアは、巨大な情報システムを設計することを仕事にしているので、職業柄、整合的な「構造」を作ること--および、「構造」のなかで、「例外」を、どのように扱うか、という対応--に対して、つよい意識を抱いているはずだ、と僕は思っているのですが、そうではない人たち （システム・エンジニアたち） を、多々、観るので、僕は、少々、戸惑っています。

　たとえば、2000冊程度の蔵書なら、本棚のなかで、学問の領域ごとに、おおまかに整理しておいても、１冊の書物を探すことは、そうそう苦労しないでしょうが、数十万冊・数百万冊の書物を収納するとなれば、効率的に探すことができるように、なんらかの・周緻な整理方式を導入しなければならないし、かつ、整理方式 （言い換えれば、検索方式） は、単純であり、あらゆる観点からの検索に対して対応できる方式でなければならないでしょう。
　そういう整理方式では、まず、どういう領域の書物が対象となっているのか、という全体像を知らなければならないでしょう。

　同じことは、１冊の書物のなかでも、適用されています。「はしがき」のなかで、目的が綴られ、全体図として目次が提示され、個々の検索に対して索引が用意されています--書物が電子化されていれば、キーワード検索もできます。
　書物を読んで、理解するためには、最低限、３回、読むことになるでしょう。まず、全体の体系を理解するために、通読して、次ぎに、精読して、全体と個々の概念の関連を調べて、３回目の読書にして、はじめて、批評することができる。３回目の読書では、前提とされている公理を検討し、公理を前提にして組み立てられた論理 （定理） の logical thread を検討することになるでしょう。
　理論は、構造を付与されたシステムです。

　読んでいる書物が、目的・前提・体系を示していれば、その書物のなかで、論理の飛躍があっても、僕は気にはしない。なぜなら、論理が飛躍している点は、新たな着想を生む契機を僕に与えてくれることが多いから。
　書物が示している目的・前提・体系を丁寧に検討しないで、書物のなかで拾った・いくつかのキーワードを対象にして、書物 （書物のなかで述べられている論理） を批評する態度に対して、僕は、強烈な嫌悪を感じます [ 書評の類にも、こういう いい加減な態度が多いようです ]。

　全体の文脈のなかでキーワードは意味を付与されているので、全体を精確に読まなければ、キーワードの意味を正確に理解することはできないし、キーワードが、すでに、聞き覚えのある用語であればあるほど、誤読する危険性が高い。たとえば、僕が専門にしているデータベース設計の領域では、スキーマ （schema） という用語は、きわめて扱いのむずかしい用語です。
　スキーマというキーワードだけを提示すれば、「正反対の」解釈が成立します。たとえば、「データ設計では、データの認知として、スキーマが大切である」という曖昧な文を僕が言ったとすれば、もし、それを聞いた人が、カント哲学の認識論を立脚点にしている人であったり、認知科学のなかで、心理学の用語として、スキーマを考えている人であれば、「暗黙知としての、組織化された知識」のことを想像するでしょう。でも、僕が使っている意味は、「形式知としての図表 （diagrammatic representation）」のことかもしれないのです。そして、モノを認知する際、モノに対して、先験的図式 （スキーマ） を対比するという考えかた （カント哲学の認識論） を認めないつもりで言っているかもしれないのです。
　でも、ひょっとしたら、「正反対」の解釈は、おたがい、見事な誤解のなかで、賛同しあうかもしれない （笑）。

　ほかにも、「意味論」という用語も、扱いのむずかしい用語です。言語学的意味論と論理的意味論では、「意味論」の意味が違います。言語学的意味論では、文と言語外現実との対応関係を論点にしますが、論理的意味論では、モデル （公理系） のなかでの意味の記述を論点にします。モデル自体も、扱いのむずかしい用語です。

　次ぎに示す４つの「因」を、プラトンが言ったのか、それとも、アリストテレスが言ったのか、僕は記憶が曖昧なのですが--書斎に出向いて、文献を調べれば良いのですが、めんどうなので止めますが、御了承のほどを--、モノを考える際、役立つ考えかたでしょうね。
　　（１） 質料因
　　（２） 形相因
　　（３） 動力因
　　（４） 目的因

　たとえば、時計を例にすれば、針とか文字盤とかリューズなどが質料因であり、時計が形相因であり、ぜんまい仕掛け （あるいは、クォーツ） が動力因であり、「時を測る」が目的因です。これらの概念は、およそ、「構造」を形成しているモノが対象なら、検討事項として、役立つでしょう。思想 （１つの公理系） を検討するときにも役立つでしょう。
　属性値集合を質料因として、テーブルを形相因として、直積集合および集合代数演算を動力因として、論理ビューを目的因とした公理系が関係モデル （relational model） です。

　さて、ＳＱＬを「醜悪」な言語というふうに非難した情緒豊かなエンジニアは、「醜悪」の意味を示すべきでしょうね [ 2004年2月29日付、参照 ]--僕は、自らの著した書物が酷評されても、なんとも思わないけれど、僕が尊敬するコッド博士の考えかたに対して、およそ、システム・エンジニアにあるまじき いい加減な論法で批評して いい気になっているヤツを許すことができない。
　歴史の流れを変えたほどの天才 （コッド博士） を批評するなら、それなりの尊敬を払い、それなりの覚悟を抱いて、批評すべきでしょう。しかも、正当な論法を示して。
　ちなみに、件のエンジニアは、コッド論文 （原文） を、３回以上、読んだのでしょうかね。

　
　 　（2004年3月7日）