未来のいつか/hyoshiokの日記スマートフォン用の表示で見る未来のいつか/hyoshiokの日記hyoshiokの日々思うことをあれやこれやこの広告は、90日以上更新していないブログに表示しています。2018-09-309月末で60歳定年退職しました当社の規定により満60歳で定年退職をした。長いようで短かった会社員生活も一区切りだ。自分のプログラマとしての会社員生活を振り返ってみる。無駄に長いし結論はないのでお忙しい人は飛ばして欲しい。9月末なのでブログ界隈では退職エントリーがそこかしこに書かれると思うが、その中で自分の退職エントリーを連ねることにどれほどの意味があろうか。ないのだが、それでも多くの書き手の年齢を考えると満60歳定年退職というところに若干の希少価値を見出せなくもない。1984年に大学院修了して以来、プログラマとしてのキャリアを重ねてきた。大学時代の同期でプログラマとして就職したものは皆無だ。当時、工学部の同期はメーカーに就職するのがほとんどで、大手家電メーカー、自動車メーカー、電力会社などなど、当時の誰でも名前を知っている人気企業に就職するものが大半だった。その中で、日本ディジタルイクイップメント(DEC)研究開発センタという外資系の知名度のない小さい企業に新卒で入るというのは異例といえば異例かもしれない。本人はそんなことは全然思っていなかったのだが、世間ではそのようなことを思っていたかもしれない。実際、両親はDECのことを知らなかった。*1DECでは日本語版COBOLプリプロセッサを作るのが最初の仕事だった。実用的なプログラムを作ったことがない新卒のプログラマにとってはちょうど良いサイズのプロジェクトだったと、いまだからこそ思う。言語プロセッサを作るということは、言語仕様は明確に決まっているので、典型的なウォータフォールモデルになる。仕様が与えられ、それに基づいて設計し、実装する。実装するというのはコードを1行1行書くという地味な作業なのだが、新卒の頭でっかちなプログラマは、もっとカッコいい仕事があるに違いないと思い違いをしている。第二次人工知能のブームなので、そんなところで仕事があるといいなあと思っているんのだが、もちろんない。最初にやったことは見よう見まねでコマンドスクリプトを駆使してビルド環境を作ることだった。生まれて初めてmakefileを書いた。makefileというのは、どのようにプログラムをコンパイルしてビルドをするかというルールを記したファイルなんだけれど、知っている人には冗長な記述だし、知らない人には、これでは説明にならない。夜中の0時に、そのスクリプトが動き出すようなスクリプトを書いて、毎日夜中の0時からビルドプロセスが動くようにした。そのビルドプロセスは、当日変更のあったファイルを取り出してコンパイルするだけではなくて、ビルドしたのちに、テストツールを起動して、全テストを流すというものだった。Integration)すなわち継続的インテグレーションという名前で知られている、毎日毎日変更のあった部分をビルドしテストをするというプロセスだ。当時は夜中のビルドあるいはデイリービルドと呼んでいた。夜中のビルドで、毎日毎日全てのテストを流す。プログラムの変更によって時としてテストで不具合を見つけることもある。既存のテストの場合、前日までOKだったのが、その日NGになった場合、当日行った変更が何らかの原因である場合が多い。今まで顕在化していなかったバグがその変更で顕在化する場合もあるし、純粋に新しいバグを埋め込んだということもある。新規のテストを追加した場合、元のプログラムに変更がなかったとしても、そのプログラムに含まれていた不都合を新たに発見することもある。実装されていない部分のテストを書いている場合はNGが出るのだけど、実装がテストを追い越してしまう場合もある。Development)などという言葉がない時代のソフトウェア開発でも同様なことは行われていたのである。ソフトウェア開発を機械力を使って加速する。ソフトウェア開発チームにはプロのプログラマーしかいない。プログラマは、プログラムを書くだけでなく開発環境の整備やテストプログラムも書く。このCI環境での開発は言語プロセッサ開発でもデータベース管理システムの開発でもOSの開発でもそのプロセスは一緒だ。DEC時代に学んだことソフトウェア開発のイロハを学んだ。プログラムを書いたらコード管理システムにチェックインする。テストを書きテストをする。当たり前のことを当たり前にする。それの大切さを学んだ。バグを発見したら、それを記録した。その記録が貴重な学びの場になった。やってバグを発見したかを記録する。テストで発見したり、たまたま発見したり、製品の場合は顧客が発見する場合もある。そのバグの原因は何かを記録する。いつバグを埋め込んだか。どのように修正したかを記録する。自分たちが作っているソフトウェアなのに、自分たちがどのようにバグを作り込んでいるか、驚くほど知らないことに唖然とする。どのようにバグを発見しているかの知見も乏しい。バグデータベースを作るだけでも学びの速度は加速する。最近のソフトウェア開発プロジェクトでは忘れられたプラクティスかもしれない。自ら学びの場を放棄しているようで勿体無いと思うが、実際はどうなのだろうか(実はよく知らない)Gitのようなコード管理システム、jenkinsのようなCI環境などがDECの開発現場にあった。外資系コンピュータベンダにいると日本語版の開発というのは避けて通れない。本社で作られたソフトウェアが日本のことどころか、英語前提ガチガチで作られていたりして、米国以外では使うこともままならなかったりする。ASCII7ビット前提とした作りになっていて、当時のUnixもひどかったし、C言語もひどかった。各国向けにソフトウェアを作り変えることをローカライズするとか言っていた。それをより一般化して、ソフトウェアの国際化という概念にしていくのが、1980年代から90年代である。10646という形にまとめていく。他社のエンジニア達と腹を割って議論するという経験を文字コードやソフトウェアの国際化を通じて行えたのは僥倖だった。OracleDECはコンピュータ業界を支配していたIBMに対する破壊的イノベーターでだった。11という16ビットないし32ビットコンピュータで徹底的に破壊していった。アメリカのコンピュータサイエンスの先端にはDECのコンピュータがあった。IBMへ果敢に挑戦しているもう一つのグループが日本のコンピュータベンダー、日立や富士通だった。彼らはIBMメインフレーム互換マシンを製造していた。IBMのようにハードウェア、OS、ミドルウェア、アプリケーションなど全てを一社で提供するベンダーを垂直統合型ベンダーという。時代は80年代に大きく変わった。PCハードウェア、OS、ミドルウェア、アプリケーション、それぞれを提供するトップベンダーが登場した。それがIntelであり、Microsoftであり、Oracleなどである。垂直統合型から水平分散型へビジネスモデルが大きく転換していったのだ。自分はDECという垂直統合型の最後のコンピュータベンダにいた。IBMを破壊的イノベータとして破壊する立場の会社にいたのだが、自分の所属している会社がその波に飲み込まれるとは理解していなかった。PCはおもちゃだと思っていた。WorkstationはスケーラビリティーがないのでVAXの敵ではないと思っていた。Rdbは世界で1番のRDBMSだと思っていた。そのどれも間違いだったと90年代に気がつく。気がついたときにはDECの経営が傾いていた。」という教科書に載っている通りである。優秀な経営者が合理的な経営をすればするほど隘路にハマって行く。一度その隘路にはまり込んでしまうと二度とそこからは抜け出せない。イノベーターのジレンマである。プログラマとしてDECで十分経験も積んだ。ソフトウェア国際化についての知見も少なからずある。文字コードについてもJIS(日本工業規格)の標準化委員会にも参加していた。92標準のレビューもしていた。日本DECの希望退職制度(二度目)に応募したのが1994年である。自分がおもちゃだと思っていた西海岸で急成長するソフトウェア企業に転職した。東海岸の大企業とはまるっきり違う文化とノリを持っていた。機会を得て、米国本社に行くことになった。1995年6月である。8の開発チームに所属してOracleの開発を行った。朝会社に行ってコーヒーを飲む、メールを読む、コードを書く、テストを書く、時にはスペックを書き、マニュアルを書く。時々バグDBを眺めて自分にアサインされているバグを直す。サポートからの問い合わせに答える、バグ報告の多くはバグではないことを知る。マニュアルを読めと言う。マニュアルのバグを見つける、マニュアルを読む、金曜日には会社でビールを飲む、ワインを飲む、自宅で肉を焼く、魚を焼く、ビールを飲む、ワインを飲む、日記を書く。コードを書くのが仕事だ。今でこそ35歳プログラマ定年説などと言う馬鹿なことを言う人が少なくなったが(いまでもそんなたわごとを言う人がいることを知っている)、当時は30過ぎてプログラムを書いているのなんか頭がおかしいと言う風潮が日本にはあった、いらないお世話である。転職は35歳までだと言うわけのわからないことをいう風潮もあった。8のコードをゴリゴリ書いていたのは37歳をすぎてからである。野茂が大リーグに挑戦したのは1995年だ。自分が単身シリコンバレーに行った年だ。95が発売され、Netscapeが破竹の勢いの時代である。インターネットが広く知られるようになった年でもある。Software1998年1月にDECはCompaqに売却され、会社として幕を閉じた。イノベータのジレンマの典型例として、一時期の覇者のあっけない幕切れであった。1998年1月、Netscapeはそのブラウザーのコードを無償で公開すると言う発表をした。それがのちにOSSとして知られる事件だ。商用ソフトウェアのソースコードを無償で公開すると言う暴挙に(暴挙としか思えなかった)Netscapeはでた。会社としてもはやNetscapeは存在しないが、OSSのムーブメントはソフトウェア開発を大きく変えた。インターネットを前提とした世界規模のソフトウェア開発方法論、それをバザールモデルとエリックレイモンだは名付けたのだが、を実証して見せた。LinuxやRubyのようなOSSが世界を席巻する。カーネル読書会99年に日本に戻ってきて、日本オラクルでサポート部隊に入って地味に仕事をしている一方でカーネル読書会という奇妙な勉強会のようなものを始めた。狭義にはLinuxのカーネルの勉強会なのだが、話題はLinuxだけではなくてOSSやテクノロジー一般のコアな勉強会という位置付けだった。OSSの場合、ソースコードがあるので、実装レベルの細かい話を突っ込んで議論できる。大きな話からミクロな話まで自由にできるというのが心地よい。ビールを飲みながらコアな話をするというノリの勉強会になった。毎月1回くらいのペースで開催して、第100回にはLinuxの創始者のLinusも参加してくれた。LinuxそんなこんなでLinuxやOSSで遊んでいたら日本オラクルのやんちゃな人たちがLinuxのビジネスをしようという話になって、気がつくと巻き込まれていた。自分としては青天の霹靂で祭り上げられた感じである。Linuxを立ち上げ取締役CTOになった。正直に言えば、経営の経験のない技術系の人間がCTOなど務まるわけはないのだけど、それ以上に技術がわかるというかOSSがわかる人がいなくて消去法で自分がその役になったという感じである。41歳でベンチャー創業だ。時代の流れはOSSだったし、それを日本という地域で普及させるのが自分のミッションでもあると感じていた。カーネル読書会は楽しかったし、OSSを普及させるのはビジネスというよりも、こちらの活動の方が役に立っていたのではないかと思わなくもない。Memberにもなった。米国NPOの経営を現場にも参加できた。すごい勢いで全力疾走をする米国ベンチャーの経営を経験した。一方で日本では、ネクタイを締めた人がOSSの意義を理解しているとは全然思えなかったし、SIの現場の人たちはOSSを無償のソフトウェアとして使っていても、バザールモデルとか自由なソフトウェアの意義などについて理解しているとは到底思えなかった。勉強会などで若いエンジニアと付き合いが深まって行くに連れて、エンタープライズとは違う世界が東京にも草の根的に育っていることを知った。その頃、未踏ソフトウェア創造事業というのがあって、面白そうなので応募したら、採択された。2002年、44歳頃である。若手のプログラマに混ざっていい歳したおっさんが嬉々としてプログラムを書いた。*2いろいろとあって、その後、楽天に移り(2009年8月、50歳)、テクノロジーカンファレンスの運営をしたり、社内報のお手伝いをしたり、楽天IT学校に関わったりした。社内公用語が英語になったのは驚いたが、三木谷さんのリーダシップを中の人として経験できたのはよかった。プログラマとして一生やって行くのだと若い頃の自分は鼻息を荒く言ったものだが、そうでも言わないことには会社員として生きて行くのが生きづらいと感じていたのかもしれない。自分が定年になるとは思ってもいなかったし、その時の自分を想像することもできていなかった。この何年か、あるいは直近の数ヶ月、60歳になったらどうするか、どうしても自分ごととして考えることが難しかった。プログラマ定年説というのがどのような意味を持つのか持たないのか、よくわかっていない。今だにわかっていない。定年というのは会社員あるいは公務員だからこそある話で、自営業だったり、商売をしていたり、農業漁業をしている人には関係ない。自分の人生は自分で決める。引退の時期は自分で決める。会社員を辞めるにあたって、そのような当たり前のことに至ったのが自分にとっての定年退職の意義である。60歳から何を始めるか会社の規定で65歳まで再雇用される制度があるが、会社勤めは辞めることにした。