創造的なエンジニアのための働く環境とは（１）

最近、自分のワークスタイルを大きく変えてみて、非常に強く感じることがある。

エンジニア、それも言われたことをソツなくこなすタイプではなくて、アンテナの感度が高く、自発的に新技術を磨き続けることを怠らず、自分の作ったものを広く世に出すことが楽しいと考えるエンジニアが、商業的に実りのあるモノを作り出せるようになるためには、ある特殊な条件が、きわどいぐらいのバランスで揃うことが重要なのだな、ということがわかってきた。もちろん、まだそれを理解するプロセスの真っ最中なのだけれど、考えがひとまとまりの輪郭をとってきたので、つれづれ書いてみようと思う。

ぼくは、インフォテリアというソフトウェアの会社で６年も製品企画その他、会社がリリースする「モノ」の運命にかかわる重大な意志決定に、経営面でも技術面でも携わってきた、、、つもりだったわけだけれど、つい最近までこの大切なことに気づくことができなかった。本人がいくら「何一つ見落とすまい」と努力しているつもりでも、本当に「つもり」で終わってしまう絶対に見えない何かがあったってことだ。

自分の勘の鈍さを呪わずにはいられないし、エンジニアという職種を離れてしまうと、こんなにも多くの大切なことが見えなくなってしまうんだな、とつくづく感じた。（あぁ、こんな記事を書いたのはもう２年半も前のことだったか。。。それにしても過去の自分のブログポストを読むと、いかに自分が変わったか・成長したかを認識できていい。）

さて、ここから述べることは、ディティールは異なれど、ぼく自身の回顧録でもある。ある種の懺悔みたいなもんだと思って読んでもらって構わない。

それが何かっていうと、技術ベンチャーにとってエンジニアは他の誰よりも（社長よりも）重要だということと、エンジニアが一線から退いてマネージャになったり企画屋になったりする時には、なにやら後ろめたい動機が背後に隠れているっていうこと。

それはね、自分が「技術の世界の変化の早さについていけなくなったかも」と感じる瞬間に起きることなんだ。

もちろん、家族を養うためにもっと給料をもらえるポジションが欲しくなった、というような、ごもっともな理由だってありうるけれど、そういう「言い訳」をしている裏には、こういうコンプレックスというか挫折というか、ある種の劣等感を感じている側面がないとは言えない。

たとえば、Cでコーディングするのが主流だった時代には誰よりも早くコードが書けて、頭の中に「問題とそれを解決する実装方法」をむすぶリンクに潤滑油が効いていて、まるで日本語のようにスラスラと書けていた誰かさんが、ちょっと他のこと（女の子と遊んだり、バンドにはまったり、まぁ世の中にはお年頃の青少年が楽しむべき、ありとあらゆる誘惑があるからね）にうつつを抜かして技術の修練をサボタージュしている間に、世の中はどんどん先に行ってしまう。さて、久々に技術に興味が戻ってきたのでどれどれ再開してみるかというときに、なんだか世の中がJavaだらけになってしまっていて、オブジェクト指向の概念が何だかつかみどころがわからくてついていけなくなってしまった。頭の中にあった「問題とそれを解決する実装方法」のリンクも何だかさび付いていて、自分の思考のスピードにコーディング能力がついてこなくなる。周りの人たちに、どんどん追い越されていく感じがしてくる。

これって、自分の言いたいことを英語で言えないときのもどかしさと同じなんだ。日本語なら、こんなにスラスラ言えるのに。。。っていう、あれね。日本語だって、普段から使ってないと、しばらく手を抜いてるとさびつくぞ。

より長い人生を生き、経験は積んでいるわけだから、言語化できない概念レベルでは一瞬で解決方法が見えている（つもりな）のだけど、それを形に、アウトプットにできない。それがもどかしいんだ。何事も、日々の筋トレが重要ってこと。

そもそも、言いたいことをうまい日本語にするのの10倍ぐらい、コーディングという作業には時間がかかる。なぜかというと、日本語を伝える相手は人間だから、相手と自分とがツーカーな関係であれば、多くを語らなくてもわかってもらえる（つもりになれる）が、コンピュータは誰に対しても等しく頑固だからだ。まったく文脈を補ってなどくれないし、ちょっとでもミスがあると冷たくプログラマーを拒絶する。このデバッグという超イライラする地道な作業が、多くのプログラマーを引退に追い込む原動力だ。

だから、プログラマーとしての経験を積んでくると、自分は概念だけをポンチ絵か何かにして、そのイライラするデバッグという作業を抱えた、コーディングというもどかしいプロセスを別の人にやってもらおうと考えるようになる。果てしない苦しみの日々を捨てて、楽になりたいんだ。

これが、大きな間違いの始まりなんだな。

これってつまり、自分の言いたいことを、誰かにうまく代弁して欲しいってことでしょ？

そんなあなたは、いつもいつも、プログラマーが提出してくるモノに落胆し、ブー垂れてるのが関の山だろう。だって、あなたの満足するものを仕上げてこれる人っていうのは、あなたと同じレベルで上位概念がわかる知性をもち、かつそれをあなたの文脈に置き換えて解釈できる知性も持ち、さらにそれを根気よく表現力豊かに言語化できるという、つまりあなたよりはるかに頭がよくて仕事ができる人である場合だけだからだ。そして、そんな人はあなたの部下ではなくあなたの上司であるべきだ。

そう、実際問題、真に才能のあるプログラマーは、上司の上司であるべきだ。

そういえばJoel Spolskyもこんなことを書いていた。

・・・奇妙なのは、私が職階の｢最下層｣にいたということだ。そう、私には部下は誰もいなかった。私が誰かに何かしてもらいたいと思ったら、それをするのが正しいということを納得させる必要があった。もし主席開発者のベン・ワルドマンが私が仕様書に書いたようなことを何もやりたくないと思っていたなら、彼は単にやらなかっただろう。テスタが私の仕様書に書いたことは完全にはテストできないと文句をつけてきたら、私はそれを単純化する必要があった。もしこれらの人々の誰かが私の部下であったなら、製品はそんなに良いものとはならなかっただろう。彼らのあるものは上司にとやかく言うのはまずいと思うかもしれない。あるいは、私がうぬぼれや近視眼のために、私のやり方でやるように断固として命令していたかもしれない。実際にはコンセンサスを得る以外には私に選択肢はなかった。このような意思決定形式が、正しいことが行われるようにするための最善の方法だった。

思いついたことを誰かにやらせれば良いモノができるんだったら苦労はない。

アイデアを思いつくだけだったら、あなたがどんな素晴らしいアイデアを思いついたとしても、同じことを思いつく人間は世の中に100人はいると思った方がいい。

だが、そのアイデアを形にする過程にはさまざまな難関がある。ほとんどの場合、それをどう進めればいいのか見当もつかない。だから、戦略というのはアイデアそのものじゃなくてこの過程にこそ埋め込まれるんじゃないか。神が宿るのはアイデアじゃなくてディティールなんだよ。

いくら金を積もうが、エンジニアリングの現場を知らない誰かさんの考えるようにはプロジェクトは進まない。それに、本当に画期的なアイデアであればあるほど、物事が予想通りに運ぶはずがない。途中に山あり谷あり、軌道修正を繰り返すわけで、「まっすぐ進め」しか言わないマネージャなんて役立たずどころか邪魔なだけだ。

つまり、もっとも重要なビジネス上の意志決定を行うべきポジションというのは、そういう山あり谷ありのエンジニアの現場にある。迫り来る氷塊や荒波をかわし、命運をともにする同志として同じ船に乗っていなくちゃいけない。指示する・指示される関係、であってはいけないんだ。

こんな基本的なことに、ぼくは今頃ようやく気がついたんだ。

だから、ぼくは若かりし頃の自分に戻ることにした。ふたたび、変化の早い技術を追い続けるレースに身を投げる決意をした。人よりもほんの少し先まで未来を見通すことができた、あの頃に戻ることにしたんだ。

一切の妥協なく同じ技術レベルでコミュニケーションすることを通じて、ぼくの考えを代弁してもらうっていうんじゃなくて、チームで思考そのものを共有し、最終的にはプログラマー本人の思考の結晶としてアウトプットしてもらうんだ。

こうして、いま、ぼくのプロジェクトにかかわっているエンジニアとの微妙な空気を孕んだ人間関係を「作家と編集者の関係」になぞらえるとうまく説明できることに気がついた。

次回はこの件について書くとしよう。

（続く）

♪ Dokken / Mr. Scary