The Cathdral and the Bazaar: Japanese 伽藍とバザール エリック・スティーブン・レイモンド（Eric Steven Raymond）著 山形浩生（YAMAGATA Hiroo）訳 大西清輝（Kiyoteru Onishi）編 ------------------------------------------------------- 【テキスト中に現れる記号について】 《》：ルビ （例）「伽藍《がらん》」モデルで ｜：ルビの付いていない漢字とルビの付く漢字の境の記号 （例）山形｜浩生《ひろお》 ［＃］：入力者注　主に外字の説明や、傍点の位置の指定 （例）役に立つ［＃「役に立つ」に傍点］ハッカー ------------------------------------------------------- 　この文章は、エリック・スティーブン・レイモンド著、山形｜浩生《ひろお》訳でインターネット上に公開されている『伽藍とバザール』をテキストファイル化したものです。 　テキスト化に際して、「青空文庫」（http://www.aozora.gr.jp/）形式のルビ（ふりがな）記述を採用させてもらったことをここに記します。 　原文の最新版は にて各種フォーマットで入手可能です。 　翻訳の原版は にて入手できます。 　翻訳のpdf版は にて入手できます。 　翻訳のPostScript版（tar+gzip圧縮）は にて入手できます。 　最後までごゆるりと、ご堪能してくださいませマセ。m(_ _)m 　2002年2月24日：バージョン1.00公開。 　2002年2月25日：バージョン1.01、ルビの追加と細部の修正。 　2002年4月10日：バージョン1.02、ルビの追加。 　2002年4月14日：バージョン1.03、ほんのちょっとだけ修正。あえてどこを修正したかは言わない。探してみてね！(^o^)/ Kiyoteru Onishi 　　概要 　この論文ではまず、大成功したフリーソフトやオープンソースプロジェクトのフェッチメール（fetchmail）を分析する。このソフトは、リナックス（Linux）の歴史から導かれる、ソフト工学についての意外な理論を試すという意図で実施されたプロジェクトである。 　本論ではその理論を、2種類の根本的にちがった開発スタイルという形で論じている。 　1つはFSF（Free Software Foundation）やそのまねっ子たちの「伽藍《がらん》」モデルで、それに対するのがリナックス界の「バザール」モデルだ。この2つのモデルが、ソフトのデバッグ作業の性質に関する、正反対の前提からそれぞれ生じていることを示す。 　続いてリナックス体験に基づき、「目玉の数さえ十分あれば、どんなバグも深刻ではない」という仮説を支持する議論を展開し、利己的エージェントによる自己修正システムとの有益な対比をしてみる。そしてこの洞察がソフトウェアの未来に対して持つ意味について、いくつか考察を行って結論としている。 　　目次 ・伽藍方式とバザール方式 ・なにはともあれメールは通せ ・ユーザは大事な財産 ・早めのリリース、しょっちゅうリリース ・バラがバラでないのは？ ・POPクライアントからフェッチメールへ ・フェッチメールの成長 ・続・フェッチメールの教訓 ・バザール方式の前提条件とは ・フリーソフト／オープンソースの社会的な意義 ・マネジメントとマジノ線について ・謝辞 ・もっと考えたい人のための文献リスト ・エピローグ：ネットスケープもバザール方式を受け入れる ・脚注 ・バージョンと変更履歴 　　伽藍方式とバザール方式 　リナックスは破壊的存在なり。インターネットのかぼそい糸だけで結ばれた、地球全体に散らばった数千人の開発者たちが片手間にハッキングするだけで、超一流のOSが魔法みたいに編み出されてしまうなんて、ほんの5年前でさえだれも想像すらできなかったんだから。 　ぼくもできなかった。リナックスがぼくのレーダー画面に泳ぎ着いたのは1993年の頭だったけれど、その頃ぼくはすでにユニックス（Unix）やフリーソフト開発に10年以上も関わってきていた。1980年代半ば、ぼくは最初期のGNU協力者の1人だったし、ネット上にかなりのフリーソフトもリリースして、いまでも広く使われているようなプログラムをいくつか、たとえばネットハック（nethack）、イーマックス（Emacs）VCモードとGUDモード、エックスライフ（xlife）などを単独または共同で開発してきた。だから、もうやり方はわかってるもんだと思いこんでいた。 　リナックスは、ぼくがわかっているつもりでいたものを、大幅にひっくりかえしてくれた。それまでだって、小さなツールや高速プロトタイプ作成、進化的プログラミングといったユニックスの福音《ふくいん》は説き続けてはいた。でももっと上のレベルでは何かどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要になってくるものだとも思っていた。一番だいじなソフト（OSや、イーマックスみたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメで、1人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげるべきもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。 　だから リーヌス・トーヴァルズの開発スタイル――早めにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――にはまったく驚かされた。静かで荘厳な伽藍づくりなんかない――リナックスコミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった（これをまさに象徴しているのがリナックスのアーカイブサイトで、ここはどこのだれからでもソフトを受け入れてしまう）。そしてそこから一貫した安定なシステムが出てくるなんて、奇跡がいくつも続かなければ不可能に思えた。 　このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。この世界の様子を学ぶにあたって、ぼくは個別のプロジェクトだけでなく、なぜリナックス界が混乱のうちに崩壊しないのか、それどころかなぜ、伽藍建設者たちの想像を絶するスピードで、続々と強みを発揮し続けられるのかを理解しようとしてきた。 　1996年半ばには、答がわかりかけてきたような気がした。そしてその頃まったくの偶然から、自分の理論を試してみる完璧な機会がやってきた。意識的にバザール方式で運営できるようなフリーソフトプロジェクトという形で。そこでバザール方式を試してみた――そして、大成功。 　というわけでこれから、そのプロジェクトの話をしようではないの。そしてそれを使って、上手なフリーソフト開発についていくつかアフォリズム（標語）を提案してみよう。全部が全部、リナックスの世界で学んだことばかりではないけれど、そういうものでもリナックス界がすごくいい例になってることがわかるはず。ぼくが正しければ、なぜリナックスコミュニティがこんなにいいソフトを続々と生み出せるのか、みんなにもずばりわかるはず――そしてみんなももっと生産的になれるはずなんだ。 　　なにはともあれメールは通せ 　1993年以来、ぼくはペンシルバニア州ウェストチェスターにある、CCIL（Chester County InterLink）という小さなフリーアクセスISPの技術面を担当してた（ぼくはCCILの共同創設者で、ぼくたちが使ってるユニークなマルチユーザBBSソフトを書いた。興味があれば、locke.ccil.orgにテルネット（telnet）してみてほしい。いまでは19回線で3,000人弱のユーザをサポートしてる）。この仕事のおかげで、CCILの56K回線を通じて1日に24時間ネットにアクセスし続けられるようになった――というより、仕事柄そうせざるをえなかったというのが実状かな！ 　そういうわけで、インターネットの電子メールがすぐに手放せなくなった。なんかややこしい理由で自宅のマシン（snark.thyrsus.com）とCCILとでSLIP接続するのに手間取って、それがうまくいくと、今度はしょっちゅうlockeサーバにテルネットしてメールをチェックするのがえらく面倒になってきた。メールをsnarkサーバに配信してもらって、新しいメールがきたらbiff(1)が報せてくれるようにしたかったわけ。 　センドメール（Sendmail）の転送機能は使えない。snarkサーバはネットにつないでないときもあって、IPアドレスも固定されてないからね。SLIP接続経由で手をのばして、メールをローカルマシンに引っ張ってきてくれるようなソフトがほしかったわけだ。そういうソフトがあるのは知ってたし、そのほとんどがPOP（Post Office Protocol）っていう簡単なアプリケーション・プロトコルを使ってるのも知ってた。そして、確かにlockeサーバのBSD/OSには、ちゃんとPOP3サーバソフトが含まれているではないの。 　あとはPOP3のクライアントがあればいい。そこでネットで探してみると、3つか4つ見つかった。しばらくはポップパール（pop-perl）を使ってたけれど、これには当然あるべき（と思われる）機能が欠けていた。とってきたメールのアドレスをいじくって、返信がうまくいくようにするのができなかったんだ。 　つまりこういうことだ。lockeサーバ上の「joe」という人が、ぼくにメールを出したとする。このメールをsnarkサーバにとってきて、それに返信したら、メールソフトはsnarkサーバ上の「joe」にそれを送って悦に入っちゃうわけ。そんな人物はいないのに。だから返信アドレスを手でなおして、@ccil.orgを最後にくっつけてたんだけれど、これはすぐにえらい手間になってきた。 　こんなのどう見ても、コンピュータがやるべきことだよね（実はRFC1123のセクション5.2.18によれば、これはセンドメールが処理しなきゃいけないんだけど）。でも、既存のPOPクライアントはどれ1つとしてこいつがこなせなかった！　というわけで、教訓その1…… 【教訓1】よいソフトはすべて、開発者の個人的な悩み解決から始まる。 　これは自明のことかもしれない（昔から「必要は発明の母」って言うし）。でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし好きでもないようなソフトを1日中シコシコ書いてることがあまりに多いんだ。でも、リナックスの世界ではちがう――リナックス界出身ソフトの質が、平均してすごく高いのはこのせいかもしれないね。 　そこでぼくは、既存のものとタメを張るようなまっさらのPOP3クライアントを書き上げるべく、即座にコード書きの渦中へ猛然ととびこんだ――かな？　ご冗談を！　ぼくはまず、手元にあるPOPユーティリティをじっくりながめてこう考えた。「ぼくの欲しいものにいちばん近いのはどれかな？」　というのも…… 【教訓2】何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば（そして使い回せば）いいかわかってるのが、すごいプログラマ。 　――だからね。すごいプログラマを気取るつもりはないけど、でもそのまねくらいはしたい。すごいプログラマの大事な特徴の1つが、建設的な面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、そのための努力じゃないってのがわかってるってこと。そして白紙から始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。 　たとえばリーヌス・トーヴァルズ（http://www.tuxedo.org/~esr/faqs/linus）は、リナックスをゼロから書き始めたわけじゃない。i386マシン用の、小さなユニックスっぽいOSだったミニックス（Minix）のコードやアイデアを再利用するところから始めてる。やがてミニックスのコードは全部落とされたか、あるいは完全に書き直された――でも最初のうちは、やがてリナックスとなるべき赤ん坊のための簡単な囲いを提供してくれてたんだ。 　同じ精神から、ぼくは既存のPOPユーティリティを探しに出た。そこそこ上手にコーディングされてて、開発のベースに使えるようなヤツを。 　ユニックス界では、ソース共有の伝統のおかげでコードの再利用が昔からとってもやりやすかった（このせいでGNUプロジェクトは、ユニックスというOSそのものについては、かなり不満を持ってたんだけれど、ベースOSにはユニックスを選んだ）。リナックス界は、この伝統を技術的な極限にまでつきつめてる。だれにでも使えるオープンなソースコードが、何テラバイトもある。だからだれかほかの人の、ほとんど使いものになりそうなコードを探すのは、リナックスの世界ではほかのどこよりもすごくいい結果を生みやすい。 　ぼくの場合もそうだった。もう一度探しに出た結果、最初に見つけたのとあわせて候補が九個あがってきた――fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail、upop――最初に落ち着いた先は呉承洪（オー・スンホン）のフェッチポップ（fetchpop）だった。ぼくは自前のヘッダ変更機能をそれに加えて、その他いろいろ改良を入れた。作者はそれを受け入れて、1.9リリースに含めてくれた。 　でも数週間たって、カール・ハリス（Carl Harris）のPOPクライアント（popclient）のコードに出くわして、困ったなと思った。フェッチポップはなかなかいい独創的なアイデア、たとえばデーモン（daemon）モードとかが入ってたんだけれど、POP3しか扱えないし、コードもいささか素人くさかった（スンホンはプログラマとして才能はあるけれどまだ駆け出しで、その両方の特徴がフェッチポップには出ていた）。カールのコードのほうが優れていて、プロ級のしっかりしたものだったけれど、大事なのに実装が面倒なフェッチポップの機能がいくつか欠けていた（ぼくがコーディングした機能も含め）。 　このままいくか、乗り換えるか？　乗り換えたら、開発ベースはよくなるけれど、かわりにこれまでのコーディングは全部捨てることになる。 　実際問題として、乗り換える理由の1つに複数のプロトコルが扱える点があった。POP3はポスト・オフィス（post-office）サーバプロトコルで一番普及はしているけれど、唯一無二ってわけじゃない。フェッチポップをはじめとする競合ソフトはPOP2もRPOPもAPOPも扱えなかったし、ぼくの方ではIMAP （Internet Message Access Protocol＝一番最近に設計された、最強のポスト・オフィスプロトコル）のサポートを入れたらいいかもしれないな、なんてことをすでにおもしろ半分で考え始めていた。 　でも、乗り換えたほうがいいかもしれない理論的な根拠もあった。これはぼくが、リナックスよりずっと前に学んだことでもある。こういうことだ…… 【教訓3】捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから（フレデリック・P・ブルックス著『人月の神話』第11章） 　あるいは言い換えると、1回とりあえず解決策を実装してみるまでは、問題を完全には理解しきれないってこと。2回目くらいになってやっと、正しい解決法がわかるくらいの理解が得られるかもしれない。だからちゃんとした問題解決をしたいなら、少なくとも1回くらいはやりなおす覚悟はしておくこと。[JB] 　ま、（と独り言）フェッチポップの改良が1回目だったわけだ。というわけで、ぼくは乗り換えた。 　最初のフェッチポップ用パッチを1996年6月25日にカール・ハリスに送ったんだけれど、実はかれはしばらくまえに、POPクライアントに興味をなくしていることがわかった。コードもほこりをかぶってる状態で、ちょっとしたバグも残ったままだったし。こっちとしては、いろいろ変えたいところもあった。だから、ぼくがこのプログラムを任されるのがいちばん理にかなってるということで、両者はすぐに合意した。 　自分でも気がつかないうちに、プロジェクトは拡大したわけだ。もはやぼくは、既存のPOPクライアントにちょっとパッチをあてるような話をしてるわけじゃない。プログラムをまるごとメンテする作業を引き受けてたんだ。そして頭の中ではいろいろアイデアも湧いてきていて、これをやったら大幅な変更が必要になるな、というのもはっきりしてた。 　コード共有を奨励するソフト文化にあって、これはプロジェクト発展の自然な道筋ではある。ぼくは次の原理を実践していたことになる…… 【教訓4】まともな行動をとってれば、おもしろい問題のほうからこっちを見つけだしてくれる。 　でもカール・ハリスの行動のほうがもっと大事だ。かれが理解していたこと…… 【教訓5】あるソフトに興味をなくしたら、最後の仕事としてそれを有能な後継者に引き渡すこと。 　なにも相談なんかしなくても、カールもぼくも、自分たちがこの世で最高の問題解決方法を実現するという共通の目標を持っていることがわかっていた。2人にとって唯一の問題は、ぼくがこれを安心して任せられる人物だってことを証明できるかということだけだった。それを実証してみせたら、かれはすぐさま優雅なふるまいを見せて、ソフトをゆだねてくれた。ぼくの順番がきたときにも、カールと同じくらいの鷹揚《おうよう》さを示したいなと思う。 　　ユーザは大事な財産 　というわけで、ぼくはPOPクライアントをひきついだ。そして同じくらい大事なことだけれど、ぼくはPOPクライアントのユーザベースもひきついだわけだ。ユーザを持つのはすばらしいことで、それは単に、自分が何かニーズに対応してるんだな、なにか役に立つことをしたんだな、ということを実証してくれるからというだけじゃない。きちんと育てれば、ユーザは共同開発者になってくれるんだ。 　これまたユニックスの伝統の強みで、これまたリナックスがみごとに極限までおしすすめる強みでもあるんだけれど、ユーザの中にもハッカーがたくさんいるわけだ。そしてソースコードが公開されてるから、かれらは同じハッカーでも役に立つ［＃「役に立つ」に傍点］ハッカーになってくれる。これはデバッグ時間短縮にはすごく役に立つ。ちょっと励ますだけで、ユーザが問題を診断し、直し方を提案してくれて、1人でやるよりずっとはやくコードを改善できるようにしてくれる。 【教訓6】ユーザを共同開発者として扱うのは、コードの高速改良と効率よいデバッグのいちばん楽ちんな方法。 　この効果の力はすごく見落としがち。はっきり言って、ぼくらフリーソフト界のほとんどだれもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そしてそれがシステムの複雑さに対してどれほど有効に機能するかについて、まったく見えてなかった。リーヌスが目を開いてくれるまでは。 　はっきり言って、ぼくはリーヌスのいちばん賢い、影響力あるハッキングというのは、リナックスのカーネル構築そのものではないと思う。むしろリナックス開発モデルの発明だと思う。本人の前でこの意見を述べてみたら、かれはにっこりして、これまで何度か言ったことを静かに繰り返した。「ぼくは基本的に怠け者で、ほかの人のしてくれた作業を自分の仕事だと称するのが好きなんだよ」。キツネのようなずるがしこい怠けぶり。あるいはロバート・ハインラインが自作の登場人物の1人について書いた有名な表現にならえば、「失敗するには怠惰《たいだ》すぎる」だろうね。 　ふりかえってみると、リナックスの手法や成功の前例はGNUイーマックス（Emacs）のリスプ（Lisp）ライブラリとリスプコードアーカイブの開発にみることができる。イーマックスのCのコア部分やその他FSFツールみたいな、伽藍建築方式にくらべると、リスプコードのプールの進化は流動的で、すごくユーザ主導で行われた。アイデアやプロトタイプ・モードは、安定した最終形に落ち着くまで3回も4回も書き直されるのがしょっちゅうだった。そしてリナックスと同じく、インターネットが可能にしたゆるい協力体制もしばしばとられていた。 　確かに、ぼく自身でもフェッチメール以前でいちばんうまくいったハッキングは、イーマックスのVCモードだと思う。これはリナックスみたいに、電子メールで3人と共同作業して開発した。今日にいたるまで、その中で実際に顔をあわせたことがあるのは1人、リチャード・ストールマン（Richard Stallman. イーマックスの作者でFSF の創始者）だけだ。これはSCCS、RCS、そして後にはCVSとなったもののフロントエンドで、「ワンタッチ」のバージョンコントロール機能をイーマックスの中から使えるようにするものだった。もとにしたのは、だれかが書いた、いい加減でちっちゃなsccs.elモード。そしてVCの開発が成功したのは、イーマックス本体とはちがって、イーマックス・リスプのコードはリリース／テスト／改良のサイクルをすごく早く回せるからだった。 　　早めのリリース、しょっちゅうリリース 　早めにしょっちゅうリリースするのは、リナックス開発モデルの重要な部分だ。ほとんどの開発者（含ぼく）は、プロジェクトがちょっとでも大きくなったらこいつはまずいやり方だと考えていた。初期バージョンはその定義からいってバグだらけだし、ユーザの我慢にも限度があるだろうから。 　この信念のおかげで、伽藍建設式の開発への関与も深まった。もし最優先課題が、できるだけ少ないバグしかユーザにお目にかけないということだったら、うん、それならリリースは半年に一度とかにして（あるいはもっと間をおいて）、リリースの間は犬みたいにひたすらバグ取りに専念するだろう。イーマックスのCの核部分はこういう形で開発された。リスプライブラリは、事実上ちがっていた。FSFのコントロールのきかない活発なリスプアーカイブがあって、そこにいけばイーマックスのリリースサイクルとはまったく関係ない、新しい開発コードが手に入ったから。[QR] 　こういうアーカイブのいちばん重要なものの1つは、オハイオ州立大のelispアーカイブでここは今日の大きなリナックスアーカイブの精神や特徴の多くを先取りしたところだった。でも、自分たちがなにをしているのかしっかり考えてみた者はほとんどいなかったし、このアーカイブの存在自体が、FSF式の伽藍建設型開発モデルの問題点についてなにを示唆しているのかについてもあまり考えなかった。1992年頃、ぼくはオハイオのコードの相当部分を正式に公式イーマックス・リスプライブラリに組み込もうとして、かなりまじめに取り組んだ。でも政治的な問題にぶちあたって、ほとんどうまくいかなかった。 　でもそれから1年たたないうちに、リナックスがかなり目に見えて広まってくると、なにかちがった、ずっと健全なことが起こっているのははっきりしてきた。リーヌスのオープンな開発方針は、伽藍建設の正反対のものだった。サンサイト（Sunsite <現metalab> ）やTSXのサーバ（tsx-11）のアーカイブははちきれそうで、パッケージもどんどん登場してきた。そしてそのすべてが、前代未聞の頻度でリリースされるコアシステムに動かされていた。 　リーヌスはいちばん効果的なやりかたで、ユーザたちを共同開発者として扱っていたことになる。 【教訓7】早めのリリース、ひんぱんなリリース。そして顧客の話をきくこと。 　リーヌスの革新は、これをやったということじゃない（似たようなことは、もうながいことユニックスの世界の伝統になっていた）。それをスケールアップして、開発しているものの複雑さに見合うだけの集中した取り組みにまでもっていったということだった。開発初期のあの頃だと、リーヌスが新しいカーネルを1日に何回もリリースすることだって、そんなに珍しくはなかった。そしてかれは、共同開発者の基盤をうまく育てて、インターネットでうまく共同作業をする点で、ほかのだれよりも上をいっていた。それでうまくいったわけだ。 　でも、具体的にどういうふうに［＃「具体的にどういうふうに」に傍点］うまくいってるんだろう。そしてそれはぼくでもまねできるものなんだろうか、それともリーヌスだけにしかない独特な才能に依存したものなんだろうか？ 　そうは思えなかった。そりゃもちろん、リーヌスはまったく大したハッカーだ（完全な製品レベルのOSカーネルをつくりあげられる人間が、ぼくたちのなかでどれだけいるね？）。でも、リナックスはとんでもないソフトウェア思想上の進歩を取り込んだりはしていない。リーヌスは、たとえばリチャード・ストールマンとかジェームズ・ゴスリング（NeWSとJavaで有名）のような、設計面での革新的天才ではないんだ（少なくともいまのところは）。むしろリーヌスはエンジニアリングの天才なんじゃないかと思う。バグや開発上の袋小路を避ける第六感と、A地点からB地点にたどりつく、いちばん楽な道を見つけだす真の直感もある。リナックスの設計はすべて、この特徴が息づいているし、リーヌスの本質的に地道で単純化するような設計アプローチが反映されている。 　じゃあ、もし急速リリースと、インターネットの徹底的な使い倒しが偶然ではなくて、労力を最小限ですまそうとするリーヌスのエンジニアリング上の天才的洞察の不可欠な部分だったんなら、かれが最大化しているのは何だったんだろう。この仕組みからかれがひねりだしているのはなんだったんだろう。 　こういう問題のたてかたをすれば、質問自体が答になる。リーヌスは、ハッカーやユーザたちをたえず刺激して、ごほうびを与え続けたってことだ。刺激は、全体の動きの中で一員となることでエゴを満足させられるという見込みで、ごほうびは、自分たちの仕事がたえず（まさに毎日のように）進歩している様子だ。 　リーヌスは、デバッグと開発に投入される人・時間を最大化することをずばり狙っていたわけだ。コードの安定性が犠牲になったり、なにか深刻なバグがどうしようもなくなったら、ユーザ基盤に見放されるかもしれないという危険をおかしてまでそれをやっていた。リーヌスの行動を見ていると、次のような信念を持っていたんじゃないかと思える。 【教訓8】ベータテスタと共同開発者の基盤さえ十分大きければ、ほとんどすべての問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。 　あるいはもっとくだけた表現だと、「目玉の数さえ十分あれば、どんなバグも深刻ではない」。これをぼくはリーヌスの法則と呼んでる。 　はじめにこの法則を書いたときは、どんな問題も「だれかには明白だ」という書き方をしていた。リーヌスはこれに異議を唱えて、問題を理解してそれをなおす人物は、必ずしもどころかふつうは、その問題を最初に記述する人間ではないと言った。「だれかが問題を見つける。そしてそれを理解するのはだれか別の人［＃「別の人」に傍点］だよ。そして問題を見つけることのほうがむずかしいとぼくが述べたことは記録しておいてね」。でも肝心なのは、見つけるのもなおすのも、だいたいすごく短期間で起きるってことだ。 　ここに、伽藍建築方式とバザール式のちがいの核心部分があるんだと思う。伽藍建設者的なプログラミングの見方では、バグや開発上の問題はややこしく、潜伏した深い現象だ。問題を全部ほじくりだしたと確信できるようになるには、少数の人が何ヶ月も専念してチェックしなきゃならない。だからリリースの間隔も開いてくるし、長く待たされたリリースが完璧じゃないときには、どうしても失望も大きくなる。 　一方のバザール的見方だと、バグなんてほとんどは深刻な現象じゃないという前提にたつことになる――少なくとも、リリースを1つ残らず、千人の熱心な共同開発者が叩いてくれるような状況にさらされたら、どんなバグも早々に浮上してくると考える。よって、たくさんなおしてもらうためにリリースも増やすし、有益な副作用としては、ときどきヘマが出回っちゃっても、あんまり失うものは大きくないってわけ。 　そして、これがすべてだ。これだけで必要十分。もしリーヌスの法則がまちがってるなら、リナックスカーネルほど複雑なシステム、リナックスカーネルくらいみんながよってたかってハッキングしてるようなシステムは、どこかの時点でまずい相互作用や、発見できない「深い」バグのせいで崩壊してたはずなんだ。一方、もしリーヌスの法則が正しければ、これでリナックスが相対的にバグが少ないことを十分説明できる。 　そしてこれは、そんなに驚くべきことでもなかったのかもしれない。社会学者たちは何年も前に、同じくらいの専門家（あるいは同じくらい無知な人たち）の意見の平均は、そういう観察者の1人をランダムに選んで意見をきくよりも、予測精度がかなり高いことを発見している。これをかれらは「デルファイ効果」と呼んだ。どうやらリーヌスが示したのは、これがOSのデバッグにも適用できるってことみたいだ。つまりデルファイ効果は、OSカーネル級の複雑なものでも、開発上の複雑さをおさめることができるんだ。 　リナックスの場合の特別な性格で、デルファイ効果的な形でとても役にたっているのは、どんなプロジェクトでもその貢献者は自薦だということだ。初期にコメントをくれた人が指摘してくれたことだけれど、貢献は、ランダムなサンプルから出てくる訳じゃなくて、そのソフトを使うだけの興味を持って、その仕組みを学び、出くわした問題への解決を探そうとして、まあまともそうな解決策を作るだけのことをした人から寄せられる。これだけのフィルタを全部突破してくる人は、貢献できるだけのものは持っている可能性がかなり高い。 　ジェフ・ダツキー（Jeff Dutky ）は、リーヌスの法則は「デバッグは並列処理可能だ」と言い換えることもできると指摘してくれた。感謝したい。ジェフの知見では、デバッグするにはデバッガは開発コーディネータと多少のやりとりは必要だけれど、デバッガ同士では大した調整は必要ない。だから、開発者を加えることで発生する、幾何級《とうひきゅう》数的な複雑性と管理コスト増大という問題には直面しないですむというわけだ。 　実際問題として、デバッガたちの作業重複によって生じる理論的な無駄は、リナックスの世界ではほとんど問題にされないようだ。「早めしょっちゅうのリリース」の効果の1つとして、すでにフィードバック済みのバグフィックスをすばやく広めることでそういう重複をなくせるということがある。[JH] 　ブルックスは、すでにジェフの見解に関連したような観察をなにげなく述べてる。「広範に使われるプログラムをメンテナンスするコストは、おおむねその開発コストの40％だ。驚いたことに、このコストはユーザ数に大きく左右される。ユーザが増えると見つかるバグも増える［＃「ユーザが増えると見つかるバグも増える」に傍点］のだ」（強調訳者）。 　ユーザが増えると見つかるバグも増えるのは、ユーザを追加することで、プログラムをもっといろんな方法で叩いてみることができるからだ。この効果は、そのユーザたちが共同開発者でもある場合にはさらに増幅される。各人が、ちょっとずつちがったものの見方と分析用ツールキットをもって、その任に当たる。「デルファイ効果」はまさにこの多様性のためにうまく機能するらしい。デバッグという分野に限った話をすると、この多様性のおかげで試みが重複する機会も減るらしい。 　だからベータテスタの数を増やしても、開発者側［＃「開発者側」に傍点］の立場からすれば目下の「一番深い」バグの複雑さが減るわけではないけれど、でもだれかのツールキットがその問題にうまくマッチして、その人にとっては［＃「その人にとっては」に傍点］そのバグが深刻ではないという可能性を増してくれるわけだ。 　リーヌスも、そこらへんは抜け目なくやってる。万が一本当に［＃「本当に」に傍点］深刻なバグがあったときのために、リナックスカーネルのバージョンのナンバリングには工夫がある。ユーザ候補は、「安定」とされたカーネル最新版を使うか、最先端にいって、新しい機能を使うかわりにバグの危険をおかすか、という選択ができるようになってる。この戦術は、ほかのリナックスハッカーたちはまだ正式に採用していないけれど、でも採用されるべきかもしれない。選択肢があるというのは、魅力を増すから。 　　バラがバラでないのは？ 　リーヌスの行動を研究して、それが成功している理由について理論ができたので、この理論を自分の（確かにずっと単純で小規模な）プロジェクトで試してみようとぼくは意識的に決めた。 　でも、まずやったのはPOPクライアントを再構成してすごく単純化することだった。カール・ハリスの実装はすごくしっかりしていたけれど、Cのプログラマにありがちな、無用な複雑さが見られた。かれはコードを中心に考えていて、データ構造はコードのサポートとして扱っていた。結果として、コードは美しかったけれど、データ構造のデザインはいきあたりばったりで、いささか醜かった（少なくともこの老いぼれリスプハッカーの高い基準で見れば）。 　でも、書き直しをやったのは、コードやデータ構造の設計を改善する以外にも目的があった。それは、このソフトを進歩させて、自分が完全に理解してるものにすることだった。自分でもわかってないプログラムのバグをなおす責任をしょいこむなんて、おもしろくもないからね。 　そして最初の1ヶ月かそこらは、単にカールの基本的な設計の考え方を追いかけてただけだった。ぼくが加えた最初の大きな変更は、IMAPのサポートを加えることだった。これは、プロトコルマシンを、汎用ドライバとメソッドテーブル3つ（POP2、POP3、IMAP用）に再構成することで実現した。これと、その前の変更は、プログラマとして頭にいれておくといい一般原則を示すものだ。特に、ダイナミックなタイプ処理をしないCみたいな言語では…… 【教訓9】賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。 　またもやフレデリック・P・ブルックス本の第11章から。「コードだけ見せてくれてデータ構造は見せてもらえなかったら、わたしはわけがわからぬままだろう。データ構造さえ見せてもらえれば、コードのほうは多分いらない。見るまでもなく明らかだから」。 　ほんとはかれが言ったのは「フローチャート」に「テーブル」だった。でも30年にわたる用語面・文化面での推移を考慮すれば、ほとんど同じことを言ってる。 　この時点（1996年9月頭、ゼロ時点から約6週間後）で、ぼくはそろそろ名前の変え時かな、と考え出した。なんといっても、もうPOPクライアントだけじゃなくなってたんだし。でも、ためらった。いまのところ、まだこのソフトにはまったく新しい部分が何もなかったからだ。ぼく版のPOPクライアントは、まだ独自のアイデンティティを確立するにいたってなかった。 　これが派手に変わったのは、フェッチメールがとってきたメールをSMTPポートに転送する方法を身につけたときだった。この話はまたあとで。それよりまず、上で、このプロジェクトを使って、リーヌス・トーヴァルズがうまくやった点についての自分の理論を試すことにした、と書いた。試すって、どういうふうに？（という疑問は当然起こるだろう）。それは以下の通り。 ・早めしょっちゅうのリリースを心がけた（間が10日以上開いたことはほとんどない。集中して開発しているときは、1日1回）。 ・だれかがフェッチメールの件で連絡してきたら、その人をベータリストに加えてリストを増やした。 ・リリースごとに騒々しいアナウンスをベータリストに送りつけて、みんなに参加をうながした。 ・そしてベータテスタたちの言うことをきいて、設計上の判断について意見を求め、パッチやフィードバックを送ってくれたら必ず誉《ほ》めた。 　こういう単純な方法の見返りはすぐにやってきた。プロジェクトの始めから、ぼくは他の開発者なら死んでもいいと思うような質の高いバグレポートをもらったし、しかもそれになかなかいいフィックスまでついてきた。よく考えられたコメントももらったし、ファンレターもきたし、賢い機能の提案ももらった。これでわかるのが…… 【教訓10】ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に大事な資源となることで報いてくれる。 　フェッチメールの成功をはかるおもしろい指標としては、このプロジェクトのベータリスト――フェッチメール友の会――のサイズを見るといい。執筆時点では249人で、毎週2、3人追加されている。 　実は、1997年5月に改訂している時点だと、このリストは人数が減りはじめてる。その理由がおもしろい。何人かがリストから外してくれといってきたんだけれど、それはフェッチメールがかれらにはまったく文句なしに機能しているので、メーリングリストのトラフィックを見る必要がないと言うんだ。成熟したバザール形式のライフサイクルでは、これが自然なのかも知れない。 　　POPクライアントからフェッチメールへ 　このプロジェクトの真のターニングポイントは、ハリー・ホックハイザー（Harry Hochheiser）がクライアント機のSMTPポートにメールを転送するための書きかけのコードを送ってきてくれたときだった。ぼくはほとんど即座に、この機能を信頼できる形で実装できたら、ほかの配信モードはほとんど時代遅れ同然になるなと気がついた。 　何週間にもわたって、ぼくはフェッチメールにいろいろ追加する形でいじってきていた。でもその間、インターフェースのデザインが使えなくはないけれど、ちょっと野暮ったいなと感じだしていた――エレガントじゃないし、貧弱なオプションがそこらじゅうにぶらさがってるし。とってきたメールをメールボックスファイルや標準出力にダンプするオプションがことさら気に入らなかったけれど、その理由が自分でもわからなかった。 　SMTP転送について考えてみたときに気がついたのは、POPクライアントはいろいろやろうとしすぎてるということだった。これはメール配送エージェント（MTA）とローカル配信エージェント（MDA）の両方をこなすよう設計されていた。SMTP転送があれば、MDAの仕事からは足を洗って、メールのローカル配信はほかのソフトにまかせればいい。ちょうどセンドメールがやってるように。 　メール配信エージェントのややこしい設定なんか、しなくたっていいじゃないか。メールボックスをロックして追加なんて、しなくていいじゃないか。ポート25は、TCP/IPサポートのあるプラットホームなら、まずまちがいなくそこにあるんだから。特にこうすれば、とってきたメールは確実に、ふつうの送り手から送られてきたSMTPメールのように見えるはずなんだ。それがもともとぼくたちの求めているものだろう。 　ここにはいくつか教訓がある。まず、このSMTP転送のアイデアは、ぼくがリーヌスのやりかたを意識的に真似ようとした最大の見返りだった。あるユーザがすばらしいアイデアを提供してくれた――ぼくは単に、その意義を理解すればよかっただけ。 【教訓11】いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識することである。時にはどっちが次善かわからなかったりする。 　おもしろいことに、もし自分が他人に負うところがいかに大きいかについて、完全かつ謙虚なくらいに正直でいたら、世の中はその発明が全部あなた自身のもので、単に自分の天才ぶりについて謙遜しているだけだと見なしてくれる。これがリーヌスの場合にどんなにうまくいってるか、みんなもごらんの通り！ （1997年8月にこの論文をパール の会議で発表したとき、最前列にラリー・ウォール がいた。ぼくがこの直前のくだりにさしかかるとかれが野次をとばした。キリスト復活論者スタイルで、「そうだそうだ、言ってやれ、兄弟！」と。全聴衆が笑った。みんなこれが、パール発明者にとってもうまくいったのを知っていたからだ。） 　そしてその同じ精神でプロジェクトを運営してほんの数週間もしないうちに、ユーザたちからだけでなく、それを伝え聞いたほかの人たちからも、同じような賞賛のメールが届くようになった。そういうメールはいくつかとってある。いつか、自分の人生なんて何の価値もなかったんじゃないかと思うようになったら、またそれを読みかえそうっと！ 　でもここには、もっと本質的で政治的でない教訓があと2つある。これはあらゆるデザインに一般化して言えることだ。 【教訓12】自分の問題のとらえかたがそもそも間違っていたと認識することで、もっとも衝撃的で革新的な解決策が生まれることはよくある。 　ぼくはPOPクライアントを、MTA/MDAの複合物として開発し、いろんな気の利いたローカル配信モードをくっつけたものにしようとし続けていた。これは解決すべき問題をまちがえていたんだ。フェッチメールの設計は、純粋なMTAとして最初から考え直す必要があった。通常のSMTPを話すインターネットメールパスの一部として。 　開発で壁にぶちあたったとき――次のパッチ以降何をしたらいいか、すごく悩んでしまうとき――というのは、自分が最終的な回答にたどりついたのかな、と考えるべきときではなく、むしろ自分が正しい質問をしているのかな、と考え直してみるべきときであることが多い。ひょっとして、問題をとらえなおしてみる必要があるのかもしれない。 　というわけで、問題をとらえなおした。明らかに、やるべき正しいことというのは…… ・汎用ドライバにSMTP転送サポートをハックして入れ込む。 ・それをデフォルトモードにする。 ・やがてはその他の配信モードをすべてうっちゃる。特にファイルへの配信と標準出力への配信は始末する。 　ということだった。 　この3番目については、しばらくためらった。ながいことPOPクライアントを使ってきて、他の配信メカニズムに頼っている古参ユーザたちを怒らせるんじゃないかと思ったからだ。理論的には、かれらは即座に.forwardファイルか、センドメール以外でもそれに相当する仕組みを使うことで、同じ結果を得ることができる。でも実際問題としては、この移行はえらく手間がかかることになるかもしれない。 　でも実際にやってみたら、利点のほうが大きく出てきた。ドライバのコードのいちばんいやらしい部分が消えた。設定もむちゃくちゃに簡単になった――システムMDAやユーザのメールボックスを探し回ったりして悩むこともなくなったし、下敷きになってるOSがファイルのロッキングをサポートしているか心配する必要もない。 　さらに、メールをなくす唯一の方法も消え失せた。もしファイルへの配信を指定してディスクがいっぱいになったら、メールは消えてしまう。これはSMTP転送では絶対に起きない。SMTPのリスナーは、メッセージが配信できるか、少なくとも後の配信用にスプールできる場合にしかOKを返してよこさないからだ。 　さらに、速度も向上（もっともこれは1回走らせたくらいではわからないけれど）。もうひとつバカにできないメリットとして、マニュアル（man）ページがすごくシンプルになった。 　あとで、ダイナミックSLIPがらみの珍しい状況を処理できるようにするため、ユーザ指定のローカルMDA経由の配信は復活させなきゃならなかった。でも、これももっと簡単にこなす方法を見つけた。 　教訓は？　古びてきた機能は迷わず捨てること――有効性を下げずに捨てられる場合には。アントワーヌ・サンテグジュペリ（かれは児童書の古典を書いていないときには、飛行家で航空機設計家だった）曰く…… 【教訓13】「完成」（デザイン上の）とは、付け加えるものが何もなくなったときではなく、むしろなにも取り去るものがなくなったとき。 　コードがどんどんよくなって、しかも同時に単純になってきたら、それはもう絶対に［＃「絶対に」に傍点］自分が正しいのがわかる。そしてこの過程で、フェッチメールのデザインは、先祖のPOPクライアントとは別の独自のアイデンティティを獲得してきた。 　そろそろ名前を変える頃だった。新しいデザインは、以前のPOPクライアントよりずっとセンドメールの双子みたいな感じになってきていた。どっちもMTAだけれど、センドメールがプッシュして配信するのに対して、新しいPOPクライアントはプルして配信する。だから引き継いで2ヶ月したところで、ぼくはこれをフェッチメールと改名した。 　SMTP配信がフェッチメールになったこのお話には、もっと一般的な教訓がある。並列処理可能なのは、デバッグだけじゃない。開発と、（かなり驚く規模で）デザイン空間の開拓も並列処理ができるってことだ。開発モードが高速なやりとりに基づくものになっていると、開発と拡張はデバッグの特殊なケースになってくる――つまり、もとのソフトの機能やコンセプトにおける「見過ごしというバグ」をなおすことになるわけ。 　もっと高次のデザインでも、自分の製品近くのデザイン空間を、多くの共同開発者たちがランダムウォークしつついろいろ考えてくれていると、とても役にたつことが多い。水たまりがドブに流れていくやり方とか、あるいはもっといいのは、アリが食物を見つけるやり方を考えてほしい。基本的には、拡散による探索をして、その後で、スケーラブルな通信メカニズムによって、探索の結果を取り尽くす。これは実にうまく機能するんだ。そしてハリー・ホックハイザーとぼくの場合と同じく、きみの周縁ライダーたちが、近くの巨大な勝利を見つけてくることは十分にありえる。自分では、近くばかり見過ぎていてちょっと気がつかなかったようなやつをね。 　　フェッチメールの成長 　そういうわけで、きれいで革新的なデザインを手に入れ、毎日自分で使ってるから確実に動くのもわかってるコードもできたし、さらにベータリストは拡大する一方。だんだんわかってきたのは、自分がやっているのが、ほんの数人にたまたま便利に使えるような、自分だけのちょっとしたハッキングなんかではなくなってきた、ということだった。ぼくがいじっているのは、ユニックスマシンとSLIP/PPPメール接続を持ってるハッカーみんなが本当に必要としているプログラムだったんだ。 　SMTP転送機能のおかげで、このソフトは競合ソフトからぬきんでて、「カテゴリーキラー」になる可能性まで出てきた。カテゴリーキラーというのは、ニッチをあまりに見事に満たしているので、それ以外の選択肢は単に放棄されるどころか、ほとんど忘れ去られてしまうようなソフトのことだ。 　こういう結果は、狙ってできるものではないし、計画して得られるものでもないと思う。ものすごく強力なデザイン上のアイデア、あとから考えると、その結果が当然きわまりなく、自然で、事前に約束されていたようにさえ思えるようなアイデアによって、そういう結果に引き込まれなくてはならないんだと思う。そんなアイデアを狙うには、たくさんアイデアを思いつくしかない――または、ほかのひとのいいアイデアをもらって、それをもとの発案者が思ってもみなかったところまでつきつめるというエンジニアリング上の判断を持つという方法か。 　アンドリュー・タネンバウム（Andrew Tanenbaum）は、i386用に簡単なネイティブのユニックスを作るというアイデアを最初に思いついた。これは教育用ツールとしてだった。リーヌス・トーヴァルズはミニックスのコンセプトを、アンドリューが予想もしなかったくらいはるか遠くにまで拡張した――そしてそれが、すばらしいものへと成長した。同じように（もっともスケールは小さいけれど）ぼくはカール・ハリスとハリー・ホックハイザーのアイデアをもとにして、それをつきつめた。ぼくらのいずれも、みんなが天才というものを考えるロマンチックな意味では「独創的」じゃなかった。でも、科学も工学もソフト開発も、ほとんどは独創的な天才の手になるものではないんだ。ハッカー神話がなんと言おうとも。 　でも結果はそれでもなかなか大した代物だった――それどころか、あらゆるハッカーが死んでもいいと思うような大成功！　そしてこれはつまり、ぼくは自分のねらいをさらに高く設定しなきゃいけないということを意味する。フェッチメールを、いまの自分に見える可能性くらいにまで優れたものにするためには、自分のニーズのためだけにコードを書くのではなく、自分の守備範囲ははずれていても他人が必要としているような機能を加え、サポートしなくてはならなくなった。そして同時に、プログラムをシンプルで堅牢《けんろう》にしておく必要もあった。 　これを認識してから書いた初の、そして圧倒的にいちばん重要な機能は、マルチドロップのサポートだった。これはつまり、複数ユーザ宛のメールが全部たまっているメールボックスからメールをとってきて、それぞれのメールを個別受信者に選り分ける機能だ。 　マルチドロップのサポートを足すことにしたのは、1つには一部のユーザがしつこくせがんだこともある。でも最大の理由は、アドレッシングを最大限に一般化して対応せざるを得なくなることで、シングルドロップのコードのバグを全部ひねりつぶせるだろうと思ったからだ。そしてそれは立派に実証された。RFC822（http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt）を解析してきちんと実装するには、えらく長い時間がかかった。これは個別部分が特にむずかしかったからではなく、相互に依存しあった面倒な細部を山ほど片づけなきゃならなかったからだ。 　でもマルチドロップアドレッシングは、ふたをあけてみたらこれまたすばらしい設計上の決定だった。なぜそう思ったかというと…… 【教訓14】ツールはすべて期待通りの役にたたなきゃダメだが、すごいツールはまったく予想もしなかったような役にもたってしまう。 　――からだ。マルチドロップフェッチメールの予想もしない利用法は、メーリングリストを運用する際に、リストの管理やaliasの展開を、SLIP/PPP接続のクライアント側［＃「クライアント側」に傍点］でできちゃえることだった。これはつまり、ISPのアカウント経由で個人マシンを走らせてる人でも、ISPのaliasファイルに絶えずアクセスすることなしにメーリングリストを運用できるってことだ。 　もう1つ、ベータテスタたちが要求してきた重要な変更は、8ビットMIMEのサポートだった。これはすごく楽だった。ぼくは自分のコードを8ビットクリーンにするように心がけてきたからだ。これは、こういう機能への要望を予想してたからではない。こんな別のルールに従ったまでのことだった。 【教訓15】ゲートウェイソフトを書くときはいかなる場合でも、データストリームへの干渉は最低限におさえるように必死で努力すること。そして受け手がわがどうしてもと言わない限り、絶対に情報を捨てないこと！ 　この規則を守っていなかったら、8ビットMIMEサポートはむずかしくてバグだらけになっただろう。でも、ぼくは守っていたので、RFC1652（http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt）を読んで、ほんのちょっとしたヘッダ生成のロジックを加えるだけですんだ。 　ヨーロッパのユーザの一部は、セッションあたりにとってこられるメッセージ数を制限するオプションをつけるようにしつこくせがんだ（電話代が高いので、それを抑えるためだ）。ぼくは長いことこれを拒否してきたし、いまでも完全に満足しているとはいいがたい。でも、世界のために書いているんなら、顧客には耳を傾けなきゃ――かれらがお金で支払ってるんじゃなくても、これは変わらない。 　　続・フェッチメールの教訓 　一般的なソフトウェア工学の問題に戻る前に、フェッチメールの経験からもう少し教訓を引っぱり出して考察しておこう。 　rcファイルの構文は、オプションの「ノイズ」キーワードを持っていて、これはパーサーに完全に無視される。このキーワードのおかげで英語に似た構文が使えるようになるので、それを全部はぎとってできるような、従来の無味乾燥なキーワードと値の対応表よりはずっと読みやすくなっている。 　これはそもそも、ある晩遅くにちょっと始めた実験が発端だった。rcファイルの宣言が、命令形のミニ言語にずいぶん似てきたのに気がついたのだ（そしてこのせいで、もとのPOPクライアントのキーワード「サーバ（server）」を「チェックせよ（poll）」に変えた）。 　この命令形のミニ言語をもっと英語風にしてみたら、使いやすくなりそうだと思った。さて、ぼくはイーマックスやＨＴＭＬや各種データベースエンジンに代表される「なんでも言語化せよ」式デザイン派閥の意識的な急進派ではあるけれど、通常は「英語っぽい」構文はふつう、あまり好きじゃない。 　伝統的にプログラマは、厳密でコンパクトで冗長《じょうちょう》性のまったくない制御構文を好む傾向にあった。これはコンピュータ資源が高価だった時代の文化的な名残だ。当時は構文解析段階は、できる限り安く単純でなきゃならなかったから。英語は 50％くらい冗長性を持っているので、当時はすごく不適切なモデルに見えた。 　英語っぽい構文を避けるべき理由としてぼくが挙げたいのはこういうことではない。ここでこれを挙げたのは、単にそれを却下するためだ。サイクルやコアが安くなってきたら、無味乾燥がそれ自体で目的化してはならない。いまでは、言語はコンピュータにとって安あがりになるよりも、人間にとって便利なほうが大事なのだ。 　でも、慎重になるべきまともな理由はある。1つは複雑さと、構文解析段階のコストだ――あんまり複雑にすると、それ自体がバグのもとになったりユーザの混乱を招いたりしかねない。別の理由として、言語の構文を英語っぽくしようとすると、しばしばその言語の使う「英語」はとんでもなく歪んだ代物になってしまい、これが高じると、そういうわざとらしい自然言語との類似は伝統的な構文と同じくらい混乱をまねくことになる（これはいろんな通称4GLや商業データベースキュエリー言語で見かける）。 　フェッチメールの制御構文は、どうやらこういう問題を免れている。それは、言語ドメインがすごく制限されているからだ。汎用言語にはほど遠い。それが表現していることは、とにかく大して複雑ではないので、英語の小さなサブセットと実際の制御言語の間を行き来するのに、精神的な混乱を起こす可能性があまりない。ここにはもっと広い教訓があるかもしれない。 【教訓16】自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。 　別の教訓は、隠すことでセキュリティを高めるという点についてのものだった。フェッチメールユーザの一部は、ソフトの仕様を変えて、パスワードを暗号化してrcファイルに保存するようにしてくれと要求してきた。のぞき屋たちが気軽にそれをのぞいたりできないようにしてほしいから、と言って。 　これはやらなかった。これでは実は、セキュリティはぜんぜん高まらないからだ。rcファイルを読む許可を与えられている人間なら、だれでもフェッチメールをどのみちあなたと同じように好き勝手に動かせてしまうんだから――そしてそいつがあなたのパスワード目当てなら、フェッチメールのコードそのものから必要なデコーダをぬきだして、ファイルを解読して盗むことができてしまう。 　だから.fetchmailrcパスワード暗号化なんかしても、ものごとをつきつめて考えない人たちに、セキュリティが高まったかのようなまちがった幻想を与えるだけだ。ここでの一般原則は以下の通り…… 【教訓17】セキュリティシステムのセキュリティは、そこで使われてる秘密の安全性にかかっている。見かけだけの秘密は要注意。 　　バザール方式の前提条件とは 　この論文の初期レビューアーや、試験読者たちがたえず返してきた質問というのは、上手なバザール形式の開発に必要な条件は何か、というものだった。これはプロジェクトリーダーの資質と、共同開発者コミュニティをつくろうとしてコードを公開する時点での、コードの状態についての条件の両方についてのものだった。 　バザール形式で最初からコードを書くのが無理だというのは、まあはっきりしているだろう。[IN]バザール形式でテストしたりデバッグしたり改善したりはできるけれど、プロジェクトを最初からバザール式で始めるのは［＃「最初からバザール式で始めるのは」に傍点］すごくむずかしいだろう。リーヌスはそんなことはしなかったし、ぼくもしなかった。あなたが生み出そうとしてる開発者コミュニティは、いじるために何か動いてテストできるものを必要としているんだ。 　コミュニティ形成を始めるときには、まずなによりも実現できそうな見込み［＃「実現できそうな見込み」に傍点］を示せなきゃならない。別にそのソフトは特によく書けてなくてもいい。雑で、バグだらけで、不完全で、ドキュメント皆無でもいい。でも絶対不可欠なのが、開発者候補たちに、それが目に見える将来にはなにか本当に使える代物に発展させられると説得できることだ。 　リナックスとフェッチメールは、どちらも強力で魅力的な基本デザインをもって公開された。ぼくが提出したバザールモデルについて考えてきた人の多くは、これがきわめて重要だということを正しく認識し、そこからいきなり、だったらプロジェクトリーダーには高度なデザイン上の直感と才能が必要にちがいないという結論に一足飛びにとびついてしまった。 　でもリーヌスはデザインをユニックスからもらってる。ぼくはもともと先祖のPOPメールからアイデアを得てる（もっともそれは後に大きく変わった。割合から言えばリナックスよりはずっと大きな変化だ）。ということは、バザール形式のリーダーやコーディネーターはずばぬけたデザインの才能が本当にいるんだろうか、それとも他人のデザインの才能をうまく生かすだけでやっていけるんだろうか。 　コーディネーターが、とてつもないデザイン上のひらめきを自分で得る必要性は必ずしもないと思う。でも、絶対に必要なのは、その人物がほかの人たちのよいデザイン上のアイデアを認識できる［＃「ほかの人たちのよいデザイン上のアイデアを認識できる」に傍点］ということだ。 　リナックスもフェッチメールも、この証拠を示している。リーヌスは（すでに述べた通り）、驚異的に独創的な設計者ではないけれど、よいデザインを認識してそれをリナックスカーネルに組み込む強力な第六感を示した。そしてすでに述べたように、フェッチメール最大の強力なデザインアイデア（SMTP転送）は他人にもらったものだった。 　この論文を早い時期に読んだ人たちは、おまえはバザールプロジェクトでのデザイン上の独創性を過小評価している、自分にはいろいろアイデアがあるもんだから、それが当然のことだと思ってるんだろう、と誉めてくれた。確かにこれは一理ある。ぼくの最大の強みは確かに、コーディングやデバッグではなく、デザイン能力にある。 　でもソフトの設計で、小利口で独創的になることの問題点は、それが習慣になってしまうことだ。ソフトは堅牢でシンプルにしておかなきゃダメなのに、反射的にそれを媚びた複雑なものにしてしまいがちになる。このまちがいのおかげでつぶれたプロジェクトもいくつかある。でも、フェッチメールではそういうことにならずにすんだ。 　だからフェッチメールプロジェクトが成功したのは、一部はぼくが小利口になりがちな自分の性格を抑えたからだと思う。これは（少なくとも）バザールプロジェクトの成功にデザイン上の独創性が不可欠という議論の反証になっている。そしてリナックスもそうだ。もしリーヌス・トーヴァルズが開発途上で根本的なOSデザインの革新をやってのけようとしていたら、その結果のカーネルがいまのものほど安定してうまくいっていたかどうか？ 　一定レベルのデザインとコード書き能力は必要だけれど、でもバザール式のプロジェクトを始めようかと真剣に考えている人なら、ほとんどだれでもそんな最低限以上の能力はあるだろう。フリーソフトやオープンソースコミュニティ内における評判の市場は、最後まで面倒を見られないような開発プロジェクトを始めないように、みんなに微妙な圧力をかける。いまのところ、これはなかなかうまく機能してきたようだ。 　別の才能で、ソフト開発とはふつうは関連づけられないけれど、でもバザールプロジェクトではデザイン上の才覚に匹敵するほど――あるいはそれ以上――重要なものがあると思う。バザールプロジェクトは、コーディネータやリーダの対人能力やコミュニケーション能力が優れていないとダメだ。 　これは説明するまでもないだろう。開発コミュニティをつくるには、人を引きつける必要がある。自分のやっていることに興味を持たせて、各人のやっている仕事量についてみんなが満足しているように気を配る必要がある。技術的な先進性は、これを実現する役にはおおいに立つけれど、でもそれだけではぜんぜん足りない。その人が発する個性も大事だ。 　リーヌスがナイスガイで、みんなかれを気に入って手伝いたくなってしまうのは、偶然ではない。ぼくがエネルギッシュで外向的で、大人数を動かすのが好きで、コメディアンの話術や本能をちょっと備えているのも偶然じゃない。バザールモデルが機能するためには、人を魅了する能力が少しくらいでもあると、きわめて役に立つのだ。 　　フリーソフトの社会的な意義 　これはもう不動の真実だ。最高のハックは、作者の日常的な問題に対する個人的な解決策として始まる。そしてその問題が、実は多数のユーザにも典型的なものであるために広まる。これでルール教訓1の話に戻ってきた。ただしもう少し便利な形で言い直してみよう。 【教訓18】おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。 　カール・ハリスとかれのかつてのPOPクライアントもそうだったし、ぼくのフェッチメールもそうだ。でもこれは長いこと理解されてきた。おもしろい点、つまりリナックスとフェッチメールの歴史がぼくたちの目をいやでも向ける点は、次の段階だ――ユーザと共同開発者たちの巨大で活発なコミュニティがある中で、ソフトがどう発展するかという話。 　『人月の神話』でフレデリック・P・ブルックスはプログラマの時間が代替不能だと看破《かんぱ》している。遅れているソフト開発に開発者を加えても、開発はかえって遅れる。プロジェクトの複雑さとコミュニケーションコストは、開発者数の二乗で増大するのに対し、終わる作業は直線的にしか増加しないというのがかれの議論だった。この論はそれ以来「ブルックスの法則」と呼ばれるに至り、真実をついているものとだれもが考えている。でもブルックスの法則が唯一無二の真理なら、リナックスはあり得なかっただろう。 　数年後、ジェラルド・ワインバーグの古典『プログラミングの心理学』が、いまにして思えばブルックスに対する重要な訂正だったものを提供してくれた。「エゴのないプログラミング」を論じるなかでワインバーグが述べたのは、開発者たちが自分のコードを私物化せず、ほかのみんなにバグを探したり改良点を見つけたりするよう奨励するようなところでは、ソフトの改善がほかよりも劇的にはやく生じる、ということだった。 　ワインバーグの分析がしかるべき評価を得なかったのは、用語のせいかもしれない――インターネットのハッカーたちを「エゴがない」と呼ぶなんて、つい笑ってしまうではないの。でも、かれの議論は今やかつてない説得力を持っている。 　ユニックスの歴史を見れば、リナックスから学びつつあるもの（そしてぼくが意図的にリーヌスの手法を真似ることで、実験的に小規模に確認したもの [EGCS]）は見えていたはずなんだ。コーディングは基本的に孤独な活動だけれど、真に偉大なハックはコミュニティ全体の関心と能力を動員することで実現されるってこと。閉ざされたプロジェクトの中で、自分の脳味噌だけを使う開発者は、オープンで発展的な文脈をつくりだして、デザイン空間の探索やコードの貢献、バグつぶしなどの改善をもたらすフィードバックが何百人も（あるいは何千人も）から戻ってくるようにできる開発者に負けてしまうんだ。 　でも従来のユニックスの世界は、このアプローチをとことんまでつきつめることができなかった。要因はいくつかある。1つはいろいろなライセンスや商売上の秘密、商業的な利害からくる法律上の制約。そしてもう1つは（いまにして思えば）インターネットがまだ発達しきってなかったことだ。 　安いインターネット以前には、いくつかの地理的に集中したコミュニティではワインバーグの「エゴのない」プログラミングが奨励されていた。そこでは開発者は、有能なチェック屋や共同開発者を楽にたくさん集めることができた。ベル研、MIT、AI研、カリフォルニア大学バークレー校――こういうところは伝説的な技術革新を生み出したし、いまでも強力だ。 　リナックスは、意識的かつ成功裏に全世界を才能プールとして使おうとした最初のプロジェクトだった。リナックス形成期が、WWW（World Wide Web）の誕生と同時期なのは偶然ではないと思うし、リナックスが幼年期を脱したのが1993から1994年という、ISP産業がテイクオフしてインターネットへの一般の関心が爆発的に高まった時期と同じなのも偶然ではないだろう。リーヌスは、拡大するインターネットが可能にした新しいルールにしたがって活動する方法を見いだした、最初の人間だったわけだ。 　安いインターネットは、リナックスモデルの発展にとっての必要条件ではあったけれど、でもそれだけでは十分条件ではなかったと思う。もう1つの重要な要素は、開発者が共同開発者を集めて、インターネットというメディアを最大限に活かすためのリーダーシップのスタイルと、協力のための慣行《かんこう》が開発されたことだろう。 　でもこのリーダーシップのスタイルとはなんで、その慣行ってのはどういうものだったんだろう。これは権力関係に基づくものではあり得ない――あり得たとしても、脅しによるリーダーシップは、いまぼくたちが目にするような結果を生み出しはしない。ワインバーグは、19世紀ロシアのアナキストであるクロポトキンの『ある革命家の回想』を引用して、この点についていい議論を展開している。 　「農奴を所有する一家に育ったわたしは、当時の若者たちみんなと同じように、命令したり指令したり、叱りつけたり罰したりといった行動の必要性について、まったく疑うことを知らぬままに成年に達した。しかしかなりはやい時期に、わたしは大がかりな企業を経営することになり、自由な人々と交渉することになった。そしてまちがい1つが重大な結果を招くような状況で、わたしは命令と規律という原理にしたがって活動するのと、共通の理解という原理に基づいて行動するのとの差をだんだん理解するに至った。前者は軍隊のパレードでは見事に機能するが、実生活において、目標が多くの重なり合う意志の真剣な努力によってしか達成できないような状況では何の価値もない」 　この「多くの重なり合う意志による真剣な努力」は、まさにリナックスのようなプロジェクトには必須――そして「命令という原理」は、ぼくたちがインターネットと呼ぶアナキスト天国のボランティアたちに対しては、実質的に適用不可能だ。効果的に活動して競争するには、共同プロジェクトを仕切りたいハッカーは、クロポトキンが「理解の原理」で漠然と示唆しているモードを使い、有益なコミュニティをリクルートしてやる気を起こさせる方法を学ばなくてはならない。つまり、リーヌスの法則を学ばなくてはならないんだ。[SP] 　前にリーヌスの法則の説明として「デルファイ効果」が考えられると述べた。でも、生物学や経済学に見られる適応型システムも、アナロジーとして強力だし魅力もある。リナックスの世界はいろんな意味で、自由市場や生態系のような動きを見せる。自己中心的なエージェントがそれぞれ効用を最大化しようとして、その過程で自己調整的な自律的秩序を生み出し、それはどんな中央集権計画の何倍も複雑で効率が高くなる。だからこここそが「理解の原理」を探すべき場所だ。 　リナックスハッカーたちが最大化している「効用関数」は、古典経済的なものではなく、自分のエゴの満足とハッカー社会での評判という無形のものだ（かれらの動機を「愛他《あいた》精神」と呼ぶ人もいるけれど、でもそれは、愛他家にとっての愛他活動はそれ自体が一種のエゴの満足だという事実を見落としている）。こういう形で機能するボランタリー文化は、実はそんなに珍しいものじゃない。ぼくが長いこと参加してきたもう1つの例は、SFファンダムで、ここはハッカー界とちがってボランティア活動の基本的な動機をはっきり「エゴブー」（他のファンたちの間で自分の評判を高めること）だと認識している。 　リーヌスは、開発そのものはほとんど他人にやらせつつ、うまいこと自分はプロジェクトの門番におさまった。そしてプロジェクトへの関心を育てて、それが自立するようにしてきた。これはクロポトキンの「共通の理解という原理」の鋭い把握《はあく》を示している。このようにリナックスの世界を準経済学的に見てやると、その理解がどのように適用されているか見て取れるだろう。 　リーヌスのやり方は、「エゴブー」の効率的な市場をつくりだす方法として見るといいかもしれない。個々のハッカーたちの利己性を、協力体制を維持しないと実現不可能なむずかしい目標に、できるだけしっかり結びつける方法だ。フェッチメールプロジェクトで、ぼくは（もっと小規模にではあるけれど）かれの手法が再現できるものだということを示した。ぼくの方が、リーヌスよりもそれをちょっと意識的かつ体系的に行ったとはいえるかもしれない。 　多くの人（特に政治的な理由で自由市場を信用しない人たち）は、自己中心的なエゴイストの文化なんか断片的で、領土争いばかりで、無駄が多く、秘密主義的で、攻撃的にちがいないと考える。でもこの予想ははっきりと反証《はんしょう》できる。数多い例の1つをあげると、リナックス関連文書の驚くべき多様性と品質と詳細さがある。プログラマたちはドキュメント作成が大嫌いというのは、ほとんど神聖化された周知の事実とされている。だったら、なぜリナックスハッカーたちはこんなにもたくさんの文書を生み出すんだろう。明らかにリナックスのエゴブー自由市場は、商業ソフト屋さんのものすごい予算をもらった文書作成業者たちよりも、気高さに満ちた他者をいたわる行動を生み出すうえでうまく機能するわけだ。 　フェッチメールとリナックスカーネルプロジェクトがどちらも示しているのは、ほかの多くのハッカーたちのエゴにきちんとごほうびをあげれば、強力な開発者やコーディネータはインターネットを使って、共同開発者がたくさんいるメリットを享受しつつ、プロジェクトが混乱しきった修羅場に陥って崩壊するのは避けられる、ということだ。というわけで、以下はブルックスの法則に対するぼくの反対提案…… 【教訓19】開発コーディネーターが、最低でもインターネットくらい使えるメディアを持っていて、圧力なしに先導するやりかたを知っている場合には、頭数は1つよりは多いほうが絶対にいい。 　フリーソフト（オープンソース・ソフト）の未来は、ますますリーヌスのやりかたを身につけた人たちのものになっていくと思う。つまり、伽藍を後にしてバザール方式を受け入れる人たちのものだ。これは別に、個人のビジョンと才能がもはやどうでもいいということではない。むしろ、フリーソフトやオープンソースの最先端は、個人のビジョンと才能を出発点としつつも、それをボランタリーな利害や興味コミュニティの構築によって増幅する人々のものだと思う。 　そしてこれは、単に「フリー」ソフト（オープンソース・ソフト）だけの未来像ではないのかも知れない。問題解決にあたって、リナックスコミュニティが動員できるほどの才能プールに太刀打ちできる商業デベロッパは存在しない。フェッチメールに貢献してくれた200人以上を雇える財力を持つようなデベロッパですら、ごくわずかしかいない！ 　もしかすると、最終的にフリーソフトやオープンソース文化が勝利するのは、協力が道徳的に正しいとかソフト「隠匿《いんとく》」が道徳的にまちがってるとかいう理由のためではなく（ちなみに後者については、リーヌスもぼくもそうは思わない）、単に商業ソフトの世界が、ある問題に有能な人々の時間を幾桁も多くそそぎ込めるフリーソフトやオープンソース界と、進化上の軍事競争で張り合えなくなるからかもしれない。 　　マネジメントとマジノ線について 　もともとの「伽藍とバザール」はいまのビジョンで終わっていた――ネットワーク化されたシヤワセな集団プログラマー／アナキストたちが、伝統的な閉鎖ソフトの階級社会を競争でうち負かして圧倒するという。 　かなりの懐疑論《かいぎろん》者は、納得しなかった。そしてかれらの挙げる質問は、まともに相手をするだけの価値がある。バザール議論へのほとんどの反論は、バザール支持者たちは従来のマネジメントが持っている生産性倍増効果を過小評価している、という話にいきつく。 　伝統的な考え方のソフト開発マネージャは、オープンソース世界ではいともあっさりプロジェクトグループが生まれ、姿を変えては消え去っていくので、オープンソース・コミュニティーがどのクローズドソースの開発者集団と比べても、数の上で圧倒的な優位性を持っているというメリットの大部分は消えてしまう、と反論することが多い。かれらの主張では、ソフト開発で重要なのは長期にわたり開発努力が継続することで、顧客が大事な製品に投資を続けてくれると期待できるようにすることなのだ、何人が鍋に骨を投げ込んでそのまま煮立てておこうと、そんなのは関係ない、ということになる。 　この議論には、確かに一理ある。実はぼくも、『魔法のおなべ』で、ソフト生産の鍵となるのは期待将来サービス価値だという考えを展開している。 　でもこの議論にはまた、大きな問題が隠されている。それが暗黙に仮定しているのは、オープンソース開発はそういう継続的な努力を提供できないということだ。ところが実は、従来型のマネジメントが不可欠だと考えるような、インセンティブ構造や組織的なコントロールなんかまったくなしに、きちんと方向性を保って有能な管理者コミュニティをずいぶん長期にわたって維持してきたオープンソースプロジェクトはたくさんある。GNUイーマックスエディタの開発は、その極端で示唆的な例だろう。15年にわたり何百もの貢献者たちの努力を吸収して、統合されたアーキテクチャの方向性を維持してきている。開発者の入れ替わりは激しくて、しかもその間ずっと活動を続けてきたのは、たった1人（開発者）だけだ。クローズドソースのエディタのどれ1つとして、これほどの長寿記録にかなうものはない。 　ここから出てくるのは、伽藍 VS バザール方式の議論とは独立した、従来型のソフト開発マネジメントのメリットに対する疑問だ。もしGNUイーマックスが一貫したアーキテクチャのビジョンを15年も維持できたり、リナックスみたいなOSが同じように8年も、ハードやプラットホームの技術が変わり続ける中で維持できたのなら――そしてもし、ほかにもきちんとしたアーキテクチャを持ったオープンソースのプロジェクトが、5年以上も続いている例があるなら――だったらわれわれとしては、そもそも従来型のマネジメント方式の開発というのは、あれだけすさまじいオーバーヘッドをかけて、いったい何を買っているんだろう、というのを当然聞いてみたくなるわけだ。 　それはまちがいなく、締め切りを信頼できる形で守るということではないし、予算内にきちんとおさめるということでもないし、仕様書をすべて反映させるということでもない。こういう目標の1つでも達成できたら、それは珍しくきちんと「マネジメント」されたプロジェクトだと言っていい。また、プロジェクトの寿命の中で、技術的・経済的な環境変化にもすばやく適応できているとは思えない。この点では、オープンソース・コミュニティのほうがはるかに高い能力を見せてきた（これはたとえば、インターネットの30年にわたり歴史と、独占ネットワーク技術の短い半減期とを比べてみればすぐに確認できる――あるいはマイクロソフト・ウィンドウズの16ビットから32ビットへの移行がえらく高コストだったのにくらべて、同じ頃に同じことをやったリナックスではほとんど何の苦労もなかったことを考えてみるといい。しかもリナックスはインテル専用ではなくて、64ビットのアルファ チップも含む一ダースものハードウェア・プラットホームでそれを実現したんだぜ）。 　伝統的な開発様式で買えるもんだと多くの人が考えているものとしては、プロジェクトがおかしくなったときに、法的に縛って責任をおわせ、可能性としては損害賠償金も得る相手ができる、ということだ。でもこんなのは幻想でしかない。ほとんどのソフトライセンスは、このソフトが商品として売り物になることすら保証しないような免責条項が書かれているし、まして性能のことなんかまるっきり保証しない――そしてソフトが期待性能に達しない場合に、損害賠償を勝ち取れたケースがあるか？　まったくないといっていいくらい、ほとんどない。そしてそれがそんなに珍しいことでなかったとしても、訴える相手がいるから安心なんていうのは、そもそもがピントはずれだ。きみは訴訟がしたかったのか？　ちゃんと動くソフトがほしかったんだろうに。 　じゃあ、マネジメントのオーバーヘッドをあんなにかけて、いったい何が手に入るんだろう。 　これを理解するには、ソフトウェアの開発マネージャたちが何をしているつもりなのかを理解しなくてはならない。ぼくの知り合いで、この仕事がとても上手らしき女性に言わせると、ソフトウェアプロジェクトのマネジメントというのは5つの機能がある。 (1)目標を決めて、みんなを同じ方向に向かせておく。 (2)しっかり見張って、大事な細部が見落とされないよう確かめる。 (3)みんなのやる気を出させて、つまらないけれど必要などた作業をやらせる。 (4)メンバーの配置を組織化して、最大の生産性をあげるようにする。 (5)プロジェクトの維持に必要なリソースをひっぱってくる。 　一見どれも立派な目標だ。1つ残らず。でもオープンソースモデルと、それをとりまく環境の中では、どれも不思議なくらいどうでもよく思えてくる。ケツのほうから撃退していこうか。 　この友人の報告では、リソース調達のかなりの部分は、実は手持ちの防衛なんだという。自分のスタッフとマシンとオフィスを確保したら、同じリソースを求めて競合している同僚のマネージャたちや、限られたプールの最有効利用を目指して配置を考えている上司たちから、それを守らなくてはならない。 　でもオープンソース開発者たちはボランティアだし、自分のかかわるプロジェクトについて、興味と能力で自薦により貢献することなったわけだ（そしてこれは、オープンソースのハッキングで給料をもらうようになったときにもおおむねあてはまる）。ボランティアの精神は、リソース調達の「攻撃」側の面倒をみてくれる。みんな自主的に自分のリソースを提供してくれるんだ。そして、伝統的な意味でマネージャが「防御」する必要性は、ほとんど、いやまったくない。 　どのみち、安いPCや高速インターネット接続の世界では、限られている唯一のリソースというのは、才能ある人々の関心だけだ。オープンソースプロジェクトは、つぶれるときにも、別にマシンやリンクやオフィスが足りないからつぶれるんじゃない。開発者自身が関心を失ったからという、それだけだ。 　そういうことなら、オープンソースのハッカーたちが、自薦によって最大の生産性をあげるべく自ら組織化するというのは、二重の意味で大事になる――そしてハッカー界の社会理念によって、有能な者だけが容赦なく選ばれる。ぼくの友だちは、オープンソース界と巨大閉鎖プロジェクトとの両方を知っていて、オープンソースが成功した理由の一部は、その文化がプログラミング人口のトップ5％しか受け入れないからだ、と信じている。彼女は、残り95％の動員を組織するのに時間を費やしている。そして、最高のプログラマと、単に有能なだけのプログラマとの 100倍もの生産性のちがいというのを、直接見せつけられているのだ。 　この生産性の差は、居心地の悪い質問をずっと投げかけ続けてきた。ということはだよ、ソフトの個別プロジェクトや、ソフト産業全体として見ても、使えない下半分を切り捨てたほうがずっとよくなるんじゃないだろうか。もし伝統的なソフト管理の唯一の機能が、一番使えないやつらを、せめて損害は出さずにトントンに持っていくくらいだとしたら、そんな仕事は何の価値もないんじゃないかということを、有能なマネージャたちは昔から理解していた。 　オープンソース・コミュニティの成功は、この質問をもっともっと尖鋭化する。インターネットで自薦のボランティアをつのったほうが、ほかのことをしていたい人たちをビルいっぱい集めて管理するよりも安くて効率がいいことが多いという、動かしがたい証拠をつきつけているからだ。 　というところで、話は都合よく動機づけのほうにやってきた。友人の論点と同じことを別の言い方で言っているのをよく聞く。伝統的な開発マネジメントは、そのままではいい仕事をしてくれない、やる気のないプログラマたちを補うためのものなんだ、と。 　この答はまた、オープンソースは「セクシー」で技術的に魅力ある仕事でしかあてにならない、という議論とセットになっていることが多い。それ以外のことは、放っておかれるままだ（あるいはいい加減にしか処理されない）。それをやるには、札束でひっぱたかれて、区画に閉じこめられた日雇いプログラマが、頭上でマネージャのふりまわす鞭の響きをききつつ必死で書くしかない、というわけだ。ぼくは、こういう主張がまゆつばだと思う理由について『ノウアスフィアの開墾』で述べた。でもこの文の趣旨からして、これを本当として受け入れたらどういうことになるかを指摘するほうが、もっとおもしろいだろう。 　もし従来型のクローズドソースでマネジメント過大のソフト開発スタイルが、退屈からくる問題でつくったマジノ線によってしか弁護できないのならば、その議論が成立するのは、それぞれのアプリケーション領域で、だれもその問題を本気で面白いとは思わないし、さらに他にだれもその問題の抜け道を見つけない場合に限られる。「退屈」なソフトにオープンソースの競合がでてきた瞬間に、顧客たちは、その問題自体が面白いから解決してやろうという人物が、それに取り組んでいるんだな、というのがわかるわけだ――そしておもしろさというのは、ソフトに限らずあらゆるクリエイティブな仕事に言えることだけれど、ただのお金なんかよりもずっとずっと優れたニンジンなんだ。 　伝統的なマネジメント構造を、みんなの尻を叩くためだけに持っておくというのは、戦術的には優れていても、戦略的にはダメだ。短期的には成功しても、長期的にはまちがいなく負ける。 　いまのところ、伝統的な開発マネジメントは2つの点（リソースの調達と、組織）で、オープンソースに対して勝ち目がなさそうに見える。そして3番目の点（動機づけ）でも、先は短そうだ。さらにあわれな包囲された伝統的マネージャは、監督面でも点をあげられない。オープンソースコミュニティを支持する最強の議論が、分散化された同業者レビューシステムが、細部の見落としがないようにするための従来型のあらゆる方式など足下にも及ばないほど優秀だ、ということなんだから。 　じゃあ、伝統的なソフトプロジェクト管理のオーバーヘッドを正当化するのに、目標設定というのくらいは救ってやれるかな？　かもね。でも、そのためには、マネジメント委員会だの企業のロードマップだのが、オープンソース界で似たような役割を果たすプロジェクトごとの「優しき独裁者」や部族の長老に比べて、価値あるみんなに共有される目標を定義するのが上手だ、と信ずべきまともな理由が必要になる。 　こいつを正面きって主張するのは、なかなかにむずかしいことだ。そしてそれがむずかしいのは、オープンソース側がどうのというわけではない（イーマックスの長寿ぶりとか、リーヌス・トーヴァルズが「世界征服」を語って開発者の群《むれ》を蜂起《ほうき》させられるとか）。むしろ、ソフトプロジェクトの目標設定にあたって、伝統的な仕組みがそのタコぶりを遺憾なく証明してきてしまったという点が問題なんだ。 　ソフト工学の、口伝理論でいちばん有名なものとして、伝統的なソフトプロジェクトの60％から75％は、結局完成せずに終わるか、あるいはその予定顧客に拒絶される、というものがある。もしこの数字が多少なりとも真実に近いなら（そして多少なりとも経験あるマネージャで、これを否定する人にはお目にかかったことがない）、たぶん半分以上のプロジェクトは、現実的に達成不可能か、あるいは単純にひたすらまちがっている目標を目指してすすんでいるということになる。 　これは、他のどんな問題にも増して、いまのソフト工学界で「マネジメント委員会」ということばがそれを聞いた者の背中に寒気を走らせる理由なのだ。それを聞いた人が、たとえマネージャであったとしても（いや、マネージャであればこそ、かな）。このパターンについてグチっていたのがプログラマだけだった時代は、とうの昔に過ぎ去っている。「ディルバート」のマンガが、いまでは重役のデスクにだって置かれているのだ。 　すると、伝統的なソフト開発マネージャへのわれわれの答は簡単だ――もしオープンソース・コミュニティが伝統的なマネジメントの価値を過小評価しているというんなら、なぜあなたたちのそんなに多くが、自分自身のプロセスに対して恐怖や恐れや侮蔑を表明しているのでしょうか？ 　またもや、オープンソース・コミュニティの存在がこの質問をかなり尖鋭《せんえい》にしてしまう――ぼくたちは、楽しんでやっているんだもの。ぼくたちの創造的な遊びは、技術面でも、市場シェア面でも、精神的なシェアでも、すさまじい勢いで成功を重ねてきている。ぼくたちは、もっといいソフトがつくれることを示しただけじゃない。よろこびが資産であることを証明してもいるんだ。 　この論文の最初の論文から2年半たって、ぼくが最後に提供できるいちばんラジカルなアイデアというのは、オープンソースが圧勝した世界のビジョンではない。だってそんなものは、いまではスーツ姿のしらふ人間たちにだって、ずいぶん納得のいくものになっているようじゃないか。 　むしろぼくは、ソフトウェア（そしてあらゆる創造的またはプロフェッショナルな仕事）についての、もっと広い教訓をここで提示してみたい。人間は仕事をするとき、それが最適な挑戦ゾーンになっていると、いちばん嬉しい。簡単すぎて退屈でもいけないし、達成不可能なほどむずかしくてもダメだ。シヤワセなプログラマは、使いこなされていないこともなく、どうしようもない目標や、ストレスだらけのプロセスの摩擦でげんなりしていない。楽しみが能率をあげる。 　自分の仕事のプロセスにびくびくゲロゲロ状態で関わり合う（それがつきはなした皮肉なやりかただったとしても）というのは、それ自体が、そのプロセスの失敗を告げるものととらえるべきだ。楽しさ、ユーモア、遊び心は、まさに財産だ。ぼくがさっき、「シヤワセな集団」という表現を使ったのは、別に「シ」の頭韻のためだけじゃないし、リナックスのマスコットがぬくぬくした幼形成熟（ネオテニー）っぽいペンギンなのもただの冗談じゃあない。 　オープンソースの成功のいちばんだいじな影響の1つというのは、いちばん頭のいい仕事の仕方は遊ぶことだということを教えてくれることかもしれない。 　　謝辞 　この論文は、デバッグを手伝ってくれた多数の人々との会話によって改善されてきた。とくに感謝したいのがジェフ・ダツキー。かれは「デバッグは並列処理可能である」という言い方を提案して、そこから生まれる分析の形成を助けてくれた。ナンシー・レボウィッツ（Nancy Lebovitz ）は、クロポトキンを引用してワインバーグをまねしたらどうかと示唆を与えてくれた。ほかに有益なコメントをくれた人としては、「一般技術」（General Technics）メーリングリストのジョン・エスリンガ（Joan Eslinger ）とマーティー・フランツ（Marty Franz ）。グレン・バンデンバーグ（Glen Vandenburg ）は貢献者人口の自己選別性が重要だということを指摘してくれたし、多くの開発というのが「見過ごしというバグ」を修正するものだという有益なアイデアをくれた。ダニエル・アッパー（Daniel Upper ）は、これについて自然界のアナロジーを提供してくれた。PLUG（フィラデルフィアリナックスユーザグループ）のメンバーたちにも感謝する。かれらはこの論文の初の公開版について、最初のテスト読者になってくれた。Paula Matuszek はソフトウェア管理の実務についてぼくを啓蒙してくれた。フィル・ハドソン（Phil Hudson ）は、ハッカー文化の社会組織構成はそのソフトの構成を反映するものであり、その逆も真だということを思い出させてくれた。最後に、リーヌス・トーヴァルズのコメントは有益だったし、かれがはやいうちから賛同してくれたので、ぼくとしてもやりやすかった。 　　もっと考えたい人のための文献リスト 　フレデリック・P・ブルックス（Frederick P. Brooks）の古典『人月の神話――狼人間を撃つ銀の弾はない』（The Mythical Man-Month、アジソン・ウェスレイパブリッシャーズ・ジャパン、1996年）からはあちこち引用させてもらった。 　というのも、かれの洞察はいろいろな意味で、まだまだそのまま通用するものだからだ。アジソン・ウェスレイ（Addison-Wesley）から出ている刊行25周年記念版 （ISBN 0-201-83595-9）を是非ともお奨めする。これにはかれの1986年論文『銀の弾などない』（"No Silver Bullet"、前掲書第16章所収）も収められている。 　この新版の巻末には、非常に有益なブルックスの20年後の回想記がついていて、このなかでブルックスはもとの文章において結果的にまちがっていた部分について、すなおに認めている。ぼくはこの論文をほとんど書き上げたときにこの回想記を読んだのだけれど、ブルックスがバザール式のやり方の例としてマイクロソフトを挙げていたと知ったときにはたまげたね！（ただし実際には、このかれの例示はまちがっていたことがわかった。1998年に、ぼくらは『ハロウィーン文書』によって、マイクロソフト内部の開発者コミュニティはひどい戦国状態にあることを知った。バザールを支えるために必要な、広いソースコードへのアクセスは、実はぜんぜん可能ではないんだ）。 　G・M・ワインバーグ（Gerald M. Weinberg）の『プログラミングの心理学　または、ハイテクノロジーの人間学』（"The Psychology of Computer Programming"、New York, Van Nostrand Reinhold 1971、木村泉他訳、技術評論社、1994年）は、「エゴのないプログラミング」という考え方を導入していて、これは名前のつけかたがまずかったと思う。「命令主義」の不毛さについて認識したのは、かれが最初でもなんでもないけれど、でもそれを特にソフト開発に結びつけて論じたのはたぶんかれが最初だと思う。 　リチャード・P・ガブリエル（Richard P. Gabriel）はリナックス以前の時代のユニックス文化を考察し、1989年の論文"Lisp: Good News, Bad News, and How To Win Big"のなかで、初期のバザール状モデルの優位性を論じている。古びたところもあるけれど、この文章はいまでも リスプファン（ぼくを含め）の間では当然ながら珍重されている。ある人がぼくに、この文のなかの「劣るほうが優秀」という章は、まるでリナックスを予見しているかのように読めることを指摘してくれた。この論文はWWWの で入手可能。 　デ・マルコ（De Marco）とリスター（Lister）の 『ピープルウェア』（"Peopleware: Productive Projects and Teams"、New York; Dorset House, 1987; ISBN 0-932633-05-6、日立ＳＫ訳、日経ＢＰ社、1989年) は知られざる名著で、フレッド・ブルックスが回想記の中で触れているのを見たときは嬉しかった。著者たちの議論のなかで、直接リナックスやフリーソフト（オープンソース）界に適用できるものはあまりないけれど、創造的な作業に必要な条件に関する著者たちの洞察は正確で、バザールモデルの長所をもっと商業的な場に導入したいと試みる人には一読の価値がある。 　最後に、ぼくはこの論文を寸前まで「伽藍とアゴラ」と呼ぶところだったのを白状しておこう。アゴラというのは、ギリシャ語で自由市場や公共集会場所をさすことばだ。マーク・ミラー（Mark Miller）とエリック・ドレクスラー（Eric Drexler）の先駆的な論文『アゴラ的システム』（"The Agoric System"）は、市場状のコンピュータ生態学にあらわれつつある性質を記述していて、5年後にリナックスがぼくをフリーソフト（オープンソース・ソフト）での類似現象に直面させたときも、これを読んでいたおかげで明確にものを考える準備ができていた。この論文はウェブ上の で入手可能。 　　エピローグ：ネットスケープもバザール方式を受け入れる 　自分が歴史の変化に手を貸したと気がつくのは、なんとも奇妙な感じだ……。 　1998年1月22日、ぼくがこの論文を初めて発表してからおよそ7ヶ月後、ネットスケープ社（Netscape Communications, Inc.）がネットスケープ・コミュニケータ（Netscape Communicator）のソースを無料でばらまく計画を発表した。この発表の前日でさえ、こんなことが起こるとはつゆほども知らなかった。 　ネットスケープ社の専務副社長兼技術担当重役のエリック・ハーン（Eric Hahn）が、発表のすぐ後にぼくにメールをくれた。こんな文面だ。「ネットスケープ社全社員を代表して、そもそもこのポイント把握を助けてくれたことに感謝します。あなたの考え方と論文が、われわれの決断にあたって根本的なひらめきを与えてくれました」。 　翌週、ぼくはネットスケープ社の招きでシリコンバレーに飛び、かれらの重役や技術陣との丸1日にわたる戦略会議（1998年2月4日）に出席した。ぼくたちはネットスケープのソース公開戦略とライセンスをつくり、その他、いずれフリーソフト（オープンソース）コミュニティに重大で前向きな影響をもたらすはずの計画をつくりあげた。この執筆時点では、これ以上の詳しい話はまだできないけれど、でも数週間以内に追って詳細が発表されるはずだ。 　この数日後に、ぼくは次のように書いた。 　ネットスケープは大規模な現実世界におけるバザールモデルのテスト機会を提供してくれようとしている。フリーソフト／オープンソース文化は、いま1つの危険に直面していることになる。もしネットスケープのやりくちがうまくいかなければ、フリーソフト／オープンソースの考え方自体がダメなせいだと思われてしまい、商業ソフトの世界はまた10年ほどは手を出そうとしなくなるかもしれない。一方、これはまたとてつもないチャンスでもある。この動きに対するウォール街などでの初期の反応は、慎重ながらも肯定的だった。ぼくたちは自らの力を証明する機会を与えられているのだ。この動きを通じてネットスケープが再び圧倒的な市場シェアを取り戻せば、それをきっかけにもうとっくに起こっていてしかるべきだったコンピュータ産業の革命が動き出すかも知れない。 　この先1年は、非常に示唆的でおもしろい時期になるだろう。 　そして確かに、実におもしろい1年だった。1999年半ば現在では、後に「モジラ（Mozilla）」と名づけられたものの開発はそこそこの成功だとはいえるだろう。ネットスケープのもとの目標は達成した。それは、マイクロソフトにブラウザ市場の独占封じ込めを許さないということだった。さらに劇的な成功もあった（特に次世代レンダリング・エンジンのGeckoのリリース）。 　しかしながら、モジラの創始者たちが願ったような、ネットスケープ外部からのものすごい開発協力は未だに得られていない。ここでの問題はどうも、モジラが長いこと、バザール方式の基本ルールを破っていたことにあるようだ。かれらは、貢献者候補たちがすぐに走らせて動いているのを見られるようなものを出荷しなかった（リリースから1年以上たつまで、モジラをビルドするには、独占モチーフ ライブラリのライセンスが必要だった）。 　いちばんのマイナス点（外部世界から見た場合）は、モジラグループが未だに商品クラスの高品質ブラウザを出荷していないということだろう――そしてプロジェクトの代表者の1人は、マネジメントのまずさと機会喪失について愚痴りつつ辞職することで、いささかの騒動を巻き起こした。かれは正しくもこうコメントしている。「オープンソースは、魔法の砂なんかじゃない」（『辞職と回顧：mozilla.org 顛末《てんまつ》記』）と。 　そりゃそうだ。モジラの長期的な見通しは、いま（1999年8月現在）、ジェイミー・ザビンスキー（Jamie Zawinski）の辞職願の頃よりもかなり改善されてはいる――でも、オープンソースにするだけで、見当ちがいの目標やスパゲッティ・コードや、その他ソフト工学の欠陥に苦しむプロジェクトが救われるわけではない、というかれの指摘は正しい。モジラは、オープンソースがいかにして成功するかという例と、いかにして失敗するかという例を同時に示してくれたわけだ。 　しかし一方では、オープンソースの考え方は、それ以外の場所で成功をおさめ、支持者を見つけてきた。1998年と1999年には、オープンソース開発モデルに対する関心が爆発的に高まった。これはリナックスOSの相変わらずの成功に牽引されたものでもあり、それを牽引するものでもある。モジラが立ち上げた動きは、ますます加速して前進しつつあるのだ。 　　脚注 　[JB]　Programing Pearlsで、有名なコンピュータ科学の警句屋ジョン・ベントレーは、ブルックスの観察についてこうコメントしている。「もし1つ捨てることを予定して置いたら、2つ捨てる結果になるだろう」。かれはほとんど確実にただしい。ブルックスの見解と、べントレーのコメントというのは、単に最初の試みはまちがえやすいから覚悟しろ、ということではない。めちゃくちゃになったのを救うよりは、正しいアイデアで一からやり直すほうが、有効な場合が多い、ということを言いたいのだ。 　[QR]　インターネットに先立つ、成功したオープンソースのバザール形式開発で、しかもユニックスやインターネットの伝統とは関係ないものも存在している。1990から1992年のinfo-Zip圧縮ユーティリティの開発（主にDOSマシン用）はその一例だ。もう1つあるのが、RBBS BBSソフトだ（これまたDOS用）。これは1983年に始まって、なかなか強力なコミュニティが形成され、インターネットの電子メールやファイル共有のほうがローカルのBBSよりもずっと技術的なメリットが高くなった今（1999年半ば）にいたるまで、定期的なリリースを繰り返している。info-ZIPコミュニティはある程度までインターネットの電子メールに頼っていたけれど、RBBS開発者の文化は、RBBS自身を使って相当なオンラインコミュニティを擁し、完全にTCP/IPインフラとは独立していた。 　[JH]　ジョン・ハスラー（John Hasler）は、ある作業が重複してやられたところで、オープンソースの開発にとっては差し引きであまり足をひっぱる結果にはならないと示唆してくれた。かれが提案したものを「ハスラーの法則」と呼ぼう。重複作業のコストは、そのチームのサイズの二乗より少ない――つまり、そういう重複を避けるために必要な、計画やマネジメントのオーバーヘッドに比べて増え方が遅いのだ。 　この主張は、実はブルックスの法則に反するものではない。複雑なオーバーヘッド総額と、バグへの弱さがチームサイズの二乗に比例するのは事実かもしれないけれど、でも重複作業からくるコストは、もっとゆっくりスケールする特殊な例でしかない。これにもっともらしい理由をつけるのは、そんなにむずかしくない。まずは、ほとんどのバグの原因となっている、計画外のよからぬ相互作用を防ぐのに比べれば、開発者のコード同士で機能の仕分けについて話あうのはずっと簡単だという、まちがいのない事実からも説明できる。 　リーヌスの法則とハスラーの法則を組み合わせると、ソフトプロジェクトでサイズの段階が三段階くらいあることがわかる。小規模なプロジェクトでは（つまり開発者が1人からせいぜい3人くらいだろう）、リーダーとなるプログラマを選ぶ以外には、ややこしいマネジメント構造は必要ない。そしてそれを超えた中間くらいのところで、伝統的なマネジメントのコストがそこそこ低くて、作業の重複を避けたり、バグを追跡したり、細かい見落としがないかを調べるためのマネジメントがメリットをもたらすサイズがあるだろう。 　でもそれを超えるとリーヌスの法則とハスラーの法則が組み合わさって、伝統的なマネジメントのコストと問題が、作業重複からの期待トラブルよりも急速に増えるサイズというのが出てくるだろう。このコストのなかでも無視できないのが、「目玉たくさん効果」を導入できないという構造的な問題だ。目玉が多いほうが（これまで見てきたように）伝統的なマネジメントよりも、バグの見落としや細部の見落としに対してはずっと効果的なのだ。だから大規模プロジェクトのケースでは、この二法則の組み合わせのおかげで伝統的なマネジメントのメリットは、ゼロにまで下がってしまう。 　[IN]　バザール方式でゼロからプロジェクトを立ち上げられるかという問題は、バザール方式が真に革新的なものをサポートできるのか、という問題と関係している。ある人に言わせると、強いリーダーシップのないバザールは、エンジニアリングの最先端にすでに存在しているアイデアをまねしたり、改良したりできるだけで、その最先端を先に進めることはできないそうだ。この議論を提出したいちばん悪名高い例が、ハロウィーン文書（原文、翻訳）だろう。オープンソース現象について書かれた、マイクロソフトの恥ずかしい社内メモだ。この著者たちは、リナックスがユニックスに似たOSを開発するのを「テールライトを追いかける」と例えてくれて、「（そのプロジェクトがひとたび技術の最先端の「飽和点」に達してしまえば）、新たなフロンティアに向けてみんなを押し進めるために必要となるマネジメントのレベルはとてつもないものとなる」と論じている。 　この議論には、深刻な事実関係のまちがいが含まれている。その1つは、ハロウィーン文書の著者たち自らが次のように洞察しているところではっきり表明されている。 　「具体的にはこれは、新しい研究上のアイデアはまずリナックス上で実装されて入手可能となり、その後でほかのプラットホームで提供されたり組み込まれたりするようになる、ということだ」 　ここでリナックスを「オープンソース」と読み替えれば、これがまるで目新しい現象でないことはわかるだろう。歴史的に、オープンソース・コミュニティがイーマックスやWWWやインターネットを発明したのは、テールライトを追っかけたり、とてつもないレベルのマネジメントがあったりしたためではない――そしていまでも、オープンソースではとても多くの独創的な仕事が続いていて、選ぶのに目移りするほどだ。あえて1つ選ぶとすると、GNOMEプロジェクトはGUIとオブジェクト技術の最先端を押し広げていて、リナックスとはかけ離れたコンピュータ業界紙からも大いに注目されている。その他の例も目白押しで、これはいつでもいいからFreshmeatを訪ねてみればすぐに証明される。 　でも、伽藍方式が（あるいはバザール方式でも、その他どんなマネジメント方式でもいい）、なにやら技術革新を信頼できるかたちで生じさせられるという、暗黙の仮定にはもっと根本的なまちがいがある。だって、そんなのナンセンスだからだ。群衆は、突破口となるような洞察なんか持てない――バザール方式のアナキストたちによるボランティア集団でさえ、まともなオリジナリティは発揮できないし、ましてやなにか現状に生存が係っているような人々からなる、企業委員会なんかからそんなものは絶対に出てきやしない。洞察は個人からくる。それをとりまく社会機構としてせいぜい期待できるのは、その突破口となる思いつきに対して敏感に反応することくらいだ――それをつぶすのではなく、ちゃんと育てて報酬を与え、きちんとテストしてやることだ。 　これをロマンチックな見方だと決めつける人もいるだろう。孤独な発明家というステロタイプに逆戻りしている、と。ちがうね。ぼくは別に、いったん生まれた突破口となる洞察をグループが育てられないなんて言ってるわけではない。それどころか、ピアレビューのプロセスから学ぶのは、こうした開発グループこそが高品質の結果を生み出すために不可欠だということだ。むしろぼくが指摘しているのは、そういうグループ開発もすべて出発点は――つまり、それに火をつけるのは必ず――だれか1人が思いついた、いいアイデア1つなんだ、ということだ。伽藍やバザールなんかの社会的な機構は、その火花をつかまえて洗練させることができるけれど、でもその機構が命令して着想を生み出したりはできないんだ。 　だから、技術革新の根本問題（これはソフトウェアに限らずあらゆるところで）というのは、そのアイデアをどうやってつぶさずにおくか、ということだ――でも、もっと根本的には、そもそも洞察を持てるような人たちをたくさん育てるにはどうしたらいいか、ということだ。 　伽藍方式の開発がこいつを実現できて、参入障壁が低い、プロセスの流動的なバザールではこれができないと仮定するのはバカげている。もしたった1人のたった1つのアイデアでいいなら、1人の人間がそのいいアイデアで、何百、何千という人々の協力をすぐに集められる社会方式のほうが、クビになる心配なしにそのアイデアに基づく作業ができるようになるために、階級機構に対して政治的な売り込みをしなくてはならないようなシステムに比べて、革新は早いに決まっている。 　そして実際に、伽藍方式を使った組織によるソフトの技術革新の歴史を見てみると、あまり数がないことがすぐにわかる。巨大企業は新しいアイデアの源として大学の研究に頼っている（だからこそハロウィーン文書の著者たちは、リナックスがその研究成果をずっとはやく取り入れられるということに危機意識を見せている）。あるいは、革新者の頭脳を中心に生まれた小企業を買収するだろう。いずれの場合にも、伽藍文化には技術革新は根付いていない。それどころか、そうやって輸入された技術革新の多くは、ハロウィーン文書の著者たちがあんなに持ち上げる「とてつもないレベルのマネジメント」によって、静かに窒息させられてしまう結果となる。 　これはでも、否定的なポイントだ。読者のみんなは、もっと肯定的な論点のほうが役にたつだろう。試しに、以下のような実験をしてみたらどうだろう。 (1)一貫性を持って適用できると思うような、オリジナリティをはかる尺度を選ぶこと。きみの定義が「オリジナリティなんて見りゃわかる」というものであっても、このテストでは問題にはならない。 (2)リナックスと競合しているクローズドソースのOSをどれでもいいから選んで、そのOS上で進行中の開発作業を記述した最高の情報源を選ぶこと。 (3)その情報源とFreshmeatを1ヶ月眺めること。毎日、「オリジナル」な仕事だと思われるリリースの発表の数を数えること。「オリジナル」の定義をその別のOSにも適用して、その数を数える。 (4)30日たったら、両方の数字をそれぞれ合計。 　これを書いた日だと、Freshmeatはリリースのアナウンス22件があって、そのうち3つは何らかの形で最先端をさらに先へ進めるようなものだった。この日のFreshmeatは低調だったけれど、でもクローズドソースのどんなプロジェクトでも、ものになりそうな技術革新が一月3つもあったら驚嘆しちゃうね。 　[EGCS]　いまや、いくつかの意味でフェッチメールよりもバザール方式の実例として好都合なプロジェクトの歴史が手に入った。それがEGCS、gccの高速版であるExperimental GNU Compiler Systemだ。 　このプロジェクトは1997年半ばに、この「伽藍とバザール」初期公開版に登場したアイデアを意識的に適用してみようという試みとしてはじまった。プロジェクトの創始者たちは、GCC（GNU Cコンパイラ）の開発が停滞していると感じていた。そしてそれ以降20ヶ月にわたり、GCCとEGCSは並行したプロジェクトとして続いていた――どちらも同じインターネット開発人口から人材を集め、どちらも同じGCCのソースべースから出発してるし、どちらもだいたい同じユニックスツールセットと開発環境から始めている。両プロジェクトの唯一のちがいは、EGCSが意識的に、ぼくがこれまでに記述してきたバザール戦術を用い、それに対してGCCの方は、閉じた開発者グループとめったにないリリースとでもっと伽藍的な開発方式を続けたということだった。 　これは、対照実験にいちばん近いものといっていい。そして結果は劇的だった。数ヶ月のうちに、EGCSのバージョンは、機能面ではるかにGCCを引き離した。最適化も向上していて、フォートラン（FORTRAN）とシープラプラ（C++）のサポートも優れていた。多くの人は、EGCSの開発途上スナップショットのほうが、GCC最新安定版より信頼性が高いと判断しており、主要リナックスディストリビューションもEGCSに移行しはじめた。 　1999年4月には、フリーソフト財団（GCC公式スポンサー）はもとのGCC開発チームを解散して、プロジェクトのコントロールを公式にEGCSステアリング・グループに譲りわたした。 　[SP]　もちろん、クロポトキンの批判とリーヌスの法則は、社会機構のサイバネティクスについてもっと大きな問題を提起している。ソフト工学についての別の口伝理論が、その1つを示している。これはコンウェイの法則と言われる――ふつうの言われ方では、「もしコンパイラをつくるのに4つのグループが作業していたら、できあがるのは4パスコンパイラになる」となる。もとの表現はもっと一般的だった。「システムを設計する組織は、その組織のコミュニケーション構造の複製であるような設計を生み出すように縛られる」というものだ。これをもっと平たくして「手段が目的を決定する」と言ってもいいだろう。あるいは「プロセスこそが成果物となる」とでも。 　したがって、オープンソース・コミュニティでは、組織形態と機能がいろんなレベルで一致していることは頭にいれておいていいだろう。ネットワークがすべてで、いたるところにある。インターネットだけじゃない。みんな分散した、ゆるい結びつきの、ピア・ツー・ピアのネットワークで作業を進めて、それがいくつもの冗長性を生んで、退行のしかたもとても緩やかだ。いずれのネットワークでも、各ノードはほかのノードがそれと協力したがる度合いに応じてのみ重要となる。 　オープンソース・コミュニティのすさまじい生産性には、このピア・ツー・ピアの部分が本当にだいじだ。クロポトキンが力関係について言おうとしていたことは、「SNAFU原理」によってさらに展開されている。その原理とは、「真のコミュニケーションは対等な者同士の間でしか成立しない。なぜなら、劣る者は上位者に耳障りのいいウソを語ったほうが、真実を語るよりも報酬を得る見込みが高いからだ。」創造的なチームワークは、まさに真のコミュニケーションに依存していて、だからそこに権力関係が入り込むと、かなり深刻に足を引っ張られる。オープンソース・コミュニティは、こういう力関係からは実質的に自由で、しかもそういう力関係がバグや機会損失という面でどんなに高いコストを支払うことになるのか、ということを反面教師的に教えてくれているわけだ。 　さらに、SNAFU原理は権威主義的な組織において、意志決定者たちと現実の間がだんだん乖離《かいり》していくと預言している。というのも、意志決定者の耳に入る入力は、ますます耳障りのいいウソばかりになってくるからだ。これが従来のソフト開発でどう効いてくるかというのは、すぐにわかる。下位の者たちには、問題を隠し、無視して、過小評価する強いインセンティブがある。このプロセスが製品となったら、ソフトウェアは悲惨なことになる。 　　バージョンと変更履歴 　バージョン1.16: 1997年 5月21日、Linux Kongressにて発表。 　バージョン1.20: 1997年 7月 7日、文献リストを追加。 　バージョン1.27: 1997年11月18日、Perl会議での逸話を追加。 　バージョン1.29: 1998年 2月 9日、「フリーソフト」を「オープンソース」に変更（「オープンソース」という用語はまだ日本語として普及していないと判断して、翻訳では併記している）。 　バージョン1.31: 1998年 2月10日、「エピローグ：ネットスケープもバザール方式を受け入れる」の章を追加。 　バージョン1.4 : 1998年 7月28日にRMSから強力な意見をもらったのを受けて、Paul EggartによるGPL vs バザール方式に関する見解を削除。ハロウィーン文書に基づいてブルックスに訂正を加筆。 　バージョン1.44: 1999年 7月末に、「マネジメントとマジノ線について」、デザイン空間探求のためのバザールの有用性を追加、エピローグの大幅加筆。 　バージョン1.45: 1999年 8月 8日に、Snafu原理について、バザール開発（前）史事例、オリジナリティに関する脚注を追加。 　これ以外の変更は、細かい編集上の変更やマークアップの変更を反映したもの。（翻訳上のミスについて、高瀬俊朗 、山根信二 、白田秀彰 、井上友一 の各氏からご指摘をいただいた。伏して感謝する――訳者記す） YAMAGATA Hiroo