○The Cathedral and the Bazaar(伽藍とバザール)
【教訓１】よいソフトはすべて、開発者の個人的な悩みの解決から始まる。
これは自明なことだろう。昔から「必要は発明の母」と言われてるしね。よ
く考えてみれば世間一般の開発者と呼ばれる人達はお金で横っ腹を叩かれて自
分にとって必要でも、好きでもないソフトを一日中シコシコ書いていることが
あまりにも多いんだ。こんなんじゃ質の高いソフトを開発するのなんて無理だ
よね。一般的にフリーソフトと呼ばれる無償のソフトの中に質が非常に高いソ
フトが存在するのはこのせいだろう。
つねにこう考えるといいのかもね。「ぼくの欲しいものは何？」
【教訓２】なにを書けばいいかがわかっているのがよいプログラマ。なにを書き直せば
（そして使いまわせば）いいかわかってるのが、すごいプログラマ。
―――だからね。すごいプログラマを気取るつもりはないけど、でもその真
似ぐらいはしたい。すごいプログラマの大事な特徴の一つが、建設的な面倒く
さがりってヤツなんだ。評価してもらえるのは結果であって、そのための努力
じゃないってのがわかってるってこと。だから何もできないやつに限ってよく、
「今度、○○を作るんだ」って叫んでいる。しかもそういった人にかぎって、
完成品はたいしたことがない。もっとも、そのうちの大部分の人間は完成でき
ずにいるけどね。だから、何にしても口だけのヤツはたいしたことがない。
一般に白紙から始めるよりは、よくできた部分解から始めたほうがほぼ絶対
に楽。たとえばリーヌスがリナックスをゼロから書き始めずに、ミニックスの
コードやアイディアを再利用するとこから始めた。やがてリナックスのコード
は全部落とされたか、あるいは完全に書き直された。
―――同じ精神から私は約束の地「FreeDOS」に辿りついた。
【教訓３】捨てることをあらかじめ予定しておけ。どうせいやでも捨てることになるんだから
（フレデリック・Ｐ・ブルックス著「人月の神話」第十一章）
私が新しい分野のコードを書く場合、一度目は勉強（研究）用だと考えてい
る。通常新しい分野の開発の場合、全ての資料が整っている場合を除いて思考
錯誤しながらの開発になる。するとしだいにコードの書き方に統一が無くなっ
て行き関数の分割もむちゃくちゃ、配列や #define文の名前もむちゃくちゃに
なってくる。こうなってくると、自分でもバグ取りが困難になっていく。する
と、一から書き直した方が早いような気がしてくる。私の場合、こう思いだし
たら、実際１から書き直した方が早い。どうせ一度理解したことを綺麗に書き
直すんだから、よっぽど巨大なコードでない限り、大抵のコードは１〜数日で
書き直せるしね。
【教訓４】まともな行動をとってれば、おもしろい問題のほうから
こっちを見つけだしてくれる。
でも、カール・ハリスの行動のほうがもっと大事だ。かれが理解していたこと・・・
【教訓５】あるソフトに興味をなくしたら、最後の仕事としてそれを
有能な後継者に引き渡すこと。
これは非常に大切なことだぞ！もしあなたがフリーソフトを開発しているの
なら、これ以上開発するのが嫌だって時は私にソースを渡してくれ、このサイ
トでよりよい後継者を見つけてあげよう。
【教訓６】ユーザを共同開発者として扱うのは、コードの高速改良と効率よい
デバッグの一番楽ちんな方法。
この効力はすごく見落としがち。実は、ぼくらフリーソフト界のほとんどだ
れもが、この効果がユーザの数の増加とともにどれほどすごくなるか、そして、
それがシステムの複雑さに対してどれほど有効に機能するかについて、まった
く見えてなかった。リーヌスが目を開いてくれるまでは。
【教訓７】早めのリリース、ひんぱんなリリース。そして顧客の話しを聞くこと。
リリースは早ければ早いほどいい。どんなバグを含もうが構わない。どんど
ん修正を加えていくことでどんな致命的なバグも取り除ける。ただし、リリー
スのバージョンは安定版と最新版の二つは最低必要だ。安定板とは致命的なバ
グは恐らくないだろうというバージョン（保証しているわけではない）で一般
人が安心して利用できるバージョンだ。しかしこのリリースはもしかすると半
年や一年は更新されないかもしれない。そこでもうひとつ用意するのが、最新
版だこれはどんな致命的なバグが含まれているか分からないが、最新の技術を
使用することができるバージョンだ。もしあなたが、自分のプログラミングの
腕に自信が無くても開発に携わりたいのならこちらを使用して欲しい。そして
思いつく限りのむちゃくちゃな操作をして欲しい。運が良ければ？あなたは未
知のバグを見つけることができるだろう。そしてそれを私達開発者に知らせて
くれれば、それに対して私達は感謝するだろう。
あとαやβバージョンのソースも用意しておくと新たにハッキングしてくれ
る新人を育成するのに役立つだろう。しかし、同じ分野の別プロジェクトを立
ち上げるキッカケとなってしまうので、もしプロジェクト管理者がベータテス
タ等の資源を減らしたくないのなら公開すべきではない。ちなみα、βのソー
ス公開については私が考え中のなので、考えがまとまり次第、別項目にしたい。
【教訓８】ベータテスタと共同開発者の基盤さえ十分に大きければ、ほとんどすべての
問題はすぐに見つけだされて、その直し方もだれかにはすぐわかるはず。
これも自明なことだ。１００人いれば１００通りの使われ方があるだろう。
しかしそのうちの数人はすぐに不満を漏らすだろう。「マシンが止まった」っ
てね。その不満を聞いた別の人は、何かの研究からその解決策をすでに知って
いるかもしれない。そうすれば数日中に最新版がリリースされるだろう。
【教訓９】賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。
（フレデリック・Ｐ・ブルックス著「人月の神話」第十一章）
間抜けなコードは直しようがあるけど、間抜けなデータ構造は構造自体もコー
ドと一緒に修正しなきゃならないしね。面倒だなぁ。
【教訓10】ベータテスタをすごく大事な資源であるかのように扱えば、向こうも実際に
大事な資源となることで報いてくれる。
これはあたりまえだ。だってベータテスタも、ネットワークの向こう側では
一人の人間として暮らしているのだから。大切な仲間として扱ってやれば、大
抵はすばらしい働きをしてくれる。しかしこれは本当にすばらしいことだな。
【教訓11】いいアイデアを思いつく次善の策は、ユーザからのいいアイデアを認識する
ことである。時にはどっちが次善かわからなっかたりする。
はっはっはぁ〜。そんなこともあったっけ。
【教訓12】もっとも衝撃的で革新的な解決策が、異聞の問題のとらえ方が
そもそもまちがっていたという認識からくるということはよくある。
開発で壁にぶちあたったとき―――次のパッチ以降、なにをしたらいいか、
すごく悩んでしまうとき―――というのは、自分が最終的な回答にたどりつい
たのかな、と考えるべき時ではなく、むしろ自分が正しい質問をしているのか
な、と考え直してみるべきであることが多い。ひょっとして、問題を捉えなお
してみる必要があるのかもしれない。
また、真の教訓は？と聞かれれば、古びてきた機能は迷わず捨てること――
―有効性を下げずに捨てられる場合には。
ちなみにアントワーヌ・サンテグジュペリ曰く……
【教訓13】真の「完成」（デザイン上の）とは、付け加えるものがなにもなくなったときではなく、
むしろなにも取り去るものがなくなったとき。
【教訓14】ツールはすべて期待通りの役に立たなきゃダメだが、すごいツールは
まったく予想もしなかったような役に立ってしまう。
【教訓15】ゲートウェイソフトを書くときはいかなる場合でも、データストリーム
への干渉は最低限におさえるように必死で努力すること。
そして受けて側がどうしてもと言わない限り、絶対に情報を捨てないこと！
【教訓16】自分の言語がチューリング的完成から程遠い場合には、
構文上の甘さを許すといろいろ楽になるかもね。
別の教訓は、隠すことでセキュリティを高めるという点についてのものだっ
た。何らかのファイル（例えばメール）なんかをパスワードで暗号化なんかし
ても、ものごとをつきつめて考えていない人たちに、セキュリティが高まった
かのようなまちがった幻想をあたえるだけだ。
私ぐらいになれば、暗号をかけるソフトからデコーダを抜き出し、ファイル
を読むなんてお手のものだしね。
ここでの一般原則は以下の通り……
【教訓17】セキュリティシステムのセキュリティは、そこで使われている
秘密の安全性にかかっている。見かけだけの秘密は要注意。
【教訓18】おもしろい問題を解決するには、まず自分にとっておもしろい問題を見つけることから始めよう。
「人月の神話」でフレデリック・Ｐ・ブルックスはプログラマの時間が代替
不能だと看破している。送れているソフト開発に開発者を加えても、開発はか
えって遅れる。プロジェクトの複雑さとコミュニケーションコストは、開発者
数の二乗で増大するのにたいし、終わる作業は直線的にしか増加しないという
のが彼の議論だった。この論はそれ以来「ブルックスの法則」と呼ばれるに至
り、真実をついているとだれもが考えている。でもブルックスの法則が唯一無
二の真理なら、リナックスはありえなかっただろう。数年後、ジェラルド・ワ
インバーグの古典「プログラミングの心理学」が、いまにして思えばブルック
スに対する重要な修正だったものを提供してくれた。「エゴのないプログラミ
ング」を論じるなかでワインバーグが述べたのは、開発者たちが自分のコード
を私物化せず、ほかのみんなにバグを探したり改良点を見つけたりするよう奨
励するようなところでは、ソフトの改善がほかよりも劇的に早く生じる、とい
うことだった。
【教訓19】開発コーディネータが、最低でもインターネットくらい使えるメディアを持っていて、
圧力なしに先導するやり方を知っている場合には、頭数は一つより多いほうが絶対にいい。
フリーソフト（オープンソース・ソフト）の未来は、ますますリーヌスのや
り方を身につけた人たちのものになっていくと思う。つまり、伽藍を後にして
バザール方式を受け入れる人たちのものだ。これは別に、個人のビジョンと才
能がもはやどうでもいいということではない。むしろ、フリーソフトやオープ
ンソースの最先端は、個人のビジョンと才能を出発点としつつも、それをボラ
ンタリーな利害や興味コミュニティの構築によって増幅する人々のものだと思
う。そしてこれは、短に「フリー」ソフト（オープンソース・ソフト）だけの
未来像ではないのかもしれない。万台解決にあたって、リナックスコミュニティ
が動員できるほどの才能プールに太刀打ちを持つようなデベロッパですら、ご
くわずかしかいない！