質問とは？
[ 551] 人力検索はてな - 質問一覧
[引用サイト] http://q.hatena.ne.jp/list
|
プロサッカー・Ｊリーグの試合について質問です。 各試合毎のスターティングメンバーは、いつ決定して発表されるのでしょうか？ カズの出場する試合を見にいきたいのですが、どうすればカズが出る試合を知ることが出来ますか？？.. 銅箔の厚さが30μのプリント基板で、パターンが幅1mm、長さ0.5mとした時に、周波数１MHzでのインピーダンスを求める時、どのようなプロセスで解いていけば良いのか分かりません。どなたか分かる方いらっしゃいましたら解説お願いできないでしょうか。.. 今日、公開の「HERO」のラストシーンで、キムタクが松たか子に、スペイン語で、確か、「君を離さない云々」と言ったのですが、そのスペイン語の文章をカタカナで教えて下さい。宜しくお願いします 大学で演劇をしているものですが、照明機材の修理について相談があります。 http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=1399%5EDX1220%5E%5E の型の調光ユニット（これと全く同じかは不明、形は酷似）を使っているのですが、修理に出す場合どうしたらよいでしょうか？ できるだけ早く、確実な、安いところを.. 私は今盛り上がっている “モバゲー”“モバオク”を試したことがありません。 �．皀丱押次Ε皀丱�クのここが面白い �▲皀丱押次Ε皀丱�クのここがつまらない・使いづらい �´△魎蔽韻任いい鵑� 教えて頂きたいです！ 歯間ブラシについて教えてください。最近年をとったせいか、歯に物がつまるので、使い始めました。気のせいか、ドラッグストアでもいろいろな種類が売られるようになって来ました。ところで、これを使うようになって、「歯間」自体がかえって広がった気がします。これは気のせいですか。それとも、実際にこうした弊害は起る.. 最近はPCと同じようにサイトを見れる スマートフォンを持つ方も増えたかと思います。 私自身は そのうち高校生や大学生もスマートフォンを もつようになる時代が来るかと考えています。 仮にそうだとした場合 果たして今後、 携帯のみのモバイルサイトはどうなっていくのでしょうか？？ あくまでモバイル勝負なのでしょうか.. プロスペックＤＶＥ７８３のフレームシンクロナイザーと画像修正機能はどんなノイズを修正できますか メーカー修理でＨＤＤを新品に交換したノートＰＣのＸＰ再インストールの不具合について： 購入時付属のリカバリーディスクで、ＸＰ−ＳＰ１がインストール済みです。 ＯＥＭ認証なのでプロダクトキー入力は要求されません。 その後、ＳＰ２更新プログラムを実施しましたが成功しません。 セーフモードで手動更新も試しまし.. Softcamというソフトなんですが、試用期間中はキャプチャしている動画に「Softcam」というロゴが出ます。 これを消したいのですが、支払いの方法がわかりません。 分かる方、よろしくお願いします。 テレビのアナウンサーの役割（例えば、バラエティー番組などで、どこまでがアナウンサーの仕事で、どこからがタレントの仕事なのかとか）について書かれているアナウンサーのブログなど知っていたら教えて下さい。 【http://end】 というURLを回答している人力検索の回答をたくさん教えてください。 ※ポイントあまり持っていないので乗っかってくださる方がいると嬉しいです。 入門程度にC++とCGIをかじったことがある私が、オンラインショップを作るために学ぶべき旬の言語は何でしょうか。 機能としては在庫数表示（登録管理）・カート機能・決済・自動返信メールの各機能があれば十分です。 現段階では、サーバーはFC2レンタルサーバーを使おうと思っています。もし「この言語で」というお勧めが.. 手紙について質問します。 ここ数年の間に、伝統的な日本風の手紙を受け取ったことがありますか。 その手紙について、どんな手紙だったのか、差し支えのない範囲で教えてください。 イメージは、縦書きで二重封筒に入って、拝啓あたりから始まり、時候のあいさつなどがきちんと書かれた手紙です。 なぜなら、私は手紙をよく.. 石川テレビ放送のカフェドシネマという番組でHEROの記者発表があり松たか子の穿いていた黒いロングスカートはなんとゆう名前でどんな店で売ってますか。 【回答拒否連鎖】 私は、自分が回答拒否されている質問(回答ボタンが灰色)の質問者すべてをＩＤを指定しての回答拒否者に設定しています。 このように設定することは合理的ではないことは充分理解していますが、 心情的には、自分の回答を拒否している人は自分の質問の回答者であってほしくないのです。 上で合理的でないと.. PHPでユーザーが入力した値が、サイトに反映するプログラムを制作しているのですが、"や*等の一部文字を入力すると、バックスラッシュ等が余計に付いてたり、消えてしまっていたりします。 どう対応すればよろしいでしょうか？.. 海外のＩＴ・ビジネス動向を紹介しているサイトを教えて下さい。 日本語、英語どちらでもかまいません。 【藤原ヒロシ（ＤＪ）】に関するトリビア情報を調べています。 例えば･･･ファンしか知らないような秘話・面白＆感動エピソード、その影響力・人気の凄さが分かるような話等々、聞いたら思わず『へぇ〜』と唸ってしまいそうな情報、宜しくお願いします!! .. |
[ 552] 賢い質問のしかた
[引用サイト] http://www.ranvis.com/articles/smart-questions.ja.html
|
他言語への翻訳については英語の原文を、原文の複写・翻訳・転載についてはCopying Policyを参照のこと。 多くのプロジェクトのウェブサイトがヘルプの項目からこのドキュメントにリンクを張っている。それは私達の意図した使い方なので構わない—しかしあなたがそのようなリンクをプロジェクトのページに追加しようとしているウェブ管理者ならば、リンクの傍らに目立つように、私達があなたのプロジェクトのサポート窓口ではないことを明示してほしい。 その注意書き無くしては、このドキュメントを公開したことで全世界の技術的問題を解決するのが私達の役目となると思い込む困った人達によって私達が再三苦しめられることになると、経験をもって学んだ。 もしあなたが助けを必要としてこのドキュメントを読んでいるならば、そして著者達から直接助けてもらえると感じて立ち去るのならば、あなたは問題の困った人達の一人である。私達に質問しないように。質問しても無視するだけである。このドキュメントはあなたの使用しているソフトウェアかハードウェアについて実際に知っている人から助けを得る方法について説明しているが、その人とは九割九分私達ではない。著者の一人があなたの使っているものの専門家であると確かに知っているのではない限り、私達を放っておいてほしい。そうすれば誰もが幸せになれる。 ハッカーの世界で技術的な質問に返ってくる答えの質は、回答の難しさだけではなく聞き方次第でもある。この手引きはあなたがより満足する回答を得られるような質問のしかたについて述べている。 今日オープンソースは広く使われている。あなたが良い回答を、他のあなたより経験のあるユーザーから得ることも、ハッカーからと同じくらい多くあるだろう。それは「いいこと」だ。ユーザーは一般に初心者が陥りやすい間違いについて多少寛容だろう。しかし経験を積んだユーザーをここで勧めるようなハッカーに対する作法で迎えることは、一般に有用な答えを得るための最も効果的な方法でもある。 最初に理解することは、ハッカーは本来難しい問題やそれについて考えさせる良い質問が好きだということだ。そうでなければ私達はここにいないだろう。私達はあなたが考えさせる興味深い質問をしてくれるならば、本当にありがたいと思う。良い質問は刺激であり贈り物なのだ。良い質問は私達の理解を深め、しばしばそのままでは私達が気づかなかったり考えもしなかった問題を明らかにしてくれる。ハッカーの間で「良い質問です」とは力のこもった心からの褒め言葉なのだ。 それにもかかわらず、ハッカー達は単純な質問に対し敵意や尊大さで応じているという評判がある。初心者や知識の無い人には反射的に無礼な態度を取っているように時には見えるかもしれない。しかし実際はそうではない。 悪びれずに言うならば、私達は質問をする前に、自分で考えたり下調べしたがらない人達に敵意を持っているのだ。そういう人達は時間を無駄にする—彼らは一方的に質問を行い、そして他のより興味深い質問や答えるに足る人に対して費やせた時間を無駄にする。このような人を私達は「敗者（losers, ルーザー）」と呼ぶ（そして歴史的な経緯でたまに「lusers」と綴る）。 単に私達の書いたソフトウェアを使いたいだけの人や、技術的な詳細について知ることに興味が無い人が多いことは知っている。大部分の人にとってコンピュータは単に道具、つまり目的を達成する手段であり、他により重要な事や生活があるのだ。私達はそれを知っており、私達を魅了する技術的な事柄に誰もが興味を持つとは期待していない。それにもかかわらず、私達の答え方はそのようなことに興味を持ち、かつ問題解決に積極的な参加者に向いている。それは変わることが無いだろうし変わるべきでもない。さもなければ私達は最善を尽くせなくなってしまう。 私達は（大部分が）ボランティアだ。忙しい時間の中から質問に答え、時にはそれに掛かり切りになる。そのため冷酷に質問を選別する。特に敗者でありそうな人の質問は、より効率良く「勝者」の質問に答えるために打ち捨てる。 もしこの態度を不快で恩着せがましい、もしくは傲慢であると思ったならば、その推測を検証してみてほしい。私達はあなたにひざまずけとは言っていない。それどころか私達の大部分は、あなた方が必要な努力を行うならば、あなた方を公平に扱い、私達の文化へ迎え入れることを何よりも好む。しかし自助努力を行いたがらない人を助けようとするのは私達にとって全く非効率的だ。無知であることは構わないが、馬鹿の振りをすることはよくないのだ。 だから私達の注意を引くために予め技術的な能力を持っている必要はない。能力に通じる類いの考え—注意深さ、思慮、観察力、解決策を見つけるための意欲的な協力者であろうとする姿勢—を見せる必要があるのだ。もしこのような待遇を受け入れられないならば、ハッカー達に個人的に手助けしてもらう代わりに誰かにお金を払い商業的なサポート契約を結ぶことをお勧めする。 私達に手助けを求めるならば、敗者の一人にならない方がいいし、そう見えないほうがいいだろう。迅速な答えを得る一番の方法は、知性と確信と見当を持った人が、ある特定の問題についてたまたま助けが必要になったかのように尋ねることだ。 （この手引きに関しての意見は歓迎する。提案はesr@thyrsus.comかrespond-auto@linuxmafia.com（原文の著者達のメールアドレス）まで送ってほしい。ただしこの文書は一般的なネチケットの手引きにするつもりはないので、技術的なフォーラムにおいて有益な回答を引きだすことに特に関係しない意見については基本的に却下する。） 質問をするときは、まずこれらを行ったという事実を提示する。それはあなたが人の時間を浪費する、怠け者のたかりではないということの証明になる。その結果学んだことを書くとより良いだろう。私達は回答から学べるということを実証した人に回答することが好きなのだ。 表示されたエラーメッセージは何でもGoogle検索を行うような戦略を取ろう（そしてウェブ検索だけでなくグループ検索も）。そうすれば質問に答えてくれるドキュメントやメーリングリストのスレッドに辿り着くかもしれない。もしそうならなくても、助けを求めるメールやニュースへの投稿をするときに「この語句を検索してみましたが期待できそうなページは見つかりませんでした」と書き添えるのは（どの語句の検索では役に立たないということが分かるだけでも）良いことだ。 時間をかけよう。数秒間Google検索するだけで複雑な問題を解決できるなどと思ってはいけない。専門家に持ちかける前にFAQを読み理解し、椅子にもたれリラックスして問題のことをしばらく考える。彼らは質問から、あなたがどれだけ読み、考えたかを量ることができるはずだし、心がけが見えればより助けたくなるはずだ。最初の検索で全く答えが見つからなかった（もしくは多すぎた）からといって、いきなり矢継ぎ早に質問を浴びせてはいけない。 質問の準備をしよう。問題についてよく考えてほしい。せっかちに見える質問にはそのような答えが、もしくは全く答えが返ってこない。助けを求める前に問題を解決しようと考察と努力を重ねたことを証明すればするほど、実際に助けが得られやすくなる。 間違った質問に気をつけよう。誤った仮定を元に質問をすると、必ずどこかのハッカーが「馬鹿な質問だな…」と考えながら無用なまでに字面通りに解釈した答えを返してくるだろう。あなたが、必要な答えではなく質問の答えを得ることで学習することを望んでいるからだ。 あなたが回答を得る資格があるとは絶対に思わないこと。そもそもサービスに対する対価を支払っていないのだから。回答を得るために、価値があり興味深く、示唆に富んだ質問をすることで、単に他人の知識を受け身で要求するのではなく、暗黙的にコミュニティーに貢献できるのだ。 一方、あなたが問題の解決法を探る過程を助けることができ、またそれを望んでいることを明確にするのはとても良いスタートだ。「どなたか助言はありますか？」、「私の例に足りないものはありますか？」、「どこか見ておくべきサイトはありますか？」と言うことは「私のするべき正確な手順を教えて下さい」と書くよりも答えを得やすいだろう。なぜなら誰かがただ正しい道筋を示してくれれば後は自力で解決するつもりであると明らかにしているのだから。 ハッカーはコミュニケーションの場が無関係な投稿で埋もれないように不適当な質問は無視する。あなたはそうされないようにすべきである。 そのため第一歩は正しいフォーラムを見つけることになる。再び、Google等のウェブ検索が助けになる。困難の元になっているハードウェアかソフトウェアに最もよく関連しているプロジェクトのウェブページを見つけよう。通常そのページにはFAQリストのページやプロジェクトのメーリングリスト、アーカイブへのリンクがある。メーリングリストはあなた自身の努力（見つけたFAQを読むことを含む）によって解決できなかった時に最後に助けを求める場所だ。プロジェクトページにはバグレポートの手順が述べられていたり、それに関するリンクがあるかもしれない。その時はそれに従おう。 どんなときでもあまり知らない人やフォーラムにメールを出すのは危険である。例えば、有益なウェブページを作っている人が無料の相談相手になりたがっていると思わないこと。あなたの質問が歓迎されるかどうか楽観的観測を行わないように。自信がないならば、どこか他の場所に送るか、いっそ送ることを止めよう。 ウェブフォーラムやニュースグループ、メーリングリストを選ぶときは、そのタイトルだけを信用しすぎることなく、FAQや注意書き（charter, 憲章）を探してあなたの質問が正しい話題か確認すること。投稿前に最近のログを読んでその場の雰囲気を掴もう。実際、投稿前にそのニュースグループやメーリングリストのアーカイブ内を検索するのはとても良い考えだ。答えが見つかるかもしれないし、見つからなくてもより良い質問をする手助けになるだろう。 あなたの話題が何かを把握すること。典型的な間違いはUnixやWindowsのプログラミングインターフェースについて、両方の環境で利用できるプログラミング言語やライブラリ、ツールに関するフォーラムで尋ねてしまうことだ。何故これが間違いなのか分からないうちは何も質問しないほうが良いだろう。 一般に、十分に厳選した有名なフォーラムの方が私的なフォーラムよりも有益な回答が得られる傾向がある。理由はいくつかあるが、一つは単に潜在的な回答者の数、そしてもう一つは読者の数だ。ハッカーは数人よりも多くの人に教えられる質問に答えたがる。 当然だが、技術のあるハッカーや有名なソフトウェアの作者は既に相当量の見当外れのメッセージを受け取っている。その殺到に加わることで、極端な場合あなたは彼らに決定打をあたえてしまうかもしれない。しばしば、有名なプロジェクトに寄与してきた人達が個人的なメールアカウントに届く無用なメールという二次的な被害に耐えられなくなりサポートを取りやめている。 あなたの地元のユーザーグループやLinuxディストリビューションは、初心者が質問するためのウェブフォーラムやIRCチャンネルを宣伝しているかもしれない（非英語圏ではまだ初心者向けの場はメーリングリストが多いかもしれない）。これらは最初に質問する場所として、とりわけ単純そうだったり一般的そうな問題につまずいた時には適しているだろう。自ら宣伝しているIRCチャンネルは質問が来るのを待っており、しばしば即座に回答が得られる。 実際（近ごろは一般的になった）Linuxディストリビューションに含まれているプログラムで問題を抱えているならば、そのプログラムのプロジェクトのフォーラムやリストよりも前にそのディストロのフォーラムやリストで質問したほうが良いだろう。プロジェクトのハッカーは単に「私達のビルドを使って下さい」と言うかもしれないからだ。 ウェブフォーラムに投稿する前には、検索機能がついているか確認しよう。もしあるならば、二三のキーワードであなたの問題に似た事例を検索してみることはきっと役立つはずだ。もし普通のウェブ検索をした上だとしても（そうでなくてはならないが）、とにかくフォーラム内を検索してほしい。ウェブの検索エンジンはフォーラム全体のインデックス化を最近していなかったかもしれないからだ。 メールのやりとりが開発者寄りになるにつれ、プロジェクトのサポートはウェブフォーラムやIRCチャンネルで行われる傾向がある。プロジェクト固有の助けが必要な時は、まずそちらを探そう。 プロジェクトに開発者によるメーリングリストがあるときは、たとえ開発者個人が一番よく答えることができると思ってもそのメーリングリストに投稿しよう。プロジェクトのドキュメントやホームページでメーリングリストのアドレスを確認してそこへ宛てる。この手段を取るのにはいくつかの道理にかなった理由がある。 一人の開発者に尋ねるに足るほど良い質問ならばグループ全体にとっても価値があるはずだ。逆に質問がメーリングリストに投稿するには馬鹿げているのではないかと思える場合でも、それが開発者個人を悩ませる口実にはならない。 リストで質問することで負担を開発者達の間で分散できる。開発者個人は（特にプロジェクトリーダーの場合）忙しくて質問に答えられないかもしれない。 多くのメーリングリストはアーカイブされ、検索エンジンによってインデックス化される。あなたがリストで質問をして回答されると、将来の質問者が再びその質問をする代わりに、あなたの質問とその回答をウェブで見つけることができる。 もし特定の質問が頻繁にされるようならば、開発者はその情報を元にドキュメントやソフトウェア自体を分かりやすく改善することができる。しかしもしこれらの質問が個人的に行われたならば、だれも最も頻繁にある質問の全体像を把握することができない。 もしプロジェクトのメーリングリストやウェブフォーラムに「ユーザー向け」と「開発者向け」（または「ハッカー向け」）の両方があり、あなたがコードをハックしているのでなければ、「ユーザー向け」のリスト／フォーラムに質問しよう。開発者のリストで歓迎されると思ってはいけない。彼らは開発者間のやりとりを混乱させるノイズだと感じるだろう。 ただしもし質問が確かに些細なことではなく、「ユーザー」のリスト／フォーラムで数日待っても回答が得られないならば、「開発者」側に出してみよう。投稿の前に二三日潜んで（いわゆるROM）そこの習慣を掴むのが懸命だろう（実際これはどんな私的・半私的なリストにも当てはまる良いアドバイスである）。 もしプロジェクトのメーリングリストのアドレスを発見できず、管理者のメールアドレスしか見当たらなかった場合はその人にメールしてみよう。しかしその場合でもメーリングリストが無いと思い込んではいけない。メールにはメーリングリストを探したけれども適切なものが見つからなかったことに言及する。また、あなたのメッセージを他の人に転送しても構わないと書いておこう。（多くの人はたとえ何も秘密が書かれていなくてもメールは公開するべきではないと思っている。転送の許可をすることで送信者にあなたのメールをどのように扱うか選択の余地を与えることができるのだ。） メーリングリストやニュースグループ、ウェブフォーラムにおいて、件名はたかだか50文字で適任の専門家の注意を引ける絶好の機会だ。「助けて下さい」等の無駄口で浪費しないように。（もちろん「助けて下さい！！！」は言うまでもない。そのような件名のメッセージは反射的に放置される。）件名で自分の苦悩を印象づけようとせず、代わりに簡潔な問題の説明に利用しよう。 多くのテクニカルサポートで使われる良い件名の形式は「対象 - 逸脱」である。「対象」の部分はどの事柄や分野の問題かを明記し、「逸脱」の部分は期待した振るまいからの逸脱を明記する。 「対象 - 逸脱」形式で書くことは問題についてより詳細に考えを整理する助けになる。何が影響を受けているのか？ マウスカーソルだけなのか、他の画像もなのか？ これはX.orgのX固有の問題なのか？ それもバージョン6.8.1に？ Foowareのビデオカード固有なのか？ それもMV1005に？ 結果を見たハッカーは一瞥しただけで即座に何に問題があるかとあなたが抱えている問題とを理解することができる。 もっと一般的に言うと、質問の件名が並ぶアーカイブの目次を見ることを想像してほしい。後であなたと似た質問を持った人が再び投稿しないでもアーカイブを探せば答えを見つけられるように内容を件名に十分反映させる。 もし返信で質問を行うときは、件名であなたが質問をしていることを示そう。「Re: テスト」や「Re: 新しいバグ」のような件名は有効な注意を得にくいものだ。また、前のメッセージの引用は新しい読者に配慮しつつ最小限に削るようにしよう。 完全に新しいスレッドを開始する際に絶対に返信を押さないように。メッセージの読み手を減らすことになる。Muttなどいくつかのメーラはメッセージをスレッド別に畳んで並べることができる。そうしている人にはあなたのメッセージが見えないことになってしまう。 件名を変えるだけでは十分ではない。Muttやおそらくは他のメーラは件名ではなくメールヘッダの他の情報を元にスレッドに並べるからだ。代わりに完全に新しいメールを作成しよう。 一方ウェブフォーラムでは良しとされる習慣が少し異なる。なぜなら通常メッセージはより強く議論のスレッドに結びついており、しばしばスレッドの外からは見えないからだ。返信で質問をするときに件名を変えることはさほど重要ではない。返信に違う件名が付けられるとは限らない上、付けてもほとんど誰も読まない。しかし返信で質問をすること自体が、スレッドを読んでいる人にしかわからないために疑問のある習慣なのだ。そのためそのスレッドを現在読んでいる人達だけに聞きたいのでないかぎり、新しいスレッドを作ろう。 「返信は××まで送って下さい」で締めた質問はかなり回答を得にくくなる。もしあなたが正しいReply-Toヘッダを付ける数秒の手間もかけられないならば、私達があなたの問題について何秒も考えられるわけがないのだ。もしメーラがそのヘッダを追加できないならば、別のメーラを使おう。あなたのOSで動作するメーラにそのようなものがないならば、別のOSを使おう。 ウェブフォーラムでは、メールで返事を求めることは完璧に不作法である—あなたがその情報がデリケートなものであると（そして誰かが何らかの不明な理由によりその情報をフォーラムのあなた以外の人達に知らせたくないと）確信しているのでない限りは。もし誰かがスレッドに返信した時にメールでその内容を通知して欲しいのならば、ウェブフォーラムの機能を使おう。そのような機能は大抵のフォーラムで、「スレッドを購読」や「スレッドに投稿されたらメールで通知」のようなオプションとして用意されている。 私達は経験的に、不注意でだらしのない人は大抵考えることやコーディングもだらしがないと知っている（賭けてもいいくらい、とにかくよくある）。そのような人の質問には答える甲斐がないので、他のことに時間を使うだろう。 そのためあなたの質問を明確に充分説明することは大切だ。そのような手間が掛けられないならば、私達も注意を払わない。言葉を洗練させるためにさらに時間をかけるように。堅苦しく、形式張る必要はない—実際ハッカーの文化は正確に使われた くだけてスラング混じりのユーモラスな言葉を重んじる。しかし正確である必要がある。あなたに頭を使っていて注意を払っているという証がなくてはならない。 正しく綴り、句読点を正しく付け、大文字小文字を正しく書こう。「its」と「it's」、「loose」と「lose」、「discrete」と「discreet」を混同させないように。全てを大文字で書かないこと。怒鳴っているように読め、失礼と判断される。（全てを小文字で書くのは読みにくいので、大文字より若干煩わしくないだけである。Alan Cox氏ならば黙認されるが、あなたではそうならない。） よってメッセンジャーで使うような省略をしてはいけない。youをほんの2文字省いてuと書くだけであなたはそのような間抜けのように見られる。より悪いのはハッカーを気取った子供っぽい書き方は命取りであり、返ってくるのは冷たい沈黙（もしくは、良くて山ほどの軽蔑と皮肉）だろう。 自分の母国語ではないフォーラムで質問をするのならば、ある程度の綴りや文法間違いはあるだろう—しかしだからといって普段より不精にはならない（普通その違いは見抜くことができる）。また回答者の使う言語が分からないならば英語で書こう。忙しいハッカーは読めない言葉で書かれた質問を単に流しがちだし、英語はインターネットで実際に使われている言語なのだ。英語で書くことで質問が読まれずに捨てられる可能性を最小限にすることができる。 MIMEエンコードの添付ファイルは普通は構わない。ただし、単にメールクライアントによって自動的に作られたもの（同じメッセージのコピー等）ではなく実際の内容（ソースファイルやパッチ）がある場合だけである。 段落中が無改行のメールを送ってはいけない（メッセージの一部に対して返信するのがとても難しくなる）。回答者が横幅80文字の画面で読んでいると考え、80文字未満で適宜改行するように。 しかし、絶対にデータ（ログファイルのダンプやセッションの記録等）は固定幅で折り返さないように。回答者があなたと同じデータを見ていると確信するために、ありのままで含めなければならない。 英語のフォーラムにMIME Quoted-Printable形式で送らないように。ASCIIでは表現できない言語ではこのエンコーディングは必要なこともあるが、多くのメーラはそれをサポートしておらず、文章全体に=20という記号がまき散らされて見苦しく混乱させることに—もしくは文章の意味合いを変えてしまうことになる。 Microsoft WordやExcel等の閉鎖的で独占的な文書形式をハッカーが読めるとは絶対に思わないこと。大部分のハッカーはこれらの形式に対して、玄関の段に捨てられた湯気を立てている豚の厩肥の山と同じような反応をする。対処できるときでも、そうさせられたことに憤るのだ。 Windowsからメールを送るならば、Microsoftのおせっかいな「引用符の変換」機能を切ろう。そうすればメールにゴミ文字をまき散らさずにすむ。 ウェブフォーラムでは、「顔文字」や「HTML」機能を（もし用意されているなら）多用しないこと。1つか2つの顔文字は普通大丈夫だが、色つきの装飾的な文字はあなたが間抜けだと思われがちになる。顔文字や色や書体の乱用はあなたが煩く笑う十代の少女であるかのように見せる。一般的にあなたが回答よりも性的なことの方に興味があるのでない限り、良い手ではない。 もしあなたがNetscape MessangerやMS OutlookのようなGUIのメールクライアントを使っているならば、標準設定のまま使うことでこれらのルールを破ることになるかもしれないので気をつけてほしい。そのようなクライアントには大抵、メニューに「ソースを表示」コマンドがある。送信済みメールフォルダのメールをこれでチェックしてあなたが不要なごみを添付せずにテキスト形式でメールを送っているか確認するように。 発生する環境（マシン、OS、アプリケーション等何でも）について書こう。ベンダーのディストリビューションとリリースレベル（「Fedora Core 4」や「Slackware 9.1」等）の情報も。 Simon Tatham氏が効果的にバグを報告するにはという優れたエッセイを書いている。一読することを強く勧める。 正確かつ有益である必要があるが、単に大量のコードやデータを質問に突っ込むことではこの結果は得られない。もしプログラムを動かなくする巨大で複雑なテストケースがあるならば、可能な限りその量を小さく削減しようとしてほしい。 これには少なくとも三つの役立つ理由がある。一つ目は質問を単純にする努力を見せることで答えが得られやすくなるから。二つ目は質問を単純にすることで有益な答えが得られやすくなるから。三つ目はバグレポートを洗練させる過程で解決策や回避策を自分自身で発見できるかもしれないからだ。 使っているソフトウェアの一部に問題が出たとき、本当に確かな根拠がない限りはバグを見つけたと報告するべきではない。ヒント：問題を解決できるソースコードのパッチをあなたが提供できるか、前のバージョンに対してリグレッションテストを行って不適当な振る舞いを証明できるのでない限りは、おそらく十分ではないだろう。ウェブページやドキュメントにも当てはまる。ドキュメントの「バグ」を見つけたら、代わりの文章を用意し、それがどこの文なのか示すべきだ。 他の多くのユーザーはその問題を体験していないことも忘れてはいけない。さもなければあなたはドキュメントを読むか、ウェブを検索した時にそれについて知っているはずだ（その問題を訴える前にそうしたでしょう？）。つまり何か間違ったことをしているのはソフトウェアではなく、きっとあなたなのだ。 ソフトウェアを書いている人達はそれを可能な限り正しく動作させるために非常に苦労している。もしあなたがバグを見つけたと主張したら、彼らの力量に疑問を示すことになり、たとえあなたが正しいとしても一部の人達の気を損ねるかもしれない。特に「バグ」と件名に書き立てることは得策とは言えない。 質問するときは、たとえ実際にバグを発見してしまったと確信していてもあなたが何か間違ったことをしてしまったと仮定するのが最良だ。もし本当にバグがあったのならば、そのような回答があるだろう。そのように振る舞うことで、あなたの勘違いで謝罪することになる代わりに、バグが実際にあった場合に責任者が謝るかもしれない。 一部の回答が欲しい人達は、失礼に、もしくは傲慢に振る舞うべきではないと理解すると、今度は逆に極端に卑下しだす。「哀れな敗者の初心者ですが…」これは気を散らすものであり役に立たない。特に実際の問題が漠然としていると鬱陶しいものだ。 あなたや私達の時間を露骨な霊長類の駆け引きで無駄にしないように。代わりに背景的な事実やあなたの疑問を可能な限り明確に示してほしい。それが卑下するよりもよい立ち回り方なのだ。 ウェブフォーラムには初心者の質問用の場が設けられている場合がある。もし初心者の質問だと思うならば、そちらへ行くように。ただしそこでも媚びてはいけない。 問題についてあなたの考えた原因をハッカーに教えることは役立たない。（あなたの診断の理論が並外れたものならば他の人の相談にのっているはずでしょう？）だからあなたの解釈と理論ではなく、必ずうまく行かない症状をそのまま伝えるようにする。解釈と診断は彼らに任せよう。もし推測を述べるのが重要だと思ったら、推測であるとはっきりと言い、何故その考えが上手くいっていないのか書こう。 カーネルをコンパイルしようとするとSIG11が必ず出ます。マザーボード上の信号線の一つの細いキズが原因ではないかと思うのですが、確認するにはどうしたらいいでしょうか？ 自作機（K6/233+FIC-PA2007(VIA Apollo VP2 chipset)+256MB Corsair PC133 SDRAM）が電源を入れて約20分経つと、カーネルのコンパイル中によくSIG11エラーを起こすようになりました。最初の20分には起こりません。再起動させても駄目ですが、一晩電源を切ると元に戻ります。RAMを交換しても解決できませんでした。関係する部分の主なコンパイルセッションログは次の通りです。 前述の例は多くの人に把握しにくいようなので、これを知っておいて欲しい：「診断する人は皆ミズーリ州から来ている」 アメリカのこの州の公式な標語は「見せてくれ」だ。（1899年に議員のWillard D. Vandiverが「私はトウモロコシと綿花とオナモミと民主主義を育てている州から来た。口先だけでは納得も満足もしない。私はミズーリから来た。証拠を見せてくれ。」と発言したことによる。）診断する人の場合は、懐疑ではなくむしろ文字通り診断のために、推測や要約ではなくあなたが見た形跡にできるだけ近いものを見る必要があるということだ。私達に見せてほしい。 うまく行かない原因を探るために最も役立つ手がかりは、多くの場合その直前の出来事にある。そのためあなたは正確に、駄目になるまでにあなたとあなたのマシンがした事を説明しなくてはならない。コマンドラインの手順ならばセッションログを（例えばスクリプトユーティリティを使って）残し、20行程度の関係する部分を引用するととても役立つ。 もしそのプログラムに診断するためのオプション（verboseモードの-v等）がいくつかあるなら、有用なデバッグ情報を記録に付け加えるオプションを選んでみてほしい。ただしそれが多いほうが良いとは限らない。読者をゴミ漬けにせずに情報を伝えられるデバッグレベルを選び出そう。 もしあなたの説明が長く（大体4段落以上に）なってしまったならば、最初に問題を簡潔に示し、そして時間に沿った話を続けるのが有効かもしれない。そうすればハッカーはあなたの説明を読む上で何に気をつけるべきか判るだろう。 もし（バグレポートとは反対に）何かをするための方法を見つけようとしているならば、まず目的を説明しよう。そしてその後にそのために行き詰まっている特定の過程を説明する。 多くの場合、技術的な手助けが必要な人は高度な目的を持ち、そのために特有と思っている進路でつまずく。その手順について助けを求めるが、進路が間違っていることには気づかない。その方法では次の手順に進むのに相当な努力を必要とするかもしれないのだ。 画像のカラーテーブルを好きな値に置き換えようとしています。今のところそのためにはテーブルの各値を編集する事しか思いつかないのですが、FooDrawのカラーピッカーで16進数のRGB値を得ることができません。 ハッカーは問題の解決は公にされるべきと思っている。最初に回答してみてからの過程を透明にすることで、より知識のある人がそれが不完全であったり間違っていることに気づいて正すことができるように、また正されるべきであると考えているのだ。そして回答者になることで、彼らは仲間から有能で知識があると見られるという対価をいくらか得ることになる。 私的な返事を求めることは過程と対価の両方を崩壊させてしまう。個人的に返信するか決めるのは回答者の権限である—また回答者が仮にそうしたとしても、通常それは質問があまりに不適格か明らかなため他の人が感心を持たないと思ったからなのだ。 この規則には限定的に例外がある。もしあなたがその質問に対して良く似た回答が大量に返ってきそうだと思うならば、「私にメールを送って下さい。後で回答のサマリーを投稿します。」という魔法の言葉が使える。メーリングリストやニュースグループを概ね似たような投稿の殺到で埋めないようにすることは思いやりのあることだ—しかし要約を投稿するという約束は守らなくてはいけない。 決まった回答の無い質問は時間を限りなく無駄にすると考えられがちだ。最も役立つ回答をくれそうな人は（彼ら自身が多くの仕事を引き受けているというだけでも）最も忙しい人でもあるのだ。そのような人達は時間の果てしない無駄が嫌いなので、決まった回答の無い質問が嫌いな傾向がある。 あなたが回答者に何をしてほしいか明確にすると（ポインタを示す、コードを送る、方針を確認してもらう等）、回答がより得られやすくなる。これは彼らの労力を一点に集中させ、回答者があなたを助けるために割かなければならない時間とエネルギーの限度を暗に設定するので良いことなのだ。 専門家の世界を理解するには専門的知識を豊富な資源と考え、回答の時間を不足した資源と考える。あなたが暗につぎ込むことを要求している時間が少なければ少ないほど、非常に優秀で忙しい人から答えが得られやすくなる。 そのためあなたの質問を専門家がさばくのに要求される時間が少なくなるように質問を組み立てるのは有効だ—しかしこれは大抵質問を単純にすることと同義ではない。そのため、例えば「Xについての適当な解説のあるポインタを示していただけますか？」というのは通常「Xについて説明していただけますか？」よりもよい質問である。もし動かないコードがあるならば、普通はどこが悪いのか説明してもらうほうが直してもらうよりは良いだろう。 どのような問題を知りたいのか手掛かりを示さずに、あなたの滅茶苦茶なソースコードをデバッグさせようとしてはいけない。何百行かのコードを書いて「動きません」と言っても無視されるだろう。10行程度のコードと「7行目の後で『X』になるはずなのに『Y』になってしまいます」の方が返事を得やすい。 単にコードを検証してもらいたいなら予めそう言っておき、特に調べて欲しい個所とその理由を必ず述べること。 ハッカーは宿題の問題であることを見抜くのが得意だ。私達のほとんどはそれを自分でやってきたのだから。それらの問題はあなたが解いて、その経験から学ぶためのものである。ヒントを求めるのは構わないが、完全な解答を求めてはいけない。 もし宿題の問題を投稿してしまったのではないかと思い、しかしいずれにせよ解決できないならば、ユーザーグループのフォーラムか（最後の手段として）「ユーザー向け」リスト／フォーラムに投稿してみよう。ハッカーはそれを見抜くが、技術のあるユーザーは少なくともヒントをくれるかもしれない。 あなたのお願いを「誰か助けてくださいますか？」や「何か答えがありますか？」のような意味のない問い掛けで終える誘惑は我慢しよう。第一に、もしあなたが問題の説明を多少なりとも有能に書き終えたなら、そのような付け加えはせいぜい余計なだけだ。第二に、余計なものなのでハッカーはうるさく感じる—そして論理的に申し分の無い、しかし軽蔑的な答え「はい、助けてもらえるでしょう。」や「いいえ、誰も助けてくれませんよ。」を返すかもしれない。 それはあなたの問題であり、私達の問題ではない。急ぐことを主張するのは逆効果になるだろう。大部分のハッカーはそのようなメッセージを失礼な、即座に特別な注意引くための自分勝手な策として単に削除する。 これにはいくらか例外はある。もしあなたがそのプログラムをどこか注目を浴びる場所で使っていて、あなたがハッカーを興奮させる人物ならば、そのことに触れる価値はあるかもしれない。その場合、もし時間を急いでおりそのことを礼儀正しく持ち出すなら、興味をもってもらい素早く答えてくれるかもしれない。 しかしこれを実行するのは危険である。なぜならハッカーが何に興奮するかという基準はおそらくあなたのものとは異なるからだ。例えば国際宇宙ステーションから投稿するのならばその資格があるが、良い気分にさせる慈善運動や政治運動のためというのは間違いなく駄目だ。実際「【緊急】ふわふわの赤ちゃんアザラシを救って！」という投稿をすることはふわふわの赤ちゃんアザラシの保護が大事だと考えているハッカーからさえも、必ず避けられるか非難されるだろう。 もしこれが不思議に思えるならば、何かを投稿する前にこのHow Toを理解するまで繰り返し読むように。 正直なところ、これは正しい文法で明確・正確かつ記述的にする程は重要でない（そしてそれに代えることはできない）。ハッカーは洗練された曖昧な文より、いくぶんぞんざいでも技術的にはっきりしたバグレポートを喜ぶ。（もしこれに戸惑うのならば、私達は質問をそれが何を教えてくれるかで評価することを思い出してほしい。） （このHow Toに対してベテランハッカー達から唯一受けた重大な反論として、前出の勧めに対する敬意と共に「Thanks in advance」は使うべきではないと指摘されたことに言及するべきだろう。ハッカーの中にはこれは後で感謝しないということを述べていると感じる人もいる。私達は「Thanks in advance」と最初に書いた上で回答者にお礼を言うか、別の方法、例えば「Thanks for your attention」や「Thanks for your consideration」と書くことで礼儀を尽くすことを勧める。） 問題が解決したらあなたを助けてくれた人全員に一筆書いて、それがどうなったかを知らせもう一度お礼を言おう。もしその問題がメーリングリストやニュースグループで一般的な関心を引いたら、そこに返信するのが適当である。 返信は元の質問のスレッドに対して、「解決」等の明確な印を付けるのが好ましい。流れの速いメーリングリストにおいて回答者になりそうな人が「問題X」のスレッドが「問題X - 解決しました」で終わっているのを見ればスレッドを読む時間さえも（問題Xに興味を持たない場合は）無駄にせずにすみ、そのため他の問題を解決するためにその時間を使うことができる。 あなたの返信は長く複雑である必要はない。簡単な「どうも—ネットワークケーブルが切れていました！ 皆さんありがとうございました。 - Bill」でもなにもないよりもマシだ。それどころか、解決策に実際の技術的な深みがない限りは、長い学術論文よりも簡潔なサマリーのほうが良いだろう。何をしたら問題が解決したかを書くように。しかし一連のトラブルシューティング全体を再現する必要はない。 いくらか高度な問題には、トラブルシューティングの履歴を投稿することが適切である。問題の最終的な症状を説明し、なにが解決策になったか、そしてその後に回避可能な袋小路を示す。袋小路は正しい解決策や他のサマリー要素の後に続けるべきであり、返信を推理小説に仕立てるべきではない。あなたを助けてくれた人達の名前を挙げれば彼らと親しくなるだろう。 この種の返信は礼儀正しく有益である上、メーリングリスト・ニュースグループ・フォーラムのアーカイブを検索している人があなたがどういう方法で解決したかを知らせるのに役立ち、従って彼らの助けになるかもしれない。 最後に、この種の返信は少なからず手伝ってくれた人達全員に問題が終わったことの満足感を与えることができる。あなた自身が技術者やハッカーではなかったら、この感覚があなたが助けを求めた達人や専門家達にとって大変に重要だということを信用してほしい。問題という物語が未解決の無へと帰していくのは苛立たしいことで、ハッカーはそれらが解決するのを見たくてうずうずしている。その衝動を解決してあげることは、次に質問をするときに大変役に立つだろう。 将来他の人があなたと同じ問題を持たないようにするにはどうすれば良いか考えよう。ドキュメントやFAQが助けになるか自問してみて、なりそうならばそのパッチを管理者に送る。 ハッカーの間では、この種の良い返信の作法は型にはまった礼儀よりも実は大事なことなのだ。それによってあなたが他の人達とうまくやっているという評判を得ることができる。それは実に貴重な財産になりうるだろう。 一つ神聖な流儀がある。もし「RTFM」と書いてある返信を受け取ったら、送信者はあなたがマニュアルを読んでおくべきだと思っている。それは大抵間違いなく正しいのでマニュアルを読もう。 RTFMには弟がいる。もし「STFW」と書いてある返信を受け取ったら、送信者はあなたがウェブを検索しておくべきだと思っている。それは大抵間違いなく正しいのでウェブを検索しよう。（より穏やかな返信では「Googleで見つかります」となる。） ウェブフォーラムではフォーラムのアーカイブを検索するように言われるかもしれない。それどころか、誰かが以前その問題を解決した時のスレッドのポインタを示してくれるかもしれない。しかしこの予想を当てにしてはいけない。聞く前にまず自分でアーカイブを検索しよう。 検索しろと言う人は多くの場合、あなたの必要としている情報が載ったマニュアルやウェブページを開いている。そしてそれを見ながらタイプしているのだ。これらの返信は(a)その情報は見つけるのが簡単であることと、(b)自分で探せば単にそれを教えてもらうよりもより多くの情報を学べると送信者が考えていることを意味する。 腹を立てるべきではない。ハッカーの基準では、回答者はあなたを無視しないことである種のおおざっぱな敬意を表しているのだ。あなたは代わりにその祖母のような優しさをありがたく思うべきなのだ。 もし回答がわからないときも、すぐに説明を求める返信をしてはいけない。回答を理解するために前と同じツールを使い、元の質問（マニュアル、FAQ、ウェブ、詳しい友人）に答えようとしてみよう。もしそれでも説明が必要ならば、あなたの学んだことを提示しよう。 例えば、私があなたに「zentryが詰まっているようです。クリアすればいいでしょう。」と教えたとする。その場合、悪い返信の質問は：「zentryって何でしょうか？」であり、良い返信の質問は：「man pageを読みましたがzentryは-zと-pオプションでしか説明されていませんでした。どちらもzentryのクリアについては書かれていません。このどちらかでしょうか、それとも私が何か見逃しているのでしょうか？」となる。 ハッカーの世界で乱暴な表現に見えるものは大概、怒らせるためのものではない。問題の解決により感心のある人達にとって、むしろそれは他人の心を暖かく曖昧にさせるよりも自然な直接的コミュニケーション法なのだ。 無礼という気がしても冷静に対処しようとすること。もし誰かが本当にそう振る舞っているならば、リストやニュースグループ、フォーラムの古参の参加者がその人を注意するだろう。もしそうならずにあなたが腹を立てると、その人物の行為はハッカーコミュニティの規範の範囲内であり、あなたに責任があると考えられてしまうだろう。それにより必要な情報や手助けを得られる可能性が減ってしまうのだ。 その一方で、いわれの無い失礼な目にあうことも時にはあるかもしれない。前出の逆として、真の無礼者を酷評し、鋭い言葉のナイフで徹底的に抉る態度も容認できる。しかしそうする前に基づく根拠を確固たるものにしよう。失礼な言葉を正す事は無益な罵り合いを始めてしまう事と紙一重で、ハッカー自身うっかりそうしてしまうこともしばしばあるのだ。初心者や門外漢だと、それを避けられる可能性は低くなる。娯楽よりも情報を求めるならば、この賭けをせずにキーボードから手を放していたほうが懸命である。 （一部の人は多くのハッカーが軽度の自閉症やアスペルガー症候群であり、実際に「正常な」人間社会の交流を行うための脳回路が欠落していると主張している。これは真実かもしれないし、そうでないかもしれない。もしあなた自身がハッカーではないならば、私達の脳に障害があると考えることでその奇行とうまく付きあう助けになるかもしれない。それは結構。私達はそれが何であれ現状が好きなので気にしないし、臨床的分類には概して健全な懐疑論を持っている。） たぶんあなたはハッカーコミュニティで数回—この記事が述べているかそれに似た様な—間違った事をするだろう。そしておそらくあなたは様々な脱線と共にどのような行動をしたかを正確に語られるのだ。人前で。 そうなったときにとる最も悪い行動は、その体験について愚痴を言うことだ。言葉の暴力を受けたと主張したり、謝ることを要求したり、叫ぶ、息を殺す、訴訟を起こすと脅す、相手の雇用主に文句を言う、便座を上げたままにする等々。その代わりにあなたがするべきこととは： 社会の規範はそれ自体ではなくそれを積極的に適用する目に見える普通の人達が維持する。批判は全て個人的なメールで伝えるべきだと愚痴を言わないでほしい。そういうものではない。また誰かがあなたの主張の一つが間違っていると意見したときに個人的に侮辱されたと、もしくは彼とは意見が違うと言い張ることが有効でもない。それは敗者の態度である。 以前、少々見当違いの礼儀を徹底し、参加者が他の投稿に対してあら探しをすることを禁止し、「ユーザーを助けたくないならば何も投稿しないで下さい」と指示しているハッカーのフォーラムがいくつかあった。しかし精通した参加者が他へ移ってしまった結果、意味のない雑談ばかりになり、技術的フォーラムとして用をなさないものに成り下がってしまった。 ハッカーが、あなたがの行動が間違っており二度とそうしないように言ったときは（それがどんなに荒々しくても）、彼は(1)あなたと(2)彼のコミュニティを心配して行動していることを心に留めておいてほしい。あなたを無視して生活から締め出す方が余程簡単なのだ。どうしても感謝できないならば、少なくとも品位を持って、愚痴らず、そしてあなたが演劇並に敏感な心と、権利があるという妄想を持つ新参者だからというだけで、脆い人形のように扱われることを期待しないようにしよう。 時には誰かが、あなたが何も失敗していない（あるいは唯一その人の頭の中以外では）にも関わらずあなたを個人的に攻撃したり、明確な理由なく非難したりするだろう。その時に不平を言うことは全く間違いである。 このような罵倒をするフレーマー達は根拠無く自分を専門家だと思い込んでいるアホウか、あなたがヘマをするか試している自称心理学者なのだ。他の読者は彼らを無視するか、自分で対処する方法を見つける。フレーマーの行いのツケは彼ら自身にまわる。それをあなたが心配する必要はない。 またフレーム合戦に身を投じようとしないこと。ほとんどのフレームは無視するのが一番だ—本当にフレームなのか、あなたの失敗に対する示唆でも、あなたの質問に対する巧妙に暗号化された答え（これもあり得る）でもないと確認した後で。 もしあなたがYをしたいのならば、適切でないかもしれない方法を取ることを仮定するべきではない。この形の質問は大抵、Xについて無知であるだけではなく解決すべきYという問題についてもはっきりしておらず、固有な状況の細部に固執していることを示している。一般にこのような人達は彼らが問題をよりうまく定義するまで無視するのが得策である。 これは質問ではない。私には、あなたの本当の質問を探るための20の質問にも興味はない—もっとマシなやることがある。このような質問を見た時、私の反応は通常以下のどれかである。 ええ。Microsoftは投げ捨ててLinuxやBSDのようなオープンソースのOSをインストールするように。 注：もしプログラムが公式にWindows版を用意しているか、Windowsマシンと共に動作する（つまりSamba）ならば、Windowsマシンに関する質問をすることができる。もっとも問題がプログラムではなくWindowsにあるという返事に驚かないように。Windowsはとても不安定なのでそういう事がよくあるのだ。 あなたが数十万の人々に使われているシステムコールやライブラリの明らかな欠陥を見つけた最初の人物である可能性もあるが、それよりもあなたが全くの無知である可能性が高いだろう。並外れた主張には並外れた証拠が必要になる。このような主張をするときは、明確かつ徹底的な欠陥の証拠資料で裏付けなくてはならない。 いいえ。解決するにはあなたのマシンを直接操作できる必要があるだろう。地元のLinuxユーザーグループに助けを求めるように。 注：Linuxのインストールに関する質問は、個別のディストリビューションのフォーラムやメーリングリストに対するもので、問題がそのディストリビューションに関係しているならば適当だろう。地元のLinuxユーザーグループでも同じである。その場合、必ず不具合の正確な詳細を述べる。もっとも最初に「linux」と全ての疑わしいハードウェアをキーワードに入念に検索してほしい。 最後に賢い質問のしかたを例を挙げて説明する。同じ問題に対する一対の質問で、一つは悪く一つは良いものである。 良い：Googleで「Foonly Flurbamatic 2600」を検索してみましたが有用なものが見つかりませんでした。この装置のプログラミングに関する情報を教えて頂けますか？ 良い：fooプロジェクトのコードがNulixバージョン6.2でコンパイルできません。FAQを読みましたがNulix関連の問題は書かれていませんでした。コンパイルしようとしたときの記録は次のようになっていますが、私が何かしたからでしょうか？ 質問者は環境を明記し、FAQを読み、エラー内容を示し、問題が誰か他の人のせいとは決めつけていない。この質問者はいくらか注意を引いてもらうに値する。 どこかのハッカーが「ああ、げっぷをさせたりおむつの交換も必要かい？」と打った後でデリートキーを叩くことだろう。 良い：マザーボードS2464でX、Y、Zをやってみました。動かなくなったときはA、B、Cを試しました。Cを試したときにおかしな症状がありました。明らかにflorbishがgrommickしているのですが結果は予想されるものではありませんでした。Athron MPマザーボードでgrommickする原因は通常なんでしょうか？どなたか問題を特定するためにできるテストの案をお持ちでしょうか？ 一方こちらは回答に値するように見える。答えが天から降ってくるのを待つ代わりに問題解決の思考力を示したのだ。 最後の質問の「答えを教えて下さい」と「問題を把握するために更にどのようなことを調べるべきか助言を下さい」との明確な違いに注意してほしい。 実のところ、最後の質問の形式は2001年8月にlinux-kernelメーリングリスト（lkml）へ投稿された質問を元にしている。私（Eric）がその時の質問者だった。Tyan S2462マザーボードに不可解なロックアップが起こったが、リストの参加者が問題の解決に重要な情報を提供してくれた。 私の場合のように質問することは人々に考えさせる題材を与える。彼らが関わることを容易に、そして魅力的にしたのだ。私は仲間の技量に対する尊敬を表し、仲間として助言を求めた。また、私が既に陥った袋小路を伝えることで彼らの時間の価値を慮っていることも示した。 その後皆に感謝し、解決までの過程がいかにスムーズに進んだか述べると、あるlkmlのメンバーは、うまく行ったのは私がリストで有名だからではなく適切な形で質問をしたからだろうと言った。 ハッカーはいくつかの面でとても冷酷な実力主義だ。彼の言ったことが正しいこと、またたかりのように振る舞っていたならば私が誰であろうと非難されるか無視されていた事は確かである。他の人のため事の顛末を手引きとしてまとめてはどうかという彼の提案がこのガイドを書くことに繋がった。 もし回答が得られなくても、私達が助けになれないと思ったからだと考えないように。時には質問したグループのメンバーが実際に答えを知らないかもしれない。確かに返答がないことと無視されることの違いを外側から見分けるのは難しいが、それらは同じではない。 一般に、質問を再投稿するのは悪い考えである。無駄に邪魔なものと見なされてしまうだろう。辛抱強く。質問に答えられる人は違う時間帯に居て、寝ているのかもしれない。あるいはそもそも質問の形式が不適切だったからかもしれない。 そのソフトウェアが大好きなオンラインの、または地元のユーザグループが（例え彼らがソフトウェアを書いたことがないかもしれないとしても）たくさんある。これらのグループは多くの場合お互いや新しいユーザーを助けられるように設けられている。 また助けてくれる商業的な会社が大小数多くある（Red HatとSpikeSourceは良く知られている2社だが、他にも多数ある）。少しの助けのためにお金を支払うという考えに狼狽しないでほしい。もし車のエンジンがヘッドガスケットを吹き飛ばしたら、おそらく修理工場に持っていき直してもらうために対価を支払うのだから。たとえソフトウェアが無料でも、サポートまで常に無料であることは期待できない。 Linuxのような人気のあるソフトウェアは開発者1人に対し最低10,000人のユーザーがいる。ひとりの人間が10,000人のサポート依頼を処理するのは全く不可能である。サポートにお金を払うことになっても、ソフトウェアまで購入しなくてはならなかった場合よりも相当小額であること（そしてクローズドソースのソフトウェアのサポートは通常、オープンソースのソフトウェアよりもより高額で役立ちにくいこと）を思い出してほしい。 寛大に。質問者は問題に関係したストレスによって実際にそうではない時でさえも、不作法な馬鹿に思えることがある。 初犯者には直接返信すること。純粋に間違えた人に公で恥をかかせる必要はない。本当の初心者はアーカイブの検索方法や、FAQがどこにあるか、どこに投稿するものかを知らなかったりする。 確かではないならそう言うように。間違っているのに信頼できそうに聞こえる回答は最悪なものだ。ただ専門家のように見られるのが楽しいからと間違った道を示さないように。謙虚かつ正直に、質問者とあなたの仲間双方に良い手本を示してほしい。 助けられないのなら邪魔をしないこと。ユーザーの環境を駄目にするような手順を冗談で書かないこと—正しい手順だと勘違いしてしまう人がいるかもしれない より詳しく聞きだすために厳密な質問をしよう。これを上手に行えば質問者は何かを学ぶ—もしかしたらあなたも。悪い質問を良いものにしようとすること。私達は皆最初は初心者だったことを忘れないでほしい。 誰かに回答するときにRTFMと呟くだけでは怠け者と見なされることもあるが、ドキュメントへのポインタは（それがGoogle検索するキーワードの提案だとしても）それよりよいものである。 もし質問に少しでも答えるならば、価値のあるものにしよう。誰かが間違ったツールや方法を取っているときに下手な回避方法を提案してはいけない。質問を再構成して良いツールを提案しよう。 あなたのコミュニティがその質問から学ぶ手助けをしよう。良い質問に答えるときは「関連するドキュメントやFAQをどう変更したらだれもこの質問に答える必要がなくなるか」と自問してみる。そしてドキュメントのパッチを管理者に送ろう。 質問に答えるために調査を行ったら、その事を元から知っていたように書くのではなくあなたの技術を説明してほしい。ある良い質問に答えることはお腹を空かせた人に一食与えるようなものだが、調査技術を例をもって教えることは生涯の食物を育てることを教えるようなものなのだ。 ソフトウェアを公開したりパッチを書く時はSoftware Release Practice HOWTOのガイドラインに従うようにしてほしい。 Evelyn Mitchell氏にはいくつか愚かな質問の例を送っていただき、また「良い回答のしかた」の節の着想を頂いた。Mikhail Ramendik氏からは改善にとりわけ貴重な助言を頂いた。 |