ある日、同僚が椅子に座りながらうとうとしていた。その後しばらくしてから、さっき昼寝していたでしょう、と指摘したところ「違いますよ。一人ブレストをしていただけですよ！」と反論された。
画面に向かって一人でコードをいじるというのは孤独な作業だ。コードの変更を最小限に押さえつつ、既存の機能は壊さずに、新しい機能をひとつ入れるにはどうしたらいいか？ここの部分をいじったら他に影響はでないか？そんなことを考えながら、おそるおそるキーボードを叩く。
大体の方針が見えてくると、キーボードを叩く速度は上がる。今頭の中にあるアイディアが頭から出てかないうちに、一気にやってしまいたい。一発でうまくいことはないだろう、でも近いところまでは行けるかもしれない。やってみなければわからないのだ。やってみると、やはりどこか動かない、が、致命傷ではない。少しの変更でどうにかなるだろう。diff をチェックすると、今回の変更はまずまず、コンパクトにまとまっている。とりあえず、現状のものをローカルにコミットしておこう。これでよし、一息ついたら、仕上げにかかるとしよう。
仕上げの作業が好きだ。もう大体動いているのだから、難しい部分は終わっている。あとはコードから無駄な部分をそぎ落としたり、関数名を吟味したり、といった作業が残っているだけだ。わかりにくい部分にはコメントもつけてあげよう。コードを整理していく作業は楽しい。
が、ここに罠があある。ああでもこうでもないとやっていると、やたら時間を食ってしまうのだ。ここの変数名は foo_size がいいだろうか、foo_length がいいだろうか、なんてことをつい考えてしまう。まあどっちだっていいのだが、どうせなら周りのコードに合わせて一貫性を持たせたい、が、周りのコードを読むと size と length が両方使われている。一貫性なんかないじゃないか！countってのまであるし。じゃあ周りも直すのか？いや、そんな余計な変更は別のパッチに分けたほうがいいだろう、しかし気になるぞこれ。。
気づくと、頭の中で、一人で自転車小屋の議論をやっていたりする。そんなところで、もたもたせず、もっと早く先に進むべきなのだが。
鵜飼文敏さんが書いた記事 [1] によると、素早く問題を解決することが大切だという。ふーん、そんなの当たり前なのでは、と最初に読んだときは思ったような気がするが、今読み直すと、鵜飼さんの言わんとしていたことがもう少しわかるようになった気がする。一人自転車小屋で費やした時間を他のことに当てていれば、もっと多くの問題を解決できていたような気がしなくもない。
[1] http://ukai.jp/Articles/2006/osm-hacker/