「本物のプログラマ」もNEETになり得る御時世の処世術
ぼくはIT業界の中で技術者からマーケティングに移った人間で、最初こそ張り切ってコトラーとか読んだけど、外資系企業で日本法人にいて3Cとか分析しても4Pのどれも殆ど触れないことに気づいて、これじゃマーケティング戦略の勉強にはならないなぁと感じて途中から技術渉外っぽい仕事に路線変更した。*1技術渉外というのも一風変わった仕事で、似たような仕事があるといっても非常に限られているだろうし、日本企業のそういった部署で中途は採ることは少ないだろうから、日々潰しが利かなくなっているのではないかという不安はある。けれどもまぁ、英語とか段取りとか、自分の苦手なところを鍛えつつ、少し突き放して業界の仕組みを眺める居場所としては面白い。
どこかでいざとなったら技術者に戻れるという気持ちもあって、Virtual PCでLinuxとかの環境はつくっているし、手元の環境には一通りのコンパイラは入れているし、研究所でつくってる新しいマイクロカーネルのソースコードをデバッガで追いかけたり、流行りものは一通り遊んでいるんだけど、基本的にプログラムは書かないし、顧客と接したり問題を解いたりしていないので、きっと技術者としては相当ナマってるだろう。
僕は技術の歴史性は意識しているけれども、優秀なプログラマになることは早い段階で諦めてしまった。優秀なプログラマというのは、歴史を知ってようが知ってまいが優秀なのである。別に修辞学や言語学に造詣の深い奴が良い物書きになるとは限らないのと一緒である。そして僕は優秀なプログラマでもシステム屋でもなかった。
僕の知る優秀なプログラマの多くは、確かに流行りのCの末裔*2ばかりでなく、アセンブラやFortran、Lisp、Prolog、ML、Haskellとか変な言語も触っているひとが多い気がする。きっと、特定の言語による抽象を所与のものとして受け入れている限り、超えられない壁のようなものがあるんだろうね。いろいろ知ってればJavaでアセンブラレベルのチューニングもできる*3し、Cobolでオブジェクト指向プログラミングだってできるのだ。
そういえば日経バイトの最終号でまつもとゆきひろさんがプログラミング言語でここ20年間は進歩がないということを書いていた。言語のことはよく知らないけど、カーネルもここ20〜30年近く進歩がない。WindowsもMacもLinuxも、UNIXの亜種ばかり残ってしまった。*4細かい違いはあれど、『オペレーティングシステム―設計と理論およびMINIXによる実装』を読めれば、だいたい中身がどうなっているかは理解できる(ような気がする)。みんな大部分がC言語で書かれPOSIXをサポートし、メモリ保護は2階層しか使わず、それなりにモジュール化しているけどマイクロカーネルではない。
でもUNIXやMachでOSの進化が止まった訳ではなく、そこから先もPlan 9とかInferno、Spring、Java OSとか色々と面白いことをやったんだけど、遅かったり互換性がなくて普及しなかったのである。けど、そろそろ状況は変わるかも知れない。セキュリティのことを厳密に考えると、ずっとシステムやデバイスドライバをC言語で書くのは辛いし、仮想化技術*5とマルチコア*6が普及すると古い資産は別パーティションで動かしましょうという逃げができるし、ソースコードレベルで形式的手法と連携させるとか、品質管理手法も大きく変わるだろう。僕はUNIXの亜種達に「レガシー」のレッテルを貼れるようになる日を楽しみにしている。閑話休題。
言語にしてもカーネルにしても開発者から覚えてもらわなければならないし、枯れるほど資産もノウハウも溜まるから、往々にして技術というのは急速に普及した時点のものでピン留めされてしまうのである。確かに世界はCやUNIXの亜種ばかりに席巻されてしまったけれども、ヘンテコな言語やOSは日々開発されている。新しいことは覚えるのが面倒だし既存資産がないから、そのコンセプトは忘れられるか、取り込まれるのが世の常であって、そう新しい発明なんてないから、忘れられた技術たちの歴史を知っていれば、いっけん新しげな技術と出会っても萌え要素の組み合わせに過ぎず、驚き戸惑うことは少ないのである。
然るに、この手の薀蓄を語る上で技術の歴史性は非常に重要だし、それは中身のない与太話の原稿を水増ししたり、コンサルと称して茶飲み話に行って専門家面するには使えるし、そういう衒学的な付加価値で高い人月単価を取る商売も世の中にはあるし、それはそれでIT肉体労働者ではないのだけれども、「優秀なプログラマ」でもないのである。
とここまで書いて、僕の考える「優秀なプログラマ」が「本物のプログラマ」であることに気づいた。然るに技術の趨勢は本物のプログラマを必要としない方向に向いている。誰が本物のプログラマであるかは本物のプログラマにしか分からないので、本物のプログラマではないマネージャにとって、みんなにFortranではなくPascalを、CやアセンブラではなくJavaやPHPを使わせた方が安心なのである。デバイスドライバとか組込系とか、どうしてもCやアセンブラで書かなきゃならない部分もあるけれども、ここは仕様の切り分けが容易なので、研究や趣味で触る以外は、真っ先にインドあたりに外注に出すべき仕事だ。Larry WallがO'Reillyをレイオフされる*7ようなご時世だし、人件費の高い日本や米国に残る高付加価値の仕事は、恐らく小野さんの宣言したプログラム・デザイナーのような路線なのだろう。それも付加価値に見合った対価を得るには、受託開発ではなく製品開発をやった方がいい。客にいわれたことをやっている限り、人月で買い叩かれてしまうからである。ひとより高い人月を取るには、ひとより先に新しい技術に手を出し、コモディティ化する前に次のネタを探す必要がある。けれども実績のない新しい技術を使うのは顧客が躊躇することが一般的であって、よほど優秀な営業に恵まれないと難しいし、失敗すると一瞬でプロジェクトが赤字になるような薄利のSI稼業では、そんなリスクのある提案はなかなかさせてもらえない。それに目先の案件や運用保守に引っ張りまわされている限り、なかなか新しい技術で遊ぶ暇もないのである。だから、努力に応じて技術者が幸せになるには、自前のサービスなり製品なりを持って、他人から頼まれた仕事ではなく自分の事業のために技術を磨いた方がいい。まぁリターンの大きい分リスクも大きいし、ネット広告バブルもいつまで続くか分からないけどさ。
という訳で僕は狭義の情報サービス産業でのキャリアパスからは絶望して逃げたけど、IT産業そのものにはまだ可能性を感じている。僕は本物のプログラマを掛け値なしに尊敬するけど、仮に本物のプログラマになれたところで、IT肉体労働者か出版奴隷かNEETになってしまうかも知れないことは知っておいた方がいい。大事なことに早い段階から気づいたようだし、頭の柔らかいうちに技術の全体像を知ることは悪くないと思うから、使い潰されて磨り減って、ふと気づいたらIT肉体労働者に堕ちていたなんてことのないよう祈ってる。
最後にどうでもいい突っ込みをすると、パソコンの歴史は40年ではなく30年だし、プログラム内蔵型デジタル計算機の歴史は60年だ。アナログや機械式も含めると計算機の歴史はさらに長い。こんなことを知ってたって何の役にも立たないけど。
出版・広告業からＩＴ業界に転職していろいろ思うところがある。
ＩＴ業界の技術者見習いの立場にうちは今いる。で、この業界って、毎日覚えなきゃいけない知識や技術がたくさんあることを実感してる。技術の歴史性をどれだけ意識してるかどうかで、優秀なプログラマかどうかが決まる。パソコンの歴史なんてたかだか４０年なんだけど、流行のプログラミング言語を覚えるだけじゃなくて、パソコンのハード、ネットワークの仕組みや、そもそもプログラムがなんで動くのかってことを覚えないと、ＩＴ肉体労働者で終わってしまう世界。
*1:ちなみにマーケティングを諦めた訳ではない。自分の考えている4Pもいじれるマーケティングをやりたければ本社にいくか、他社に転職すべきなんだろうけど、とりあえず目先にそういう選択肢が見当たらなかったのだ。それにマーケティング理論はベタに仕事にするだけでなく、自分の売り込み方を組み立てることにも使える、ということに気づいたし。
*3:確かiアプリで動く某エミュレータの作者だっけか、携帯電話機メーカーからJITコンパイラのソースコードを借りて、JITコンパイルされた後の命令数ができるだけ小さくなるようにチューニングしていた
*4:Windows 9xとかMac OS 9とか最近まで非UNIX文化圏はあったのに。そういえばOS/400とかz/OSは非UNIX文化圏で興味深いけど、公開されてる文書も少ないし手元で触る機会がないからよく知らない
*5:これも最近のバズワードだけど、S/360で動くCP以来40年近くの歴史がある
*6:単にプロセス技術の制約によるパッケージングという話であって、技術といえるかは微妙
*7:Tim O'ReillyはWeb 2.0とか煽っておきながら出版事業の不振に喘いでいるらしい。まぁ先がよくみえることと、正しく体を動かせることとは違うんだろうし、Larry Wallならその気になればいくらでもスポンサーが集まる気がするけど
