はじめに
質問は業務の基本であると言って良いほど、エンジニアにとって日常的な行為です。質問の内容は多岐にわたり、技術的な質問から社内ローカルルール、昨日何食べた？のような雑談まで様々です。
そのように、いたるところで様々な内容の質問が飛び交っていることもあり、質問に関する記事をよく目にします。そして、その多くが質問の作法に関する内容であり、つぎのような質問の答えにたどり着きやすくすることを主としているように思います。
- 質問される側が答えやすいようなに質問しましょう
- 質問される側の時間を大切にしましょう
- 自分で調べてから質問しましょう
たしかにこれらの内容は大切だと思います。ただ、これらは新卒や経験の浅いエンジニアにとって、質問の際にやること、考えることが多く、質問の敷居を上げてしまっているようにも感じています。その結果、質問するかどうか悩んでしまっていることがあるのではないかと考えています。
そこで本記事は、質問するかどうかを判断する指標を与え、円滑に質問をするための助けとすることを目的とします。また、質問される側の人にも、質問する人に対して質問の敷居を下げるための指標として活用してもらうことを目的とします。
※本記事は個人の経験に基づくものであり、何らかの一般的事実に基づく裏付けが無いこと、すべてのケースに当てはまるものではないことにご注意ください。
対象読者
- 質問する前に少し立ち止まってしまう人
- 新人、若手エンジニア
- 質問されることが多い人
なぜ質問するのか
まずはじめに、なぜあなたは質問するのでしょうか。質問したいのでしょうか。それはいくつか考えられますが、おおよそ、つぎにあげるようなところではないでしょうか。依頼とか相談のようなものもあります。
- 知りたいこと、わからないことを知るため、わかるため
- 「for文ってどう書くんでしたっけ」
- 「この基板の表層で差動100Ωにするには、LSいくつにすればよいか知ってますか？」
- 何かを決断・判断するため
- 「この日程で展開しちゃって良いですよね？」
- 「この部分の修正、A案とB案のどっちが良いですか？」
- その人しか知らないこと・できないことがあるため
- 「〇〇さんが昨日紹介していたツールはどこから入手できますか？」
- 「〇〇さんが書いたコード、なんでこのような処理にしてるんですか？」
- 「この不具合ってどうやってわかったんですか？履歴を見ると〇〇さんが起票者だったんですが。」
これらは表面的な一次の理由のですね。これらの理由のもうひとつ深い階層の理由はどのようなものでしょうか。
もうひとつ深い「なぜ質問するのか」
それは、業務を進めるためでしょう。
上であげた最初の例では、for文の書き方がわからないと、担当している部分のコードが完成しない。つまり、業務（プロジェクト）が前に進まない。業務を前に進めるための一つの手段として質問を選択した、という見方です。上であげた例はほぼそのような背景から質問が発生していると考えられます。
もちろん、そのようなロジックに合う例ばかりをあげているので、数多ある質問のなかには当てはまらないものもあるでしょう。ただ、業務上発生する質問の多くは業務に関連するものと思っているので、ここではそれを主として扱います。
そして、業務であるにも関わらず、質問するかどうか悩む人はなぜ悩んでしまうのでしょうか。
なぜ質問するか悩むのか
なぜ質問をためらうか、それは、冒頭で述べた質問の作法の裏返しではないかと思っています。要は相手のことを考えるあまりに、または自分のことを考えるあまりにためらってしまう。こんな質問で相手の手を止めてしまうのではないか、こんなこともわからないのかと思われてしまうのではないか、そもそも話しかけづらい…などなど。
自分の場合ですが、どのような形式で質問されても、自分が答えられるように前提や周辺情報は一緒に収集しますし、質問されたくないタイミングで質問された場合は、後で答えるから待ってくれと言うので、質問歓迎スタンスを示しています。しかし、それを受け取る側（＝質問する側）がどう感じているかはわかりません。
つまり、結局のところ、質問する側の判断指標や心持ちに新たな視点を加えてあげる必要があると考えます。
質問しないとどうなるか
そこで、質問をためらって、結局質問できなかった場合、どうなるかを考えます。
前述のとおり、質問は業務を進めるためにするものです。つまり、質問しなかった場合、業務が滞ることになります。自分が担当しているコードが完成しません、回路が完成しません、図面が完成しません、プロジェクトが止まります。結果的に、ユーザーに製品やサービスが届かなかったり、遅延したりするでしょう。と、まあこれはかなり影響範囲を大きくしましたが、どのような業務もそのプロジェクト全体につながっていると考えると、そう遠くはないように思います。
その質問をためらったことで、ユーザーに不利益を与えて良いでしょうか？
質問するかどうか判断する指標はこれ！
業務を進めるために必要かどうか！
これに尽きます。ここでは質問の相手や自分のことを考える必要はありません。もっと大きい視点で背中を押して貰えれば、きっと質問できるはずです。もはや自分で調べることなんか忘れてノータイムで質問しても良いくらいです。それでプロジェクトが動くのですから。そして、質問する回数が増えてきたときに、相手や自分のこと、作法などを考えれば良いのです。
おわりに
心持ちのような、経験に基づくふわっとした内容でしたが、一人でも質問ができるようになり、一つでも円滑に業務が進めば幸いです。
ここまで経験に基づく持論を展開してきましたが、書きながら、この程度のことはみんな知っていて、その上でいろいろ発信してるよなあと思ってしまいました。そんなことを思いながら、最後にもうひとつ。質問のテンプレをよく見かけますが（状況、やったこと、調べたこと、質問内容、やりたいことなどを書くというやつ）、もし作るなら、これは質問される側が用意してあげましょう。これって質問に答えやすくするためのものですよね（と思っています）。記事に上がるようなものは、汎用的な一般的なものが多いと思いますが、実業務では必要な項目も変わってくるはずです。さらに、人によってはそこまで情報不要ということもあるでしょう。質問される側は、自分はどんなことがわかっていないと、質問（＝問題）を解決できないかを冷静に見直してみると良いかもしれません。
本当は、質問とはなにかという定義から多くの事例を使ったケーススタディのようなところまで書きたかったのですが、量が多くなってしまうので別の機会にまわします。
ご覧いただきありがとうございました。