いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。
これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題自体を変えるのだ。
あなたの書くコードは、探索している問題に対するあなたの理解を表している。だから頭の中にコードを保持できたときに初めて、問題を本当に理解したと言えるのだ。
プログラムを頭の中に入れるのは容易なことではない。プロジェクトを何ヶ月か放っておいたなら、戻ったときに再び深い理解を取り戻すのには何日もかかる。そのプログラムに積極的に取り組んでいる場合でさえ、その日その日に取り掛かるとき頭の中にプログラムをロードするのには30分もかかるかもしれない。そしてこれはいい場合での話だ。典型的なオフィスで働く普通のプログラマがこの状態に至ることは決してない。 さらに劇的なことを言うなら、典型的なオフィスで働く普通のプログラマが、自分の解いている問題を本当に理解することは決してない。
最高のプログラマでさえ、取り組んでいるプログラムの全体をいつも頭にロードしているわけではない。しかしそれに近付くためにできることはある。
プログラマが偶然の事情でこれらの8点をすべて満たしている場合がいかに多いかは驚くものがある。誰かが新しいプロジェクトのアイデアを考えつくが、公式に承認されたものではないため、自分の時間でやることになる——しかしそうすると邪魔が入らない のでより生産的なことに気づく。自分の新しいプロジェクトへの情熱に突き動かされているため、休まずに長い時間続けることになる。最初は単なる実験なので、「製造用」言語ではなく、単なる「スクリプト」言語を使うが、実際にはその方がはるかに強力だ。彼はプログラム全体を何度 も書き直す。公式のプロジェクトであればそんなことはできないかもしれないが、彼は好きでこのプロジェクトをやっているのであり、完璧なものにしたいと思っているのだ。自分以外の誰も見ることはないので、個人的なメモのようなものを除けばコメントも省略している。一緒に働くのは必然的に小さなグループとなる。それは他の人たちにはそのアイデアのことをまだ話していないのか、あるいは他の人たちを巻き込むにはあまりに不確かに思 えるためだ。グループがある場合でも、同じコードを複数の人がいじることはなく、コードがあまりに早く変わるのでそんなことはそもそも不可能だ。プロジェクトは小さく始まり、それは最初はアイデアが小さいからだ。彼はただちょっと試してみたいハックがあるだけなのだ。
さらに驚くべきは、公式に承認されて行われるプロジェクトがこの8点をすべてまずく行うことがいかに多いかということだ。実際、多くの組織においてソフトウェアが書かれる仕方を見ると、彼らがわざと間違ったやり方をしようとしているのではないかと思えるくらいだ。そしてある意味で、それはその通りなのだ。組織というものを定義付ける資質の一つは、個々人を交換可能なパーツとして扱うということだ。これはもっと並列可能なタスクであればうまくいく。たとえば戦争のような。歴史のほとんどを通じて、よく訓練された職業軍人の軍隊は、勇猛な個々の戦士からなる軍隊を破ってきた。しかしアイデアを温めるというのはあまり並列化することができない。そしてプログラムが何かというと、それはアイデアなのだ。
個々人の才能に依存するという考えを組織が嫌うのは単に事実であるだけでなく、トートロジーと言える。そうしないということが、組織の定義の一部を成しているのだ。少なくとも現在の我々の持つ組織という概念はそうだ。
あるいは個人に交換可能になることを求めずに個人の努力を結集できるような、新しい種類の組織を定義することもできるかもしれない。マーケットはそのような組織形態 なのかもしれないが、マーケットはその堕落した形態だと言った方が正確だろう。組織が可能でないときに、デフォルトで手に入るものがマーケットだ。
たぶん我々にできる最善のことは、ある種のハックをすることだ。たとえば組織の中のプログラミングをする部分には、他の部分と別な働き方をさせるというような。大企業に最適な解法は、インハウスでアイデアを作ろうと は試みさえせずに、単に買い取ることなのかもしれない。しかし解法がどんなものになるにせよ、第一歩は問題があることを認識するということだ。「ソフトウェア会社」という言い方はそもそも矛盾を含んでいる。二つの言葉 は、逆の方向に引っ張っていこうとする。大きな組織にいるいいプログラマは組織と折り合いが悪いもので、それは組織というのがプログラマのやろうとすることを妨げるようにデザインされている ためだ。
いいプログラマはそれでもどうにかして多くのことを成し遂げる。しかしそのためには雇い主である組織に対して実質反逆といえる振舞に出ることがしばしば必要になる。プログラマの行動は 、彼らのする仕事の要求に突き動かされている。そのことを理解しておくのは役に立つ。長時間続けて働き、その間は他の義務をすべて無視する。最初に仕様書を書いたりせずにまっすぐプログラミングに飛び込む。すでにちゃんと動いているコードを書き直す。彼らがそうするのは無責任さのためではない。一人で働きたがるのも、ドアから顔を出して挨拶した人に怒鳴りつけるのも、友好的でないからではない。この一見ランダムな煩わしい習性のコレクションには、ひとつの説明があるのだ。プログラムを頭の中に入れておくことのパワーだ。
このことを理解することが、大きな組織にとって助けになるのかどうかわからない。しかし彼らの競合には間違いなく助けになる。大企業の最大の弱点は、個々のプログラマに偉大な仕事をさせないということだ。だからあなたが小さなスタートアップにいるなら、そこが攻撃すべき場所になる。大きなひとつの頭の中で解く必要がある問題に取り組むことだ。
原稿に目を通してくれたサム・アルトマン、デビッド・グリーンスパン、アーロン・イーバ、ジェシカ・リビングストン、ロバート・モリス、ピーター・ノーヴィグ、リサ・ランドール、エメット・シアー、サーゲイ・ツァレフ、スティーブン・ウルフラムに感謝する。
home rss |