技術系メーリングリストで質問するときのパターン・ランゲージ

目次

• はじめに
• メーリングリスト —— サポートセンターではなく互助会です
• 表題 —— あいさつではなく用件を書きましょう
• 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう
• 書き出し —— 最初に問題の要旨を書きましょう
• 肩書き —— 会社の名前を背負っていることを忘れないように
• 実行手順 —— 手順は箇条書きで書きましょう
• 結果の予想 —— 期待した結果を書きましょう
• 実際の結果 —— 実際に起きたことを書きましょう
• ステップ明記 —— どこからうまく行かなくなったかを書きましょう
• 実際の値 —— 条件を具体的に書きましょう
• エラーメッセージ —— 必ずコピー＆ペーストしましょう
• 判断理由 —— そのように考えた理由を書きましょう
• 文献の引用 —— 読者の手間を省くように書きましょう
• ソース —— 関連する部分を抽出して示しましょう
• スレッド —— 関連する話題なら「返信」しましょう
• メールの引用 —— 適切な量だけ引用しましょう
• 仕様書 —— 仕様書にあたって確認しましょう
• 環境 —— 自分の環境をはっきり書きましょう
• 過去ログ —— 投稿前に過去ログを読みましょう
• 検索エンジン —— 投稿前に、自分で検索してみましょう
• 著者・作者 —— 書いた本人に尋ねましょう
• まとめのメール —— 投稿した本人が要点を簡潔にまとめましょう
• ローカルルール —— 郷に入れば郷に従え
• 付録：質問のためのテンプレート(public domain)
  • テンプレートを利用した質問の例
• さらに書くべき項目
• 顧客のネットワーク情報
• 再配布条件(GPL)
• リンク
• 読者からのフィードバック
• 更新履歴

---

はじめに

こんにちは、結城浩です。

このページは技術系メーリングリストで質問するときのコツをご紹介します。 ここに書かれていることは「心がけ」「ヒント」「アドバイス」に過ぎません。 法律のようにこれを守る必要はありませんし、 他の人がこれを守っていないからといって怒るべきではありません。

ローカルルールを持っているメーリングリストもありますので、 ここで書かれているパターンを機械的に適用しないでください。

ページ末の 「付録」には質問のためのテンプレートも用意しましたので、 参考にしてください。

言うまでもありませんが、 このページは自由にリンクしてくださって構いませんし、 メーリングリストなどで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(エキサイト)、 FreshEye(フレッシュアイ)、などなど無数の検索エンジンが存在します。 あなたの問題に関するキーワードを放り込んで、まずは下調べをしてみましょう。

　　

メーリングリストの 過去ログやFAQを検索するのもお忘れなく。 それから、場合によっては、 参考書の著者やWebの作者本人に聞くのも有効です。 …

---

---

著者・作者 —— 書いた本人に尋ねましょう

… 参考書を読んでるんだけれど、どうもおかしいから、他の人の意見を聞いてみよう。 Webページを読んでやってみたんだけれど、うまくいかないから、他の人の意見を聞いてみよう。

　　

問題： メーリングリストで議論が巻き起こったけれど、結局結論は出なかった。 いろんな意見で何を信用すればいいのでしょうか。

メーリングリストで意見を聞いたり、質問の回答をもらったりするのは有益です。 自分の想像のつかないような情報を得たりします。

けれども、 参考書の疑問や、Webページの問題に、 決定的な解答が得られる保証は何もありません。 メーリングリストで意見を言っている人は、みなそれぞれの意見を言っているだけですから。

だから、こうしましょう：

解法： 参考書の疑問は著者本人に尋ねましょう。 Webページの問題点はそのページの作者に尋ねましょう。 もしかすると、それは単なる誤植かもしれません。 ただし、 著者本人に尋ねたとしても返事が得られるという保証はありませんし、 返事が返ってこなくても怒ってはいけません。

　　

尋ねた結果は まとめのメールとして再度メーリングリストに流すといいですね。 …

---

---

まとめのメール —— 投稿した本人が要点を簡潔にまとめましょう

… やったー。動いたぞー。問題解決だー。よかったよかったー。やっぱりメーリングリストは便利だー。 ありがとー。感謝しますー。

　　

問題： 問題が解決したら、お礼のメールを出す必要があるのかな。どう書けばいいのかな。

情報を送ってくれた人に「お礼」するのは大事ですけれど、 ただ「ありがとうございます、解決しました」だけでは不十分です。 問題と解決のあいだにはさまざまな情報の流れがあったはずです。 うまくいったアドバイス、機能しなかった手順、紹介されたWebページ…。

情報はメールで流れますから、何がどうなって、 結局どうなったのかを後からたどるのは難しいものです。 またそれをすべてメーリングリスト管理者に負わせるのはやりすぎです。

だから、こうしましょう：

解法： 問題の解決で恩恵を受けた人が、問題・解決・参照リンクなどを簡潔に記述し、 まとめのメールとしてメーリングリストに投稿しましょう。 情報を送ってくれた人たちへのお礼も大事ですけれど、 もっと大事なのはメーリングリストという「場」を支えている人々への情報のフィードバックです。 そうすれば同じようなトラブルが起きたときの助けとなります。 そしてまとめのメールを流すことによって、 あなたは、メーリングリストから恩恵を受ける(take)立場から、貢献する(give)立場に変わるのです。 ギブ・アンド・テイク(give & take)、これがコミュニティを支えます。

　　

もちろん、まとめのメールは スレッドを切らないように返信で投稿します。 また、「○○のエラー(まとめ)」「△△問題の解決手順」「○○に関する結論の要約」などのように 適切な表題をつけることもお忘れなく。 まとめのメールは、FAQのページを作るための重要なもとネタになります。 そして、ここから先は、メーリングリスト管理者のパターンランゲージへとつながっていくことでしょう。 …

---

---

ローカルルール —— 郷に入れば郷に従え

… この「技術系メーリングリストで質問するときのパターン・ランゲージ」はなかなか有効だな。 じゃあ、これにちゃんと従ってメールを投稿すれば完璧だな。

　　

問題： 「ここのメーリングリストでは○○禁止です」という注意を受けちゃった。 ちゃんとした投稿しているのになあ。

メーリングリスト(ML)にはいろいろあります。 小人数のML、大人数のML、初心者向けのML、専門家向けのML、 議論を中心にしたML、わいわいとおしゃべりを楽しむML、 商業活動絶対禁止のML、宣伝大歓迎のML…。

メーリングリストにはいろいろあり、 それぞれのルールや習慣があります。 「このメーリングリストでは○○禁止」のように明文化している場合もありますし、 明文化されていないこともあります。

多くの技術系メーリングリストでは、 次の行為は嫌がられますが、 メーリングリストによっては許可されている場合もあります。

• ファイルを添付すること
• HTMLメールを流すこと
• あからさまな営業行為や人材募集
• 話題と無関係なメールを流すこと
• 質問のマルチポスト（複数のメーリングリストに同じ質問を同時期に流すこと）

メーリングリストごとにそれぞれの文化や習慣があり、 そこに集まる人の人数や性格によっても、 喜ばれる行為や嫌われる行為は変化します。

だから、こうしましょう：

解法： そのメーリングリストのローカルルールを探しましょう。 そのメーリングリストの運営方針やローカルルールは、 メーリングリストのWebページなどに書いてあります。 もしもローカルルールが見つからなかったら、 過去ログを読んでみましょう。 そのメーリングリストはどんな雰囲気ですか。 どんなやりとりが行われていますか。 あなたの投稿したい内容に似た投稿はなされていますか。 この「技術系メーリングリストで質問するときのパターン・ランゲージ」は一般的なガイドにすぎません。 郷に入れば郷に従え。 あなたの参加しているメーリングリストの方針に従いましょう。

　　

過去ログを読むとメーリングリストの雰囲気をつかむことができます。 そもそも メーリングリストは互助会のようなものですから、一方的に質問するのではなく、 互いに情報交換する意識を持つといいですね。 …

---

---

付録：質問のためのテンプレート(public domain)

以下に、質問のためのテンプレートを例示します。 この部分はpublic domainにしますので、どうぞご自由にお使いください。 ただし、これを質問のたびに全部使うのはいささかくどいですので、 適宜修正して（不要な部分は削除、補うべき内容はより詳しく）お使いください。

【所属機関や自分の技能を表現する解説】の【氏名】です。

○○を実行すると、○○というエラーになる問題で困っています。
原因または解決策をご存知の方はいらっしゃいませんか。

私の行った手順は以下です。
(1)
(2)
(3)

すると、以下のような結果になりました。

【表示されたものをコピー＆ペーストする】

私は【予想結果】になると思いました。
なぜなら、【参考資料】には、
以下のように書かれているからです。

> 【適切な分量の引用】
> 【適切な分量の引用】
> 【適切な分量の引用】

原因を確かめるため、以下のようなテストを行ってみましたが、
問題の解決には至りませんでした。

(a) 入力を○○ではなく××にしてみた
→上記と同じ結果になった

(b) ソースプログラムの○○をやめて、××にした
→以下のようなコンパイルエラーになった

【エラーメッセージのコピー＆ペースト】

なお、私の環境は以下の通りです。
【マシン, メモリ量, 関連周辺機器, OS, 利用ソフト, バージョンなどを箇条書きに】

検索エンジンで○○、××、△△を検索しましたが、
◎◎に関するページばかりで、解決に役立つ情報は見つかりませんでした。
このメーリングリストの過去ログも調べましたが、
○○に関する話題は見つかりませんでした。

【個人を識別する適切な署名】

テンプレートを利用した質問の例

上記のテンプレートを利用した質問の例を示します。 これは1例にすぎません。 こう書かなければいけないわけでもありませんし、 こう書けば必ず回答がくる保証もありません。 あなたが投稿する場合には、 あなたの参加しているメーリングリストの 過去ログを読んで、みんなが親切に答えてくれた投稿メールを参考にするのもよい方法です。

To: Perlの技術ML
From: とむら <tomura@example.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@example.org

---

さらに書くべき項目

• あわてないで。送信ボタンを押す前に、もう一度だけ最初から最後まで読み返す習慣をつけましょうね。
• 「そもそも、やりたいことは何ですか？」
• 「HTMLメールは使わないでください」
• 「ファイルを添付するのはやめてください」
• 「あからさまな営業活動はやめてください」
• 「マルチポストはやめてください」
• 「入門書は何か読みましたか？」
• 送信前に読み返すこと。
• 感情的な反応をしないこと。技術的な面にのみ反応すること。
• 丁寧な文章を書くこと。必要以上に馴れ合わないこと。
• 必要以上になれなれしい言葉を使わないこと。
• 必要以上にかしこまった言葉を使わないこと。
• 相手には相手の都合があるということ。
• 好かれる人、嫌われる人。
• 多数のROMの存在を忘れないこと。
• 人のせいにしないこと。
• 他の人の投稿を観察すること。
• 1つのメールで1つの質問に限ること。
• 長い文書は避けること
• サブジェクトの付け方で、質問者も何が問題なのかを見極めることが出来る。
• サブジェクトを考える過程で自ら解決方法を見つけてしまうことも。
• 必要がなかったらサブジェクトを変えないということ
• 自己レス: 応答をうながすための--, 新情報の追加のための--, 自己解決の報告としての--

---

顧客のネットワーク情報

（以下は、ほそのひでともさんからの指摘を元にしたメモです。）

会社の仕事に関連した質問を投げるときには、 会社の名前を背負っていることを忘れないようにする必要があります。 特に顧客のネットワークに関する情報の取り扱いには注意しましょう。

表示された メッセージをコピー＆ペーストして投稿するときに、 うっかり顧客のドメイン名や、IPアドレスまでそのまま公開してしまうと、 顧客の情報が全世界に公開されてしまう危険性があるからです。

顧客のネットワークに関する情報を隠蔽する手段として、 「192.168.x.yのようなプライベートIPアドレス」に置き換えたり、 「example.co.jp等の例示用ドメイン名」を活用したりする方法があります。

---

再配布条件(GPL)

読者からのフィードバックを除いた、 この文書全体は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です。 何の制限もありません。 自由に使ってください。

---

リンク

• メールを書く心がけ
• メーリングリストビギナーズコラム
• How To Ask Questions The Smart Way (by Eric Raymond) (OZAWA -crouton- Sakuroさん、情報感謝)
• Outlook Express をお使いの方 or ML 初心者の方へ (堀田倫英さんのページ)
• ネット上で問い合わせる際のマナー

---

読者からのフィードバック

フィードバック詳細

---

更新履歴

• 2017年10月10日、レスポンシブデザインに修正。
• 2001年11月27日、GPLとする。
• 2001年11月26日、公開。
• 2001年7月5日、準備開始。