伽藍とバザール

『**伽藍とバザール**』（がらんとバザール、、カテドラルとバザール）は、エリック・レイモンドによって書かれたオープンソースソフトウェア（OSS）のソフトウェア開発方式に関するエッセイおよび書籍である。

当記事では、Cathedralの訳語に伽藍、Bazaarの訳語にバザールを使用する。訳語については、「Cathedral」の日本語訳の節を参照。

伽藍方式としてGNU Emacsの開発スタイル、バザール方式としてLinuxカーネルの開発スタイルとFetchmailのマネジメント経験を挙げている。また、ソースコードを常時公開して多くの利用者・開発者がソフトウェア開発に携わる開発手法のメリットを主張している。

## 歴史
1997年5月27日、ドイツのヴュルツブルクで開催されたLinux Kongressで講演の形で発表された。その後、1999年に書籍として出版された。原作書籍の表紙に描かれているイラストは、トレチャコフ美術館所蔵のリュボーフィ・ポポーワによる1913年の絵画『*Composition with Figures*』である。エッセイは2000年前後以降よりOpen Publication License 2.0の下で公開されている。日本語翻訳版は山形浩生が1999年に執筆し、オープンコンテント相当の制約で公開されている。

本書はオープンソース部作となる『伽藍とバザール』『』『』および2011年現在未発表の『』のうち、ソフトウェア関係者向けに書かれた最初のひとつである。

## 伽藍とバザール

伽藍方式は、ソフトウェアの開発は閉鎖的な開発チームにより制限する。事例としてGNUプロジェクトのGNU Emacsを挙げている。GNU Emacsは巨大で強力なテキストエディタであり、GNUプロジェクトの開発チームがソフトウェアを実装し、ソースコードがインターネットを通して公開されていた（またGPLなので、不特定多数の利用者・開発者によるEmacsの設計・実装も、フォークして行うのはライセンス上はそれを妨げるものはない（実際にXEmacsが派生している）。現代風に言うなら、プルリクエストの取り込みに消極的だった、というのが「閉鎖的な制限」である）。

バザール方式は、ソースコードがインターネットを通して公開されている点はEmacsと同じだが、実装もまた公開的に行われ、不特定多数の利用者・開発者によりソフトウェアの設計・実装を進める。バザール方式の事例としてLinuxカーネルとFetchmailを挙げている。エリック・レイモンドはLinuxカーネルのプロジェクトリーダーであるリーナス・トーバルズをバザール方式の先駆者として称賛している。また、自身のバザール方式の開発体験としてFetchmailプロジェクトに携わり、本書でその経験を述べている。

エッセイの主題はバザール方式におけるエリック・レイモンドが提起したリーナスの法則「十分な目玉があれば、全てのバグは洗い出される」である。バザール方式ではソースコードがより広く利用可能にすることで公開された試験・精査・検証となり、より迅速に全ての形状のバグを見つけることに繋がる。対称的に、伽藍方式ではバグを退治することに莫大な時間と労力を費やさなければならず、それ故に開発中のバージョンのソースコードは少数名の開発者しか利用することが出来ない。

C言語のコンパイラであるGCCとEGCSは伽藍方式とバザール方式の良い対比プロジェクトである。GNUプロジェクトのGCCは伽藍方式で開発が進められていたが開発速度と品質は著しくなく、有志のGCCからフォークしたEGCSはバザール方式で開発が進められておりGCCを上回り高機能・高品質であった。1999年にGCCの開発主管は伽藍方式の旧チームを解散してバザール方式のEGCSチームに移った。

一方で、バザール方式により、即効性のある成功が収められるものと楽観するのは間違いであろう。伽藍とバザールの最後にあるNetscapeの1998年のオープンソース化は、2004年に「バージョン1がリリースされ、それから9か月間で6000万回ダウンロードされるという成功をおさめ」（Mozilla Firefoxの記事より引用）るまでに、主要な開発者ジェイミー・ザウィンスキーの離脱と、6年という（業界の時間感覚としてはかなり長い）困難の時を経ている。

## バザール方式の教訓
さまざまなソフトウェア開発の取り組みから学んだバザール方式の19の教訓を挙げ、それぞれがオープンソースソフトウェア開発における優れた開発手法に関する題目を述べている。

# 全ての良いソフトウェアは開発者の個人的な希望から始まる。
# 良いプログラマは何を書けば良いか知っている。凄いプログラマは何を書き直せば・何を再利用すれば良いか知っている。
# 破棄する計画を立てる。いずれにせよ、そうすることになる。
# 適切な取り組みをしていれば、おかしな問題は自発的に主張してくる。
# ソフトウェアに興味がなくなった時には、ソフトウェアを手放して優秀な後継者に引き継ぎする。
# 利用者を共同開発者として扱うことは迅速な実装改善と効率的なデバッグの最短ルートである。
# を実施し、顧客の話を聞く。
# 十分なベータテスターと共同開発者の基盤があれば、大半の問題はすぐに特定されて誰かが直す。
# 賢いデータ構造と愚かなソースコードは、その逆であるよりずっと良い成果を出す。
# あなたがベータテスターを最も有益な資産として扱うなら、彼らは最も有益な資産となり応えてくれる。
# 次の最適案は利用者による良いアイディアに気付かされる。後から出たアイディアの方が良いこともある。
# 大半の衝撃的で革新的な解決策は自身の問題の捉え方が間違っていることに気付くことから始まる。
# 完璧な設計はそれ以上の追加することがなくなった時ではなく、それ以上の削減することがなくなった時である。
# 全てのツールは想像通りに便利であるべきであるが、本当に凄いツールは作者の想像を越えた便利さを与える。
# どんなゲートウェイソフトウェアを実装する場合でも、データストリームへの影響は可能な限り最小限に抑え、受け手が強制しない限りはデータを決して破棄しない。
# 自分の書き方がチューリング完全から外れているなら、シンタックス・シュガーは手助けになる。
# セキュリティシステムのセキュリティはそれが秘密である時だけ意味を成す。見掛けのセキュリティには注意すること。
# おかしな問題を解決することは、おかしな問題を探すことから始まる。
# 開発コーディネーターが少なくともインターネットと同等に良質な交流手段を持って圧力をかけない先導手法を知っているなら、必然的に頭数は多い方が良い。

## 受容と影響
1998年、ネットスケープコミュニケーションズがNetscape Suiteのソースコードを公開することを後押しをして、Netscape SuiteがMozilla Application Suiteとして生まれ変わることとなった。このネットスケープコミュニケーションズのアクションはエリック・レイモンドをハッカー分野で著名にさせるに十分な出来事だった（そもそもエリック・レイモンドはジャーゴンファイルの編集（1990年以降）などで、もともとハッカー分野ではそれ以上著名になることはないくらいに著名な人物であり、正確にはハッカー以外に著名になった）。

1999年、Oreilly Mediaが初版を出版したものは、Open Publication Licenseでライセンスされ公開している著書が初めて商用書籍として販売された事例となった。

はエッセイ『*The Hive*』で、Wikipediaはバザール方式に似ていると述べた。ジミー・ウェールズ自身、バザール方式に触発されており、「大量の共同作業の可能性を目の当たりにした」と述べている。

1999年、はエリック・レイモンドのオープンソースソフトウェアに関する2件の批判的エッセイを掲載し、2つ目のエッセイは『*A second look at The Cathedral and the Bazaar*』として知られている。それらはエリック・レイモンドにより反論が提示されている。

## 「Cathedral」の日本語訳
「Cathedral」は「伽藍」と訳されているが、建築学の訳語としてはともかく、開発におけるヒエラルキーといったことも踏まえた宗教的意味あいを表現する言葉としては「大聖堂」（より細かくはカトリックの司教座が置かれた司教座聖堂）に当たる。「伽藍」は仏教寺院の建物**群**を指す言葉で、エリック・レイモンドが意図した中央集権スタイルを意味する言葉としては、本来はそぐわない。これは建築家ル・コルビュジエの著作『*When the Cathedral was White*』が『伽藍が白かったとき』と訳されており、これを踏まえて山形浩生が訳したものである。建築学において伽藍をCathedralと訳すことは一般的である。

## 脚注

### 注釈

### 出典

## 外部リンク

* The Cathedral and the Bazaar - Eric S. Raymond - 原文
*  - 山形浩生 日本語訳