質問に関することで悩む若手エンジニアは多い

• 「ちゃんと調べてから質問した？」
• 「今日の進捗は？ない？ずっと同じ場所で悩んでいたの？？」
• 「わからないところあったらすぐ質問してね？」
• 「すみません。どうして欲しいのかわからないです」

他にもいろいろあると思いますが、
上記の様なことを言われているうちに質問することへの心理的障壁が上がってしまい、
質問する行為自体が悩みの種になってしまうことも多いです。

自身のキャリアのキャリア初期に「こうするとうまくいった」・「こうしておけばよかった」
また、エンジニアキャリアをスタートしたばかりの人をサポートする様になって「こうすればうまくいくんじゃない？」と
アドバイスする機会もあったので、今回は質問という話題に絞って、残しておきたい。

カテゴリ分けするともっと見やすくなるかもしれないが、思いついたエピソードや事柄を羅列する形にしたいと思います。
稚拙ながら誰かの役に立てば幸いです。

質問テンプレートや質問までの時間の目安を決める（よくあるパターン）

若手エンジニアの多い組織では質問形式のテンプレート（下記みたいなやつ）を使っていたり、
「15分悩んだら質問をしましょう」みたいなルールを設けていることも多いと思と思います。

## 起きている事象
## 試したこと
## 問題に対する仮説

ただ、こういったガイドラインを設けていても質問に関することで悩む人はいます。
また、同じ組織内で同時期に入った人同士でも、テンプレートや組織内の質問ガイドラインに沿って質問していても
質問力に差が出ることは多いです。
そして成長速度にも差が出たりしまうが、
質問が上手い人は大体独り立ちするのも早いと思っています。（あるある？）

結局は技術者としてのマインドなのでは？と思う様に

一定のガイドラインを設けていても改善しないのは
マインドによるものなのでは？と思う様になりました。

そこで、あるある的な話題として良い例とよくない例に分けて
事例紹介しておこうと思います。

もちろん自身のしくじりも多々含んでおりますが何卒お付き合いくださいませ。

良くない例

①質問文の情報の解像度が低い

これは新米のエンジニアにありがちなもので
「実装したものを実行してみたのですが、正しく動作しません」的なやつです。王道ですね。
質問テンプレートに沿っていても各項目に書かれている情報が粗いと、回答者に下記の印象を与えかねません。

• 何を実行したの？
• 正しい動作って何？

情報が粗いと回答者の負荷が高まります。

• 実行内容（システム的な操作を含む）
• 正しい動作（これは質問者にとって期待している挙動） が一体何なのか明確にする必要があります。

例としては
「項目A表示条件に相当するhogehogeがtrueになる状態でブラウザからアクセスしました。（←実行） 表示項目Bの上にAが表示されることを期待していますが（←期待する動作） 表示されないという状況が起こっています。(←実際に起きた挙動)」

必要に応じて、前提条件や自身の仮説を述べることでより解像度が高い質問ができる様になると思います。

②状況の報告でしかないく、相手に期待することを書いていない（何が問題なのか不明）

「実装し〜を行ったところ、エラーが出ました」的なやつ。

厳しい言い方をすると、「だからどうしたの」と思ってしまいます。(僕もよくやってしまっていましたorz)
これは意地悪なのではなく、システムとして不適切なデータが渡ってきた時などには
正しくエラーをを返すという状況が多数あります。
つまり、エラーが出るという状況は、システムとしてそれが正しい動きな場合もあるわけです。
エラーが出るということが期待する動作でないのなら
「レコードが追加されること期待しているのですが、実際の挙動として〜というエラーメッセージが出ます。原因がわからず、詰まってしまっておりますので一緒に確認いただきたいです。」
という様に、自分自身が起きている事象のどの部分に疑問を感じているのか記載しその上で
相手に期待すること（エラーの原因を調査を手伝って欲しいとか、実装をみて欲しいとか）
ということを伝える必要があると思います。

③テンプレートにこだわりすぎている

ガイドラインとして質問の形式があると、必ずそれに則って記載しないといけないと考える人がいます。
生真面目なのはいいことなのですが、質問の回答に必要な情報ある程度絞れている様な条件下で、
不要な前提条件などがつらつらと書かれていると回答者にとってノイズとなり、趣旨を把握するまでの時間が長くなってしまいます。
課題解決にとって必要と思われる情報を記載しノイズになる情報は書かない様に訓練することも必要です。

④短絡的な答えを求めプロセスに無関心

「答えをください」的なやつ。
回答者は大抵の場合、質問者の理解度がどの程度なのかを考え、
理解が浅い様なら概念的に理解できる様な説明をするのです。
「Aから判断すると、Bが期待されると思っているのですが〜」
の様にできる限り、過程を意識し自身の思考プロセスが相手に伝わる様に意識しましょう。
また、質問に対する説明を受けているときに、その場の答えがわかったからと言って聞き流すのではなく、
仕組みを理解することに努めましょう。

多くの回答者は自分の時間が奪われることよりも、質問者がよく理解しないまま進めてしまうことを嫌がります。

最大限理解することは解答してくれた人に対するリスペクトであると思います。

⑤職場は教育機関ではない

よく考えずに「教えていだきたいです」を連発する系です。
作業割り振りしているリーダーも振った作業の全てを把握しているわけではありません。
また、将来的に自己解決できる様な人材に成長することを期待されています。
わからないなりに考えた考えた痕跡や相手にとって負荷の低い質問を心がけプロとして自覚を持つべきであると思っています。（前提条件やどこまでわかっているかを記載する）
質問をして待っていれば誰かが整理してくれるといった態度は避けることが賢明です。

⑥他人（チームメイトへの）への過剰配慮

• 質問すると、相手の時間を奪うのではないか？
• こんな質問をするとレベルが低いと思われてしまうのではないか
• 自分の身に降りかかった困難は自己解決しないと気が済まない 上記の様考えを持つ人がいます。

持っておく考え方はチームとしてのアウトプットを最大化する意識だと思っています。
例えば、質問を何らかの理由で躊躇い、解決する見込みが低いのにもかかわらず、
悩み続けてその日進捗がなかったとします。

多くの場合のプロジェクトでは納品期日が決まっているので、進捗がなかったことにより
明日以降に振る予定だったタスクがふれなくなります。
多くの場合このタスクはチームリーダーや他のチームメイトが作業を巻き取ることになります。
つまり、解決の見込みがないのに同じ箇所で悩み続けるという行為は
翌日以降のチームメイトの時間を奪っていることになるのです。

エゴを捨てて自分で解決できる見込みがない問題に関しては早めにアラートを上げる勇気を持つことは必要であると考えています。

⑦プロとしての自覚がない

「〜が起きています。どうしましょうか？」みたいなやつですね。

「あなたはどうしたいの？（どうすべきだと考えているの？）」と思われてしまうでしょう。

みんな最初から問題を解決できるわけではありませんが、
仮説・検証を繰り返すことで段々自己解決できる領域が増えていくのです。

わからないなりに持論を持つことはプロとして大事なことだと思います。

良い心構え編

①回答者のコストを意識した質問を心がける

質問に対する想定解答を考えることは今後自走するために有用な方法です。

• 自己解決
• YES/NO
• 選択肢
• 単語
• 文章
• 議論が必要

上に行けば行くほど、解答に対する負荷が軽いです。

一番上を自己解決としているのは理想です。
質問に必要な情報を集めていたら、解決の糸口が見つかり自己解決に至る経験はあるのではないでしょうか。
質問内容を適切にしよう心がけることは自身に起きている問題を客観視できるきっかけ
となるので、一定時間進捗がなかったら、質問事項を整理する段階に入りましょう。

②その質問を通じて成長してやるぞという意気込みを持ち、チームに還元する

チームメイトは質問を機に周辺知識を習得し成長することを期待しています。

• 「昨日アドバイスいただいたところの周辺を調べていると勘違いしやすいところだった様なので社内wikiにまとめました」
• 「教えていただいたAについて調べているとわかりやすい記事があったので共有します」

の様に質問を機に、体型的な理解を求め、それをチームや回答してくれた人に還元する気持ちを持つことで良好な関係を築くことにつながると思っています。

③最終的な判断基準を自分で持つことを怠らない

質問を解答してくれる人は多くの場合で、その問題に直面した過程を大事にして、成長機会とすることを望んでいます。
また、プロとして最終意思決定は自分で行わなければなりません。
単に「チームリーダーの意見だから」ということでだけで、従ってしまうべきではありません。
質問というのはあくまで起きている事象から、解決に至りそうな部分を切り取っています。
必要な前提条件が漏れていたりすると解答者の答えもかわる可能性があるということを忘れては行けないのです。
回答を得たら、回答をくれた人の思考プロセスに着目し、
起きている事象に対して適切なのか？質問含めていない前提条件によって回答が可能性はあるか考えます。
「AさんのBというアドバイスを踏まえ再度自分で考えた結果Cとして進めようと思います」という様なコミュニケーションが取れる様になってくると
自走するステップになると思っています。

④方針を決める質問をする

駆け出しエンジニアの頃はよく手戻りが発生します。

• 「新しい関数を定義するのではなく既存の改修をしてほしかった」
• 「別のクラスで実装をしてほしかった」

の様に設計に関わる部分などは特にレビュー時に指摘されると修正範囲が大きくなります。

慣れないうちや設計的に自信がないときは思い切って
「〜クラスに新しい関数を定義して引数としてAを取りBを返して要件を満たそうと思います。問題なさそうかレビューお願いします」
の様に実装案をレビューしてもらうことをお勧めします。
ここでレビューをもらい、実装方針のプロセスを吸収することで実装や設計の知見がつきます

相手の時間をとってしまうことは躊躇う要因になりますが、ソースが出来上がってからレビュー時に根本的な実装方針を指摘するとなるとレビュアーにとって負荷が思い作業になり、レビューの回数も増えがちです。

方針を決めてベクトルの向きが大きく外れていないか確認し、進み始めることは結果的にコミュニケーションコストの削減になると考えています。

質問がうまくいけば好循環にまわりやすい

スキルも浅く、チームにも入りたての頃は心理的にも負荷がかかりやすく、
色々迷うこともあると思います。
質問を通じたコミュニケーションが良いものになるとチームメイトとの関係性がより良いものになり、
結果的にいいサイクルに回り始めると、人と協力しながらプロダクトを作っていくことがより楽しいものになると思っています。

良好な関係構築を積極的におこなう

逆説的にはなりますが、関係性ができていると質問もしやすくなります。
最近はリモート中心になるとことも多いかと思いますが、
チームメイトをランチに誘ったり、オンラインのランチ会を企画するのも一つの手であると思います。

普段とは違う一面が見えたり、パーソナリティが見えてくると質問への心理的な障壁は下がるきっかけになるかも知れません。

最後に

拙い文章になりますが、以上で締めたいと思います。

新人エンジニアのお悩みあるあるとして
『動けば別に良くない？』と言っていた二年前の自分にシステム設計の話をしてみる
を書いてみました。
こちらも新人エンジニアの心理的なことについて書いていますので、よかったら読んでみてください。