提问的智慧（How To Ask Questions The Smart Way）

[zeruns]

原文：How To Ask Questions The Smart Way

翻訳：王刚<yafrank at 126 dot com>
日付：2013年10月26日
内容

目次

• 免責事項
• はじめに
• 質問する前に
• 質問するとき
  • フォーラムを慎重に選ぶ
  • 初心者向けフォーラムやIRCは通常最も速く応答する
  • ステップ2：プロジェクトのメーリングリストを使う
  • 意味のある明確な件名を使う
  • 返信しやすい質問にする
  • 明確で文法的・綴り的に正しい文章を書く
  • 読みやすく標準的なファイル形式で質問を送る
  • 問題を正確かつ具体的に記述する
  • 量より質
  • バグを見つけたと早まって宣言しない
  • 低姿勢でも自助努力の代わりにはならない
  • 予想ではなく症状を述べる
  • 時系列で症状を列挙する
  • プロセスではなく目標を述べる
  • 私的なメール返信を要求しない
  • 質問は明確に
  • コードに関する質問
  • 宿題のような質問は投稿しない
  • 無意味な要求は削除する
  • 「緊急」とマークしない、たとえ本当にそうでも
  • 礼儀は常に役立つ
  • 問題解決後に簡潔な追記をする
• 回答の読み方
  • 「マニュアルを読め（RTFM）」「検索しろ（STFW）」：完全に失敗したと悟る方法
  • まだわからない場合は……
  • 無礼に対処する
• 負け犬のように反応するな
• 質問のタブー
• 良い質問と悪い質問
• 回答が得られない場合
• より良い回答の仕方
• 関連リソース
• 謝辞

翻訳：インドネシア語、ベラルーシ語、ブラジルポルトガル語、簡体中国語、オランダ語、フランス語、ジョージア語、ドイツ語、ギリシャ語、ヘブライ語、日本語、ポーランド語、ポルトガル語、ルーマニア語、ロシア語、スペイン語、タイ語。本文を複製・ミラー・翻訳・引用したい場合は、私の複製規約を参照してください。

免責事項

多くのプロジェクトのサイトが「助けの得方」セクションで本文へリンクしていますが、それは構いません。ただし、そのリンクを生成したプロジェクトのウェブ管理者の場合は、リンクの近くに目立つように「私たちはこのプロジェクトのサポートを提供しません！」と明記してください。

この注意書きがないことで苦い思いをしてきました。私たちはしつこく付きまとわれることになるでしょう。彼らは「この文書を公開したのだから、世界中の技術問題を解決する責任がある」と思い込んでいます。

もし助けを求めて本文を読み、作者に直接助けを得られると思って去るのであれば、あなたはまさに「バカ」の一人です。私たちに質問しないでください。無視されます。私たちは、あなたのソフトウェアやハードウェアの問題を実際に理解している人から助けを得る方法を教えているだけです。99.9％の場合、私たちはその「人」ではありません。本文の作者があなたの問題の専門家であると非常に確信できる場合を除き、邪魔しないでください。そうすれば皆が少し幸せになれます。

はじめに

ハッカーの世界では、技術的な質問への回答は、質問の仕方と問題の難しさに大きく依存します。本文は、満足のいく回答を得るためにどのように質問すべきかを教えます。

オープンソースソフトウェアは広く使われており、通常、ハッカーよりも経験豊富な他のユーザーから回答を得られます。それは良いことで、彼らは初心者のありがちな欠点をより寛容に受け止めてくれます。しかし、私たちが推奨する方法を使い、これらの経験豊富なユーザーをハッカーのように扱うことで、最も効率的に回答を得られます。

まず最初に理解すべきことは、ハッカーは難しい問題や思考を促す良い質問が好きだということです。そうでなければ、本文を書いていません。もしあなたが面白い問題を提示してくれれば、私たちは感謝します。良い質問は刺激であり贈り物であり、私たちの認知を発展させ、気づかなかった問題を明らかにします。ハッカーの間で「良い質問！」は熱烈で誠実な賛辞です。

さらに、ハッカーは簡単な質問に対して敵意や傲慢さを示すという評判もあります。時折、私たちは初心者や愚かな人間に対して条件反射的に無礼に見えることもありますが、実際はそうではありません。

私たちが容赦なく敵視するのは、質問する前に考えず、自助努力をしない人間です。そのような人は時間の無底洞です。彼らはただ受け取るだけで与えることを知らず、時間を浪費します。その時間は、もっと面白い問題や答えに値する人のために使えるはずです。私たちはそのような人を「敗者（loser）」と呼びます（歴史的な理由により「lusers」と綴ることもあります）。

私たちは、多くの人が私たちが書いたソフトウェアを使いたいだけで、技術的な詳細を学びたいとは思っていないことを理解しています。ほとんどの人にとって、コンピュータは単なる道具であり、目的を達成するための手段です。彼らには生活があり、より重要なことがあります。私たちはそれを認め、誰もが私たちを魅了する技術的な問題に興味を持つことを期待しません。しかし、私たちの回答スタイルは、本当に興味を持ち、問題解決に積極的に参加したい人に合わせたものであり、それは変わらず、変わるべきでもありません。もしそれが変われば、私たちは自分たちが最も得意とすることにおいて鋭さを失うことになります。

私たち（ほとんど）はボランティアであり、忙しい生活の中から時間を割いて答えています。時には手に負えないこともあります。そのため、特に敗者と思われる質問を容赦なくフィルタリングし、勝者に時間を使えるようにしています。

もしこの態度が嫌味っぽく、施しを受ける者の立場であるか、傲慢に見えるなら、あなたの前提を見直してください。私たちはあなたに屈服することを要求していません。実際、もしあなたが適切な努力をすれば、私たちのほとんどは喜んで平等に対話し、私たちの文化を歓迎します。自助努力をしない人を助けることは、私たちにとって非効率です。わからないことは問題ありませんが、愚かに振る舞うことは許されません。

だから、技術的に優れている必要はありませんが、優れているように振る舞うことが必要です。機知、着想、観察力、問題解決への積極的な参加を示さなければなりません。もしあなたが他者と差をつけることができなければ、商業的なサポートを有料で購入することをお勧めします。ハッカーに無償で助けを求めるのではありません。

もし私たちに助けを求めることを決めたなら、敗者になりたくはないでしょう。実際、敗者と見なされたくもありません。迅速で効果的な回答を得る最良の方法は、質問者が賢く、自信があり、着想に富み、たまたま特定の問題で助けが必要なように見せることです。

（本文への指摘は [email protected] または [email protected] まで歓迎します。ただし、本文は一般的なネチケット指南を目指していません。技術フォーラムで有用な回答を引き出すことに特に関連しない提案は一般に拒否されます。）

質問する前に

メール、ニュースグループ、フォーラムで技術的な質問をする前に、以下を行ってください：

• 質問しようとしているフォーラムの過去の文書で答えを検索する
• インターネットで答えを検索する
• マニュアルを読んで答えを探す
• FAQを読んで答えを探す
• 自分で調査・実験して答えを探す
• 詳しい友人に尋ねて答えを探す
• プログラマーなら、ソースコードを読んで答えを探す

質問するときには、上記を行ったことをまず示してください。これは、あなたが寄生虫ではなく、他人の時間を無駄にしていないことを示すのに役立ちます。さらに、それから何を学んだかを述べるとよいでしょう。私たちは、答えから学ぼうとする人に答えるのが好きです。

Googleなどの検索エンジンを使って、遭遇したエラーメッセージを検索することで、問題を解決する文書やメーリングリストのスレッドが直接見つかることがよくあります。たとえ結果が得られなくても、メーリングリストやニュースグループで助けを求める際に「Googleで以下の語句を検索しましたが、有用なものは見つかりませんでした」と付け加えるのは良いことです。検索キーワードを質問や考えられる解決策と結びつけることで、同様の問題を持つ他の人にも役立ちます。

焦らないでください。複雑な問題が数秒のGoogle検索で解決することを期待しないでください。FAQを読んでください。専門家に質問する前に、ゆっくりと考えてください。私たちは、あなたがどれだけ読み、考えたかを質問から読み取れます。準備ができていれば、回答を得られる可能性が高くなります。最初の検索で結果が得られなかったからといって、すべての質問を一度に投げかけないでください。

真剣に考え、質問を準備してください。軽率な質問には軽率な回答しか得られないか、まったく得られません。質問する前に自分の問題を解決するために考え、努力したことを示せば示すほど、本当の助けを得られる可能性が高くなります。

誤った質問をしないでください。もし質問が誤った前提に基づいていると、ハッカーは「愚かな質問だ……」と思いながら、誤った前提のまま答え、あなたに「聞いたこと」ではなく「必要なこと」の答えを与えないでしょう。

あなたには回答を受ける資格はないと考えてください。毕竟、そのサービスに支払っていないのですから。もしあなたが内容のある、面白く、思考を促す質問──明らかにコミュニティに経験を貢献し、他人から知識を受け取るだけでない質問──を提示すれば、回答を「稼ぐ」ことができます。

一方で、あなたが問題解決に参加する能力と意欲があることを示すのは良い始まりです。「誰か方向を示してくれませんか？」「何が不足していますか？」「どのサイトを調べればよいですか？」は、通常「完全な手順を教えてください」よりも回答を得やすいです。なぜなら、方向さえ示されれば残りは自分でやるという姿勢を示せるからです。

質問するとき

フォーラムを慎重に選ぶ

次のことをすると、「敗者」と見なされるか、無視されるでしょう：

• フォーラムのテーマと無関係な質問を投稿する
• 高度な技術問題向けフォーラムに浅薄な質問を投稿する、またはその逆
• 多数のニュースグループに同時投稿する
• 面識もなく、あなたの問題を解決する義務もない個人にプライベートメールを送る

コミュニケーションのチャネルを無関係なもので汚さないように、ハッカーは場違いな質問を排除します。あなたもその対象になりたくないでしょう。

したがって、まず適切なフォーラムを見つけることが第一歩です。Googleなどの検索エンジンは友達です。遭遇しているソフトウェアやハードウェアの問題に最も関連するプロジェクトサイトを検索してください。そこには通常、FAQ、メーリングリスト、文書へのリンクがあります。努力（FAQの閲読を含む）しても答えが見つからない場合、それらのメーリングリストが最後の頼みの綱です。プロジェクトのサイトにバグ報告の手順やリンクがある場合は、確認してください。

知らない個人やフォーラムにメールを送るのはリスクが伴います。たとえば、内容の豊富なウェブページの作者が無料のコンサルタントになりたいと思っているとは限りません。あなたの質問が歓迎されるかどうか、楽観的に予測しすぎないでください。不確かであれば、別の場所に投稿するか、まったく投稿しないでください。

フォーラム、ニュースグループ、メーリングリストを選ぶ際には、名前だけを信用せず、FAQやライセンス文書を読み、あなたの質問がテーマに合っているか確認してください。投稿する前に、過去の投稿を読んで、その場の雰囲気を感じ取ってください。実際、投稿する前にニュースグループやメーリングリストの過去ログで質問に関連するキーワードを検索することは極めて良いアイデアです。答えが見つかるかもしれません。たとえ見つからなくても、より良い質問を整理するのに役立ちます。

機関銃のようにすべてのヘルプチャネルに一斉投稿しないでください。大声で叫ぶのと同じくらい不愉快です。一つずつ、丁寧に。

テーマを理解してください！典型的な間違いの一つは、クロスプラットフォームの可搬性を目指す言語、ライブラリ、ツールのフォーラムで、UnixやWindowsのOSプログラミングインターフェースに関する質問をすることです。なぜこれが大きな間違いなのか理解できない場合は、概念を理解するまで質問しないでください。

一般に、慎重に選んだ公開フォーラムで質問する方が、プライベートフォーラムで同じ質問をするよりも有用な回答を得やすいです。潜在的な回答者の数も多ければ、フォーラムの参加者も多く、ハッカーは多くの人を啓発するような質問に答えたがる傾向があります。

熟練したハッカーや人気ソフトウェアの作者は、不適切なメッセージの氾濫にさらされています。あなたの追加がラクダの背骨を折る最後の一本のわらになることもあります。人気ソフトウェアの作者が、プライベートメールに殺到するスパムに耐えられなくなり、サポートを中止してしまった例がすでに何度もあります。

初心者向けフォーラムやIRCは通常最も速く応答する

ローカルのユーザーグループや使用しているLinuxディストリビューションは、初心者が助けを得られるフォーラムやIRCチャネルを宣伝しているかもしれません（非英語圏では、初心者フォーラムはメールリストであることが多いです）。これらは質問を始めるのに良い場所です。特に、比較的簡単または一般的な問題だと感じている場合はそうです。宣伝されているIRCチャネルは質問を歓迎する公開された場所であり、通常リアルタイムで回答を得られます。

実際、問題のプログラムが特定のディストリビューションに由来する場合（これはよくあります）、まずそのディストリビューションのフォーラムやメーリングリストで質問し、次にプログラム自体のプロジェクトフォーラムやメーリングリストに質問してください（そうでないと、プロジェクトのハッカーは「私たちのコードを使え」とだけ返答するかもしれません）。

どのフォーラムに投稿する前にも、検索機能があるか確認してください。あれば、質問のキーワードで検索してみてください。役立つかもしれません。すでに包括的なウェブ検索を行っているはずですが、フォーラムも再検索してください。検索エンジンがフォーラムのすべての内容をインデックスしていないこともあります。

プロジェクトのユーザサポートは、フォーラムやIRCチャネルで提供される傾向があり、電子メールでのやり取りはプロジェクト開発者のために予約されています。したがって、プロジェクトに関連する助けを求めるなら、まずフォーラムやIRCで探してください。

ステップ2：プロジェクトのメーリングリストを使う

プロジェクトに開発者メーリングリストがある場合は、個々のメンバーではなくリストに質問してください。たとえ彼が最もよく答えられると確信していてもです。プロジェクトの文書やホームページを調べ、メーリングリストを見つけてそれを使ってください。この方法にはいくつかの良い理由があります：

• 個々の開発者に送った質問が（もし）十分に良ければ、プロジェクト全体にも利益をもたらします。逆に、自分の質問がプロジェクト全体にとって愚かだと思っても、それが個々の開発者を困らせる理由にはなりません。
• リストに質問することで、開発者の負担を分散できます。個々の開発者（特にプロジェクトリーダー）は、あなたの質問に答える時間がないほど忙しいかもしれません。
• ほとんどのメーリングリストはアーカイブされ、それらは検索エンジンにインデックスされます。リストに質問して回答を得れば、将来他の人がウェブ検索であなたの質問と回答を見つけ、再び質問する必要がなくなります。
• しばしば質問される問題がある場合、開発者はその情報を使って文書やソフトウェア自体を改善し、より明確にすることができます。私的に質問された場合、誰も最も一般的な問題の全体像を見ることができません。

プロジェクトに「ユーザー」と「開発者」（または「ハッカー」）の両方のメーリングリストやフォーラムがあり、コードをいじくっていないのであれば、「ユーザー」リストやフォーラムに質問してください。自分が「開発者」リストで歓迎されると思わないでください。彼らはあなたのノイズに悩まされるでしょう。

しかし、自分の質問が普通ではなく、「ユーザー」リストやフォーラムで数日間返信がない場合は、「開発者」リストやフォーラムを試してもよいでしょう。投稿する前に、少なくとも最近数日間の保存された投稿を静かに観察し、その場の雰囲気を理解することをお勧めします（実際、これはプライベートまたは半プライベートリストに参加する際の良い習慣です）。

プロジェクトのメーリングリストが見つからず、プロジェクトメンテナのメールアドレスしか見つからない場合は、とにかくメールを送ってください。その場合でも、メーリングリストが存在しないと仮定しないでください。メールの中で、適切なメーリングリストを見つけようとしたが見つからなかったことを述べ、自分のメールが他の人に転送されることに反対しないことを付け加えてください（多くの人は、秘密がない場合でも、プライベートメールは公開されるべきではないと考えています。転送を許可することで、相手に選択肢を与えます）。

意味のある明確な件名を使う

メーリングリスト、ニュースグループ、フォーラムでは、件名は50字以内で有資格の専門家の注意を引く黄金のチャンスです。「助けてください」などの愚痴でそのチャンスを無駄にしないでください（大文字の「助けて！！！！」は反射的に削除されます）。私たちをあなたの苦しみの深さで感動させようとするのではなく、その限られたスペースで超簡潔に問題を記述してください。

件名の良い慣習は「オブジェクト──異常」形式です。多くの技術サポート組織がこの方式を使っています。「オブジェクト」部分で問題の対象を特定し、「異常」部分で期待される動作との不一致を記述します。

愚か：

助けて！ノートPCのビデオが正常に動作しません！

賢明：

X.org 6.8.1でマウスカーソルが歪む、MV1005チップセット

より賢明：

MV1005チップセットを使うX.org 6.8.1でマウスカーソルが歪む

「オブジェクト──異常」形式で書くことは、問題を詳細に考えるのに役立ちます。何が影響を受けているのか？マウスカーソルのみ、それとも他のグラフィックスも？X.orgでのみ？それも6.8.1でのみ？特定のビデオチップセット？それもMV1005モデルのみ？ハッカーは一目で問題を理解できます。

件名が良ければ、次に同様の問題を抱える人が検索で直接答えを見つけ、再び質問する必要がなくなります。

返信で質問する場合は、件名を変更して質問していることを明確にしてください。「Re: テスト」や「Re: 新しいバグ」のような件名は注目を集めません。また、返信の中で新しいテーマにあまり関連しない引用は削除してください。

リストメッセージでは、返信ボタンをクリックして新しいスレッドを始めないでください。視聴者が制限されます。muttのようなメールリーダーは、スレッドでソートし、折りたたんで非表示にするため、そのような人はあなたのメッセージを決して見ません。

件名を変えるだけでは不十分です。muttや他のメールリーダーは、件名以外のヘッダもチェックしてスレッドを判別するため、新しいメールを送った方がよいでしょう。

フォーラムでは、メッセージが特定のスレッドに密接に結びついており、スレッド外では通常見えないため、返信で質問しても問題ありません。すべてのフォーラムが返信での件名変更を許可しているわけではありませんが、そうしてもほとんどの人は見ません。ただし、返信で質問すること自体が疑わしい場合があり、現在スレッドを見ている人にしか読まれません。スレッドの現在のアクティブな人にだけ質問したいのでなければ、新しいスレッドを立ち上げた方がよいでしょう。

返信しやすい質問にする

「～に返信してください」と書くと、回答を得られないことが多いです。もしメールクライアントで返信アドレスを設定するのに数秒もかけたくないなら、私たちもあなたの質問を考えるのに数秒もかけたくありません。もしメールクライアントがそれをサポートしていないなら、より良いものに変えてください。OSがそのようなメールクライアントをサポートしていない場合は、より良いOSに変えてください。

フォーラムで、電子メールで返信を要求することは、情報が機密であると確信している場合を除いて、完全に無礼です。フォーラムが「スレッドをウォッチ」「返信があったらメールで通知」などの機能をサポートしている場合は、それを使いましょう。

明確で文法的・綴り的に正しい文章を書く

経験から、不注意でいい加減な人は、考え方やプログラミングも同様であることが多いです（賭けてもいい）。そのような人に答えても利益はありません。私たちは時間を他に使いたいのです。

質問を明確に、良く表現することが極めて重要です。もしそれが面倒に思えるなら、私たちもあなたの質問を注意深く読むのが面倒になります。言葉を選ぶのに少し余分な努力を払ってください。堅苦しく、形式的である必要はありません。実際、ハッカー文化は、非公式な、スラングやユーモアを正確に使うことを高く評価します。ただし、正確でなければなりません。思考し、問題に注目している兆しがなければなりません。

綴り、句読点、大文字を正しく使い、「its」と「it’s」、「loose」と「lose」、「discrete」と「discreet」を混同しないでください。すべて大文字にしないでください。それは大声で叫んでいると見なされます（すべて小文字も読みにくいためよくありません。Alan Coxならともかく、あなたには無理です）。

一般的に、半文盲のばかのように書けば、無視されるでしょう。インスタントメッセンジャーの略語も使わないでください。「you」を「u」と略すと、2回のキーストロークを節約する半文盲のように見えます。さらに悪いことに、子供のような汚い文字で書けば、確実に無視されます（または、せいぜい非難や皮肉の嵐が降りかかるでしょう）。

非母語のフォーラムで質問する場合は、綴りや文法のミスに限定的な寛容が与えられますが、怠慢は許されません（はい、私たちは通常その違いを見分けられます）。また、返信者が使用する言語を知らない限り、英語で書いてください。忙しいハッカーは、自分が読めない言語で書かれたメッセージを削除することが一般的です。インターネットでは英語がリングワであり、英語で書くことで、読まれることなく削除される可能性を最小限に抑えられます。

英語を第二言語として書く場合は、潜在的な返信者に言語上の困難を知らせておくとよいでしょう。例えば：* 英語は母国語ではありません。綴りミスがあればご容赦ください。

• もし○○語を使う方がいらっしゃれば、メール／DMで連絡してください。翻訳を手伝っていただけるかもしれません。
• この技術用語自体には精通していますが、スラングや慣用的な言い回しはよく分かりません。
• すでに○○語と英語の両方で質問を投稿しています。どちらかで返信していただければ、喜んで翻訳します。

読みやすく標準的なファイル形式で質問を送信する

わざと読みにくくすると、大抵は無視されます。人は読みやすい質問を好むので：

• プレーンテキストを使い、HTML（HyperText Markup Language）は使わない（HTML をオフにするのは難しくない）
• MIME（Multipurpose Internet Mail Extensions）添付ファイルは、実体（ソースファイルやパッチなど）があれば問題ないが、メールクライアントが自動生成する雛形（本文の単なるコピーなど）だけは避ける
• 1 行の文を何度も折り返して送らない（返信時に部分引用が困難になる）。読者は 80 桁幅のターミナルで読むことを想定し、80 桁未満で折り返す
• しかし、ログファイルやセッション記録のように「固定幅そのまま」のデータは折り返さない。内容はそのまま貼り付け、返信者が同じものを見られるようにする
• 英語フォーラムでは、Quoted-Printable MIME エンコードでメッセージを送らない。非 ASCII 言語には必要かもしれないが、多くのメーラーは対応しておらず、=20 などが散在すると読みにくく、意味を損ねる
• マイクロソフト Word や Excel などの閉鎖的専用形式で文書を書いてはならない。多くのハッカーは「熱い豚ふんをドア前に置かれた」くらい嫌う。処理できてもやりたがらない
• Windows からメールを送る場合、Microsoft の「スマート引用符」をオフにする（「ツール」→「自動修正オプション」→「入力時自動書式」でチェックを外す）。ゴミ文字が混入する
• フォーラムでは、絵文字や HTML 機能（提供されていても）を乱用しない。絵文字 1～2 個なら許容されるが、カラフルな文字は無能だと思われる。過剰に使うとニヤニヤ少女に見え、有用な返信は得にくくなる
• GUI メールクライアント（Netscape Messenger、Outlook など）を使う場合、デフォルト設定が上記を満たさないことがある。送信フォルダのメッセージを「ソース表示」で確認し、余計なゴミがない純粋なテキストであることを確かめる

問題を正確に内容を持たせて記述する

• 問題の症状を慎重かつ明確に記述する
• 問題が発生した環境（マシン、OS、アプリケーション、関連項目すべて）を記述し、ベンダーのディストリビューションとバージョン（例：「Fedora Core 7」「Slackware 9.1」）を明記する
• 質問する前に調べたこととその理解を記述する
• 問題特定のために行った診断手順を記述する
• 最近行ったコンピュータ／ソフトウェア設定の変更を記述する
• 可能なら、管理可能な環境で問題を再現する手順を提供する
• ハッカーが尋ねそうなことを先読みし、答えを用意する

コードが怪しいと思う場合は、再現手順を提示することが特に重要である。そうすれば、有用で迅速な返信が得られる確率が飛躍的に上がる。

Simon Tatham は「How to Report Bugs Effectively」という素晴らしい文書を書いている。ぜひ一読されたい。

量より質、簡潔に

精炼で内容のある記述をすべきである。大量のコードやデータを羅列しても意味がない。巨大で複雑なテストケースがクラッシュする場合、できるだけ小さく削る努力をせよ。

理由は三つ。第一、問題を単純化しようとする姿勢を見せると返信を得やすい。第二、単純化すると「有用な」返信を得やすい。第三、削っているうちに自分で解決策や回避策を見つけることがある。

すぐに「バグだ」と叫ばない

ソフトウェアで問題に遭遇しても、非常に強い根拠がない限り、すぐに「バグだ」と宣言するな。ヒント：ソースパッチを提示できるか、前のバージョンで正しく動くことを回帰テストで示せない限り、十分に確信しているとは言えない。Web ページや文書についても同様である。

あなたの問題を経験していない他のユーザーが多数存在することを忘れるな。そうでなければ、文書を読んだり Web を検索したときに見つかっていたはずだ（文句を言う前にやったよね？）。つまり、ソフトウェアよりもあなたのほうが間違っている可能性が高い。

ソフトウェアを書いた人々は、それを完璧にしようと懸命に努力している。「バグだ」と主張すれば、彼らの能力を疑っていることになる。たとえ正しくても、不快に思う者が出るかもしれない。また、件名に「Bug！」と書くのも非常に幼稚である。

質問するときは、たとえ心の中では明確にバグを見つけたと確信していても、「自分が何か間違えている」のような書き方をすべきである。本当にバグであれば、返信でそれが明らかになる。そうすれば、メンテナが謝ることになり、失敗して謝るよりもはるかにましである。

卑屈になるのは自助努力の代わりにならない

無礼や傲慢な態度で答えを要求してはいけないが、逆に「私はつまらない新米の敗北者ですが……」のように卑屈になるのも困るし役に立たない。実際の問題が不明瞭だと、さらに不快になる。

低級な霊長類の方法で時間を無駄にするのではなく、背景と問題を可能な限り明確に記述せよ。卑屈になるよりもはるかに効果的である。

初心者用の別フォーラムがある場合、本当に初歩的な問題であればそこを使えばよい。それでも卑屈になる必要はない。

症状を述べて、推測は述べない

何が原因かを告げても無駄である（診断理論が素晴らしいなら、他人に助言を求めないはずだ）。したがって、問題の生の症状だけを伝え、解釈や推測は彼らに任せる。推測を述べる必要がある場合は、明確に「自分の推測であり、うまくいかなかった理由」を示せ。

愚か：

カーネルをコンパイルすると SIG11 エラーが続出します。マザボの配線が切れていると思うのですが、見つけるには？

賢明：

自作マシン（K6/233 CPU、FIC-PA2007 マザー[VIApollo VP2 チップセット]、Corsair PC133 SDRAM 256 MB）で、起動後 20 分程度でカーネルコンパイル中に頻繁に SIG11 エラーが出ます。再起動では時計がリセットされませんが、夜通し電源を切るとリセットされます。メモリはすべて交換済みです。関連するコンパイルログを添付します。

多くの人がこの点を理解できないので、言い換えると「すべての診断専門家はミズーリ州出身だ」。ミズーリ州の公式モットーは「Show Me」である。診断者にとって、これは懐疑ではなく、あなたが見た生の証拠をそのまま見せるという有用な要求である。推測や要約ではなく、事実を示せ。

問題の症状を時系列で列挙せよ

クラッシュ直前の出来事に、解決のための最も効果的な手がかりが含まれることが多い。したがって、クラッシュ前に自分、コンピュータ、ソフトウェアが何をしていたかを正確に記録せよ。コマンドラインの場合、スクリプトツールで生成されたセッションログを引用し、関連する 20 行程度を示すと非常に役立つ。

クラッシュするプログラムに診断オプション（-v など）がある場合は、それを使って記録に追加情報を含めよ。「多ければよい」わけではない。適切なレベルで、有用な情報を提供せよ。

記録が長い（4 段落超）場合は、最初に問題の概要を述べ、後で時系列で詳細を示すとよい。読む人が何に注意すべきかが分かる。

目標を述べよ、手順ではなく

「～をしたい」（バグ報告ではなく）の場合、最初に目標を述べ、次に問題が発生した特定の手順を示せ。

しばしば、助けを求める人は高次の目標を持ち、自分が選んだ特定の手段で行き詰まり、どうすればその手段を通れるかを聞くが、その手段自体が間違っていることに気づいていない。

愚か：

グラフィックソフトのカラーピッカーで 16 進 RGB 値を取得するには？

賢明：

画像のパレットを自分の指定した色に置き換えたい。今のところパレットスロットを一つずつ編集する方法しか知らないが、グラフィックソフトのカラーピッカーで 16 進 RGB 値を取得できない。

後者なら、より適切なツールを使うという回答が可能になる。

私的なメール返信を要求するな

ハッカーは問題解決プロセスを公開・透明にすべきだと考える。途中でより優れた人が不完全や不適切な点を指摘できるように、最初の返信も修正されるべきである。同時に、返信者も自分の能力・知識を他者に示すことで報酬を得る。

私的な返信を要求すると、このプロセスと報酬が失われる。そうしないで、返信者に私的にするかを決めさせよ。もし私的に返信した場合、質問があまりに稚拙または浅薄で他者に意味がないと考えたからである。

例外は、質問が大量の同様の返信を引き起こすと確信できる場合。「メールで連絡してください、まとめて投稿します」は魔法の一文である。メーリングリストやニュースグループを同様の返信の洪水から救うのは礼儀であるが、約束は守れ。

明確に質問せよ

漠然とした質問は、底なしの時間の穴と見なされる。有用な回答を出せる人は最も忙しい人々であり、底なしの時間の穴に敏感で、それを嫌う。

返信者に何をしてほしいか（方向を示す、コードを送る、パッチをチェックするなど）を明確にすれば、有用な回答を得やすい。彼らが集中でき、助けるために必要な時間・労力に上限を設定できるからである。

専門家の世界は「知識は豊富だが応答時間は希少」である。要求する時間が少なければ、本当に詳しくて忙しい専門家から回答を得られる可能性が高まる。

質問を限定して、専門家が最小の時間で答えられるようにせよ。例えば「X の良い解説はどこにありますか？」は「X を説明してください」より賢明である。コードが動かない場合、どこが悪いかを見てもらうほうが、直してもらうより賢明である。

コードに関する質問

何百行もコードを貼って「動きません」とだけ書いても無視される。数十行で「7 行目以降、 が表示されるはずが が出ます」と示せ。非常に高い確率で返信を得られる方法。

コードの問題を最も正確に説明するには、問題を示す最小のテストケースを提示することです。最小のテストケースとは何か？　それは、予期しない動作を再現するのに必要なだけのコードで構成された問題の提示です。最小のテストケースをどう作るか？　もしどの行や部分が問題を引き起こすか分かっているなら、それをコピーし、サンプルが完結するための最小限の周辺コードを付け足す（「最小限」とは、ソースがコンパイラ・インタプリタあるいはそれを処理するプログラムにちょうど受け入れられること）。問題を特定の部分に絞れない場合はソースをコピーし、問題と無関係なコードを削除していく。提示できる最小テストケースは小さいほどよい（「量より質」参照）。

非常に小さい最小テストケースを作れないこともあるが、努力すること自体が問題を解決する助けになる。たとえ解決できなくても、ハッカーは努力を見て協力的になる。

コードレビューを頼みたいだけなら、最初に明言し、特に注目してほしい部分とその理由を必ず示す。

宿題っぽい問題は投稿するな

ハッカーは「宿題」系の質問を見抜く。私たちは自分の宿題は自分で済ませてきた。ヒントを求めるならともかく、完全な解答を求めるのはダメ。

宿題っぽいと思えど解決できない場合は、ユーザグループやフォーラム、プロジェクトの「ユーザ」メーリングリストで質問してみよ。ハッカーは見抜くが、古参がヒントをくれるかもしれない。

無意味な要求を削除せよ

「誰か助けて？」「答えは？」など、意味のない文末フレーズを付けるのをやめよ。問題記述が不十分なら余計なだけであり、ハッカーは煩わしいと思って「はい、助けられます」「いいえ、助けはありません」と論理的だが退ける返答をする。

「はい／いいえ」質問は、そういう回答が欲しい場合以外避けること。

たとえ緊急でも「至急」タグを付けるな

これはあなたの問題であって私たちのではない。「至急」と銘打つと大抵逆効果：ほとんどのハッカーは無礼と利己的だと見なして削除する。スパムフィルタにも引っかかり、見えないまま終わることも。

国際宇宙ステーションから投稿するくらいの有名でハッカーを沸かす場面なら例外かもしれないが、期限があるなら丁寧に触れるに留めよ。ただし「緊急：かわいいアザラシを救え！」などと書けば、たとえアザラシが重要でもハッカーは避ける。

礼儀は常に有用

「お願いします」「ご協力ありがとうございます」と言い、無償で時間を割いてくれることに感謝を示す。

正直なところ、文法の正確さ・明瞭さ・正確性・内容の充実・独自フォーマットの回避より重要ではないが、技術的に明確なバグ報告よりも礼儀だけの曖昧な報告を好むハッカーは少ない。技術的に問題を整理した上で丁寧にすれば、有用な返信の確率は上がる。

（「事前に感謝」は一部の古参ハッカーに「事後の感謝を省略するつもりか」と受け取られるため、使うなら事後にもう一度感謝するか、別の言い回しを使うとよい。）

解決したら簡潔に追記せよ

解決後、協力してくれた全員に問題がどう解決したかを簡潔に報告し、もう一度感謝する。注目を集めたメーリングリストならそこに追記。

最適なのは元スレに「解決済み」「fixed」などと付けて返信すること。スレ一覧で「問題X」「問題X-解決済み」と並べば、興味ない人は時間を節約できる。

追記は長く不要。「ネットケーブルが断線でした！　みなさんありがとう」で十分。高深でなければ短く親切なサマリーでよい。解決手段を示し、迂回路の詳細は最後に短く。

深い問題ならデバッグ履歴の要約を載せ、最終状態と解決策を示した後、避けられた迂回路を書く。探偵小説にするな。協力者の名前を挙げれば友達が増える。

この種の追帖は、同じ問題を検索する人の役に立ち、協力者にも達成感を与える。問題がどう終わったか分からないのはハッカーにとっても苛立ちである。「かゆいところに手が届いた」という信頼は次回の質問に必ず役立つ。

次に同じ問題を引き起こさないため、FAQやドキュメントのパッチを検討し、維持者に送ること。

このようなフォローアップは、伝統的な礼儀よりもハッカー社会では重く、貴重な評判を築く方法である。

回答の読み方

「マニュアルを読め（RTFM）」「検索しろ（STFW）」：完全にやらかしたサイン

RTFM と言われたら、本当にマニュアルを読むべきだ。STFW と言われたら、ググれということだ（穏やかに言えば「Google is your friend!」）。

フォーラムでは過去ログを検索せよ、と言われることもある。が、質問前に自分で検索すべきである。

検索を促す人は、すでに答えを見つけており、自分で調べた方が学べると考えている。無視されないだけで感謝すべきだ。

まだ分からないとき

回答が理解できないときは、すぐに「説明して」と要求せず、自分でマニュアルやFAQ、Web、友人などで調べる。それでも必要なら、自分がどこまで理解したかを示せ。

「インプット項目をクリアしろ」と言われたとき：

• 悪い追記：「インプット項目って何？」
• 良い追記：「マニュアルを読みましたが、-z/-p スイッチでしか言及がなくクリア方法が書かれていません。どちらのことでしょうか？」

無礼に対処する

ハッカーに見える無礼は、多くは故意ではなく、問題解決を優先する率直なスタイルである。侮辱を感じたら冷静に。本当に過剰なら先輩が注意する。それでも怒る場合、あなたが悪者と見なされ情報を得にくくなる。

本物の無礼には容赦ない反論もアリだが、根拠が必要。新手や部外者は無闇に乗るべきではない。

（軽度の自閉症・アスペルガーが多いという説もある。そうでなくても「正常な」社交回路が欠落している。気にしないでほしい。）

負け犬の反応をするな

やらかして公開処刑されることもある。その後にしてはいけないこと：

• 悲嘆にくれる
• 謝罪を要求
• 法的脅迫
• 雇主にクレーム
• 蓋を閉め忘れる

すべきこと：素直に受け入れる。公開批判はコミュニティの健全な維持に必要だ。私的にすべきだと主張しても無駄。個攻撃と叫んでも始まらない。

別のフォーラムでは「手助けできないなら黙れ」という高圧的な礼儀ルールがあり、結果として有益な参加者が離れ、無意味な世間話だけが残る。

「友愛」か「有用」か、どちらかを選べ。

ハッカーが「やめろ」と言うのは、あなたとコミュニティを気遣ってのこと。感謝できなくても、尊厳を保ち、繊細な新人だから特別扱いを求めない。

やらかしてないのに攻撃されることもある。そんなときに文句を言うと本当にやらかす。

挑発者は自称専家の無能者か、あなたが本当にやらかすかテストしているだけだ。読者は無視するか、自分なりに対処する。あなたは介入する必要はない。

質問タブー

典型的な愚かな質問と、ハッカーの内心：

• どこにXがある？
• XでYをどうやる？
• シェルプロンプトをどう設定？
• Bass-o-maticでAcmeCorp文書をTeXに変換できる？
• プログラム／設定／SQLが動かない
• Windowsマシンが壊れた
• システムツールXのせいだ
• Linuxのインストールに失敗
• ルートパスワードを奪うには？

---

Q: どこにXがある？
A: ググレ。Googleの使い方を知らないのか？

Q: XでYをやりたい
A: Yを解決したいなら、的外れな方法を提示するな。XもYも分かってない上に視野狭窄だ。

Q: シェルプロンプトの設定は？
A: 質問できる頭があるなら、RTFMして自分で調べろ。

Q: Bass-o-maticで変換できる？
A: 試せ。試せば答えも時間の無駄もない。

Q: 動かない
A: 質問になってない。補足ある？　がんばれ。関係ない。

Q: Windowsが壊れた
A: Windowsを削除してLinuxでも入れろ。
※ただしSambaなどWindows連携ソフトなら可。Windowsが原因と言われても文句を言うな。

Q: システムツールXのバグ
A: 数万人が使っているものをあなたが初めて見つけた可能性より、根拠のない主張の方が圧倒的に高い。非凡な主張には非凡な証拠が必要。

Q: Linuxのインストールに失敗
A: 直接操作しないと分からない。地元のLUGを頼れ。
※特定のディストロならそのフォーラムで、詳細を書け。事前に「linux」とハードウェア名で検索せよ。

Q: パスワード奪取には？
A: そんなことしたい時点で下劣。教えを請う時点でアホ。

良い質問と悪い質問

悪い例：
Foonly Flurbamatic についてどこに情報がある？

良い例：
「Foonly Flurbamatic 2600」でググったが有益な情報が見つからない。誰か情報源を知らない？

悪い例：
ソースがコンパイルできない、バグってる！

良い例：
Linux 6.2 で某プロジェクトのソースがコンパイルできない。FAQも読んだ。エラーログは以下の通り。何が悪い？

悪い例：
マザーが怪しい、助けて！

良い例：
S2464でX,Y,Zを試し、だめならA,B,Cを試した。Cの時の奇妙な症状は…。Athlon MPでこれが起きる原因は？　他に試すべきことは？

「答えをくれ」ではなく「次に何を試せば手がかりが得られるか」を聞くことが重要。

この最後の例は2001年8月のLinuxカーネルメーリングリストで実際に私（Eric）が投稿したものであり、正しい聞き方をした結果、解決に至った。名前ではなく正しい質問の仕方が答えを得た理由である。

回答が得られないとき

回答がない≠無視。単に誰も知らないだけ。同じ質問を繰り返すのはスパムとみなされる。時差や質問の整理の悪さもある。

他に初心者向けリソースやローカルユーザグループ、商用サポートもある。有償でもソフトが無料ならトータルで安い。閉源ソフトのサポートより安くて質が高いことも多い。

より良い回答をするには

• 親切に。プレッシャーで無礼に見えても実際はそうでない。
• 初犯には私的に。公の恥辱は不要。
• 分からないときは「分からない」と言え。間違った権威ある回答は害になる。
• 助けられないなら邪魔するな。ジョークでシステムを破壊されてはたまらない。
• 探索的反問で詳細を引き出せ。悪い質問を良い質問に変えられれば双方が学べる。
• 「RTFM」と言うなら、マニュアルや検索キーワードを示せ。
• 答えるなら良い答えを。つまらない回避策より良いツールや再構成を。
• 本当の問題に答えよ。「X,Y,Z,A,B,Cを試したがだめ」に対して「Xを試せ」は無意味。
• コミュニティが学べるように。FAQやドキュメントを改善するパッチを送れ。
• 調べて答えたなら、テクニックを示せ。「魚を与えるより釣り方を教えよ」。### 関連リソース

個人コンピュータ、Unix、インターネットの仕組みに関する基礎知識が必要な場合は、Unix およびインターネットの仕組みの基本原理を参照してください。

ソフトウェアやパッチを公開する際は、ソフトウェアリリースの実践に従ってみてください。

謝辞

エヴリン・ミッチェル（Evelyn Mitchell）は愚かな質問の例をいくつか提供し、「質問への回答を改善する方法」というセクションの執筆をインスピレーションしてくれました。ミハイル・ラメンディク（Mikhail Ramendik）は特に貴重な提案と改善を寄稿してくれました。