日記/2011/04/23/「技術センス」って何だろうなぁ。

先日の面接で「技術センスってどんなものだと思う？」と質問されて少し考え込んでしまった。
というのも、これまで仕事上で技術センスの「良し悪し」について苛立ったり悩まされたりあるいは驚嘆したりしたことが無いから。もちろんこれまでプログラミングをしてきた実績として、自分自身の技術センスがダメダメなわけではない、という自負はある。
もしかしたら、プログラムソースコードと付き合っていく中で「上手い作り方してるなぁ」とか「ダメダメだなぁ」とか感じたものが、実は「技術センス」の良し悪しだったのかもしれない。
でもそれも、技術センスの「結果」としてソースコードの上手い下手なのかもしれない。

じゃぁ根源的な「技術センス」って何だろうと思い、自分より年下の技術者で「筋が良いな」と感じた人を思い浮かべてみる。

彼・彼女らに共通なのは、「目の前のレイヤーの一つ下のレイヤーまで想像し、調べようとしている」こと。

端的にまとめると「好奇心」となるし、もう少し技術者寄りの言い方をすると「時計やラジオを分解して中の仕組みを覗いてみたい」、そういう姿勢だろう。

ただ、もう二つ、面接で言いそびれた要素がある。
IT技術に絞ると、どの技術もその後ろにはそれを考案し、実装した「人間」が必ずいる。なぜこの技術が開発されたのか？開発者を取り巻く当時の状況は？などなど。
そうした文脈、コンテキストを簡単でも良いので把握しておかないと、その技術の適用範囲、対象を間違えてしまう。

なので、「技術の向こう側にいる、それを開発した人間」を想像できること。これも「技術センス」には必要なことなんじゃないかな、と思う。

勿論「使う人間」も想像できないと駄目なのだけれど、個人的にはニーズが先にあって技術が発達すると考えているので、最初のニーズが開発者自身のひとりだけだったとしても、使う人間を想像するのは必要条件だと考えている。わざわざ明示的に「技術センス」に含める必要は無いかなとも思う。

最後の一つが「A is B, but A is NOT C」を切り分ける、あるいは切り分けようとする「意思」だと思う。
ある現象に目を向けたとき(ソフトウェアバグとか)、それの原因というか実体というか本質を捉えるのには無数の「A is NOT C」を見つける必要があると思う。
なにより、「A is B」を見つけるよりも「A is NOT C」を見つけるほうが大変。原因を取り違えるのは良くあることだけど、それも「A is B」や「A is ALSO D, E, F...」と間違えるのが簡単だから。
逆に「A is NOT C」「A is NOT D」を積み重ねていって、影響しない要素を削り落としていくのは大変。「影響しないことを断定する」のって結構精神的にも怖い。なぜなら、たった一件の肯定で全て覆ってしまうから。

だらだら長くなってしまった。「技術センス」を三行でまとめると：

• 一つ下のレイヤー、裏側の仕組みを把握したいと望む好奇心
• 技術を作った人間に想いを馳せる想像力
• 「A is B」だけでなく「A is NOT C」を積み重ねて因果関係を明らかにする分析力

最後に一点だけ。
技術センスが欠けているからと言ってIT技術者失格、というわけではないと思う。
IT技術者への入り口は沢山あり、技術力を支える基盤も沢山あるだろう。
上で述べた「技術センス」はその中の一つであり、根っこではない。

「技術センスが自分には欠けてるのではないか」と悩んでいるとすれば、「技術センスが無くてもやっていけるだろう」と開き直っても良いし、あるいは技術センスが良いと思われる知り合いを増やして助言なり手助けなりをお願いしてもいいだろう。

或いは「あいつは技術センスがない」と部下や同僚に悩んでいるとすれば、それはその人の一面だけしか見ていないのかもしれない。あるいは、「自分のほうが技術センスが高く優秀だ」という傲慢かもしれない。悩みの大元、自分が他人の無能について悩むときの心の動きについては特に注意して観察する必要がある。

蛇足：
・・・これまで「技術センス」を、どちらかというと「職人的な筋の良さ」の文脈で使っていた。
これに反対する人、あるいは別の文脈で「技術センス」を捉えている人もいるかも知れない。

自分がこれまで仕事上で尊敬できる人はどうだったかというと、必ずしも「職人的な筋の良さ」を感じられる人、あるいは上で述べたような技術センスを有する人ばかりではなかった。
アセンブラからFORTRAN、制御機器の特殊なシーケンスプログラミングを経験した辺りでマネージャに移った人は、対顧客交渉や営業、調整能力に秀でていたと共に人をdriveするのに長けていた。
C言語どっぷりで、C++やオブジェクト指向が分からないと嘆いていた人は、細かいプログラミングテクニックではなく、「システム全体」の設計や評価能力が非常に高かった。コンポーネント間の連携におけるデータの整合性について鋭い感覚を有しており、システム全体として動作するときの矛盾や辻褄の合わない点を真っ先に指摘する役割を担っていた。

そういった、技術センス以外の面で尊敬できる人たちに、随分と助けられてきたことを最後にメモして、だらだらとしたこの記事を締めさせていただきます。