このウインドウを閉じる

Once an engineer, always an engineer.

 
 以下の問いに対して、じっくりと考えてみてください。

     今の職業を選んで良かったですか。

 僕は、システム・エンジニアという職業を選びましたが、上述の問いに対して、「はい」というふうに即答できないようです (苦笑)。
 僕は、自らの人生に関して、公の空間のなかで、思い出を語るつもりは、毛頭、ないのですが、システム・エンジニアを選んだ理由は、まったくの偶然だった--もっと、正確に言えば、自ら、納得して選んだのではなくて、たまたま、就職した企業のなかで、(コンサルタントになるための前段階として) プログラマになったのが、そもそもの起点だったようです。

 ただ、僕は、プログラマという職業が嫌だったので、転職を いくども 考えていたし、コンピュータ業界から離れるために、ガードマン (或る大使館の守衛) になりました。英語の翻訳家になろうと思い、The Japan Times のなかに掲載されていた (翻訳家の) 求人広告を観て、コンピュータ・ソフトウェアの英文マニュアルを日本語に翻訳する仕事を応募しました。僕が就職した企業は、(僕の職歴を判断して、) 僕を (翻訳家ではなくて) プログラマとして雇いました。コンピュータ業界に もどった僕は、再び、プログラマになりました。

 再就職した企業では--6回目の転職でしたが(笑)--、僕は、(欧米の) アプリケーション・パッケージ を日本のなかに移植するために、アプリケーション・パッケージの日本語化・日本化を担当しました。アプリケーション・パッケージのソース・コードを読んで、日本税法の仕様を、オン・コーディングする仕事をしていました。僕は、自らの仕事を嫌っていました。まいにち、憂鬱でした。
 ただ、請け負った仕事を手抜きすることは、僕の自負心が許さなかったので、(仕事を嫌ってはいましたが) 仕事には全力を注いでいました。仕事を嫌だという感情と、良い仕事をしなければならないという意志が、相反しながら混ざり合って、僕の精神状態は、きわめて、ストレスが堆積した状態でした。
 僕は、30歳以前に就いていた過去の職業を封印したい (笑)。

 30歳を過ぎてから、仕事の中味が変わりました。
 当時、日本では、いまだ、RDB が使われていなかった時代でしたが、RDB の導入・普及を担当することになって、DBA になりました。僕は、RDB を、日本のなかに導入・普及した張本人の1人です。今から振り返れば、20年前の出来事です--いま、20歳代のプログラマなら、当時、幼稚園に入っていなかった頃ですし、30歳代のプログラマなら、小学生でしょうね。

 僕は、古い思い出を語るつもりはないのであって、僕が語りたい点は、アプリケーション・パッケージのソース・コードを読んだり、 RDB を作った天才的なエンジニアたちから、直接に、RDB の internals を教えてもらったりしたことが、僕のエンジニアとしてのキャリアを転換することになった、ということです。
 そういう仕事をやってきて、「エンジニアは、自らが担当するプロダクトの internals を知り尽くしていなければならない」というエンジニア観 (エンジニア像) を持つようになりました。RDB の性能に関して、極限までのパフォーマンスを実現する技術は、いまでも、だれにも負けないつもりです。

 技術に対して自信を持つようになって、自らの仕事に対して、ようやく、誇りを感じましたが--30歳半ばの頃ですが--、或る日、或るクライアントから以下のように言われました。

  正美さん、我々ユーザにとっては、プロダクトの中味など、どうでも良いことなのです。
  エンジンの構造を知らなければ、運転できない、という訳ではないでしょう。
  新しいエンジンの構造が、昔のエンジンの構造とちがうなら、運転のやりかたも
  ちがってくるでしょう。
  我々が知りたいのは、新しい運転のしかたです。
  そして、そのプロダクトを使えば、事業に対して、どういう貢献ができるのか、という
  点なのです。正美さん、運転のしかた (データ設計) を教えてください。

 そして、僕は、いよいよ、データ設計を仕事の対象にすることになりました。
 データ設計に関して、Eric G. Vesely 氏 (米国のコンサルタント)が、数年に及んで、僕を個人指導してくれました。僕の仕事の力点が、DBA から DA へと移りました。

 DA になってから、日々、事業のなかで使われている「生の」データを対象にして、データベースを設計するようになったので、僕は、「事業に関する知識」ということを、はじめて、強烈に意識しました--それ以前にも、僕は、事業過程 (財務過程・生産過程)の知識を、或る程度、持っていたのですが、習得していた知識は役に立たないことを痛感しました。
 しかも、複数のクライアントを同時に請け負うので、様々な事業形態を知らなければならない、という大きな壁にぶつかりました。しかし、一人のエンジニアが、個々の事業文化を対象にして、短い年数のあいだに、知識を習得することなど、金輪際、できる訳がない。
 僕が、 DA として、悩んだ点は、「いかにして、クライアントの事業実態 (事実) を『正確に記述して』、データベース化できるか」という点でした。

 この悩みが、いよいよ、T字形 ER手法を考える起点になったのです。

 さて、長々と、僕のキャリアを綴ってきましたが、エンジニアになってから、僕が、痛烈に感じた点は、以下の2点です。
 (1) 自らが使うプロダクトの仕組み (設計思想をふくむ) を熟知しているか。
 (2) データベース化の対象となる事業を正確に記述できるか。

 コンピュータ業界に対して、多大な不信感を抱いていた僕を、まがりなりにも、エンジニアとして、誇りを抱くようにしてくださったのは、アシスト社の人たちです。RDB を扱うことになったのは、アシスト社に勤めていた頃です。もし、僕が RDB を扱っていなかったら、僕は、いまの仕事をしていないでしょうね、きっと。
 僕を育ててくださったアシスト社の皆さんに感謝しております。

 僕は、いまなら、エンジニアとして誇りを抱いていますが、いっぽうでは、エンジニアになって良かったかどうか、という問いに対して、「はい」という返事を迷うことなく即答することができない。
 職業選択の自由のなかで--様々な可能性のなかで--、 (偶然に選んだとしても) 1つの職業を選んだのですが、一抹の「寂しさ」を感じているようです。おそらく、その「寂しさ」は、選ばれなかった・様々な可能性に対する「未練」なのかもしれない、、、。

 
 いつもとは論調のちがう文章になってしまいましたが、(日本では、4月を、1つの会計年度のはじまりとする企業が多いので、) 4月は、はじまりの時節と思い、新たな会計年度を迎えるにあたって、自らの職業の価値を問い直してみるのも良いでしょう。
 日に日に新たにして、また、日に新たなり。

 
 (2004年4月1日)

  このウインドウを閉じる