このウインドウを閉じる

To fish in the air, to hunt in the sea.

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

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

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

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

 (1) データ構造
 (2) データ演算
 (3) Integrity 制約

 以上の項目を記号化して、たとえば、モデルを M として、(1) を D として、(2) を O として、(3) を I とすれば、以下のように記述することができます。

  M = (D, O, I).

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

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

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

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

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

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

 
 (2005年 7月23日)

 

  このウインドウを閉じる