伽藍とバザール #1

　僕自身が開発者として大切にしたい姿勢や思想の多くが、ハッカー文化、オープンソース文化の文脈で既に語られています。例えば、エリック・レイモンドの「伽藍とバザール」では、様々なオープンソースソフトウェアの開発から 19 の味わい深い教訓を導き出しています。

　この note の初めに、私の自己紹介を兼ねて「伽藍とバザール」を読んでいきたいと思います。優れた書評はすでに数多く書かれていると思うので、ここでは自己紹介を含むものとして私的な体験や考察を数多く交えていきたいと思います。

はじめに

　オープンソース・ソフトウェアを読むというのは、ごくシンプルに、楽しいものです。優れた開発者が、現実の問題をどのように定式化・モデル化し、どのように使われることを想定したか、といった設計的な側面。それをどのように解くか、どのような言語仕様を用いて実装するか、という実装的な側面。どちらも、自分には全く思いもよらないような、新しい着想や手法に触れたとき、見ず知らずの開発者と深く分かりあったような心持ちになります。コメントの書き方ひとつとっても、この人は、このクラスを使う人のことを深く考えて、もしくは信頼をして、書いてくれているなぁ、なんて感じると、開発者の誠実さに触れたような、温かい気持ちにもなります。

　公開されたソースコードは、何らかのライセンスの下、世界で共有されたソフトウェア部品です。大げさな言い方をすれば、人類が蓄積している技術知の一端を担うものです。ひとつのソースコードが世界につながっている。あらゆる前提が異なる未来の誰かに、何かひとつでも今の自分が考えたという思考の証が伝わるかもしれない、それって素敵なことじゃない？

　ではさっそく、冒頭で紹介した「伽藍とバザール」の 19 の教訓を読んでいきましょう！

「伽藍とバザール」 19 の教訓

http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ より引用

1.  Every good work of software starts by scratching a developer's personal itch.
すべての良いソフトウェアは、開発者個人のムズムズする気持ちから始まる

この note での外国語の翻訳や人工言語の解釈は、私の主観的な理解に大きく影響を受ける「インチキ超訳」です。原著者の意図を、自分の能力の及ぶ限り尊重するつもりですが、インチキ超訳では原文に書いてないことを行間の虚空から捻り出すことがありますので、ご注意ください😅
　第一の教訓では、「itch」の訳出がちょっとだけそうです。これは単なる「強い希望」とか「切望」とかではなくて、「痒くてムズムズするのをどうにかしたい」ような感じ、「あー、このソフトもっとこうだったらいいのになー、微妙に違うんだよなー、あとちょっとだけココがこう変わるだけでいいのに！」という感覚、わかります。

2.  Good programmers know what to write. Great ones know what to rewrite (and reuse).
普通のプログラマーは、何を書くべきかを知っている。優れたプログラマーは何を書かないで済ませられるかを知っている。

そしてすぐに警句が来ます。ムズムズする気持ちは大事だけど、その気持ちのままいきなり一行目を書き出すんじゃねーぞ！という。後半は直訳すれば「グレートなプログラマーは、何を書き直せばよいか（再利用すればよいか）を知っている」となりますが、再びのインチキ超訳です。確かに、書かないで済ませるというより、既存の優れたコードに基づくべきだと本文でも述べていますね。

While I don't claim to be a great programmer, I try to imitate one. An important trait of the great ones is constructive laziness. They know that you get an A not for effort but for results, and that it's almost always easier to start from a good partial solution than from nothing at all.
私自身はグレートプログラマーであると主張するつもりはないけれど、まずは形だけでもそういうふうに振る舞って近づいて行きたいと思っています。グレートプログラマーの大事な資質は、建設的な怠け癖なんです。つまり、できるだけ努力しないで結果が得られればそれに越したことは無いということで、ゼロから書き始めるより、既存の良いコードをベースにして書いていくことの方がずっと簡単だということです。

「constructive laziness」というのは対立する概念です。直訳すれば「建設的な怠惰」、誰かの優れた実装を基にして書き直していくというというのは自分でウンウン考えてゼロから書き始めるよりも建設的、laziness という言葉に込められた意味の二重性です。laziness が推奨されるのです。成果を出すために。
　この言葉の初出は、ハインラインの SF 小説「Time Enough for Love（愛に時間を）」の中で語られる「The Tale of the Man Who Was Too Lazy to Fail（ものぐさ過ぎて失敗できなかった男の話）」でしょうか。

愛に時間を　１

「アイラ、進歩は、事をおこなうにあたってもっと楽な方法はないかと探しまわるものぐさな人間によって作られるんだ」

「お言葉をうかがっているとどうやらわたしは四半世紀を無駄に費やしてしまったようです」

「たぶんそうだろうな、もしもきみが、朝早く起きて必死で働くなんてことをしていたのならね。だがやりかたを変えるにはまだ遅くないぞ。…（中略）… ものぐさを芸術にした男の物語を聞きたくないか？その男の人生は、”もっとも少ない努力の法則” の好例だ。」

　　　　　　ロバート・A・ハインライン、矢野徹「愛に時間を」より引用

　ものぐさ過ぎて失敗できなかった男、デイヴィッド・ラムの物語が語られます。その内容は、ぜひ原著をご覧いただければと思いますが、デイヴィッドの物語は最後にちょっとした補足がなされます。

この話には続きがある。デイブが自分のことを「有能な専門家」と考えていたとは思わない。だがかれは、自分がついた仕事を全て簡単にした。かれの後継者はつねに、かれの前任者より仕事が少なくなっていたんだ。かれの後継者が仕事を組織しなおして、手間をもう一度三倍に、そして必要な部下の数も三倍に、するのが通常だった…（中略）… 建設的なものぐさの才能をもった人間など、めったにいないものさ。

　　　　　　ロバート・A・ハインライン、矢野徹「愛に時間を」より引用

　愚直なる努力が美徳である、という態度は一歩間違うと、手段と目的を混同し、手段が目的化する恐れがあります。建設的に怠惰でいるとは、言い換えれば、

Be lazy about doing, not lazy about thinking.
(手を動かすことに怠惰たれ、考えることを怠けるな）

ということだと思っています。

3.  Plan to throw one away; you will, anyhow.
最初から、それを廃止するときのことを考えておこう。今はそう思ってはいないだろうけど、遠からず嫌でも廃止することになるから。

　どんな問題も、最初に定式化、実装したときには完全にそれを自分のものにできていないことが多い。二度目はもっとうまくやれるのです。うまくやりたいと思ったら、少なくとも一回はゼロからやり直すことを想定した方が良い。

　これは本当に痛感することが多いです。自分が取り組んでいた問題の真の範囲は（気づかなかったけど）このくらいの広がりだったのだ、ということや、この状態変数を持つことが本質的に設計を簡略化させるのだ、ということや、実体験としても枚挙にいとまがない。二度、三度と同じような問題に取り組んでいると、その問題について今一番考えているのは自分なのではないか、という幻想を持ちますが、いやいや、それは過去にたくさんの人間が通ってきた道、ということも多いですね。

4. If you have the right attitude, interesting problems will find you.
正しい方向に進んでいれば、興味深い問題の方からやってくる。
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
あるプログラムに興味を無くしたら、それを優秀な後継者に引き継ぐことが最後の義務だ。

ペアで語られています。コードを書き捨てるのではなく、書いた人間にはそれを継続させる義務がある、ちゃんとやっていれば、後継者として興味深い問題を解決するチャンスがやってくるのだ、という意図だと理解しています。この文脈とはズレますが、前者の教訓は、私自身は別の意味で捉えているところもあって、それは「ブラックボックスにして進めた箇所には、必ず後から逆襲される。それを理解しなければ前に進めないときが、いつか必ずやってくる。」という意味です。よほどのことが無い限りは、ブラックボックスとして問題を先送りしない方が良いと思っています。それで何度おそるべき手戻りを起こしてしまったことか・・・

6.  Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
利用者を共同開発者として取り扱うことが、迅速な改善と、効率的なデバッグのための一番楽な方法だ。

さて、この教訓は、オープンソース文化の一番素敵なところかもしれません、みんなで寄ってたかって修正、改善し続けるパワーは想像以上にスゴイぜ！
　そしてここでも laziness がキーワードになっています。Linux の開発プロセスの発明こそがもっとも偉大だ、という文脈で

... he has often said: "I'm basically a very lazy person who likes to get credit for things other people actually do.'' Lazy like a fox. Or, as Robert Heinlein famously wrote of one of his characters, too lazy to fail.
リーナスはいつも静かにこう言っていた「僕はとても怠け者で、誰かの仕事を自分の仕事だ称することが好きなだけなんだよ。」キツネみたいな怠け者、言い換えれば、ハインラインがいう「ものぐさすぎて失敗できなかった男」だよ。

　リナス・トーバルズとデイヴィッド・ラムの姿が少し重なって感じられました。

　さて、19 の教訓のうち、まだ 3 分の 1 ですね、ハインラインに脱線してしまったからだ 😅

引用部のライセンス表示
引用部に別の記載の無い引用箇所のライセンスは以下の通りです。

Copyright © 2000 Eric S. Raymond
Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0.
$Date: 2002/08/02 09:02:14 $