『伽藍とバザール（The Cathedral and the Bazaar）』
著者：Eric Steven Raymond
翻訳：山形浩生 （日本語訳は→こちら）
発表日：1999年7月30日
【要約】
Linuxのカーネル開発は、従来のプログラム開発の常識を覆すような手法で進められました。従来のプログラム開発の常識が「伽藍方式」で、それを覆した新しい手法が「バザール方式」です。著者のエリック・レイモンドは、Linuxのカーネル開発の成功を目の当たりにした後、Fetchmail の開発において自らもバザール方式を試してみました。本書はこれらの経験から得られた複数の人間の協働（プログラム開発に限らず）に関する新しい考察です。
- 当初筆者は、一番だいじなソフト（OS やEmacs みたいな本当に大規模なツール）は、集権的でアプリオリなアプローチで伽藍のように組み立てなければダメであり、完成するまではベータ版も出さないようにしなければダメだと考えていたが、Linuxの開発スタイルはそれをひっくり返した。
- リーヌス・トーヴァルズの開発スタイルは（１）はやめにしょっちゅうリリース、（２）任せられるものはなんでも任す、（３）なんでもオープンにするであり、それはまるで、いろんな作業やアプローチが渦を巻くでかい騒がしいバザールに似ている。そのような騒がしい場所から一貫した安定したシステムが生み出されてきたのである。
- 「必要は発明の母」という言葉があるように、よいソフトはすべて開発者の個人的な悩み解決から始まる。Linuxの場合がまさにそうであった。しかし、従来の「伽藍方式」におけるソフト開発者は、お金で横っ面をはられて自分では要りもしない好きでもないソフトを一日中シコシコ書いていることが多い。
- ユーザは共同開発者になってくれる大事な財産である。ソースコードが公開されているから、ユーザが問題を診断し直し方を提案してくれ、一人でやるよりずっとはやくコードを改善できる。その効果はユーザが増えるほど顕著になる。
- Linux以前の開発者は、初期バージョンはバグだらけで、それを使わされるユーザにも我慢の限界があり、そんなものはとうていリリースできないと考えていた。その場合、リリースは半年に一度（あるいはもっと間をおいて）になり、開発者はリリースの間はひたすらバグ取りに専念することになる。
- 上記とは対照的に、「はやめにしょっちゅうリリース、そして顧客の話を聞くこと」がLinux開発モデルの最も重要な部分である。ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかる。もっとくだけた表現をすれば「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これが「リーヌスの法則」である。
- リーヌスは、ハッカーやユーザたちをたえず刺激してごほうびを与え続けた。刺激は全体の動きの中で一員となることでエゴを満足させられるということ、ごほうびは自分たちの仕事がたえず（まさに毎日のように）進歩している様子である。
- バーザール方式のコミュニティ形成を始めるときには、まずなによりも実現できそうな見込みを示す必要がある。そのソフトは特によく書けてなくてもいい。雑で、バグだらけで、不完全で、ドキュメント皆無でもいい。でも絶対不可欠なことは、開発者候補たちに、それが目に見える将来にはなにか本当に使える代物に発展させられると説得できることである。
- オープンソース開発者たちはボランティアであり、自分のかかわるプロジェクトに興味を持ち、自薦により貢献することなった人たちであり、自主的に自分のリソースを提供してくれる。そして伝統的な意味で、マネージャが制御する必要性は、ほとんど、いやまったくない。
- 楽しみが効率をあげる。「ぼくたちは、楽しんでやっているんだもの。」ぼくたちの創造的な遊びは、技術面でも、市場シェア面でも、精神的なシェアでも、すさまじい勢いで成功を重ねてきている。ぼくたちは、もっといいソフトがつくれることを示しただ けじゃない。よろこびが資産であることを証明してもいるんだ。オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。
【著者が得た教訓】（訳文のまま）
- よいソフトはすべて、開発者の個人的な悩み解決から始まる。
- 何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。
- 捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレッド・ブルックス『人月の神話』第11章）
- まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
- あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。
- ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。
- はやめのリリース、ひんぱんなリリース。そして顧客の話をきくこと
- ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
- 賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
- ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。
- いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。
- 自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。
- 「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。
- ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。
- ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！
- 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。
- セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。
- おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
- 開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は一つよりは多いほうが絶対にいい。
【要約者による注釈（念のために）】
本文で使われている「ハッカー」は、「コンピュータや電気回路一般について常人より深い技術的知識を持ち、その知識を利用して技術的な課題をクリアする人々」のことで、これが本来の意味です。「情報の破壊や不当な複製、アクセス制御の突破など、不正な利用を行う者」に対しては「クラッカー」という言葉を使うのが妥当です。
コメント