9月末で60歳定年退職しました

当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。

9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。もちろんないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。

1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。

その中で、日本ディジタルイクイップメント（DEC）研究開発センタという外資系の知名度のない小さい企業に新卒で入るというのは異例といえば異例かもしれない。本人はそんなことは全然思っていなかったのだが、世間ではそのようなことを思っていたかもしれない。実際、両親はDECのことを知らなかった。*1

DECでは日本語版COBOLプリプロセッサを作るのが最初の仕事だった。実用的なプログラムを作ったことがない新卒のプログラマにとってはちょうど良いサイズのプロジェクトだったと、いまだからこそ思う。

言語プロセッサを作るということは、言語仕様は明確に決まっているので、典型的なウォータフォールモデルになる。仕様が与えられ、それに基づいて設計し、実装する。実装するというのはコードを1行1行書くという地味な作業なのだが、新卒の頭でっかちなプログラマは、もっとカッコいい仕事があるに違いないと思い違いをしている。第二次人工知能のブームなので、そんなところで仕事があるといいなあと思っているんのだが、もちろんない。

最初にやったことは見よう見まねでコマンドスクリプトを駆使してビルド環境を作ることだった。生まれて初めてmakefileを書いた。makefileというのは、どのようにプログラムをコンパイルしてビルドをするかというルールを記したファイルなんだけれど、知っている人には冗長な記述だし、知らない人には、これでは説明にならない。

夜中の0時に、そのスクリプトが動き出すようなスクリプトを書いて、毎日夜中の0時からビルドプロセスが動くようにした。そのビルドプロセスは、当日変更のあったファイルを取り出してコンパイルするだけではなくて、ビルドしたのちに、テストツールを起動して、全テストを流すというものだった。

今でこそ、CI (Continuous Integration)すなわち継続的インテグレーションという名前で知られている、毎日毎日変更のあった部分をビルドしテストをするというプロセスだ。当時は夜中のビルドあるいはデイリービルドと呼んでいた。

夜中のビルドで、毎日毎日全てのテストを流す。プログラムの変更によって時としてテストで不具合を見つけることもある。既存のテストの場合、前日までOKだったのが、その日NGになった場合、当日行った変更が何らかの原因である場合が多い。今まで顕在化していなかったバグがその変更で顕在化する場合もあるし、純粋に新しいバグを埋め込んだということもある。

あるいは新規のテストを追加した場合、元のプログラムに変更がなかったとしても、そのプログラムに含まれていた不都合を新たに発見することもある。

さらには、まだ実装されていない部分のテストを書いている場合はNGが出るのだけど、実装がテストを追い越してしまう場合もある。

TDD(Test Driven Development)などという言葉がない時代のソフトウェア開発でも同様なことは行われていたのである。

ソフトウェア開発を機械力を使って加速する。ソフトウェア開発チームにはプロのプログラマーしかいない。プログラマは、プログラムを書くだけでなく開発環境の整備やテストプログラムも書く。

このCI環境での開発は言語プロセッサ開発でもデータベース管理システムの開発でもOSの開発でもそのプロセスは一緒だ。

DEC時代に学んだこと

ソフトウェア開発のイロハを学んだ。プログラムを書いたらコード管理システムにチェックインする。そしてテストを書きテストをする。当たり前のことを当たり前にする。それの大切さを学んだ。

バグを発見したら、それを記録した。その記録が貴重な学びの場になった。どうやってバグを発見したかを記録する。テストで発見したり、たまたま発見したり、製品の場合は顧客が発見する場合もある。そのバグの原因は何かを記録する。いつバグを埋め込んだか。どのように修正したかを記録する。

自分たちが作っているソフトウェアなのに、自分たちがどのようにバグを作り込んでいるか、驚くほど知らないことに唖然とする。どのようにバグを発見しているかの知見も乏しい。

バグデータベースを作るだけでも学びの速度は加速する。最近のソフトウェア開発プロジェクトでは忘れられたプラクティスかもしれない。自ら学びの場を放棄しているようで勿体無いと思うが、実際はどうなのだろうか（実はよく知らない）

Gitのようなコード管理システム、jenkinsのようなCI環境などがDECの開発現場にあった。

ソフトウェアの国際化

外資系コンピュータベンダにいると日本語版の開発というのは避けて通れない。本社で作られたソフトウェアが日本のことどころか、英語前提ガチガチで作られていたりして、米国以外では使うこともままならなかったりする。

ASCII７ビット前提とした作りになっていて、当時のUnixもひどかったし、C言語もひどかった。各国向けにソフトウェアを作り変えることをローカライズするとか言っていた。それをより一般化して、ソフトウェアの国際化という概念にしていくのが、1980年代から90年代である。

当時はUnicodeなどというものもなくて、AppleやXeroxの人たちが中心となって、1988年ごろにUnicodeの原型となるものが提案されたが、それはどう考えても使い物になるものではなく、各社のエンジニア達が様々な議論を経て、ISO 10646という形にまとめていく。

他社のエンジニア達と腹を割って議論するという経験を文字コードやソフトウェアの国際化を通じて行えたのは僥倖だった。

Oracle

DECはコンピュータ業界を支配していたIBMに対する破壊的イノベーターでだった。70年代から80年代にかけてIBMのローエンド市場をPDP-11ないしVAX 11という16ビットないし32ビットコンピュータで徹底的に破壊していった。アメリカのコンピュータサイエンスの先端にはDECのコンピュータがあった。

IBMへ果敢に挑戦しているもう一つのグループが日本のコンピュータベンダー、日立や富士通だった。彼らはIBMメインフレーム互換マシンを製造していた。80年代のことだ。

IBMのようにハードウェア、OS、ミドルウェア、アプリケーションなど全てを一社で提供するベンダーを垂直統合型ベンダーという。時代は80年代に大きく変わった。PCの登場だ。

PCハードウェア、OS、ミドルウェア、アプリケーション、それぞれを提供するトップベンダーが登場した。それがIntelであり、Microsoftであり、Oracleなどである。

垂直統合型から水平分散型へビジネスモデルが大きく転換していったのだ。

自分はDECという垂直統合型の最後のコンピュータベンダにいた。IBMを破壊的イノベータとして破壊する立場の会社にいたのだが、自分の所属している会社がその波に飲み込まれるとは理解していなかった。

PCはおもちゃだと思っていた。Unix WorkstationはスケーラビリティーがないのでVAXの敵ではないと思っていた。OracleはDEC Rdbほどの性能もなければ機能もない、DEC Rdbは世界で１番のRDBMSだと思っていた。

そして、そのどれも間違いだったと90年代に気がつく。気がついたときにはDECの経営が傾いていた。

「イノベーションのジレンマ (―技術革新が巨大企業を滅ぼすとき (Harvard business school press))」という教科書に載っている通りである。

優秀な経営者が合理的な経営をすればするほど隘路にハマって行く。そして一度その隘路にはまり込んでしまうと二度とそこからは抜け出せない。イノベーターのジレンマである。

プログラマとしてDECで十分経験も積んだ。ソフトウェア国際化についての知見も少なからずある。文字コードについてもJIS(日本工業規格)の標準化委員会にも参加していた。SQL 92標準のレビューもしていた。

日本DECの希望退職制度（二度目）に応募したのが1994年である。36歳だ。

そして自分がおもちゃだと思っていた西海岸で急成長するソフトウェア企業に転職した。東海岸の大企業とはまるっきり違う文化とノリを持っていた。

Oracleである。

機会を得て、米国本社に行くことになった。 1995年6月である。Oracle 8の開発チームに所属してOracleの開発を行った。

朝会社に行ってコーヒーを飲む、メールを読む、コードを書く、テストを書く、時にはスペックを書き、マニュアルを書く。時々バグDBを眺めて自分にアサインされているバグを直す。サポートからの問い合わせに答える、バグ報告の多くはバグではないことを知る。マニュアルを読めと言う。マニュアルのバグを見つける、マニュアルを読む、金曜日には会社でビールを飲む、ワインを飲む、自宅で肉を焼く、魚を焼く、ビールを飲む、ワインを飲む、日記を書く。

コードを書くのが仕事だ。

今でこそ35歳プログラマ定年説などと言う馬鹿なことを言う人が少なくなったが（いまでもそんなたわごとを言う人がいることを知っている）、当時は30過ぎてプログラムを書いているのなんか頭がおかしいと言う風潮が日本にはあった、

いらないお世話である。

転職は35歳までだと言うわけのわからないことをいう風潮もあった。

余計なお世話である。

自分が転職したのは36歳だし、Oracle 8のコードをゴリゴリ書いていたのは37歳をすぎてからである。年齢は関係ない。野茂が大リーグに挑戦したのは1995年だ。自分が単身シリコンバレーに行った年だ。

Windows 95が発売され、Netscapeが破竹の勢いの時代である。

インターネットが広く知られるようになった年でもある。

Open Source Software

1998年1月にDECはCompaqに売却され、会社として幕を閉じた。イノベータのジレンマの典型例として、一時期の覇者のあっけない幕切れであった。

そして、1998年1月、Netscapeはそのブラウザーのコードを無償で公開すると言う発表をした。それがのちにOSSとして知られる事件だ。

商用ソフトウェアのソースコードを無償で公開すると言う暴挙に（暴挙としか思えなかった）Netscapeはでた。会社としてもはやNetscapeは存在しないが、OSSのムーブメントはソフトウェア開発を大きく変えた。

インターネットを前提とした世界規模のソフトウェア開発方法論、それをバザールモデルとエリックレイモンだは名付けたのだが、を実証して見せた。LinuxやRubyのようなOSSが世界を席巻する。世界を変えた。

カーネル読書会

99年に日本に戻ってきて、日本オラクルでサポート部隊に入って地味に仕事をしている一方でカーネル読書会という奇妙な勉強会のようなものを始めた。

狭義にはLinuxのカーネルの勉強会なのだが、話題はLinuxだけではなくてOSSやテクノロジー一般のコアな勉強会という位置付けだった。

OSSの場合、ソースコードがあるので、実装レベルの細かい話を突っ込んで議論できる。大きな話からミクロな話まで自由にできるというのが心地よい。

ビールを飲みながらコアな話をするというノリの勉強会になった。毎月１回くらいのペースで開催して、第100回にはLinuxの創始者のLinusも参加してくれた。

Miracle Linux

そんなこんなでLinuxやOSSで遊んでいたら日本オラクルのやんちゃな人たちがLinuxのビジネスをしようという話になって、気がつくと巻き込まれていた。自分としては青天の霹靂で祭り上げられた感じである。

2000年6月に日本オラクルに出資してもらい、Miracle Linuxを立ち上げ取締役CTOになった。正直に言えば、経営の経験のない技術系の人間がCTOなど務まるわけはないのだけど、それ以上に技術がわかるというかOSSがわかる人がいなくて消去法で自分がその役になったという感じである。41歳でベンチャー創業だ。

時代の流れはOSSだったし、それを日本という地域で普及させるのが自分のミッションでもあると感じていた。

カーネル読書会は楽しかったし、OSSを普及させるのはビジネスというよりも、こちらの活動の方が役に立っていたのではないかと思わなくもない。

OSDLというのちにLinux FoundationになるところでBoard Memberにもなった。米国NPOの経営を現場にも参加できた。すごい勢いで全力疾走をする米国ベンチャーの経営を経験した。

一方で日本では、ネクタイを締めた人がOSSの意義を理解しているとは全然思えなかったし、SIの現場の人たちはOSSを無償のソフトウェアとして使っていても、バザールモデルとか自由なソフトウェアの意義などについて理解しているとは到底思えなかった。

勉強会などで若いエンジニアと付き合いが深まって行くに連れて、エンタープライズとは違う世界が東京にも草の根的に育っていることを知った。

その頃、未踏ソフトウェア創造事業というのがあって、面白そうなので応募したら、採択された。2002年、44歳頃である。若手のプログラマに混ざっていい歳したおっさんが嬉々としてプログラムを書いた。*2

いろいろとあって、その後、楽天に移り（2009年8月、50歳）、テクノロジーカンファレンスの運営をしたり、社内報のお手伝いをしたり、楽天IT学校に関わったりした。社内公用語が英語になったのは驚いたが、三木谷さんのリーダシップを中の人として経験できたのはよかった。

プログラマとして一生やって行くのだと若い頃の自分は鼻息を荒く言ったものだが、そうでも言わないことには会社員として生きて行くのが生きづらいと感じていたのかもしれない。

まさか自分が定年になるとは思ってもいなかったし、その時の自分を想像することもできていなかった。

この何年か、あるいは直近の数ヶ月、60歳になったらどうするか、どうしても自分ごととして考えることが難しかった。プログラマ定年説というのがどのような意味を持つのか持たないのか、よくわかっていない。今だにわかっていない。

定年というのは会社員あるいは公務員だからこそある話で、自営業だったり、商売をしていたり、農業漁業をしている人には関係ない。

自分の人生は自分で決める。引退の時期は自分で決める。

会社員を辞めるにあたって、そのような当たり前のことに至ったのが自分にとっての定年退職の意義である。

60歳から何を始めるか

会社の規定で65歳まで再雇用される制度があるが、会社勤めは辞めることにした。100年人生だ。人生二毛作である。会社員ではない人生も面白いと思う。幸い、娘は独立した、扶養家族はいない。

そこで、大学に行くことにした。8月に大学院の試験を受けて幸いにも合格した。*3

9月末より東京大学大学院情報理工学系研究科電子情報学専攻博士課程の学生である。*4

先日安田講堂で入学式があった。家族席ではなくて新入学生の席で総長の式辞を聞いた。英語であった。*5

研究の経験はないが、実務経験はある。プログラムもちょっとは書けるし、プログラムを読むことは好きだ。マニュアルを読むことも好きだ。論文を読むことは苦ではない。

自分をバージョンアップすることに興味がある。ハードコアな研究をして世界に貢献したい。誰もがまだ見つけていない何かを見つけてみたい。インパクトの大きい研究をしたいと思う。

出来るか出来ないかはわからないけど、やって見ることが大事だということは人生から学んだ。うまくいかなくてもそれを失敗とは思わない。人生幾つになってもチャレンジだ。

Be a Hacker. Make the world better.

*1:親が入社前から名前を知っているのは最後の会社（楽天）だけだった

*2:Intelのマニュアルをボロボロになるまで読んだ https://tech.nikkeibp.co.jp/it/members/NSW/ITARTICLE/20030619/2/

*3:TOEFLの問題集をやった。TOEICとは全く傾向が違うのでちゃんと対策をしないと大変なことになる。各専攻の専門試験は過去問が公開されているので、それを地道に解く。教科書をしっかり読んで理解をした。コンピュータアーキテクチャ、アルゴリズム、情報理論の教科書を読んだ。情報のエントロピーの計算とか出来るようになったが試験には出なかった

*4:http://www.i.u-tokyo.ac.jp/index.shtml

*5:https://www.u-tokyo.ac.jp/ja/about/president/b_message30_08.html