質問の知恵

賢い質問の仕方

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

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

Copyleft 2001 by D.H.Grand(nOBODY/Ginux), 2010 by Gasolin, 2015 by Ryan Wu

本中国語ガイドは原文 3.10 版および 2010 年にGasolinが翻訳したバージョンに基づく最新の翻訳です；

翻訳の問題を指摘するために、ぜひIssue を発行するか、直接Pull Request を送ってください。

この記事には簡体字版もあります: https://github.com/FredWe/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md

原文バージョン履歴 #

声明#

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

本ガイドはこのプロジェクトの実際のサポートサービスを提供していません！

私たちはこの声明が欠けていることによる苦痛を深く理解しています。この声明がないために、私たちは無知な人々に悩まされ続けています。彼らは、私たちがこのガイドを公開したので、私たちが世界中のすべての技術的問題を解決する責任があると考えています。

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

概要#

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

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

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

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

私たちは、考えようとせず、質問する前に自分がすべきことをしない人々に対して軽蔑を抱いていることを隠しません。そういう人々は時間泥棒です - 彼らは与えようとせず、ただ奪うことを望んでおり、私たちがより興味深い問題やより答える価値のある人々に使える時間を消耗させます。私たちはこういう人々を 失敗者（lusers）と呼びます。

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

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

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

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

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

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

質問する前に#

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

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

質問をする際には、上記の努力を行ったことを最初に示してください。これにより、あなたが不労所得を得ようとしているわけではなく、他人の時間を無駄にしている質問者ではないことが示されます。もしあなたが上記の努力を通じて得たことを一緒に表現できれば、さらに良いでしょう。私たちは、回答から学ぶことができる人々の質問に答えることをより喜んでいます。

Google で遭遇したさまざまなエラーメッセージを検索するなどの戦略を使用すると、問題を解決するためのドキュメントやメールリストの手がかりを直接見つける可能性が高くなります。結果が得られなくても、メールリストやニュースグループで助けを求める際に「私は Google で以下の文を検索しましたが、役に立つものは見つかりませんでした」と付け加えるのも良いことです。これは、検索エンジンがどのように役立たなかったかを示すだけでなく、同様の問題に直面している他の人々が検索エンジンによってあなたの質問に導かれることを可能にします。

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

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

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

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

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

質問する時#

質問するフォーラムを慎重に選ぶ#

質問する場を慎重に選んでください。以下のことを行った場合、無視されるか、失敗者と見なされる可能性が高くなります：

テーマに合わないフォーラムに質問を投稿する
上級技術問題を議論しているフォーラムに非常に初歩的な質問を投稿する；その逆も同様
異なるニュースグループに同じ質問を繰り返し投稿する（クロスポスト）
知人でもなく、あなたの問題を解決する義務のない人にプライベートメールを送信する

ハッカーは、場を間違えた質問を排除して、彼らのコミュニケーションのチャネルが無関係なもので埋め尽くされるのを防ぎます。あなたはこのようなことが自分に起こることを望まないでしょう。

したがって、最初のステップは正しいフォーラムを見つけることです。再度言いますが、Google や他の検索エンジンはあなたの友人です。これらを使って、あなたが直面しているソフトウェアやハードウェアの問題に最も関連するウェブサイトを見つけてください。通常、そこには FAQ、メールリスト、および関連する説明文書へのリンクがあります。あなたの努力（FAQ を読むことを含む）が結果を出さなかった場合、ウェブサイトにはバグ報告（Bug-reporting）のプロセスやリンクがあるかもしれません。そうであれば、過去を振り返ってみてください。

見知らぬ人やフォーラムにメールを送ることは、最もリスクの高い行動の一つです。たとえば、豊富なコンテンツを提供するウェブページの著者があなたの無料の顧問になりたいと思うとは限りません。あなたの質問が歓迎されるかどうかを楽観視しないでください - 確信が持てない場合は、他の場所に送信するか、まったく送信しないでください。

フォーラム、ニュースグループ、またはメールリストを選択する際には、名前をあまり信じず、FAQ やライセンスを確認して、あなたの質問が適切かどうかを確認してください。投稿する前に、既存のトピックをざっと見て、そこの文化を感じ取ることができます。実際、ニュースグループやメールリストの過去の記録を検索して、あなたの質問に関連するキーワードを見つけるのは非常に良いアイデアです。そうすれば、答えが見つかるかもしれません。たとえ見つからなくても、より良い質問をまとめるのに役立ちます。

すべての支援チャネルに一度に「掃射」するのはやめましょう。これは大声で叫ぶようなもので、不快に思われます。一つずつ行ってください。

あなたのテーマを明確にしてください！最も典型的な間違いの一つは、特定のプラットフォームに移植可能な言語、ライブラリ、またはツールに関するフォーラムで Unix または Windows オペレーティングシステムのプログラムインターフェースに関する質問をすることです。なぜこれが大きな間違いなのか理解できない場合は、まずその違いを理解するまで何も質問しない方が良いです。

一般的に、慎重に選ばれた公共フォーラムで質問する方が、プライベートフォーラムで同じ質問をするよりも有用な回答を得る可能性が高いです。これにはいくつかの理由があります。潜在的な回答者の数、観客の数を考慮してください。ハッカーは、多くの人に役立つ質問に答えることを好みます。

熟練したハッカーや人気のあるソフトウェアの著者は、過剰な誤送信を受け取っています。最後の一押しが彼らを圧倒することがあります - 何度も、人気のあるソフトウェアの著者は、自分のソフトウェアのサポートから手を引くことになりました。なぜなら、彼らのプライベートメールボックスに押し寄せる無駄なメールが耐えられなくなるからです。

Stack Overflow#

検索して、その後 Stack Exchange で質問してください。

近年、Stack Exchange コミュニティは、技術的およびその他の問題に対する回答の主要なチャネルとなっています。特にオープンソースプロジェクトに関連するものです。

Google のインデックスは即時的であるため、Stack Exchange を見る前に Google で検索してください。誰かが似たような質問をすでにしている可能性が高く、Stack Exchange のウェブサイトは検索結果の最初の数件に表示されることがよくあります。Google で答えが見つからなかった場合は、特定の関連テーマのウェブサイトを探してください。タグ（Tag）検索を使用すると、検索結果をさらに絞り込むことができます。

Stack Exchange は100 を超えるウェブサイトに成長しました。以下は最も一般的に使用されるいくつかのサイトです：

Super User は一般的なコンピュータの質問をする場所です。もしあなたの質問がコードやプログラミングに関係ない場合、ここに行ってください。
Stack Overflow はプログラミングに関する質問をする場所です。
Server Fault はサーバーやネットワーク管理に関する質問をする場所です。

ウェブサイトと IRC フォーラム#

ローカルのユーザーグループ（user group）や、使用している Linux ディストリビューションは、ウェブフォーラムや IRC チャンネルを宣伝しているかもしれません。これらの場所は、新米の助けを提供するための良い出発点です（いくつかの非英語圏では、新米フォーラムはメールリストである可能性が高いです）。宣伝された IRC チャンネルは、質問を歓迎する公開の場所であり、通常は即座に応答が得られます。

実際、プログラムに問題が発生した場合、特定の Linux ディストリビューションが提供するバージョンでのみ発生する場合（これは非常に一般的です）、最初にそのディストリビューションのフォーラムやメールリストで質問し、その後プログラム自体のフォーラムやメールリストで質問するのが最善です。（そうでなければ）そのプロジェクトのハッカーは「私たちのバージョンを使用してください」とだけ返答するかもしれません。

フォーラムに投稿する前に、検索機能があるかどうかを確認してください。もしあれば、問題のいくつかのキーワードを検索してみてください。これが役立つかもしれません。もしその前に一般的なウェブ検索を行っていた場合（あなたもそうするべきです）、フォーラムを再度検索してみてください。検索エンジンがこのフォーラムのすべてのコンテンツをインデックスする時間がなかった可能性があります。

フォーラムや IRC チャンネルを通じてユーザーサポートを提供することは増加傾向にあり、電子メールは主にプロジェクト開発者間のコミュニケーションに留まっています。したがって、最初にフォーラムや IRC でそのプロジェクトに関連する支援を求めるのが最善です。

ステップ 2、プロジェクトのメールリストを使用する#

プロジェクトが開発者メールリストを提供している場合、リストに質問をすることが重要です。個々のメンバーにではなく、リストに質問してください。たとえあなたがその人があなたの質問に最もよく答えられると確信していても。プロジェクトのドキュメントやホームページを確認して、プロジェクトのメールリストを見つけて使用してください。この方法を採用することを支持するいくつかの良い理由があります：

個別の開発者に質問する必要があるほど良い質問は、プロジェクト全体のグループにも有益です。逆に、あなたの質問がプロジェクト全体にとってあまりにも愚かだと思うなら、個別の開発者を煩わせる理由にはなりません。
リストに質問することで、開発者の負担を軽減できます。個別の開発者（特にプロジェクトリーダー）は、あなたの質問に答える余裕がないほど忙しいかもしれません。
ほとんどのメールリストはアーカイブされており、アーカイブされた内容は検索エンジンによってインデックスされます。リストに質問して回答を得ると、将来的に他の人がウェブ検索を通じてあなたの質問と回答を見つけることができ、再度質問する必要がなくなります。
もし特定の質問が頻繁に尋ねられる場合、開発者はこの情報を利用してドキュメントやソフトウェア自体を改善し、より明確にすることができます。私的に質問するだけでは、最も一般的な質問の全体像を誰も見ることができません。

もしプロジェクトに「ユーザー」と「開発者」（または「ハッカー」）のメールリストやフォーラムがあり、あなたがそのソースコードに触れないのであれば、「ユーザー」リストやフォーラムに質問してください。開発者リストで歓迎されると思わないでください。彼らはあなたの質問を彼らの開発を妨げるノイズと見なすかもしれません。

ただし、もしあなたが特別な質問をしていると確信し、「ユーザー」リストやフォーラムで数日間返信がない場合は、「開発者」リストやフォーラムで質問してみてください。投稿する前に、そこでの行動様式を理解するために数日間観察することをお勧めします（実際、これは任意のプライベートまたは半プライベートリストに参加する際の良いアイデアです）。

プロジェクトのメールリストが見つからず、プロジェクトのメンテナの電子メールアドレスしか見つからない場合でも、彼にメールを送ってください。この場合でも、（プロジェクトの）メールリストが存在しないと仮定しないでください。あなたの電子メールには、適切なメールリストが見つからなかったことを試みたことを述べ、他の人に転送されることに異議がないことを示してください（多くの人は、秘密がない場合でも、プライベートな電子メールが公開されるべきではないと考えています。あなたの電子メールを他の人に転送することを許可することで、相応の人々にあなたのメールを処理する選択肢を与えます）。

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

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

良いタイトルの例は「目標 - 差異」という形式の説明です。目標部分ではどのアイテムまたはグループに問題があるかを示し、差異部分では期待される動作と一致しない点を説明します。

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

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

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

目標 - 差異形式の説明を書くプロセスは、問題を詳細に考える手助けになります。何が影響を受けていますか？マウスカーソルだけですか、それとも他のグラフィックもありますか？X.org の X 版でのみ発生しますか？それとも 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記号は見栄えが悪く、注意を散漫させ、内容の意味を破壊する可能性すらあります。
絶対に、決してハッカーに閉じた形式で書かれた文書を読むことを期待しないでください。たとえば、マイクロソフトの Word や Excel ファイルなどです。ほとんどのハッカーは、まだ熱を帯びた豚の糞をあなたの玄関の階段に倒すような反応を示します。たとえ彼らがそれを処理できたとしても、彼らはそれを非常に嫌います。
Windows を使用しているコンピュータから電子メールを送信する場合、マイクロソフトの愚かなスマートクオート機能を無効にしてください（[オプション] > [校正] > [自動修正オプション] からスマートクオートのチェックボックスをオフにします）。これにより、あなたのメールにゴミ文字が散らばるのを防ぎます。
フォーラムでは、絵文字やHTML機能を乱用しないでください（提供されている場合）。一つか二つの絵文字は通常問題ありませんが、派手なカラーテキストはあなたが無能であると見なされる傾向があります。絵文字、色、フォントを過剰に使用すると、あなたは愚かな小娘のように見えるかもしれません。これは通常良いアイデアではありません。役に立つ返信よりもセックスに興味がある場合を除いて。

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

問題を正確に説明し、具体的に述べる#

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

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

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

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

多くを語るのではなく、精を重んじる#

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

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

すぐにバグを見つけたと主張しない#

ソフトウェアを使用しているときに問題が発生した場合、あなたが非常に、非常に根拠がある場合を除いて、すぐにバグを見つけたと主張しないでください。ヒント：問題を解決するためのソースコードのパッチを提供できない限り、または以前のバージョンの回帰テストが不正確な動作を示さない限り、あなたはほとんど確信を持っていません。これはウェブページやファイルにも当てはまります。もしあなたが（バグを）発見したと主張するなら、あなたはその位置の修正や代替ファイルを提供できるべきです。

他の多くのユーザーがあなたが発見した問題に遭遇していないことを覚えておいてください。さもなければ、あなたは文書を読んだりウェブページを検索したりしているときにそれを発見していたはずです（あなたは不満を抱える前にこれを行ったのですよね？）。これは、あなたが間違っている可能性が高いことを意味します。

ソフトウェアを作成する人々は、できるだけ完璧にするために非常に苦労しています。もしあなたがバグを見つけたと主張するなら、それは彼らの能力を疑うことになります。たとえあなたが正しいとしても、彼らの一部の人々を冒犯する可能性があります。特に、あなたがタイトルにバグと叫んでいる場合は、特に注意が必要です。

質問する際には、たとえあなたが私的に本当にバグを見つけたと確信していても、あなたが何かを間違えたことを書くのが最善です。もし本当にバグがあるなら、あなたは返信の中でそれを目にするでしょう。これを行うことで、もし本当にバグがあれば、メンテナはあなたに謝罪するでしょう。これは、他の人を怒らせて謝罪を求めるよりも良い結果をもたらします。

謙虚に接することができるが、まずは調査を行う#

ある人々は、粗野または傲慢に質問するべきではないことを理解していますが、彼らは別の極端を選択します - 謙虚に接することです：私はただの悲しい新米で、失敗者ですが...。これは困惑させるだけでなく、特に実際の問題の曖昧な説明とともにあると、さらに不快です。

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

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

問題の症状を説明し、推測しない#

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

愚かな質問

私はカーネルをコンパイルしているときに連続して SIG11 エラーに遭遇しました。
どこかの飛び線がマザーボードの走行線に接触しているのではないかと思います。これをどうやって確認すればよいですか？

賢い質問

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

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

発生時系列に問題の症状を列挙する#

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

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

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

プロセスではなく目標を説明する#

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

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

愚かな質問

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

賢い質問

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

後者の質問方法は賢いものであり、別のより適切なツールを使用することをお勧めしますというような回答を得る可能性があります。

プライベートメールでの返信を求めない#

ハッカーは、問題の解決プロセスが公開され、透明であるべきだと考えています。このプロセスの中で、より経験豊富な人々が不完全または不適切な点に気づいた場合、最初の返信が修正されるべきです。同時に、助けを提供する側も他の同僚から能力や知識を認識されることで、何らかの報酬を得ることができます。

あなたがプライベートな返信を求めると、このプロセスと報酬は中断されます。そうしないでください。返信者にプライベートに回答するかどうかを決定させてください - もし彼が本当にそうした場合、通常は彼が問題の書き方が悪すぎるか、あまりにも表面的であると考えているからです。

このルールには限られた例外があります。もしあなたが質問が大量の同様の返信を引き起こす可能性があると確信している場合、この魔法の質問文は私にメールを送ってください。私はフォーラムにこれらの返信を要約しますです。メールリストやニュースグループを同じような返信の洪水から救おうとするのは非常に礼儀正しい行為です - しかし、あなたは約束を守る必要があります。

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

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

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

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

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

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

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

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

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

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

宿題の質問を投稿しない#

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

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

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

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

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

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

一般的に、はいまたはいいえ、正しいまたは間違っている、あるまたはないのような質問を避けるべきです。あなたがはいまたはいいえの回答を得たい場合を除いて。

急いでいる場合でも、タイトルに「緊急」と書かない#

これはあなたの問題であり、私たちの問題ではありません。「緊急」と宣言することは、逆効果になる可能性が高いです。ほとんどのハッカーは、無礼で自己中心的に即座に注意を引こうとする質問を直接削除します。さらに悪いことに、「緊急」という言葉（または他の注意を引こうとするタイトル）は、スパムフィルターによってフィルタリングされることがよくあります - あなたの問題を見たい人は、永遠にそれを見ることができないかもしれません。

半分の例外があります。もしあなたが非常に目立つ場所にいて、ハッカーたちを興奮させるようなことをしている場合、そうする価値があるかもしれません。この場合、もし時間的なプレッシャーがあるなら、それを礼儀正しく言及することが重要です。人々は、あなたが早く回答を得ることに興味を持つかもしれません。

もちろん、これは非常にリスクが高いです。なぜなら、ハッカーが興奮するポイントは、あなたのものとは異なることが多いからです。たとえば、NASA の国際宇宙ステーション（International Space Station）からこのようなタイトルを発信することは問題ありませんが、自分の気分が良い慈善行為や政治的理由で発信することは確実に問題です。実際、緊急：この毛むくじゃらのアザラシを救ってください！のような投稿は、ハッカーに無視されるか、彼らを怒らせることになります。たとえ彼らが毛むくじゃらのアザラシを重要だと考えていても。

もしあなたがこれが信じられないと思うなら、ガイドの残りの部分をもう一度読み返し、理解するまで投稿しないことをお勧めします。

礼儀正しさは重要であり、時には非常に役立つ#

礼儀正しく、お願いしますやご配慮ありがとうございます、またはあなたの助けに感謝しますなどの言葉を使ってください。人々に、彼らがあなたのために時間を費やして無料で助けてくれることに感謝していることを示してください。

率直に言って、この点は明確で正確、適切な文法を使用し、特定の形式を避けることよりも重要ではありません（また、これに取って代わることもできません）。ハッカーは、少し突っ込みがあるが技術的に明確なバグレポートを好むことが一般的であり、礼儀正だがあいまいなレポートを好むことはありません。（この点が理解できない場合は、私たちが問題が何を教えてくれるかに基づいて問題の価値を評価していることを思い出してください）

しかし、もしあなたが解決すべき問題のリストを持っている場合、礼儀正しさは有用な応答を得る可能性を高めるでしょう。

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

問題解決後、簡単な補足説明を加える#

問題が解決したら、あなたを助けてくれたすべての人に説明を送信し、問題がどのように解決された

原文バージョン履歴#

目次#

声明#

概要#