オンラインのプロジェクトに参加するひとたちが陥りがちな罠のひとつに 「すべてのメッセージに返信しなければ！」というものがあります。 そんなことはありません。 第一、数ヶ月を経てある程度の規模になったプロジェクトについて、 すべてのスレッドの議論を追いかけるなんて不可能です。 また、自分が注目しているスレッドについても、 その投稿の多くは別に返信を要求しているものではないでしょう。 開発系のフォーラムでは特に、次のようなメッセージが多くなる傾向があります。

これらのいずれについても、本質的には 返信は不要です。注意深くスレッドを観察していれば、 あなたが言いたいことはきっと他のだれかが言ってくれるでしょう (みんなが同じように考えていたら、結局だれも発言しなくなってしまうんじゃないの？ と思われるかもしれませんが、そんなことはありません。 たいていの場合、何か言わずにはいられない人が 誰かしら 存在するものです)。 明確な目的がある場合にのみ返信を行うようにしましょう。 まずは自分に問いかけることです。 「その返信で何を達成したいのか、きちんとわかっているのか？」 「その目的は、自分が返信しない限り達成できないものなのか？」

あなたがスレッドに口出しをするのに適切な場面は次のふたつです。 a) 提案内容の不備に気づいたが、おそらく他の誰もそれに気づいていないと思われるとき、 そして b) 誰かと誰かの間の意思疎通がうまくいっていないときに、 投稿内容を整理して二人の関係を修復してあげられそうなとき。 あとは、誰かが何かをしてくれたことに対する感謝のメッセージや ただ単に "私もそう思います！" というだけのメッセージなどを送信してもよいでしょう。 というのも、そういった投稿をすればそのメールに対する返信が不要であることがはっきりするからです。 そして、そのスレッドで最後にメールを投稿した人に対して 「スレッドがきれいにまとまった」という安心感を与えることもできます。 しかし、そんな投稿の際にも、投稿の前によく考えるようにしましょう。 「ちょっと投稿しすぎじゃない？」と思われるより 「もうちょっと発言してほしいな」と思われるほうがずっとマシです (活発なメーリングリスト上でどのように振舞えばいいのかについての意見は、 付録D なんで自転車置場の色まで気にしなきゃならないの？ の後半をご覧ください)。

活発なメーリングリストで欠かせないのは、次の 2 点です。 まず明らかなのは、注目すべきものとどうでもいいものを見分けること、 もうひとつは、できるだけノイズの 原因 となることを避けることです。自分自身の投稿の S/N 比を高く保つだけでなく、 他の参加者のメッセージの S/N 比も同様に高くしたい。 それができないならいっそのこと投稿しないでほしい。

どうすればいいのかを考えるために、まずは状況を考えてみましょう。 この中で、生産的でないスレッドといえるのはどれでしょうか？

うまく機能していないスレッドがすべて無駄なものであるとは限りません。 中には重要な話題が含まれているかもしれません。 そんな場合は、そのスレッドが盛り上がっていないということ自体が問題です。

あまり押し付けがましくならないようにスレッドの流れをよい方向に持っていくのは、 ある種の芸術といえます。単に「無駄な話をするのはやめよう」とか 「もっと前向きなことを投稿するようにしようよ」とか言うだけではうまくいきません。 もちろんこれらを個人的に行うことはできるでしょうが、 ちょっと強く言ってしまうと攻撃的になってしまいます。 そうではなく、前に進むためには次に何をすべきなのかを提案しなければなりません。 あなたが望む結果が得られるような道筋を (無理やり指示しているような流れになるのを避けつつ) 示してあげるのです。 提案のよしあしを区別するのは、主に口調の問題となります。 たとえば、こんなやり方はよくありません。

それよりは、こちらのほうがいいでしょう。

後者のアプローチを最初のものと比べてみましょう。 最初のほうは「私」と「その他のメンバー」の間に一線が引かれていましたが、 後のほうは違います。みんなをうまく議論に巻き込んでいます。 あなたがそのスレッドの議論に最初からかかわっていたかどうかに関係なく、 主語を「私たち」とすることが重要です。これによって、 それまでスレッドをみているだけで何も発言しなかった人たちに対しても 「みんなにかかわる話なんだ」ということを確認させることができるからです。 スレッドが煮詰まってしまった原因については説明していますが、 誰かをののしったり自分の意見を押し付けたりはしていません。 淡々と事実を述べているだけです。 最も重要なのは、前向きに進めるために次に行うべきことを示している点です。 これにより、ただ単に議論を打ち切らせる (そんな制限をしても、だれも守ってくれないでしょう) のではなくより建設的な方向に会話を持っていこうとしているのです。

そのスレッドをもっと膨らませたいといった状況ばかりであるとは限りません。 時には、こんなスレッドはさっさと打ち切ってしまいたいと思うこともあるでしょう。 この場合には、スレッドを終了させるための投稿をします。 もしそのスレッドが既にみんなに忘れ去られてしまっているものなら、 あなたが投稿するだけでそのスレッドは事実上終了するでしょう。 もちろん、スレッドを打ち切るための完璧な方法なんてありません。 もしそんなのがあったとしても、使いたいとは思わないでしょう。 しかし「何か目に見える成果を出してください。 でなければこのスレッドを終了します」とお願いすると、うまくいくことでしょう。 ただ、スレッドを終了させるのは十分に考えた後にしてください。 話題によっては、雑談の中から生産的な内容に発展することがあるかもしれません。 あまりに拙速に打ち切ってしまうと、あなたはせっかちな人と思われてしまいます。

どんなスレッドであっても、すぐに終了するとは期待しないでください。 あなたが投稿した後にも、おそらくいくつかの投稿があるでしょう。 あなたのメールがまだ届いていなかったり、あるいはいわゆる 「最後にひとこと」が言いたかったりといった人たちによるものです。 心配することはないですし、先ほどの投稿を繰り返す必要もありません。 スレッドが収束する (あるいはさらに膨らんでいく) のを黙って見守っていればいいのです。 完全にスレッドをコントロールすることなんてできません。 ただ、あなたは多くのスレッドに何らかの効果を及ぼせるはずです。

どんな議題であっても議論は紆余曲折するものですが、 技術的な難度が低い話題になればなるほど 議論が発散する可能性があがります。 結局のところ、技術的な難度が高い話題になればなるほど その話題についていける人の数が少なくなるということです。 そんな話題についていける人というのは、たいていは長年経験を積んだ開発者です。 彼らはこれまでに何度となくそのような議論に参加しており、 全員が納得のいく合意を得るにはどうしたらいいのかを知っているのです。

というわけで、合意を得ることが最も難しいのは、 誰にでもわかる (誰でも意見が言える) レベルの技術的な問題となります。 また同様に、組織論や広報活動、資金調達などの "やわらかめ" な話題も合意を得にくいものです。 これらの話題については、人はいつでも気の済むまで議論に参加することができます。 議論に参加するための前提条件もなければ 何が正しくて何が間違っているのかを (後になっても) 決めることもできない、 そして、他人の意見を聞いてから「後出し」で議論に参加することもできるからです。

議論の量と話題の複雑さが反比例するという原則はよく知られており、俗に Bikeshed Effect (自転車置場効果) と呼ばれています。 ここで、Poul-Henning Kamp による説明を見てみましょう。 もともとは BSD 開発者向けに投稿されたものですが、今や超有名になっています。

(彼の投稿の完全版はかなり長くなりますが、一読の価値はあります。 付録D なんで自転車置場の色まで気にしなきゃならないの？ でご確認ください。また http://bikeshed.com も参照ください)

これまでにグループでの議論に参加したことがある人なら誰でも Kamp の言っていることがよくわかるでしょう。 しかし、自転車置場に色を塗るようなことを避けるよう 全員 を説得するのは不可能です。 できることといえば、そんな状況を見つけたときに 「こういう状態になっているんじゃない？」と指摘するくらいです。 そして、影響力の強い開発者たちに対して 「早めに筆をおろしてくれませんか？」とお願いするのです。 そうすれば、少なくとも彼らはノイズの原因とはならなくなります。 自転車置場の塗装大会を完全にやめさせることはできないでしょうが、 プロジェクトの文化をうまく育てていけばそんな羽目になる頻度を下げる (そして発生したときも早く収束できるようにする) ことができます。

宗教論争 (holy war: 聖戦) とはある種の論争のことです。 ただ、時には話し合いで解決できないほど大きな問題になることもあります。 お互い、相手側を打ちのめすまで議論を続けようとします。 これは、先ほどのいわゆる「自転車置場問題」とは多少異なるものです。 自転車置場の議論に加わっている人たちは、先を競って自分の意見を表明します (だって簡単に意見を言えるから)。 でも、彼らは必ずしもそれを強く主張するわけではありません。 時には相手の意見に理解を示すこともあります。 しかし「宗教論争」においては、相手の意見に耳を傾けた時点で負けです。 みんな「正解はたったひとつである」という点では合意しているのですが、 ただ「正解がどれか」という点で争っているのです。

いったん宗教論争が始まってしまったら、 みんなが満足するようなかたちでそれを収束させることは不可能です。 炎上している真っ只中で「これって宗教論争じゃない？」 と指摘したところで無意味です。 そんなこと、みんなとっくに知っているわけなんだから。 残念なことに、宗教論争の多くは 「この問題は話し合いを続ければ解決できるのか」 という点に対しても意見の対立が発生するものなのです。 第三者からみれば、どちら側も相手を説得できそうにないのは明らかです。 当事者たちは「相手側は何もわかっちゃいない。 うまく説得すればきっと私たちの考えをわかってくれるだろう」とお互い考えています。 私は「こんな争いには正解なんてない」とは 言いません。 時には正解があることもあるのです。 私も過去に何度か宗教論争に巻き込まれましたが、 そのときはいつも私たちのほうが正論でした。 とはいえ、そんなのはどうでもいいことです。 どちらが正しいのかを納得いくように説明する方法なんてないのですから。

宗教論争を解決しようとしてやりがちなことは 「こんなことをいつまでも続けていても時間のムダじゃないか！ もういい加減やめてしまわない？」 と言うことですが、これでは不十分です。 このやりかたには 2 つの問題があります。 まず、これまで議論に費やしてきた時間や気力は取り戻せないということです。 いま大事なのは「あとどれだけ議論しなければならないのか？」です。 もし「もうちょっと話をすれば解決できそうだ」と感じている人が何人かいるのなら、 (少なくとも彼らの視点からは) 議論を続けるのは理にかなっています。

もうひとつの問題は、 そこで議論をやめてしまう (現状維持とする) ことが、 どちらか一方に事実上の勝利宣言をするのに等しいことがあるということです。 また時には「とにかく現状をどうにかしなければならない」という点では合意しているが 「どのように変えるのか」で争っているということもあります。 こんな場合は、議論を打ち切ってしまったら誰の得にもなりません。 そのことはみんなわかっているので、この場合は議論を続けることも可能でしょう。

じゃあ、いったいどのように処理したらいいのでしょう？

まず言えることは、そんな議論が起こりえないようにするということです。 これは、皆さんが思っているほど難しいことではありません。

宗教論争になりがちなネタは、だいたい予想がつきます。 プログラミング言語についてだったりライセンスについてだったり (10章ライセンス、著作権、特許 の 「GPL とライセンスの互換性」 をご覧ください)、 あるいは reply-to の処理についてだったり ( in 3章技術的な問題 の 「Reply-to はどうすべきか」 をご覧ください) などです。 たいていのプロジェクトは一度や二度はこういう経験をしており、 それによって開発者たちの結束が急速に深まったりします。 このような争いをやめさせたり、 あるいは被害をできるだけ抑えたりするための方法は、どこに行っても同じです。 たとえ自分側の意見が正しいと確信しているのだとしても、 とりあえずは 相手側の意見にも耳を傾け、 理解を示すようにしましょう。この手の争いでよくある問題は、 それぞれの側が可能な限り敷居を高くしてしまって 自分たち以外の考えはみんなまったくばかげていると言い切ってしまうことです。 このような場合、相手側を説得したり意見を変えさせるようにしたりするのも 難しくなってしまいます。つまり、単に相手に「まちがっていました」 と認めさせるだけではなく「心から まちがっていました！」と認めさせなければならなくなるのです。 相手側に説得を受け入れてもらいやすくするには、 まずあなた自身の確信を押し付けないようにすることです。 つまり、現在行われている議論の内容をきちんと理解していること、 そして説得力があるかどうかはともかく、少なくとも分別はあるということを示すことです。 相手が返事を返す余地があるような意思表示をするようにしましょう。 そうすれば、状況は改善するでしょう。 結果としてあなたが望んでいたそのものは得られないかもしれませんが、 少なくとも、プロジェクトの士気に影響を及ぼすような巻き添え被害は防ぐくとができます。

宗教論争が避けられない状況になったら、 あなたがどの程度それにかかわるのかを早めに決断しましょう。 なんだったら、その手の議論を正式に放棄してしまってもかまいません。 そうすれば、皮肉を言ったり 反対意見に対して捨てゼリフを残したりせずに きれいに宗教論争から身を引くことができます。 議論を放棄する場合は、潔く行うことが大切です。

プログラミング言語に関する宗教論争は、少し事情が異なります。 というのも、彼らは技術的に高いレベルにある人であることが多く、 また多くの人が何らかの意見を持っており、利害関係が非常に高くなるからです。 その争いの結果、プロジェクトで使用する主要なプログラミング言語が決まってしまうかもしれません。 一番いい方法は、プロジェクトの初期段階のうちに 開発者間で言語を選択してしまうことです。そして いったん決めた開発言語については、「それが他の言語より優れているから」 という理由 ではなく、 「それがいちばん書き慣れているから」という理由で守っていくようにします。 決して「プログラミング言語を学術的に比較する」といった方向に陥らないようにしましょう (なぜだかよくわかりませんが、誰かが Perl を持ち出したとたんに この方向に話が進むことが多いようです)。 この手の話題はまったく無駄なものであり、避けるべきです。

この手の議論に関する歴史的な背景については http://catb.org/~esr/jargon/html/H/holy-wars.html をご覧ください。また、Danny Cohen によるより簡単な解説が http://www.ietf.org/rfc/ien/ien137.txt にあります。

メーリングリストでの議論においては、 少数派の意見がいかにも大きな異議であるように見せることは簡単です。 長々としたメールをメーリングリストに大量に投稿すればいいのです。 これは議事進行妨害と似ていますが、 反対意見が大きくなっていると思い込ませることにはより強力な意味があります。 というのも、あまりにたくさんの意見が行きかうと 「誰がいつ何を言ったのか」を追いかけるのが面倒になってしまうからです。 「よくわからないけど、何だか重要なことを議論しているんだな」 と本能的に感じ、騒ぎがおさまるまでしばらくおとなしくしている人が多くなるのです。

このような効果をうち消す最もよい方法は、何らかの証拠をもって 「異議を申し立てている人がどれだけ少数であるかということ」 「他の大半の人たちが合意しているということ」 を明確に指摘することです。より状況を明確にするために、 明確に意見は表明していないがおそらく多数派に合意するであろうと思われる人たちに 個別に意見を聞いてみてもいいでしょう。 反対している人たちが自分の意見を故意に膨らませようとしているといったことを 指摘するのはやめましょう。多分彼らはそんな気持ちはないでしょう。 たとえ意図的にしているのだとしても、 それを指摘したところで戦略上なんの利点もありません。 あなたがすべきことは、単に実数を比較して示すこと。 そうすれば、他の人たちは自分の実感とずれていることをわかってくれるでしょう。

この手法は、賛成か反対かがはっきりするような議論に関しては適用できません。 この方法がうまくいくのは、誰かが大騒ぎしているものの 大半の人にとってはそれが議論すべき問題なのかどうか判断できないといった場合です。 議論をしばらく見ていて、それが (メールの数のわりには) あまり人々の気を引いていないものであって どうでもいい議論であると判断したら、それをはっきりと示してあげましょう。 いわゆる "口うるさい少数派" が目立っているときには、あなたの投稿が一服の清涼剤となるでしょう。 こんな場合、たいていの人はちょっと落ち込んでいます。「なんてこった。 大量の投稿があるので多分重要なことを話しているんだろうけど、 いったい何がどうなっているのかちっともわかりゃしない」といった気分です。 実際の議論が必要以上に大げさになりすぎていたことを説明すれば、 彼らはそれまでの流れを見直して 何が起こっていたのかを理解してくれるでしょう。