エンジニアが最初に身に着けるべきは質問力である件 | 僕の黒歴史と対策を暴露

憧れのエンジニアになり、念願の業務プロジェクトに配属。

いよいよチームの一員として開発業務をこなしていくぞ！！という段階になると、最初はわからないことばかりのはずです。

不明点に詰まっていては仕事にならないので、周りに質問して解決していくしかありません。

しかし、質問を繰り返していくうちに、以下のように感じてしまうことはありませんか？

このように感じてしまうのは、もしかすると質問力不足が原因かもしれません。

自身の質問内容を振り返りエンジニアとして的確な質問ができるきっかけとなればとの思いから、そして何よりエンジニアとして駆け出しの過去の自分に届けたいとの思いから、この記事を書きました。

新人エンジニアが質問で失敗する理由

僕は30代未経験からエンジニアに転職しました。

わからないことを質問することをを繰り返していると、

と、肌で感じることがありました。

新人エンジニアがこのように捉えられてしまう要因には、以下のようなものが考えられます。

基礎的すぎる内容だから

あまりにも初歩的すぎる内容を質問するのは考えもの。

なぜなら、エンジニアはIT技術やプログラミングのプロだからです。

基礎知識は備えているのが当然と見なされますし、もし不足しているなら質問ではなく自習して身に着けるようにしなければなりません。

入社初週だろうとベテランだろうと、技術力を駆使して業務を遂行する対価として給料が発生していることに変わりはありません。

例えば、

おいおい……、と思いますよね。

エンジニアも同じ。

以下のような、あまりにも基礎的すぎる質問は控えるべきです。

単純に忙しいから

スケジュール厳守かつ、突発的な不具合が日常茶飯事のエンジニアは、常に多忙です。

特に納期直前や難解なにエラーに遭遇したときなど、他のことは考えられないほどに切羽詰まっていることもあります。

そのような状況で質問を受けても、時間的余裕が無くて対応できない場合があります。

質問力が低いから

そして、新人エンジニアが質問で失敗する最大の原因はこれだと感じています。

エンジニアの実務レベルの質問は、専門的かつ高度な知識が要求されます。

そのため、何に困っていて、何を教えてほしいのか。環境や、試行錯誤に基づく仮説を、的確に相談相手に伝える必要があります。

しかし、新人エンジニアは知識と経験の不足から、これができません。

質問の方法が悪ければ、受けた側は「結局何が言いたいの？」となり、解決までに時間と手間がかかります。

これを繰り返していると、「こいつの質問は面倒だな……」、と思われてしまうのです。

質問力は必須スキル

エンジニアにおける質問とは、相手の時間と労力をいただく行為です。

実務レベルの質問が一瞬で解決できることはまずありません。

時間と手間をかけながら、まずは状況を理解し、一緒に考え、試行錯誤し、ようやく解決……、となります。

そのため、質問をする際は以下を意識するべきです。

エンジニアとしてやっていく以上、質問力は必須スキルです。

IT技術の進歩は早く、また開発現場では多種多様な言語や手法が使われます。

そのため、どれだけ経験を積んだエンジニアでも、知らない技術を求められるという状況は必ず発生するからです。

ダメな質問とは

では、新人のうちについついやりがちな、ダメな質問とは具体的にどのようなものでしょうか。

相手をイライラさせてしまう質問は、以下の要素にあてはまっている可能性が高いです。

自分で試行錯誤をしていない

自分で一切調べたり解決しようとしたりせず、とりあえず質問をしてしまう。

「悩む時間なんてムダ！誰かが即答してくれたらそのぶん早く作業が進むでしょ！！」

と思ってしまうかもしれませんが、これは絶対にNGです。

エンジニアが成長するのは、未知の状況に遭遇した時に仮説検証を繰り返し、それを解決できた時です。

自分で考えずにすぐにヘルプを求めていてはいつまでも成長がありません。

情報が整理されていない

自分の中で状況が整理されておらず、思考が混沌としていると、曖昧な質問になってしまいます。

例えば「バックエンドの通信ができません」とだけ言われても、質問を受けた側としては情報が少なすぎて、どこを糸口に考えればよいのかわかりません。

フロントエンドは起動しているのか？環境変数は正しく設定したか？バックエンドは起動しているのか？どんなエラーが出ているのか？

基礎の基礎からトラブルシューティングをしていかなければならないので、時間と手間がかかります。

質問内容を理解していない

質問内容自体を理解できていない、というのも意外とありがち。

例えば「Gitのマージでコンフリクトが起きている」トラブルを質問しているのですが、実はGitのプルやマージで何が起こるのかを把握できておらず、ただ目の前のエラーを解決する方法を知ろうとしている、みたいなイメージです。

これでは、回答を得られても本質を理解できません。

なぜその操作で解決できたのかがわからず、その場は凌げても、類似のケースではまた同様の質問を繰り返してしまうかもしれません。

僕のNG質問を暴露

僕はエンジニアになりたての頃、質問に対する配慮が不足しており、まさに前述のダメな質問パターンを繰り返していました。

恥ずかしい限りですが、反面教師にしていただければとの思いから暴露します。

基礎的すぎる質問

まずは一番まずかったなと思う質問。

……自分で調べろや！！、というレベルですよね。

でも配属初週はコンテナ仮想化なんて意味不明でしたし、膨大な未知の言葉に押しつぶされそうで、これは聞くべきことなのか？という判断すらできませんでした。

ちなみにプロジェクトのリーダーやメンバーに恵まれ、僕のために数名が1時間ほど時間をとってくださり、認識合わせの名目で基礎知識の勉強会を設けていただけました。

自分で試行錯誤をしていない＋質問を理解していない

続いて、軽率に質問に走ってしまったパターン。

プロジェクトのマニュアルに従って環境構築をしていたのですが、Gitからクローンしたソースコードを統合開発環境にインポートしたところでエラーが生じて行き詰まりました。

この質問のNG要素は2つ。

まずは、試行錯誤不足です。

試行錯誤とはいっても当時は何をしたらよいのかわからず、何度かクローン→インポートを繰り返し、同じエラーが生じることを確認して質問しました。

エンジニアの試行錯誤とは、同じ手順を何度も繰り返して再現性を確認することではありません。

今回のケースであれば、インポート順を変えてみる、不足しているプロジェクトが無いかリモートリポジトリを確認する、ソースコードを読んで依存関係をチェックする、などが試行錯誤です。

また、質問を理解していなかったのも問題でした。

Maven、pom.xml、依存関係etc.といった、質問中に登場する概念すら、理解が曖昧でした。

このような状況では、仮に回答を得られたとしても、その回答内容を理解できず、わかったようなわからないような……、といったフワフワした状態で終わってしまいます。

情報が整理されていない質問

続いて、自分の中で思考がクリアになっていないのに質問してしまった失敗。

考えがまとまっていないので言い回しが長ったらしく、何が言いたいのかわからなくなっています。

僕はこれを、チームミーティングの場でリーダーに向かって発してしまいました。

リーダーとしては、ソースコードも見ていない状態でいきなりこんなことを聞かれても困ってしまいますよね。

せめてソースコードの該当箇所や懸念点、自分の考えを整理したうえで発言するべきだったと後悔しました。

良い質問とは

良い質問とは、以下のようなものと言えます。

僕は失敗に気づいて以来、質問をする際には、以下のポイントを必ずセルフチェックするようにしています。

質問の主旨がクリアになっているか

質問の主旨とは、何をしたいところ、何が起こっていて、何を回答してほしいのか、ということです。

これを相手に的確に伝えられるかどうかが、良い質問の必須条件です。

そのため、主旨は充分に整理したうえで、質問の最初に伝えるのがおすすめ。

発生している状況を時系列で説明していくと、まどろっこしくなるためです。

核心に続いて、環境や試行内容などの付加条件を伝えていくことで、相手も主旨を理解して話を聞くことができます。

結果、質問の途中で認識の齟齬が生じ、質問と回答が嚙み合わないといったリスクを下げられます。

できることは全て試行済みであるか

質問をする前に、自分で試行できる内容は全て行っておくべきです。

理由はシンプルで、怪しいポイントを事前に減らしておくことで、質問相手が無駄な労力と時間をかけることなく、核心について考えやすくするためです。

ネットで類似の同様のケースを解決したという情報がないか調べたり、これまでの経験から怪しいと思われるポイントを掘り下げたり。

知識と経験をフル活用して試行済みであるかどうかは、質問前に常に自問自答していきたいところです。

質問力を上げるために意識するべきこと

質問力を上げていくために、僕は普段から、以下を意識するようにしています。

質問テンプレートを使う

毎回質問のたびに質問方法を考えるのは手間なので、事前にテンプレートを作っておくのがおすすめです。

正解は無いので、各自がやりやすいように作ってOK。

僕はいつも、以下のテンプレートを用いています。

全てをメモする

発生した問題やその前提条件、調べたこと、試したことなどは、膨大な情報量となっていきます。

都度整理していかなければ、あっという間に情報が溢れてごちゃごちゃになってしまいます。

質問するときや質問後に議論しているとき、速やかに取り出せるよう、メモに残す習慣をつけておいたほうが良いです。

またメモをとることで、今何をしているのかを見失いずらくなります。

わからないことを調べているうちに別のわからないことが生じる、と調査対象がどんどん分岐していくことも珍しくないため、このメリットは大きいです。

1時間は自分で試行錯誤する

質問する前に、自分で徹底的に考えることは重要です。

しかし、そうしていると無限に時間が過ぎてしまうもの。

業務である以上、生産性のない不明点対応に、膨大な時間を費やしてしまうのも考え物です。

15分ルール

Googleの人工知能チームには、「15分ルール」という考え方があるそうです。

これは、行き詰ったら15分は自力で考え、それで解決できなければ質問する、というもの。

ただ、新人エンジニアの場合、15分で試行錯誤できる内容は限られているはずです。

そこで、1時間というタイムリミットを設けて、その時間内は全力で考え抜くというのがちょうど良いかなと感じています。

萎縮しない

既に質問で失敗したり、回答してもらえなかった経験があると、萎縮して質問すること自体をためらってしまうかもしれません。

しかし、だからといって質問しなくなるのは絶対にNG。

以下のように、マイナスの面しかないからです。

前述のポイントを押さえたうえで作成した質問に真摯に向き合ってもらえないのであれば、そのプロジェクトや相談相手に問題があります。

変に気を使ったりへこへこしたりせず、堂々と質問するようにしましょう。

まとめ：質問力こそがエンジニアとしてやっていくためのカギ

本記事では、新人エンジニアがまず身に着けるべきは質問力であるということを、僕の実体験も踏まえながら紹介しました。

業務の納期やマイルストーンが迫っているのに、エラーや不明点で作業が進まない。

さらにその解決の糸口さえ見えないというのは、エンジニアにとって最も辛い状況の一つです。

それを打開するには、周りに質問して助けてもらうしかありません。

エンジニアとしての質問力を身に着けておくことが、周囲との協業をスムーズに進めるカギです。

ぜひエンジニアになりたての時期から正しい質問力意識し、業務効率アップ＆ストレス低減を目指していきましょう！！