計算機科学 （computer science） を専門にしていれば、数学の知識・技術を習得していることは、たしかに、役立つが--データベース設計では、コッド氏が提示した関係モデルは、数学の技術を使っているが--、（事業過程を対象にしたシステムを作る） ＳＥは、数学を「習得していなければならない （a must）」 という訳ではない。

　しかしながら、エンジニアたちを観ていて、どうも、数学に対して、「ひけめ」 を感じているようですね--数学を知らないということを、弱点のように思っているようです。

　ぼくは、データ設計技法を作るエンジニアなので、どうしても、数学を知っていなければならないけれど、事業過程を対象にしてシステムを作るエンジニアが、どうして、数学に対して 「ひけめ」 を感じるのか、という点を納得できない。かれらにとっては、数学の知識に比べて、購買管理・生産管理・販売管理・財務管理などの知識のほうを重視しなければならないと、ぼくは思っているのですが、、、。

　データ・モデルでは、以下の３点を抽象化した構成を云います。

　（１） データ構造
　（２） データ演算
　（３） Integrity 制約

　以上の項目を記号化して、たとえば、モデルを M として、（１） を D として、（２） を O として、（３） を I とすれば、以下のように記述することができます。

　　M ＝ （D, O, I）.

　（　） は、並びを示していますので、まず、データ構造があって、それを演算して、そして、（演算が終わって、） データ構造の integrity が崩れない、ということを示しています。そういうふうに記述したからと云って、数学を使っていることにはならないでしょう （笑）。以上の記述は、あくまで、対象を記号化したにすぎない。

　さて、モデル （modeling） のなかに、数学を導入する理由は、「モデルが 『無矛盾性 と 完全性』 を実現する」 ように作らなければならないからです。単純に言い切ってしまえば、「モデルを使っていて、モデルが破綻しない」 ということを守るためです。
　そして、繰り返して使うことができる「手続き」として具体化するためです。

　言い換えれば、繰り返し使う「手続き」のなかに矛盾が起こったり、あるいは、「手続き」のなかに不意打ちを認めれば、繰り返し使う「手続き」にならないからです。ほかの言いかたをすれば、（様々な人たちの様々な価値観を前提にした） 「恣意性」を、できうるかぎり、除去する、ということです。

　そういうふうに考えれば、モデルを作ること （modeling） ができる対象領域もあれば、そうでない対象領域もある、ということになりますね。
　事業過程のなかで使われている「情報」を対象にして、データ・モデルを作ることはできますが、事業過程そのものをモデル化することは、まず、できないでしょう。もし、それができるならば、事業そのものを、オートマトンが運営すればよい、ということになってしまいます。モデルは、繰り返し使うことができるように定式化された手続きである、と考えたほうがわかりやすいでしょうね。そして、モデルのなかで使われる変項 （語彙、あるいは観察述語） は、（モデルが、そもそも、目的にしていた対象領域であれば、） いくつもの対象領域に対して適用したら、変量しても変質しない、ということです。

　そういうふうな領域では、数学を知っていることは役立ちますが、そうでない領域では、数学を知っていることは、あくまで、「教養」であって、数学を直接に使うことは、まず、ないでしょうね。したがって、そうでない領域のなかで仕事をしている人たちが、数学に対して、「ひけめ」を感じることを、ぼくは不思議に思っています。小説家や画家は、数学に対して、「ひけめ」など感じていないでしょう。

　数学や英語やパソコンに関して、過多な反応を示す人たちが多いのは、どうしてなのでしょうね、、、（謎）。

　
　（2005年 7月23日）