読書めも『伽藍とバザール』
概要
このエッセイでは、fetchmailというオープンソースプロジェクトを立ち上げたレイモンドは、Linuxの成功から得た知見でソフトウェアエンジニアリングに関する分析します。
彼は、商用ソフトウエアの開発に見られる「伽藍（大聖堂）」モデルと、Linuxの開発で行われた「バザール」モデルという、根本的に異なる2つの開発スタイルについて論じています。
大聖堂 vs バザール
伽藍モデル: 少数の優秀な開発者によって綿密に計画され、閉鎖的な環境で開発が進められます。リリースは慎重に行われ、頻度は低くなります。
バザールモデル: オープンな環境で、多くの開発者が協力して開発を進めます。リリースは頻繁に行われ、ユーザーからのフィードバックを積極的に取り入れます。
ライナスの法則
Linuxの成功の鍵は、リーナス・トーバルズが採用した「早期かつ頻繁なリリース」と「ユーザーを共同開発者として扱う」というアプローチにあると主張します。これは、「十分な数の目があれば、すべてのバグは浅い」という「ライナスの法則」に基づいています。
バザールモデルでは、多くの開発者が新しいリリースを試用することで、バグはすぐに発見され修正されると考えられています。
フェッチメールの教訓
レイモンドは、自身のフェッチメールプロジェクトを通じてバザールモデルをテストし、その有効性を確認しました。彼は、このプロジェクトから得られた教訓を以下のようにまとめています。
良いソフトウェアは、開発者自身の個人的なニーズを解決することから始まる。
優れたプログラマーは、何を書くべきかを知っている。偉大なプログラマーは、何 を書き直すべきか（そして再利用すべきか）を知っている。
ユーザーを共同開発者として扱うことは、迅速なコードの改善と効果的なデバッグへの最短ルートである。
早期にリリースし、頻繁にリリースし、顧客の声に耳を傾ける。
優れたアイデアを持つことと同じくらい重要なのは、ユーザーからの優れたアイデアを見抜くことである。
言語がチューリング完全からは程遠い場合、糖衣構文はあなたの味方になることができる。
設計における完璧さは、もう何も付け加えるものがないときではなく、もう何も取り去るものがないときに達成される。
オープンソースソフトウェアの社会的文脈
レイモンドは、オープンソースソフトウェアの成功は、ハッカー文化の社会的文脈と密接に関係していると主張します。ハッカーは、他のハッカーからのより多くの評価をえるために、自己中心的にふるまいます。
オープンソースプロジェクトは、この自己中心的な行動を、持続的な協力によってのみ達成できる困難な目標に結びつける効率的な市場を作り出します。
マネジメントとマジノ線
従来のソフトウェア開発では、マネージャーは資源の配分、人材の管理、進捗の監視など、様々な役割を担っています。しかし、オープンソース開発では、これらの役割の多くはボランティアによって自律的に行われます。
レイモンドは、従来型の管理手法は、オープンソース開発の文脈では必ずしも有効ではなく、むしろ開発の妨げになる可能性があると指摘しています。
ネットスケープはバザールを受け入れる
エッセイの最後に、レイモンドは、ネットスケープがNetscape Navigatorのソースコードを公開した事例を取り上げ、商用ソフトウェア開発におけるバザールモデルの可能性について考察しています。
彼は、ネットスケープの試みは、オープンソースの概念を商用世界に広める大きなチャンスであると同時に、失敗すればオープンソースに対する信頼を失墜させる危険性もあると指摘しています。
そして、試みは失敗し、信頼を大きく失墜させてしまいました。しかし、そこからまた新たな試みが生まれています。
オープンソースソフトウェア作成の教訓
レイモンドは、このエッセイを通じて、優れたオープンソースソフトウェアを作成するための教訓をいくつか提示しています。
個人的なニーズを解決する: 良いソフトウェアは、開発者自身の個人的な問題を解決することから始まる。
再利用と書き直し: 優れたプログラマーは既存のコードを再利用し、必要があれば書き直すことを恐れない。多くの場合、最も革新的な解決策は、問題に対する自分のコンセプトが間違っていたことに気づくことから生まれる。それはしばしば、正しい答えを持っているかどうかではなく、正しい質問をしているかどうかを問う時である。
早期かつ頻繁なリリース: ユーザーからのフィードバックを得るために、早期に、そして頻繁にリリースすることが重要である。
ユーザーを共同開発者として扱う: ユーザーからのバグ報告やパッチは貴重な資源である。よいアイデアを持つことの次に良いことは、ユーザーの良いアイデアを認めることです。
シンプルで明確な設計: コードは理解しやすく、保守しやすいものでなければならない。間抜けなデータ構造だと、どれだけスマートなコードを書いても理解しにくい。
柔軟性と拡張性: 将来の変更や拡張に対応できる設計が重要である。
これらの教訓は、オープンソースソフトウェア開発だけでなく、あらゆるソフトウェア開発プロジェクトにおいても役立つものです。
ブルックの法則
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
Raymond 氏は、早期リリースと頻繁なリリース、そして ユーザーの声に耳を傾ける という Linus Torvalds 氏の手法を採用しました。これらの手法により、多くのユーザーからバグ報告や機能要望が集まり、fetchmail の品質向上と開発速度の向上に繋がりました。
Raymond 氏は、fetchmail の前身である popclient のデータ構造を大幅に書き直しました。これにより、コードがシンプルになり、保守性や拡張性が向上しました。
「Linus の法則」は、多くの開発者がバグを探すことで、バグの発見と修正が迅速に行われる ということを意味します。オープンソースソフトウェア開発では、ソースコードが公開されているため、誰でもバグを探すことができ、問題解決に貢献できます。
Raymond 氏は、fetchmail の開発において、ユーザーからのバグ報告や機能提案を積極的に受け入れ、開発に反映 しました。また、ユーザーに感謝の意を表し、コミュニティへの参加を促しました。
Raymond 氏は、「完璧さ」とは 付け加えるものが何もない状態ではなく、取り去るものが何もない状態 であると定義しています。これは、ソフトウェアはシンプルで無駄がなく、必要な機能のみを備えているべきだということを意味します。
Raymond 氏は、ユーザーを協力開発者として扱う ことが重要だと述べています。ユーザーからのフィードバックを積極的に受け入れることで、ソフトウェアの品質向上と開発速度の向上に繋がります。
Raymond 氏は、fetchmail の開発において、貢献者たちの名前を文書に掲載し、彼らの功績を称える ことで、彼らの「エゴ」を満たしました。また、ユーザーからのバグ報告や機能提案に感謝の意を表し、コミュニティへの参加を促しました。
「ギフト経済」とは、金銭的な報酬ではなく、貢献すること自体に喜びを見出し、互いに助け合い、貢献し合う 経済システムです。オープンソースコミュニティでは、開発者たちは自分の時間と才能を「ギフト」として提供し、ソフトウェアの開発に貢献しています。
Raymond 氏は、オープンソースソフトウェア開発は、多くの開発者が参加できるため、バグの発見と修正が迅速に行われ、品質が向上 すると主張しています。また、開発コストが低く抑えられるため、より多くの機能を開発できると述べています。
Raymond 氏は、Netscape のブラウザをオープンソース化したことは、商業ソフトウェア開発におけるバザールモデルの可能性を示す重要な実験 であると評価しています。しかし、オープンソース化だけでは成功は保証されず、コミュニティの育成や開発体制の整備が重要であると指摘しています。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？