人生を書き換える者すらいた。人生を書き換える者すらいた。この1年は家族との時間を重点確保だったのでこなした仕事量は例年よりかなり少なめだったけど、最近新しい仕事仲間も増えたことだし(どのくらいの戦力になるかは不明だが)、来年は今年地下で進行させていたプロジェクトをどんどん表に出していきたい。この1年は、人に指示を出して仕事をさせるという点で僕にとってはいろいろ経験が大きかった。この立場になると、ついつい「泥臭くて技術的価値は低いけど任務遂行のためには必要」なことを人にやらせたい誘惑が出てくるものだというのが自分でよくわかった。いう作業はハッカーは忌み嫌うものだし、僕も他人に指示されたらあまりやる気はないものなので、エンジニアリングとして楽しい仕事になるよう常に心掛けたい。「泥臭くて技術的価値は低いけど任務遂行のためには必要」これについて考えさせられた事件がサラリーマン時代にあったのでこれを書いてみようと思う。この事件は僕が独立を真剣に考え始めた大きなきっかけになった事件で、実は今でもときどき夢に出てくる。当時サラリーマンだったとき、組み込み向けのJavaVMの仕事をしていた。イチからVMを書くのではなく、ライセンスを受けたソースコードをベースに若干の機能追加や本来想定していない別のOSへの移植とかをやっていたのである。ここでVMが動作中に謎のクラッシュをする問題が発生した。その組み込み環境向けには専用のC++コンパイラを使わなければならないのだが、それがどうやら怪しい雰囲気である。試しにコンパイラの最適化オプションのレベルを下げて動作させると正常に動くようになったので犯人はコンパイラと特定された。聞いたことないメーカーのコンパイラだし、コンパイル速度がたいへん遅い(VisualC++に比べると5倍は時間がかかり、VMをフルビルドすると30分もかかる)し、もともとコンパイラのレベルが低そうな雰囲気はあったからな...さてどうするか?最適化しないでコンパイルした製品を出荷することはパフォーマンスの観点から受け入れられない。コンパイラの製作元に連絡して修正してもらうか、別のコンパイラに乗り換えるかするのはスケジュールが間に合わない。会社には僕と別チームでやっている全く別のJavaVMを使う選択肢があり、それを使えば対外的な契約上は問題はない。それを使うことにすれば僕のチームの数か月の仕事は捨てることになるし、チームの会社内での評価も必然下がってしまう。ボーナスや昇進にも影響出るだろう。僕はこの時点で、コンパイラの問題なんだからもう手出しはできないし、自分のチームの負けを認めて降伏しよう、と思っていた。コンパイラの品質に問題があることをもっと早く発見できなかったのがチームのミスである。ところが、同じチームの同僚のK君は違った。普段から人付き合いは苦手で黙々と作業するのが得意な性格ではあったが、なんと彼は次のような作戦に出た。●VMのソースファイルを半分に分け、AB2グループを作る。●Aのみ最適化したもの、Bのみ最適化したもの、で2つのVMをビルドし、それぞれ動作させる。●クラッシュした側で最適化しているファイルのどれかに問題があることが特定される。半分に絞った問題のあるファイルについて同じことを繰り返して絞り込んでいくわけだ。いってもファイルは100以上あるし、1回のビルドで30分かかるのでとんでもなく時間がかかる。K君は徹夜して(20時間はぶっつづけで仕事したはずである)問題のあるファイルを1つに絞り込むことに成功したのである。この根性は尊敬するし、「期限内に動作するVMを仕上げる」という会社のミッションをクリアするという点では最適な行動だったと今でも思う。技術的な観点からは、仮にここを一時的に凌いでも将来のメンテナンスのことを考えるとそんな爆弾を抱えたコンパイラを使うこと自体がありえない。僕は、いくら会社から与えられた任務とはいえ、技術的には危険で、かつ単調な徹夜作業をK君のようにこなせるかというと絶対に無理だ。金をもらってもやりたくないと思った。一方で会社の立場では、やはりK君のような行動を勇士として認めなければならない。上司の立場だったら、K君のような兵士は重宝するだろう。この事件をきっかけに、もっと面白い仕事を自由にやるポジションがいいな、と思って独立を考えはじめたのである。サラリーマンとして仕事してれば、断ることができないシーンがどうしてもあるからね。独立して面白さ・仕事量・稼ぎのバランスを自由に変更できるようにならないとこの先もたない、と思った。僕がサラリーマンを辞めたのはこの事件の半年後くらいである。大企業はどれだけ息苦しい世界なんだ...部下がいるとつい面倒なタスクを丸投げしたくなるが、それは我慢して面倒を回避する技術を確保するようにしたい。