| ホーム ＞ 結城浩の心がけ ＞ 技術系メーリングリストで質問するときのパターン・ランゲージ | 検索 | 更新情報 |
|
|
|
技術系メーリングリストで質問するときのコツを整理したページです。
こんにちは、結城浩です。
このページは技術系メーリングリストで質問するときのコツをご紹介します。 ここに書かれていることは「心がけ」「ヒント」「アドバイス」に過ぎません。 法律のようにこれを守る必要はありませんし、 他の人がこれを守っていないからといって怒るべきではありません。
ローカルルールを持っているメーリングリストもありますので、 ここで書かれているパターンを機械的に適用しないでください。
ページ末の 「付録」には質問のためのテンプレートも用意しましたので、 参考にしてください。
すごく急いで書いたので、表現が不適切な部分が多々あります。 随時修正していきますが、もしお気づきの点がありましたら、 フィードバックのフォームからお願いします。 改善案・ご意見を歓迎します。
みなさんからのご意見の一部は 読者からのフィードバックでご紹介しております。 いただいたフィードバックは、少しずつこの文章に反映させていこうと思っています。 感謝します。
「技術系」と書きましたが、 登場する例などから言えば「プログラミング系」という方がより適切かもしれませんね…。
言うまでもありませんが、 このページは自由にリンクしてくださって構いませんし、 メーリングリストなどでURLを紹介してくださって構いません。 再配布条件(GPL)に従って再配布することもできます。 ぜひ、みなさんのコミュニティで役立ててください。
… わからないことがあったら、メーリングリストに聞いちゃえ。 動かなかったら、メーリングリストに聞いちゃえ。 トラブルが起きたら、メーリングリストに聞いちゃえ。 …どうして回答が来ないんだろう。
問題： 「メーリングリストはサポートセンターではありません」というメールを受け取りました。 メーリングリストに参加するときの心構えって何でしょう。
技術系メーリングリストは、サポートセンターではありません。 つまり、そのメーリングリストに参加している人々は、 あなたの問題を解決するための義務は持っていません。 回答のメールを出す義務も持っていません。 たくさんメールを出して1つも返事が来なくても、 苦情や文句をいってはいけません。 自分の質問には必ず回答メールがくるはずだ、 返事が来ないのはおかしい、ぷんぷん…と怒ってはいけません。
技術系メーリングリストは、一種の「互助会」です。 ある技術に興味のある人たちが集まって、 互いに知識や情報を交換・共有する場所です。 年齢もいろいろ、経験もいろいろです。 質問に答える人も、情報提供する人も、 自分の本来の業務や勉強の合間に投稿しているのです。 メーリングリストは互いの好意の上に成り立っている助け合いの場であり、 自分がわからないところを人に教えてもらい、 自分がわかるところを人に教えてあげる場所なのです。
だから、こうしましょう：
解法： メーリングリストを「有益な回答がすぐにもらえるサポートセンター」だと思ってはいけません。 むしろ「自分もその一員になっている互助会」だと考えましょう。 自分がわからないときに人から助けてもらうだけでなく、 自分がわかるときには積極的に人を助けてあげましょう。
メーリングリストでは互いが誰だかよくわかりませんから、 適切な自己紹介が必要になります。 メーリングリストで流れたメールのやりとりは、 過去ログとしてまとめられていますので、雰囲気をつかんでおきましょう。 よく知られた事実をわざわざ聞きなおすことがないように、 検索エンジンで下調べしましょう。 メールの内容を適切に判断できるように、 用件をズバリと書いた表題をつけるようにしましょう。 他の人が話の流れを追えるように、 スレッドを切らないように注意しましょう。 自分の問題を解決してもらったあかつきには、 他の人の役に立つように まとめのメールを投稿しましょう。 …
… いまからメーリングリストに質問を投げようと思います。 メーリングリスト参加者の知恵を借りて、 何とか解決のヒントでも得られたらうれしいなあ。 丁寧なメールが大事だと思って、 「はじめまして初心者です」という表題でメールを出しました。
問題： 「表題をちゃんと書いてください」という返事が返ってくるばかり。 質問の表題(Subject)はどのように書いたらいいのでしょうか。
あなたのメールの中で、 メーリングリストの参加者がまず最初に目にするのがこの「表題」です。 本文を読む前に、あなたの問題が何であるかを知る前に読むのが表題です。
忙しい人なら、本文を読むかどうかをこの表題で判断します。 表題を読んで興味をいだけば本文を開きますし、 意味がわからなかったり、興味を抱かなかったりしたら、 すぐに読み飛ばされてしまうでしょう。
ありがちな失敗は「こんにちは」「はじめまして」「初心者です」「困っています」「教えて下さい」という表題をつけてしまうことです。 また「ありがとう」「動きました」という表題も見かけます。 これらの表題には「本文を読むべきかどうか」を判断する情報が何も含まれていません。 ですから、無視される可能性も高いことになります。
だから、こうしましょう：
解法： 表題には、用件をズバリと書きましょう。 例えば「○○で△△というエラー」「○○が実行できない」「△△と○○の違い」などです。 ポイントは、あなたのつけた表題を読み返してみて、あなたの問題を解決してくれそうな人がその表題を読んで本文へ進んでくれるかどうか、です。
「私は○○です」という 自己紹介は本文の中に含めます。 質問内容を詳しく書くときには 手順の提示や 結果の予想などを使って本文中に具体的に書きます。 正しく 用件を書いた表題は、 過去ログを検索する際にも有効になります。 …
… 質問だけを投稿したら「失礼なやつだ」という応答が返ってきました。 詳しい自己紹介を投稿したら「くどいメールを出すな」という応答が返ってきました。
問題： 質問だけでもだめ、詳しすぎてもだめなんて、困ってしまう。 どんな風に自己紹介を書けばいいんでしょう。
メールでは、相手の顔を見ることができません。 文章として表現されていなければ、その人の知識も技能も経験もまったくわかりません。 自己紹介は、読み手に対して、自分の姿を見せるためにあります。
自分の知識、技能、経験が相手にうまく伝わっていれば、 相手が回答の文章を書くときに大いに助けになります。 コンピュータを昨日買ったばかりの人に答えるのと、 コンピュータの専門的な仕事を何年もしている人に答えるのとでは、 説明の仕方は大きく変わるでしょう。
「初心者です」という表現は、あまり情報を含んでいません。 何についての初心者なのか、何を基準に初心者と言っているのかわからないからです。
だから、こうしましょう：
解法： 自分はどんな知識を持っているのか、が分かるように、自己紹介を書きましょう。 「○○会社でプログラマをやっている××と申します」と書けば、 「プログラマなんだからプログラミングの用語を使っても大丈夫だろう」と他の人に分かります。 「Javaのアプレットはよく書きますが、Servletは書いたことがありません」と書けば、 「Javaの基本的な知識は持っているのだろう」と他の人にわかります。 「初心者です」と書くのではなく 「△△については入門書のサンプルを動かした程度です」 「○○は読みましたが、仕事でプログラミングした経験はありません」 などと具体的に書きましょう。
自分の姿を伝えるのは自己紹介だけではありません。 自分の 予想やその 判断理由の述べ方を通しても、 「ああ、この人はこういうことは理解できるのだな」 と読み手に伝えることができるのです。 …
… メーリングリストにたくさん質問を投げるんだけど、誰も答えてくれない。 丁寧に文章を練って、エラーメッセージはきちんと コピー＆ペーストして、詳しく詳しく具体的に書いているんだけど、まっとうな答えがもらえません。
問題： 「結局、何が言いたいの？」というメールが来るばかり。 どうしたらみんなに考えてもらえるんだろう。
メールを読む人は、初めから読んでいきます。 途中で興味を失ったり、自分に関連がないと判断したら、 そこで読むのをやめてしまいます。
詳しいメールは大事ですけれど、 読者が読んでくれなかったら何にもなりませんし、 もちろん応答もなくなるでしょう。
だから、こうしましょう：
解法： 問題の要旨をメールのはじめにまとめましょう。 そのときに、関連すると思われるキーワード(OS, 技術, エラーの種類)などをまぜておきます。 そうすると、同じOSを持っている人、その技術に関心がある人、同じようなトラブルにあった人の注目を引く可能性があります。 「詳しい情報は以下に」と書いておけば、読者の助けになります。
要点をさらに絞ったものが 表題になります。 要点を読んで関心を持ってもらっても、 実行手順が書かれていないと、他の人は試してみることができません。 …
… 会社の業務で書いているプログラムなんだけど、どうもうまく動かない。 メーリングリストで質問しちゃえ。
問題： 会社の同僚から「恥ずかしい質問をするな」というメールが来てしまいました。 仕事の疑問はメーリングリストに聞いてはいけないのかな？
会社のメールアドレスで投稿すると、 （本人がそう思っていなくても）会社の名前を背負っていることになります。 もしかしたら、現在取り引きしている相手の会社の人がそのメールを読むかもしれません。 あまりに恥ずかしい質問をすると「この会社の人はこんなことも知らないのか」と思われる可能性がありますので、 注意が必要です。
また、 ソースを投稿する場合でも、会社の業務規定に違反する危険がありますので、注意が必要です。
逆に、アイディアに満ち、専門的な知識を含み、他の人への配慮が十分になされているメールの場合には 「ほほう、この会社のこの人は、こんなにすばらしいのか」とさりげない宣伝になる可能性もあります。
だから、こうしましょう：
解法： 自分がどのメールアドレスで参加しているかを確認しましょう。 会社のメールアドレスを使うなら、 多かれ少なかれ会社の名前を背負っていることを忘れないようにしましょう。
投稿した内容は、 過去ログとして長い期間保存され、 さまざまな人が読むことになりますので、さらにご注意を。 …
… 「こんなエラーが出る」という投稿をしたのに、 エラー解決のための返事が返ってきません。
問題： 「私のところでは再現しません」という返事ばかりがやってきます。 自分と同じ状況を、相手のところで再現させるには、どうしたらいいんでしょう。
「エラーが起こる」と主張するだけでは、 読者にはそれを再現する方法はわかりません。 技術的なやりとりでは特に「手順」が大切です。 ちょっと手順が狂うだけで起きる現象が大きく変化するからです。
自分の実行手順がはっきりしないまま投稿しないようにしましょう。 投稿者自身が何をしているのかわからないのに、読者にわかるわけがありません。
手順が複雑すぎて書けないというなら、実はそのこと自体が問題です。 問題がうまく整理されていない、 起きている現象の分析が不足していることを表しているからです。
再現する方法を文章で書くと、 手順があいまいになりがちです。 投稿者の手順を知っているのは投稿者だけですから、 投稿者ができるだけ明確に手順を表現する必要があります。
だから、こうしましょう：
解法： 自分がやった手順を箇条書きにしましょう。 そして手順に(1)(2)(3)…と番号をつけましょう。 そうすれば、同じ手順を読者も試すことができますし、 「(2)は不要なのでは？」とか「私の場合には(3)になる前にエラーになりました」のように、 番号を使って意思疎通がしやすくなります。
手順を示すだけでは十分ではありません。 その結果 「どうなると思ったのか」、そして、 「実際の結果」を書くのは大事です。 そうすれば、読者が投稿者の行動を検証し、投稿者の思考をたどることができるからです。 自分がやった手順が何かの文献に書かれているなら、 「文献の引用」を行うと読者の助けになりますね。 …
… 「手順を箇条書きで」わかりやすく書いているし、 「実際の結果」も コピー＆ペーストできちんと提示しているのに、 読者はみんなピンと来ていないみたい。
問題： 「それで？」「それがどうしたの？」「それで正しいのでは」「あなたは、どうなると思ったの？」という応答が返ってきました。 自分の考えたことをうまく読者に伝えるには、どうしたらいいのでしょうか。
投稿者が現象を勘違いしているとき、 「実際の結果」は正しいのにそれが誤っていると判断してしまうことがあります。 そういう場合、読者は手順と結果を見比べて 「まったくおかしくない。この投稿者は何が言いたいのだろう」と 悩んでしまいます。
エラーが起きるからといって誤っているとは限りません。 間違ったプログラムを書いたなら、エラーが起きるのが「正しい」振る舞いです。 ファイルが存在しなければ「ファイルが存在しません」というメッセージは「正しい」振る舞いです。
また、微妙な現象の場合には投稿者の意図を読者が読み違えることもあります。 そのときにはその「微妙な部分」がどこなのか読者がわかるように、 投稿者は記述を工夫する必要があります。
だから、こうしましょう：
解法： 自分が予想した結果を書きましょう。 「自分はこういう結果になると思いました」 「こういう表示になると思いました」「こういうエラーになると思いました」 そんな言葉と共に自分が予想した動作を記述しましょう。 そうすれば、読者は投稿者の思考を理解することができます。 投稿者の勘違いしている部分、あるいは現象の微妙な部分を踏まえた上で回答することができます。
「実際の結果」を読者に見せるためには、 手順を箇条書きにするのが有効です。 また自分がそのように予想した 理由を述べることも大事です。 …
… 「○○がうまく動きません」というメールを流したのに、 動かすための情報が返ってきません。
問題： 「どういう現象が起きましたか」というメールばかりがやってきます。 「どうなったのか」をうまく表現するにはどうしたらいいでしょうか。
「どうなったのですか」という質問は、「実際の結果」を求めている表現です。 「うまく動かない」というだけでは何も読者に伝わりません。 「このように動くと私は思います」といくら書いても無意味です。
だから、こうしましょう：
解法： 実際に起きた結果を示しましょう。 あなたの想像ではなく、実際に起きたことを述べましょう。 実際に起きたことと、あなたの予想をはっきりわけて書きましょう。
実際に起きたことを書くだけではなく、 どういう結果になると思ったか、も書きましょう。起きた現象は実は当然の結果かもしれませんから。 実際に起きた結果を示すには、 コピー＆ペーストを使うことが肝心です。 …
… 「うまくいきません」「エラーがでます」と投稿したのに、 誰からも答えが返ってきません。
問題： 「どこまで出来たの？」「何が出来て、何が出来なかったの？」と逆に聞かれてしまいました。 どう書けばいいのでしょうか。
何かの結果を得るまでには、必ず「ステップ」があります。 簡単な例を挙げると、プログラミングでは、 「コーディングが完了する」→「コンパイルが正常に終了する」→「実行が正常に終了する」→「期待した結果が得られる」 のようなステップがあります。 「うまくいかない」と書いただけでは、投稿者がどのステップまで進んだのか、読者にわかりません。 どこまで進んだのかがわからない限り、適切な回答は得られません。
だから、こうしましょう：
解法： あなたがどのステップまで進むことができたのかをはっきり書きましょう。 「○○までは出来ました」「○○はできませんでした」 を明確にしましょう。
「コーディングはできたけれど、コンパイルエラーになった」
「コンパイルは正常に終わったけれど、実行時にエラーになった」
「実行も正常に終わったのだが、結果がファイルに出力されなかった」
「ファイルは作成され、結果も書き込まれたのだが、その結果が期待したものとは異なっていた」
「出来ました」というだけでは不十分かもしれません。 出来たと思った 理由を述べることが必要になる場合もあります。 どういうステップを経るのが正しいのかを間違えている場合もありますから、 手順を箇条書きにしましょう。 エラーメッセージが表示されたら、 コピー＆ペーストして示しましょう。 …
… 現象を再現するための手順を箇条書きにして投稿したけれど、 他の人から適切な回答が返ってきません。
問題： 「同じ手順をやりましたけれど、その現象は起きません」という返事が返ってきました。 自分のところでは起きるのに。どうしたらよいのでしょうか。
現象を再現させることは問題解決の重要な一歩です。 手順を箇条書きにすることは大切ですが、 それだけでは不十分な場合があります。
「数値を入力したら異常終了します」と書くよりも、 「100を入力したら異常終了します」と書く方がよいでしょう。
もっとよいのは「-10, -20, 0では異常終了しませんが、100を入力したら異常終了します」のように 現象が起きる場合と起きない場合の違いを明確にすることです。
「100を入力したら…」と書くのはよいけれど「正の数を入力したら…」と書くのは不適切です。 そこには事実だけではなく書き手の「推測」が入ってきているからです。 推測を書く場合には、事実と分けて書きましょう。
だから、こうしましょう：
解法： 具体的な値を提示しましょう。 ちょっと変わった手順があるなら、それを明示しましょう。 同じ方法でも、入力によって結果が変わるようなら、それを明示しましょう。 現象が起きる場合と、起きない場合の違いをできるだけ明記しましょう。
「異常終了します」と書くだけではなく、表示されたエラーメッセージを そのままコピー＆ペーストするのがよいですね。 再現させるためには、手順だけではなく 環境を明示する必要もありますね。 …
… 「エラーが起きました」って書いているのに、 誰も助けてくれません。
問題： 「どんなエラーメッセージが表示されましたか」と言われてしまいました。 どう書いたらいいのでしょうか。
トラブルが起きた場合にエラーメッセージが表示されることがあります。 エラーメッセージには重要な情報が多数書かれています。 初心者には、エラーメッセージが意味していることがよくわからない場合もありますが、 熟練した人には、エラーメッセージを見るだけで、 他の情報を何も見なくても問題解決の方法がわかる場合があります。
だから、こうしましょう：
解法： 表示されたエラーメッセージをそのままコピー＆ペーストしましょう。 自分でタイプしなおしたり、自分で解釈・要約しようとしてはいけません。
そのエラーメッセージが表示されるまでの 手順を箇条書きにすると、他の人が再現テストできます。 再現テストが簡単にできるように、 事実の提示を行いましょう。 …
… 「○○は出来ましたが、××は出来ません」と ステップを明記したのですが、なんだかみんな私を疑っているみたい。 本当に出来たんだってば。
問題： 「どうして○○が出来たと思ったのですか？」なんて聞かれてしまいました。 ちゃんと出来たのになあ…。
人は、現象の判断を誤る場合があります。 「うまく○○ができた」と思っていても、 実際にはできていない場合もよくあります。 前回のテストの結果が残っていて、 それを見て「出来た」と判断してしまうこともよくあります。
投稿者が ステップを明記したとしても、その判断が誤っていたら、適切な回答は望めません。 けれど、判断が誤っているかどうかを投稿者自身が考えるのは難しいものです。
だから、こうしましょう：
解法： 「○○と考えたのは、○○と表示されたからです」のように理由を明記しましょう。 理由と根拠を明記して、投稿者の判断が正しいかどうかを読者に考えてもらいましょう。
「正常動作したと考えたのは、ファイルの内容が100になっていたからです」
「ソースの変更が正しく反映されたと考えたのは、オブジェクトをすべて削除して再コンパイルしたからです」
「マシンのせいではないと考えたのは、他の3台のマシンでも同じ現象が起きたからです」
根拠を示すために、 文献の引用をする必要があるかもしれません。 仕様書を判断の理由にするのはよい方法です。 表示された エラーメッセージをコピー＆ペーストして「こういうメッセージが表示されたからです」と示すのもよい方法です。 …
… 判断の理由を示そうと思ったんだけど、 何て書いたらいいかよく分からない。 参考書にそう書いてあったからそうかな、と思っただけなんだもの。
問題： 「そう判断した理由は何ですか」と聞かれたときに、 「参考書に書いてあった」だけじゃだめなんでしょうか。
参考書はたくさんあります。 また、参考書が正しい場合もあるし、間違っている場合もあります。 昔は正しかったんだけど、現在では古くなっている場合もあります。 参考書は正しいんだけど、投稿者の適用が間違っている場合もあります。 単純に投稿者が誤読している場合もあります。
手元に本があるなら、手間を惜しまず書名を書きましょう。 「某参考書」と書いても無意味です。 それは読者に何の情報も与えないからです。
だから、こうしましょう：
解法： 参考書を明記しましょう。 本の名前やISBN、ページ番号などを使って、 読者がその記述を同定できるようにしましょう。 微妙な表現があるなら、適切な分量だけ引用しましょう。 そうすれば、その本を持っていない読者も考えを進めることができるからです。 もしも参考にしたWebページがあるなら、 そのURLを明記しましょう。
判断の理由を示すと同時に、 関連ソースを示すことができれば、 メーリングリストの参加者が助けてくれる可能性は高くなります。 単なる参考書ではなく 仕様書にあたるのはとてもよい態度です。 著者や作者が間違っていることだってありえます。 そんなときには、 本人に聞くのが確実です。 あなたの持っている本を読者が持っているとは限りませんから、 「○○ページの手順を実行しました」のように書くだけではなく 具体的に 手順を箇条書きに示したほうがいいですね。 …
… 自分がやっていることを文章で説明したり、 手順を箇条書きしているんだけれど、 読者は今ひとつピンと来ていないようである。
問題： 「もっと具体的に書いて」と言われるけれど、 箇条書き以上、どう具体的に書けというのでしょう。
やっていることを最も具体的に示すものはプログラムです。 自分の動かしているプログラムから、関連するところをうまく切り出せれば、 読者が現象を再現するのに大いに役に立ちます。
ただし、大量のプログラムをメーリングリストに流されては迷惑ですし、 業務上の秘密が他人に漏れてしまわないように注意しなくてはなりません。 実行ファイルを添付しても、ウイルスの危険性があるので、誰も実行してはくれないでしょう。
だから、こうしましょう：
解法： 関連するソースを抽出して、メールの本文中に含めます。 多すぎず、少なすぎずという分量の判断は難しいことですが、 読むのに苦痛ではないくらいの量に抑える必要があり、 でも問題の本質がわかるほどには多くなければなりません。 もっともよいのは、現象を再現するためのミニマムなプログラムをあらためて作ることです。 そうすれば、投稿者自身が現象をよりよく理解することにもつながるからです。
自分の作ったプログラムを提示するだけではなく、 自分の環境を明示することも大事です。 …
… 自分の投稿にやっと回答が返ってきたよ。うれしい、うれしい。でも、まだ解決しない。 「もう少し詳しく説明してほしいって」メールを出してみよう。
問題： 「スレッドを切らないように」という注意のメールをもらっちゃった。スレッドって何？
メーリングリストのメールはばらばらではありません。 1つのメールに対して複数のフォローアップ(レスポンス、レス、回答、追加質問…)のメールがまるで糸のように連なっているのです。 このメールの流れを「スレッド」と言います。 1つのスレッドの中にあるメールはある話題に関することで、 他のスレッドのメールは他の話題に関すること。 後から1つの話題を追いかけるときには、そのスレッドをたどっていくことになります。
スレッドを形成するのは、 メールの中に含まれる「In-Reply-To」ヘッダという情報です。 これは一般にメールソフトの「返信」機能によって自動的に付加されます。 直接関連する話題なのに新しくメールを出すとこの「In-Reply-To」が設定されません。 つまりスレッドが途中でプチンと切れてしまうことになります。 これでは、 過去ログを使って後から話題を追いかけようとする人が道に迷ってしまいます （RFC 2822によれば、スレッド形成には「In-Reply-To」よりも、 むしろ「References」を使うというご指摘を木下さんよりいただきました。 ご指摘を感謝します）。
だから、こうしましょう：
解法： 関連する話題ならメールの「返信」機能を使って投稿しましょう。 そうすればスレッドが切れません。 逆に新しい話題は「返信」機能を使わずに新規メールとして投稿しましょう。 そうすれば1つのスレッドに多数の話題が混在することを避けられます。
新規メールでも、返信メールでも、 表題を適切につけることは常に大切です。 過去ログをスレッド形式で読むことができるメーリングリストも多数あります。 メールを引用するときは 適切な量だけ引用しましょう。 …
… 親切な人が情報をメールしてくれたおかげで、うれしいことに問題が解決しそうです。 でも受け取ったメールの中でよく意味のわからない部分がありましたので、 スレッドを切らないように返信して、「もう少し詳しく教えて」とメールしました。すると…
問題： 「意味がわからないのはどの部分ですか」 「全文引用は避けてくださいね」と言われてしまいました。 全文引用を避けるってどういうことでしょう。
メールに返信するときには、しばしば相手のメールの内容が「引用」されます。 メールソフトの設定によって、 相手のメールの文章の前に「＞」のような記号がつく場合もありますし、 メールの末尾に相手のメールの文章がすべて付加される場合もあります。
いずれの場合でも、 相手のメールの文章すべてを付加したまま返信しては、 メールの分量が非常に多くなってしまいます。 そうすると、 相手のメールの中の「どの部分について」詳しく知りたいのかがわかりにくくなってしまいます。 これが全文引用の弊害です。 相手のメールの「どの部分について」言及しているのかが不明確では、 質疑応答も議論も成り立ちません。
だから、こうしましょう：
解法： 全文引用を避けて返信しましょう。 相手のメールのどの部分について、 自分がコメントしているのかが明確になるように、 適切な量だけ引用するように心がけましょう。 ベテランの人のメールをよく読んで、どのように引用を整理、編集しているかを観察しましょう。 また、相手が自分のメールを引用しやすいように書く工夫もしてみましょう。
手順に番号をつけて箇条書きにしておくと、適切な量の引用がしやすくなります。 メールではなく、 文献の引用をするときにも、適切な量になるように心がけましょう。 メールの引用の仕方を観察するには、 過去ログが便利ですね。 …
… 私が持っているのは参考書Aです。 別の人が持っているのは参考書Bです。 AとBで書いてあることが違うので、議論が平行線になってしまいます。
問題： 「仕様書ではどうなっているのか」という投稿が流れたけれど、 仕様書とはいったいなんでしょう。
仕様書とは、そのシステムの構造や振る舞いを定義・規定している文書です。 専門家向けに書かれていて読みにくかったり、ぶ厚かったりしますけれど、 そこに書いてあることが議論の基礎となります。
プログラミング言語の問題なら、その言語の仕様書にあたるのが確実です。 フレームワークの問題なら、フレームワークのリファレンスにあたるとよいでしょう。
参考書はあくまで参考になる本、というだけのことです。 最終判断は仕様書にあたるのが一番です。 ただし仕様書に書かれていないこともたくさんあります。 そのときには「仕様書には書かれていないが、○○の実装ではこうなっている」などとして 議論が決着する場合もあります。
だから、こうしましょう：
解法： 仕様書を探しましょう。仕様書を確認しましょう。 最終的な結論に収束させるために仕様書を利用しましょう。 場合によっては「仕様書には書かれていない」ことを確認しましょう。
水掛け論にならないようにするためには、 判断の理由を示すことが大事です。 文章だけによる解説ではなく、具体的な 関連ソースを付加することも、相互理解に役立ちます。 …
… どうも話がかみ合わない。 私の書いたことが全然理解されていないようだし、 返事としてやってきたアドバイスは、私にまったく理解できない用語が使われている。
問題： メールの中で「あなたの環境は？」と聞かれました。 環境はどんな風に書き表したらいいのでしょう。
Windowsで起きている問題に、Macでの解決方法を示してもあまり役にはたちません。 ソフトのバージョンを確認せずに現象が再現する／しないと論じても、 有益な情報は得られないでしょう。
だから、こうしましょう：
解法： 自分のOS, メモリ量, 使用ソフト, バージョン, 周辺機器, マシンの種別, ... などを明記しましょう。 どの情報が有効かどうかは一概にいえませんので、柔軟に考えましょう。 ある場合にはバージョンの最後の一桁の違いが重要かもしれません。 またある場合には同時に走らせているアプリケーションの数がキーになるかもしれません。 しかし、自分の環境を明記することは、問題解決に役に立つことは覚えておきましょう。
環境だけではなく、実際に動かしたプログラムの 関連ソースや、自分が行った 手順を明記することもお忘れなく。 …
… きちんと 自己紹介もしたし、 問題の要旨もまとめた。 手順も書いたし、 メッセージはコピー＆ペーストした。 これできっと、回答が得られるなあ。
問題： ところが「過去ログを読みなさい」という一言が返されるだけだった。 どうして解決法を教えてくれないの。
多くのメーリングリストでは、 それまでのメールのやりとりを「過去ログ」あるいは「アーカイブ」といった名前で保管しています。 その過去ログはWebを使って検索したり閲覧したりできる場合があります （メーリングリストによってはメールでコマンドを送って過去ログを取得する場合もありますので、ご注意ください）。
過去に同じような事例があったにも関わらず、 再度、参加者が手を動かして回答するのは労力の無駄、と考える人は多数います。 （そう考えない人もいます）。
初心者向けのメーリングリストに高度な質問をしても誰も答えてくれないかもしれません。 逆に高度な議論をしているメーリングリストにあまりにも初歩的な質問をすると無視されるかもしれません。 過去ログを読むと、そのメーリングリストの雰囲気がよくわかります。 雰囲気をつかんでから投稿しないと、思わぬ恥をかいたり、トラブルの元になったりします。
だから、こうしましょう：
解法： 投稿前に過去ログをチェックしましょう。 過去に、自分の問題と同じ問題がなかったか、 類似する問題がなかったか、その解決方法はどうか…。 そのような手間をかけた上で、まだ解決しないときにはじめて投稿しましょう。 過去ログを読んで解決しなかったなら「過去ログの○○は読みましたが…」 という説明を本文にいれましょう。 そうすれば「過去ログを読みなさい」という指摘からまぬかれるかもしれません。 そのメーリングリストに、自分の投稿が適切かどうかを判断するときにも、過去ログは役に立ちます。
過去ログという形ではなく FAQ(よくある質問とその回答) という形になっている場合もありますので要チェックです。 はじまったばかりのメーリングリストには過去ログがないかもしれません。 でも、投稿前には 検索エンジンでチェックすることもお忘れなく。 …
… 過去ログには答えはなかった。 じゃあさっそく投稿しようっと。
問題： 投稿したところ「Googleで調べると見つかりますよ」という一言が返ってきました。 どうして解決方法を書いてくれないの？
現在、Webページには膨大な量の「問題→解決」のためのページがあります。 アプリケーション、言語、プロトコル、ハードウェア…さまざまな分野に対して、 さまざまな難易度の解説ページがあります。
メーリングリストに問題を投げて、回答を待つのも結構ですが、 そのまえに、関連するキーワードでWebページを検索するのはよい態度です。
メーリングリストで誰かが書いてくれる短い解説の文章よりも、 詳しい手順つき、図解つきの解説ページが見つかるかもしれません。
あるいはまた、 自分が投稿しようとしているメーリングリストよりももっと 適切なメーリングリストが見つかるかもしれません。
だから、こうしましょう：
解法： 検索エンジンで調べましょう。 Google(グーグル)、 Infoseek(インフォシーク)、 Goo(グー)、 Excite(エキサイト)、 Lycos(ライコス)、 FreshEye(フレッシュアイ)、などなど無数の検索エンジンが存在します。 あなたの問題に関するキーワードを放り込んで、まずは下調べをしてみましょう。
メーリングリストの 過去ログやFAQを検索するのもお忘れなく。 それから、場合によっては、 参考書の著者やWebの作者本人に聞くのも有効です。 …
… 参考書を読んでるんだけれど、どうもおかしいから、他の人の意見を聞いてみよう。 Webページを読んでやってみたんだけれど、うまくいかないから、他の人の意見を聞いてみよう。
問題： メーリングリストで議論が巻き起こったけれど、結局結論は出なかった。 いろんな意見で何を信用すればいいのでしょうか。
メーリングリストで意見を聞いたり、質問の回答をもらったりするのは有益です。 自分の想像のつかないような情報を得たりします。
けれども、 参考書の疑問や、Webページの問題に、 決定的な解答が得られる保証は何もありません。 メーリングリストで意見を言っている人は、みなそれぞれの意見を言っているだけですから。
だから、こうしましょう：
解法： 参考書の疑問は著者本人に尋ねましょう。 Webページの問題点はそのページの作者に尋ねましょう。 もしかすると、それは単なる誤植かもしれません。 ただし、 著者本人に尋ねたとしても返事が得られるという保証はありませんし、 返事が返ってこなくても怒ってはいけません。
尋ねた結果は まとめのメールとして再度メーリングリストに流すといいですね。 …
… やったー。動いたぞー。問題解決だー。よかったよかったー。やっぱりメーリングリストは便利だー。 ありがとー。感謝しますー。
問題： 問題が解決したら、お礼のメールを出す必要があるのかな。どう書けばいいのかな。
情報を送ってくれた人に「お礼」するのは大事ですけれど、 ただ「ありがとうございます、解決しました」だけでは不十分です。 問題と解決のあいだにはさまざまな情報の流れがあったはずです。 うまくいったアドバイス、機能しなかった手順、紹介されたWebページ…。
情報はメールで流れますから、何がどうなって、 結局どうなったのかを後からたどるのは難しいものです。 またそれをすべてメーリングリスト管理者に負わせるのはやりすぎです。
だから、こうしましょう：
解法： 問題の解決で恩恵を受けた人が、問題・解決・参照リンクなどを簡潔に記述し、 まとめのメールとしてメーリングリストに投稿しましょう。 情報を送ってくれた人たちへのお礼も大事ですけれど、 もっと大事なのはメーリングリストという「場」を支えている人々への情報のフィードバックです。 そうすれば同じようなトラブルが起きたときの助けとなります。 そしてまとめのメールを流すことによって、 あなたは、メーリングリストから恩恵を受ける(take)立場から、貢献する(give)立場に変わるのです。 ギブ・アンド・テイク(give & take)、これがコミュニティを支えます。
もちろん、まとめのメールは スレッドを切らないように返信で投稿します。 また、「○○のエラー(まとめ)」「△△問題の解決手順」「○○に関する結論の要約」などのように 適切な表題をつけることもお忘れなく。 まとめのメールは、FAQのページを作るための重要なもとネタになります。 そして、ここから先は、メーリングリスト管理者のパターンランゲージへとつながっていくことでしょう。 …
… この「技術系メーリングリストで質問するときのパターン・ランゲージ」はなかなか有効だな。 じゃあ、これにちゃんと従ってメールを投稿すれば完璧だな。
問題： 「ここのメーリングリストでは○○禁止です」という注意を受けちゃった。 ちゃんとした投稿しているのになあ。
メーリングリスト(ML)にはいろいろあります。 小人数のML、大人数のML、初心者向けのML、専門家向けのML、 議論を中心にしたML、わいわいとおしゃべりを楽しむML、 商業活動絶対禁止のML、宣伝大歓迎のML…。
メーリングリストにはいろいろあり、 それぞれのルールや習慣があります。 「このメーリングリストでは○○禁止」のように明文化している場合もありますし、 明文化されていないこともあります。
多くの技術系メーリングリストでは、 次の行為は嫌がられますが、 メーリングリストによっては許可されている場合もあります。
メーリングリストごとにそれぞれの文化や習慣があり、 そこに集まる人の人数や性格によっても、 喜ばれる行為や嫌われる行為は変化します。
だから、こうしましょう：
解法： そのメーリングリストのローカルルールを探しましょう。 そのメーリングリストの運営方針やローカルルールは、 メーリングリストのWebページなどに書いてあります。 もしもローカルルールが見つからなかったら、 過去ログを読んでみましょう。 そのメーリングリストはどんな雰囲気ですか。 どんなやりとりが行われていますか。 あなたの投稿したい内容に似た投稿はなされていますか。 この「技術系メーリングリストで質問するときのパターン・ランゲージ」は一般的なガイドにすぎません。 郷に入れば郷に従え。 あなたの参加しているメーリングリストの方針に従いましょう。
過去ログを読むとメーリングリストの雰囲気をつかむことができます。 そもそも メーリングリストは互助会のようなものですから、一方的に質問するのではなく、 互いに情報交換する意識を持つといいですね。 …
以下に、質問のためのテンプレートを例示します。 この部分はpublic domainにしますので、どうぞご自由にお使いください。 ただし、これを質問のたびに全部使うのはいささかくどいですので、 適宜修正して（不要な部分は削除、補うべき内容はより詳しく）お使いください。
【所属機関や自分の技能を表現する解説】の【氏名】です。 ○○を実行すると、○○というエラーになる問題で困っています。 原因または解決策をご存知の方はいらっしゃいませんか。 私の行った手順は以下です。 (1) (2) (3) すると、以下のような結果になりました。 【表示されたものをコピー＆ペーストする】 私は【予想結果】になると思いました。 なぜなら、【参考資料】には、 以下のように書かれているからです。 > 【適切な分量の引用】 > 【適切な分量の引用】 > 【適切な分量の引用】 原因を確かめるため、以下のようなテストを行ってみましたが、 問題の解決には至りませんでした。 (a) 入力を○○ではなく××にしてみた →上記と同じ結果になった (b) ソースプログラムの○○をやめて、××にした →以下のようなコンパイルエラーになった 【エラーメッセージのコピー＆ペースト】 なお、私の環境は以下の通りです。 【マシン, メモリ量, 関連周辺機器, OS, 利用ソフト, バージョンなどを箇条書きに】 検索エンジンで○○、××、△△を検索しましたが、 ◎◎に関するページばかりで、解決に役立つ情報は見つかりませんでした。 このメーリングリストの過去ログも調べましたが、 ○○に関する話題は見つかりませんでした。 【個人を識別する適切な署名】
上記のテンプレートを利用した質問の例を示します。 これは1例にすぎません。 こう書かなければいけないわけでもありませんし、 こう書けば必ず回答がくる保証もありません。 あなたが投稿する場合には、 あなたの参加しているメーリングリストの 過去ログを読んで、みんなが親切に答えてくれた投稿メールを参考にするのもよい方法です。
To: Perlの技術ML From: とむら <tomura@textfile.org> Subject: CGIの文字化け 先月からPerlでCGIを書きはじめた、とむら(仮名)と申します。 Cのプログラミング経験は3年ほどありますが、PerlやCGIははじめてです。 市販されているXXXXスクリプトを修正して実行すると、 文字化けを起こすという問題で困っています。 原因または解決策をご存知の方はいらっしゃいませんか。 私の行った手順は以下です。 (1) XXXX.cgiをhttp://xxxx からダウンロードする。 (2) 管理ファイル名$adminの値をadmin.datからadmin.txtに変更する。 (3) 見出しを「一覧」から「ソフトウェアの表示」に変更する。 (4) XXXX.cgiをサーバにFTPで転送する。 (5) XXXX.cgiのパーミッションを 755(rwxr-xr-x)にする。 (6) ブラウザからXXXXにアクセスする。 すると、 「ソフトウェアの表示」 と表示されるべき部分が、 「ャtトウェアの侮ヲ」 と表示されてしまいます （最後の「ヲ」は半角文字です。 そのままメールすると読めなくなると思い、ここだけ全角で書きなおしました。 あとは表示されたものをそのままコピー＆ペーストしています）。 手順の(3)を行わないと、正しく「一覧」と表示されます。 関連すると思われるスクリプトは以下のようになっています。 (これより前に100行ほどあるのですが、多すぎるのでカットしました) print "<head><title>$title</title>"; print "<body>"; print "<h1>ソフトウェアの表示</h1>"; print "</body>"; print "</html>"; ローカルマシンのコマンドラインから、 -cwで文法チェックしても異常は見つかりません(以下のようになります)。 perl -cw XXXX.cgi XXXX.cgi syntax OK なお、私の環境は以下の通りです。 (ローカルマシン) ・Windows NT 4.0 ・Internet Explorer 5.0 (サーバ) ・自作CGIが使えるXXXXプロバイダのサーバ ・サーバはApacheですが、バージョンは不明です。 検索エンジンで「文字化け CGI」を検索しましたが、 解決に役立つ情報は見つかりませんでした。 過去ログも読みましたが、探し方がまずいのか、 関連する情報を見つけることはできませんでした。 ---- とむら(仮名) tomura@textfile.org
（以下は、ほそのひでともさんからの指摘を元にしたメモです。）
会社の仕事に関連した質問を投げるときには、 会社の名前を背負っていることを忘れないようにする必要があります。 特に顧客のネットワークに関する情報の取り扱いには注意しましょう。 表示された メッセージをコピー＆ペーストして投稿するときに、 うっかり顧客のドメイン名や、IPアドレスまでそのまま公開してしまうと、 顧客の情報が全世界に公開されてしまう危険性があるからです。 顧客のネットワークに関する情報を隠蔽する手段として、 「192.168.x.yのようなプライベートIPアドレス」に置き換えたり、 「example.co.jp等の例示用ドメイン名」を活用したりする方法があります。
読者からのフィードバックを除いた、 この文書全体はGNU General Public License(GPL)のもとに置きます。 それぞれのコミュニティで活用してくださることを期待します。
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
なお、 「質問のためのテンプレート」はpublic domainです。 何の制限もありません。 自由に使ってください。
あなたのご意見・感想をお送りください。 あなたの一言が大きなはげみとなりますので、どんなことでもどうぞ。
検索エンジンで探したページのURLです。 この他にもリンクしてくださっているページがありましたら フォームからURLをご連絡ください。
公開直後に情報・意見を送ってくださった、以下の方々に感謝します(順不同)。
木下達也さん、伊藤哲さん、い〜じま け〜こさん、 なみかわさん、西田忠弘さん、中村弘輝さん、根津智幸さん、澤田保隆さん、川橋全人さん、空峰翼さん、OZAWA -crouton- Sakuroさん、上手裕さん。
このほかにも非常にたくさんの方からメールやフィードバックをいただきました。 感謝します。 読者からいただいた感想・フィードバックのほんの一部をご紹介いたします (プライバシーそのほかをかんがみて、一部編集しています)。 みなさんありがとうございます。
◆ とても参考になりました。 自分もいくつかのMLを運営しているので「あーいるいる、こういうひと」と思うことばかり。 結局技術系MLへの投稿の投げ方は「論文と同じである」ことにも気がついたり。 ケータイメールやBBSから流れてきた人にはまったくの異質の文化であるから こういう悲しい行き違いがあるのかもしれません。 (24歳 大学生)
◆ 私自身もC言語開発プラットフォームのMLで回答する立場、質問する立場にあります。 マナーはそれぞれですが、やはり失礼なメールを受取る事はしょっちゅうです。 結城様のこのページを見て、なるべく腹を立てないようにしております。 一度、ML上でこのURLを紹介したのですが、それでも相変わらず同じようなメールが流れてきます。 でも、寛容が一番の薬なのですね。 このようなページを作って頂いて有り難うございます。 (プログラマ)
◆ 大変分かり易く親切な解説だと思います。 こういった内容が、あちこちのパソコン雑誌や入門書など目に付く ところにあればいいな（いらいらが少しは減る）と思いました。 表題での「ありがちな失敗例」として、 「教えて下さい」というのもよく見ます。 また「ありがとう」「動きました」というのもよくあります。 お礼の言葉だけでなくまとめを書くべき、と後ろの方に書いてあり ますが、「表題」のところでこういうタイトルも中身がないのだ、 ということを少し触れた方が良いかなと思いました。 私が考えたタイトルの上手な付け方のコツは、 (1)本文を書き終えてからタイトルを考える。 (最初にタイトルを書いてから本文を書くと失敗することがある) (2)本文の中からキーワードを見つける (3)キーワードを使って質問内容をズバリ一言で表す簡潔な言葉にする などです。
結城：ご指摘を元に、 「表題」に少し加筆しました。 また、本文を書き終えてからタイトルを考えるというのは、 私自身もまったく同じように考えるときがあります。 メールの「表題」を入力するフィールドは本文の後に置いた方が有益ではないかとも思っています。 「メールを書く心がけ」のページでは、 「表題は内容の要約であって、本文の一行目ではありません」 という解説文を書きました。
◆ すばらしいページですね。 自分がメールを書く際に気を付けている点は網羅されています:) (というよりも、それ以上です!) 「文献の引用」の部分ですが、書籍名を示すだけではなく、 「実行手順」も必ず示すようリンクを張ってはいかがでしょう? いくつかの ML では"〜の p.xxx の内容を実行しました。"と 送ってこられる方がいらっしゃいますが、 同じ書籍を持っている人でなければ、それに応えることは出来ません。 この場合は、"〜の p.xxx を参考にして、〜の順で実行しました"のように 実行手順を併記してもらう方が回答しやすいのではないかと思います。 しかし、読んでいて思ったのですが、 これを読んだ人の一部はメーリングリスト = 質問をする場という 勘違い的な思いこみをしてしまいそうですね…。 なんとかしてメーリングリストのおもしろさを伝えられると良いのですけどね。 いろいろ書いてしまいましたが、すばらしい文書だと思います。 では。 (22歳 大学生)
結城： ご指摘を参考に、 「文献の引用」を少し加筆しました。 感謝します。
◆ 何度か同じ趣旨で同じ目的の文章を書きかけては 「やっぱり面倒だ」 「わざわざ教える必要もないだろう、無視で教えるべきだ」 と投げてきた自分にはできなかったことをやりとげ、 公開、維持されている結城さんには、ちょっと尊敬してしまいます。 思えば、わたしのモチベーションがおごりや苛立ちだったので 当然の結果かもしれません。 なにはともあれ、今後わたしは悩まずに、 一言リンクを返すだけで済むので本当に有りがたい(笑） なにより、ここを読んで学ぶことがある 多くの悩める方にとってすばらしい贈り物でしょう。 ご苦労様でした。そして、有難う！ (30歳 ゲーム開発)
◆ すばらしいです。 『ありがとうございます』と書かせてください。 自分/他人を含めて、再度投稿方法を見直す良い機会を提供していただけました。 p.s. 英語化してみてはいかがでしょうか。 時間的に不可能な場合、英語化していただける方を募ってはいかがでしょうか。 （残念ながら私にはスキルが無いのですが） 全世界的に必要な内容だと感じます。 勝手なことを言って申し訳ないと思っておりますが、 内容がすばらしいのでもったいないと思いまして...。 まずは、御礼まで。 (34歳 組込プログラマ)
結城：ご意見感謝します。 なるほど。英語化はいいですね。 残念ながら、結城自身はその時間を作り出す余裕がいまはありません。 どなたか、英訳してくださる方はいませんか？ 大歓迎いたします。 ご連絡いただければ、 必要に応じて、HTMLの元のテキストファイルをお渡しすることもできます。
◆ 第一印象は「結城さん,良くぞ書いてくださいました」です. ありがとうございます.率直に感激すると共に感謝しております. さて,ML 初心者にとって一番難しく,おそらく一番嫌な思い出になりがちなのが "ローカルルール 「郷に入れば郷に従え」"(タイトルは,「自分にあったMLを探そう」の方がいいかなと思いました.)ではないかと思います. 今後ここは充実されて欲しい部分です. ML は「特定の関心や目的,技術に対するスタンスを共有している人たちの互助」という事が, 結城さんの文全体を読めばわかるのですが,少し散らばって書かれている印象を受けました. ちなみに,私が参加しているいくつかのML は大きく分けて2つの傾向が 有って,トラブルの原因となりがちなのは...
1. 技術力を深め,その技術を習得し習熟する事自体が目的の人たちが集うML(情報工学を専攻している学生さんや,研究者さんが多い)
2. 技術を使って付加価値を生み出す事を目的としている人たちが集うML (職業プログラマ,サンデープログラマなど)
1. の目的の人たちが多く集う ML に,2 のスタンスで質問を投げ, 「何故私達があなたの仕事を手伝わなければいけないの?」などと, きつーいフォローをもらっている人もいます(文化の違いに寛容でない人が多いみたいです). 過去ログを見るときにも, ほとんどフォローされていない質問に一定の傾向が無いかも留意したほうがいいと思います. やんわりと拒絶されているという事だと思います. (33歳 職業プログラマ)
結城：メール感謝します。 「自分にあったMLを探そう」というのは確かによいパターンです。 実はこの「技術系メーリングリストで質問するときのパターン・ランゲージ」を書く前に、 「技術系メーリングリストのパターン・ランゲージ」という、より一般的な文章を書いていました。 そのときには、「自分にあったMLを探そう」というパターンを含めていました。 しかし、それを考え始めると「入会時」「退会時」にまつわるさまざま、 さらに「議論」「フォローアップ」「質問への回答」など、 それだけで大量のパターンを抱える部分への言及が必要になってしまう…うう。 まあ、時間ができるごとに、少しずつ拡充していきたいと思います。
◆ すばらしい。
◆ パソコン通信の時代から、「ネットワークを通じて先輩諸氏のお知恵を借りる」方法で私も成長してきた訳ですが、 最近仲間になった方々の投稿スタイルを見ていると、 ちょっとつきあいにくい感じがすることがあります。 一応、私のホームページにもネチケットなる項目を入れて居ますが、 やはり言うべきことはだれがが言わなければネットの世界がすべて２ちゃんねるみたいなスタイルになりかねません。 ＃ホンネという点では２ちゃんスタイルも面白いですが また、このページの内容を（私なりに消化したうえで） 私のホームページに活用させて頂きたいと思っています。 今後ともご活躍を期待します。 (64歳 分類すると年金生活者)
◆ このページを読んだら日ごろの疲れが取れた気がします。 ありがとう。 (30歳 ISPサポート)
◆ いくつもの事例を丁寧にパターン化してあって、とても参考になりました。 メーリングリストや職場での直接受ける質問についての私の感想は、 自分の置かれている状況、困っている状況が的確に説明できる人や場合は、 問題の半分以上解決できた状態にある。言い換えれば、 困っている人は自分が何に困っているかを的確に掴んでいない、 という状況にあることがほとんどだなということです。 困った人が、最初からきちんと自分の状況を説明できないというのは、 ある種当然のことだと思います。この文章を読んで、困っている人たち自身に、 自分のおかれている状況を冷静に見直す習慣、 あるいは、そういう実力を付けていただけるのが、一番だなと思います。 (41歳 会社員)
◆ ああ、私が言いたい事が全て書いてあると感じました。 私はソフトウエアの技術者ですが、 最近、MLにメールを投げてくる人の自己解決能力が弱いと良く感じています。 また、会社内で解決できてもおかしくないような事までMLに投げてくるような事も多く、 いったいこの人の会社は何をやっているのだろうと感じる事もしばしばです。 会社の事情というのもわかりますが、 右も左もわからないような人にお客様に収めるプログラムを作らせてしまう会社も会社だとよく思います。 プログラムは一朝一夕に出来るものではありません。きちんと教育してあげる事は必要だと思います。 会社で育ててあげないと結局その会社のためにもならないと思うのですが、 どうなんでしょうか。 (37歳 会社員)
結城：メール感謝します。 お気持ちは理解できます。 コンピュータ関連の業務は、非常に（異常に）変化の激しいものであり、 なかなか会社内での教育体制も整っていないのかもしれませんね。 インターネットの普及と共に、メールを使う母集団が大きくなったことから 自己解決能力がまだ身についていない人の声も流れるようになったのかもしれません。 自己解決している人は、質問のメールは投稿することは少ないでしょうから。
話は少しそれます。技術力のある人の中には、 あまり丁寧に教えるとかえって教育的ではない、 と考える方もいらっしゃいます。 MLに質問すれば、いつも丁寧に答えてくれるものだと考えてしまい、 自分で解決しようという気持ちが薄れるのだということです。 確かにそういう面もあるかもしれません。 私自身はどう考えているかというと、 回答をすることによって、自分の知識を広くしたり、 自分の理解を深めたりする態度でいたいと思っています。 ええと、言葉足らずですが、この話はきっといつか「技術系メーリングリストで回答するときのパターン・ランゲージ」に つながるのだと思いますので、メモ代わりにここに書いておきます。
◆ 流すように読んでしまい，ちゃんと精読していないのですが，その段階でも十分に興味をそそられ，かなり共感できる部分がありました。 私は都市計画を主専攻とする学生で，アレクサンダーのパタンランゲージに大変感銘を受けていました。 都市計画分野では難解すぎることと実現可能性が低いことから，今では 一昔前の理論として若干風化しているように思えます。 しかし近年，システム工学の分野でかなり熱い注目を集めていることを最近知り，感動と喜びを覚えています。 このMLランゲージのように，システム分野で噛み砕かれたパタンランゲージの理論と実践が， 近い日に都市計画分野に逆輸入できる日が来るのを楽しみにしています。 あんま関係ないですかね？？ (25歳 大学院生)
結城：メール感謝します。 もし、ご興味があるなら、あなたご自身が現代の都市計画分野にパターンとパターンランゲージを適用してみる、 というのはいかがでしょう。どんな学問分野であっても、よい習慣、練られた解法というのが存在しますから、 それをパターンとして記述することは可能だと思います。 興味を持った人が自分でパターンを書くという態度は、 パターンのコミュニティでよく登場するテーマの1つです――これもパターン…。
◆ 『会社の名前を背負っていることを忘れないように』に書かれていることは、 質問する側の立場から見れば仰る通りなんですが、 逆に読む側への心構えとしては逆かなぁと思います。 メーリングリストでの発言というのは、 あくまでも個人としての発言でしょうから、 それを持って発言者の所属する組織の正式な回答と取られるのは大きく問題があるかと思います。 (25歳 会社員)
◆ すばらしい！ の一言です。こんなに簡潔で、気持ちよく読めるページは めったにお目にかかれません。 java-house.etl.go.jpのメーリングリストから知りましたが、なにか今日は得した気持ちになってしまいました。 このようなページを読まさせてもらい、ありがとうです。
◆ 一見言っていることは間違っていないようだが、 一つ一つが技術の人の言い訳に聞こえる。 人間味がない。こんなことは重要ではない。 なんともならないことを何とかしてあげるという互助が感じられない。 はっきり「馬鹿はメールするな」と言ったほうがずっとすっきりする。 回りくどい法律を呼んでいるようで不愉快。 そんなことは誰でも知っている。 知っていてやっているのに文句ばっかり。 (63歳 社長代行)
結城：ご意見ありがとうございます。 参加者に互助の気持ちがあったとしても、 質問に十分な情報が書かれていなくてはどうにも助けることができない、 という状況があることもご理解いただければ、と思います （そして、そういう状況は非常に多く起きているのです）。 メールを使ったコミュニケーションというのは歴史がまだ浅く、 現在、みんなが試行錯誤の中でよりよい方法を見つけ出そうとしている段階だと思っています。 ぜひ、あなたのお知恵もお貸しいただければ感謝です （メールアドレスが書かれていなかったのでWebページでお返事いたします）。
◆ 既に色んなところで紹介されてるけど、こういうのはもっと普及して欲しい。 読まない人にはプリントアウトして会社内で配るとか。 (森山和道さん 2001年11月27日の日記)
◆ 見事です。 MLではなく掲示板ですが、 いちいち説明せずに、 『事前に 「技術系メーリングリストで質問するときのパターン・ランゲージ」 を読め』 と言えば済むので、 助かります。 (44歳 会社員)
◆ メーリングリストに質問を投稿する際、他の参加者に 極力ご迷惑をおかけしないよう、質問の内容には 特に気を使っているつもりです。 ですが、しばしばうっかりして、 自分の環境や発生したエラーの詳細などの必要な情報を 書き忘れてしまう癖があります。 ですので、 「質問のためのテンプレート」をこうして公開してくださったことには、 非常に感謝しております。 P.S. 結城さんの 『Java言語で学ぶデザインパターン入門』は 我々のゼミでも使わせていただいております。 今度の マルチスレッド編も期待しています。 (22歳 大学生)
◆ 「著者・作者 ―― 書いた本人に尋ねましょう」に関連して、最近では 著者、訳者、もしくは出版社が正誤表を用意している場合がありますので、 そちらを先に探すほうがよいかもしれません。 まあ、細かいことですが。 (yomoyomoさん)
◆ こんにちは。 仕事でメールでの顧客サポートをしています。 メール文化が進んでいるようですが、まだまだ慣れない方も多く、 問合わせを受けても的を得た返信がなかなか出来ません。 こちらを拝見し、顧客への返信時、 「何を」「どのように」聞き返すのか、が判ったような気がします。 対面接客での対応書籍は溢れているのですが、 メールでの対応事例は少ないように思われ、大変参考になりました。 これからもリファインされるとの事で、大変楽しみにしております。 どうか頑張ってください。 (35歳 サポートセンター)
◆ 「技術系メーリングリストで質問するときのパターン・ランゲージ」 面白く読ませていただきました。 １点気になったところがありましたのでお知らせします。 「過去ログ ―― 投稿前に過去ログを読みましょう」の章に「その過去ログはWebを使って検索したり閲覧したりすることができます。」という記述があります。 この表現だと私には全てのメーリングリストはWebから過去ログを 検索したり閲覧したりできるという風に受け取れました。 メーリングリストへ過去ログ取得のコマンドを送信しなければ 過去ログを取得できないメーリングリストも多々あると思います。 そこで、以下のように表現を変えてみてはいかがでしょうか。 「その過去ログはWebを使って検索したり閲覧したりすることもできます。」 乱文しつれいします。 (プログラマ)
結城：ご指摘を踏まえて修正しました。ありがとうございます。
◆ 毒のない 真・技術系メーリングリスト FAQという感じがしてちょっと物足りないかなぁ、という気もしましたが、 毒のないほうが自称初心者の人には受け入れやすいんでしょうかね? それはそうと最近は自分の回線の太さを武器に巨大なファイルを添付して 送ってくる人が増えてる気がするので、そういう話も書いて頂けると嬉しいです。 添付の可／不可は ML の ローカルルールに含まれるかなって気もしてますが。 (29歳 会社員)
◆ とても分かりやすく適切で感心しました。 ただし質問のためのテンプレートは少々改行が多く長過ぎるような気がします。 掲示板と連動しているMLの場合、文章の分量を切り詰めないと表示されるの項目が少なくなってしまいますので不便です。内容はそのままでけっこうですから、 なるべくスペースを節約できる書き方をぜひご指導ください。 (32歳 映像制作)
◆ とても簡潔に、しかも押し付けがましくなく親切にまとめられていて、 非常に良いと思います。 自分も反省すべき点があったし、他の人にもぜひ読んで欲しいと思います。 MLに限らず、掲示板にも言えることだと思いますので、 プロバイダ全部に配って欲しいくらいです。 スレッドの件で1つ。 マイクロソフトの製品で、返信してもスレッド壊すのがありますよね。 どう思いますか？ 自分は早急に改善して欲しいと思っているのですが。 (31歳 会社員)
◆ このページは やじうまwatchで知りました(2001-11-27)． 身につまされる事も多いです． MLのオーナーをしているのですが， つい先日もMLの投稿でひと悶着あったところです． もしよろしかったらMLでページの紹介をしたいと思います． 問題がありましたらご連絡下さい． 貴重な情報をありがとうございます． (36歳 会社員)
◆ 大変有意義な文書だと思います。 メーリングリストへの投稿マナーを論じる際にはよく、 真・技術系メーリングリスト FAQが引き合いにだされますが、 あれを読んでとまどったり逆ギレしてしまうような人にはとても役に立つと思います。 同僚や後輩にもぜひ一読するよう勧めさせていただきたいと思います。 P.S. 『Java言語で学ぶデザインパターン入門』には大変お世話になっております。こちらもあわせて御礼申し上げます。 (26歳 会社員)
◆ はじめまして。時々雑誌の記事も読ませていただいております。 この文章は非常に参考になる点が多くありました。 過去ＭＬやＮＩＦＴＹ等で、失敗した経験もありますし、 若い人からの質問に、私が怒ってしまった経験もあります。 そういった経験から、最近はもっぱら、ＲＯＭばっかりになっております。 ネットワークが一般的に使われるようになって何年にもなりますが、 こういったネチケットのたぐいが広く知られるようになれば よりスムーズで有益なコミュニケーションが取れるようになると 思いました。 (39歳 会社員)
◆ このような情報が公開されていることに、インターネットのすばらしさを感じます。 私も心がけたいと思います。ありがとうございます。 (32歳 会社員)
◆ これまで、いろいろなメーリングリストで、 何度も繰り返されてきたやりとりが再現されていて、 ちょっと、面白かったです。 メーリングリストに限らず、メールで人に質問するときに気を付けるべき事が、わかりやすく書かれていると思います。 読みやすくて、ためになります。 知り合いにも、教えてあげようと思います。
◆ すばらしいテンプレートですね。このテンプレートの例示は極めて教育的だと考えました。発表していただいたこととても有益と存じます。 ところで、どのテンプレートや約束、ルールでもそうなのですが、技術的なことを質問するときに、「何の為にそれを行うのか？」という、基本設計や、 概要設計レベルの話題提供の必要性を訴えているものが、すごく少ないような気がします。この種の意識は、みなさんにとって有用ではないのかしらん、 と常々感じております。 質問者が運用レベル、基本設計レベルで、何をしたいのか はっきり示してあると、回答も、おのずと変わってくると 思うのですよね。 細かい技術レベルで応答を繰り返すよりも 「代案としてこういうのもありかな？」を 引き出せる質問のありかたも 検討すべき時期ではないかと思うのです。 特に、ＭＬの参加者の技術レベルが はなれていればいるほどですね。 (44歳 システム担当)
◆ 大変参考になりました。 人に何かを伝えるということは本当に大変です。 メーリングリストに限らず情報を人に伝える場合などに 参考にさせていただきたいと思います。 (31歳 会社員)
◆ こんにちは。C-Magazineを中学生のころからずっと愛読しております。 とあるところから、このページの存在を知ったのですがこれを読む人は すでに上記のことを心得ており、心得ていない人ほど読まないのでしょうね。 ですが啓蒙を続ける努力は必要でしょう。 これからもお体に気をつけてご活躍ください。 (22歳 SE&大学生)
◆ 技術系メーリングリストで質問するときのパターン・ランゲージ拝読しました。 自分自身の中でため息が洩れてしまいます。 『当たり前の事』 だけれど、自分自身では『できていないなぁ』と、思いました。 すみません。 と、共に、これからは、これを読んでもっと上手くMLでコミュニケーションが取りたいと思いました。 (28歳 デザイナー)
◆ いま会社で研修中の方に、胸をはって 紹介できるページを結城さんが作ってくれた！という感じで、 とてもうれしいです。ありがとうございます。 自分も自分なりに 「初心者を自称する人は嫌い。初学者になってほしい。」 というコラムを書いていました。いずれ反響があれば結城さんのような コンテンツになってたと思います。 (なみかわみさき)
◆ Style Sheet を切ってある環境だと非常に読みにくい!!! と思いました。
結城：暫定的に横線を入れて対処してみました。ご意見ありがとうございます。
◆ うーん、素晴らしい！！！ とある大学の研究室にも通っているのですが、 この文章をそこの学生に読ませたいと思います。 (27歳 Javaプログラマ)
◆ この文書は「メーリングリストで質問する」ことに焦点を当てていますが、 サポート窓口へ問い合わせたり、技術的なトラブルを自分で解決するときの心得としても同じように通用するものです。 一言で言えば、どういう操作をしたらどういう結果が出たが、 本来はどういう結果が出るべきだ、そのためにはどこをどう修正しなければならない、 ということを正確に記述することが必要となります。「正確に」というのは、まず自分が本当に正しく 把握できているかの確認と、相手に誤解をまねいたり、 あいまいだったりせずに伝えられるかの両面があります。 これは、わかっている人には当然なのですが、わかっていない人に向けて、 これほどわかりやすく解説している文書は見たことがありません。 このような有用な文書を公開してくださった結城浩さんに感謝いたします。 さっそく会社のメーリングリストでも是非読むよう案内を流しました。 (32歳 会社員)