伽藍とバザール

『伽藍とバザール』：オープンソース開発のパラダイム

エリック・レイモンドによって執筆された『[伽藍]]とバザール』は、オープンソース[[ソフトウェア]開発の二つの異なるアプローチを比較分析した、影響力のあるエッセイであり書籍です。本書は、ソフトウェア開発のあり方について新たな視点を提供し、オープンソース[[ソフトウェア]]の開発手法に関する議論を大きく前進させました。

伽藍方式とバザール方式

本書では、ソフトウェア開発の二つのモデルとして、「伽藍（Cathedral）」方式と「バザール（Bazaar）」方式が提示されています。

伽藍方式

伽藍方式は、中央集権的な開発モデルを指します。この方式では、少数の開発者が厳密な計画の下で、綿密に設計されたソフトウェアを開発します。開発プロセスはトップダウンで進められ、リリースは計画的かつ慎重に行われます。GNU Emacsの開発スタイルがこの方式の例として挙げられています。

バザール方式

一方、バザール方式は、分散型の開発モデルです。この方式では、多数の開発者がオープンな環境で、それぞれの専門知識やアイデアを持ち寄りながらソフトウェアを開発します。ソースコードは常に公開され、多くの利用者や開発者が開発に携わります。Linuxカーネルの開発スタイルやFetchmailのマネージメント経験が、この方式の好例として挙げられています。バザール方式の大きな特徴は、その柔軟性と迅速な開発速度です。多くの参加者による多様な視点が、バグの早期発見や革新的なアイデアの創出を促進します。

バザール方式の教訓

本書では、バザール方式の開発から得られた19の教訓が提示されており、オープンソース[[ソフトウェア]]開発における重要な原則を理解する上で非常に参考になります。以下にその一部を紹介します。

1. 全ての良いソフトウェアは開発者の個人的な希望から始まる。
- 開発者の個人的な動機が、ソフトウェア開発の原動力となる。
2. 良いプログラマは何を書けば良いか知っている。凄いプログラマは何を書き直せば・何を再利用すれば良いか知っている。
- コードの再利用は、開発の効率化に不可欠である。
3. 破棄する計画を立てる。いずれにせよ、そうすることになる。
- ソフトウェアは常に変化し続けるため、柔軟な姿勢で開発に臨む必要がある。
4. 適切な取り組みをしていれば、おかしな問題は自発的に主張してくる。
- 問題は隠れてしまうのではなく、自ずと表面化する。
5. ソフトウェアに興味がなくなった時には、ソフトウェアを手放して優秀な後継者に引き継ぎする。
- 責任ある引継ぎは、プロジェクトの継続性を保つ上で重要である。
6. 利用者を共同開発者として扱うことは迅速な実装改善と効率的なデバッグの最短ルートである。
- ユーザーからのフィードバックは、ソフトウェアの改善に不可欠である。
7. 素早く頻繁なリリースを実施し、顧客の話を聞く。
- 小さな変更を頻繁にリリースし、ユーザーからのフィードバックを迅速に反映させる。
8. 十分なベータテスターと共同開発者の基盤があれば、大半の問題はすぐに特定されて誰かが直す。
- 多くの人々が関わることで、問題の解決が迅速に進む。
9. 賢いデータ構造と愚かなソースコードは、その逆であるよりずっと良い成果を出す。
- 適切なデータ構造は、ソフトウェアのパフォーマンスを向上させる。
10. あなたがベータテスターを最も有益な資産として扱うなら、彼らは最も有益な資産となり応えてくれる。
- ベータテスターを大切に扱うことで、彼らはより積極的にフィードバックを提供してくれる。
11. 次の最適案は利用者による良いアイディアに気付かされる。後から出たアイディアの方が良いこともある。
- ユーザーのアイデアは、開発に新たな視点をもたらす。
12. 大半の衝撃的で革新的な解決策は自身の問題の捉え方が間違っていることに気付くことから始まる。
- 問題に対する先入観を捨て、新たな視点から見直す。
13. 完璧な設計はそれ以上の追加することがなくなった時ではなく、それ以上の削減することがなくなった時である。
- ソフトウェアの本質を見極め、不要なものを排除する。
14. 全てのツールは想像通りに便利であるべきであるが、本当に凄いツールは作者の想像を越えた便利さを与える。
- ツールの可能性は、開発者の想像力を超えることがある。
15. どんなゲートウェイソフトウェアを実装する場合でも、データストリームへの影響は可能な限り最小限に抑え、受け手が強制しない限りはデータを決して破棄しない。
- データは可能な限り保持し、必要な時に処理する。
16. 自分の書き方がチューリング完全から外れているなら、シンタックス・シュガーは手助けになる。
- コードをより読みやすく、書きやすくする。
17. セキュリティシステムのセキュリティはそれが秘密である時だけ意味を成す。見掛けのセキュリティには注意すること。
- セキュリティは、秘密にされている場合にのみ有効である。
18. おかしな問題を解決することは、おかしな問題を探すことから始まる。
- 問題を解決するためには、まず問題を見つける必要がある。
19. 開発コーディネーターが少なくともインターネットと同等に良質な交流手段を持って圧力をかけない先導手法を知っているなら、必然的に頭数は多い方が良い。
- 多くの開発者が参加できる環境を整備する。

受容と影響

『伽藍とバザール』は、ソフトウェア開発の世界に大きな影響を与えました。ネットスケープコミュニケーションズがNetscape Suiteのソースコードを公開する決断を後押しし、Mozilla Application Suiteの誕生につながりました。また、Wikipediaの創設者であるジミー・ウェールズも本書から影響を受け、「大量の共同作業の可能性を目の当たりにした」と述べています。本書は、オープンソース[[ソフトウェア]]開発の基本的な考え方を広め、その発展を大きく促進しました。

「Cathedral」の日本語訳について

本書における「Cathedral」の訳語は「伽藍」となっていますが、これは建築学的な意味合いを重視したものです。本来、開発におけるヒエラルキーといった宗教的な意味合いを踏まえるならば「大聖堂」と訳すのがより適切です。「伽藍」は仏教寺院の建物群を指す言葉であり、エリック・レイモンドが意図した中央集権的な開発スタイルを表す言葉としては、本来はそぐわないとの指摘もあります。

まとめ

『伽藍とバザール』は、オープンソース[[ソフトウェア]]開発における重要な原則を提示した、必読の書です。本書は、ソフトウェア開発者だけでなく、プロジェクトマネージャーや起業家にとっても、非常に有益な知見を提供しています。オープンな開発コミュニティの可能性を信じ、多くの人々が協力することで、より良いソフトウェアが生まれることを教えてくれます。

もう一度検索