臨界点を超えた先のコミュニケーションモデル：オープンソースソフトウェアの育て方（1/3 ページ）

オープンソースプロジェクトのメンバー間でのコミュニケーションは人数が増えれば増えるほど面倒になります。それが臨界点に達するとき、負の反応は静かに出てくることになります。ここでは、巨大化したプロジェクトに適したコミュニケーションモデルを考えます。

[Karl Fogel， ]

巨大化への対応

　オープンソース界では、成功の代償は重いものです。あなたの書いたソフトウェアが有名になればなるほど、その情報を知りたがる人の数も劇的に増加します。一方、みんながほしがっている情報を提供できる人の数は、それほど急激に増えることはありません。さらに、たとえ情報をほしがる人と情報を提供する人の増加率がうまい具合にバランスが取れていたとしても、オープンソースプロジェクトのメンバー間でのコミュニケーションは人数が増えれば増えるほど面倒になります。

　例えばメーリングリストを考えてみましょう。たいていのプロジェクトには、一般的なユーザー向けのメーリングリストがあります。いわゆる“users”とか“discuss“とか“help”などといった名前のメーリングリストです。名前が何であるかにかかわらず、これらのメーリングリストの目的は同じです。疑問がある人が質問をすれば何らかの答えが得られるということ、そして、それらのやり取りをただ眺めていることでそれなりの知識を得られるということです。

　この手のメーリングリストのメンバーは数千人になることも珍しくありません。また、一日当たりの投稿数が数百になることもよくあります。しかし、このくらいの規模になってくると、システムは徐々に破たんし始めます。個々のメンバーが一日にさばききれない量のメッセージを受け取るようになると、メーリングリストのメッセージがその人にとって重荷になってしまうでしょう。

　考えてもみましょう。例えば、MicrosoftがWindows XP用にこの手のメーリングリストを開設したとします。Windows XPを使っている人は、世界中に何億人といます。そのうちのほんの0.1％の人が24時間のうちに1つの質問を投稿すれば、この仮想メーリングリストの一日の投稿数は10万通にもなってしまいます。もちろん、実際にはそんなメーリングリストは存在しません。もしあったとしても、だれもそんなメーリングリストのメンバーでい続けることはできないでしょう。

　これはメーリングリストに限った問題ではありません。IRCチャンネルやオンラインの掲示板、その他個人からの質問を受け付けるあらゆるシステムには同じ論理が当てはまります。この論理が示唆するところはあまり思わしくありません。オープンソースモデルでしっかりとしたサポートを続けようとすると、世界征服できるほどにまでプロジェクトの規模を拡大するのは不可能だということです。

　メーリングリストや掲示板の規模が臨界点に達しても、大爆発が発生するといったことはありません。負の反応は、静かに出てくることになります。例えばメーリングリストから脱退する人やIRCチャンネルから去る人が出てきたり、ノイズが目障りだという理由で質問を控える人が出てきたりといった具合です。人がみなこのように合理的な選択をすれば、掲示板の規模はある程度管理可能な範囲で落ち着くのでは？　と考える人がいるかもしれません。しかし、このような場合にまずメーリングリストから去っていくのは、たいていの場合は経験を積んだメンバーです。一方、参加して日が浅い人たちはそのままそこに残ったままでいるでしょう。

　つまり、プロジェクトの規模が大きくなりすぎてもまだ同じコミュニケーションモデルを使用していると、その場における質問や回答のレベルが徐々に低下していくことになります。まるで、（実際にはそうではないかもしれないのに）新参者の方が古参メンバーより劣っているように見えてしまうかもしれません。このような状況になると、古株のメンバーはそこに参加するメリットをあまり感じられなくなり、どこかほかの場所を探すようになるでしょう。プロジェクトの規模が拡大したときにコミュニケーションの仕組みをどうするか。これには、次の2つの戦略がかかわってきます。

1. 全体としては巨大化の悪影響が出てきつつあるようだが、特定の分野の話題についてはまだその影響を受けていないところを見つけたら、その分野の話題だけに特化した会議室を新たに作成する（つまり、被害がおよばないうちにほかの場所に避難させる）
2. 情報を自動的に取得できる場所を多く確保し、それをきちんと系統立てて管理する。また、常に最新の情報を反映させ、人が見つけやすいようにする

　作戦（1）は、通常はそれほど難しくありません。たいていのプロジェクトは、最初はメーリングリストが1つだけで始まります。そこでは、一般的な議論のほかに、機能追加の要望や設計に関する疑問、コーディングに関する問題などさまざまな内容をごちゃ混ぜにして扱います。そしてプロジェクトにかかわるすべての人たちがそのメーリングリストに参加しています。しばらくすると、扱う内容によって幾つかのメーリングリストに分割した方がよいということが分かってきます。例えば、あるスレッドでは開発に関連する話題が盛り上がっており、別のスレッドでは、いわゆる「○○をするにはどうすればいいの？」的な質問が行われ、また別のスレッドではバグリポートや機能追加要求が行われていたりといった具合です。中には複数のスレッドに参加する人もいるかもしれませんが、ここで重要なのは、これら異なるタイプのスレッドには共通点がほとんどないことです。ということで、これらの話題をそれぞれ個別のメーリングリストに分割しても、特に弊害は出ないでしょう。

　この分割は、二段階の手順を踏んで行います。まず新しいメーリングリスト（あるいはIRCチャンネルなど）を作成し、次にそのメーリングリストを適切に使用するよう、ほかの人たちを誘導することになります。後半の作業は数週間程度の時間をかけて行うことになりますが、それくらいあれば人はみなその考えを理解してくれるでしょう。

　あなたがすべきは、間違った場所に投稿してきた人に対して他人にも見える場所でそれを指摘してあげることです。そうすれば、ほかの人たちはいちいち指摘されなくても新しい場所を利用するでしょう。すべてのメーリングリストの一覧をまとめたWebページを作成するのも有用です。ほかの人に新しい場所を指定する代わりに、そのページを参照させるだけでよくなります。うまくいけば、ほかのメンバーも投稿の前にそのページを参照してくれるようになるかもしれません。

　作戦（2）は、そのプロジェクトが存続する限りずっと続けることになる作業です。もちろんこれは、ドキュメントを常に最新の状態に保って（章2.さあ始めましょうのドキュメント項をご覧ください）みんなをそこに誘導する作業の一環でもあります。しかし、それ以外にも考慮すべき点があります。次のセクションでは、こちらの作戦について詳しく見ていきます。