著作一覧 |
エリック・レイモンドの伽藍とバザールが19991997年(翻訳版の日付を最初書いていた。以降修正済)なので、もう15年も昔のことなのか。それだけ年月がたてば、ソフトウェア開発者でも、プレジデントやダイヤモンド並のいい加減な知識でいい加減なことを書いたりしたりするのだなぁと感慨もある。
感慨もあるが、少なくともソフトウェア開発そのものを仕事にしているのなら、もう少しまともな知識を持つほうが良いんじゃないか? とも思う。
というわけで、読まずに済ませるOSSの歴史入門を簡単に書いてみたり。
ただ、どれも読めばささっと読めるものばかりなので(山形浩生の訳も読みやすい)、リンクもつけたし本物を読んでももちろん良い。
まずは、『伽藍とバザール』だ。
さて、1997年。Linuxが実用的なOSになってきたころの話だ。FSF(GNUの組織)が1980年代から開発をしている(そもそもgccやGNUのツールは、そのために開発されたはずの)完全にフリーなUNIX互換OSHURDがいつまでたっても完成しないのに、なぜフィンランドの学生が386PC買ったうれしさについ作り始めたOS=Linuxがまともに使えるようになったのか? ということに着目して、HURDの開発体制とLinuxの開発体制に原因を求める論文が発表された。書いたのはエリック・レイモンド。題は『伽藍とバザール』。
普通に考えれば、Emacsを開発したハッカーの中のハッカーRMSとその仲間(つまりgccやGNU Toolsなどなどを開発している連中だ)たちが開発しているHURDのほうが先にモノになるはずだ。
だが、現実は違った。
(伽藍というのは、カテドラル(大聖堂)のこと。翻訳者の腕のみせどころだが、固い漢字の『伽藍』と軽いカタカナの(日本人的にはアラビアンナイトのようないかがわしさを連想させる)『バザール』と訳すことで、概念の対比を強調しているが、宮大工の仕事とテント張りの仕事の対比と考えても良い)
伽藍の建築現場では、親方に指図できるものはいない。弟子達がしゅくしゅくと作業をしていく。外部の人間が壁の歪みを指摘したとして、それが親方の耳に入るかどうかさえ見当がつかない。
バザールでは、商人が1000円で売っている商品に客が介入して400円なら買ってもいいぜとやる。そりゃちょっと旦那、800円でどうですか? と、その場で交渉が始まり適正なところに価格が落ち着く。
OSのように複雑で規模が大きく、開発者の人数も多いソフトウェアの開発をするにはどのような体制が適切だろうか? 設計者が設計し、実装者が実装し、テストをする、そういう伽藍建築のように少数の権威とそれにしたがう集団のよる体制であるべきだ、と誰もが考えていた(ただし、マイクロソフトは違う、と信じられていたわけだし(人月の神話の新装版に追加されたブルックスの回想記。『伽藍とバザール』脚注参照)、その片鱗はジョエルのエッセイに少し見えるが、1990年代後半にはマイクロソフトですら大企業的になっていたようだ)のだが、Linuxの成功を見ると、それは間違いかもしれない。
・意思決定のスピード(なにはともあれメールは通せ)
・開発プロセスへのユーザの組み込み(ユーザは大事な財産)
・リリース頻度の短期化(はやめのリリース、しょっちゅうリリース)
これらが、Linuxの成功の要因のようであり、まさにHURDには欠けているものだ。
では、それらを可能にする条件は何か。
それは、プロジェクトリーダーがナイスであることだ。
バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。
これが、『伽藍とバザール』だ。
おそらく、伽藍=プロプラエタリ、バザール=オープンソースという誤解をしている人がいるかもしれない。だが、オープンソースという言葉は、この時点ではまだ存在しきっていない。したがって、そもそもそういう対比ではないのだ。
わかりやすく、21世紀現在の言葉で、伽藍とバザールという対比を現実社会に当てはめると、もっとも近いものは、ウォーターフォールvsアジャイル だ。
(アジャイル開発で、リーダーがどれだけナイスであろうと心がける必要があるかを考えると良いと思う)
参考書
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣(Venkat Subramaniam)
アジャイルサムライ−達人開発者への道−(Jonathan Rasmusson)
(これは読んだことないけど、ナイスガイ角谷がからんでいるのだから、良い本なのだろう)
・追記:shiroさんのご指摘を受けて1997年に修正。ありがとうございます。併せて「10年以上前」を「15年前」に修正。
ジェズイットを見習え |