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

[Karl Fogel， ]

しきたりの成文化

　プロジェクトが歴史を積み重ねて複雑さを増していくにつれ、新規参入する人たちが覚えなければならないデータの量も増加します。長年そのプロジェクトにかかわっている人たちは、プロジェクトの成長とともにそのしきたりを作り上げたり学んだりすることができました。彼らは往々にして、いままで築き上げてきた伝統がどれほど巨大なものかに気づいていません。そして、新たに参加してくる人たちがその伝統を守らないのをみて驚くのです。もちろんこれは、最近の人たちが古株よりも劣っているということではありません。プロジェクトの初期に比べ、新規参入のハードルが高くなっていることが問題なのです。

　プロジェクトが積み上げていく伝統には、コミュニケーションの方法や、コーディング規約およびほかの技術情報を蓄積する方法もあります。これらについては、それぞれ章2.さあ始めましょうの開発者向けドキュメント項および章4.プロジェクトの政治構造と社会構造のすべてを記録しておく項で例を挙げて説明しました。このセクションでは、プロジェクトの成長に伴ってこれらのガイドラインをいかに最新の状態に保つかを説明します。特にコミュニケーションに関するガイドラインは重要です。というのも、これはプロジェクトの規模や複雑さが大きくなるにつれて変わっていくものだからです。

　まずは、みんなが何に困っているのかを調べましょう。同じような状況で（特に新入りのメンバーが）困っていることに気づいたら、それは「ガイドラインをきちんと設定すべきなのに、まだできていない」証拠です。次に、同じことを何度も何度も繰り返して言うのを嫌がらないようにしましょう。嫌々言っているように思われてはいけません。新入りさんがどんどん入ってくる以上、あなたやほかのベテランメンバーが同じことを繰り返すはめになるのは避けられません。

　すべてのWebページ、メーリングリストへのすべての投稿、そしてすべての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で十分に議論してからバグを登録するように」と書いてやろうと。そう、黄色い背景に赤の太字で。すべてのページの先頭にでかでかと。わたしたちはそれを実行しました（その結果はSubversion Issue Trackerでご覧いただけます）。

　この結果、本来のバグ以外が登録されてしまうことが激減したのです。もちろん、（期待通り）現在もそれは続いています。しかも、ユーザー数が増えているにもかかわらず、ゴミの量は目に見えて減っています。その結果、バグデータベースの中に含まれるゴミの量が減っただけではなく、バグに対応する人たちの空気もよくなってきたのです。今でもたまにバグ以外のゴミが登録されることもありますが、そんな場合の反応も暖かいものとなっています。これは、そのプロジェクトのイメージとメンバーの精神衛生の両方によい影響を及ぼします。

　このことから得られた教訓は、単にガイドラインを作成するだけではダメだということでした。作成したガイドラインは、それを最も必要としている人たちの目につきやすいところに掲げる必要があったのです。そのプロジェクトにあまりなじみのない人でも明確に分かるようにしなければならなかったのです。

　そのプロジェクトのしきたりを説明する場所は、何も静的なWebページだけではありません。ある程度は対話的な取り締まりも必要です（ここで言う「取り締まり」とは、手錠だの牢屋だのといったものではありません。単に好意的な注意をする程度のものです）。章2.さあ始めましょうのきちんとしたコードレビューの習慣項で説明したコミットレビューを含むすべてのピアレビューでは、特にそのプロジェクトの決まりに反していないかどうかも注意してレビューしましょう。

　Subversionプロジェクトで利用している規約をもう1つご紹介しましょう。わたしたちは、“r12908”と書けばそれは“バージョン管理リポジトリのリビジョン12908”という意味であるとしています。小文字の「r」は非常にタイプしやすい文字だし、数字の半分の高さしかないので数字と組み合わせても識別しやすいのです。もちろん、こんな決まりを作ったからといってみんながすぐそれに従うとは限りません。例えば、こんなログメッセージを含むコミットメールが届くこともあるでしょう。

------------------------------------------------------------------------

r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines

J. Random からのパッチを採用した

* 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万人だろうが1人だろうが、その負荷はそれほど変わりません。本当につらくなるのは、質問してくる人の数が増え始めてきたときです。従って、プロジェクトの規模が大きくなってきたら、質問の量を減らす方向に進めることを心がけましょう。そのためには、質の高い情報を提供し、さらにその情報を見つけやすいようにしておくことです。そうすれば、わざわざ質問するまでもなく必要な情報をすぐに見つけられるようになります。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク