オープンソースにおける開発方法

伽藍（がらん）方式とバザール方式

ここまで、いくつかの開発プロセスについて説明してきましたが、ある意味、これまで説明してきた開発プロセスよりも、大きな成果を上げている「やり方」があります。それが、バザール方式です。

これは、エリック・レイモンドの論文「The Cathedral and the Bazaar（伽藍とバザール）」（http://www.catb.org/~esr/writings/cathedral-bazaar/、翻訳版：http://cruel.org/freeware/cathedral.html）で論じられている方式です。論文では、Linuxの開発方式を「バザール方式」、それ以外のよくある開発方式を「伽藍方式」と定義し、主にバザール方式のメリットを説いています。

伽藍方式

伽藍方式とは、中央集権的に伽藍を組み上げるかのようなやり方を指す。少数の高スキルの開発メンバーで慎重に開発する。完成するまでベータ版すら出さないような、リリースに対して厳しい考え方。一応言っておくと、多くのオープンソースが、このやり方で成功を収めている。

バザール方式

Linuxの開発で採用されているやり方。任せられるものは他人に任せ、早めにしょっちゅうリリースするという、リリースに対して厳しくない考え方。いろいろな作業やアプローチが渦巻くバザールのようなので、このような名前がついた。

両者の根本的な考え方の違いの1つが、バグに対する考え方です。伽藍方式では、バグは「あってはならないもの」です。つまり、バグがない状態でリリースするために、リリース前に、少数の開発者が長い期間バグ探し（そしてバグ修正）を行います。他方、バザール方式では、極端な言い方をすると、バグは「直すもの」でしかありません。リリースすれば、全世界の利用者によってバグ探しが行われます。

バグが発見されると、これまた全世界の開発者によって修正され、次のリリースに反映されます。バザール方式では、利用者も開発者も全世界の大多数となることもあり、そうなると、このバグ探し、バグ修正、リリースのサイクルを非常に短くできるのです（図1）。

バザール方式の考え方

エリック・レイモンドは、Fetchmailの開発に際して、意識的にバザール方式を実践したと述べています。そして、バザール方式を実践する上での注意点を4点挙げています。

1）早めにしょっちゅうのリリースを心がけた

リリースを増やす（＝リリースサイクルを短くする）ことにより、バグ探し、バグ修正のサイクルを短くすることができます。また、プロジェクトの成果が明確になるため、開発者のモチベーション維持にも効果があります。

2）誰かがFetchmailの件で連絡してきたら、その人をベータリストに加えてリストを増やした。

3）リリースごとに騒々しいアナウンスをベータリストに送りつけて、みんなに参加をうながした。

ベータリストを増やすことにより、開発者を確保することができます。開発者を増やすことにより、バグ探しやバグ修正のスピードアップを期待できます。もちろん、ベータリストから多数参加してもらうことが重要です。

4）ベータテスタたちの言うことを聞いて、設計上の判断について意見を求め、パッチやフィードバックを送ってくれたら必ずほめた。

「言うことを聞く」のも「意見を求める」のも「ほめる」のも、開発者や利用者のモチベーションを向上させます。言うまでもないことですが、モチベーション向上は生産性向上に直結します。

上記の考え方は、特に「頻繁なリリース」「開発メンバーのモチベーション」といった切り口で、アジャイルな開発プロセスと共通していると言えるのではないでしょうか。