概要と気づいたことなどメモ．

Motivation

論文『伽藍とバザール』を読んだ．ソフトウェア工学というキーワードでネットサーフィンしたらみかけて，タイトルが気になったので．本稿はオープンソース・ムーブメントの理論的指導者，エリック・レイモンドにより書かれたもの．その概要と気づいたことなどを簡単にまとめておく．

伽藍形式とバザール形式

伽藍形式とは，従来のソフトウェア開発手法のことを指す．特に，OSやEmacs等の大規模ソフトウェアは，少数精鋭の閉じたコミュニティで粛々と伽藍のように作成されるべき，とされていた．
バザール形式とは，オープンソース開発のような自由で開けた開発を指す．高頻度のリリースを行い，任せられるものはなんでも他人に任せて，バザールのように騒々しくオープンに開発された．この形式を用いた例として，Linuxが挙げられている．
この二者のうち，後者が特に良い結果を生み出すことができる(場合もある)として紹介されている．

バザール形式の利点とは?

利点というか，こんな形式でも安定したシステムを作り上げることができるということ自体が驚きだという話．しかも，高品質で満足のいく品が出来上がる．では，なぜそんなことができたのだろう? 従来の開発手法との違いはどこにあったのだろう?

バザール形式の成功した理由とは?

バザール形式の特徴は，「分散性」と「多様性」と「集合知」であると言われている．本形式では数多くの参加者による作業分担が行われる．この場合，作業の重複が懸念されるが，高頻度のリリースによりそのリスクも削減される．
経済学の用語としてデルファイ効果というものが説明されていた．噛み砕くと，一人の技術者に意見を仰ぐより，同等の技術者住人から意見を聞いて，それを平均化した方が良いというもの．リーヌスも，「問題を理解してそれを直す人物は、必ずしもどころか普通は同一人物ではない。だれかが問題を見つける。そしてそれを理解するのはだれか別の人なんだ。」と言っている．人はそれぞれ異なる観点を持つため，バザール形式では参加人数が多いほどバグの発見数も増える．そして，その修正は他の誰かに任せることができる．
従来の開発手法では，このようなバグの発見に少人数が何ヶ月もの時間を費やす．その結果リリースの間隔が大きくなり，その結果リリースが完璧でない場合の失望が大きい．しかし，バザール方式ではこのようなバグは深刻な問題ではない．誰かがそれを発見し，それを直すためにリリースは増え，たまにヘマがあったところで，失うものは多くない．

伽藍形式との比較

従来のソフトウェア開発とバザール形式を比較して，レイモンドは以下のようなことを言っている．

オープンソースが成功した理由の一部は、その文化がプログラミング人 口のトップ 5% しか受け入れないからだ、と信じている。彼女は、残り 95% の動員を組織するのに時間を費やしている。
…
もし伝統的なソフト管理の唯一の機能が、一番使えないやつらを、せめて損害は出さずにトントンに持っていくくらいだとしたら、そんな仕事は何の価値もないんじゃないか

さらに，以下のように締めくくられる．

ぼくたちは、もっといいソフトがつくれることを示しただけじゃない。よろこびが資産であることを証明してもいるんだ。
…
人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばん嬉しい。簡単すぎて退屈でもいけないし。達成不可能なほどむずかしくてもダメだ。シヤワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。
…
オープンソースの成功のいちばんだいじな影響の一つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。

やりたいことをやる，という当たり前のことが，結果的に製品の品質や生産性の向上につながる．Googleの20%ルールの話や，少し気色が異なるけど，Appleのゴールデンサークルの話を思い出した．
これは本当に個人的な話になるけど，自分の場合は「やりたいこと」というのが今の所あまりはっきりしていないので，これは本当に大切なことなんだなぁと他人事みたいにしか思えない．

論文には著者の教訓が記されている．最後に，そのうちのいくつかを紹介しておく．

• よいソフトはすべて、開発者の個人的な悩み解決から始まる。
• まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。
• おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。