(これは、オープンソースマガジン2006年6月号の「ハッカー養成塾！」という コーナーに寄稿した記事の、編集前の原稿です。)
川合 史朗
そこそこ、プログラムは書けると思う。 エリック・レイモンド(*eric)の言うとおり言語もいくつか かじってみたし、有名なソフトのソースコードも読んでみた。 でも、もっと良いコードを、ばりばり書けるようになりたいな。
本稿では、ハッカーの世界の入口を通り抜けたそんな人が、 次を目指すにはどうすれば良いかを考えてみたい。
フルタイムのプログラマとして働き出して間もない頃、 ある有名なハッカーと話していて、 少し前に発表された論文の技法はどう思うかを尋ねたことがある。 彼はさらりと答えた。「それね、実装してみたんだけれどこういう パターンだと性能出ないんだよね。」 それを聞いて、なんてカッコいいんだと思ったものだ。
学生の頃、論文を読むのは苦痛だった (書くのは今でも苦痛だが)。 それよりは自分で色々考えてコードを書いている方が楽しかった。 でも、ソフトウェアに関する論文や本は、小説みたいにそれを読んで 楽しむものじゃない(*paper)。むしろ料理やスポーツの 解説書みたいなものだ。そこに書かれていることを自分でやってみて、 初めて役に立つ。学生の頃にそれに気づいていたらなと思う。
論文や本の中にはとても抽象的で、 わけのわからない記号で埋めつくされたものもある(*math)。 だが、それがアルゴリズムについて述べたものであれば、 記号を丁寧に自分の使っているプログラミング言語の言葉に 置き換えてゆくと、動くプログラムができあがるんだ。 それを実際に動かしてみれば、何を言っているのかがよくわかる。
これは論文みたいな「硬い」ものに限らない。誰かがブログで 「こういうアルゴリズムでやってみたらうまくいった」と書いていたら、 自分でもそれを書いて動かしてみればいい。理解のための再実装は、 車輪の再発明とは違う。それはスポーツのトレーニングだとか、 音楽家が楽譜を読んで自分でも演奏してみるのに近い。 それは自分の力になるだけでなく、その行為自体が楽しいものだ。
自分独自のアイディアだって、書いてみることではじめて それをしっかりとらえることができる。コードを書くことで、 ぼんやり考えていた時には見えなかった細部に注意を払うことが できるからだ。
書いてみることは、理解を深めるだけでなく、新しいアイディアを 得るのにも役立つ。大抵、新しいアイディアは、書き終わった コードを動かして「遊んで」いる時にやってくる(*idea)。
「書いて理解する」を実践しようとした時に壁になるのは、 アイディアというのは動作するプログラムの一部でしかないということだ。 新しい3Dアニメーション合成のアイディアを思いついたとして、それを 確かめてみるには、3Dオブジェクトを表現するデータ構造、 データの入出力、結果の表示と加工のUI、など様々な要素が 必要になる。アイディアの実装よりも、そういった周辺部分の道具立てを 揃える方が面倒なことが多い。
動作しているプログラムの中で何が起きているかを知るための道具、 というのはとりわけ重要だ。アルゴリズムは抽象的な存在だ。 それが意図したように動いているかを知るには、 何らかの方法でプログラムの動作を「目に見える」ものにする必要がある。
私の知る優れたプログラマに例外なく備わっているのが、 そのような道具を素早く作る能力である。 以前、私があるゲームのコリジョンルーチン(*coll)の微妙なバグで悩んで、 生産性のお化けみたいな同僚に相談した時のことだ。 彼は自分の席に戻ると、コリジョンの対象となる三角形を フレーム毎にビジュアライズするルーチンをさくっとエンジンに組み込んでしまった。 そのルーチンはその時だけでなく、以降のデバッグでも大いに役立った。
性能のチューニングのためにベンチマークスイートを作成したり、あるいは 自動化テストを書くことさえも、広い意味で道具を作ることに含まれるだろう。 それ自体は楽しいことではない。 スポーツで言えば筋トレ、楽器で言えば音階練習みたいなものだ。 エキサイティングではないが、欠かすことは出来ない。 だがそこに楽しみを見つける方法はあるし、実力がつくに従ってその部分は楽になる(*beauty)。
書くことによって新しいアイディアが生まれる。 しばしば、アイディアの生まれるスピードにプログラムを書くことが追い付かなくなって、 頭のなかに試したいアイディアが積み重なってゆくことがある。これは危険な兆候だ。 アイディアはなまものであり、早く料理しないと傷んでしまうからだ。
リリースする、というのはひとつの解決策である。全てのアイディアを 実装するまで待っていると、頭の中のアイディア倉庫の 暗い片隅で昔のアイディアにカビが生えてるんじゃないかという不安を 常に抱えることになる。知的な便秘だ。
具体的な行為としては、新しいバージョン番号をつけてアナウンスする というのが一般的だが、形にとらわれる必要はない。 リリースとは文字どおり、手放すことだ。 直したい箇所はたくさんあるし、試したいアイディアもたくさんあるけれど、 現状は現状として認めてひとまず手放してみる、ということが要点だ。
手放すことによって、プログラムを客観的に見られるようになる。 ここで頭の中のアイディア倉庫を大掃除しよう。未解決の問題、 溜っていたアイディアを書き出して、 現在のプログラムと突き合わせてみる。重要だと思っていた 欠点が実はそれほど問題ではないことがわかったり、既に別の方法で 解決されていることに気づくかもしれない。昔のアイディアよりもっと うまい方法を思いつくかもしれない。頭の倉庫に風を通して、隅々まで 綺麗にしてから、必要なアイディアだけを運び込もう。
ハッキングには波がある。ある一ヶ月で自分でも信じられないような量の コードを書ける時もあれば、しばらくの間、生産性がガタ落ちすることもある。
ある日突然、コードが書けなくなることがある(*block)。 何をどう書くか、大まかな手順はわかっているのに、 いざエディタに向かうとどうしてもコードに集中できない。 ついemailを書いたりwebを見たり。コーヒーを飲みに行って、 同僚とちょっとダベって、そのうちなんとなく 書けそうな気がして席に戻るが、PCに向かうと それは湯気のように消えうせてしまう。
悪い場合は数週間から数ヶ月もそれが続く時がある。 プログラミングを職業にもしている場合、問題は深刻だ。 コーディングには機械的に出来る部分があるので、 気力で脳を絞れば、糞のようなコードだと思いつつも、 何かを書いてゆくことは出来る。 だがそうすればするほど、ますますエディタに向かうことが苦痛になってくる。
残念ながら、これに関する特効薬は知らない。 誰でもそういう時があること、 そして自分が今書けない状態なのだと認めることで、少しは楽になるかもしれない。 もちろん、しばらくPCの前から離れてリフレッシュできるならそれに 越したことはない。それが無理なら、コーディング以外の作業に回るのも手だ。 ドキュメント書きはお薦めである。コーディングとは違う部分の脳を使うし、 プログラムを客観的に眺めることができる。コーディングに追われている同僚は ドキュメントを後回しにしがちなので、手伝えば感謝もされる。 テストフレームワークを整えてもいい。美術的センスがあるなら、 プログラムのアイコンのデザインやプロジェクトのWebサイトデザインなども、 脳のバランスを取るのにいいかもしれない(*block2)。
あるいは、邪魔されない、静かに集中できる環境を作って、 自分の心と向かい合ってみよう。 解くべき問題の本質を理解していないのか。 自分の解きたい問題は別にあるのか。 実力が足りないのか。必要以上に「綺麗に」解こうとしてはいないか。 プライドや恐れが邪魔をしているのではないか。
もちろんそれで全てが解決するほど簡単じゃないけれど、少しづつでも 前に進めば、違う景色が見えるかもしれない。
他のクリエイティブな道と同様、ハッカーの道もひとつではないし、 ゴールもない。だがどの道を取っても、きつい登りの後には素晴らしい 眺望が待っている。それがハッカー道の醍醐味でもある。
次回は、本稿に書いた「アイディアを書いて試してみる」を実践しているサイト、 「できるかな?」(*hirax)を主宰する平林純さんにバトンを渡します。
(*eric) エリック・レイモンド「ハッカーになろう」 http://cruel.org/freeware/hacker.html
(*paper) 読みものとしても楽しい論文、というのもあるにはある。
(*math) 計算機科学の論文にギリシャ文字と数式が溢れる理由について、 ポール・グレアムは「数学への羨望」を指摘している。 「ハッカーと画家」p.27。
(*idea) 書くことが苦手な人ほど、アイディアにこだわる傾向があるかも しれない。新しいアイディアを生み出すペースが遅いと、 たまに思いついたアイディアが貴重なものに思えてしまうんだ。 実際には、本当に重要なアイディアというのは実装が済んだ後に 振り返ってそうだと気づくことが多い。
(*coll) 物体と物体の衝突を検出するプログラム。素直に書くと 大変時間のかかる処理なので、様々な最適化アルゴリズムがある。 最適化をがりがりかけてゆくと、 「ごく稀な条件が重なった場合におかしくなる」というバグが 入りやすい。
(*beauty) こういった道具をプログラムに組み込むことは、しばしば プログラムの美観を損ねることがある。コリジョンルーチンの例では、 彼の最初のハックはモジュールをまたがって情報を受け渡すのにグローバル変数を 利用していた。「ただ動く」プログラムではなく、美しいプログラムを書きたいと 思い始めた頃のプログラマは、せっかく綺麗に作られたモジュール構造を 壊すことを恐れて、大胆な変更に手が出せないことがある。 力のあるプログラマはコードを捨て去ることに抵抗がない。まず汚くても 動かしてみて、ダメなら元に戻せばいいし、うまくいってその機能を 将来も使いたくなったらその時に設計を考え直せばいいと思っている。
(*block) 作家が文章を書けなくなるwriter's blockになぞらえて、 私はprogrammer's blockと呼んでいる。
(*block2) チームで作業している場合は自分が不調であることをちゃんと 言っておこう。でないと軋轢が生じるからね。
(*hirax) http://www.hirax.net/
このコーナーはバトン記事なんですが、他の方の回もネットで読めるものがあります。 他にも見つけたら足して下さい。