アーキテクトと変態は紙一重
「卵をテーブルに立てることができますか？」「そんなのできるわけがない」「こうやるんですよ。グシャッ」「そんなの俺でもできる！」
コロンブスの卵のような話は多々あって、工学の成果の多くはそういうものかもしれない。「こうやればできる」を探し出すまでが大変で、見習って真似るのはよほど簡単。よほど簡単とはいうものの、それでも10年ぐらいエンジニアやっててもなかなか到達できなかったりする世界だったりするわけだ。道を開いた人はまさにニュートンの言うところの巨人で*1そうした偉大な先人の肩に乗って僕らは若くして多くの知見を得られ、多くの技能を身につけることができる。
エンジニアたらんとするなら、やはり何かを切り開きたいものだ。自分は巨人ではないけれども、巨人の真似事をしようと悪戦苦闘の日々である。アーキテクトを志したからには背負わねばならない業の様なものだ。
アーキテクトの発想
実業務では日々いろいろな課題がつみあがる。それをとにかく「なんとかする」のがアーキテクトのお仕事のひとつ。*2「どうにもなりませんね」じゃダメなんだ。少しでもマシな方向へ進まなければいけない。そのためにはいろんな手段を考える。多くの手段はボツになる。言語仕様の隅々まで活用して王道なアイデアから荒唐無稽なアイデアまでとにかく絞り出して活路を見出す。
通常は有益な使い方を考えるところを、無益な使い方を考えて遊んだのがJava変態文法最速マスター - プログラマーの脳みそなんだ。確かにここで用いられている文法は100%Javaの言語仕様の範囲内だ*3。そんなの知ってる。Java言語仕様に載ってるよ」とか言うなら、真っ先に卵を潰してテーブルに立ててごらんよ。使われているアーキテクチャ（というかここでは文法だが）が既知で簡単なものだったからといってプロダクトを侮ってはいけない。どれだけ知っていても必要な時に引き出せないようでは駄目だし、踏まえて応用してアイデアを練れなくては役に立たない。
図書館は知識をたくさん保持しているが、エンジニアを代行できない。図書館の本でエンジニアが育つのだとしてもだ。そこが図書館とエンジニアの決定的な差なんだ。
Xxxが使えない、どうする？
エンジニアリングにはやはり王道というのがあって、こういうときはこう対処するのが一番筋がいいといった方法論がある。通常はそうすればいいのだけど、現場というのは何かと起きるわけで、その王道が封じられるシチュエーションに遭遇したりする。そんな時どうするのか。
「あーっとJavaの開発をやっていたら社給品*4のHHキーボード(\24,990)のセミコロンが壊れて利かなくなってしまったー（棒」
「if (null==hoge()){}の形で呼べば戻り値のあるメソッドは呼べるぜ」
「リフレクションを使えば戻り値がvoidのメソッドでも呼べるぜ」
「HashMapをextendsすればフィールド宣言の代わりにput()とget()でデータを保持できるぜ」
「returnが書けないから戻り値のあるメソッド作れないかと思ったがHashMapをスコープ代わりに使えば代替えできるな」
「なんだ、セミコロンなくてもなんとかなるじゃん」
「ちょｗ キーボード直すとか、コピペするとかしろよｗ」
「なんだよ、元気いいな。何かいいことあったのかい？」
そんな感じで架空の課題の解決に取り組んだのがJavaでセミコロンなしでプログラムを書く - プログラマーの脳みそだ。傍でケラケラ笑うのもいいけど、こんなとき何がしかの対策を提案できなきゃただの頭数にしかなれないよ。何が起きても何とかする指揮官がいるとしたらどれだけ心強いだろう？アーキテクトの道を行くなら、そういう期待に応えなきゃいけない。
呼吸をするようにアイデアを考える
そんなわけで、日々現れる課題をクリアし続けるためにも、アーキテクトは呼吸をするかのようにアイデアを提示し課題を解決しなければいけない。
ネタで変態的発想ができない奴が業務で革新的な発想ができるものか
なぎせ ゆうき on Twitter: "ネタで変態的発想ができない奴が業務で革新的な発想ができるものか"
スポーツ選手が日々ランニングをするように、アーキテクトはお馬鹿な課題にとりくんだり、お馬鹿な解決手段を試したりしなければいけない。楽しむことが何より大事なんじゃないかな。
