第6章 コミュニケーション

目次

書いたことがすべて
構成や体裁
中身
口調
何が失礼にあたるのか
陥りがちな罠
目的のない投稿をしない
生産的なスレッドとそうでないスレッド
簡単な議題ほど長引く
宗教論争を回避する
"口やかましい少数派" について
扱いにくい人たち
扱いにくい人たちへの対応
実例
巨大化への対応
アーカイブを目に付きやすくする方法
全リソースをアーカイブと同様に扱う
しきたりの成文化
バグ追跡システムでは議論しない
宣伝・広報
セキュリティ脆弱性の告知
バグ報告を受ける
大至急それを修正する
CAN/CVE 番号
事前通知
修正を一般に公開する

明瞭に、わかりやすく書くという技術は、 オープンソース界で暮らす上で最も重要なもののひとつといえるでしょう。 ある意味ではプログラミング技術よりも重要かもしれません。 プログラミングの技術は優れているがコミュニケーションスキルに欠ける人は、 一度にひとつずつのことしかこなせません。 また、周りの人の気を引くことにも苦労するかもしれません。 逆に、プログラマーとしては二流だがコミュニケーションスキルが優れている人は、 周りの人をうまく巻き込んでさまざまな作業をこなすことができます。 そして、結果としてプロジェクトをよい方向に引っ張っていってくれるのです。

コードを書く能力のある人が、 必ずしも他人とうまくやっていくためのコミュニケーション能力があるとは限りません。 よいプログラムを書く能力と技術的な問題をうまく説明する能力とには それなりの相関関係はあるかもしれませんが、 「技術的な問題を説明する」ということは プロジェクト内でのコミュニケーションにおけるほんの一部のことに過ぎません。 それよりもずっと大事なことは、次の3つ。 まず聞き手の気持ちになって考えること、 自分の投稿やコメントを客観的に見るようにすること、 そして他人にも自分自身の投稿やコメントを客観的に見させるようにすることです。

……といったことを口で言うのは簡単ですが、実際にやってみると これは非常に難しいことです。というのも、フリーソフトウェアの開発には さまざまな人たちが参加しており、彼らのコミュニケーション方法もそれぞれ異なるからです。 何か意見を述べたいときはどうすればいいのでしょう? メーリングリストへ投稿する? バグ追跡システムに登録する? それともコードのコメントとして記述する? 掲示板での質問に回答するとき、相手がどれくらいの知識を持っていると想定したらいいのでしょう? 当然、ここでいう「相手」とは、質問の当事者だけでなく 後であなたの回答を読むであろう第三者も含まれます。 開発者と利用者の関係を良好な状態に保つにはどうしたらいいのでしょう? 利用者からの機能追加要求や勘違いのバグ報告、 その他の雑談などに開発者たちが悩まされないようにするには? コミュニケーションの手段が尽きたら相手にどう伝えたらいいでしょうか? また、どう対処したらいいのでしょうか?

これらの問題に対する解決策は、通常は一時的なものとなります。というのも、 どんな解決策であっても、プロジェクトの規模が大きくなったり プロジェクトの体制が変わったりすれば意味がなくなってしまうからです。 また、これらの解決策はたいていその場しのぎのものになります。 刻々と変化する状況にあわせて即興で対応しなければならないからです。 すべてのメンバーは、コミュニケーション不全に陥っていないかどうかを常に気にかけ、 それに対応する必要があります。このような行動を支援することも、 オープンソースプロジェクトの運営の大事な一部です。 以下のセクションでは、あなた自身がうまくコミュニケーションを行う方法を扱います。 また、プロジェクト内での円滑なコミュニケーションを維持するための方法についても説明します。 [24]

書いたことがすべて

考えてもみてください。インターネット上では、あなたが何者であるかを判断する基準は 「あなたが何を書いたか」「他人があなたのことをどのように書いたか」 しかありません。たとえあなたが頭脳明晰で洞察力に優れ、 カリスマ性のある人物だったとしても、 あなたの書いたメールが中身のない乱雑なものだったら 他の人たちはあなたのことを「中身のない乱雑な人」とみなすことでしょう。 逆に、実際のあなたが中身のない乱雑な人だったとしても、 あなたの投稿する内容が明快で有益なものなら、 他の人たちは実際のあなたがどうであるかなんて気にしません。

自分が何かを書くときには十分注意を払うようにしましょう。 決して損はしません。フリーソフトウェアのハッカーとして長年の経験を持つ 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 のメールのような質問は失礼にはあたりません。 状況によってはちょっと非情に見えたり馬鹿にしているように感じられるような質問であっても、 それは真剣になされたものであり、 必要な情報をできるだけ手早く引き出したいという以外に隠された意図はありません。 サポートセンターの有名な質問である「コンピュータのコンセントはちゃんとささっていますか?」 というのは典型的な例です。サポート係の人は、 ただ単にコンセントがささっているかどうかを知りたいだけです。 仕事を始めたばかりのころはこの質問の前にいちいち丁寧な前置き ("すみませんが、いくつかの可能性を排除するために少々質問させていただいてよろしいでしょうか? 中には基本的すぎるものもありますが、我慢してくださいね……") をしていたのでしょうが、それにも疲れてきたのでしょう。 今や、彼女は単刀直入に「ささっているのかいないのか」を聞くだけになっています。 フリーソフトウェアのメーリングリストでも、同様の質問が散々行われています。 これは決して相手を侮辱しているのではありません。 最も明らかな (そしておそらく最もありがちな) 可能性をできるだけ早い段階で排除しておきたいというだけのものなのです。 それをよくわかっている人は、文句も言わずにその質問に従い、 よりよい結果を得ることになります。 しかし、もし文句を言う人がいてもそれをけなしてはいけません。 これは、単なる文化の相違であり、どちらが悪いとかいうものではありません。 あなたの質問 (あるいは批評) には隠れた意味はまったくないということを説明してあげましょう。 単に情報を効率的に取得したかった (あるいは伝えたかった) だけであり、 それ以上でも以下でもないと言えばいいのです。

では、何が失礼にあたるのでしょう?

先ほど、技術的な批評をすることは一種のほめ言葉にあたると言いました。 その観点から言うと、真剣な批評をしないということは一種の侮辱になるかもしれません。 これは、誰かの作業 (何らかの提案やコードの変更、バグの報告など) を単に無視することを言っているのではありません。 あとできちんと返事をすると約束したのでない限り、 何も反応しなくても一向に問題はありません。 周りの人も、単に何か言うだけの時間がなかったんだとみなしてくれるでしょう。 しかし、もし何か反応を返すのなら、決して手抜きをしてはいけません。 時間をかけてしっかり分析し、必要なら適切なサンプルを用意し、 過去ログのアーカイブから関連する議論を探すといった作業を欠かさないようにしましょう。 そんなことをしている時間はないが、でも一言だけいっておきたいという場合は、 メッセージの中に釈明をいれておきましょう ("これ、たしかバグとして報告されていたはずなんだけど、 今ちょっと探しているヒマがないんだ。ごめんね" といった具合に)。 大事なのは、文化的な基準があることを認識することです。 その基準は守ること。そしてもし守れない事情があるときは、 守れないことを認識していると知らせること。 いずれにせよ、基準が大切です。 この基準を守れなかった上にその理由も説明していないとなると、その話題 (そして関係者たち) に対して十分に時間をかけるだけの価値がないと考えているように思われてしまいます。 怠け者であると思われるよりも、 単に時間がないだけなんだということを率直に説明しておくほうがいいでしょう。

もちろんこれ以外にも失礼にあたることは多々あるでしょう。 しかしその多くはフリーソフトウェア開発に限ったものではありません。 一般常識の範囲で判断できるはずです。 もしまだご覧になっていないのなら、 2章さあ始めましょう「炎上を阻止する」 も参照してください。

人間の脳には、表情を認知するための領域があります。 通称は "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.comwww.hotmail.com、そして www.yahoo.com などで取得できます。



[24] これらの問題については、いくつか興味深い研究があります。たとえば Gutwin、Penner および Schneider による Group Awareness in Distributed Software Development もそのひとつです。この論文はオンラインで公開されていましたが、 一時しばらく見えなくなっていました。その後、改めて http://www.st.cs.uni-sb.de/edu/empirical-se/2006/PDFs/gutwin04.pdf で公開されました。もしこの URL で見つからない場合は、 また別の場所に移動した可能性があります。サーチエンジンを使って探してみてください。