オープンソース界では、成功の代償は重いものです。 あなたの書いたソフトウェアが有名になればなるほど、 その情報を知りたがる人の数も劇的に増加します。 一方、みんながほしがっている情報を提供できる人の数は、 それほど急激に増えることはありません。 さらに、たとえ情報をほしがる人と情報を提供する人の増加率が うまい具合にバランスがとれていたとしても、 オープンソースプロジェクトのメンバー間でのコミュニケーションは 人数が増えれば増えるほど面倒になります。 たとえばメーリングリストを考えてみましょう。 たいていのプロジェクトには、一般的なユーザー向けのメーリングリストがあります。 いわゆる "users" とか "discuss" とか "help" などといった名前のメーリングリストです。 名前が何であるかにかかわらず、これらのメーリングリストの目的は同じです。 疑問がある人が質問をすれば何らかの答えが得られるということ、 そして、それらのやり取りをただ眺めていることで それなりの知識を得られるということです。
この手のメーリングリストのメンバーは数千人になることも珍しくありません。 また、一日あたりの投稿数が数百になることもよくあります。 しかし、このくらいの規模になってくると、システムは徐々に破綻しはじめます。 個々のメンバーが一日にさばききれない量のメッセージを受け取るようになると、 メーリングリストのメッセージがその人にとって重荷になってしまうでしょう。 考えてもみましょう。たとえば、Microsoft が Windows XP 用にこの手のメーリングリストを開設したとします。 Windows XP を使っている人は、世界中に何億人といます。 そのうちのほんの 0.1% の人が 24 時間のうちにひとつの質問を投稿したとすると、 この仮想メーリングリストの一日の投稿数は10万通にもなってしまいます! もちろん、実際にはそんなメーリングリストは存在しません。 もしあったとしても、だれもそんなメーリングリストのメンバーでい続けることはできないでしょう。 これはメーリングリストに限った問題ではありません。 IRC チャンネルやオンラインの掲示板、 その他個人からの質問を受け付けるあらゆるシステムには同じ論理があてはまります。 この論理が示唆するところはあまり思わしくありません。 オープンソースモデルでしっかりとしたサポートを続けようとすると、 世界征服できるほどにまでプロジェクトの規模を拡大するのは不可能だということです。
メーリングリストや掲示板の規模が臨界点に達しても、 大爆発が発生するといったことはありません。 負の反応は、静かに出てくることになります。 たとえばメーリングリストから脱退する人や IRC チャンネルから去る人が出てきたり、 ノイズが目障りだという理由で質問を控える人が出てきたりといった具合です。 人がみなこのように合理的な選択をすれば、 掲示板の規模はある程度管理可能な範囲で落ち着くのでは? と考える人がいるかもしれません。 しかし、このような場合にまずメーリングリストから去っていくのは、 たいていの場合は経験を積んだメンバーです。 一方、参加して日が浅い人たちはそのままそこに残ったままでいるでしょう。 つまり、プロジェクトの規模が大きくなりすぎても まだ同じコミュニケーションモデルを使用していると、 その場における質問や回答のレベルが徐々に低下していくということになります。 まるで、(実際にはそうではないかもしれないのに) 新参者のほうが古参メンバーより劣っているというように見えてしまうかもしれません。 このような状況になると、古株のメンバーは そこに参加するメリットをあまり感じられなくなり、 どこか他の場所を探すようになるでしょう。 プロジェクトの規模が拡大したときにコミュニケーションの仕組みをどうするか。 これには、次のふたつの戦略がかかわってきます。
全体としては巨大化の悪影響が出てきつつあるようだが、 特定の分野の話題についてはまだその影響を受けていない というところを見つけたら、その分野の話題だけに特化した会議室を新たに作成する (つまり、被害が及ばないうちに他の場所に避難させる)。
情報を自動的に取得できる場所を多く確保し、 それをきちんと系統立てて管理する。 また、常に最新の情報を反映させ、人が見つけやすいようにする。
作戦 (1) は、通常はそんなに難しくありません。 たいていのプロジェクトは、最初はメーリングリストがひとつだけで始まります。 そこでは、一般的な議論のほかに、機能追加の要望や設計に関する疑問、 コーディングに関する問題などさまざまな内容をごちゃ混ぜにして扱います。 そしてプロジェクトにかかわるすべての人たちがそのメーリングリストに参加しています。 しばらくすると、扱う内容によって いくつかのメーリングリストに分割したほうがよいということがわかってきます。 たとえば、あるスレッドでは開発に関連する話題が盛り上がっており、 別のスレッドでは、いわゆる「○○をするにはどうすればいいの？」 的な質問が行われ、また別のスレッドではバグレポートや機能追加要求が行われていたりといった具合です。 中にはこれらのスレッドの複数に参加する人もいるかもしれませんが、 ここで重要なのは、これら異なるタイプのスレッドには 共通点がほとんどないということです。 ということで、これらの話題をそれぞれ個別のメーリングリストに分割しても、 特に弊害は出ないでしょう。
この分割は、二段階の手順を踏んで行います。 まず新しいメーリングリスト (あるいは IRC チャンネルなど) を作成し、 次にそのメーリングリストを適切に使用するよう、 他の人たちを誘導することになります。 後半の作業は数週間程度の時間をかけて行うことになりますが、 それくらいあれば人はみなその考えを理解してくれるでしょう。 あなたがすべきことは、間違った場所に投稿してきた人に対して 他人にも見える場所でそれを指摘してあげることです。 そうすれば、他の人たちはいちいち指摘されなくても新しい場所を利用することになるでしょう。 すべてのメーリングリストの一覧をまとめたウェブページを作成するのも有用です。 他の人に新しい場所を指定する代わりに、そのページを参照させるだけでよくなります。 うまくいけば、他のメンバーも投稿の前にそのページを参照してくれるようになるかもしれません。
作戦 (2) は、そのプロジェクトが存続する限りずっと続けることになる作業です。 もちろんこれは、ドキュメントを常に最新の状態に保って (2章さあ始めましょう の 「ドキュメント」 をご覧ください) みんなをそこに誘導するという作業の一環でもあります。 しかし、それ以外にも考慮すべき点があります。 次のセクションでは、こちらの作戦について詳しく見ていきます。
通常は、オープンソースプロジェクトにおけるあらゆるやり取りの内容は (IRC での会話は例外として) 保存されます。 そのアーカイブは、一般に公開された検索可能な場所に配置され、 常に参照できるようになります。すなわち、 なんらかの情報が特定の場所に保存されたら、 それは常に同じ場所に存在する必要があるということです。
できるだけこれらのアーカイブを活用し、その存在を広めるようにしましょう。 たとえわかりきった内容の質問に答える場合であっても、 その答えを含むアーカイブがありそうなら それを探して場所を示したほうがいいでしょう。 あなた自身が常にそのようにするよう心がけていると、 「アーカイブがそこにある」「アーカイブを検索すれば答えが得られる」 ということに気づいてくれる人もあらわれるでしょう。 また、同じ内容を改めて書き直すのではなくアーカイブを参照させるようにすることで、 「同じ情報を重複させない」という指針を守ることができます。 同じ回答をわざわざいろんな場所に分散させる必要なんてありますか? このような重複をできるだけ減らすように心がければ、 ある回答に以前にたどり着いた人が、 それを再び見つけ出すことも簡単になるでしょう。 参照をうまく利用することは、検索結果全般にもよい影響を与えます。 というのも、インターネットのサーチエンジンは 他の場所から多く参照されているリソースを重視するからです。
しかし、場合によっては情報を多重化してもいいこともあります。 たとえば、あなた以外の人が投稿した次のようなメッセージが アーカイブ内にすでにあるとしましょう。
おそらく Scanley のインデックスが狂い始めているのでしょう。 復旧させるには次の手順を実行してください。 1. Scanley サーバを停止する 2. Scanley に同梱されているプログラム 'defrobnicate' を実行する 3. サーバを立ち上げる
数ヵ月後に、また別の人が「インデックスがおかしいみたいなんです」 という投稿をしてきたとしましょう。アーカイブを検索したあなたは 先ほどのメッセージを見つけました。でも、そのメッセージの手順にはすこし不備があるようです (単なる間違いなのか、あるいはその当時とは仕様が変わったのかといったところでしょう)。 こんなときのイケてるやりかたは、 作業手順をきちんとまとめなおしたメッセージを新たに投稿し、 そこで「以前の投稿は内容が古くなっている」と明記しておくことです。
おそらく Scanley のインデックスが狂い始めているのでしょう。 7 月にも同じような投稿があり、J. Random がそれに対して回答しています。 その回答は http://blahblahblah/blah にあります。以下に示す手順は、 J. Random が示した手順をもう少しきちんと補足したものです。 1. Scanley サーバを停止する 2. Scanley サーバを実行しているユーザーになる 3. そのユーザーで、'defrobnicate' プログラムを実行する 4. Scanley を手動で起動し、インデックスが正常になったことを確認する 5. サーバを再起動する
(理想を言えば、古いほうの投稿にメモをつけて 「この内容は古くなっています。新しい情報はこちらです」 といったことが指定できればいいのでしょう。 しかし、私の知る限り、このような「新しい情報はこちら」 機能を持ったアーカイブソフトウェアは存在しないようです。 おそらく、アーカイブの内容の整合性を失わずにこの機能を実装するのは 少し手間のかかることなのでしょう。 こういうこともあるので、よくある質問とその回答については 専用のウェブページを作成しておくことをお勧めするのです)
アーカイブの使用法として最もよくあるのは、 技術的な質問に対する答えを探すというものでしょう。 しかし、プロジェクトにとってのアーカイブの重要性は、それをはるかに上回るものです。 そのプロジェクトの公式なガイドラインがいわば「制定法」であるとするなら、 アーカイブはそのプロジェクトの「慣習法」といえます。 すなわち、これまでに行われたあらゆる議論の流れとその結論がアーカイブから得られるのです。 以前と同じような議論を繰り返す際には、まずアーカイブを検索してみるのが義務といえるでしょう。 そうすれば、現在の状況や予想される反論を知ることができ、 それに対する反証の準備をすることができます。 おそらく自分では思いつかなかった角度からの意見も見つけることができるでしょう。 また、他のメンバーもあなたがすでにアーカイブを検索しているものとして話を進めるでしょう。 たとえ以前の議論で何の結論も出ていなかったとしても、 その議論を再開する際には以前の議論へのポインタを示すべきです。 そうすることで、他のメンバーは 「その議論の結論がまだ出ていない」そして「あなたがやるべきことをやっている」 つまり、あなたの意見はこれまでの議論の繰り返しではないのだろうということをわかってくれます。
これまでのアドバイスは、単なるメーリングリストのアーカイブだけにあてはまるものではありません。 特定の情報は常に同じ場所で得られるようにする、 見つけやすい場所に置くなどといった原則は、 プロジェクトのすべての情報に対して同様にあてはまるものです。 プロジェクトの FAQ を例にして考えてみましょう。
人は FAQ をどのように使うのでしょう?
適当な単語やフレーズを入力して検索できればいいですね。
単に特定の質問に対する答えを探すというだけでなく、 全体をざっと眺めたいこともあるでしょう。
Google のようなサーチエンジンでも FAQ の内容を見つけられるようにしてほしいと思うことでしょう。
FAQ の特定の項目を直接指し示せるようにもしたいものです。
FAQ に新たな内容を追加できるようにもしたいでしょう。 しかし、注意すべきなのは、FAQ への新たな内容の追加は FAQ の検索よりもはるかに頻度の低いものであるということです。 FAQ は、書き込むよりも読まれるほうが圧倒的に多いものです。
1. は、つまり FAQ が何らかのテキスト形式でなければならないということです。 2. と 3. が言わんとしていることは、FAQ が HTML ページとして存在しなければならないということです。 2. はさらに、HTML が読みやすい形式であること (つまり、その見栄えを変更できること) や目次を持っていることも要求しています。 4. を満たすには、FAQ の各項目に HTML の 名前付きアンカー を指定しておく必要があります。 それによって、ページ内の特定の場所に直接到達できるようになります。 5. が意味するところは、FAQ のソースファイルの取得が容易であり (3章技術的な問題 の 「すべてをバージョン管理する」 をご覧ください)、 また編集しやすいものでなければならないということです。
ここでは FAQ についてのみ取り上げましたが、 これは、リソースの体裁を整えるほんの一例にすぎません。 ここで取り上げた内容 (直接検索できること、 主要なサーチエンジンから検索できること、閲覧しやすいこと、 特定の場所を参照しやすいこと、適切に編集しやすいこと) は、ウェブページ全般やソースツリー、 バグ追跡システムなどでも当てはまるものばかりです。 メーリングリストのアーカイブ用ソフトウェアの多くは、 これらの項目の重要性に大昔から気づいていました。 そのため、メーリングリストのアーカイブ用ソフトウェアの多くは これらの機能を自前で搭載しています。 その他の形式の文書については、 担当者がそれなりに手間をかける必要があるかもしれません (このような作業をボランティアに任せていくための方法については 8章ボランティアの管理 で説明します)。
プロジェクトが歴史を積み重ねて複雑さを増していくにつれて、 新規参入する人たちが覚えなければならないデータの量も増加します。 長年そのプロジェクトにかかわっている人たちは、 プロジェクトの成長とともにそのしきたりを作り上げたり学んだりすることができました。 彼らは往々にして、今まで築き上げてきた伝統がどれほど巨大なものかに気づいていません。 そして、新たに参加してくる人たちがその伝統を守らないのをみて驚くのです。 もちろんこれは、最近の人たちが古株よりも劣っているということではありません。 プロジェクトの初期に比べ、新規参入のハードルが高くなっていることが問題なのです。
プロジェクトが積み上げていく伝統には、 コミュニケーションの方法や、 コーディング規約および他の技術情報を蓄積する方法もあります。 これらについては、それぞれ 2章さあ始めましょう の 「開発者向けドキュメント」 および 4章プロジェクトの政治構造と社会構造 の 「全てを記録しておく」 で例を挙げて説明しました。 このセクションでは、プロジェクトの成長に伴って これらのガイドラインをいかに最新の状態に保つかを説明します。 特にコミュニケーションに関するガイドラインは重要です。 というのも、これはプロジェクトの規模や複雑さが大きくなるにつれて変わっていくものだからです。
まずは、みんなが何に困っているのかを調べましょう。 同じような状況で (特に新入りのメンバーが) 困っていることに気づいたら、 それは「ガイドラインをきちんと設定すべきなのに、まだできていない」 という証拠です。 次に、同じことを何度も何度も繰り返して言うのをいやがらないようにしましょう。 いやいや言っているように思われてはいけません。 新入りさんがどんどん入ってくる以上、 あなたや他のベテランメンバーが同じことを繰り返すはめになるのは避けられません。
すべてのウェブページ、メーリングリストへのすべての投稿、 そしてすべての IRC チャンネルには告知用のスペースを設けるようにしましょう。 これは商業的な広告を行うものではなく、 そのプロジェクト自身のリソースについて告知するための場所となります。 そこに何を載せるのかは、それをどのような人たちが読むのかにあわせて決めます。 たとえばユーザーからの質問を受け付ける IRC チャンネルの場合、 それを利用する人の多くはこれまでにそのプロジェクトにかかわったことがない人となるでしょう。 単にインストールしてみただけであることも多いでしょうし、 たいていは「今すぐに」回答を欲していることでしょう (ちょっとでも待てるのなら、普通はメーリングリストに質問するでしょうから。 答えが返ってくるのに多少時間がかかることさえ我慢できれば、 こっちのほうが手間がかかりません)。 普通の人は IRC チャンネルに常駐することはありません。 ふらっと登場して質問を行い、そして去っていくだけです。
したがって、このチャンネルで扱う話題の対象は、 ソフトウェアについての技術的な質問の回答を 今すぐに ほしい人たちということになります。 今後ずっとプロジェクトのコミュニティーに参加するであろう人たちにくらべ、 この手の人たちにとってはコミュニティーのガイドラインはそれほど重要ではありません。 活発なチャンネルがどのようにしているのかの例を見てみましょう (3章技術的な問題 の 「IRC / リアルタイムに行なわれるチャットシステム」 で示した例と見比べてみるといいでしょう)。
あなたはチャンネル #linuxhelp で話しています。 #linuxhelp のトピックは以下の通りです。 質問する前に、以下の二つは必ず読んでください。 http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto | チャンネルに関するルールは http://www.nerdfest.org/lh_rules.html にあります | kernel 2.6.x へのアップグレードについて質問する前に http://kerneltrap.org/node/view/799 を調べてください | kernel のメモリ空間が参照可能になる脆弱性: http://tinyurl.com/4s6mc -> 2.6.8.1 か 2.4.27 にアップデートすること | 衝突するハッシュアルゴリズム: http://tinyurl.com/6w8rf | reiser4 ファイルシステムリリース)
メーリングリストの場合、この「告知スペース」にあたるのは 全メッセージの最後に付加されるちょっとしたフッターとなります。 たいていのプロジェクトでは、この部分にメーリングリストへの参加方法や 脱退方法を載せています。また、そのプロジェクトのホームページや FAQ ページの場所を載せていることもあるでしょう。 そんなことなんて、メーリングリストのメンバーならみんな知っているはずだと思われるかもしれません。 おそらくそれは正しいでしょう。しかし、 メーリングリストへの投稿を見るのは、 何もメーリングリストの参加者だけであるとは限りません。 メーリングリストのアーカイブは、さまざまな場所からリンクされることになります。投稿の内容によっては、 メーリングリストの参加者よりもずっと多くの人たちに読まれることになるものもあるでしょう。
書式を整えることには絶大な効果があります。 たとえば Subversion プロジェクトでは、 3章技術的な問題 の 「バグ追跡システムをあらかじめフィルタする」 で説明したバグフィルタリング技術で ある程度うまくいっていました。 ただ、それでもバグとは言えないような内容がたびたび登録されてしまっていました。 そんなことがあるたびに、担当者がいちいち彼らに教えてやる必要があったのです。 そう、これまで 500 人もの人に言ってきたのと同じことを。 ある日のこと。そんな状況に業を煮やしたある開発者が、 バグ追跡システムのガイドラインを読まずに投稿するユーザーに対してキレはじめたのです。 それを見た他の開発者たちは、この方式ではもはややっていけないことに気づきました。 彼は提案しました。バグ追跡システムのトップページの目立つところに 「メーリングリストや IRC で十分に議論してからバグを登録するように」と書いてやろうと。 そう、黄色い背景に赤の太字で。すべてのページの先頭にでかでかと。 私たちはそれを実行しました (その結果は http://subversion.tigris.org/project_issues.html でご覧いただけます)。 その結果。本来のバグ以外が登録されてしまうことが激減したのです。 もちろん、(期待通り) 現在もそれは続いています。 しかも、ユーザー数が増えているにもかかわらず、ゴミの量は目に見えて減っています。 その結果、バグデータベースの中に含まれるゴミの量が減っただけではなく、 バグに対応する人たちの空気もよくなってきたのです。 今でもたまにバグ以外のゴミが登録されることもありますが、 そんな場合の反応も暖かいものとなっています。 これは、そのプロジェクトのイメージとメンバーの精神衛生の両方によい影響を及ぼします。
このことから得られた教訓は、 単にガイドラインを作成するだけではダメだということでした。 作成したガイドラインは、 それを最も必要としている人たちの目に付きやすいところに掲げる必要があったのです。 そのプロジェクトにあまりなじみのない人でも明確にわかるようにしなければならなかったのです。
そのプロジェクトのしきたりを説明する場所は、何も静的なウェブページだけではありません。 ある程度は対話的な取り締まりも必要です (ここで言う「取り締まり」とは、 手錠だの牢屋だのといったものではありません。単に好意的な注意をする程度のものです)。 2章さあ始めましょう の 「きちんとしたコードレビューの習慣」 で説明したコミットレビューを含むすべてのピアレビューでは、 特にそのプロジェクトの決まりに反していないかどうかも注意してレビューするようにしましょう。
Subversion プロジェクトで利用している規約をもうひとつご紹介しましょう。 私たちは、"r12908" と書けばそれは "バージョン管理リポジトリのリビジョン 12908" という意味であるとしています。 小文字の "r" は非常にタイプしやすい文字だし、 数字の半分の高さしかないので数字と組み合わせても識別しやすいのです。 もちろん、こんな決まりを作ったからといってみんながすぐそれに従うとは限りません。 たとえば、こんなログメッセージを含むコミットメールが届くこともあるでしょう。
------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines J. Random からのパッチを採用した <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: revision 12828 に存在していたtypoをいくつか修正 ------------------------------------------------------------------------
...こんなコミットに対するレビューの返事は、次のようになるでしょう。 "ところで、過去の変更内容を指す場合は 'revision 12828' じゃなくて 'r12828' 形式にしてくれないかな?" これは、単に格好だけの問題ではありません。 そうすることで、人間が読みやすくなるだけでなく 機械で自動解析することも簡単になるのです。
このような標準にしたがって 共通の方式を使用するようにし、それをどこでも一貫して使うようにすると、 そのプロジェクトの事実上の決まりとして認められるようになります。 このような決まりを作っておくと、 プロジェクト内のコミュニケーションをより円滑にするためのツールを作りやすくなります。 たとえば "r12828" 形式で書かれたリビジョンを リポジトリ閲覧システムへの直リンクに変換したりといったことがやりやすくなるのです。 もし "revision 12828" のような形式でリビジョンを表すようにすると、 ツールを作るのは難しくなるでしょう。たとえば途中に改行がはいったりすることもあるでしょうし、 文章の中から抜き出すのも難しくなります ("revision" という単語は他の場面でもよく使われるでしょうし、 "12828" のような単なる数字もさまざまな場所で用いられます。 一方、リビジョン番号以外の意味で "r12828" 形式を用いることはまずないでしょう)。 同様のことが、バグ番号や FAQ の項目番号 (ヒント: 名前付きアンカーと ID 属性 で説明したように、URL で名前付きアンカーを用いることを考えてみましょう) などにも当てはまります。
短めの決まった形式が存在しない情報であっても、 できるだけ一貫して重要な情報を提供するようにしなければなりません。 たとえばメーリングリストへの投稿を指すときに、 単に送信者と件名だけで済ませてはいけません。 それだけでなく、アーカイブへの URL と Message-ID ヘッダも含めるようにしましょう。 Message-ID ヘッダを含めておけば、 メーリングリストへの投稿をローカルに保存している人たち (旅行中でも過去のメールを読めるように、オフラインのコピーを ラップトップに残している人もいます) にとって便利です。 アーカイブにアクセスしなくても、Message-ID ヘッダからメッセージが特定できるからです。 この場合、送信者と件名だけでは不十分です。 だって、同じスレッド内で同じ人が同じ件名のメッセージを 一日に何度も送信することって、そんなに珍しいことではないでしょう？
プロジェクトの規模が大きくなればなるほど、この手の一貫性はより重要となります。 一貫性とは、プロジェクトのメンバーがどこでも同じ規則に従うこと。 そして規則に従わなければならないと認知していることを指します。 こうしておけば、無駄な質問が繰り返されることも減ります。 メンバーが 100 万人だろうがひとりだろうが、 その負荷はそれほど変わりません。本当につらくなるのは、 質問してくる人の数が増え始めてきたときです。 したがって、プロジェクトの規模が大きくなってきたら、 質問の量を減らす方向に進めることを心がけましょう。 そのためには、質の高い情報を提供し、 さらにその情報を見つけやすいようにしておくことです。 そうすれば、わざわざ質問するまでもなく 必要な情報をすぐに見つけられるようになります。