当社の規定により満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という形にまとめていく。 他社のエンジニア達と腹を割って議論するという経験を文字コードやソフトウェアの国際化を通じて行えたのは僥倖だった。

カーネル読書会 99年に日本に戻ってきて、日本オラクルでサポート部隊に入って地味に仕事をしている一方でカーネル読書会という奇妙な勉強会のようなものを始めた。 狭義にはLinuxのカーネルの勉強会なのだが、話題はLinuxだけではなくてOSSやテクノロジー一般のコアな勉強会という位置付けだった。 OSSの場合、ソースコードがあるので、実装レベルの細かい話を突っ込んで議論できる。大きな話からミクロな話まで自由にできるというのが心地よい。 ビールを飲みながらコアな話をするというノリの勉強会になった。毎月１回くらいのペースで開催して、第100回にはLinuxの創始者のLinusも参加してくれた。