「伽藍とバザール」について
ってみなさんどれくらい読んでいるんでしょう？
なんとなく、「人月の神話」や「熊とワルツを」、あるいは「エキストリームプログラミング（白本）」のような、プログラミングにおける古典読み物のひとつだと個人的には感じています。
とはいえ、上げた三冊は私も一通り読んでいるのですが、じつは伽藍とバザールは素通りしていました。
なんでかっていうと、これOSSソフトウェア、特にLinuxの開発モデルについて開発した本なんです。こういう古典読み物を読み漁っていた当時としては、あんまり興味を引く題材じゃなかったのですよね。もっぱらプロプライエタリかつオンプレミスなソフトを書き続けていた日々だったので。
安易な人員投入を批判する「人月の神話」や、リスク管理について教えてくれる「熊とワルツを」、アジャイル開発の熱い萌芽を感じる「エクストリームプログラミング」なんかとは、だいぶ違う毛色を感じたんですよね。
Amazonの書籍紹介ページにも「Linux、オープンソース(OSS)関係者必読の書」って書いてあって、もちろんそれは正しいと思うのだけれど、安易に読者を狭め過ぎじゃないのかと思うんですよね。1
特に、今あらゆるものがどんどんオープンになっているこの世の中で、どのようにソフトウェアの開発はあるべきなのか、それを示している書籍になります。
と、書籍と言いましたが、さすがOSSについて書いた本です。書籍、及び翻訳自体もクリエイティブ・コモンズのもとにOSSとなっています。
実は書籍版は、上記に加え「ノウアスフィアの開墾」と「魔法のおなべ」、あとは訳者の山形センセイによるインタビューなんかもセットになっていますが、今回取り上げるのは「伽藍とバザール」までです。そこまでで十分面白いので、未読の方は是非。PDFで40ページほどととっても読みやすい分量となっております。
「伽藍とバザール」のメタファの誤解
ちょっと伽藍とバザールのことを知っているなら、あるいはOSSと大企業（窓の会社とか青い会社とか赤い会社とか）との戦いの歴史を知っている人なら、「伽藍」とは大企業手動によるプロプライエタリでクローズドな開発のことを、そしてバザールとはOSSによる自由なソフトウェア開発のことを指している、と考えるでしょう。
そう思っている人こそ、読んでもらいたいです。なぜなら 伽藍とバザールとは、大企業とOSSのメタファではないからです。
本文より引用しましょう。伽藍とは以下のようなモデルです。
でももっと上のレベルでは何かどうしようもない複雑な部分がでてきて、もっと中央集権的で、アプリオリなアプローチが必要に なってくるものだとも思っていた。一番だいじなソフト（OS や、Emacs みたいな本当に大規模なツール）は伽藍のように組み立てられなきゃダメで、一人のウィザードか魔術師の小集団が、まったく孤立して慎重に組み立てあげるべ きもので、完成するまでベータ版も出さないようでなくちゃダメだと思っていた。
そう、伽藍とは初期の大規模設計（Big Design Upfront）を前提とするシリアルなモデル のことを指しています。
ではバザールモデルとは。
リーヌス・トーヴァルズの開発スタイル――はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする――には まったく驚かされた。
バザールとは、 頻繁なリリースサイクルを前提とした、オープンでイテレーティブな開発モデル を指しています。
つまり、いまの俗な言葉で言えば（定義としての揺れがあることは十分に承知しつつ）、
- 伽藍 = ウォーターフォール かつ 中央集権
- バザール = アジャイル かつ 自己組織化
といえるのではないでしょうか。
もちろん伽藍モデルは大企業に多く、バザールモデルはOSSに多いことは事実ですが、あくまで伽藍とバザールが指すのは開発モデルであって、プロジェクトの形態ではありません。何が言いたいかというと、 企業内のクローズドな開発であっても、ある程度のバザール的要素は適用できるのです。
「伽藍とバザール」に書いてあること
伽藍とバザールに書いてあるのは、「なぜバザールモデルが機能するのか」という分析です。そしてこの分析というのは1990年代に行われたもの、というのに価値があります。
なぜなら、その時代にはGithubどころか、Gitすら存在していないのです（LinusがGitを作るのはちょうどこの文章が日本語訳された後）。もちろんSlackもありません。あるのはメーリングリストと初期のWWWのみ。
これは現代のGithubなれしている人たちからしたらただの昔話ですが、実際の皆さんの組織はどうでしょう？**社内の情報共有の仕組みって、実質1990年代で止まっているのではないですか？**メールによる伝達が主で、ソースコードは結局共有ファイルサーバに上げられて、あってもSVNまでしかない、という人はまだまだいるのでは？
そう、そんな状況だって、バザールモデルが機能するのだ、ということがこの本を読むとわかるのです。これはすなわち、「納得できたなら、どんな会社でもやれる」ということになります。
バザールモデルが機能する仕組み
ではなぜ「はやめにしょっちゅうリリース、任せられるものはなんでも任して、乱交まがいになんでもオープンにする」、どう考えても秩序が取れないバザールモデルはなぜ機能するのでしょうか。
本書には多くのポイントが書いてありますが、個人的に重要だと思うのは以下の３つです。
-
開発者の個人的な情熱を原動力とする
- 逆に情熱を失ったならメインからは降りる
-
ユーザーを共同開発者として扱う
- 優秀なベータテスター兼デバッガー兼修正者となる
-
ユーザーの興味と情熱を惹きつけつづける
- 頻繁なリリース
- 貢献の可視化
まず重要なのは、バザールモデルとはいえどもそのバザールの長、LinuxでいうLinusでありEmacsにおけるRMSのような存在がいるということです。これは個人であったりチームであったりもしますが、どのみちバザールにはその進路をゆるく決定づけられる（そしてそうあるよう皆から信託された）人物がいます。その人物の個人的な情熱を原動力とし、プロジェクトは牽引されます。
そして、バザールにおいてはそのソフトウェアやライブラリのユーザは共同開発者として扱います。もちろんその条件としては、ユーザも情熱を持ってそのソフトウェアを利用していることが条件になるでしょう。
そして情熱を持った開発者がいて、情熱を持ったユーザがいて、あと一つ必要なのは情熱を焚き付けつづける仕組みです。これを担保するのが頻繁なリリースであり、貢献の可視化であり、もっといえばプロジェクトの透明性そのものとなります。
情熱を持った開発者が、自分のソフトウェアをオープンにし、頻繁なリリースと貢献の感謝で熱狂的なユーザを獲得し、その熱狂的なユーザの貢献によりさらにプロジェクトが発展する。
ごく単純化してしまえば、この流れがバザールモデルが機能する仕組みとなります。
企業内にバザールモデルは適用できるのか
上記のようなプロセスを考えたときに、果たして企業内にそのようなプロセスを持ち込むことができるのでしょうか。
個人的にはできる、と考えています。ある程度大きな企業においては「社内OSS」、中小規模においては「部分的OSS」というアプローチがあるのではないでしょうか。
社内OSS
文字通り、社内にむけてソースコードを公開しプロジェクトをすすめることです。公開するのは、各プロジェクトそのものでもいいですが、難しい場合はそのプロジェクトで使ったツール類、ライブラリ類、あるいはIaCコード、そういったものが考えられると思います。
重要なのは、ただ公開するだけではなく、ちゃんと自分たちのプロジェクトで使っていること、レポジトリオーナー権をもたせてある程度の所有権を与えること、だと思います。
いろいろな話を伝え聞くに、Googleというのはこれを最も積極的にやっている企業なのではないでしょうか。もちろんGoogle自体がOSSにおいてかなり先駆的な役割を果たしているのですが、それ以上にGoogleでは社内のツールから新たな製品やOSSが生み出されているのです。
たとえばKubernetesはもはやコンテナオーケストレーションツールのスタンダードとなっていますが、もともとはGoogle社内で、かつクローズドなツールから派生していったものだったはずです。Kubernetesは結果的にはOSSになっていますが、それ以外にもGCPに乗っかっているようなツール群は、社内のツール群をうまく活用して製品に展開していっているように思えます。これは、社内におけるバザールモデルが機能していることの証左ではないでしょうか。
部分的OSS
これは、コアとなる部分はOSS化せずにプロプライエタリに保ちつつ、その周辺ツールをOSS化する、という方法です。
このやり方でぱっと頭にうかぶのが時雨堂です。時雨堂はコア製品である"WebRTC SFU Sora"についてはクローズドかつプロプライエタリですが、その周辺ツールはことこどくOSS化しています。2
そしてOSS群に関しては、Discordサーバで活発な議論がなされつつ機能追加がなされており、開発スピードが保たれていると同時に、そのオープンさから開発者を惹きつけ、おそらくはSora自体の売上にもかなりの貢献をしているものと思われます。
このように、OSS的な側面を企業として取り入れ、バザール手法のメリットを取り入れることは可能なはずです。
企業がバザールモデルを取り入れられる条件とは
とはいえ、どんな企業でもこのプロセスが有効であるとも思いません。企業内で「透明性」と「スラック（ゆとり）」が確保されていないと、それを発展させるのは難しいでしょう。
透明性
まず必要なのは透明性です。各プロジェクトにおいて、今どのような技術で何を作っているのか、という現在の状態だけではなく、未来に向けたロードマップを提示することがまず非常に重要でしょう。
それを社内に公開するのか社外に公開するのかに関わらず、変な隠し立てをせずに技術的な透明性を常にアピールしないと、そもそも使ってもらうこと自体が難しいはずです。
スラック（ゆとり）
チャットツールじゃないですよ。こっちです。
社内にせよ社外にせよ、こういったOSS活動は稼働を100%切り詰めていては不可能です。Googleの20%ルールが有名ですが、そもそも自分の情熱を傾けてプロダクトを作る時間、というのを確保しないと、バザールモデルというのは機能しません。
終わりに
というわけでつらつらと書いてきました。個人的には、会社のソフトウェアをどう発展させていくかというのの方向性として、ひとついい視点をもらったな、と今更ながら感じたので、ざっと書いてみました。
また古典を読み直そうかな。良い本でした。