概要

開発し始めのころは、なにか躓いたときに「良い質問＝ほしい回答が得られる質問」を作るのが難しかったのですが、最近は無意識のうちに3つのステップで質問文を作っていると前よりも良い質問に近づいたかなと思っています。
今回はその3つのステップを紹介したいと思います。

伝わりやすい質問を作成するための3ステップ

「先輩エンジニアに質問しても、『どういうことですか？』と返されてしまう」「自分の困りごとの言語化が難しい」と思っている新人エンジニアのみなさんは、

自分が持っている情報をすべて書き出す
伝わりやすい構成に並び替える
文章を整形する

を意識するとうまくいくかもしれません！

業務になれていないうちは上手な質問は難しい

社会人2年目の後半から、会社で内定者インターン生のメンタとして業務のサポートをしています。
夕会や1on1等で進捗や困りごとのヒアリングをしているのですが、その中で「言語化が難しいです」「いい質問をすることが難しく感じています」という困りごとを聞きました。
思い返してみると、自分も開発を始めたての頃はわからないことだらけで、キャッチアップ大変だったなと思いSlackを遡ってみたところ、こんな質問が出てきました。

この質問、すごい必死感に伝えようとしている気持ちは出ているのですが、今の自分だったらもっとこう書くよなという点がいくつか出てきました。

全員が出社して仕事しているのであれば、このあたり口頭で会話しながら相談すればすぐに解消しそうな気もしますが、リモート前提の働き方だとそうもいきません。
「テキストベースで自分の欲しい情報を人からもらう」というのは業務において大事なスキルだとは思うのですが、なかなか良い質問の仕方について学ぶ機会もないので、今回は上記の僕の質問を添削する形で、当時から2年ほどたった自分だったらどう質問するかを書いてみたいと思います。

なぜあなたの質問は答えにくのか

そもそも、業務中に質問する場合には、業務を進める上でなにか困りごとや知りたいことがある場合がほとんどかと思います。
となると、質問のゴールは「ほしい回答が得られること」です。
では、なぜ質問をしてもほしい回答が得られないのでしょうか？
ケース別にいくつか原因を考えてみました。

質問に対しての答えがなかなかもらえないケース

先輩エンジニアもだいたいは自分の業務を進めています。
急ぎだったり、複雑な開発をしている際には、そちらに集中する必要があることも多いです。
そんななかで割り込みのタスクがあった際には、割り込みが簡単なものであればすぐに対応できますし、複雑で頭を使うような負荷が高いものだと、手元の回答が落ち着いてから答えるということもあるかと思います。
つまり、質問の負荷が高いと回答のコストが高くなってしまい、つい回答するのが後回しになるのです。
負荷が高い質問には以下のようなものがあります。

文章が冗長で読むのが大変
- 1文が長い、「xxので、xxので、xx」などの助詞が続いている
- 口語文で書かれている
情報が整理されていない
- 事実と解釈が混じっている
回答に必要な情報に漏れがあり確認の必要がある
質問の粒度が大きい

質問に対して答えがもらえたが、こちらがほしい回答じゃなかった場合

もう一つのケースは、レスはもらえるが欲しい回答がずれている場合です。
以下の2つの原因が思い浮かびました。

前提情報が不足している
言葉の使い方が間違っている

極端な例ですが「おすすめの本ありますか？」と聞かれるのと「質問の仕方に困っていてなにかインプットしたいなと思っているのですが、おすすめの本ありますか？」のように、前提がずれていると質問者がほしい情報（役に立ちそうな本）は帰ってこないですよね。（回答者が「何用の本を探していますか？」みたいに確認のレスをする光景が目に浮かびます）
また、「質問の仕方」に困っているのに、「コミュニケーションに困っていて」のように聞いてしまうような場合もあります。そのように言葉を間違って使ってしまっても、ほしい回答からは遠のいてしまいます。

3つのステップで質問を考える

このような状況を避けるために、いつもどういうことを考えて質問をしているかということをふりかえって言語化してみたところ、だいたい3つのステップにわけることができました。

自分が持っている情報をすべて書き出す
伝わりやすい構成に並び替える
文章を整形する

1. 自分が持っている情報をすべて書き出す

まずは、自分の頭の中を整理します。
この時のコツは、相手に伝えることを考えずに、ただただ自分の持っている情報をアウトプットすることです。

上記の例に出した質問だと、

テストが失敗した
product_part1がないと失敗している
product_group.rb:32で代入しているつもり
変数を確認しようと思った
RSpecで変数を確認したい
raiseは使ったけど確認できてない
Rspecを実行したらRecordInvalidエラーが出ている
リモートで確認するしかない？
git rebase -iした
エラーが出た
git push -fしても大丈夫？
なにか間違ってリポジトリ壊しちゃったらどうしよう

もやもやしていることに対して、頭の中に浮かんだことをただただ列挙します。

2. 伝わりやすい構成に並び替える

次に、1で出した情報を分類していきます。質問の本文を見ると1,2,3と質問に数字をつけているのですが、それぞれ独立して話が進むと思うので、スレッドを分けて、なるべく1つの質問の粒度を小さくしたほうが独立して回答できるので回答の負荷が下がります。

僕はだいたい

やっていること、背景
困っていること、詰まっていること、課題
知りたいこと、相手に求めること、期待

こんな感じで整理することが多いような気がしますが、質問のフォーマットはTPOに分けて使い分けてください。

また、このときに事実と解釈をわけることも大事です。特に背景知識が少ないと、間違って事実を解釈している場合が多く、そうなると回答者の回答の方向性も間違ったものになってしまいます。

この時点で、ダブっている内容や情報の粒度も整理します。
上記の例だと、「変数を確認しようと思った」「RSpecで変数を確認したい」は同じ意味なので、統合できます。また、「テストが失敗した」「product_part1がないと失敗している」もほとんど意味が同じなので「product_part1がないとテストが失敗している」のように統合していきます。

そうすると下記のようにできます。

質問1
- PR番号#XXXXを開発中
- product_part1がないと失敗している
- product_group.rb:32で代入しているつもり
- 代入の仕方が合っているか確認してほしい
質問2
- RSpecで変数を確認したい
  - raiseは使ったけど確認できてない
- どうすれば確認できるか教えてほしい
質問3
- Rspecを実行したらRecordInvalidエラーが出ている
- リモートで確認するしかない？
- 他に方法があれば確認方法を教えてほしい
質問4
- git rebase -iした
- エラーが出た
- git push -fしても大丈夫か知りたい

3. 文章を整形する

ここまで整理できたら、質問の骨子が感性です。
あとは伝わりやすいように文章を整形していきます。
結論ファーストで書くと、最初の文章を読んだだけで質問の内容の想像ができるので、認知不可が下がります。具体的には、質問で困っている箇所＋知りたいことを抽象化した文章を頭に持ってきます。
また、本文中では書ききれない非言語情報を伝えるために絵文字を伝えるのも効果的かと思います。
絵文字を入れることで文章が柔らかくなるほか、困り度を表情で表すことで質問をもらった相手が回答の優先度を気づいたりもできる気がします。

また、実際のエラー文や参考リンクがあれば貼っておきます。エラー分やURLなどの長い記号が文章中にあると文章全体が読みづらくなってしまうので、スレッドに続ける形で補足情報として貼り付けるか、本文からリンクとして参照してもらうようにします。

こんな感じで直してみました。

質問1
PR#XXXX(リンク）のコードのテストを書いていて確認いただきたい箇所があったので質問させてください🙇‍♂️
スレッドの箇所で、「xxx」というエラーがでています。
product_group.rb:32での変数の代入が、問題かと思っていますが、こちら書き方合っていますでしょうか？😭
質問2
RSpecでの変数の確認の仕方について質問させてください🙏
xxx(リンク)の箇所で、使った変数を確認したいのですが、どうすればコンソールから確認できますか？
（raiseは使ったのですが確認できずでした🤔）
質問3
Rspecを実行時の結果の確認方法について教えていただきたいです！😇
xxxしたらRecordInvalidエラーが出ているようなのですが、これはリモートで確認するしかないでしょうか？
質問4
git rebase -iしたあとにgit push -fしてしまっても良いでしょうか？
コミットを整理しようとgit rebase -iしたところgit push時に下記スレッドのようなエラーが出るようになってしまい。。
こちら大丈夫か不安なので一度確認のため質問させていただきました🙇‍♂️

いかがでしょうか？
もちろん、質問者と回答者は環境や人によって全く違うので、これが全員にとって読みやすい/回答しやすいとは思っていないのですが、このようなステップで質問を考えると少しは考えやすくなるかも？と思ったので紹介させていただきました。

ちなみに今はインターン生からの質問ややりとりに関しては1on1や夕会などでわかりやすかったところや逆に伝わりにくかったところをお互いみながら進めています。
こういう双方向のやりとりがあることで、だんだんとコミュニケーションが改善されている気がします。
最後はお互い試行錯誤しながらチームですり合わせていくしかなさそうです。

とはいえ今回の記事を書きながら、改めて思ったのは他の人に何かを伝えることって本質的に難しいということです。
今回の記事も、自分が普段やっていることをすべて洗い出して、フォーマットに当てはめて構成を考えて、文章の形で整形して作ってみましたが、果たしてうまく伝えられているのかは不安が残りますし、コミュニケーション関連なので正解がない世界のような気もしております。

こちらの記事を読んでくださった方の中で、もしもこんなこと気をつけているよ！というものや、フィードバック等があればぜひ教えて下さい。