はじめに

業務で実装を行っている際や、個人開発を行っている際に、わからない箇所が出てくることが多くあると思います。
その際、同じチームメンバーに質問したり、質問投稿サイトで技術的な質問を行うと思うのですが、初めのうちはなかなかほしい回答をすぐもらえなかったり、逆に相手から確認の質問をたくさん受け取って問題解決までに時間がかかってしまうことが多くあるのではないでしょうか。
私自身、プログラマ1年目のころにこのような経験を何度かしており、「良い質問の仕方を知りたい」と思う場面が多々ありました。
そこで、同じように考えているプログラマの方に、ほしい情報をすぐ得られるような質問の仕方を共有したいと思い、これまでのプログラマ経験の中で質問時に大切だなと思った内容を書きたいと思います。

対象読者

プログラミング初心者で不明点が出てきたときの質問の仕方に難しさを感じている方
プログラマとして、質問の仕方の型を増やしたい方
質問を受ける回答者として、どのような質問を受けるとよいのかを知りたい方（質問者へ質問時のアドバイスを行いたい方）

質問するときのポイント

前提として、以下で記載する質問の仕方は、「100％これが正解」というよりかは「実装時に不明点やできないことがあって他の人の力を借りたいが、事前に何を他の人に伝えるとよいかわからない・わからない箇所がわからない」など困った時に必要に応じて参考にしていただけるとよいと思います。
主に、技術系メーリングリストで質問するときのパターン・ランゲージに記載されている内容を参考に記載しております。

個人的には、以下の点を質問時に伝えることが大切だと考えてます。

行いたいこと
調べたこと
行ったこと（実装内容や実行手順）・行った理由・想定結果
どこまで想定通りにできたのか
どこから想定通りにできていないのか
発生したエラーメッセージ・エラーログ（コピペする）

以下でそれぞれの詳細を記載していきます。

行いたいこと

ここでもポイントは、「自分が行おうと思っている実装内容」よりも「そもそもの具体的な仕様や要件は何か（なぜその実装を行う必要があるのか）」を重点的に伝えることです。
そもそもの仕様・用件を伝えることで、質問者自身が考えていた実装だけでなく、他の実装方法も回答者が提示できるようになります。

質問で実装内容だけを伝える例
- 質問者：「Javascriptでswitch caseを用いた条件分岐処理を行う方法を教えてほしい」
- 回答者：「 switch xxx ... のようなコードの記述が可能」
  （↑それが良い実装方法とは限らない）
質問で仕様・要件も伝える例
- 質問者：「ユーザが画面上で1を選択したときには"A"を、2を選択したときには"B"を表示したいが、Javascriptでswitch caseを用いた条件分岐処理を行う方法を教えてほしい」
- 回答者：「そもそもswitch caseを用いるのではなく、連想配列で { 1: A, 2: B } のようなデータを使用して実装することが可能」
  （↑回答者はより良い実装方法の提示が可能）

調べたこと

事前に技術調査を行い、調査の結果、わけあってその技術や実装方法を採用しない場合もあるかと思います。そのような内容は質問時には事前に伝えると効率的に質問の回答をもらうことができます。
調査内容を伝えないと、
質問者：「xxxという問題を解決したいのですが、どうすればよいですか？」
回答者：「oooという方法で実装するのはどうでしょうか」
質問者：「それはすでに調査済みで、△△△という理由でその方法をとらないようにしているんですよね」
回答者：「（それ早く言ってよ...）」
という会話になってしまい、質問者は欲しい回答がなかなか得られなくなってしまいます。
上記のように、質問者が事前に調べた内容と同様の内容を回答者も調べる、ということは往々にして起こるため、回答者の調査対象を質問者と重複しないようにして効率よく回答を得るためにも事前に調べた内容は回答者に共有すると良いです。

行ったこと（実装内容や実行手順）・行った理由・想定結果

すでに何らかのプログラムを実装している場合には、「どのようなプログラムを書いたのか」「どのような手順で画面を操作したのか」など実装内容・実行手順を伝えましょう。
加えて、ここでのポイントは、「その実装を行った理由」と「プログラムを動かした際の想定結果」を伝えるなど、質問者の実装時の思考を伝えることです。

「その実装を行った理由」…実装時の前提条件の共有となり、回答者はこの情報からあらかじめ考慮しないといけない事項を把握できます
（例： xxxという制約があるため、oooという実装を行った ）
「プログラムを動かした際の想定結果」…本来どのような結果となってほしいのかを記載することで、実際に得られる結果の妥当性を回答者が把握することができ、「実行結果自体は正しい結果なのか」「実行結果自体が誤った結果なのか」を把握できます

どこまで想定通りにできたのか

すでに何らかのプログラムを実行した結果を取得している場合には、問題の切り分けを行いやすくするためにも、まずはどこまで想定通り動いているのかを伝えましょう。
（「行ったこと（実装内容など）」で伝えた内容のうち、どこまで想定通りの結果なのかを記載）

どこから想定通りにできなかったのか

「どこまで想定通りにできたのか」に加えて、どこから想定通り動いていないのかを記載しましょう
（エラーの発生箇所の特定を早められるため）
エラーの発生箇所や想定通り動いていない箇所の特定には、以下のような方法が考えられます。

フロントエンド開発の場合…DevToolsのようなツールを利用してブレークポイントを張って処理をステップ実行してみたり、コンソールへの表示内容を確認
サーバサイド開発の場合…処理結果のログ出力の仕組みを利用（作成）してログを確認、Visual StudioのようなIDEを利用してステップ実行

発生したエラーメッセージ・エラーログ（コピペする）

実行の結果、何らかの意図しないエラーが発生している場合には、エラーメッセージやエラーログも共有しましょう。
（発生したエラーの解消方法を見つけやすくするため）
ここでのポイントは、出力されたメッセージやログをコピペすることです。
コピペすることで、以下のようなメリットがあります。

正確な状況把握が可能であるため
（無理にエラーメッセージを質問者自身で解釈して質問時に伝えると、解釈が実際のエラー内容と異なっているかもしれないため）
回答者が調査時に検索しやすくなるため
（エラーメッセージでそのまま検索可能となる）

レベルに応じた質問内容

The Five Orders of Ignoranceに示されているように、「わかる/わからない」のレベルには5段階あると考えられています。
この5段階それぞれに応じて、「質問するときのポイント」をどのように使用して質問を考えるとよいのかも記載したいと思います。

全部わかっている（質問不要なレベル）
わからないことがわかっている
- 「質問するときのポイント」で記載した内容に沿って質問する
わからないことがわからない
- 「質問するときのポイント」で記載した内容のうち、（すべてを無理に記載する必要はないが）「どこまで想定通りにできていて、どこから想定通りにできていないのか」を質問時に伝える
  「何が原因かはわからないが、実装した処理のどこまでが動いていてどこから動かなくなったのか」など
わからないことがわからない状況を何とかする術を知らない
- 「質問するときのポイント）」で記載した内容のうち、「行いたいこと」（=実装対象の仕様や要件）を把握しているかを確認する（そもそもなぜその機能が必要なのか（=why）に立ち返ってみる）
- 「質問するときのポイント」で記載した内容を「誰に聞いて or どのようなワードで検索して or どのようにデバッグして」調査可能かを質問する
無知にレベルがあることを知らない
- The Five Orders of Ignoranceの1～5の存在を知る

解決後に行うとよいこと

質問した問題の解決方法の回答者への共有
（バグ修正などの質問を行っている場合は）発生していたバグ原因の回答者への共有

質問の回答者は、自分の回答結果によってどのように問題が解決されたのかが気になるものです。
また、知識の共有にもなるのでぜひ解決方法の共有を行いましょう。

参考