よく思うのが、

1. 何が
2. どうして
3. どうなった

という流れで質問すれば理解されやすいと感じます。

質問している人自身が理解してない場合、大抵は「どうなった」だけを言うので、原因を辿るまでに回答する側が右往左往する、理解しないのかと思います。

例：インターネットが壊れた

StackOverflow や Teratail といった不特定多数ユーザが集まる技術系 Q&A サイトを前提としておきます。（病院の例えはなるほどと思ったのですが、日常生活や社会生活におけるQ&Aではなく技術領域に範囲を絞った意見になります）

不特定多数のユーザから良い回答をもらうには下記が重要と思います。

• 1. コンテキストの共有：質問者が置かれている状況、問題解決にあたっての前提条件の説明
• 1. 大局的な目的の共有：最終的に／本当に解決したい問題の説明
• 1. 直接課題の説明：直接発生して困っている出来事の説明

1)適切なコンテキスト共有がなされないと、技術的には適切であっても質問者本人にとっては的外れな回答になる可能性が高まります。回答者は質問者が置かれている状況など知りようがありません。

2)最終ゴールの共有がされないと、「XY 問題」に陥る可能性があります。適切に提示されないかぎり、回答者は質問者が目指したい方向性を知ることはできません。

3)直接課題の説明がなされないと、単なる感想や意見表明になってしまいます。3)が無い質問なんてと思われるかもしれませんが、前掲サイトでは「質問」を含まない質問投稿もたまに見かけます。

過去に思うところがあり、「技術系Q&Aサイトのすゝめ」という記事を書いたりしました。

---

少しそれますが、個人的には「良い回答」にもレベルが存在すると思います。

• 1. 質問者の直接的な課題を解決する直接回答。
• 1. 上記に加えて、質問者が問題を深く理解できるような説明を含む回答。
• 1. 上記に加えて、多くのユーザにとって役立つ知識や詳細な解説を含む回答。

短期的には1)だけ有ればよいのですが、Q&Aサイトの存在意義としては3)まで到達すると素晴らしいでしょうね。（常にそうあるべきとは言いません）

@github0013@github
「何が」「どうして」「どうなった」という流れで質問すれば理解されやすい

5W1H と似た、状況の情報伝達ってやつですね。

インターネットが壊れた

うわー、わかる。「パソコンが壊れた」とか。

質問側も「どうしてこうなった」とお手上げでも、回答者も一緒に右往左往するしかないですものね。

@yohhoy
最終ゴールの共有がされないと、「XY 問題」に陥る可能性があります。

「XY 問題」はじめて耳にしました！ なるほどー、これは多いかも。「印刷できない」という問題に「このドライバであってますか？」みたいな質問をしたことがあります。

@yohhoy さんと重複するところが多いのですが… 明確な一つの回答を求める質問の場合は

• 何に困っているのか（何を解決したいのか）
• それはどういう状況で起きたのか
• 自分で何を試したか

の３点の事実を伝えるようにしています。

e.g.

• 咳が止まりません
• 三日前の夜から続いています
• のど飴を舐めてみたのですが改善しません

「たぶん風邪だと思うのですが…」というような憶測は質問相手の専門家を不機嫌にさせてしまう可能性が高いのと、不正確な情報は混乱の元なのでなるべく言わないようにしていますね。

@studio15
事実を伝えるようにしています。
「たぶん風邪だと思うのですが…」というような憶測は質問相手の専門家を不機嫌にさせてしまう可能性が高い

これは身に覚えがあります。質問にも書いた病院で、素人判断で「たぶん██だと思うのですが」と、まさにそれでした。何科に行けばいいのか分からず、ネット情報だけで判断・思い込みで行動していました。

問題も理解していないのに勝手に答えを考えてきて、答え合わせを求めてくるって、そりゃ先生もイラっとしますよね。

@Zuishin
teratail 公式の、「質問の仕方」について述べたドキュメントです。

そういうことですね。

Qiita Q&A にも、新規質問を作成すると以下のページへのリンクがありました。質問下手な人は、確認事項の確認も下手であるのかもしれません。

• 良い質問を書くためのガイドライン @ Qiita

QA って、本質は、質問側が回答者からヒアリングすることなんですが、そこをわかっていない方が多いように思います。

最初の質問が拙くても、会話によって回答を持っている方から回答を引き出せばいい。
なので、最初の質問は、回答を持っているであろう人が興味を持って、時間を割いてくれるようなものにすることが重要です。

リアルなら、「なぜこのタイミングで質問しようとしたか」とか、回答者側を巻き込むような枕があると回答者を巻き込みやすいです。

QA サイトであれば、タイトルが非常に重要ですね。
タグがあるのであれば、それも重要になってくると思います。

@te2ji
本質は、質問側が回答者からヒアリングすること
回答を持っているであろう人が興味を持って、時間を割いてくれるようなものにすること
タイトルが非常に重要

「時間を割いていただいている」という意識は大事ですよね。媚びへつらう必要はありませんが。

「重要！お急ぎください」みたいな「開かないとわからない」タイトルは悪質 DM や詐欺メールのタイトルと同じと感じていたのですが、それが「タイトルに収められない問題だから」という理由であれば、「問題を絞り切れていない」ということでもあると再認識しました。タイトル、重要。

@yohhoy さんの「XY 問題」についてのご指摘が非常に興味深かった。
この概念を知りませんでしたが，言われてみると確かに，回答側としても質問側としても身に覚えがありまくりです。

（私を含む人びとが）Y な質問をしてしまう背景として，本人なりに問題の所在を最小化・局所化しようとしたとか，回答者の負担を減らそうとした，といったこともあると思います（まあ裏目に出ているわけですが）。

あと，いろいろ努力してうまくいかず困り果てているときって，そもそも何のために何をやろうとしてどういう経緯でどうなって今に至っているかが把握できてなかったりしますよね。

ハイキング中に倒れている人を発見して，すぐに救急に電話しなくちゃ，でも電波が届いてない，よし急いで下山だ，アンテナマークを確認しながら駆け降りて，どうにか 1 本立つところまで来たら，携帯の電池が切れた，どどどうしよう，そうだ USB ケーブルでノート PC に繋げば充電できるぞ，しまった PC もバッテリー切れだ，へへ，そういうこともあろうかと乾電池式の外付けチャージャーを持ってきてたのよ，おっと，乾電池を行きの駅で買おうと思って忘れてた！まてよ，ヒゲそりの乾電池もたしか単三だったよな，これを使おう，うわー焦ってるから電池ケースが開かない，落ち着け，ここのツメを左に回せばいいんだが硬い，くっ，何かマイナスドライバー的な物，な，無いか，何か金属片，そういえばバッグの底にゼムクリップが落っこちてなかったっけ？ んー，見当たらない，もうこうなったら全部ひっくり返して（バサバサッ），あったー！ このゼムクリップの先端をここに，んー，滑っちゃうな，もう少し針金のカーブをゆるく曲げ直して引っかけてと，おりゃっ！，おっし，電池ケースが開いた！ ガッ，ガッデム！ 電池 3 本だったのかよ，足りないっつの，おや？ 向こうのほうに人の影が，「すみませーん！」「おーい！」，お年寄りかな，聞こえないみたい，もう駆けてくしかない，タッタッタッタッタッ，はぁはぁはぁ，「すみませーんっ！」，あ，やっと気づいてくれた，はぁはぁはぁ，「こ，このあたりに，はぁはぁはぁ，か，乾電池売ってるお店，ありませんか？」
（お目汚しでした）

@scivola
どういう経緯でどうなって今に至っているかが把握できてなかったり

ハイキングが途中からハッキングになってて 草

新しい技術を試行錯誤しながら勉強している時は、とくに身に覚えあります。いま思えばトンチンカンなところを叩いていたな、と。

模索しているときって、ハイキングの例のようにメソッド・チェーン的に直前の作業が繋がっていくから、最終段階でどこでおかしくなったのかわかりづらいんですよね。

すでに @Zuishin さんがteratailでの例を挙げていらっしゃいますので要らんかもと思いつつ投稿させていただきます。

といっても、僕が「回答しやすい文章とは」と意識を持てたのは、僕個人の定番ではありますがUbuntu Japanese WikiのBugReportのページですね。はい、「バグレポート」です。

上記リンク先の記事のよくあるテンプレートだけでも大分意識できるかなと。以下は一部Markdown解釈してしまう箇所があるので少し編集しております:

...最初に現象の概略を書く...

[How To Reproduce]

...現象を再現させるまでの手順を書く...

[Actual Result]

...どのような現象が発生するのかを書く...

[Expected Result]

...本来なら、どのような動作が起こるべきかを書く...

[How To Fix] :Option

...根本的に問題を解決するパッチなどがあれば書く...

[Workaround] :Option

...なんらかの方法で、問題を回避できる場合はその方法を書く...

バグ報告と質問がなぜ関係するのか

また同Wikiのページから引用いたしますが、ページの冒頭には大事なことが書いていると僕は勝手に思っております。

Ubuntuにおいて「バグ」とは欠陥に限らず、使いにくさも含む広義の「バグ」です。

使いにくさも含む、これが胆かと。

「思った通りに動かない」なら「どう動くと思ったのか」

この投稿の冒頭の引用テンプレでは Expented Result の部分ですね。

僕個人は割とこの辺は質問者のワガママを露呈してしまってよいと思います。むしろここがはっきりしていないと、質問者が回答をもらって、
「なんか思っていたのと違うんですけどーっ 」
と怒っても、質問者・回答者とお互いがお互いの心証を悪くする様な気がします。

もっと僕個人の価値観を露呈してしまうと、
「その『どう動くか』も全く想像できない」
なら、そのとおり書いてもらったほうが回答者も、
「手取り足取り教えないといけないのね」
という回答の詳細度の調整がしやすいと思います。

ただ僕の場合は「質問内容を読んでの回答までの思考順序」まで書いているので、くどいと思う人にはくど過ぎると思います。この投稿のように。

質問者が記入落ちしてしまう事柄に対する僕個人の同情要素

このセクション、いるのか？　まあいいや。

Qiitaをご覧かつ記事も投稿している皆さんは質問サイトを見るたびに「どうして……（呆気）」と思ってしまうことがあるかもしれません。僕は冷血薄情の下等知的生命体なのでなおさら。

なので、なんとか質問者の気持ちを察して上げれるようにと僕個人が質問文を読むときの心がけ程度の小話をいくつか書いていきます。

「何をしたか」が書いてない

率直に言ってしまえば、高速で流れていくコンソールログをいちいち読む意識が働くかというと、不慣れな人は働かないですし、ましてや「ログ」というものの存在そのものを認知していないことはよくある話だと思いますので、
「知らないなら仕方ないね 」
の気持ちで、ログの確認方法をやんわり伝えるくらいがいいのかなと。

前提・背景となる知識が乏しい

僕個人のド素直な話をしますと、今日のプログラミングはいきなりWebアプリだったりするので、
「それぞれのシステム・フレームワークでのお約束」なぞ意識できるかというと、かなり難しい気が。ドメイン（関心事）の細分化や横断とその集約って、僕個人の感想ですが初学者には恐ろしくヘヴィな話に思うのです。

僕のたとえ話はあまりにも的外れなのは承知しておりますが、下手すると「数値」と「数字」の違いを意識できるのも相当時間が必要な気がします。なお僕は専門学校に入って漠然と意識して、卒業してから数年後に関数型パラダイムを学んでその辺りをやっと言葉に起こせるようになったと……思いたいですorz

「何をしたいか」が書いてない

これは暴論になりますけど、文字列と静止画だけで構成されている書籍や文書であると想像しにくい節はあるでしょう。ましてや今は動画コンテンツが容易に閲覧できる時代なのでなおのこと「こうなるのかな？」という想像がしにくいかと。できたとしても、初めと終わりだけで途中経過は文字通りかすんでいるかと。

これは先ほどの「何をしたか」の話にも通じますが、僕個人の考えでは「想像ができないものを言葉に起こすのはとてつもなく難しい」と思います。それこそH.P.ラブクラフト作品の日本語訳みたいな質問文が現れるかもしれませんし、質問者自身がまさにラブクラフト作品の登場人物みたいな気持ちをコンピューター限らず思っているかもしれません。

---

とだらだら質問者の心境・心情を僕個人の妄想でだらだら書きましたが、もしかすると実際の質問者さんはそんなこと微塵も思っておらずむしろ、
「自分がこう思っているからみんなもこう思うだろう・感じるだろう・考えるだろう」
というノリと雰囲気で書いた質問を読み返しても違和感を感じず投稿ボタンをポチーッ！　としているのかもしれません。が、そういう場合に僕は、
「悪い、ワイはエスパーじゃないんや……」
と素直に質問者に謝って回答してる……はずなのだが自身皆無orz

偉そうに書いたが、オチ

とずいぶん偉そうなことをだらだら書きましたが、僕のteratailでの質問 を眺めると、まあしょっぱいしょっぱい。それどころかいわゆる「プログラミングにおける精神論」みたいなことも質問していて、我ながら「うんなもん自分で見つけろボケナス」と鼻で笑ってしまいました。見事にマイナス評価もついていますし。

ということでKEINOSさん、ポエムごめんなさいorz

P.S.

Zuishinさん、その節（メタプロの質問などで）はお世話になりました。改めてこの場を借りてお礼申し上げます。

@manzyun
「回答しやすい文章とは」と意識を持てたのは、僕個人の定番ではありますが Ubuntu Japanese Wiki の BugReport のページです
ただ僕の場合は「質問内容を読んでの回答までの思考順序」まで書いているので、くどいと思う人にはくど過ぎると思います。

GitHub で OSS のコントリビュートをしようと Issue を作成した時のテンプレートとかもそうですよね。

「（え？そこまで情報を書かないといけないのん？ まじポン？。。。）」
「（でも、どういう状況かわからないんだから、情報がないよりは良いんだろうし）」 ｶﾁｬｶﾁｬ
「（あ、ここは指摘されるだろうな。わかる。でもね、それなりの理由があるのよ）」 ｶﾁｬｶﾁｬ

といった葛藤。あります。で、相手は TL; DR で読まずに答えてくれるも

「（そこ、書いたんだけどなぁ ...） (´・ω・｀) ｼｮﾎﾞｰﾝ」

となる。

「（あ、概要を把握してから詳細を見た方が頭に入るよね）」

と反省し、TL; DR（概要） と TS; DR（詳細）にわけるも、また「（そこ、書いたんだけどなぁ ...） (´・ω・｀) ｼｮﾎﾞｰﾝ」となる。

箇条書きを駆使したり、クッション用語（ギャグ）を入れてみたり。。。

「不特定多数の人が読む」とか考えると、だんだん最小公倍数がわからなくなり、気づくと最大公約数的な文章になってしまう。

臨機応変に書けばいいのかもしれないけれど、それが難しいというジレンマ。

Q&A を日本語にすると「問答」。

そういうこと？ 修行なの？ 写経に並ぶ修行なの？

私は「回答者にどんな方向性で答えて欲しいか」を質問に入れるように気を付けています。
@yohhoy さんの 2) と同じことかも知れません。

あえて無理やり医療の例で言うのなら「眠れずに困っている」と相談する相手が内科医と臨床心理士では回答が異なるだろうと考えているからです（正確ではありませんが、極端な例です）。

対面で面識があるなら相手の得意分野が分かっているケースもあると思いますが、質問サイトなどでは回答者のバックグラウンドが想定外の可能性もありますので、「回答に含まれていて欲しい内容の方向性」 は伝えておきたいと思いますね。

自分が求めている回答が「解決方法」ではなく「共感」であることもあったりしますので。

Qiita質問機能の「意見交換」と「Q&A」を選ぶところから Q&A は始まっているのかも知れませんね。

@hidao
「回答者にどんな方向性で答えて欲しいか」を質問に入れるように気を付けています。
自分が求めている回答が「解決方法」ではなく「共感」であることもあったりしますしますので。

なるほど。「解決方法」ではなく「共感」は、自分の質問のタイプを見極める個人的には素敵な指針だと思いました。

1. 問題がよくわかっていない → 問題の明確化（カウンセリング）
2. 問題点は見えた → 自分なりに色々試して問題を克服してみる（コーチング）
3. 色々試したが解決方法がわからない → その道の人に聞いてみる（コンサルティング）

たいていの Q&A の場合は、３を求めているのですが、２の「何を試したか」の情報が抜けていたり。そもそも１の段階だったり。

１の状態で、「何が問題なのかわからない」が「結果は正しくないことはわかっている」時には「共感」のする・しないで切り分けているところがあると気づきました。

私はよく「色々調べてみたのですが」と言ってしまうのですが「（わかりやすい情報ないよね？）」という共感を得ようとしているのだ、と。

逆に言えば、問題がよく分かっていないので解決法にたどり着けない、というググラビリティの低さなんですが、「エンジンかけても、かからないんですもの。わからないんです」という気分。

「月曜の朝にエンジンがかからず、出社する気になりません。どうしたらいいでしょうか」という質問に「出社してください」という答えを求めていないのと似ています。

ん？