やさしい質問の仕方
はじめに
質問って難しいですよね。ちゃんと伝えないと欲しい答えが返ってこないし時間がかかります。
それは相手にとっても同じことで、要領を得ない質問は推察が必要で疲れます。
疲れる質問を繰り返すと、辟易されてどんどんコミュニケーションが取りづらくなり悪循環を生みます。
ですが相手が答えやすい質問であれば、逆にコミュニケーションの機会にもなります。
新人教育の備忘録も兼ねて、ここで質問の仕方を紹介します。
質問形式（オープン/クローズド）
質問は大きくオープンクエスチョンとクローズドクエスチョンに分かれます。
どちらも一長一短あり、うまく使い分けることが重要です。
-
オープンクエスチョン
答えの範囲を絞らずに質問するパターンです。
会話のキャッチボールや想定外の答えを許容するので、雑談やヒアリングに適しています。 -
クローズドクエスチョン
はい/いいえ等いくつかの選択肢を提示し、求める答えの範囲を狭めて質問するパターンです。
アンケート等で使われています。
仕事ではできるだけクローズドクエスチョンを意識しよう
質問は相手に思考を強制します。
質問の範囲が広ければ広いほど、曖昧であればあるほど、質問された側は考えることが増えストレスがかかります。
何かを教えて欲しい場合や問題を解決したい場合等、ついオープンクエスチョンをしてしまいがちですが、できるだけクローズドクエスチョンに寄せて質問できるようにしていきましょう。
※クローズドクエスチョンに寄せるとは、相手の答える範囲を特定し極力負荷をかけない質問内容にするという意味です。
例
(オープンの場合)
間違えてコミットしてしまいました。どうしたらいいですか？
→新人にありがちですね。質問された側は状況確認からスタートする必要があります。
(少しクローズドに寄せた場合)
Gitでコミットを取り消す方法について教えてください。
→Gitについての質問であることはわかりますが、調べた上での質問なのか等、気になる点があります。
(もっとクローズドに寄せた場合)
Gitでコミットを取り消す方法について教えてください。
調べたところ、revertというコマンドがそれにあたるように思いましたが、合っていますか？
よりふさわしい方法があれば教えていただきたいです。
→はい/いいえ+αに絞られるので、回答しやすくなりました。
質問の目的と前提
質問するとき、質問の目的と前提(背景)の説明が必要です。
これを疎かにすると、相手は何を求められているのか、どういう状況なのかがわからずストレスを感じます。
また、本当にほしい答えをもらえない可能性もあります。
例
（質問形式の例に目的と前提の説明を加えた場合）
Gitでコミットを戻す方法について教えてください。
調べたところ、revertというコマンドがそれにあたるように思いましたが、合っていますか？
よりふさわしい方法があれば教えていただきたいです。
謝ってdevelopブランチに修正をコミットしてしまったので取り消したいためです。
まだpushはしていません。
→目的と前提を追加したことで、resetを教えてもらえる可能性が高まりました。
どの程度説明するか
例は簡素な質問ですが、根深い問題や複雑な質問の場合、過去の経緯や現状を全て説明しようとすると時間がかかってしまい、お互い大変です。
説明の際は相手の状況を意識した上で説明内容を取捨選択できると良いでしょう。
例えば、直属の上司や先輩が相手で、状況をある程度把握されている場合、細かい前提は省いた方がスムーズです。
逆に業務上直接関係しない相手等、理解度を把握できない場合は、説明や補足をしっかり行い無駄なやり取りが発生しないよう意識した方が良いでしょう。
質問のフォーマット
上記を踏まえ、自分なりに質問のフォーマットを用意しておくと考えを整理しやすく、相手の負担も減らすことができます。
特におすすめなのが、冒頭の概要で相手と「何の話をするか」のメンタルモデルを合わせた上で、「結論（質問内容）→ 目的・前提 → 補足（自分で調べたこと）」の順で説明する構成です。
推奨フォーマット
- 概要：何についての相談か一言で。相手の脳内をそのトピックに切り替えてもらう。
- 質問内容：一番聞きたいこと（結論）を先に。
- 目的・背景：なぜそれを知りたいのか、今の状況や前提を伝える。
- 補足（自分で調べたこと）：どこまで自力で確認したかを提示し、調査の重複を防ぐ。
具体例1：実装方針・設計の相談
「画面間でデータを受け渡したいが、最適な方法がわからない」というケースです。
構成例
-
概要：
商品詳細画面でのデータ保持方法について相談 -
質問内容：
前の画面で取得した「一時的なID」を、次の画面のAPI呼び出しでも使い回したいのですが、フロントエンド側のStorage等で管理する設計でしょうか？ -
目的・背景：
現状、画面をリロードするとIDが消えてしまい、APIがエラーになります。
今のAPI構成では、遷移後の画面でこのIDを再取得する手段がないため、フロント側で保持し続ける必要があると考えています。 -
自分で調べたこと：
API仕様書を確認しましたが、遷移後の画面用API（GET）のレスポンスには、このIDが含まれていませんでした。
この書き方のメリット
回答側は「フロントで頑張って保持するコードを書こう」とアドバイスする前に、「そもそもAPI側のレスポンスにIDを含めるのが本質的な解決（修正）ではないか？」 という、より良い選択肢に即座に気づけます。
前提を共有することで、「手段（Storage保存）」ではなく「目的（IDの確保）」に対する最適な回答が得られます。
具体例2：ライブラリ導入・技術選定の相談
「新しいツールやライブラリをプロジェクトに入れたい」というケースです。
構成例
-
概要：
日付計算ロジックの実装と、ライブラリ導入の検討について -
質問内容：
標準のDateオブジェクトでは複雑な期間計算が難しいため、軽量ライブラリ（Day.js等）を導入してもよいでしょうか？ -
目的・背景：
今回実装する「キャンペーン期間の判定」において、タイムゾーンや営業日を考慮した比較が必要になりました。
標準機能のみだとコードが煩雑になり、バグの温床になりそうだと懸念しています。 -
自分で調べたこと：
標準のIntl関連APIも調べましたが、期間の重なり判定を簡潔に書くには不十分でした。
また、候補のライブラリはバンドルサイズへの影響も軽微であることを確認済みです。
この書き方のメリット
回答側は、質問者がすでに 「なぜ標準機能ではダメなのか」「導入の懸念点（サイズなど）はクリアしているか」 を検証済みであることを一目で理解できます。
これにより、「まずは標準機能で試して」といった不必要なやり取りをスキップでき、スムーズに意思決定に進めます。
まとめ
フォーマットに沿って書くことで、「相手に状況を推測させるコスト」を低減させることにつながります。
結果として、
- 質問者は、最短ルートで正しい回答が得られる
- 回答者は、思考の負荷が減り、気持ちよく回答できる
のように双方にとって「やさしい」コミュニケーションになります。
おまけ
オープンクエスチョンで気を付けたいこと
前述の通り、質問は思考を強制します。
そのため、後輩への指導等の場面でも質問は多用されますが、後輩の立場でオープンクエスチョンをされるとプレッシャーを感じて思考がまとまらないことがあると思います。
指導の際も目的や前提を説明した上で質問し、過剰なプレッシャーを与えないよう配慮したいですね。
質問を質問で返す
画像の通り、質問に質問で返すと怒られますが、大抵質問をする側が目的と背景の説明を怠っているために質問で返さざるを得ないように思います。
目的と背景をしっかり説明して、質問を質問で返す必要がないよう意識できると良いですね。
おわり。少しでも参考になれば幸いです。
Discussion