若い エンジニア たち--ただし、問題意識を抱いた熱意ある若い エンジニア たち--と語っていると、彼らが提示する根本的な問題意識は、僕が、普段、扱いかねている論点と、ほとんど、同じであることに気づくことが多い。
　おそらく、システム・エンジニア であるがために感じる問題意識は、年齢には関係しないのでしょうね。

　そして、その問題意識を、仕事のなかで継続して抱きながら、なんとか、ソリューション を考えたいと思うか、それとも、一時的な関心として忘れ去るか、という点が、エンジニア として、その後の仕事の質を形成するように僕には思われます。
　Ｔ字形 ER手法は、10年くらい前に着想した方法ですが、理論として、無矛盾性と完全性を備えて、技術として、単純性と実効性を実証するためには、10年を費やさなければならなかった。ちなみに、Ｔ字形 ER手法を考える起点になった点は、以下のような極めて素朴な疑問点だった。

　　- 従業員の データ 集合の中に、部門 コード を挿入するのは正しいのか。
　　- 従業員の データ 集合の中に、入社日が定義されることは正しいのか。
　　- 従業員の データ 集合は、正社員と パート の サブセット になる
　　　正社員とパート では、アトリビュート構成が相違するので、null が起こる。
　　　データ 集合として、null が起こることは正しいのか。

　おそらく、従業員の データ のなかに、部門 コード や入社日が定義されることは 「常識 （generally accepted）」 であるし、データ のなかに null があれば、アルゴリズム のなかで、それに対応すればよい、と考えるのが 「常識 （generally accepted）」 とされているでしょうね。ただ、その 「常識」 が正しい （logical） ことにはならない。

　幸い、コッド 博士 （Codd, E.F.） が、自ら提示なさった セット・アット・ア・タイム 法に関して、「弱点」 を述べてくださったので、次の世代の我々は、コッド 氏の セット 理論を改善しやすかった--もっとも、それが、僕を、10年間、苦しめることになったのですが、、、なぜなら、「数理 モデル」 のなかに、「意味論」 を導入せざるを得なくなったから。
　僕は、エンジニア として、「意味論」 を毛嫌いしていて、モデル は 「数理 モデル」 でなければならない、と思っていたから。

　コッド 博士が セット・アット・ア・タイム 法を提示なさらなかったら、Ｔ字形 ER手法は生まれなかったでしょうね。「先達はあらまほし」。
　個人が、独力にて、できることなど高が知れている。普通の力量しかない我々が集まって組織を作れば、集成された力は、強力な 「新しい力」 となって、作用するから、組織を作るのでしょう。逆に言えば、普通の力を集めて飛翔するために組織を作る、と云っていいでしょうね。

　組織では、参加している人たちが 「協業」 できるための技術と 「協調」 できるための理念 （および、管理） がなければならない。技術という点では、エンジニア は貢献できるのですが、エンジニア は、性質として、どうも、「協業」 も 「協調」 も苦手のようです （笑）。
　組織が組織として作用するためには、「管理」 が前提となります。端的に言いきってしまえば、組織を関数 （多項式） とみなせば、技術は単なる複数の パラメータ であって、それらの技術を統合する関数が 「管理」 でしょうね。そういう考えかたをすれば、エンジニア として、「悲劇」が起こる。つまり、エンジニア は、いつまでたっても、マネジメント の下にある、と。

　競争のなかで survive するためには、専門的な技術を身に着けたほうが良い、と云われる割には、エンジニア は、マネジメント に比べて、一段低い職種として扱われているのが現実です。収入を増やしたければ、マネジメント になったほうがよい、というのが欧米の 「常識 （generally accepted）」 です。
　ただ、エンジニア は、マネジメント の力量が乏しい。したがって、エンジニア が マネジメント になったとしても、第一級の エンジニア が無能な マネジメント になってしまう危険性も大きいようです。しかも、マネジメント の力量というのは、定量的に測量できない （笑）。

　僕は、エンジニア であり、かつ、（SDI を経営している） マネジメント です。
　経営に関して、僕は、非常に単純な計測規準を適用していて、損益計算書が マネジメント の 「通信簿」 だと思っています。つまり、経営成績が 「赤字」 なら、マネジメント として落第ということです。SDI は、設立して 14年になりますが、僕の 「通信簿」 には、「赤点」 が、3回、あった （苦笑）--設立直後と、一昨年と昨年です。設立直後は、先行投資があったので、覚悟のうえの 「赤字」 だったのですが、一昨年と昨年は、日本経済の沈下を直接に浴びてしまいました。バブル が弾けたとき、SDI は、逆に、過去最高益を更新したし、景気の変動に影響されない企業体質にしていたつもりだったのですが、さすがに、昨今の経済状態は、SDI の経営にも波及しました。今年は、なんとか、持ち直しそうなので、胃の痛みも和らいだのですが、「赤字」 が続くようなら、マネジメント として落第でしょうね。
　「赤字」 が、3期、続けば--たとえ、先行投資であっても、3年以内に 「結果」 を出すことができないなら--、経営陣は退陣すべきでしょう。

　マネジメント は 「戦略 （環境適応能力）」 を考えることを仕事にしています。
　エンジニア と マネジメント の両方をやっていて感じたことは、それぞれ、「職種」 でしかない、という点です。つまり、マネジメント は 「戦略」 を考えるのが仕事であり、エンジニア は 「技術」 を作るのが仕事である、と。いずれにしても、現状の問題点に対して、ソリューション を提示することが仕事である、と。つまり、そういうふうに考えれば、「職種」 の間には、上下関係はない、と。

　逆に言えば、現状の問題点に対して ソリューション を提示するという意識 （および、技術のなかに込められた設計思想まで遡って技術を解析するという意識） がなければ、エンジニア としても、マネジメント としても、いずれは、閉塞状態に陥る、ということです。

　エンジニア の教育では、そういう意識を養うことを主眼としなければならないし、もし、OJT が正しく導入されているのなら、現状の問題点--いまだ、多くの人たちが感知できていない問題点--を感知できるようにして、どのように、代替案 （あるいは、技術の適用） を考えればよいか、ということを指導しているだろうと僕は想像していたのですが、現実は、どうも、先輩の 「経験」 を、後輩に口伝しているだけのようですね （苦笑）。

　技術は具体的な手続きですから 「継承」 することができます--たとえ、それを体得するまで、数年の年月がいるとしても。
　「経験」 が大切にされ継承されなければならない、という論点は、技術を適用した際に起こった問題点を継承して、新たな ソリューション を提示するとき、そして、そのときにかぎる、ということです。エンジニア にとって、「私」 など、どうでもいい。おそらく、組織にとっても、「私」 など、どうでもいい。エンジニア にとっても、組織にとっても、「我々」 という言いかたが前提です。

　ただ、そこに一抹の寂しさがある、、、。つまり、「私」 は、「歯車 （a cog of wheel）」 に過ぎないのではないか、という--技術は 「共有」 できるがゆえに、その技術を使う 「私」 は、ほかのだれかの代替物に過ぎないのではないか、という。

　（2003年10月19日）