フェティシストの先輩はいくじなし

私が今のように酒飲みでなく、駆け出しのPerlプログラマだった頃、先輩がいた。

私達が仕事のコードを書いている時、先輩は聞いたこともないフレームワークのテストをしていたり、英文のサイトを読んで大半の時間を過ごしていた。
たまに気が向くと、私のような新米プログラマー達にDBマイグレーションが簡単にできる方法や自作のフレームワークのアーキテクチャを優しく教えてくれたりしたが、それらは全て当時の私達の理解を超えていて、正直、どう反応していいものやらわからなかった。

1

ある時、私達のプロジェクトが炎上した。
納期ギリギリで、システムが出来るには出来たのだが、挙動が不安定で、何より実行速度が極度に遅く、想定のユーザー数をさばけなかったのだ。

社長が出てきたり、顧客との悶着があったりした末、納期が再設定され、先輩がプロジェクトリーダーになり、私達がそれを手伝うことになった。

のんびりした様子で先輩は私達のコードをざっと眺めて、まずそれを褒めた。
「ちゃんとモジュール化されているし、DBコネクションが複数張られることもない」
「思ったより悪くないね」と先輩は微笑んだ。

そして、笑顔のまま、それらのコードを全て放棄した。

2

先輩が重視したのはとにかくシンプルさだった。

例えば失敗したシステムには、私が書いた拙いORマッパがあった。
Userオブジェクトを生成して、saveメソッドを呼び出すと、userテーブルに書き込まれる、といったアレだ。
先輩は「こういうのは結局使いにくいんだよ」と言って、全てのテーブルについてfetch_user、add_userのような関数を作るように命じた。（今で言うとトランザクションスクリプトだ）

また、生真面目にBEGIN、COMMITといったSQLを発行していたものを、トランザクションオブジェクトを作って、そのbeginメソッド、commitメソッドを呼び出すようにした（commitせずにオブジェクトが破棄されるとrollbackする仕組みだ）

しかし、その実装を見た私は驚いた。RDBMSのトランザクションに加えて、システム全体で単一のロックファイルを使った排他制御が行われていたのだ。

せっかくRDBMSのトランザクションを使っているのに、なぜジャイアントロックをするのか。こんなことをすればユーザーが何かを更新する度に、全てのテーブルの読み込みが待たされることになる。
私は当然懸念を表明したが、先輩は「これで十分」と言って聞かなかった。

こんな調子で、予定通りシステムは出来上がった。想定の性能も出て、問題らしい問題は全くなかった。

私は半ば感心し、半ば挫折した気分だった。
なぜプロジェクトが成功したのかもよくわからなかったし、何より、私達が書いたコードは全て捨てられてしまった結果がこれなのだ。
まるで、0点の答案を返されて、追試で答えだけを教えてもらって合格点をもらった。そんな気分だった。

3

先輩が会社を辞めたその後も、あの時の先輩の判断について私は考え続けた。

ORマッパについては、そもそも出来がよくなかったし、もし、使い続けていたらひよっこの私達には使いこなせないか、習得やバグ取りに時間をとられることになっただろう。
なにより私達は、fetch_userでuserデータを取り出し、update_userでデータを書き換えることに何の疑問も抱かずにすんだ。

ジャイアントロックについては、正直ずっと釈然としなかった。
実際、後のバージョンで、必要に迫られて私はそれらを全て除去した。（ご想像の通りサーバーの台数が増えてファイルロックが使えなくなったのだ）

しかし、データ不整合が起きたと聞いた時(結局、それは誤解だったのだが)、真っ先に自分の実装を疑わなくてはいけない羽目に陥った。

先輩は常に正しかった。と私は数年後に思った。

私達ひよっこPerlプログラマーという手数、次は絶対に失敗できない重圧、納期、それら全ての要因を考えた上で、全てが「ベストの選択だった」としか言いようがなかった。

4

齢を重ねた。

私の歳はとうに当時の先輩の年齢を超えている。
経験も、まあ努力の差や、私の怠惰な性格を差し引いても同等かそれ以上になるだろう。
本当なら、私は当時の先輩の境地に達している筈である。

だが、今だに私は先輩がわからない。

後輩や誰かが書いた無駄に複雑でバグだらけのコードを見ても、先輩のように全てを破棄する決断を下すことができない。
これはこれで動いている以上、どこか正しいのではないか、と、思ってしまう。

生産性を増大させる見込みのあるフレームワークやアーキテクチャを見分けることができない。
新しいフレームワークを見ても、将来性や導入（学習）のコストを考えて、二の足を踏んでしまう。

私ができるのは、せいぜい、前任の某が使っていたのが回ってきたから、という理由でフレームワークを選んだり、クイックハック気味にバグを取ったり、あんまりひどい時はコードを少しリファクタリングしてわかりやすくするぐらいのことだ。

今でも私は、先輩のように、あの故郷を目指してただ一直線に突き進む鳥のように、速やかに、迷いなく、何かを決めるということができない。ただの一つも。

5

しかし、とも思う。
自分の才能の無さを棚に上げれば、先輩は一種のフェティシストだったのではないか、と思うのだ。
シンプルさやミニマルな実装に対する偏愛があっただけだったのではないか、と。

私は先輩の鮮やかな開発を見た。まるで最初から最後まで全てをわかっているような決断の速さと、狂いのなさを見た。
反面、今の私はどのような開発現場にも使える「銀の弾丸」が存在しないことも、また知っている。
納期やクライアントの理不尽さに対抗するには、手段を選んではいけない事を知ってしまってもいる。

今の私にはシンプルを愛する先輩がその後も、どんな状況でも上手くやれた、とまで言い切ることができない。

6

ダーティーなクイックハックを行う時、こういう時、先輩ならば、と私は何度も自問したものだ。
それでもなお先輩はシンプルを追い求めるだろうか？と。

おそらく追い求めるだろう。営業の虚をついて、以前のコードを全て破棄するぐらいのことは平気でやってしまうだろう。
なぜなら先輩には「確信」があるからだ。一切のバグを出さず、所定の時間で、自分の好みに実装を作りかえるぐらいわけはない、と本気で考えているのだ。

私にはついぞその「確信」は芽生えなかった。
私はただ迫り来る波をうまくかわせればいいとだけ思っている臆病なサーファーだ。

だが、プログラマとして生きていくにはそれで必要十分なことだったように思う。

風の噂で、先輩は私よりずっと早くプログラムを辞めて、ITとは何の関係もない仕事についた、と聞いた。

フェティシストは「完全」を知っている。だが、それ故に生き続けるのも難しのかもしれない。
私は「不完全」なシステム開発の汚濁を生きた。だからこそ、まだ立っている。
まあ、抜け出せなくなっているだけかもしれないのだが。

ただ今でも、私がコードを書く時、必要以上に複雑になっていやしないか、と少し怯えている背中から、私の先輩はあの時の笑顔のまま、私のコードを見てくれているのだ。

筋少の大車輪