質問の知恵

賢い質問の仕方

本ガイドの英語版の著作権は Eric S. Raymond, Rick Moen に帰属します。

原文の URL:http://www.catb.org/~esr/faqs/smart-questions.html

宣言#

多くのプロジェクトがその使用支援 / 説明ページに本ガイドへのリンクを張っていますが、これは素晴らしいことです。私たちも皆さんにそうすることを奨励します。しかし、もしあなたがそのプロジェクトのウェブページを管理している人であれば、ハイパーリンクの近くに目立つ位置で次のことを明記してください：

本ガイドはこのプロジェクトの実際のサポートサービスを提供するものではありません！

私たちは、上記の声明がないことによる苦痛を深く理解しています。この声明がないために、私たちはしばしばいくつかの愚か者に悩まされます。これらの愚か者は、私たちがこのガイドを発表したからには、世界のすべての技術的問題を解決する責任があると考えています。

もしあなたが何らかの支援が必要でこのガイドを読んでいるのであれば、そして最終的にこのガイドの著者から直接の支援を得られなかったために去ることになったのなら、あなたは私たちが言うところの愚か者の一人です。私たちに質問しないでください。私たちはあなたを無視するだけです。このガイドでは、あなたが直面しているソフトウェアやハードウェアの問題を理解している本物の専門家から支援を得る方法を教えていますが、99% のケースではそれは私たちではありません。このガイドの著者の一人があなたの直面している問題の専門家であると確信しない限り、私たちを煩わせないでください。そうすれば、皆が少し幸せになります。

はじめに#

ハッカーの世界では、技術的な問題を投げかけたときに、最終的に有用な回答を得られるかどうかは、あなたが質問し、追求する方法に大きく依存します。このガイドでは、満足のいく答えを得るための正しい質問の仕方を教えます。

ハッカーだけでなく、オープンソース（Open Source）ソフトウェアが非常に普及している今、他の経験豊富なユーザーからも良い答えを得られることが多く、これは良いことです。ユーザーはハッカーに比べて、新人がよく直面する問題に対してより寛容であることが多いです。しかし、経験豊富なユーザーをハッカーと見なし、このガイドの方法で彼らとコミュニケーションを取ることも、彼らから満足のいく回答を得るための最も効果的な方法です。

まず、ハッカーは挑戦的な問題や私たちの思考を刺激する良い問題を好むことを理解する必要があります。もし私たちがそうでなければ、あなたが質問したい相手にはならないでしょう。私たちにとって、繰り返し考えさせられる良い質問をしてくれたなら、私たちはあなたに感謝するでしょう。良い質問は刺激であり、贈り物です。良い質問は私たちの理解を深め、通常は私たちが以前に気づかなかったり考えなかった問題を明らかにします。ハッカーにとって、「良い質問！」は心からの称賛です。

とはいえ、ハッカーは単純な問題に対して軽蔑や傲慢さを持つ悪名を持っており、これが時には私たちが新人や無知な人々に対して敵対的に見えることがありますが、実際はそうではありません。

私たちは、考えようとせず、質問する前に自分がすべきことをしない人々に対して軽蔑を抱いていることを隠しません。そういう人々は時間の浪費者です - 彼らはただ受け取ることを望み、決して与えようとせず、私たちがより興味深い問題やより価値のある人々に使える時間を消耗させます。私たちはこうした人々を ルーザー（lusers） と呼んでいます。

私たちは、多くの人々が私たちが書いたソフトウェアを使用したいだけであり、技術的な詳細を学ぶことに興味がないことを理解しています。ほとんどの人にとって、コンピュータは単なるツールであり、目的を達成する手段に過ぎません。彼らには自分の生活があり、もっと重要なことをしなければなりません。私たちはこの点を理解しており、すべての人が私たちを魅了する技術的な問題に興味を持つことを期待していません。それでも、私たちの質問への回答スタイルは、実際にそれに興味を持ち、問題解決に積極的に参加する意欲のある人々に向けられたものであり、これは変わることはなく、変わるべきではありません。これが変わると、私たちは自分たちが最も得意とすることの効率を下げることになります。

私たちは（大部分は）自発的に、忙しい生活の中から時間を割いて疑問に答え、しばしば質問の洪水に圧倒されています。したがって、私たちは無情にいくつかのトピックをフィルタリングし、特にルーザーのように見える人々を排除して、より効率的に時間を使ってウィナー（winner）の質問に答えます。

もし私たちの態度が嫌いで、傲慢すぎると感じるなら、少し考えてみてください。私たちはあなたに屈服するよう求めているわけではありません - 実際、私たちのほとんどは、あなたが基本的な要求を満たすために少し努力さえすれば、平等にコミュニケーションを取ることを非常に喜んでいます。しかし、自分を助けようとしない人々を助けることは非効率的です。無知は問題ありませんが、愚かであるふりをするのは許されません。

したがって、あなたは技術的に非常に熟練している必要はありませんが、私たちの注意を引くためには、あなたが熟練するための特性を示さなければなりません - 機敏さ、考えを持つこと、観察力、問題解決に積極的に参加する意欲です。もしあなたがこれらの特性を示せないのであれば、商業会社にお金を払って技術サポート契約を結ぶことをお勧めします。ハッカー個人に無償で助けを求めるのではなく。

もしあなたが私たちに助けを求めることを決めたのなら、もちろんあなたはルーザーとして見られたくないし、ルーザーの一員になりたくないでしょう。すぐに迅速かつ効果的な回答を得る最良の方法は、ウィナーのように質問することです - 賢く、自信を持ち、問題解決の考えを持ちながら、特定の問題に対して少し助けを得る必要があるだけです。

（このガイドに対する改善提案を歓迎します。あなたの提案を [email protected] または [email protected] にメールしてください。ただし、この記事はネットエチケットの一般的なガイドラインではなく、通常、技術フォーラムで有用な回答を得るのに役立たない提案は拒否されます。）

質問する前に#

電子メール、ニュースグループ、またはチャットルームで技術的な質問をする準備をする前に、次のことを行ってください：

質問するフォーラムの古い投稿を検索して答えを探してみてください。
インターネットで検索して答えを見つけてみてください。
マニュアルを読んで答えを見つけてみてください。
FAQ（よくある質問）を読んで答えを見つけてみてください。
自分で確認したり実験したりして答えを見つけてみてください。
身近な強者の友人に聞いて答えを見つけてみてください。
プログラマーであれば、ソースコードを読んで答えを見つけてみてください。

質問をする際には、まず上記の努力をしたことを示してください。これは、あなたが労力を惜しまず、他人の時間を無駄にしない質問者であることを示すのに役立ちます。もしあなたが上記の努力の過程で学んだことを一緒に表現できれば、さらに良いでしょう。私たちは、答えから学ぼうとする姿勢を示す人々の質問に答えることをより喜びます。

特定の戦略を活用して、遭遇したさまざまなエラーメッセージを Google で検索することから始めてみてください（Google フォーラムやウェブを検索することも含めて）。そうすれば、問題を解決するためのドキュメントやメールリストの手がかりを直接見つけることができる可能性が高いです。結果が得られなかった場合でも、メールリストやニュースグループで助けを求める際に「私は Google で次のフレーズを検索しましたが、有用な情報は見つかりませんでした」と付け加えるのも良いことです。これは、検索エンジンがどのように役立たなかったかを示すだけでなく、同様の問題に直面している他の人々が検索エンジンを通じてあなたの質問に導かれるのを助けます。

焦らず、複雑な問題を数秒の Google 検索で解決できるとは期待しないでください。専門家に助けを求める前に、FAQ を再度読み、リラックスして、問題について考える時間を取ってください。私たちを信じてください、彼らはあなたの質問からあなたがどれだけ読んで考えたかを見抜くことができます。もしあなたが準備万端であれば、答えを得る可能性が高くなります。最初の検索で答えが見つからなかったからといって、すべての質問を一度に投げかけないでください（または、見つかった答えが多すぎるからといって）。

質問を準備し、注意深く考え直してください。なぜなら、軽率な質問は軽率な回答しか得られないか、まったく回答が得られないからです。あなたが助けを求める前に、問題解決のためにどれだけ努力したかを示すことができればできるほど、実質的な助けを得る可能性が高くなります。

間違った質問をしないように注意してください。あなたの質問が誤った仮定に基づいている場合、一般的なハッカー（J. Random Hacker）は「愚かな質問…」と思いながら、無意味な字面の説明であなたに答えるでしょう。あなたが求める答えではなく、質問の回答から教訓を得ることを期待しているのです。

決して自分が資格があると思わないでください。あなたにはその資格はありません；あなたにはありません。結局のところ、あなたはこのサービスに対して何の報酬も支払っていないのです。あなたは答えを得るために努力しなければならず、意味のある、興味深い、思考を刺激する質問をする必要があります - コミュニティの経験に貢献できる潜在能力を持つ質問であり、他人から知識を受け取るだけの受動的な質問ではありません。

一方で、答えを見つける過程で何かをする意欲を示すことは非常に良いスタートです。誰かヒントをくれますか？、この例で何が欠けていますか？、どこをチェックすべきですか？は、必要なプロセスを正確に貼り付けてくださいよりも回答を得やすいです。なぜなら、あなたが誰かに正しい方向を指し示してもらえれば、あなたにはそれを完了する能力と決意があることを示しているからです。

質問するとき#

意味のある、明確なタイトルを使用する#

メールリスト、ニュースグループ、またはフォーラムでは、約 50 文字以内のタイトルが経験豊富な専門家の注意を引く良い機会です。「助けてください」、「お願い」、「急いで」（ましてや「助けて！！！！」のような反感を抱かせる言葉を使うのは、この機会を無駄にすることになります）を使ってこの機会を浪費しないでください。あなたの苦痛の程度で私たちを感動させようとしないでください。むしろ、この限られたスペースで非常にシンプルで簡潔な説明を使って質問を提示してください。

良いタイトルの例は目的 -- 差異の形式で、多くの技術サポート組織がこのように行っています。目的の部分では、どのアイテムまたはグループに問題があるかを示し、差異の部分では期待される動作と一致しない点を説明します。

愚かな質問：助けて！私のノートパソコンが正常に表示されません！

賢い質問：X.org 6.8.1 のマウスカーソルが変形します。特定のグラフィックカード MV1005 チップセット。

より賢い質問：X.org 6.8.1 のマウスカーソルが、特定のグラフィックカード MV1005 チップセット環境下で変形します。

目的 -- 差異形式の説明を書くプロセスは、問題に対する詳細な考察を整理するのに役立ちます。何が影響を受けましたか？ただマウスカーソルだけですか、それとも他のグラフィックもですか？ X.org の特定のバージョンでのみ発生しますか？それとも 6.8.1 バージョンでのみですか？特定のグラフィックカードチップセットに関連していますか？それともその中の MV1005 モデルだけですか？ハッカーは一目見ただけで、あなたの環境とあなたが直面している問題をすぐに理解できます。

要するに、あなたがタイトルだけが表示されるアーカイブのディスカッションスレッドを検索していると想像してください。あなたのタイトルが問題をよりよく反映することで、次に同様の問題を検索している人がこのディスカッションスレッドに注目できるようになります。

返信で質問を提起する場合は、内容のタイトルを変更して、あなたが質問をしていることを示してください。Re: テストやRe: 新しいバグのようなタイトルは、十分な注意を引くのが難しいです。また、連続性に影響を与えない範囲で、前の内容を適切に引用し、削除することで、新しい読者に手がかりを残すことができます。

ディスカッションスレッドに対して、直接返信をクリックして全く新しいディスカッションスレッドを開始しないでください。これにより、あなたの観客が制限されます。なぜなら、いくつかのメールリーディングプログラム（例えば mutt）は、ユーザーがディスカッションスレッドでソートし、メッセージを折りたたむことを許可しているため、そうする人々はあなたが送信したメッセージを決して見ることがありません。

単にタイトルを変更するだけでは不十分です。mutt や他のいくつかのメールリーディングプログラムは、メールのタイトル以外の情報もチェックして、ディスカッションスレッドを指定します。したがって、全く新しいメールを送信する方が良いです。

ウェブフォーラムでは、良い質問の仕方は少し異なります。なぜなら、ディスカッションスレッドが特定の情報と密接に結びついており、通常はディスカッションスレッドの外で中身を見ることができないため、タイトルを変更するのではなく、返信して質問することが許容されます。ただし、すべてのフォーラムが返信内で分離されたタイトルを許可しているわけではなく、そうすることで基本的に誰もあなたの投稿を見ないでしょう。しかし、返信して質問すること自体は曖昧な行為であり、それはそのタイトルを見ている人だけが読むことになります。したがって、もしあなたがただそのディスカッションスレッドの現在の活発な人々に質問したいのでなければ、別のスレッドを立てる方が良いです。

質問を簡単に返信できるようにする#

あなたの返信を……に送ってくださいで質問を終えることは、ほとんどの場合、あなたが回答を得られない原因になります。もしあなたがメールクライアントで返信先アドレスを設定するのに数秒かかるのが面倒だと感じるなら、私たちもあなたの質問を考えるのに数秒かかるのが面倒だと感じます。もしあなたのメールプログラムがそれをサポートしていないなら、良いものに変えてください；もしオペレーティングシステムがそのようなメールプログラムをサポートしていないなら、良いものに変えてください。

フォーラムでは、電子メールでの返信を要求することは非常に無礼です。特に、返信が敏感な情報である可能性がある場合（そして、誰かが未知の理由であなたにだけ答えを知らせることを望む場合）を除いて。もしあなたが単に誰かがディスカッションスレッドに返信したときにメールで通知を受け取りたいだけなら、ウェブフォーラムにそれを要求することができます。ほとんどのフォーラムは、このディスカッションスレッドを追跡する、返信があったときにメールで通知するなどの機能をサポートしています。

明確で正確、かつ文法的に正しい文を使用する#

私たちは経験から、注意を怠る質問者は通常、プログラムや思考も粗雑であることを知っています（私は保証します）。注意を怠る人の質問に答えるのはあまり価値がないため、私たちは他の場所で時間を費やす方が良いです。

正しいスペル、句読点、大文字小文字は非常に重要です。一般的に、あなたがそれを面倒だと感じ、気にしないのであれば、私たちも面倒だと感じ、あなたの質問を気にしません。少し余分なエネルギーを使って言葉を考え直してください。あまり堅苦しくなく、正式である必要はありません - 実際、ハッカー文化は非公式な言葉、スラング、ユーモアを正確に使用することを重視しています。しかし、それは非常に正確でなければならず、あなたが問題について考え、注意を払っていることを示す必要があります。

正しくスペルを確認し、句読点や大文字小文字を使用し、itsをit'sと混同せず、looseをloseにせず、discreteをdiscreetにしないでください。すべて大文字を使用しないでください。これは無礼な大声での叫びと見なされます（すべて小文字もあまり良くありません。なぜなら、読みづらいからです。Alan Coxはそうするかもしれませんが、あなたはそうではありません）。

より口語的に言えば、もしあなたが半文盲のように書いているなら、ほとんど無視されるでしょう。また、即時通信の略語や火星文を使用しないでください。例えば、のをㄉに簡略化することは、少しでもキーを打つのを減らそうとする小白のように見えます。さらに悪いことに、子供のように落書きのように見えるのは確実に自殺行為であり、誰もあなたを気にかけないでしょう（あるいは、せいぜい多くの非難や嘲笑を受けることになります）。

もし非母国語のフォーラムで質問する場合、スペルや文法の小さな間違いを犯すことは許されますが、思考においては粗雑であってはいけません（そう、私たちは通常、両者の違いを理解できます）。また、返信者が使用する言語を知らない限り、英語で書くようにしてください。忙しいハッカーは、理解できない言語で書かれたメッセージを直接削除することが一般的です。インターネット上では英語が共通語であり、英語で書くことで、あなたの質問が未読のまま直接削除される可能性を最小限に抑えることができます。

もし英語があなたの第二言語であるなら、潜在的な返信者にあなたが言語の困難を抱えていることを示すのは良いことです：
[訳注：以下に原文を添付します]

English is not my native language; please excuse typing errors.

英語は私の母国語ではありません。タイプミスをお許しください。

If you speak $LANGUAGE, please email/PM me;
I may need assistance translating my question.

もしあなたが特定の言語を話すなら、私にメール / 私信をください；私は私の質問を翻訳するのを手伝ってもらう必要があるかもしれません。

I am familiar with the technical terms,
but some slang expressions and idioms are difficult for me.

私は技術用語には詳しいですが、俗語や特定の表現にはあまり詳しくありません。

I've posted my question in $LANGUAGE and English.
I'll be glad to translate responses, if you only use one or the other.

私は私の質問を特定の言語と英語で書きました。もしあなたが一方の言語だけで答えれば、私は喜んで他方に翻訳します。

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

もしあなたが意図的に質問を読みづらくしているなら、それはほとんど無視されることになります。人々は理解しやすい質問を読むことを好むので：

HTML ではなくプレーンテキストを使用してください（HTML を無効にするのは難しくありません）
MIME 添付ファイルは通常許可されますが、実際に内容がある場合（例えば、添付されたソースコードやパッチ）に限ります。メールプログラムが生成したテンプレート（例えば、単に手紙の内容のコピー）ではなく。
一行の文を何度も改行したメールを送信しないでください（これは返信の一部を非常に困難にします）。あなたの読者が 80 文字幅の端末でメールを読んでいると想像し、改行ポイントを 80 文字未満に設定するのが最善です。
しかし、決して固定改行データ（例えば、ログファイルのコピーやセッション記録）を使用しないでください。ファイルはそのまま保持され、返信者があなたが見ているものと同じものを見ていると確信できるようにするべきです。
英語のフォーラムでは、Quoted-Printable MIME エンコーディングを使用してメッセージを送信しないでください。このエンコーディングは非 ASCII 言語を投稿する際には必要かもしれませんが、多くのメールプログラムはこのエンコーディングをサポートしていません。分断されると、そのテキストに散在する=20記号は見栄えが悪く、注意を散漫にし、内容の意味を損なう可能性があります。
絶対に、決してハッカーが閉じた形式で書かれた文書を読むことを期待しないでください。例えば、Microsoft の Word や Excel ファイルなどです。ほとんどのハッカーは、まだ熱い豚の糞をあなたの玄関に投げつけられたときの反応のように反応します。たとえ彼らがそれを処理できたとしても、彼らはそれを嫌います。
もしあなたが Windows のコンピュータから電子メールを送信する場合、Microsoft の愚かなスマートクォート機能を無効にしてください（[オプション] > [校正] > [自動修正オプション] から、スマートクォートのチェックボックスをオフにしてください）。これにより、あなたのメールにゴミ文字が散在するのを防ぎます。
フォーラムでは、絵文字やHTML機能を乱用しないでください（それらが提供されている場合）。一つか二つの絵文字は通常問題ありませんが、派手なカラーテキストは、あなたが無能な人間であると見なされる傾向があります。絵文字、色、フォントを過剰に使用すると、あなたは愚かな小娘のように見えます。これは通常良いアイデアではありません。なぜなら、あなたが有用な返信よりもセックスに興味がある場合を除いて。

もしあなたがグラフィカルユーザーインターフェースのメールプログラム（例えば Microsoft の Outlook やその他の類似のもの）を使用している場合、それらのデフォルト設定がこれらの要件を満たさないことがあることに注意してください。ほとんどのこの種のプログラムには、メニューに基づくソースコードを表示コマンドがあり、それを使用して送信フォルダ内のメッセージを確認し、余分な不純物のないプレーンテキストファイルが送信されていることを確認できます。

問題を正確に説明し、内容を持たせる#

あなたの問題やバグの症状を注意深く、明確に説明してください。
問題が発生した環境（マシンの構成、オペレーティングシステム、アプリケーション、および関連情報）を説明し、ベンダーのリリースとバージョン番号を提供してください（例：Fedora Core 4、Slackware 9.1など）。
質問する前に、あなたがこの問題をどのように研究し理解したかを説明してください。
質問する前に問題を特定するために取った診断手順を説明してください。
最近行った可能性のある関連するハードウェアまたはソフトウェアの変更を説明してください。
可能な限り、この問題を再現するための確立された環境を提供してください。

ハッカーがあなたにどのように反問するかを推測し、彼が質問する際に事前に答えを提供することを心がけてください。

上記のポイントの中で、あなたがコード内に問題があると考えている場合、ハッカーにあなたの問題を再現できる環境を提供することが特に重要です。これを行うことで、あなたが有効な回答を得る機会と速度が大幅に向上します。

Simon Tathamは《バグを効果的に報告する方法》という素晴らしい記事を書いています。ぜひ読んでみてください。

言葉は多くなく、内容が重要#

あなたは正確で内容のある情報を提供する必要があります。これは、あなたが大量のエラーメッセージやデータを単に質問に転記することを要求するものではありません。もしあなたがプログラムがクラッシュする状況を再現できる大規模で複雑なテストサンプルを持っているなら、それをできるだけ小さく切り詰めるようにしてください。

これを行うことには少なくとも三つの利点があります。
第一に、問題を簡素化するために努力したことを示すことで、回答を得る機会が増えます；
第二に、問題を簡素化することで、有用な回答を得る可能性が高くなります；
第三に、バグレポートを精練する過程で、あなた自身が解決策や回避策を見つける可能性が高くなります。

謙虚さを持ちつつ、まずは自分で調べる#

ある人々は、粗野または傲慢に質問して回答を求めるべきではないことを理解していますが、別の極端に走ることを選択します - 謙虚すぎることです：私はただの悲惨な初心者で、ルーザーですが...。これは困惑させるだけでなく、特に実際の問題の曖昧な説明とともにあると、さらに不快です。

原始的な霊長類のトリックを使ってあなたと私の時間を無駄にしないでください。代わりに、背景条件とあなたの問題の状況をできるだけ明確に説明してください。これは、謙虚さよりもあなたの位置をより良く特定します。

時には、ウェブフォーラムには初心者の質問専用のセクションが設けられていることがあります。もし本当に初心者の問題に直面していると思うなら、そこに行くのが良いですが、同じように謙虚すぎないでください。

問題の症状を説明し、推測を避ける#

ハッカーにあなたが問題がどのように発生したと考えているかを伝えることはあまり役に立ちません。（もしあなたの推測がそれほど有効であれば、他の人に助けを求める必要はありません）。したがって、彼らに問題の症状をそのまま伝え、あなたの説明や理論ではなく、問題の症状を伝えるようにしてください。ハッカーに推測や診断をさせるのです。もし自分の推測を述べることが重要だと思うなら、それが単なる推測であることを明確にし、なぜそれが機能しなかったかを説明してください。

愚かな質問

私はカーネルをコンパイルしているときに連続して SIG11 エラーに遭遇しました。
どこかの飛行機がマザーボードの走行線に接触していると思いますが、どのようにチェックすればよいでしょうか？

賢い質問

私の組み立てたコンピュータは FIC-PA2007 マザーボードに AMD K6/233 CPU（VIA Apollo VP2 チップセット）を搭載し、
256MB の Corsair PC133 SDRAM メモリを使用しています。カーネルをコンパイルしていると、起動から 20 分後に頻繁に SIG11 エラーが発生しますが、
最初の 20 分間は同じ問題が発生しません。再起動しても効果がなく、夜間にシャットダウンすると再び 20 分間は正常に動作します。
すべてのメモリを交換しましたが、効果はありませんでした。関連部分の標準的なコンパイルログは以下の通りです…。

上記の点が多くの人々にとって協力が難しいと感じさせることがあるため、ここに一言：すべての診断専門家はミズーリ州出身です。 アメリカ国務省の公式モットーは見せてくださいです（これは 1899 年に国会議員 Willard D. Vandiver が述べた言葉で、私はトウモロコシ、綿花、ゴボウ、民主党員を生産する国から来ました。雄弁は私を説得することも、私を満足させることもありません。私はミズーリ州から来ました。あなたは私に見せなければなりません。）。診断者にとって、これは疑念ではなく、彼らが見たいのはあなたが見ている原始的な証拠にできるだけ一致するものであり、あなたの推測や帰納的な結論ではありません。したがって、私たちに見せてください！

問題の症状を時系列で列挙する#

問題が発生する前の一連の操作は、問題を特定するのに最も役立つ手がかりです。したがって、あなたの説明には操作手順とマシンやソフトウェアの反応を含めるべきです。コマンドライン処理の場合、操作記録（例えば、スクリプトツールが生成したもの）を提供し、関連する数行（例えば 20 行）を引用することが非常に役立ちます。

クラッシュしたプログラムに診断オプション（例えば、-v の詳細スイッチ）がある場合は、これらのオプションを選択して、記録にデバッグ情報を追加するようにしてください。覚えておいてください、多いは良いではありません。読者がゴミに埋もれないように、適切なデバッグレベルを選択して有用な情報を提供してください。

あなたの説明が長い場合（例えば、4 段落を超える場合）、最初に問題を要約し、その後時系列で詳細を説明するのが役立ちます。こうすることで、ハッカーはあなたの記録を読む際に注意すべき内容を知ることができます。

目標を説明し、プロセスを説明しない#

何かをする方法を理解したい場合（バグを報告するのではなく）、最初に目標を説明し、その後にあなたが詰まっている特定のステップを述べてください。

技術的な助けを求める人々は、心の中により高いレベルの目標を持っており、彼らはその目標に到達できると思っている特定の道で詰まってしまい、どのように進むべきかを尋ねに来ますが、その道自体に問題があることに気づいていません。その結果、非常に多くの労力を費やすことになります。

愚かな質問

どのようにして特定の描画プログラムのカラーピッカーから 16 進数の RGB 値を取得できますか？

賢い質問

私は画像の色コードを自分の選んだ色コードに置き換えようとしています。今のところ、唯一の方法は各色コードブロックを編集することだと知っていますが、
特定の描画プログラムのカラーピッカーから 16 進数の RGB 値を取得することができません。

後者の質問の方が賢いです。あなたは別のより適切なツールを提案するという回答を得るかもしれません。

あなたの問題とニーズを明確に表現する#

漫然とした質問は、ほぼ無限の時間のブラックホールです。最も有用な回答を得る可能性が高い人々は、通常、最も忙しい人々です（彼らが忙しいのは、ほとんどの作業を自分で完了しなければならないからです）。このような人々は、無制限の時間のブラックホールに非常に嫌悪感を抱いているため、漫然とした質問を嫌う傾向があります。

もしあなたが回答者に何をしてほしいのか（指導を提供する、コードの一部を送信する、あなたのパッチをチェックする、またはその他のこと）を明確に述べれば、最も有用な回答を得る可能性が高くなります。なぜなら、これにより回答者が集中して助けることができるように、時間と労力の上限が設定されるからです。これは素晴らしいことです。

専門家が置かれている世界を理解するために、専門的なスキルを豊富な資源と考え、返信にかかる時間を希少な資源と考えてください。あなたが彼らに求める時間が少ないほど、真の専門家からの回答を得る可能性が高くなります。

したがって、あなたの問題を定義し、専門家があなたの問題を特定し、回答するのに必要な時間を最小限に抑えることができれば、このテクニックは有用な回答を得るのに非常に役立ちます - しかし、このテクニックは通常、問題を簡素化することとは異なります。したがって、私はXをより良く理解したいのですが、良い説明がある場所を指摘していただけますか？と尋ねることは、あなたはXを説明できますか？と尋ねるよりも通常良いです。もしあなたのコードが機能しない場合、他の人にどこが問題なのかを見てもらうように頼むことは、他の人に修正を求めるよりも賢明です。

コードに関する質問をする際#

他の人に問題のあるコードをデバッグしてもらうように頼む場合、どこから始めるべきかを示さないでください。数百行のコードを投稿して、動かないと言うだけでは、完全に無視されることになります。数十行のコードを貼り付けて、7行目以降で<x>が表示されることを期待していましたが、実際には<y>が表示されましたと言う方が、応答を得る可能性が高くなります。

プログラムの問題を最も効果的に説明する方法は、バグを示す最小限のテストケース（bug-demonstrating test case）を提供することです。最小限のテストケースとは何か？それは問題の縮図です；プログラムの異常な動作をちょうど示す小さなプログラムの断片であり、他の気を散らす内容を含まないものです。最小限のテストケースを作成するには？もしあなたがどの行またはどの部分のコードが異常な動作を引き起こすかを知っているなら、それをコピーして、状況を再現するのに十分なコード（例えば、そのコードがコンパイル / インタープリタ / アプリケーションで処理されるのに十分なもの）を追加してください。もし問題を特定のブロックに縮小できない場合は、コードのコピーを作成し、問題の動作を引き起こす部分を削除してください。要するに、テストケースは小さければ小さいほど良いです（言葉は多くなく、内容が重要のセクションを参照してください）。

一般的に、かなりの精度のあるテストケースを得ることは容易ではありませんが、常にそうすることを試みるのは良い習慣です。この方法は、あなたがこの問題を自分で解決する方法を理解するのに役立ちます - そして、たとえあなたの試みが成功しなくても、ハッカーたちはあなたが答えを得るために努力していることを見て、より協力的になるでしょう。

もしあなたが他の人にコードをレビューしてもらうことを望む場合、メールの冒頭でそれを伝え、特にどの部分に注目してほしいか、なぜそれが重要かを必ず言及してください。

自分の宿題の問題を投稿しない#

ハッカーは、どの問題が宿題のような問題であるかを見分けるのが得意です。なぜなら、私たちのほとんどはこのような問題を自分で解決したからです。同様に、これらの問題はあなたが解決するべきです。あなたはヒントを求めることができますが、完全な解決策を求めないでください。

もしあなたが自分が宿題のような問題に直面しているのではないかと疑っているが、それでも解決できない場合は、ユーザーグループ、フォーラム、または（最後の手段として）プロジェクトのユーザーメールリストやフォーラムで質問してみてください。ハッカーたちは見抜くでしょうが、経験豊富なユーザーがいくつかのヒントを提供してくれるかもしれません。

無意味な質問文を取り除く#

無意味な言葉で質問を終えることを避けてください。例えば、誰か助けてくれますか？やこれに答えはありますか？などです。

まず第一に：もしあなたの問題の説明があまり良くない場合、そう尋ねることは蛇足です。

第二に：このように尋ねることは蛇足であるため、ハッカーたちはあなたに対して非常に不快感を抱くでしょう - そして通常、論理的には正しいが無意味な回答で彼らの軽蔑を示すことになります。例えば、そうです、誰かがあなたを助けることができますやいいえ、答えはありませんなどです。

一般的に、はいまたはいいえ、正しいまたは間違っている、あるまたはないタイプの質問を避けてください。あなたがはいまたはいいえの回答を得たいのでない限り。

礼儀正しさは無駄ではなく、時には非常に役立つ#

礼儀正しく、お願いしますやご関心をお寄せいただきありがとうございます、またはあなたの配慮に感謝しますを多用してください。皆があなたが彼らの時間を無料で提供することに感謝していることを知っていると良いでしょう。

正直に言うと、この点は明確で正確、かつ文法的に正しいことや、特定の形式を避けることほど重要ではありません（またはそれに取って代わることはできません）。ハッカーたちは、少し唐突だが技術的に明確なバグレポートを読むことを好む傾向があり、礼儀正しいが曖昧なレポートを好むことはありません。（この点が理解できない場合、私たちは問題が私たちに何を教えてくれるかによって問題の価値を評価していることを思い出してください）

しかし、もしあなたが解決すべき問題のリストを持っているなら、少し丁寧にすることで、有用な応答を得る可能性が高まります。

（私たちは、このガイドが発表されて以来、経験豊富なハッカーから得た唯一の重大な欠陥フィードバックは、事前に感謝の意を表することに関するものであることに気づきました。一部のハッカーは、先に感謝しますが、事後に感謝しないという暗示を意味することを感じています。私たちの提案は、先に感謝しますと言うか、その後返信者に感謝の意を示すか、またはご関心をお寄せいただきありがとうございますやあなたの配慮に感謝しますのように感謝を表現する別の方法を使用することです。）

問題が解決したら、簡単な補足を追加する#

問題が解決したら、あなたを助けてくれたすべての人に通知し、問題がどのように解決されたかを知らせ、再度感謝の意を示してください。問題がニュースグループやメールリストで広く注目を集めた場合、そこで説明を投稿するのが適切です。

理想的な方法は、最初の質問のトピックにこのメッセージを返信し、タイトルに修正済み、解決済みまたはその他の同等の意味を持つ明確なマークを含めることです。人々が行き交うメールリストでは、問題Xと問題のX - 解決済みというディスカッションスレッドを見た潜在的な返信者は、もう時間を無駄にする必要がないことを理解します（彼らが個人的に問題Xに興味がある場合を除いて）。したがって、この時間を使って他の問題を解決することができます。

補足は長くても深くなくても構いません；単純にこんにちは、実はネットワークケーブルに問題がありました！皆さんありがとう - ビルという一言が、何も言わないよりも良いです。実際、結論が本当に技術的な内容でない限り、短くて可愛らしい要約の方が長文よりも良いです。問題がどのように解決されたかを説明し、解決策を指摘した後に、避けるべき盲点を示すことができます。盲点を避ける部分は、正しい解決策や他の要約資料の後に配置し、この情報を探偵小説のようにしないでください。あなたを助けてくれた人々の名前を挙げることで、より多くの友人を得ることができます。

礼儀正しさと内容のある補足は、他の人がメールリスト / ニュースグループ / フォーラムであなたの問題を解決するための実際の解決策を見つけるのに役立ち、彼らもその恩恵を受けることができます。

少なくとも、この補足は、問題の解決によってすべての協力者が満足感を得るのに役立ちます。もしあなた自身が技術的な専門家やハッカーでないなら、私たちを信じてください。この感覚は、あなたが助けを求めたマスターや専門家にとって非常に重要です。問題が未解決のままであることは、失望を引き起こします；ハッカーは問題が解決されるのを見たいと切望しています。良い人には良い報いがあり、彼らの欲求を満たすことで、次回の質問時に甘い思いをすることができます。

他の人が将来同様の問題に直面するのを避ける方法を考え、文書を作成するか、FAQ を追加することが役立つか自問してください。もしそうであれば、それをメンテナに送信してください。

ハッカーの間では、このような良いフォローアップは、実際には伝統的な礼儀よりも重要であり、他人に良く接することで評判を得る方法であり、これは非常に貴重な資産です。

答えを解釈する方法#

RTFM と STFW：あなたが完全に失敗したことを知る方法#

古くて神聖な伝統があります：もしあなたがRTFM（Read The Fucking Manual）という返答を受け取ったら、回答者はあなたがマニュアルを読むべきだと考えています。もちろん、基本的に彼は正しいです。あなたは読んでみるべきです。

RTFM には若い親戚がいます。もしあなたがSTFW（Search The Fucking Web）という返答を受け取ったら、回答者はあなたがウェブで検索するべきだと考えています。その人はおそらく正しいです。検索してみてください。（より穏やかな言い方は **Google はあなたの友達です**！）

フォーラムでは、あなたが古い投稿をさかのぼるように求められることもあります。実際、誰かが以前にこの問題を解決したディスカッションスレッドを親切に提供してくれることもあります。しかし、このような配慮に依存しないでください。質問する前に古い投稿を検索するべきです。

通常、これらのいずれかであなたに回答する人は、必要な内容を含むマニュアルや URL を提供してくれるでしょう。そして、彼らがこれらの単語を打っているとき、彼らも読んでいます。これらの回答は、回答者が

あなたが必要な情報を非常に簡単に入手できると考えている；
自分でその情報を検索する方が、あなたに教えるよりも多くのことを学べると考えている。

あなたはこれに不満を抱くべきではありません；ハッカーの基準に従えば、彼はあなたに一定の関心を示し、あなたの要求を無視しなかったのです。あなたは彼に感謝の意を示すべきです。

それでも理解できない場合#

もしあなたが返答を理解できない場合、すぐに相手に説明を求めないでください。以前に問題を解決しようとしたときのように（マニュアル、FAQ、ウェブ、身近な専門家を利用して）、まず彼の返答を理解しようとしてください。もし本当に相手に説明を求める必要がある場合は、あなたが何かを学んだことを示してください。

例えば、もし私があなたに「zentryがハングしているようです；まずそれをクリアしてください。」と答えた場合、これは非常に悪いフォローアップ質問の応答です：zentryって何ですか？ 良い質問の仕方はこうです：ああ~~~説明書を見ましたが、-zと-pの2つのパラメータしかzentryに言及していませんでしたが、どちらのことを指していますか？それとも、私が見落とした何かがありますか？

質問すべきでないこと#

以下は、いくつかのクラシックな愚かな質問と、ハッカーが回答しないときに心の中で思っていることです：

質問：X プログラムまたは X リソースはどこにありますか？

質問：X を使って Y をどうやって行いますか？

質問：私のシェルプロンプトをどう設定しますか？

質問：Bass-o-matic ファイル変換ツールを使って AcmeCorp ファイルを TeX 形式に変換できますか？

質問：私のプログラム / 設定 / SQL 文は機能しません

質問：私の Windows コンピュータに問題があります。助けてくれますか？

質問：私のプログラムが動かなくなりました。システムツール X に問題があると思います。

質問：Linux（または X）をインストールする際に問題があります。助けてくれますか？

質問：root アカウントをハックするにはどうすればいいですか？/OP 特権を盗むには？/ 他人のメールを読むには？

質問：X プログラムまたは X リソースはどこにありますか？

回答：私が見つけた場所に決まっているだろ、愚か者 -- 検索エンジンの向こう側だ。まさか、まだGoogleの使い方がわからない人がいるのか？

質問：X を使って Y をどうやって行いますか？

回答：もしあなたが解決したいのが Y であるなら、質問する際に適切でない方法を提示しないでください。この種の質問は、質問者が X について完全に無知であるだけでなく、Y の問題を解決することについても混乱しており、特定の状況に思考が制約されていることを示しています。このような人を無視するのが最善です。彼らが問題を明確にするまで待ちましょう。

質問：私のシェルプロンプトをどう設定しますか？

回答：もしあなたがこの質問をするだけの知恵があるなら、あなたはそれをRTFMして自分で見つけるだけの知恵も持っているはずです。

質問：Bass-o-matic ファイル変換ツールを使って AcmeCorp ファイルを TeX 形式に変換できますか？

回答：試してみればわかります。もしあなたが試したのなら、あなたは答えを知っているので、私の時間を無駄にする必要はありません。

質問：私のプログラム / 設定 / SQL 文は機能しません。

回答：これは問題とは言えません。あなたが私に 20 の質問をさせて本当の問題を見つけるまで、私は興味を持ちません -- 私にはもっと面白いことがあります。この種の質問を見たとき、私の反応は通常次の 3 つです。

何か補足がありますか？
残念ですね。あなたが解決できることを願っています。
それは私にとって何の関係がありますか？

質問：私の Windows コンピュータに問題があります。助けてくれますか？

回答：もちろん、腐ったゴミを捨てて、Linux や BSD のようなオープンソースのオペレーティングシステムに切り替えなさい。

注意：もしプログラムが公式の Windows 版を持っているか、Windows と相互作用する（例えば Samba）場合、あなたは Windows に関連する問題を尋ねることができます。ただし、問題が Windows オペレーティングシステムによって引き起こされているのではなく、プログラム自体によって引き起こされている場合の回答には驚かないでください。なぜなら、一般的に Windows は非常に悪いからです。このような発言は通常正しいです。

質問：私のプログラムが動かなくなりました。システムツール X に問題があると思います。

回答：あなたは、何千人ものユーザーによって繰り返し使用されているシステムコールやライブラリファイルに明らかな欠陥があることに気づいた最初の人かもしれませんが、あなたには根拠がまったくない可能性が高いです。特異な主張には特異な証拠が必要です。あなたがそのように主張する場合、あなたは明確で詳細な欠陥の説明を持っている必要があります。

質問：Linux（または X）をインストールする際に問題があります。助けてくれますか？

回答：いいえ、あなたのコンピュータで手を動かさなければ、問題を見つけることはできません。地元の Linux ユーザーグループに実際の指導を求めてください（あなたはここでユーザーグループのリストを見つけることができます）。

注意：もしインストールの問題が特定の Linux ディストリビューションに関連している場合、そのメールリスト、フォーラム、または地元のユーザーグループで質問するのが適切かもしれません。この場合、問題の正確な詳細を説明してください。その前に、Linuxとすべての疑わしいハードウェアをキーワードにして慎重に検索してください。

質問：root アカウントをハックするにはどうすればいいですか？/OP 特権を盗むには？/ 他人のメールを読むには？

回答：そうしたいのであれば、あなたは卑劣な人間です；ハッカーに助けを求めることは、あなたが愚か者であることを示しています！

良い質問と愚かな質問#

最後に、いくつかの例を挙げて、どのように賢く質問するかを示します。同じ質問の 2 つの尋ね方を並べて、1 つは愚かなもので、もう 1 つは賢いものです。

愚かな質問：

私はどこで Foonly Flurbamatic に関する情報を見つけることができますか？

この尋ね方は、STFWのような回答を得ることを望んでいるだけです。

賢い質問：

私は "Foonly Flurbamatic 2600" を Google で検索しましたが、有用な結果は見つかりませんでした。誰かこのデバイスのプログラミングに関する資料を見つける場所を知っていますか？

この質問はすでに STFW を行っており、彼は本当に問題に直面しているようです。

愚かな質問

foo プロジェクトから取得したソースコードがコンパイルできません。どうしてこんなにひどいのですか？

彼はすべて他人のせいだと考えており、この傲慢で自信過剰な質問者です。

賢い質問

foo プロジェクトのコードが Nulix 6.2 でコンパイルできません。私は FAQ を読みましたが、Nulix に関連する問題は記載されていませんでした。これが私のコンパイルプロセスの記録です。私は何を間違えたのでしょうか？

質問者は環境を特定し、FAQ を読み、エラーをリストし、問題の責任を他人に押し付けていません。彼の質問は注目に値します。

愚かな質問

私のマザーボードに問題があります。誰か助けてくれますか？

この種の質問に対するハッカーの反応は通常、わかった、あなたの背中を叩いておむつを替えますか？というものです。そして、削除ボタンを押します。

賢い質問

私は S2464 マザーボードで X、Y、Z を試しましたが、効果がありませんでした。さらに A、B、C を試しました。C を試したときの奇妙な現象に注意してください。明らかに florbish が grommicking していますが、結果は予想外です。通常、Athlon MP マザーボードで grommicking を引き起こす原因は何ですか？次に何をテストすれば問題を特定できるか知っている人はいますか？

この人は、別の視点から見ると、答える価値があります。彼は問題を解決する能力を示しており、ただ答えが天から降ってくるのを待っているわけではありません。

最後の質問では、私に答えを教えてくださいと私にヒントを与えて、次に何を診断すべきかを指摘してくださいの間の微妙で重要な違いに注意してください。

実際、後者の質問は、2001 年 8 月に Linux カーネルメールリスト（lkml）で行われた実際の質問から来ています。私（Eric）がその質問をした人です。Tyan S2464 マザーボードでこの説明できないロックアップ現象を観察し、リストのメンバーがこの問題を解決するための重要な情報を提供してくれました。

私の質問方法によって、他の人々が考え、参加しやすくなりました。私は彼らと同等の能力を持っていることを示し、彼らに私と一緒に探求するよう招待しました。私が彼らの貴重な時間を尊重していることを示すために、私が通過した道を彼らに伝え、彼らが再び時間を無駄にしないようにしました。

その後、私は皆に感謝の意を示し、この良い議論の経験を称賛しました。Linux カーネルメールリストのメンバーの一人は、私の問題が解決されたのは、私がこのリストの有名人であったからではなく、正しい方法で質問したからだと感じたと述べました。

ハッカーはある意味で豊富な知識を持っていますが、人情に欠ける人々です。私は彼が正しいと思います。もし私が乞食のように質問していたら、誰であっても、ある人々を怒らせたり、無視されたりすることは確実です。彼は私にこのことを記録するように勧め、これが本ガイドの出現につながりました。

質問に対するより良い回答方法#

態度を優しく。問題がもたらすストレスは、人々を無礼または愚かに見せることがありますが、実際にはそうではありません。

初犯者には私的に返信する。誤りを犯したことを率直に認める人々を公然と恥じさせる必要はありません。真の初心者は、検索の仕方や FAQ を見つける方法すら知らないかもしれません。

もし不確かであれば、必ず言ってください！権威のあるように聞こえる誤った回答は、何もないよりも悪いです。専門家のように聞こえるのが楽しいからといって、他の人を誤った方向に導かないでください。謙虚で正直であり、質問者と仲間に良い模範を示してください。

もし助けられないなら、彼を妨げないでください。実際の手順を冗談にすることは、ユーザーの設定を壊す可能性があります -- かわいそうな愚か者はそれを本当の命令だと受け取るかもしれません。

試験的に反問して、より多くの詳細を引き出す。もしあなたがうまくやれば、質問者は何かを学ぶことができます -- あなたも学ぶことができます。愚かな質問を良い質問に変えることを試みてください。私たちは皆、初心者だったことを忘れないでください。

怠け者に RTFM と文句を言うことは正当ですが、ドキュメントの位置を指摘すること（たとえそれが Google 検索のキーワードを提案するだけであっても）はより良いです。

もしあなたが回答することを決めたら、良い回答を提供してください。他の人が間違ったツールや方法を使用しているときに、ぎこちない回避策（workaround）を提案するのではなく、より良いツールを推奨し、問題を再定義してください。

ポジティブに質問に答える！もしこの質問者がすでに深く研究し、X、Y、Z、A、B、C を試したが結果が得られなかったことを示しているなら、AまたはBを試してみてくださいやX、Y、Z、A、B、Cを試してみてくださいと答え、リンクを添付することは無意味です。

コミュニティが問題から学ぶのを助ける。良い質問に答えるとき、あなた自身にどのように関連するドキュメントやFAQを修正して、同じ質問に再度答える必要がないようにするか？と尋ねてください。そして、ドキュメントのメンテナにパッチを送信してください。

もしあなたが研究の後に回答を行ったのであれば、あなたのスキルを示し、結果を直接提供するのではなく。結局のところ、魚を与えるよりも釣り方を教える方が良いのです。

謝辞#

Evelyn Mitchel は、いくつかの愚かな質問の例を提供し、質問に対するより良い回答方法のセクションを書くためのインスピレーションを与えてくれました。Mikhail Ramendik は、特に貴重な提案と改善を提供してくれました。

Simple is Better

宣言#