20代のころ - 未来のいつか/hyoshiokの日記

週末のオープンソースカンファレンスでの質疑をきっかけに http://d.hatena.ne.jp/codemaniax/20040907#p1 トラックバックをいただく。20代のころの話をしてみる。わたしが仕事とか自分のキャリアの話をするときに聞く人はちょっと注意をしてほしい。仕事の進め方というかキャリアの積み重ねというか、そーゆー話は一般論ではなくて非常に個人的な話で、たまたま私の場合ではこうだったという個々の事情の積み重ねに過ぎず、誰にでも適用可能だとか、これが一番いいとか、XXXになるためにはどーだこーだということでは決してない。繰り返すけどたまたまわたしの場合はこーだったということでしかない。どーゆー人生を送るかということは最終的には自分で決めることだ。自分の人生に満足するかしないかは自分で決めることだ。あーゆー人生を送ってみたいとか、こーゆー人生を過ごしたいとか、そーゆーことはすべて個人的な話で、どれがよくてどれが悪いと言うことはない。当たり前だけど。
安直に答えに飛びつかない方がいい。旅の道筋は人の数だけある。幸せの形は人の数だけある。
にもかかわらづ自分の個人的な体験を記すことは20代でいろいろがんばっている人にちょっとは参考になるかもしれないと思っていて、そーゆーことを伝えることは必ずしも無駄なことではないとも思っていたりする。自分は自分、人は人である。
DECの研究開発センターというところに大学を出て就職をした。DECと言う会社は70年代後半にVAXというミニコンピュータを発売しそれが売れに売れて80年代急成長をしていた。IBMを筆頭とするメインフレーマーにミニコンピュータという武器で果敢にも挑戦していた。1983年に米国DECは研究開発センターを東京に開設し、わたしは1984年に新卒として入社した。一人一台VT100という端末を与えられた。そして社内のコンピュータはすべて社内ネットワーク接続されていた。コンピュータがネットワークに接続されているというのを当たり前と感じる世代にとって、それが当たり前でない時代があり、当たり前でない時代にすべてのコンピュータが接続されているということの先進性を理解することは非常に難しい。私企業が持つ世界最大のコンピュータネットワークをDECは持っていた。IBMも同様な社内ネットワークを持っていたがメインフレームを中心とした中央集中的なもので、完全なPeer to PeerなネットワークはDECぐらいにしか存在しなかった。インターネットが商用化されるはるか以前の話である。
さてわたしの仕事と言えばDECが日本市場にVAXを導入するにあたり米国製のソフトウェアを日本語化するということである。いまでこそソフトウェアの国際化、各国語化などという概念が確立されていて、技術的に難しい問題と言う事はほとんどないが、当時はそのようなノウハウも十分になく日々手探りの時代であった。文字コード一つをとっても、ソフトウェア国際化に適した文字コードはどうあるべきかというような議論の土台すらなかった。
70年代後半、日本の大手コンピュータベンダーは日本語ワープロの開発やメインフレームによる日本語処理の実践により長らく米国IBMの独壇場であったコンピュータの世界においても独自性を発揮しつつあった。http://d.hatena.ne.jp/hyoshiok/20040418 でふれたが富士通のJEF http://www.ykanda.jp/jef.htm が先駆であった。
DECは日本市場に参入するにあたり国産ベンダーの日本語処理技術をベンチマークとして参考とした。わたしもJEFのマニュアルをいろいろ読んだものである。
わたしが入社して最初に与えられた仕事は日本語COBOLというものの開発であった。米国製COBOLでは日本語が簡単に扱えないので当時JEIDAが検討していた日本語COBOLの仕様を参考にCOBOLのコンパイラーを作るというのが新卒のわたしの仕事であった。詳細ははしょるが米国COBOL開発チームのプロジェクトリーダーが来日しソフトウェアエンジニアリングのいろはを教えてくれた。
その後いくつかのプロジェクトを経験しVAX Rdb の担当になった。当時、せっせと日本語化をしていたのだがマルチバイト特有の処理は日本語だけではなくて中国語も韓国語も同様の処理が必要だと言うことに気が付いていた。われわれのコードを参考に香港DECの開発チームが中国語版、韓国語版を作った。日中韓でコードを共通化するためにC言語で言うところの#ifdefを利用した。オリジナルのコードと2バイト特有のコードをコンパイル時のフラグによって切り替えるようにした。1986年ごろの話である。香港DECのエンジニアが作った、中国語版、台湾版、韓国語版のソースコードを日本語版Rdbのソースコードにマージしてアジア版のRdbを作った。ソースコードは一本化したがバイナリは日本語版、中国語版、台湾版、韓国語版と4つあった。当時のわたしの夢はオリジナルのつまり米国製のRdbで日中韓の言語が問題なく扱えるようにすることであった。4つの別々の各国語版の製品ではなく一つのグローバルな製品を作りたかったのである。一つのバイナリで世界中の言語をサポートする。われわれはそれを国際化Rdbと呼んだ。そして当時そのような製品は世界中どこを探してもなかった。わたしたちはそのような製品を作ると言う夢を持っていた。
SQLの標準にも各国語の文字を簡単に扱える仕様が備わっていなかった。日本では芝野さんを主査とするSQLの標準化をするグループがあった。ISOではDECのJim Meltonがテクニカルエディタをやっていた。Jimらと共同で国際化の仕様を練ってそれをもとに国際化Rdbを実装することにした。1988年から89年ごろの話である。アジア版ソースコードは一本化したのでそれをもって私が米国本社に飛んだのは89年10月ごろである。サンフランシスコ経由で行く予定だったがサンフランシスコの大地震で急遽ニューヨーク経由になった。米国のニューイングランド地方の紅葉は実に見事だったことを今でもよく覚えている。
Jimらと仕様を検討しつつ、Rdbの本体にせっせとアジア版のコードをマージしていった。コンパイルスイッチを実行時スイッチに書き換えながらせっせと来る日も来る日もコードをマージしていった。そのときの実装の話をDigital Technical Journal, vol5 no 3, 1993 http://www.hpl.hp.com/hpjournal/dtj/vol5num3/intro.htm に Hirotaka Yoshioka and Jim Melton, "Character Internationalization in Databases: A Case Study", http://www.hpl.hp.com/hpjournal/dtj/vol5num3/vol5num3art7.pdf として記した。
SQLの仕様は92年（SQL 92と呼ばれる）に完成し国際化機能についてはいち早くDECのRdbが実装した。仕様の制定にあたってはRdbでの実装の経験が生かされた。

コンパイル時フラグでの実装例
Figure 7 Compilation Flag in DEC Rdb Version 3
! This example switches the default TPU shareable
! image (TPUSHR). If the Japanese variant is set,
! then the default editor should be JTPUSHR.
!
%IF $ARDB_JAPAN_VARIANT
%THEN
    TPU_IMAGE_NAME = ( IF (.TPU_NAME EQL 0)
                       THEN $DESCRIPTOR ('TPUSHR')
                       ELSE $DESCRIPTOR ('JTPUSHR'));
%ELSE
    TPU_IMAGE_NAME = $DESCRIPTOR ('TPUSHR');

実行時フラグ実装例
Figure 8 Run-time Checking in Version 4
! This code could be translated to the following
! which might contain redundant code but should work:
!
IF.ARDB_JAPAN_VARIANT ! If ARDB_JAPAN_VARIANT flag is true,
THEN ! then Rdb/VMS should use the J-Rdb/VMS behavior.
   TPU_IMAGE_NAME = ( IF (.TPU_NAME EQL 0)
                      THEN $DESCRIPTOR ('TPUSHR')
                      ELSE $DESCRIPTOR ('JTPUSHR'))
ELSE
   TPU_IMAGE_NAME = $DESCRIPTOR ('TPUSHR');

今から見ると非常に幼稚なコードであるが、既存のコードを生かしたままほぼ機械的に変換しマージした。実装に利用した言語はBLISSというDEC社内で利用されていたシステム記述言語である。Cではない。
そんなこんなで約一年ほど米国東海岸にいてわたしにとっても初めてだけどDECにとってもはじめての国際化したソフトウェア製品を出すことに成功した。帰国後、DEC社内の国際化アーキテクチャグループに所属し、DEC社全体の国際化アーキテクチャを定義した。そのときに国際化Rdbの経験についてDigital Technical Journalに記したのだが、その号は国際化アーキテクチャグループによるソフトウェア国際化の特集号である。 http://www.hpl.hp.com/hpjournal/dtj/vol5num3/toc.htm
当時Unicodeについてや、そもそもソフトウェアの国際化はどうあるべきかなどをDEC社内だけではなくIBM、HPの人々と熱く議論した。そのとき国際化Rdbで実際に手を動かして実装したという経験が自分の自信につながっていた。わたしの技術者としてのバックグラウンドである。
当時の米国での上司はSteve Haganというのだが、梅田望夫がhttp://blog.japan.cnet.com/umeda/archives/001008.html で

そして最後に、オラクルの東海岸開発拠点長Steve Haganインタビューがある。この開発拠点は、オラクルがDECから9年前に買収して、現在に至っている。アメリカ国内といえども、東と西のコラボレーションは色々な意味でけっこう大変だ。現在のグローバル分散開発には、米国内分散拠点でのノウハウが活かされているのだろう。

と紹介している。 http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=100 を参考にしてほしい。Steveは実は地球の裏側のチームとコラボレーションをとった経験があるのである。
DEC Rdbは後にOracleに買収され今でもOracle Rdbという製品群として今も開発が続けられているがOracle 9iとかOracle 10gと呼ばれるいわゆるOracle RDBMSとは別系統の製品である。
その後DECを辞めて日本オラクルに転職したのだけど、米国OracleでOracle 8の国際化の実装者を探しているときに日本オラクルにはその道のエキスパートがいるらしいということでSteve Haganがわたしを推薦してくれた縁で米国Oracleに行くことになったのである。
Rdb開発チームの一員として働いていたことは今でもわたしの誇りである。いまから15年前の話である。