頭の中にプログラムを入れる

Paul Graham / 青木靖 訳
2007年8月

いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。

これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題自体を変えるのだ。

あなたの書くコードは、探索している問題に対するあなたの理解を表している。だから頭の中にコードを保持できたときに初めて、問題を本当に理解したと言えるのだ。

プログラムを頭の中に入れるのは容易なことではない。プロジェクトを何ヶ月か放っておいたなら、戻ったときに再び深い理解を取り戻すのには何日もかかる。そのプログラムに積極的に取り組んでいる場合でさえ、その日その日に取り掛かるとき頭の中にプログラムをロードするのには30分もかかるかもしれない。そしてこれはいい場合での話だ。典型的なオフィスで働く普通のプログラマがこの状態に至ることは決してない。 さらに劇的なことを言うなら、典型的なオフィスで働く普通のプログラマが、自分の解いている問題を本当に理解することは決してない。

最高のプログラマでさえ、取り組んでいるプログラムの全体をいつも頭にロードしているわけではない。しかしそれに近付くためにできることはある。

  1. 気が散ることを避けること。気が散るというのはどんな仕事でも不都合なものだが、プログラミングにおいてはとりわけ不都合であり、プログラマというのは扱いうる限界まで詳細を突き詰めて考えているからだ。

    気が散ることの危険は長さにではなく、それがどれだけ頭の中をかき乱してしまうかに依存している。プログラマは頭の中にコードを保ったまま、オフィスを出てサンドイッチを買いに行くこともできる。しかしまずい類の割り込みであれば、30秒で頭の中にあるものを払拭してしまう。

    奇妙なことだが、スケジュールされた気を散らすものは、不意の気を散らすものよりももっと有害になりうる。1時間後にミーティングがあるとわかっていると、難しい問題に取り組もうという気にもならないだろう。
     
  2. 長時間続けて働く。プログラムに取りかかるときに毎回一定のコストが発生するのだから、短いセッションを何度もやるよりは、回数の少ない長いセッションをする方が効率が良い。もちろん疲れから頭が働かなくなる時点がくる。その長さは人によって違っているようだ。休みなく36時間ハッキングする人たちの話を聞いたことがある。私の場合は一番長くて18時間くらいで、12時間を超えると効率が落ちる。

    肉体的に耐えうる限界までやるのが最適というわけではない。プロジェクトに休みを入れることにはコストと同時に利点もあるのだ。しばらく休んで問題に戻ってみると、無意識が答えを用意してくれていることがときどきある。
     
  3. 簡潔な言語を使う。強力なプログラミング言語はプログラムを短くしてくれる。プログラマは 、少なくとも部分的には、書いている言語によってプログラムを考える。言語が簡潔であるほど、プログラムは短くなり、頭にロードして保持するのがより容易になる。

    強力な言語の効果は、ボトムアッププログラミングと呼ばれるスタイルを使うことで拡張することができる。プログラムを複数の層に分けて書き、下の層が上の層に対するプログラミング言語として機能するようにするのだ。これを適切にやったなら、頭の中に入れるのは一番上の層だけで済む。
     
  4. プログラムを書き直し続ける。プログラムを書き直すことによって、しばしばより明解なデザインが得られる。しかしそういうことがなかったとしても、書き直すことには利点がある。プログラムを書き直すためにはそのプログラムを完全に理解している必要があり、プログラムを頭の中に入れる方法としてこれ以上のものはないのだ。
     
  5. 読めるコードを書く。プログラマは人に読めるようにコードを書くのがいいことだとはわかっている。しかし最も重要な読み手が誰かというと、それは自分自身なのだ。始めの時期においてはとくにそうだ。プロトタイプは自分自身との対話だ。そして自分のために書いているときには優先度も違ったものになる。他の人のために書いている時 であれば、コードをあまり難しくしない方がいいと思うかもしれない。入門書みたいに書き下してやれば、他の人が読みやすくなるかもしれない。一方で自分の頭にロードしやすいようにコードを書こうとするときには、簡潔にするのが一番だ。
     
  6. 小さなグループで作業する。頭の中でプログラムを操作するとき、自分のコードの終わるところで視界が途切れてしまうものだ。他の部分を自分のコードと同じようによく理解することはできない。さらに大きいのは、勝手に書き換えるわけにいかないということだ。だからプログラマの数が少ないほど、プロジェクトはより完全な変異を遂げていくことができる。プログラマが一人の時であれば(プロジェクトの始め はそうであることが多い)、全体をすっかり再デザインすることだってできる。
     
  7. コードの同じ部分を複数の人にいじらせない。他の人の書いたコードを自分のコードと同じくらいよく理解することはできない。どんなに熱心に読んだとしても、それは単に読んだというに過ぎず、書いたわけではないのだ。だからコードのある部分が複数の人によって書かれていたとすると、それは誰によっても一人の人に書かれたコードほど深く理解されることはない。

    そして他の人もいじっているコードは、安全に再デザインすることができない。単に許可をもらう必要があるということではない。再デザインすることなど考えもしないかもしれない。複数の人によって書かれたコードを再デザインするのは、法律を変えるようなものだ。 一方で自分だけのコードを再デザインするのは、曖昧なイメージに別な解釈を与えるようなものだ。

    複数の人でプロジェクトをやろうと思うなら、それをコンポーネントに分けて、それぞれを一人が受け持つようにすることだ。
     
  8. 小さく始める。プログラムは馴染んでいくほど頭の中に入れておくのが簡単になる。すっかり探索したと自信を持てる部分は、ブラックボックスとして扱えるようになる。しかしプロジェクトをやり始めたときには、すべてを見ることを強いられる。大きすぎる問題で始めると、すっかり頭に取り込むことができないかもしれない。だから大きく複雑なプログラムを書く必要があるときに最良の方法は、仕様書を書くことではなく、問題のサブセットを解くプロトタイプを作ることだ。計画にどんな利点があるにせよ、プログラムを頭の中に入れておけることの利点には及ばない 。

プログラマが偶然の事情でこれらの8点をすべて満たしている場合がいかに多いかは驚くものがある。誰かが新しいプロジェクトのアイデアを考えつくが、公式に承認されたものではないため、自分の時間でやることになる——しかしそうすると邪魔が入らない のでより生産的なことに気づく。自分の新しいプロジェクトへの情熱に突き動かされているため、休まずに長い時間続けることになる。最初は単なる実験なので、「製造用」言語ではなく、単なる「スクリプト」言語を使うが、実際にはその方がはるかに強力だ。彼はプログラム全体を何度 も書き直す。公式のプロジェクトであればそんなことはできないかもしれないが、彼は好きでこのプロジェクトをやっているのであり、完璧なものにしたいと思っているのだ。自分以外の誰も見ることはないので、個人的なメモのようなものを除けばコメントも省略している。一緒に働くのは必然的に小さなグループとなる。それは他の人たちにはそのアイデアのことをまだ話していないのか、あるいは他の人たちを巻き込むにはあまりに不確かに思 えるためだ。グループがある場合でも、同じコードを複数の人がいじることはなく、コードがあまりに早く変わるのでそんなことはそもそも不可能だ。プロジェクトは小さく始まり、それは最初はアイデアが小さいからだ。彼はただちょっと試してみたいハックがあるだけなのだ。

さらに驚くべきは、公式に承認されて行われるプロジェクトがこの8点をすべてまずく行うことがいかに多いかということだ。実際、多くの組織においてソフトウェアが書かれる仕方を見ると、彼らがわざと間違ったやり方をしようとしているのではないかと思えるくらいだ。そしてある意味で、それはその通りなのだ。組織というものを定義付ける資質の一つは、個々人を交換可能なパーツとして扱うということだ。これはもっと並列可能なタスクであればうまくいく。たとえば戦争のような。歴史のほとんどを通じて、よく訓練された職業軍人の軍隊は、勇猛な個々の戦士からなる軍隊を破ってきた。しかしアイデアを温めるというのはあまり並列化することができない。そしてプログラムが何かというと、それはアイデアなのだ。

個々人の才能に依存するという考えを組織が嫌うのは単に事実であるだけでなく、トートロジーと言える。そうしないということが、組織の定義の一部を成しているのだ。少なくとも現在の我々の持つ組織という概念はそうだ。

あるいは個人に交換可能になることを求めずに個人の努力を結集できるような、新しい種類の組織を定義することもできるかもしれない。マーケットはそのような組織形態 なのかもしれないが、マーケットはその堕落した形態だと言った方が正確だろう。組織が可能でないときに、デフォルトで手に入るものがマーケットだ。

たぶん我々にできる最善のことは、ある種のハックをすることだ。たとえば組織の中のプログラミングをする部分には、他の部分と別な働き方をさせるというような。大企業に最適な解法は、インハウスでアイデアを作ろうと は試みさえせずに、単に買い取ることなのかもしれない。しかし解法がどんなものになるにせよ、第一歩は問題があることを認識するということだ。「ソフトウェア会社」という言い方はそもそも矛盾を含んでいる。二つの言葉 は、逆の方向に引っ張っていこうとする。大きな組織にいるいいプログラマは組織と折り合いが悪いもので、それは組織というのがプログラマのやろうとすることを妨げるようにデザインされている ためだ。

いいプログラマはそれでもどうにかして多くのことを成し遂げる。しかしそのためには雇い主である組織に対して実質反逆といえる振舞に出ることがしばしば必要になる。プログラマの行動は 、彼らのする仕事の要求に突き動かされている。そのことを理解しておくのは役に立つ。長時間続けて働き、その間は他の義務をすべて無視する。最初に仕様書を書いたりせずにまっすぐプログラミングに飛び込む。すでにちゃんと動いているコードを書き直す。彼らがそうするのは無責任さのためではない。一人で働きたがるのも、ドアから顔を出して挨拶した人に怒鳴りつけるのも、友好的でないからではない。この一見ランダムな煩わしい習性のコレクションには、ひとつの説明があるのだ。プログラムを頭の中に入れておくことのパワーだ。

このことを理解することが、大きな組織にとって助けになるのかどうかわからない。しかし彼らの競合には間違いなく助けになる。大企業の最大の弱点は、個々のプログラマに偉大な仕事をさせないということだ。だからあなたが小さなスタートアップにいるなら、そこが攻撃すべき場所になる。大きなひとつの頭の中で解く必要がある問題に取り組むことだ。

 

原稿に目を通してくれたサム・アルトマン、デビッド・グリーンスパン、アーロン・イーバ、ジェシカ・リビングストン、ロバート・モリス、ピーター・ノーヴィグ、リサ・ランドール、エメット・シアー、サーゲイ・ツァレフ、スティーブン・ウルフラムに感謝する。

 

home  rss  

オリジナル: Holding a Program in One's Head