コミュニケーション
明瞭に、わかりやすく書くという技術は、
オープンソース界で暮らす上で最も重要なもののひとつといえるでしょう。
ある意味ではプログラミング技術よりも重要かもしれません。
プログラミングの技術は優れているがコミュニケーションスキルに欠ける人は、
一度にひとつずつのことしかこなせません。
また、周りの人の気を引くことにも苦労するかもしれません。
逆に、プログラマーとしては二流だがコミュニケーションスキルが優れている人は、
周りの人をうまく巻き込んでさまざまな作業をこなすことができます。
そして、結果としてプロジェクトをよい方向に引っ張っていってくれるのです。
コードを書く能力のある人が、
必ずしも他人とうまくやっていくためのコミュニケーション能力があるとは限りません。
よいプログラムを書く能力と技術的な問題をうまく説明する能力とには
それなりの相関関係はあるかもしれませんが、
「技術的な問題を説明する」ということは
プロジェクト内でのコミュニケーションにおけるほんの一部のことに過ぎません。
それよりもずっと大事なことは、次の３つ。
まず聞き手の気持ちになって考えること、
自分の投稿やコメントを客観的に見るようにすること、
そして他人にも自分自身の投稿やコメントを客観的に見させるようにすることです。
……といったことを口で言うのは簡単ですが、実際にやってみると
これは非常に難しいことです。というのも、フリーソフトウェアの開発には
さまざまな人たちが参加しており、彼らのコミュニケーション方法もそれぞれ異なるからです。
何か意見を述べたいときはどうすればいいのでしょう？
メーリングリストへ投稿する？ バグ追跡システムに登録する？
それともコードのコメントとして記述する？
掲示板での質問に回答するとき、相手がどれくらいの知識を持っていると想定したらいいのでしょう？
当然、ここでいう「相手」とは、質問の当事者だけでなく
後であなたの回答を読むであろう第三者も含まれます。
開発者と利用者の関係を良好な状態に保つにはどうしたらいいのでしょう？
利用者からの機能追加要求や勘違いのバグ報告、
その他の雑談などに開発者たちが悩まされないようにするには？
コミュニケーションの手段が尽きたら相手にどう伝えたらいいでしょうか？
また、どう対処したらいいのでしょうか？
これらの問題に対する解決策は、通常は一時的なものとなります。というのも、
どんな解決策であっても、プロジェクトの規模が大きくなったり
プロジェクトの体制が変わったりすれば意味がなくなってしまうからです。
また、これらの解決策はたいていその場しのぎのものになります。
刻々と変化する状況にあわせて即興で対応しなければならないからです。
すべてのメンバーは、コミュニケーション不全に陥っていないかどうかを常に気にかけ、
それに対応する必要があります。このような行動を支援することも、
オープンソースプロジェクトの運営の大事な一部です。
以下のセクションでは、あなた自身がうまくコミュニケーションを行う方法を扱います。
また、プロジェクト内での円滑なコミュニケーションを維持するための方法についても説明します。
これらの問題については、いくつか興味深い研究があります。たとえば
Gutwin、Penner および Schneider による
Group Awareness in Distributed Software Development
もそのひとつです。この論文はオンラインで公開されていましたが、
一時しばらく見えなくなっていました。その後、改めて
で公開されました。もしこの URL で見つからない場合は、
また別の場所に移動した可能性があります。サーチエンジンを使って探してみてください。
書いたことがすべて
考えてもみてください。インターネット上では、あなたが何者であるかを判断する基準は
「あなたが何を書いたか」「他人があなたのことをどのように書いたか」
しかありません。たとえあなたが頭脳明晰で洞察力に優れ、
カリスマ性のある人物だったとしても、
あなたの書いたメールが中身のない乱雑なものだったら
他の人たちはあなたのことを「中身のない乱雑な人」とみなすことでしょう。
逆に、実際のあなたが中身のない乱雑な人だったとしても、
あなたの投稿する内容が明快で有益なものなら、
他の人たちは実際のあなたがどうであるかなんて気にしません。
自分が何かを書くときには十分注意を払うようにしましょう。
決して損はしません。フリーソフトウェアのハッカーとして長年の経験を持つ
Jim Blandy は、次のような話をしてくれました。
あれは 1993 年のこと。当時私は Free Software Foundation で働いており、
GNU Emacs のバージョン 19 のベータテストをしていました。
私たちはだいたい週に一度のペースでベータ版をリリースし、
それを試したユーザーからバグ報告をもらうようになっていました。
直接会ったことはないのですが、
いつもすばらしい仕事をしてくれるユーザーが一人いたのです。
彼のバグ報告は常に明快でわかりやすく、問題を解決する大きな助けになりました。
時には彼自身がバグを修正してくれることもありましたが、
それもまた的確なものがほとんどでした。まさに最高の奴だったんです。
FSF では、誰かが書いたコードを取り込む前には、
そのコードの著作権を FSF に渡すための法的手続きをしてもらうことになっています。
見知らぬ誰かさんからもらったコードをそのまま取り込むことは、
破滅への第一歩だからです。
そこで私は、彼にメールで書類を送りました。
「ちょっとした事務手続きが必要なんだ。内容はここに説明してあるので、
まず君がここに署名してほしい。そしてもうひとつの書類に君の雇用主の署名をもらってほしい。
そうしたら君のバグフィックスを取り込めるだろう。いつもありがとう。感謝してるよ。」
こんな内容でした。
彼から返ってきた返事は「私には雇用主はいません」というものでした。
で、私は言いました。
「ああ、そうかい。それなら、代わりに君の通う大学に署名をもらって送り返してくれないかな？」
しばらくして、彼から再び返事が返ってきました。
「あ、あの……。僕、実はまだ 13 才で、親と同居しているんですけど……」
彼の文面がとても 13 才のガキが書いたのようなものには見えなかったので、
誰もそんなことは想像していなかったのです。
皆に気に入られるようなものの書き方について、これからみていきましょう。
構成や体裁
ケータイのメールじゃないんだから、
何も考えずにただだらだら書き連ねるといったことはやめましょう。
ちゃんとした文を書き、単語の先頭はちゃんと大文字にして、
適切に段落分けをするようにしなければなりません。
これは、メールだけでなくその他のちゃんとした文書においても最も重要なことです。
IRC のようなその場限りのやりとりの場合は、
あまりそんなことを気にする必要はありません。
略語を使いまくったりしても大丈夫です。
しかし、正式な掲示板上などにはそんな習慣を持ち込まないでください。
メールやマニュアル、バグ報告などのように後に残ることが前提の文書については、
標準的な文法やスペルで書く必要があります。
また、きちんと構成されていなければなりません。
これは決して「とりあえず長いものには巻かれておけ」
とかいう類の話ではありません。ここで挙げた規則は、
単なるしきたりといったものではないのです。
文書を読みやすくするために進めてきた結果がこれなので、
できるだけそれを尊重するようにしましょう。
読みやすく書くようにする理由は、
他人が理解しやすくなるからというだけではありません。
そうすることで、あなたが「他人としっかりコミュニケートするつもりのある人だ」
と認められるようになるからという面もあります。
メールを書く際には、
オープンソース開発者の間で暗黙の了解となっている決まりごとがいくつかあります。
メールではプレーンテキストのみを使用し、
HTML やリッチテキストといった形式は避けましょう。
テキストにのみ対応したメールソフトでは、
他の形式のメールがうまく見えないことがあります。
また、半角 72 文字程度で改行を入れるようにしましょう。
1 行が 80 文字を超えてはいけません。
これ (80 文字) は、端末の画面上で 1 行に表示できる桁数の標準値です。
これより広い幅の端末を使っている人もいるでしょうが、
これより狭いものを使っている人はいません。
80 文字ぎりぎりではなくもう少し余裕を持って改行しておくことで、
返信時に引用符を追加しても改行位置を気にする必要がなくなります。
実際に改行すること。
メーラーによっては、メールの作成時にはいかにも改行しているように見せていても、
実際のメールでは改行されていないといったものもあります。
そのまま送信すると、あなたの意図したところに改行が入っていない状態の
メールが送信されることになります。受け取った側の画面によっては、
改行の位置がおかしくなってしまうことでしょう。
もしあなたがそのようなメーラーを使っているのなら、
メール作成時に実際の改行を見せるような設定項目がないか探してみましょう。
画面の出力やコードの一部、その他フォーマット済みのテキストを記述する場合は、
はっきりとわかるように位置をずらしておきましょう。
どこからどこまでが地の文でどこからどこまでが引用なのかを明確にしておくことが大切です
(本書を執筆しはじめた当初は、こんなことを説明するつもりはありませんでした。
しかしさまざまなオープンソース関連のメーリングリストを見ていくうちに、
さまざまな種類のテキストを区別せずごちゃごちゃにしている人があまりにも多いことに気づきました。
それはそれは非常に読みづらいものでした。
そのおかげで彼らの投稿の内容をつかみにくくなるだけでなく、
率直に言って彼らはちょっとだらしない人たちだなと感じました)。
他人のメールを引用して返信する際は、
適切な場所に返信内容を書くようにしましょう。
必要なら、いくつかの場所に分けて書くことになってもかまいません。
また、不要な部分は引用しないようにしましょう。
もしその投稿全体に対して一言コメントしたいのなら、
投稿の先頭 (つまり、あなたの返信を書いた後に
メールの引用が続く形式) にそれを記述します。
それ以外の場合は、まず関連する箇所を引用したうえで、
その後に返信を書きます。
メールの件名はよく考えてつけるようにしましょう。
これは、メールの中でもっとも重要なものとなります。
というのも、プロジェクトの他のメンバーは
そのメールを読むかどうかを件名で判断することになるからです。
いまどきのメールソフトは、関連するメッセージをスレッドにまとめる機能を持っています。
スレッドにまとめるための基準は、
件名が同じというだけではなくその他のヘッダの内容も使用します
(このヘッダの内容は、表示されないこともあります)。
もしひとつのスレッド内で話題が変わるときは、
返信の際に件名を適切に変更することもできます (変更すべきです)。
その他のヘッダの内容によってスレッドの構成はそのまま保持されますが、
件名を変えておくと、そこで話題が変わったことがわかりやすくなります。
また、本当に新しい話題を始めたい場合は、新しいメールとして送信するようにします。
既存のメールに「返信」して件名だけを変えるというのではいけません。
さもないと、あなたの出したメールがスレッドに紛れ込んでしまいます。
これによる損失は、単に時間を浪費してしまうことだけではありません。
「コミュニケーションツールをうまく使いこなせる人」
というあなたの評判も落ちてしまいます。
中身
きれいに体裁を整えたメールは読者の気を引くことでしょう。
しかし、実際に読んでもらうには中身が大切です。
「これさえ守れば中身のある内容を書ける」というようなルールはもちろんありません。
しかし、それに近づくための原則ならいくつかあげることができます。
読む人のことを考えて書くようにしましょう。
活発に活動しているオープンソースプロジェクトには、
さまざまな情報が付きまとっています。メールの読み手が、
それらの情報をすべて知っているものと期待してはいけません。
実際のところ、彼らはそんな情報など知ろうともしないこともあるものです。
可能な限り、読み手にとって便利な情報を提供するようにしましょう。
たとえば、ほんの数分時間を使うだけで、
メーリングリストのアーカイブで特定のスレッドを表す URL を調べることができます。
それを示すことで、読み手が同じことをする手間を省くことができるでしょう。
さらに 5 分から 10 分ほど余計に時間を割けば、
複雑になったスレッドの簡単なまとめを作成することもできるでしょう。
これは、あなたの投稿の背景にある話の流れを伝えるのに役立ちます。
こんな風に考えてみましょう。プロジェクトがうまくいけばいくほど、
メーリングリストや掲示板の書き手に対する読み手の比率が高くなります。
あなたの投稿する内容が n 人に読まれているとすると、
あなたがちょっと時間を使って作業をするだけで n
人ぶんの同じ時間を節約できるようになるわけです。n
が大きくなればなるほど、この価値は向上します。
そしてあなたがそうしているのを見れば、他の人たちも同じようにしてくれるようになるでしょう。
その結果、プロジェクト全体の効率が向上することになります。n
人が苦労するのと一人が苦労するのとどちらがいいかといえば、後者でしょう。
物事を誇張しないようにしましょう。
オンラインの投稿では、話が大げさになりがちです。
たとえばバグを報告する人は、開発者たちの気を引くように
わざと大げさに話すこともあります。ちょっと気になる点が見つかったときに
「この深刻な問題のおかげで、私 (そして友人や同僚や親戚一同)
はまともにこのソフトウェアを使うことができない」
といった具合に報告するわけです。
しかし、この問題はユーザーからの報告に限ったことではありません。
プログラマーたちだって、技術的な議論をしているときに同じようなことをしています。
特に、どちらが正しいかという問題より
各自の好みにかかわるような問題を扱う際にその傾向があります。
"そのやりかただと、コードが読みにくくなっちゃうよ。
保守する人はたまったもんじゃないだろうな。それに引き換え
J. Random の提案した方法は..."
もう少し控えめな言いかたにしたほうが、実際の気持ちは伝わりやすくなります。
"たしかにそれでも動くよ。でも、可読性や保守性を考えると、
それは理想的なやりかたではないと思うんだ。J. Random
の提案する方法だとそんな問題は発生しない。なぜなら..."
誇大表現を完全になくすことは不可能でしょうし、また一般にそうする必要もありません。
他の誤解に比べると、誇大表現が及ぼす被害はそれほどでもありません。
主に書き手側が損をするだけのことです。
読み手側はそれを補正して読めるので、単に書き手が少し信頼性を失うというだけだからです。
プロジェクトにおけるあなたの影響力を考えると、
不要な誇大表現は避けるようにしておくべきです。
そうすると、あえてキツめに表現する必要が生じた場合に
周りの人たちにそれを受け入れてもらいやすくなります。
よく見直すようにしましょう。
ある程度以上の量の文章を書いた場合は、完成した文章を実際に送信する前に
もう一度頭から読み直すようにします。作文の授業でも同じことを教わったかと思いますが、
これはオンラインの議論でも特に重要です。オンラインの議論は断続的なものになる傾向があるので
(メッセージを書いている途中で過去のメールを読み直したり、何かのウェブページを確認したり、
何らかのコマンドを実行してデバッグ出力を取り込んだり、……)、ついつい論旨を見失いがちです。
断続的に書き上げたあとで一切チェックせずに送信したメッセージは、
読み手にもそのように受け取られてしまいがちです。
これは書き手にとってもうれしいことではありません。
きちんと時間をとって、書いた内容を見直すようにしましょう。
投稿内容がきちんとまとまっていればいるほど、
あなたのメッセージを読んでもらいやすくなるでしょう。
口調
繰り返しメッセージを作成しているうちに、
おそらく自分の文面がかなり素っ気ないものになっていくことに気づくことでしょう。
これはほとんどの技術系フォーラムでありがちな話ですし、それ自体には特に問題はありません。
一般社会でのコミュニケーションではありえないような素っ気無いやり取りが、
フリーソフトウェアのハッカーたちの間ではごく普通なのです。以下に引用するのは、
とあるコンテンツ管理ソフトのメーリングリストにかつて私が投稿したときに
受け取った返信です。
どんな問題が発生したのか、もうちょっと詳しく正確に説明してくれませんか？
それから。
お使いの Slash のバージョンは何ですか？
元の投稿からはそれを読み取ることができませんでした。
apache/mod_perl のソースをビルドした手順を正確に教えてください。
slashcode.com に投稿された Apache 2.0 のパッチを試してみましたか？
Shane
まさに簡潔そのものです！ 挨拶もなければ署名は自分の名前だけ。
そしてメッセージの本文はと言えば
一連の質問事項を可能な限り簡潔に並べただけ。
唯一あった質問以外の文はといえば、私の元の投稿に対する間接的な批判でした。
しかし、私は Shane のメールを見て気を悪くすることはありませんでした。
彼の素っ気ない返答を見ても「ああ、忙しい人なんだろうな」
というくらいのことしか思わなかったのです。
彼は私の投稿を無視することもできたのに、あえて質問を返してきたのです。
つまりこれは、彼が私の問題を解決するために時間を割いてくれているということを意味します。
すべての読み手がこのように好意的に受け取ることができるでしょうか？
必ずしもそうではないでしょう。それはその人や状況によります。
たとえば、ある人が自分の犯した間違い (おそらく彼女はバグを書いてしまったのでしょう)
について説明する投稿をしたとしましょう。
これまでの経験から、あなたは彼女が気の小さい人であることを知っています。
こんな場合は、もちろん簡潔な返信を書くこともできますが
少しは彼女の気持ちを気にかけるようにしたほうがいいでしょう。
あなたの返信の大部分は、簡潔に技術者の視点で見た分析になるかもしれません。
かなり素っ気ないものになることもあるでしょう。そんな場合でも
「簡潔に書いているのは決して君を冷ややかな目で見ているからではないんだよ」
とわかるようなことを最後に何か示しておきましょう。
たとえば、バグを修正するためのアドバイスをひととおり忠告した後の締めの言葉として
「じゃ、がんばってね。<あなたの名前>より」といったことを書いておけば、
決してあなたに悪気があるわけじゃないことが伝わります。
あるいは、意図的に絵文字を使ってみたりして
相手に安心感を与えるという作戦も効果的です。
参加者がどう感じるかについていちいち気にするのを変に感じるかもしれません。
でも、ぶっちゃけた話、人の感情というものは生産性に大きな影響を及ぼします。
感情は他の意味でも重要ですが、あえて実益の範囲に的を絞ったとしても、
不満を感じている人はよいソフトウェアを書くことができないといえるでしょう。
しかし、電子メディアには多くの制約があるので、
人が何を感じているのかを知る手がかりを常に得られるとは限りません。
そこで、a) こんな場合に普通の人はどんなふうに感じるだろうか？
b) 過去のやりとりから、この人はどんな人物だと考えられるだろうか？
といった内容をもとに経験から推測する必要がでてきます。
中にはもっと突き放した態度で、単純に額面通りの対応をすることを好む人もいます。
つまり、彼女が自分で「私、こう思うんです」と言わない限りは
決してそれに対する対応をしないというものです。
個人的にはこの方法はおすすめできません。それにはいくつかの理由があります。
まず、現実の世界ではみんなそんなことはしないでしょう？
何でオンラインだとそうなるんですか？
もうひとつ。たいていのやりとりは公開の場所で行われるので、
たいていの人はプライベートな場所に比べて自分の感情を抑えがちになります。
もう少し正確に言うと、他人に対する感情 (感謝や怒りなど)
は表現してもかまわないと考えているようですが、内心 (不安やプライドなど)
は知られたくないようです。しかし、大半の人たちは
周囲の人が自分のことをよくわかってくれていると感じていればよい仕事をしてくれます。
ちょっとしたことを気にかけるだけで、状況をうまく判断できるようになります。
そして、今以上に人をやる気にさせることができるようになるのです。
もちろん、「プロジェクトのカウンセラーになれ」
「皆がうまくやっていけるよう常に手助けしてやれ」
と言いたいわけではありません。
しかし、皆がどのように振舞っているかを注意深く気にしていれば、
実際に面と向かって会ったことのない人でも
どんな人なのかがなんとなくわかるようになるでしょう。
そして、自分が何か書くときの口調に気を使うようにすれば、
あなたに対する周りの印象は驚くほどよくなります。
これは、プロジェクト全体にとってもよいことです。
何が失礼にあたるのか
オープンソース文化の特性のひとつに、
何が失礼で何が失礼でないかということに関する独特の基準があります。
以下で説明する内容は、ソフトウェア開発やソフトウェア全般に特有のものではありません
(数学や自然科学、工学にかかわっている人たちならおなじみのものでしょう)。
しかし、フリーソフトウェアの世界は人材の出入りが頻繁に行われ、
新しい人たちが常に流入してきます。
こういう考え方になじみのない人たちが流入してくることも大いにありえるでしょう。
まずは、失礼では ない ことについて説明します。
技術的な批評については、
たとえそれが直接的で歯に衣着せぬものであっても失礼にはあたりません。
実際のところ、逆にそれはほめ言葉ともとれるかもしれません。
批評するということは、
それが時間をかけて真剣に議論する価値があるものだと暗に認めているわけです。
そして、それがうまく成長すると、批判よりも賞賛のほうが多くなってくるわけです
(もちろん、その批評が個人攻撃に成り下がってしまったり
その他の明らかに失礼な内容になってしまうこともありえます)。
ぶっきらぼうで素っ気ない質問、たとえば先ほど引用した Shane
のメールのような質問は失礼にはあたりません。
状況によってはちょっと非情に見えたり馬鹿にしているように感じられるような質問であっても、
それは真剣になされたものであり、
必要な情報をできるだけ手早く引き出したいという以外に隠された意図はありません。
サポートセンターの有名な質問である「コンピュータのコンセントはちゃんとささっていますか？」
というのは典型的な例です。サポート係の人は、
ただ単にコンセントがささっているかどうかを知りたいだけです。
仕事を始めたばかりのころはこの質問の前にいちいち丁寧な前置き
("すみませんが、いくつかの可能性を排除するために少々質問させていただいてよろしいでしょうか？
中には基本的すぎるものもありますが、我慢してくださいね……")
をしていたのでしょうが、それにも疲れてきたのでしょう。
今や、彼女は単刀直入に「ささっているのかいないのか」を聞くだけになっています。
フリーソフトウェアのメーリングリストでも、同様の質問が散々行われています。
これは決して相手を侮辱しているのではありません。
最も明らかな (そしておそらく最もありがちな)
可能性をできるだけ早い段階で排除しておきたいというだけのものなのです。
それをよくわかっている人は、文句も言わずにその質問に従い、
よりよい結果を得ることになります。
しかし、もし文句を言う人がいてもそれをけなしてはいけません。
これは、単なる文化の相違であり、どちらが悪いとかいうものではありません。
あなたの質問 (あるいは批評) には隠れた意味はまったくないということを説明してあげましょう。
単に情報を効率的に取得したかった (あるいは伝えたかった) だけであり、
それ以上でも以下でもないと言えばいいのです。
では、何が失礼にあたるのでしょう？
先ほど、技術的な批評をすることは一種のほめ言葉にあたると言いました。
その観点から言うと、真剣な批評をしないということは一種の侮辱になるかもしれません。
これは、誰かの作業 (何らかの提案やコードの変更、バグの報告など)
を単に無視することを言っているのではありません。
あとできちんと返事をすると約束したのでない限り、
何も反応しなくても一向に問題はありません。
周りの人も、単に何か言うだけの時間がなかったんだとみなしてくれるでしょう。
しかし、もし何か反応を返すのなら、決して手抜きをしてはいけません。
時間をかけてしっかり分析し、必要なら適切なサンプルを用意し、
過去ログのアーカイブから関連する議論を探すといった作業を欠かさないようにしましょう。
そんなことをしている時間はないが、でも一言だけいっておきたいという場合は、
メッセージの中に釈明をいれておきましょう
("これ、たしかバグとして報告されていたはずなんだけど、
今ちょっと探しているヒマがないんだ。ごめんね" といった具合に)。
大事なのは、文化的な基準があることを認識することです。
その基準は守ること。そしてもし守れない事情があるときは、
守れないことを認識していると知らせること。
いずれにせよ、基準が大切です。
この基準を守れなかった上にその理由も説明していないとなると、その話題 (そして関係者たち)
に対して十分に時間をかけるだけの価値がないと考えているように思われてしまいます。
怠け者であると思われるよりも、
単に時間がないだけなんだということを率直に説明しておくほうがいいでしょう。
もちろんこれ以外にも失礼にあたることは多々あるでしょう。
しかしその多くはフリーソフトウェア開発に限ったものではありません。
一般常識の範囲で判断できるはずです。
もしまだご覧になっていないのなら、
の
も参照してください。
顔
人間の脳には、表情を認知するための領域があります。
通称は "fusiform face area" です。
その機能の大半は先天的なものであり、後から身につけるものではありません。
個々の人物を見分けるという技能は生き延びるためにきわめて重要なものなので、
専用の特別なハードウェアが発達してきたということだったのです。
インターネットを使用した共同作業は、心理学的にはちょっと奇妙なものといえるでしょう。
だって、緊密な連携をとっている相手のことを、
自然で直感的な方法では決して認識できないのですから。
たとえばどんな顔なのかもわからなければどんな声なのかもわからない、
そしてどんな背格好なのかもわからないといった具合です。
これを補うには、特定の スクリーンネーム
を決めてあらゆる場所でそれを使用するように心がけましょう。
メールアドレスの先頭 (@ 記号より前) の部分や IRC のユーザー名、
リポジトリのコミッター名、バグ追跡システムのユーザー名などなど、
すべての場所でこのスクリーンネームを使用するようにします。
この名前が、オンラインでのあなたの "顔" となります。
短い文字列で、実際の顔と同じ働きをさせるわけです。
残念ながら私たちの脳にはこれに直接反応するハードウェアは内蔵されていないわけですが。
スクリーンネームは、あなたの実名から直感的に得られるものにしましょう
(たとえば私は "kfogel" にしています)。メールヘッダなど、
場合によっては実名を実際に表記することもあるでしょう。
From: "Karl Fogel" <kfogel@whateverdomain.com>
実際のところ、この例には 2 つの内容が存在します。
先ほど説明したように、スクリーンネームは実名と直感的に対応します。
しかし、実名は 実際の名前です。
つまり、これは次のような何らかの作り上げた名称とは異なります。
From: "Wonder Hacker" <wonderhacker@whateverdomain.com>
The New Yorker の 1993 年 7 月 5 日号に掲載された
Paul Steiner の有名な漫画で、ある犬がコンピュータ端末にログインするというものがあります。
影の声がこう言います。"インターネット上では、誰も君が犬だなんて思わないだろう"
この手のことを考える人たちの頭の中にはきっと「オンライン上での立場をよりよくしたい」
「オンライン上で有名になりたい」といった気持ちがあるのでしょう。
"Wonder Hacker" と名乗っておけば周りの人たちに 本当に
凄腕のハッカー (wonderful hacker) だと信じてもらえると思っているようです。
だけど事実は事実。たとえ誰も気づかなかったとしても、
君が犬であることには変わりありません。
オンラインで仮想人格を作り上げたところで、読者を感動させることはできません。
周りの人たちは、あなたのことを単なる夢想家かあるいは臆病者とみなすでしょう。
周囲とのやりとりには実名を使うようにしましょう。
もし何らかの理由で匿名でいたい場合は、
いかにも本名っぽいハンドルを作成してそれを使用するようにしましょう。
オンラインで一貫した "顔" を使用し続けることに加えて、
あなたをより認識してもらいやすくする方法がいくつかあります。
もしあなたが何らかの肩書き ("医師"、"教授"、"監督" など) を持っているのなら、
あまりそれを見せびらかさないようにしましょう。
また、直接それに関する話題になったときは別にして、
肩書きについて言及することも避けましょう。
ハッカー界、そして特にフリーソフトウェア文化においては、
肩書きに頼る人は排他的な臆病者とみなされます。
たとえばメールの最後に書く署名の一部として肩書きが登場するくらいなら問題ありません。
ただ、議論の際に自分の立場をよくするためにその肩書きを使うのは避けましょう。
間違いなくそれは裏目に出ます。
あなただって、肩書きなんかじゃなくあなた自身を認めてもらいたいでしょう？
メールの署名欄について補足します。
できるだけ小さくて上品なものにしておきましょう。
何なら署名なんてなくってもかまいません。
あらゆるメールの末尾に法的な注意書きをでかでかと掲載するようなことは避けましょう。
特に、フリーソフトウェアプロジェクトへの参加と両立しない意見を述べるようなときに、
これは致命的です。たとえば、私が参加している
ある公開メーリングリストの参加者の中には、
すべての投稿の末尾にこんな様式の文書をつけてくる人がいます。
重要な通知:
あなたが誤ってこのメールを受け取ってしまったり、我々のメールに関する
免責条項の声明や監視ポリシーを読みたい場合は、以下の声明文を読むか、
このメールの送信者と連絡を取って下さい。
このメールでのやりとりは Deloitte & Touche LLP から発信されたもの
です。Deloitte & Touche LLP は 登録番号 OC303675 でイングランドと
ウェールズ地方に登録された有限事業組合です。組合のメンバーの名前は以下
の住所で閲覧可能です。Stonecutter Court,1 Stonecutter Street, London
EC4A 4TR, United Kingdom. ここは組合の主たる営業所であり、登録済みの
事務所です。Deloitte & Touche LLP は、金融サービス機構(FSA) が認証
し、管轄しています。
このメールと添付された内容は秘密のものであり、閲覧に特別な許可が必要な
場合があります。これは送信者が意図した受信者のみが利用できます。仮にあ
なたがそうした人でない場合、このメールに含まれているやりとりや情報を開
示したり、コピーしたり、利用したりすることは強く禁じられており、違法行
為です。あなたが仮にこのメールを誤って受け取ったのであれば、"間違って受
けとりました" というタイトルをつけて IT.SECURITY.UK@deloitte.co.uk に返
送するとともに、このメールとそのコピーを破棄してください。
電子メールによるやりとりは、盗聴されたり、破損したり、改竄されたり、配
送の途中で失われたり、配送が遅延したり、中身が不完全な場合があったり、
コンピューターウイルスが含まれることがあるので、エラーがなく安全である
という保証がありません。私たちはこのような事態やそれが引き起こした結果
生じる不利益を受け入れることは出来ません。電子メールで私たちと連絡をと
りあう方々は、全員がこのリスクを受け入れているとみなされます。
私たちの顧客と連絡を取る場合、このメールと添付される内容に含まれるいか
なる意見やアドバイスも、Deloitte & Touche LLP 顧客契約書で示されて
いる諸条件によって制約を受けます。
私たちのビジネスに関係ない意見やアドバイス、その他の情報がこのメールに
記されている場合、それは私たちが発信したものでも、認めたものでもありま
せん。
たまに出てきてちょっと質問するだけという人がこんなことをするのだったら、
馬鹿らしいとは感じるかもしれませんがそれほどの害はないでしょう。
しかし、もしこの人物が本格的にプロジェクトに参加したいと言い出したらどうしましょう？
この法的文書がきっと問題になってくるでしょうね。
ここには、少なくともふたつの危険信号があります。
まず、この人物は自分のツールを完全にコントロールできるわけではないということ。
もしかしたら、社内のメールサーバが強制的にこのメッセージをメールに付加しており、
それを迂回する手段がないのかもしれません。そしてもうひとつは、
彼の所属する組織はフリーソフトウェア活動に関する理解がほとんど (あるいはまったく) ないということ。
もちろんこの組織はメーリングリストへの投稿を明確に禁止しているわけではありませんが、
彼の投稿は明らかに歓迎されざるものでしょう。
まるで、機密情報が外部にもれるリスクの回避が最優先されているようです。
「外向けのメールには必ずこういった文書をつけておけ」
というような決まりのある会社で働いている方は、
無料のメールアカウントを取得してそのアドレスでプロジェクトに参加することを検討しましょう。
無料のメールアカウントは、たとえば gmail.google.com や www.hotmail.com、そして www.yahoo.com などで取得できます。
陥りがちな罠
目的のない投稿をしない
オンラインのプロジェクトに参加するひとたちが陥りがちな罠のひとつに
「すべてのメッセージに返信しなければ！」というものがあります。
そんなことはありません。
第一、数ヶ月を経てある程度の規模になったプロジェクトについて、
すべてのスレッドの議論を追いかけるなんて不可能です。
また、自分が注目しているスレッドについても、
その投稿の多くは別に返信を要求しているものではないでしょう。
開発系のフォーラムでは特に、次のようなメッセージが多くなる傾向があります。
見過ごせない問題についての意見
誰かが言ったことに関する賛成意見あるいは反対意見
これまでの議論のまとめ
これらのいずれについても、本質的には
返信は不要です。注意深くスレッドを観察していれば、
あなたが言いたいことはきっと他のだれかが言ってくれるでしょう
(みんなが同じように考えていたら、結局だれも発言しなくなってしまうんじゃないの？
と思われるかもしれませんが、そんなことはありません。
たいていの場合、何か言わずにはいられない人が
誰かしら 存在するものです)。
明確な目的がある場合にのみ返信を行うようにしましょう。
まずは自分に問いかけることです。
「その返信で何を達成したいのか、きちんとわかっているのか？」
「その目的は、自分が返信しない限り達成できないものなのか？」
あなたがスレッドに口出しをするのに適切な場面は次のふたつです。
a) 提案内容の不備に気づいたが、おそらく他の誰もそれに気づいていないと思われるとき、
そして b) 誰かと誰かの間の意思疎通がうまくいっていないときに、
投稿内容を整理して二人の関係を修復してあげられそうなとき。
あとは、誰かが何かをしてくれたことに対する感謝のメッセージや
ただ単に "私もそう思います！" というだけのメッセージなどを送信してもよいでしょう。
というのも、そういった投稿をすればそのメールに対する返信が不要であることがはっきりするからです。
そして、そのスレッドで最後にメールを投稿した人に対して
「スレッドがきれいにまとまった」という安心感を与えることもできます。
しかし、そんな投稿の際にも、投稿の前によく考えるようにしましょう。
「ちょっと投稿しすぎじゃない？」と思われるより
「もうちょっと発言してほしいな」と思われるほうがずっとマシです
(活発なメーリングリスト上でどのように振舞えばいいのかについての意見は、
の後半をご覧ください)。
生産的なスレッドとそうでないスレッド
活発なメーリングリストで欠かせないのは、次の 2 点です。
まず明らかなのは、注目すべきものとどうでもいいものを見分けること、
もうひとつは、できるだけノイズの 原因
となることを避けることです。自分自身の投稿の S/N 比を高く保つだけでなく、
他の参加者のメッセージの S/N 比も同様に高くしたい。
それができないならいっそのこと投稿しないでほしい。
どうすればいいのかを考えるために、まずは状況を考えてみましょう。
この中で、生産的でないスレッドといえるのはどれでしょうか？
すでに行われている議論をもう一度繰り返す。
まるで、最初に投稿した内容を
誰も読んでいないのではないかと思われるような状態。
話がどんどん誇張されていき、
その議論にかかわる人がどんどん減っていく状態。
実際には何もしない人たちばかりが大騒ぎし、
実際に動くことになる人が黙り込んだままの状態。
はっきりとした提案を出さないまま、
多くのアイデアが議論されている状態
(もちろん、どんな興味深いアイデアだって
最初はぼんやりとした想像から始まるものです。
ここで大事なのは、そこからどう膨らませるかです。
そのスレッドは、ぼんやりとした空想レベルのアイデアを
具体的にまとめあげる流れになっていますか？
それとも、別の想像や関係のない想像などの
どうでもいいことに振り回されていますか？)
うまく機能していないスレッドがすべて無駄なものであるとは限りません。
中には重要な話題が含まれているかもしれません。
そんな場合は、そのスレッドが盛り上がっていないということ自体が問題です。
あまり押し付けがましくならないようにスレッドの流れをよい方向に持っていくのは、
ある種の芸術といえます。単に「無駄な話をするのはやめよう」とか
「もっと前向きなことを投稿するようにしようよ」とか言うだけではうまくいきません。
もちろんこれらを個人的に行うことはできるでしょうが、
ちょっと強く言ってしまうと攻撃的になってしまいます。
そうではなく、前に進むためには次に何をすべきなのかを提案しなければなりません。
あなたが望む結果が得られるような道筋を
(無理やり指示しているような流れになるのを避けつつ)
示してあげるのです。
提案のよしあしを区別するのは、主に口調の問題となります。
たとえば、こんなやり方はよくありません。
これ以上議論しても、収束しないでしょう。
とりあえず、だれかがこの提案を実現するパッチを書くまでこの話題はやめることにしませんか？
同じ議論を何度も繰り返すなんて無意味です。
ごちゃごちゃ言うより、結局はコードでしょ？
それよりは、こちらのほうがいいでしょう。
いくつかの提案はありましたが、結局どれもうまく膨らませることができず、
多数決をとる段階まではいきませんでした。
また、今や新しい意見も出てこなくなっています。
単にこれまでの議論を繰り返しているだけです。
今私たちに必要なのは、この提案に関する完全な仕様か
あるいはパッチを含む投稿でしょうね。そうすれば、
少なくともなんらかのアクション
(その仕様について合意をとったりパッチをテストしたり)
ができるでしょう。
後者のアプローチを最初のものと比べてみましょう。
最初のほうは「私」と「その他のメンバー」の間に一線が引かれていましたが、
後のほうは違います。みんなをうまく議論に巻き込んでいます。
あなたがそのスレッドの議論に最初からかかわっていたかどうかに関係なく、
主語を「私たち」とすることが重要です。これによって、
それまでスレッドをみているだけで何も発言しなかった人たちに対しても
「みんなにかかわる話なんだ」ということを確認させることができるからです。
スレッドが煮詰まってしまった原因については説明していますが、
誰かをののしったり自分の意見を押し付けたりはしていません。
淡々と事実を述べているだけです。
最も重要なのは、前向きに進めるために次に行うべきことを示している点です。
これにより、ただ単に議論を打ち切らせる
(そんな制限をしても、だれも守ってくれないでしょう)
のではなくより建設的な方向に会話を持っていこうとしているのです。
そのスレッドをもっと膨らませたいといった状況ばかりであるとは限りません。
時には、こんなスレッドはさっさと打ち切ってしまいたいと思うこともあるでしょう。
この場合には、スレッドを終了させるための投稿をします。
もしそのスレッドが既にみんなに忘れ去られてしまっているものなら、
あなたが投稿するだけでそのスレッドは事実上終了するでしょう。
もちろん、スレッドを打ち切るための完璧な方法なんてありません。
もしそんなのがあったとしても、使いたいとは思わないでしょう。
しかし「何か目に見える成果を出してください。
でなければこのスレッドを終了します」とお願いすると、うまくいくことでしょう。
ただ、スレッドを終了させるのは十分に考えた後にしてください。
話題によっては、雑談の中から生産的な内容に発展することがあるかもしれません。
あまりに拙速に打ち切ってしまうと、あなたはせっかちな人と思われてしまいます。
どんなスレッドであっても、すぐに終了するとは期待しないでください。
あなたが投稿した後にも、おそらくいくつかの投稿があるでしょう。
あなたのメールがまだ届いていなかったり、あるいはいわゆる
「最後にひとこと」が言いたかったりといった人たちによるものです。
心配することはないですし、先ほどの投稿を繰り返す必要もありません。
スレッドが収束する (あるいはさらに膨らんでいく) のを黙って見守っていればいいのです。
完全にスレッドをコントロールすることなんてできません。
ただ、あなたは多くのスレッドに何らかの効果を及ぼせるはずです。
簡単な議題ほど長引く
どんな議題であっても議論は紆余曲折するものですが、
技術的な難度が低い話題になればなるほど
議論が発散する可能性があがります。
結局のところ、技術的な難度が高い話題になればなるほど
その話題についていける人の数が少なくなるということです。
そんな話題についていける人というのは、たいていは長年経験を積んだ開発者です。
彼らはこれまでに何度となくそのような議論に参加しており、
全員が納得のいく合意を得るにはどうしたらいいのかを知っているのです。
というわけで、合意を得ることが最も難しいのは、
誰にでもわかる (誰でも意見が言える) レベルの技術的な問題となります。
また同様に、組織論や広報活動、資金調達などの "やわらかめ"
な話題も合意を得にくいものです。
これらの話題については、人はいつでも気の済むまで議論に参加することができます。
議論に参加するための前提条件もなければ
何が正しくて何が間違っているのかを (後になっても) 決めることもできない、
そして、他人の意見を聞いてから「後出し」で議論に参加することもできるからです。
議論の量と話題の複雑さが反比例するという原則はよく知られており、俗に
Bikeshed Effect (自転車置場効果) と呼ばれています。
ここで、Poul-Henning Kamp による説明を見てみましょう。
もともとは BSD 開発者向けに投稿されたものですが、今や超有名になっています。
話せば長くなる昔話だけど、実際のところは単純な話だ。C・ノースコート・
パーキンソンが 1960 年代初期に書いた「パーキンソンの法則」という本があって、
そこにはものごとの管理に関するさまざまな洞察が書かれていたんだ。
[...]
自転車置場の例にでてくるもう一方の役者が、原子炉だ。なんだか、
いかにも時代を感じさせるなぁ。
パーキンソンは、委員会に乗り込んで数百万から数億ドルもの原子炉建設計画を承認させる方法を説明している。
しかし、
原子炉ではなく自転車置場を作りたいと思ったら終わりのない議論に巻き込まれることになるだろうとも言っている。
パーキンソンによると、原子炉はあまりに巨大で高価そして複雑であるために
みんながその内容を把握できなくなるということだ。考えようともせずに思考停止してしまい、
「まぁここまで来る前に誰か他の人が一部始終をチェックしただろう」
ということになってしまう。リチャート・P・ファインマンの著書には、
これに関連するロス・アラモスでの興味深い事例がいくつか紹介されている。
さぁ一方自転車置場だ。週末をつぶせばだれでも作ることができ、
余った時間にテレビで試合を見て楽しむことさえできるだろう。
どんなに用意周到であったとしても、どんなに妥当な提案だったとしても、だれかが機会をとらえては、
自分もなにかやっていることを示したり、自分もそれに注目してることを示したり、
「俺を忘れるな」と言ったりするだろう。
デンマークでは、こういったことを「指紋をつける」って言うんだ。
個人的なプライドや見栄のために何かをして、あとからその証拠を見せられるようにする。
「ほら見ろよ。これ、俺がやったんだ」てな具合にね。
政治家どものよくやりそうなことでもあるが、一般人だって機会があればやりそうだよ。ほら、
よく生乾きのセメントに足跡がついてたりするだろう？
(彼の投稿の完全版はかなり長くなりますが、一読の価値はあります。
でご確認ください。また
も参照ください)
これまでにグループでの議論に参加したことがある人なら誰でも
Kamp の言っていることがよくわかるでしょう。
しかし、自転車置場に色を塗るようなことを避けるよう
全員 を説得するのは不可能です。
できることといえば、そんな状況を見つけたときに
「こういう状態になっているんじゃない？」と指摘するくらいです。
そして、影響力の強い開発者たちに対して
「早めに筆をおろしてくれませんか？」とお願いするのです。
そうすれば、少なくとも彼らはノイズの原因とはならなくなります。
自転車置場の塗装大会を完全にやめさせることはできないでしょうが、
プロジェクトの文化をうまく育てていけばそんな羽目になる頻度を下げる
(そして発生したときも早く収束できるようにする) ことができます。
宗教論争を回避する
宗教論争 (holy war: 聖戦) とはある種の論争のことです。
ただ、時には話し合いで解決できないほど大きな問題になることもあります。
お互い、相手側を打ちのめすまで議論を続けようとします。
これは、先ほどのいわゆる「自転車置場問題」とは多少異なるものです。
自転車置場の議論に加わっている人たちは、先を競って自分の意見を表明します
(だって簡単に意見を言えるから)。
でも、彼らは必ずしもそれを強く主張するわけではありません。
時には相手の意見に理解を示すこともあります。
しかし「宗教論争」においては、相手の意見に耳を傾けた時点で負けです。
みんな「正解はたったひとつである」という点では合意しているのですが、
ただ「正解がどれか」という点で争っているのです。
いったん宗教論争が始まってしまったら、
みんなが満足するようなかたちでそれを収束させることは不可能です。
炎上している真っ只中で「これって宗教論争じゃない？」
と指摘したところで無意味です。
そんなこと、みんなとっくに知っているわけなんだから。
残念なことに、宗教論争の多くは
「この問題は話し合いを続ければ解決できるのか」
という点に対しても意見の対立が発生するものなのです。
第三者からみれば、どちら側も相手を説得できそうにないのは明らかです。
当事者たちは「相手側は何もわかっちゃいない。
うまく説得すればきっと私たちの考えをわかってくれるだろう」とお互い考えています。
私は「こんな争いには正解なんてない」とは 言いません。
時には正解があることもあるのです。
私も過去に何度か宗教論争に巻き込まれましたが、
そのときはいつも私たちのほうが正論でした。
とはいえ、そんなのはどうでもいいことです。
どちらが正しいのかを納得いくように説明する方法なんてないのですから。
宗教論争を解決しようとしてやりがちなことは
「こんなことをいつまでも続けていても時間のムダじゃないか！
もういい加減やめてしまわない？」
と言うことですが、これでは不十分です。
このやりかたには 2 つの問題があります。
まず、これまで議論に費やしてきた時間や気力は取り戻せないということです。
いま大事なのは「あとどれだけ議論しなければならないのか？」です。
もし「もうちょっと話をすれば解決できそうだ」と感じている人が何人かいるのなら、
(少なくとも彼らの視点からは) 議論を続けるのは理にかなっています。
もうひとつの問題は、
そこで議論をやめてしまう (現状維持とする) ことが、
どちらか一方に事実上の勝利宣言をするのに等しいことがあるということです。
また時には「とにかく現状をどうにかしなければならない」という点では合意しているが
「どのように変えるのか」で争っているということもあります。
こんな場合は、議論を打ち切ってしまったら誰の得にもなりません。
そのことはみんなわかっているので、この場合は議論を続けることも可能でしょう。
じゃあ、いったいどのように処理したらいいのでしょう？
まず言えることは、そんな議論が起こりえないようにするということです。
これは、皆さんが思っているほど難しいことではありません。
宗教論争になりがちなネタは、だいたい予想がつきます。
プログラミング言語についてだったりライセンスについてだったり
( の
をご覧ください)、
あるいは reply-to の処理についてだったり
( in
の をご覧ください) などです。
たいていのプロジェクトは一度や二度はこういう経験をしており、
それによって開発者たちの結束が急速に深まったりします。
このような争いをやめさせたり、
あるいは被害をできるだけ抑えたりするための方法は、どこに行っても同じです。
たとえ自分側の意見が正しいと確信しているのだとしても、
とりあえずは 相手側の意見にも耳を傾け、
理解を示すようにしましょう。この手の争いでよくある問題は、
それぞれの側が可能な限り敷居を高くしてしまって
自分たち以外の考えはみんなまったくばかげていると言い切ってしまうことです。
このような場合、相手側を説得したり意見を変えさせるようにしたりするのも
難しくなってしまいます。つまり、単に相手に「まちがっていました」
と認めさせるだけではなく「心から
まちがっていました！」と認めさせなければならなくなるのです。
相手側に説得を受け入れてもらいやすくするには、
まずあなた自身の確信を押し付けないようにすることです。
つまり、現在行われている議論の内容をきちんと理解していること、
そして説得力があるかどうかはともかく、少なくとも分別はあるということを示すことです。
相手が返事を返す余地があるような意思表示をするようにしましょう。
そうすれば、状況は改善するでしょう。
結果としてあなたが望んでいたそのものは得られないかもしれませんが、
少なくとも、プロジェクトの士気に影響を及ぼすような巻き添え被害は防ぐくとができます。
宗教論争が避けられない状況になったら、
あなたがどの程度それにかかわるのかを早めに決断しましょう。
なんだったら、その手の議論を正式に放棄してしまってもかまいません。
そうすれば、皮肉を言ったり
反対意見に対して捨てゼリフを残したりせずに
きれいに宗教論争から身を引くことができます。
議論を放棄する場合は、潔く行うことが大切です。
プログラミング言語に関する宗教論争は、少し事情が異なります。
というのも、彼らは技術的に高いレベルにある人であることが多く、
また多くの人が何らかの意見を持っており、利害関係が非常に高くなるからです。
その争いの結果、プロジェクトで使用する主要なプログラミング言語が決まってしまうかもしれません。
一番いい方法は、プロジェクトの初期段階のうちに
開発者間で言語を選択してしまうことです。そして
いったん決めた開発言語については、「それが他の言語より優れているから」
という理由 ではなく、
「それがいちばん書き慣れているから」という理由で守っていくようにします。
決して「プログラミング言語を学術的に比較する」といった方向に陥らないようにしましょう
(なぜだかよくわかりませんが、誰かが Perl を持ち出したとたんに
この方向に話が進むことが多いようです)。
この手の話題はまったく無駄なものであり、避けるべきです。
この手の議論に関する歴史的な背景については
をご覧ください。また、Danny Cohen によるより簡単な解説が
にあります。
"口やかましい少数派" について
メーリングリストでの議論においては、
少数派の意見がいかにも大きな異議であるように見せることは簡単です。
長々としたメールをメーリングリストに大量に投稿すればいいのです。
これは議事進行妨害と似ていますが、
反対意見が大きくなっていると思い込ませることにはより強力な意味があります。
というのも、あまりにたくさんの意見が行きかうと
「誰がいつ何を言ったのか」を追いかけるのが面倒になってしまうからです。
「よくわからないけど、何だか重要なことを議論しているんだな」
と本能的に感じ、騒ぎがおさまるまでしばらくおとなしくしている人が多くなるのです。
このような効果をうち消す最もよい方法は、何らかの証拠をもって
「異議を申し立てている人がどれだけ少数であるかということ」
「他の大半の人たちが合意しているということ」
を明確に指摘することです。より状況を明確にするために、
明確に意見は表明していないがおそらく多数派に合意するであろうと思われる人たちに
個別に意見を聞いてみてもいいでしょう。
反対している人たちが自分の意見を故意に膨らませようとしているといったことを
指摘するのはやめましょう。多分彼らはそんな気持ちはないでしょう。
たとえ意図的にしているのだとしても、
それを指摘したところで戦略上なんの利点もありません。
あなたがすべきことは、単に実数を比較して示すこと。
そうすれば、他の人たちは自分の実感とずれていることをわかってくれるでしょう。
この手法は、賛成か反対かがはっきりするような議論に関しては適用できません。
この方法がうまくいくのは、誰かが大騒ぎしているものの
大半の人にとってはそれが議論すべき問題なのかどうか判断できないといった場合です。
議論をしばらく見ていて、それが
(メールの数のわりには) あまり人々の気を引いていないものであって
どうでもいい議論であると判断したら、それをはっきりと示してあげましょう。
いわゆる "口うるさい少数派" が目立っているときには、あなたの投稿が一服の清涼剤となるでしょう。
こんな場合、たいていの人はちょっと落ち込んでいます。「なんてこった。
大量の投稿があるので多分重要なことを話しているんだろうけど、
いったい何がどうなっているのかちっともわかりゃしない」といった気分です。
実際の議論が必要以上に大げさになりすぎていたことを説明すれば、
彼らはそれまでの流れを見直して
何が起こっていたのかを理解してくれるでしょう。
扱いにくい人たち
扱いにくい人たちに対して電子会議室上で対応するのは、
面と向かって対応することに比べて多少難しくなります。
ここで言う "扱いにくい" とは "失礼な" という意味ではありません。
確かに失礼な人たちは不快なものですが、彼らが必ずしも扱いにくいというわけではありません。
本書では、すでに失礼な人たちへの対処法は説明済みです。
とりあえず一言指摘したあとは、そのまま無視してしまうか、
何事もなかったかのように他の人たちと同じよう接すればいいのです。
それでも彼らが失礼な振る舞いを続けるようなら、
彼らはきっとそのプロジェクトの誰にも見向きもされなくなるでしょう。
自業自得です。
本当にやっかいなのは、あからさまに失礼な態度であるとはいえないが
プロジェクトの進み具合に悪影響を与えている人たちです。
彼らは他の人たちの時間や労力を余計に費やさせるだけで
プロジェクトに何の利益ももたらしません
扱いにくい人たちの一例について、Amy Hoy が愉快な記事
Help Vampires: A Spotter's Guide
で的確に指摘しています。Hoy 曰く、
「それはきっと、時計の時刻合わせをするのと同じくらいに普通のこと。
コミュニティの衰退は、放射性同位体の減衰と同じくらいに予測可能なこと。
オープンソースのプロジェクトなり言語なりがそれなりの知名度を得るようになると
— 半減期を迎えると、と言ってもいい —
奴らはやってくる。そしてコミュニティの気力をそぐようになる。
奴らは Help Vampire。そして、それを阻止するために私はここにいる...」
。
そういった人たちは、プロジェクトを進めるにあたって要となる箇所を探しては
そこで自分の影響力を誇示しようとします。
このような行いは、単に失礼であるだけの人よりよっぽど油断なりません。
なぜなら、その振る舞いだけでなくそれによる被害も明白だからです。
このような行いの典型的な例は、いわゆる議事進行妨害です。
進行中の議題について、誰かが (いかにももっともらしく聞こえるように)
「まだ結論は見えていない。もっと別の解決策も検討してみるべきだ。
違う視点から見直してみるのもいい」といった意見を述べるが、
実際のところは既にほぼ合意がとれているかあるいは採決をとる準備ができているといった状況です。
別の例を考えてみましょう。なかなか合意が得られない議論において、
「まずはお互いの意見の不一致を確認してこれまでの議論のまとめを作成しよう」
という流れになることがあります。
そのまとめを作成した結果、自分が気に入らない方向に進むかもしれないと考えている人は、
まとめの作成作業さえも邪魔しようとするかも知れません。
妥当な提案に対していちいち反対したり、
誰も喜ばないような新たな話題を持ち出したりなどといった手段で粘着してくるわけです。
扱いにくい人たちへの対応
こんな振る舞いに対抗するには、
何が彼らをそうさせるのかを理解することが助けになります。
たいていの人は、意識してそのように振舞っているわけではありません。
毎朝起きたときに「さあ、今日も斜に構えて議論をかき乱し、
みんなをいらいらさせてやろう」と考える人なんていませんよね。
そんな行動に彼らを導くのは、たいていの場合は
「自分はこのグループでの議論や意思決定の際に仲間はずれにされているのではないか」
という被害妄想です。彼らは自分がないがしろにされていると感じています。
あるいは (もっと深刻な場合は) 自分だけをのけものにして
他のメンバーだけで何かをしようとたくらんでいると感じることもあります。
そう感じている彼にとって、プロジェクトの進行に口をはさんで
何とか 自分のほうに目を向けてもらえるようにすることは
完全に正当な振る舞いです。極端な場合は、彼は
「自分が戦わなきゃこのプロジェクトはダメになってしまう」と思い込んでいるかもしれません。
こういった攻撃は、その性質上みんなが一斉に気づくものではありません。
人によっては、明白な証拠があらわれるまでそれを認めないかもしれません。
つまり、このような攻撃を何とか収めるのはそれなりの作業になるということです。
何かが起こっていると自分が気づくだけでは不十分で、
他のメンバーを納得させるだけの証拠を用意する必要があるのです。
その証拠を示す際には十分な注意が必要です。
戦うだけの余力がない場合、とりあえずはしばらく見過ごしておくのが得策です。
ちょっとした感染性の病気と同じようにとらえらばいいのです。
プロジェクトが極端に衰弱していない限り、
病気に感染してもなんとかなります。
下手に薬に頼ると、何らかの副作用があるかもしれません。
しかし、無視できない程度の被害が出始めたら、それが動き出すときです。
まず、目にしている状況をしっかり書き留めてください。
公開しているアーカイブを参照するようにしましょう。
このような場合のためにも、プロジェクトの活動をアーカイブしておくことが大切になります。
よい手がかりが見つかったら、
次にプロジェクトの他のメンバーと個人的な話し合いをします。
このときに「こんな風に感じるんだけど……」と話すのではなく、まず
「最近何か感じることはない？」というように問いかけるようにします。
トラブルメーカーの行いについて他人がどう思っているのかについて聞けるのは、
これが最後のチャンスになるかもしれません。
あなたがいったんトラブルのことについて話し始めると
どうしても相手の意見は変化してしまい、
もともとどう考えていたのかを思い出せなくなってしまうでしょう。
個人的な話し合いの結果、
同じような問題を感じている人が少なからずいるとわかったとしましょう。
そろそろ何か行動をおこすときです。
このときは ほんとうに 用心深くならなければなりません。
この手のトラブルメーカーは、しばしば「自分が不当にいじめられている」
と思い込んでしまいがちだからです。何をするにしても、
「プロジェクトの動きを故意に妨害している」「被害妄想に陥っている」
あるいはその他あなたが疑っていることが事実であると決め付けて責めたりしてはいけません。
あなたの最終的な目標は、もっと妥当なもので
かつプロジェクト全体の利益のためになるものでなければなりません。
彼らの振る舞いを改めさせるか、あるいは追い出してしまうか。
最終的にはどちらかになるでしょう。
あなたと他の開発者たちとの関係によっては、
事前に個別に手を組んで共同で責めていくことも有効かもしれません。
ただ、それが裏目に出ることもあります。
裏でこそこそと何かをして中傷しているようにとられたら、
あまりよく思われないかもしれません。
たとえまずい行動をしたのが手を組んだ相手のほうだったとしても、
言い出したのがあなたである以上、周りから見ればまずい行動をしたのは
あなた だということになります。
自分のいいたいことを示す例をできるだけ多く集めるようにしましょう。
そして、できるだけやさしく紳士的に説得するようにするのです。
もしかしたら問題の当事者を説得しきれないかもしれません。
しかし、その他大勢の人たちを説得できればそれで十分です。
実例
私がフリーソフトウェアにかかわりだしてから 10 年以上たちますが、
私が覚えている限り、これまでにこのようなことが起こったのは一度だけです。
そのときは、実際に投稿をやめてもらうよう働きかけるはめになりました。
このような場合によくありがちなことですが、
実際のところ彼はまったく悪気はなく、良かれと思ってやっていただけでした。
彼は単に、投稿すべきときと控えるべきときの区別ができなかったのです。
私たちのメーリングリストは一般に公開されており、
彼は非常に頻繁にそこに投稿していました。
さまざまな内容について質問を繰り返すこともあり、
コミュニティーの間で徐々に目障りに感じられるようになってきました。
質問を投稿する前に少しは自分で調べるようにやさしくお願いしてはみたのですが、
彼には何の効果もありませんでした。
最終的に有効だったのは、完全に中立で定量的なデータを示すことでした。
開発者のひとりがアーカイブを調べ、
以下のようなメッセージを何人かの開発者に個別に送ったのです。
問題の人 (以下の一覧における 3 番目の人。ここでは仮に "J. Random" とします)
がプロジェクトにかかわり始めてから日がまだ浅いこと、
そしてコードやドキュメントに一切貢献していないこと。
なのにメーリングリストの投稿ランキングでは 3 番目になっていることがわかります。
From: "Brian W. Fitzpatrick" <fitz@collab.net>
To: [... 匿名性を確保するため、送信先は省略します ...]
Subject: The Subversion Energy Sink
Date: Wed, 12 Nov 2003 23:37:47 -0600
過去25日間の svn [dev|users] リストの投稿数トップ6は以下のとおりです。
294 kfogel@collab.net
236 "C. Michael Pilato" <cmpilato@collab.net>
220 "J. Random" <jrandom@problematic-poster.com>
176 Branko Čibej <brane@xbc.nu>
130 Philip Martin <philip@codematters.co.uk>
126 Ben Collins-Sussman <sussman@collab.net>
この中の5人は、近々発表予定の Subversion 1.0 に貢献してくれている人たち
です。
また、この中の1人は、他の5人の足を引っ張って時間と気力を浪費させているだ
けの人です。彼のおかげでメーリングリストが停滞するだけでなく、無意識のう
ちにSubversionの開発自体も速度が低下してしまっています。詳細な解析をした
わけではありません。ただ、Subversionメーリングリストのスプールをざっと
grepしてみたところ、この人物がメールを投稿するたびに、他の5人の中の少な
くとも2人が返信をするはめになってしまっているようです。
そろそろ何らかの行動を起こすべきときじゃないでしょうか？ たとえそれで当
該人物がここから去ってしまうことになってもやむを得ません。控えめにやさし
く説得するだけでは何の効果もないことはすでに証明されています。
dev@subversion はバージョン管理システムの開発を手助けするためのメーリン
グリストであり、グループセラピーを行う場所ではありません。
- 3日もの間、大量のメールと格闘し続けた Fitz より
最初のうちは気づかなかったのですが、J. Random (仮名)
の振る舞いはプロジェクトの進行を妨げる典型的なものでした。
彼は、議事の進行を妨害しようとするなどの具体的な行動をとったわけではありません。
ただ「各メンバーに節度を持った対応を期待する」という
メーリングリストの方針をうまく利用していたということです。
私たちは「どんなネタをどんなときに投稿すべきか」といった判断は
完全に各個人に任せていたのです。
したがって、誰かが不適切な投稿をしたり
それを改善するそぶりを見せなかったりしても、
私たちはどうすることもできなかったのです。
彼が頻繁に投稿を繰り返すことを他のメンバーはみんな気にしていたのですが、
「それは○○という規則に違反している」と指摘する根拠はなかったのです。
当時の Fitz のやり方は、巧妙なものでした。
彼はまず定量的な証拠を集めました。そして、それを慎重に広めたのです。
まずは、仲間になってくれると心強いと思われるごく一部の人たちにだけ
それを伝えるようにしました。
何らかの対応が必要だと合意した彼らは、J. Random
に電話をかけて問題点を直接指摘し、投稿を控えてくれるよう頼みました。
彼は、なぜそんなことを言われなければならないのかをわかっていないようでした。
まあ、もしわかってくれるだけの人であれば、
最初からこんな問題は起こらなかったでしょうけどね。
結局、彼は投稿をやめることに同意してくれました。
そしてメーリングリストは通常どおりに戻ったのです。
最終的にこの作戦がうまくいった理由のひとつは
「彼の投稿をスパム対策用のソフトウェア
( の
をご覧ください)
で拒否することもできるんだよ」
という圧力を遠まわしに与えたことにもありました。
しかし、このような圧力を与えることができたのも、
Fitz が最初に主要人物に根回しをしておいたからこそです。
巨大化への対応
オープンソース界では、成功の代償は重いものです。
あなたの書いたソフトウェアが有名になればなるほど、
その情報を知りたがる人の数も劇的に増加します。
一方、みんながほしがっている情報を提供できる人の数は、
それほど急激に増えることはありません。
さらに、たとえ情報をほしがる人と情報を提供する人の増加率が
うまい具合にバランスがとれていたとしても、
オープンソースプロジェクトのメンバー間でのコミュニケーションは
人数が増えれば増えるほど面倒になります。
たとえばメーリングリストを考えてみましょう。
たいていのプロジェクトには、一般的なユーザー向けのメーリングリストがあります。
いわゆる "users" とか "discuss" とか "help"
などといった名前のメーリングリストです。
名前が何であるかにかかわらず、これらのメーリングリストの目的は同じです。
疑問がある人が質問をすれば何らかの答えが得られるということ、
そして、それらのやり取りをただ眺めていることで
それなりの知識を得られるということです。
この手のメーリングリストのメンバーは数千人になることも珍しくありません。
また、一日あたりの投稿数が数百になることもよくあります。
しかし、このくらいの規模になってくると、システムは徐々に破綻しはじめます。
個々のメンバーが一日にさばききれない量のメッセージを受け取るようになると、
メーリングリストのメッセージがその人にとって重荷になってしまうでしょう。
考えてもみましょう。たとえば、Microsoft が Windows XP
用にこの手のメーリングリストを開設したとします。
Windows XP を使っている人は、世界中に何億人といます。
そのうちのほんの 0.1% の人が 24 時間のうちにひとつの質問を投稿したとすると、
この仮想メーリングリストの一日の投稿数は10万通にもなってしまいます!
もちろん、実際にはそんなメーリングリストは存在しません。
もしあったとしても、だれもそんなメーリングリストのメンバーでい続けることはできないでしょう。
これはメーリングリストに限った問題ではありません。
IRC チャンネルやオンラインの掲示板、
その他個人からの質問を受け付けるあらゆるシステムには同じ論理があてはまります。
この論理が示唆するところはあまり思わしくありません。
オープンソースモデルでしっかりとしたサポートを続けようとすると、
世界征服できるほどにまでプロジェクトの規模を拡大するのは不可能だということです。
メーリングリストや掲示板の規模が臨界点に達しても、
大爆発が発生するといったことはありません。
負の反応は、静かに出てくることになります。
たとえばメーリングリストから脱退する人や
IRC チャンネルから去る人が出てきたり、
ノイズが目障りだという理由で質問を控える人が出てきたりといった具合です。
人がみなこのように合理的な選択をすれば、
掲示板の規模はある程度管理可能な範囲で落ち着くのでは?
と考える人がいるかもしれません。
しかし、このような場合にまずメーリングリストから去っていくのは、
たいていの場合は経験を積んだメンバーです。
一方、参加して日が浅い人たちはそのままそこに残ったままでいるでしょう。
つまり、プロジェクトの規模が大きくなりすぎても
まだ同じコミュニケーションモデルを使用していると、
その場における質問や回答のレベルが徐々に低下していくということになります。
まるで、(実際にはそうではないかもしれないのに)
新参者のほうが古参メンバーより劣っているというように見えてしまうかもしれません。
このような状況になると、古株のメンバーは
そこに参加するメリットをあまり感じられなくなり、
どこか他の場所を探すようになるでしょう。
プロジェクトの規模が拡大したときにコミュニケーションの仕組みをどうするか。
これには、次のふたつの戦略がかかわってきます。
全体としては巨大化の悪影響が出てきつつあるようだが、
特定の分野の話題についてはまだその影響を受けていない
というところを見つけたら、その分野の話題だけに特化した会議室を新たに作成する
(つまり、被害が及ばないうちに他の場所に避難させる)。
情報を自動的に取得できる場所を多く確保し、
それをきちんと系統立てて管理する。
また、常に最新の情報を反映させ、人が見つけやすいようにする。
作戦 (1) は、通常はそんなに難しくありません。
たいていのプロジェクトは、最初はメーリングリストがひとつだけで始まります。
そこでは、一般的な議論のほかに、機能追加の要望や設計に関する疑問、
コーディングに関する問題などさまざまな内容をごちゃ混ぜにして扱います。
そしてプロジェクトにかかわるすべての人たちがそのメーリングリストに参加しています。
しばらくすると、扱う内容によって
いくつかのメーリングリストに分割したほうがよいということがわかってきます。
たとえば、あるスレッドでは開発に関連する話題が盛り上がっており、
別のスレッドでは、いわゆる「○○をするにはどうすればいいの？」
的な質問が行われ、また別のスレッドではバグレポートや機能追加要求が行われていたりといった具合です。
中にはこれらのスレッドの複数に参加する人もいるかもしれませんが、
ここで重要なのは、これら異なるタイプのスレッドには
共通点がほとんどないということです。
ということで、これらの話題をそれぞれ個別のメーリングリストに分割しても、
特に弊害は出ないでしょう。
この分割は、二段階の手順を踏んで行います。
まず新しいメーリングリスト (あるいは IRC チャンネルなど) を作成し、
次にそのメーリングリストを適切に使用するよう、
他の人たちを誘導することになります。
後半の作業は数週間程度の時間をかけて行うことになりますが、
それくらいあれば人はみなその考えを理解してくれるでしょう。
あなたがすべきことは、間違った場所に投稿してきた人に対して
他人にも見える場所でそれを指摘してあげることです。
そうすれば、他の人たちはいちいち指摘されなくても新しい場所を利用することになるでしょう。
すべてのメーリングリストの一覧をまとめたウェブページを作成するのも有用です。
他の人に新しい場所を指定する代わりに、そのページを参照させるだけでよくなります。
うまくいけば、他のメンバーも投稿の前にそのページを参照してくれるようになるかもしれません。
作戦 (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 のソースファイルの取得が容易であり
(
の をご覧ください)、
また編集しやすいものでなければならないということです。
名前付きアンカーと ID 属性
ウェブページ内の特定の場所に直接移動させるには、
名前付きアンカーを使う方法と id 属性を使う方法の二通りがあります。
名前付きアンカー は単なる HTML の
アンカー要素 (<a>...</a>)
と同じで、そこに "name" 属性を追加したものです。
<a name="mylabel">...</a>
最近のバージョンの HTML では、より汎用的な id
属性 をサポートしており、<a>
だけでなく任意の HTML 要素で使用することができます。
たとえば次のように使用します。
<p id="mylabel">...</p>
名前付きアンカーと id 属性の使用法は、どちらも同じです。
URL の最後にハッシュマーク (#) に続けてラベルを指定すると、
ブラウザはページ内のその場所に直接移動するようになります。
http://myproject.example.com/faq.html#mylabel
名前付きアンカーは事実上すべてのブラウザがサポートしており、
最近のブラウザのほとんどは id 属性にも対応しています。
万全を期すなら、名前付きアンカーだけを用いるか
名前付きアンカーと id 属性を 併用 する
(もちろん、そのときは両者に同じラベルを指定する)
ことをおすすめします。名前付きアンカーについては、
開始要素と終了要素をひとつにまとめることはできません。
たとえ要素内のテキストが存在しない場合でも、
以下のように開始要素と終了要素を別々に書かなければなりません。
<a name="mylabel"></a>
……とはいえ、普通はここには (セクションのタイトルなど)
何らかのテキストが入るものです。
名前付きアンカーを使うにしても id 属性を使うにしても、
ラベルを指定してアクセスしない限りはブラウザ上でそのラベルは見えないことに注意しましょう。
しかし、たとえば FAQ の特定の回答をメールで示したい場合など、
その場所のラベルが何なのかを知りたいこともあるでしょう。
このような場合のために、"name" や "id" 属性を指定した場合は
title 属性 も同じ要素に指定しておくとよいでしょう。
たとえば次のようにします。
<a name="mylabel" title="#mylabel">...</a>
title 属性を指定した要素内のテキストの上をマウスポインタが通過すると、
たいていのブラウザでは title 属性の内容をポップアップ表示します。
私は、この title 属性の内容にハッシュマークも含めるよう心がけています。
それを見たユーザーが、URL の最後にそれをつなげれば
直接この場所に到達できるということに気づきやすくするためです。
ここでは FAQ についてのみ取り上げましたが、
これは、リソースの体裁を整えるほんの一例にすぎません。
ここで取り上げた内容 (直接検索できること、
主要なサーチエンジンから検索できること、閲覧しやすいこと、
特定の場所を参照しやすいこと、適切に編集しやすいこと)
は、ウェブページ全般やソースツリー、
バグ追跡システムなどでも当てはまるものばかりです。
メーリングリストのアーカイブ用ソフトウェアの多くは、
これらの項目の重要性に大昔から気づいていました。
そのため、メーリングリストのアーカイブ用ソフトウェアの多くは
これらの機能を自前で搭載しています。
その他の形式の文書については、
担当者がそれなりに手間をかける必要があるかもしれません
(このような作業をボランティアに任せていくための方法については
で説明します)。
しきたりの成文化
プロジェクトが歴史を積み重ねて複雑さを増していくにつれて、
新規参入する人たちが覚えなければならないデータの量も増加します。
長年そのプロジェクトにかかわっている人たちは、
プロジェクトの成長とともにそのしきたりを作り上げたり学んだりすることができました。
彼らは往々にして、今まで築き上げてきた伝統がどれほど巨大なものかに気づいていません。
そして、新たに参加してくる人たちがその伝統を守らないのをみて驚くのです。
もちろんこれは、最近の人たちが古株よりも劣っているということではありません。
プロジェクトの初期に比べ、新規参入のハードルが高くなっていることが問題なのです。
プロジェクトが積み上げていく伝統には、
コミュニケーションの方法や、
コーディング規約および他の技術情報を蓄積する方法もあります。
これらについては、それぞれ
の および
の で例を挙げて説明しました。
このセクションでは、プロジェクトの成長に伴って
これらのガイドラインをいかに最新の状態に保つかを説明します。
特にコミュニケーションに関するガイドラインは重要です。
というのも、これはプロジェクトの規模や複雑さが大きくなるにつれて変わっていくものだからです。
まずは、みんなが何に困っているのかを調べましょう。
同じような状況で (特に新入りのメンバーが) 困っていることに気づいたら、
それは「ガイドラインをきちんと設定すべきなのに、まだできていない」
という証拠です。
次に、同じことを何度も何度も繰り返して言うのをいやがらないようにしましょう。
いやいや言っているように思われてはいけません。
新入りさんがどんどん入ってくる以上、
あなたや他のベテランメンバーが同じことを繰り返すはめになるのは避けられません。
すべてのウェブページ、メーリングリストへのすべての投稿、
そしてすべての IRC チャンネルには告知用のスペースを設けるようにしましょう。
これは商業的な広告を行うものではなく、
そのプロジェクト自身のリソースについて告知するための場所となります。
そこに何を載せるのかは、それをどのような人たちが読むのかにあわせて決めます。
たとえばユーザーからの質問を受け付ける IRC チャンネルの場合、
それを利用する人の多くはこれまでにそのプロジェクトにかかわったことがない人となるでしょう。
単にインストールしてみただけであることも多いでしょうし、
たいていは「今すぐに」回答を欲していることでしょう
(ちょっとでも待てるのなら、普通はメーリングリストに質問するでしょうから。
答えが返ってくるのに多少時間がかかることさえ我慢できれば、
こっちのほうが手間がかかりません)。
普通の人は 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 プロジェクトでは、
の
で説明したバグフィルタリング技術で
ある程度うまくいっていました。
ただ、それでもバグとは言えないような内容がたびたび登録されてしまっていました。
そんなことがあるたびに、担当者がいちいち彼らに教えてやる必要があったのです。
そう、これまで 500 人もの人に言ってきたのと同じことを。
ある日のこと。そんな状況に業を煮やしたある開発者が、
バグ追跡システムのガイドラインを読まずに投稿するユーザーに対してキレはじめたのです。
それを見た他の開発者たちは、この方式ではもはややっていけないことに気づきました。
彼は提案しました。バグ追跡システムのトップページの目立つところに
「メーリングリストや IRC で十分に議論してからバグを登録するように」と書いてやろうと。
そう、黄色い背景に赤の太字で。すべてのページの先頭にでかでかと。
私たちはそれを実行しました (その結果は
でご覧いただけます)。
その結果。本来のバグ以外が登録されてしまうことが激減したのです。
もちろん、(期待通り) 現在もそれは続いています。
しかも、ユーザー数が増えているにもかかわらず、ゴミの量は目に見えて減っています。
その結果、バグデータベースの中に含まれるゴミの量が減っただけではなく、
バグに対応する人たちの空気もよくなってきたのです。
今でもたまにバグ以外のゴミが登録されることもありますが、
そんな場合の反応も暖かいものとなっています。
これは、そのプロジェクトのイメージとメンバーの精神衛生の両方によい影響を及ぼします。
このことから得られた教訓は、
単にガイドラインを作成するだけではダメだということでした。
作成したガイドラインは、
それを最も必要としている人たちの目に付きやすいところに掲げる必要があったのです。
そのプロジェクトにあまりなじみのない人でも明確にわかるようにしなければならなかったのです。
そのプロジェクトのしきたりを説明する場所は、何も静的なウェブページだけではありません。
ある程度は対話的な取り締まりも必要です (ここで言う「取り締まり」とは、
手錠だの牢屋だのといったものではありません。単に好意的な注意をする程度のものです)。
の
で説明したコミットレビューを含むすべてのピアレビューでは、
特にそのプロジェクトの決まりに反していないかどうかも注意してレビューするようにしましょう。
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 の項目番号
(ヒント:
で説明したように、URL で名前付きアンカーを用いることを考えてみましょう)
などにも当てはまります。
短めの決まった形式が存在しない情報であっても、
できるだけ一貫して重要な情報を提供するようにしなければなりません。
たとえばメーリングリストへの投稿を指すときに、
単に送信者と件名だけで済ませてはいけません。
それだけでなく、アーカイブへの URL と Message-ID
ヘッダも含めるようにしましょう。
Message-ID ヘッダを含めておけば、
メーリングリストへの投稿をローカルに保存している人たち
(旅行中でも過去のメールを読めるように、オフラインのコピーを
ラップトップに残している人もいます) にとって便利です。
アーカイブにアクセスしなくても、Message-ID
ヘッダからメッセージが特定できるからです。
この場合、送信者と件名だけでは不十分です。
だって、同じスレッド内で同じ人が同じ件名のメッセージを
一日に何度も送信することって、そんなに珍しいことではないでしょう？
プロジェクトの規模が大きくなればなるほど、この手の一貫性はより重要となります。
一貫性とは、プロジェクトのメンバーがどこでも同じ規則に従うこと。
そして規則に従わなければならないと認知していることを指します。
こうしておけば、無駄な質問が繰り返されることも減ります。
メンバーが 100 万人だろうがひとりだろうが、
その負荷はそれほど変わりません。本当につらくなるのは、
質問してくる人の数が増え始めてきたときです。
したがって、プロジェクトの規模が大きくなってきたら、
質問の量を減らす方向に進めることを心がけましょう。
そのためには、質の高い情報を提供し、
さらにその情報を見つけやすいようにしておくことです。
そうすれば、わざわざ質問するまでもなく
必要な情報をすぐに見つけられるようになります。
バグ追跡システムでは議論しない
バグ追跡システムを積極的に活用しているプロジェクトでは、
バグ追跡システムで議論そのものを進めてしまうようになるという危険が常にあります。
議論を行うための場所としてはメーリングリストのほうが適しているのにもかかわらずです。
きっかけはちょっとしたことです。
誰かが問題点を投稿する際に、何らかの提案やパッチを付け加えたとしましょう。
それを見た他の人が、その解決策には何らかの問題があると考え、
指摘します。
それを見た元の投稿者がさらに反論をします。
……このような具合です。
問題なのは、まずバグ追跡システムは
議論をするには適していない場所だということです。
そしてもうひとつ。他人の目が届かないということもあります。
開発に関する議論は開発者向けメーリングリストで行うものと考えられているので、
議論に参加したい人は開発者向けメーリングリストのほうをチェックしているのです。
彼らは、バグ追跡システムの状況を扱うメーリングリストには参加していないかもしれません。
仮に参加していたとしても、その中身はそれほど真剣にチェックしていない可能性があります。
いったいどこがマズかったというのでしょう？
最初にバグを報告した人が自分なりの解決策を示したのがそもそもの問題？
はじめからメーリングリストに投稿すべきだった？
それとも、最初の報告に対して反応した人のほうに問題がある？
この問いに対する正解はありませんが、一般的な原則はあります。
問題の報告に単なるデータを追加したい場合は、バグ報告システムを使用するようにし、
何らかの 会話 を始めるつもりならメーリングリストを使用するということです。
どちらが適切かがはっきりしない場合もあるでしょうが、
自己判断でできるだけ適切なほうを選ぶようにしてください。
たとえば、何らかの議論を呼びそうなパッチを添付する際には、
おそらくそれについて何らかの質問が返されるであろうと予測できます。
通常は問題を報告する際にパッチも添付するのでしょうが
(自分で直接コミットする気がない、あるいはコミット権がない場合を仮定しています)、
議論を呼びそうなパッチの場合はメーリングリストを使用したほうがいいでしょう。
いずれにせよ、単なるデータの追加から実際の対話に移行しはじめる段階は誰かが気づくことでしょう。
このセクションの最初であげた例の場合、パッチに問題があることに気づいた
２番目の投稿者がそれにあたります。
パッチに問題があることに気づいたということは、
その後何らかの議論が始まることも予測できるでしょうし、
その後の会話は適切な場所で続けるべきだということもわかるでしょう。
数学にたとえてみましょう。
もしその情報がすぐに収束していきそうなら、バグ追跡システムに直接投稿するようにします。
一方その情報が発散しそうなら、メーリングリストや IRC チャンネルを使ったほうがいいでしょう。
これは決して、バグ追跡システムでは一切の意見交換を禁じるということではありません。
たとえば、元の報告者に対しての詳細な再現手順の問い合わせなどは、
たいていすぐに収束するものです。
その問いに対する答えが新たな問題を発生させることなどまずないでしょう。
単にこれまでにまとめられている情報を補足するものとなるだけです。
その程度の内容のやりとりで、わざわざメーリングリストをにぎわせることはありません。
必ず、一連のやりとりはバグ追跡システムの中で済ませるようにしてください。
同様に、そのバグ報告が間違い (バグではない) ことが明らかだというのなら、
そのバグ報告に対して直接そのように言うといいでしょう。
また、提案内容にちょっとした問題
(問題の解決を妨げるほどには重大でない問題)
があったときに、それを指摘するくらいならかまいません。
一方「バグか仕様か」や「そのソフトウェアのあるべき振る舞い」
といった思想的な話題を扱う場合は、きっと他のメンバーも議論に参加したくなることでしょう。
その手の話題は、一点に収束するのではなくあちこちに寄り道しがちです。
ということで、これはメーリングリストのほうに振るようにしましょう。
バグ追跡システムへの報告に関する議論をメーリングリストに移した場合は、
メーリングリストのスレッドへのリンクをバグ報告に追加しておきましょう。
たとえそのバグ報告でその後議論が展開することがないとしても、
後日そのバグ報告を参照した人が議論に参加したい場合などにそのリンクが重要となります。
最初にスレッドを立ち上げる人の負担が少し増えることになりますが、
オープンソースの世界には「言いだしっぺの法則」という文化があります。
後からそのバグを参照するであろう何千何万の人たちが利益を受けることを思えば、
議論に参加している数人の手間が増えることも我慢できるでしょう。
メーリングリストでの議論の結果得られた結論や議論のまとめは、
もとのバグ報告にもコピーしておくようにしましょう。
後でそれを読む人たちにとって役立ちます。
議論をメーリングリストへ移行させるときの手順は、次のようになります。
まずそのスレッドへのリンクをバグ報告に追加し、
メーリングリストでの議論が収束したらその結論をバグ報告にコピーする
(そして、メーリングリスト上での結論のメッセージへのリンクを付加する)。
そうすれば、後でそのバグ報告を見た人は、
あちこちたどらなくてもそのバグがすでに収束していることを把握できます。
結論をコピーしても、よくある「どちらが正しい情報かわからない」
という情報重複の問題を引き起こすことはありません。
メーリングリストのアーカイブやバグ追跡システムのコメントは通常は静的なものであり、
後で変化することがないからです。
宣伝・広報
フリーソフトウェアの世界では、
内部での議論と一般向けのアナウンスの間に明確な違いはありません。
その一因としては、想定する読み手がはっきり定義できないことがあります。
ほぼすべての投稿が一般向けに公開されているとすれば、
プロジェクトの外部の人たちがその投稿をどう受け取るかなどコントロールできません。
プロジェクトの外部に公開するつもりなどまったくなかった投稿であっても、
たとえば slashdot.org
へのタレコミなどの影響で何百万もの人に読まれることになるかもしれません。
オープンソースプロジェクトを運営していくにあたってこれは避けられないことです。
ただ、通常そのリスクはあまり大きくありません。
一般に、正しい方法で情報の報道価値を示しておきさえすれば
プロジェクトの外部に伝えるべき情報はきちんと伝わるようになります。
重要なアナウンスの場合、その公開方法は 4 通りか 5 通りくらいになることもあります。
そして各方面へのアナウンスはほぼ同時に行わなければなりません。
プロジェクトのトップページは、おそらく最も多くの人たちが目にする場所でしょう。
重大なアナウンスに関しては、トップページにも掲載するようにしましょう。
ここに掲載するのは概要だけとし、詳細な情報を知りたい人のためには
プレスリリース (以下で説明します) へのリンクを用意しておきます。
また、ウェブサイト上には「ニュース」や「プレスリリース」
と題した場所を設け、アナウンスの詳細はそこに書くようにします。
プレスリリースの目的のひとつは、
他のサイトからのリンクの際に使用する、正規の
「アナウンスオブジェクト」を用意することにあります。
したがって、プレスリリースは適切な構造にしておく必要があります。
プレスリリースごとに個別のウェブページを用意するにしても、
ひとつのblogの個別のエントリとするにしても、
あるいはその他の形式にするとしても、
他のサイトからリンクする際に
別のプレスリリースと区別できるようにしておかなければなりません。
そのプロジェクトが RSS フィードを提供しているのなら
( をご覧ください)、
そこにもアナウンスを含めなければなりません。
サイトの構築方法によっては、
プレスリリースを作成したら自動的にフィードも更新されるようになっているかもしれません。
新たなリリースが公開されたというアナウンスの場合は、
上のそのプロジェクトについてのエントリも更新しましょう
(Freshmeat のエントリを作成する方法については
をご覧ください)。
Freecode のエントリを更新すると、
Freecode の変更履歴を扱うメーリングリストにそのエントリの内容が投稿されます。
このメーリングリストに投稿されるのは
Freecode の更新情報だけではありません。
それ以外にも、多数の人が注目しているポータルサイト
( など)
の更新情報も投稿されます。
Freecode は、これらのデータを RSS フィードでも提供しています。
つまり、あなたのプロジェクトの RSS
フィードを購読していない人たちにも
Freecode 経由で情報を伝えることができるのです。
あなたのプロジェクトのアナウンス用メーリングリストにメールを送信します。
アナウンス用メーリングリストの名前は "announce" とします。
つまり announce@yourprojectdomain.org
のようになるというわけです。
これは事実上の標準として使われている名前であり、
この名前のメーリングリストに流されるメールは
重要なアナウンスのみに限定しなければなりません。
流れるメールのほとんどは
そのソフトウェアの新たなリリースに関するものとなるでしょうが、
それ以外にも資金集めのお知らせやセキュリティ上の脆弱性の発見
(本章で後ほどとりあげる
をご覧ください)
に関するメールも送信されます。
あるいは、プロジェクトが大きく方向転換する際のお知らせなども投稿されるでしょう。
announce メーリングリストの流量はあまり多くなく、
また重要な内容のみに使用するものです。
そのプロジェクトの各種メーリングリストの中でも
購読者の管理に最も力を入れる必要があります
(あまり乱用するのではなく、熟考してから投稿するようにしましょう)。
誰もが好き勝手にアナウンスを作成したり
スパムだらけになってしまうことを避けるため、
announce メーリングリストは
必ずモデレートしなければなりません。
これらの各所に出すアナウンスは、できるだけ同時になるようにしましょう。
メーリングリストに流されたアナウンスが
プロジェクトのホームページやプレスリリースに反映されていなければ、
それを見た人は混乱してしまいます。
さまざまな変更 (メールの送信、ウェブページの編集など)
を事前に準備しておいて同時に実行すると、
情報の一貫性が失われることが少なくなります。
それほど重要でもない出来事の場合は、
上であげた手法のうちいくつか (あるいはすべて) を省略してもかまいません。
出来事の重要性に応じて、それでもプロジェクトの外部には自然に伝わっていくでしょう。
たとえば「新しいリリースが公開されました」というのは重要な出来事ですが、
ただ単に「次のリリースの公開予定日が決まりました」
というのは、実際のリリースに比べてそれほど重要ではありません。
リリース予定日が決まったという程度の情報なら
(アナウンス専用ではなく) 通常のメーリングリストに投稿し、
あとはウェブページ上のタイムラインを更新しておくくらいで十分でしょう。
しかし、あなたのプロジェクトに関心を持っている人たちは、
リリース予定日が決まったという話題をインターネット上の他の場所で持ち出すかもしれません。
メーリングリストに参加しているけれども
ただ話を聞いているだけで自分は一切発言しないという人たちが、
必ずしも他の場所でも同じように黙っているとは限りません。
口コミの影響は侮れません。ちょっとしたアナウンスであっても、
それが正しい内容で周りに広まるよう心がける必要があります。
具体的に言うと、他の人に引用されることを想定した投稿では、
どの部分を引用してもらいたいのかを明確にし、
その部分は公式のプレスリリースと変わらないレベルで書くようにするということです。
たとえば次のようにします。
開発の最新状況をお知らせします。Scanley のバージョン 2.0 を、
2005 年 8 月中旬にリリース予定です。詳細な情報は
http://www.scanley.org/status.html でもご覧いただけます。
このバージョンで追加される主要な機能は、正規表現による検索です。
その他の新機能は、 ... また、
次のようなバグの修正も含まれます ...
最初のパラグラフでは、ふたつの重要な情報
(リリース予定日と新機能) を簡潔に説明し、
さらに詳細な情報を知るための URL を示しています。
この部分だけしか読まなかったとしても、内容が伝わるようにしておきましょう。
メールの残りの部分は、他に伝わる際には無視される可能性があります。
もちろん、中にはメール全体へリンクする人もいるかもしれません。
しかし、ほとんどの人はメールの一部を引用するのみとなります。
そうである以上、一部を引用する人が引用しやすいようにすることを心がけましょう。
うまく引用してもらえば、情報を広く伝えることができます。
セキュリティ脆弱性の告知
セキュリティ脆弱性の処理のしかたは、
他のバグ報告の場合とは異なります。
通常、フリーソフトウェアの世界では、
物事をオープンにして誰にでも見えるようにすることが当たり前のことです。
一般的なバグ報告の対応状況は、興味のある人なら誰にでも見えるようになっています。
いつバグが報告されたのか、どのような議論がなされたのか、
そして最終的にどのように修正されたのか。
これらはすべて、知りたければ誰でも知ることができるわけです。
セキュリティに関するバグの場合は、これとは異なります。
セキュリティに関するバグが原因でユーザーのデータが漏洩してしまう可能性もありますし、
場合によってはコンピュータを破壊してしまうことになるかもしれません。
このような問題をオープンな場で議論してしまうと、
問題があることを全世界に知らしめてしまうことになります。
当然その中には、そのバグを悪用しようという人たちもいることでしょう。
単に淡々とバグを修正してコミットしただけでも、バグの存在を世にさらしてしまうことになります
(攻撃者の中には、公開されているプロジェクトのコミットログをチェックしている人もいます。
変更内容を調べれば、変更前のコードにセキュリティ上の問題があることがわかるでしょう)。
ほとんどのオープンソースプロジェクトでは、
この開放性と秘密主義の対立に折り合いをつけるために
同じような方針をとっています。その方針は、以下のようなものとなります。
修正が完了するまではバグのことを口外しない。
そして、バグがあったことをアナウンスすると同時に修正プログラムを公開する。
修正プログラムは、可能な限り迅速に提供する。
そのバグが外部からの報告で発覚したものである場合は特に急ぐ必要があります。
というのも、プロジェクトの外部の人間の中に少なくとも
1 人はその脆弱性を突く攻撃ができる人がいるということがはっきりしているからです。
実際のところ、この規則は標準化した手順としてまとめることができます。
これらの手順について、以下のセクションで解説します。
バグ報告を受ける
当然のことながら、各プロジェクトには
セキュリティバグの報告を一般から受け付けるための窓口が必要です。
しかし、これは通常のバグ報告を受け付けるアドレスと一緒にはできません。
というのも、通常のバグは誰にでも見えるようになっているからです。
そこで、セキュリティ関連のバグ報告を受け取るためのメーリングリストを別途用意します。
このメーリングリストのアーカイブは一般に公開してはいけません。
また、参加資格は厳しく制限するべきです。そのプロジェクトに長くかかわっていて
信頼できる開発者たちのみをメンバーに加えるようにしましょう。
もし "信頼できる" の具体的な定義が必要な場合は、たとえば
"コミット権を得てから 2 年以上経過している"
などといった条件を使用するといいでしょう。
そうすれば、参加資格に関して "えこひいきしているのでは?"
といった批判を避けることができます。
このメーリングリストに参加しているメンバーが、
セキュリティバグに対応するメンバーとなります。
セキュリティ関連のメーリングリストについては、
スパム対策やモデレートは行わないのが理想です。
というのも、重要な報告がスパム扱いされてしまうと困りますし、
たまたまその週末にすべてのモデレータがメールをチェックしなかったなどという理由で
重要な報告に気づくのが遅れるというのも困ります。
何らかのスパム対策ソフトウェアを使用するのなら、
可能な限り緩やか目の設定にしておきましょう。
重要な報告をフィルタリングしてしまうくらいなら、
多少のスパムが混ざってしまうほうがずっとましです。
作成したメーリングリストをうまく活用するためには、
そのアドレスを周知させる必要があります。
しかし、このメーリングリストはモデレートされておらず、
またスパム対策も甘いものです。したがって、
そのアドレスを宣伝するときには、アドレスを隠すために何らかの細工が必須となります。
詳細は の
で説明します。
幸いにも、アドレスを読みにくいものになどしなくてもアドレスを隠すことは可能です。
をご覧になったうえで、
そのページの HTML ソースを確認してみてください。
大至急それを修正する
セキュリティメーリングリストに報告が来たら、次は何をすればいいのでしょう?
まず最初にすべきことは、その問題の重大度 (severity)
と緊急性 (urgency) を評価することです。
その脆弱性はどれくらい深刻なものでしょう?
悪意のある攻撃者が、
そのソフトウェアを使用しているコンピュータを乗っ取ってしまえるほどのものですか?
それとも、ただ単に何らかのファイルのサイズが漏洩してしまうというだけのものですか?
その脆弱性を突く攻撃の難易度はどの程度ですか?
スクリプトを使って誰でも攻撃できる程度のもの?
あるいはその場の状況を熟知している人が
高度に頭を働かせても、ごくまれにしか成功しないもの?
誰が その問題を報告してきたのですか?
この問いへの答えによって脆弱性そのものの性質が変わるわけではありませんが、
他にどれくらいの人がその問題に気づいている可能性があるかを推測することができます。
もしそのプロジェクトの開発者自身から報告されたのなら、ちょっとだけ
(本当にちょっとだけ) 安心できます。
おそらく、その報告者は他人にその問題を漏らしていないでしょうから。
一方、もし anonymous14@globalhackerz.net
とかいうアドレスからのメールで報告を受けたのなら、
一刻も早く対応すべきでしょう。
あなたにその問題を報告してくれた人は、
あなた以外の人にもその情報を漏らしているかもしれません。
あるいは報告を受けたときには既にその脆弱性を突いた攻撃を始めているかもしれません。
ここで考えているのは、あくまでも
緊急 (urgent) と
超緊急 (extremely urgent)
のどちらかというレベルの話であることに注意しましょう。
たとえ今回の報告が既知の信頼できるところからのものであったとしても、
それよりずっと前に他の人が同じ問題を発見しているが
ただ報告していないだけなのかもしれません。
緊急性が低いといえるのは、
そのバグが本質的に深刻なセキュリティ問題を引き起こさないといえる場合のみです。
ところで、さきほどの "anonymous14@globalhackerz.net"
の例は、決して冗談で言ったわけではありません。
実際、このようにどこの誰だかわからないような相手からバグの報告を受けることもあり得ます。
彼らは自分の身元を明かすこともないでしょうし、
あなたの味方なのか敵なのかさえはっきりさせないでしょう。
でもそんなの関係ありません。あなたにセキュリティホールを教えてくれたということは、
向こうはあなたに対してひとつ貸しを作ったと考えているはずです。
それに対して、誠意を持って対応する必要があります。
まず報告してくれたことに対して感謝し、
修正版を公式リリースする予定日を彼らに伝えるようにします。
時には 報告者側から 日時を指定されることもあります。
つまり、「バグが修正されているかどうかにかかわらず、
○月○日になればこの問題を公表する」などどして暗黙の脅しをかけてくるようなものです。
これは単なる弱い物いじめに感じられるかもしれませんが、
おそらくその報告者が過去に経験したいやな思い出
(せっかくセキュリティ問題を報告してやったのに、
ソフトウェアの作者にまともに取り合ってもらえなかったなど)
に基づく先制攻撃と考えたほうが適切でしょう。
いずれにせよ、報告者をいちいち怒らせている余裕などありません。
結局のところ、もしそのバグが深刻なものなのだとしたら、
その報告者はユーザーに問題を引き起こさせる方法を知っているということになります。
彼の機嫌を損ねないよう丁重に扱いましょう。
そうすればきっと相手もこちらを尊重してくれることでしょう。
セキュリティバグの報告者としてほかによくあるのは、
セキュリティの専門家です。彼らはソフトウェアのコードを監査するのを仕事にしており、
ソフトウェアの脆弱性についての最新情報を追いかけています。
この手の人たちは、バグを報告する側だけでなくバグ報告を受け取る側としての経験も豊富です。
おそらくあなたのプロジェクト内のどのメンバーよりも経験を積んでいることでしょう。
また、彼らの特徴としては、期日を指定してその日までの対応を迫り、
期日がくればバグを一般に公表するというやり方があります。
交渉次第で期日を引き延ばすこともできるかもしれませんが、それは相手によります。
セキュリティの専門家たちにとっては、報告先にまともに取り合ってもらうための
唯一効果的な方法が期日を設定することなのです。
彼らが期日を指定してきたとしても、それを失礼だとは思わないようにしましょう。
それなりの理由があって続いている伝統なのですから。
重大度と緊急性を判定し終えたら、実際の作業に取り掛かり始めます。
修正をエレガントに行うか、それともとにかくすばやく修正するのかのトレードオフになることもあります。
このようなときのために、まず最初に緊急性を判定しておいたのです。
セキュリティに関する修正についての議論は、当然セキュリティメーリングリスト内でのみ行います。
また、問題の報告者がもし議論への参加を希望するなら、報告者もその議論に参加させましょう。
そして、技術的な理由でそれ以外の開発者が参加することもあるかもしれません。
修正内容をリポジトリにコミットしてはいけません。
一般に公開するまではパッチ形式で管理しておくようにします。
もし仮にそれをコミットしてしまったら、
たとえログメッセージを適当に取り繕っていたとしても
見る人が見ればその変更の意味するところを感づかれてしまいます。
どこの誰がどういう目的であなたのリポジトリをチェックしているかなんてわかりません。
コミットメールの送信をやめたとしても無意味です。
まず、コミットメールの送信が突然止まったという時点で
「なにか怪しい」と思われてしまうでしょう。
そしてコミットメールの有無にかかわらず、
その内容はリポジトリのデータとして残されているわけです。
修正の開発はすべてパッチ形式で行い、パッチは隔離された場所で管理します。
そのバグの対応をしている人たちだけが知っている個別のリポジトリなどがいいでしょう
(Arch や SVK といった中央管理型ではないバージョン管理システムを使用しているなら、
完全にバージョン管理された環境で作業を進めることができます。
バグへの対応中は、外部からはリポジトリにアクセスできないようにしておけばいいのです)。
CAN/CVE 番号
これまでに、セキュリティの問題の中で CAN 番号
や CVE 番号 といったものをみたことがある人がいるかもしれません。
たとえば "CAN-2004-0397" あるいは "CVE-2002-0092"
といった形式のものです。
これらの番号は、どちらも同じ型の内容を表しています。これは
で管理されている
"Common Vulnerabilities and Exposures"
リストのエントリを表します。このリストの目的は、
既知のセキュリティ問題についての共通の呼び名を提供することにあります。
そうすることで、個々の問題をはっきり区別できるようになります。
また、詳細な情報を探すための中央広場としての働きもあります。
"CAN" 番号と "CVE" 番号の唯一の違いは、
前者はまだ正式に認定される前の状態であるということです。
CVE Editorial Board によって認定されて公式リストに登場したものが後者となります。
しかし、どちらの情報も一般に公開されており、
認定の前後で番号自体は変わりません。
単に、番号の前の "CAN" が "CVE" に置き換わるだけのことです。
CAN/CVE のエントリ自体には、
バグの詳細な説明や対処方法などは含まれていません。
その代わりに、そのバグの概要説明と外部リソース
(メーリングリストのアーカイブなど) へのリンクを用意し、
詳細な情報が知りたい人はそちらを参照すればいいようになっています。
の真の目的は、
きちんと整理整頓された場所を用意してすべての脆弱性に名前をつけ、
詳細なデータを得るための道筋を示すことです。たとえば、エントリの例として
を見てみましょう。その記述内容は非常に簡潔なものであり、
なにやら怪しげな略語をつけたリンクがあるだけです。
これらの略語の意味については
でご確認ください。
あなたが対応した脆弱性が CVE の条件を満たすようなら、CAN 番号の取得を検討するといいでしょう。
取得方法は、意図的に難しくしてあります。
基本的に、まずあなたが誰かの知り合いであるか、誰かの知り合いの知り合いである必要があります。
なんだかよくわからない言い方ですが、要はこういうことです。
脆弱性でもない内容や中身のないような報告に対応するのを避けるため、
CVE Editorial Board は既知の信頼できる情報源からの報告しか受け取らないのです。
したがって、脆弱性をリストに載せてもらうには、
あなたのプロジェクトと CVE Editorial Board の橋渡しをする仲介役が必要になるということです。
周囲の開発者に聞いてみましょう。その中に一人くらいは、
「以前に一度 CAN を取得したことがある」とか
「知り合いが CAN を取得していた」とかいう人がいるでしょう。
この方式の利点は、知り合いのつてをたどっていくうちに
a) それは MITRE の言うところの脆弱性に該当しないから投稿する必要はない
とか
b) その脆弱性にはすでに CAN あるいは CVE 番号が割り当てられている
といったことを教えてくれるかもしれないということです。
後者の可能性としては、そのバグが既に別のセキュリティメーリングリストで報告されているといったことがあります。
たとえば 、あるいは
の BugTraq メーリングリストなどがこれにあたります
(もしあなたのプロジェクトに対して何も連絡がないまま後者の状態になっているのだとしたら、
自分たちのうかがい知れないところで何かが起こっているということを心配しなければなりません)。
どうせ CAN/CVE 番号を得るのなら、
普通はバグの調査段階のできるだけ早いうちに番号を取得したいものです。
そうすれば、その後のやりとりはその番号を使用して進めることができます。
CAN エントリは、一般に公開される日まで使用できません。
それまでは空のエントリが存在するだけ (場所を確保するだけ)
であり、あなたがバグの存在と修正を公表するまで、
そこには何の情報も掲載されません。
CAN/CVE のプロセスについてのより詳細な情報は
で得られます。また CAN/CVE 番号を非常にうまく使っている
オープンソースプロジェクトの例としては
があります。
事前通知
セキュリティ対策チーム (セキュリティメーリングリストのメンバー、
あるいはそのセキュリティ問題の対応担当者) が修正を完了したら、
次はそれをどのように公表するのかを判断する必要があります。
単に修正をリポジトリにコミットするとか全世界に公表するとかだと、
そのソフトウェアを使用している人たちは
事実上即時のアップグレードを迫られることになってしまいます。
さもないと、攻撃を受ける危険性が生じるわけですから。
したがって、ある種の重要なユーザー向けには
事前通知 をしておくほうが適切なこともあります。
いわゆるクライアント/サーバ型のソフトウェアなどでは特にこれが重要です。
有名なサーバが、一時的にでも攻撃の対象となってしまう可能性があるからです。
これらのサーバの管理者にとっては、アップグレードを行うためには
1 日から 2 日の時間が必要となるでしょう。
脆弱性が一般に公開される前にそのくらいの猶予があれば、
サーバの管理者はありがたいと思うことでしょう。
事前通知とは、単に一般公開前にそれらの管理者向けにメールを送信することを指します。
通知メールでは、脆弱性の内容とその対処方法を説明しておくようにします。
事前通知の送信先は、その情報を適切に扱ってくれると信頼できる相手に限定しなければなりません。
つまり、事前通知を受け取る資格があるのは、次のふたつの条件を満たす相手だけだということです。
まず、攻撃を受けると深刻な問題となるような巨大で重要なサーバを運営しているということ。
さらに、一般公開の前にその問題をペラペラしゃべってしまうような
口の軽い人ではないということ。
事前通知のメールは、それぞれの相手に個別に (一度に一通ずつ) 送信するようにします。
全員に一括送信などしては いけません。
そんなことをすれば、それを受け取った人たちに「私のほかにどんな相手に送っているのか」
を知られてしまいます。これが何を意味するのか。それを受け取った人は
「(私以外の) 他のメンバーのサーバにも同じセキュリティホールがある」
ということを知ってしまうことになります。
全員をブラインドカーボンコピー (BCC) で指定すればいいという問題でもありません。
受け取り先が使用しているスパムフィルタの設定によっては、BCC
で送信されたメールをブロックしたり優先度を下げたりするようになっていることもあるからです
(最近のスパムには、BCC を使用して送られてくるものが多いのです)。
事前通知メールの例を、ここに示します。
From: あなたの名前
To: admin@large-famous-server.com
Reply-to: あなたの名前 (セキュリティメーリングリストのアドレスではありません)
Subject: [機密] セキュリティ脆弱性の通知
このメールは、Scanley サーバにおけるセキュリティ警告に関する極秘の事前
通知です。
このメールの内容は、決して他人に転送しないでください。一般向けには 5 月
19 日に公表する予定です。それまではこの情報を口外しないようお願いいたし
ます。
あなたにこのお知らせを送信した理由は、(おそらく) あなたが Scanley サー
バをご利用いただいており、5 月 19 日にセキュリティホールを公表する前に
パッチを適用したいであろうと考えられるからです。
参照:
=====
CAN-2004-1771: Scanley stack overflow in queries
脆弱性:
=======
サーバのロケールの設定が正しくない場合に、クライアントから不正な
クエリを送信するとサーバ上で任意のコマンドを実行できるようになります。
重大度:
=======
非常に深刻。サーバ上で任意のコードの実行を許してしまいます。
回避方法:
=========
scanley.conf で 'natural-language-processing' オプションを 'off'
に設定することで、この脆弱性を回避可能です。
パッチ:
=======
以下のパッチは Scanley 3.0、3.1 および 3.2 に適用可能です。
新しい公開リリース (Scanley 3.2.1) が 5 月 19 日の直前に公開されます。
つまり、この脆弱性を公表するのと同時に公開するということです。以下の
パッチを適用するか、あるいは新しいリリースが発表されるのをお待ちくだ
さい。3.2 と 3.2.1 の違いは、以下のパッチのみです。
[...ここにパッチを示します...]
CAN 番号を取得している場合は、それを事前通知に含めるようにしましょう
(先ほどの例で示したようにします)。まだ情報は公開されておらず
MITRE のページには何も掲載されていませんが、それでも含める価値があります。
CAN 番号を示すことで、それを受け取った相手は「この通知で知ったバグと
後日正式に公開されるバグが確かに同じものである」ということを確認できます。
正式にバグが公開されたときに、余計な心配をせずにすむというわけです。
まさにこれこそが、CAN/CVE 番号の重要なところです。
修正を一般に公開する
セキュリティバグへの対応で最後に行うのが、
修正内容を一般に公開することです。
ひとつの包括的なアナウンスで、以下の内容を説明しなければなりません。
まずその問題の内容、そして CAN/CVE 番号を取得していればその番号、
当面の回避策と本質的な修正方法などを示します。
"修正" は、通常はそのソフトウェアの最新バージョンへのアップデートとなります。
しかし、ソースコード形式で実行されるソフトウェアなどでは、
パッチの適用をもって "修正" とすることもあります。
新しいリリースを作成した場合は、それが通常のリリースとは異なり
セキュリティパッチの適用によるものであることを明示しておく必要があります。
そうしておけば、保守的な管理者であっても
副作用を気にせずにアップグレードできるようになります。
当然、今回のセキュリティ修正は将来のリリースにも含まれているでしょうから、
将来のアップグレードの際にも心配せずにすみます
(リリース手続きの詳細については、
の
で説明します)。
セキュリティ対応の修正で新バージョンをリリースするか否かにかかわらず、
通常の新バージョンのリリースと同程度の優先度でアナウンスを行うようにします。
つまり、そのプロジェクトの announce
メーリングリストにメールを送ったりプレスリリースを作成したり
Freecode のエントリを更新したりといったことです。
そのプロジェクトの評判を気にしてセキュリティバグの存在を甘く見るなんてことは論外ですが、
セキュリティに関するアナウンスの影響と実際の問題の重大度との兼ね合いには注意しましょう。
そのセキュリティホールが単に些細な情報が漏洩するというだけのものであって
コンピュータ全体がのっとられてしまうほどのものではないという場合は、
あまり大騒ぎしないほうがいいこともあります。場合によっては
announce メーリングリストへの投稿も控えるということもありえます。
ささいなことで毎回大騒ぎしていると、ユーザーはどう思うでしょう?
実際にはそれほどではないのに「このソフトウェアはあまり安全ではない」
と思われてしまうかもしれません。また、本当に深刻な問題が発生したときにそれをアナウンスしても、
「またいつものやつだろう」と無視されてしまう可能性もあります。
重要度の判断方法については、
にすばらしい入門文書があるので、ぜひご覧ください。
セキュリティ問題の対処方法がよくわからない場合は、
経験がありそうな人を探して相談するようにしましょう。
脆弱性の評価やその処理の技術は、経験を積まないとなかなか得られないもので、
最初のうちは失敗することが多いものです。
セキュリティ脆弱性の扱いに関する Apache Software Foundation のガイドラインが
にあります。こちらも参照ください。この素晴らしいチェックリストを見れば、
自分がすべてを注意深く行っているかどうかを判断できます。