伽藍とバザール #2

僕自身の自己紹介を兼ねて「伽藍とバザール」にまとめられたオープンソース文化から得られた経験則を読んでいます。第二回バザール開催。

伽藍とバザール 19 の教訓　7〜11

7. Release early. Release often. And listen to your customers.
とにかくリリースしよう、頻繁にリリースしよう、そしてユーザーの声を聞こう。

　例えば半年に１回とかのリリースにして、その間、念入りに、ひたすらバグ取りに集中する、というのは確かによくあるリリーススタイルです。オープンソース文化におけるこの経験則はその対極にあります。リーヌスの取り組みは刺激的です。Linux のカーネルの開発というとても難しいタスクを１日に何回もリリースしたのですから。それは、開発者を刺激して知的な報酬を与えていた、つまり自分たちの仕事がほとんど毎日進歩してることを目の当たりにさせるということでした。それによって、一時的に深刻なバグの発生やユーザーを失うリスクを犯してでも、バグ取りにかかるチームの人月を最大化させようとした、そしてあの有名なセリフにつながります。

8.  Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally,  "Given enough eyeballs, all bugs are shallow.'' 
ベータテスターと共同開発者の数が十分大きければ、ほとんどすべての問題はすぐに発見されるし、その直し方も誰かにはきっと明らかだ。もっとくだけた表現で言えばつまり「目玉の数さえ十分なら、どんなバグも大したこと無い」ということ。

オープンソース文化は、開発者コミュニティと切っても切れないものです。いかにチームの力を最大化するか。

このことにはたくさんの教訓が眠っています。まず「バグ」に対しての２つの捉え方が語られています。

伽藍派　バグを外に出すことは恥ずかしいことで、そもそも少数の精鋭が数ヶ月かけて念入りにチェックしないとならないものだ。だからリリースの間隔も開いてしまうし、ユーザーにとっては長く待たされたリリースが完璧じゃないと失望も大きくなる。

バザール派　バグなんて深刻な問題じゃない、頻繁なリリースをたくさんの熱心な共同開発者が叩いてくれれば良いのだから。どんどん直してもらうために、どんどんリリースする。時々やばいヤツが出回っちゃうけど、それで失うものは大したことはない。

広く使われるプログラムをメンテナンスするコストは、開発コストの四割くらいになる。そして不思議なことに、このコストは、利用者が増えれば増えるほど増大するのだ。

利用者が増えることでセキュリティリスクが顕在化する事例というのも、最近でもよくニュースになっています。営利企業がプロプライエタリなクローズドソースソフトウェアを開発する上では、このコストを全て自社で飲み込む覚悟が必要になるということでもあります。大規模で統制された開発チームが、ウォーターフォール型で統制された開発を遂行する、まるで規律の取れた軍隊のような・・・海軍にありながらも、ものぐさ過ぎて失敗できなかったデイヴィッド・ラムの物語が、ここにも重なってくるように感じます。

さて、話は大きく変わります。

9. Smart data structures and dumb code works a lot better than the other way around.
適切なデータ構造とクソコードは、その逆と比べてずっとマシだ

これはもうその通り。何も専門的な難しいデータ構造を知らないとならないとダメということじゃなくて、自分が取り組む課題をどのようにモデル化するか、というときに、どういうデータ構造を使うのが適切だろう？世の中にすでに似たような課題はないかしら？とちょっと一歩立ち止まるだけで良いと思います。データ構造もそうだし、どのようなメッセージングモデルを採用するか、どのようなデザインパターンを採用するか、知っている範囲でできるだけ一般的なアリものを使っていこう！ということ。

　このことはもうひとつ良い効果があります。適切なデータ構造などを採用することで、設計意図が仲間に伝わりやすくなります。仮にその実装がちょっとアレだったとしても、それはきっと仲間が直してくれるでしょう😁

　囲碁の世界に、「下手の考え休むに似たり」という格言があります。対局中に長考することも多いですが、下手なうちは、どれだけ長いこと考えても大した手は思いつかないので、上手い人から見たらまるで休んでいるようなものだ、という、厳しい言葉ですが、囲碁打ちの経験上は否定できない言葉でもあると思います。
　囲碁の上達においては、「定石」を学ぶことが大切です。実際の対局が、知識としての定石通りの展開になることはあまりありませんが、先人たちが試行錯誤して導いてきたパターンを学ぶことを通して、その途中途中にある様々な変化に対応する力を養うことができます。

　良いオープンソースを読むことは、良い定石を学ぶことに近いかも（ここは宣伝かな？😁）。

10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.
ベータテスターこそがあなたが持っている最高のリソースだ、というように振る舞えば、実際にそうなる。

愛されたいなら、まず相手を愛しなさい、ですね。「most valuable resource 」という表現ですが、この「リソース」に含まれる他のリソースとしては、例えば、「時間」や「自分ひとりの工数、もしくは能力」、「自由に使える計算資源」、ちょっと極端ですが「お金」といったものまで、自分個人に紐づくすべてのリソースを含むのではないかと感じます。それらと比較しても、ベータテスターは開発を行う上で重要なリソースであるのだ、と。では、実際にどのように振る舞えばよいのでしょうか？本文にひとつのヒントが示されています。

(1) I released early and often (almost never less often than every ten days; during periods of intense development, once a day).
集中できるときは 1 日に 1 回、遅くとも 10 日を開けずに頻繁にリリースした。

(2) I grew my beta list by adding to it everyone who contacted me about fetchmail.
メールを送ってきてくれた人は分け隔てなく、ベータユーザーのリストに追加した。

(3) I sent chatty announcements to the beta list whenever I released, encouraging people to participate.
リリースするたびに、リリース文を饒舌に書いてベータユーザーに送るんだ。彼／彼女らの参加を促すためにね。

(4) And I listened to my beta-testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.
そしてベータユーザーの声を聞くんだ。設計上の決断についての意見を求めたりもする。フィードバックやパッチを送ってくれるたびに褒めるんだよ。

最初は、「うわ、痛いところをつかれた」と思ってしまうこともあるかもしれません。でもこれは上に紹介した「バグをどう捉えるか？」という意識の問題です。もしくは、チームをエンカレッジするために敢えて褒めるようなこともあるでしょう。まずは形から入るだけでも良いですね。そのうちいつの間にか、それが自然なことになるように感じます。「いやーーー、モヤモヤしてたところがついに超絶スッキリ解決したよ！ありがとう！！！」みたいな。
　まぁ今でも「あああああそれだよー！自分で思いつけなかったのがくやしい！おろかすぎる！」って思っちゃうこともありますけどね 😁

11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
ユーザーが素晴らしいアイディアを提案してくれるから、僕はその意義を理解すればよいだけ。それは良いアイディアを得るための二番目に優れたやり方、一番のときもあるけど。

良いアイディアを得るために一番優れたやり方は、自分で考えること？いや、そうじゃないこともあるよ（むしろそうじゃないことの方が多いかも）、という経験は、開発者であれば誰しもあることではないでしょうか。とはいえ、一度は自分でウンウン悩んだことじゃなければ、提案してくれたアイディアが素晴らしいものであることを理解することすらできないかもしれません。チャンスは備えあるところにのみ訪れるのです。

本文ではさらに面白い逸話が紹介されています。

Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius. We can all see how well this worked for Linus!

(When I gave my talk at the first Perl Conference in August 1997, hacker extraordinaire Larry Wall was in the front row. As I got to the last line above he called out, religious-revival style, ``Tell it, tell it, brother!''. The whole audience laughed, because they knew this had worked for the inventor of Perl, too.)

とても興味深いことに、自分の仕事が他人に負うところがいかに大きいかについて、心の底から謙虚かつ真摯な態度でいたならば、世の中は、その仕事の全てがあなたのもので、単に自分の天才性を謙遜しているだけだとみなしてくれる。これがリーヌスの場合にどれだけ上手く行っているかは、みんなもよーく知っているでしょ！笑

（私がこのことを 1997 年の Perl カンファレンスで話した時、最前列にいた ラリー・ウォールが「言ったれ、もっと言ったれ！」って野次ってきた。会場はもう大爆笑、だってそこにいた連中はみんな、同じことが Perl の発明者として有名なラリーにも当てはまるって知ってたからさ。）

技術の前では皆平等です。優れたアイディアを優れていると正しく認識できるということは幸せなことですね。

引用部のライセンス表示

Copyright © 2000 Eric S. Raymond
Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0.
$Date: 2002/08/02 09:02:14 $