83/ 伽藍とバザール

エリック・レイモンド氏がOSSとLinuxの革新性について書いた本

Linuxの衝撃

Linux は、ぼくがわかっているつもりでいたものを、大幅にひっくりかえしてくれた。それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといった Unix の福音は説き続けてはいた。でももっと上のレベルでは何かどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。一番だいじなソフト（ OS や、 Emacs みたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメで、一人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげるべきもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。

だからリーヌス・トーヴァルズの開発スタイル――はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――にはまったく驚かされた。静かで荘厳な伽藍づくりなんかない―― Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった（これをまさに象徴しているのが Linux のアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう）。そしてそこから一貫した安定なシステムが出てくるなんて、奇跡がいくつも続かなければ不可能に思えた。

良いソフトは、開発者の個人的な課題解決から始まる

教訓その1: よいソフトはすべて、開発者の個人的な悩み解決から始まる。

これは自明のことかもしれない（昔から「必要は発明の母」って言うし）。でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし好きでもないようなソフトを一日中シコシコ書いてることがあまりに多いんだ。でも、 Linux の世界ではちがう―― Linux 界出身ソフトの質が、平均してすごく高いのはこのせいかもしれないね。

「何を使い回せば良いのか」を分かっていることが重要

「何を書けば良いのか」を分かっているのがGood Programmer

「何を使い回せば良いのか」を分かっているのがGreat Programmer

すごいプログラマの大事な特徴の一つが、建設的な面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、そのための努力じゃないってのがわかってるってこと。そして白紙から始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。たとえばリーヌス・トーヴァルズ（ http://www.catb.org/~esr/faqs/linus）は、 Linux をゼロから書き始めたわけじゃない。 386 マシン用の、小さな UNIX っぽい OS だった Minix のコードやアイデアを再利用するところから始めてる。

捨てることをあらかじめ予定しておけ

捨てることをあらかじめ予定しておけどうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第 11 章

あるいは言い換えると、1 回とりあえず解決策を実装してみるまでは、問題を完全には理解しきれないってこと。2 回目くらいになってやっと、正しい解決法がわかるくらいの理解が得られるかもしれない。だからちゃんとした問題解決をしたいなら、少なくとも 1 回くらいはやりなおす覚悟はしておくこと。

ユーザーを共同開発者にする

ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。この効果の力はすごく見落としがち。はっきり言って、ぼくらフリーソフト界のほとんどだれもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そしてそれがシステムの複雑さに対してどれほど有効に機能するかについて、まったく見えてなかった。リーヌスが目を開いてくれるまでは。

はっきり言って、ぼくはリーヌスのいちばん賢い、影響力あるハッキングというのは、 Linux のカーネル構築そのものではないと思う。むしろ Linux 開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。

ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。

はやめのリリース、しょっちゅうリリース

はやめにしょっちゅうリリースするのは、 Linux 開発モデルの重要な部分だ。ほとんどの開発者（含ぼく）は、プロジェクトがちょっとでも大きくなったらこいつはまずいやり方だと考えていた。初期バージョンはその定義からいってバグだらけだし、ユーザの我慢にも限度があるだろうから。この信念のおかげで、伽藍建設式の開発への関与も深まった。もし最優先課題が、できるだけ少ないバグしかユーザにお目にかけないということだったら、うん、それならリリースは半年に一度とかにして（あるいはもっと間をおいて）、リリースの間は犬みたいにひたすらバグ取りに専念するだろう。

Linux がかなり目に見えて広まってくると、なにかちがった、ずっと健全なことが起こっているのははっきりしてきた。リーヌスのオープンな開発方針は、伽藍建設の正反対のものだった。 Sunsite （現 metalab）や tsx-11 のアーカイブははちきれそうで、パッケージもどんどん登場してきた。そしてそのすべてが、前代未聞の頻度でリリースされるコアシステムに動かされていた。

はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと

リーヌスの革新は、これをやったということじゃない、それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。

開発初期のあの頃だと、リーヌスが新しいカーネルを一日に何回もリリースすることだって、そんなに珍しくはなかった。そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく共同作業をする点で、ほかのだれよりも上をいっていた。

リーヌスは、ハッカー/ ユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。

リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザ基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。

リーヌスの行動を見ていると、次のような信念を持っていたんじゃないかと思える： •8. ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。

あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。

伽藍とバザールの根本的な違い

ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。

伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、潜伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。

一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを一つ残らず、千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。よって、たくさんなおしてもらうためにリリースも増やすし、有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。

壁にぶち当たったら、正しい問題を問いているかを考えろ

自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。

開発で壁にぶちあたったとき――次のパッチ以降何をしたらいいか、すごく悩んでしまうとき――というのは、自分が最終的な回答にたどりついたのかな、と考えるべきときではなく、むしろ自分が正しい質問をしているのかな、と考え直してみるべきときであることが多い。ひょっとして、問題をとらえなおしてみる必要があるのかもしれない。

完成とは「付け加えるもの」がなくなった時ではなく、「取り去るもの」がなくなった時である

古びてきた機能は迷わず捨てること――有効性を下げずに捨てられる場合には。アントワーヌ・サンテグジュペリ（かれは児童書の古典を書いていないときには、飛行家で航空機設計家だった）曰く： •13.「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。

コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に自分が正しいのがわかる。

プログラマの時間は代替不可能

『人月の神話』でフレッド・ブルックスはプログラマの時間が代替不能だと看破している。遅れているソフト開発に開発者を加えても、開発はかえって遅れる。プロジェクトの複雑さとコミュニケーションコストは、開発者数の 2 乗で増大するのに対し、終わる作業は直線的にしか増加しないというのがかれの議論だった。この論はそれ以来「ブルックスの法則」と呼ばれるに至り、真実をついているものとだれもが考えている。でもブルックスの法則が唯一無二の真理なら、 Linux はあり得なかっただろう。

OSSが成功した理由は「トップ5%しか受け入れない」から

ぼくの友だちは、オープンソース界と巨大閉鎖プロジェクトとの両方を知っていて、オープンソースが成功した理由の一部は、その文化がプログラミング人口のトップ 5% しか受け入れないからだ、と信じている。彼女は、残り 95% の動員を組織するのに時間を費やしている。そして、最高のプログラマと、単に有能なだけのプログラマとの 100 倍もの生産性のちがいというのを、直接見せつけられているのだ。

この生産性の差は、居心地の悪い質問をずっと投げかけ続けてきた。ということはだよ、ソフトの個別プロジェクトや、ソフト産業全体として見ても、使えない下半分を切り捨てたほうがずっとよくなるんじゃないだろうか。もし伝統的なソフト管理の唯一の機能が、一番使えないやつらを、せめて損害は出さずにトントンに持っていくくらいだとしたら、そんな仕事は何の価値もないんじゃないかということを、有能なマネージャたちは昔から理解していた。

丁度良いハードルが生産性を上げる

人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばん嬉しい。簡単すぎて退屈でもいけないし、達成不可能なほどむずかしくてもダメだ。シヤワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。楽しみが能率をあげる。

オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。