エンジニア同士の相談をスムーズにする質問テンプレート

エンジニアとして仕事をしていると、自分一人では判断できないことや、他のメンバーに確認しなければならない場面が多くあります。
たとえば、
「エラーの原因が分からない」
「この実装方針で問題ないか確認したい」
「既存処理の仕様が分からない」
「どこまで自分で対応してよいか判断できない」
といった場面です。
こうしたとき、質問の仕方によってはすぐに解決することもあれば、何度もやり取りが必要になることもあります。
今回は、エンジニア同士で相談するときに意識したいポイントと、実際に使いやすい質問の形についてまとめてみます。

「分かりません」だけでは状況が伝わらない

相談するときに、
「この処理が分かりません」
「エラーが出ています」
「動きません」
とだけ伝えてしまうことがあります。
もちろん、困っていること自体は伝わります。
しかし、質問を受けた側からすると、
「何をしようとしているのか」
「どこまで正常に動いているのか」
「何を確認したのか」
「どのような状態を期待しているのか」
といった情報が分かりません。
そのため、回答する前に状況確認のやり取りが必要になります。
相談をスムーズに進めるためには、質問する側である程度情報を整理しておくことが大切です。

質問するときに整理したい5つの情報

私は、エンジニア同士で相談するときには、次のような情報を整理すると伝わりやすいと考えています。

何をしたいのか

まず最初に「目的」を伝えます。
たとえば、
「ユーザー登録後に確認メールを送信したい」
「一覧画面に検索機能を追加したい」
「このエラーの原因を特定したい」
などです。
目的が分かると、質問を受ける側も「最終的にどうしたいのか」を理解しやすくなります。

現在どうなっているのか

次に、現在の状況を伝えます。
「画面は表示されるが、ボタンを押しても処理が実行されない」
「データベースには登録されているが、画面に表示されない」
など、できるだけ具体的に伝えます。
「動かない」という表現だけではなく、
「どこまでは動いているのか」
ここまで説明すると、原因の切り分けもしやすくなります。

本来どうなる想定なのか

現在の状態だけでなく、
「本来どうなるべきなのか」
これも重要です。
たとえば、
「ボタンを押すと登録処理が実行され、完了画面へ遷移する想定です」
というように、期待している動作を伝えます。
現在の状態と期待する状態の差が分かれば、問題となっているポイントも見えやすくなります。

すでに何を確認したのか

質問する前に確認した内容も伝えます。
たとえば、
「ログは確認しました」
「設定値は見直しました」
「同じ処理を行っている別画面と比較しました」
「一度変更前の状態に戻しました」
などです。
これを伝えることで、相手が同じ確認を繰り返す必要がなくなります。
また、
「そこまで確認できているなら、次はここを見てみよう」
と次の調査につなげやすくなります。

自分では何が原因だと思っているのか

可能であれば、自分なりの考えも添えるとさらに相談しやすくなります。
たとえば、
「ログを見る限り、データ取得まではできているため、画面側の処理に原因があるのではないかと考えています」
といった形です。
必ずしも正しい必要はありません。
自分がどのように考えているのかを共有することで、回答する側もアドバイスしやすくなります。

そのまま使える質問テンプレート

実際に相談するときは、次のような形にすると情報を整理しやすくなります。

【やりたいこと】
〇〇を実装したいです。
【現在の状況】
現在は〇〇までは正常に動作していますが、△△の処理で問題が発生しています。
【期待する動作】
本来は△△すると、□□になる想定です。
【発生している問題】
実際には〇〇というエラーが表示され、処理が停止します。
【確認したこと】
・〇〇を確認しました
・△△を試しました
・□□までは正常に動作することを確認しました
【自分の考え】
〇〇までは正常なため、△△付近に原因があるのではないかと考えています。
【確認したいこと】
この認識で合っているか、また他に確認した方がよい箇所があれば教えていただきたいです。

毎回すべてを書く必要はありません。
簡単な質問であれば、
「何をしたいのか」
「何が起きているのか」
「何を試したのか」
の3つだけでも十分です。
大切なのは、質問を受けた人が状況をイメージできるようにすることだと思います。

BeforeとAfterで比べてみる

たとえば、次のような質問があったとします。
Before
「ログイン処理が動きません。分かりますか？」
これだけでは、回答する側は状況をほとんど把握できません。
一方で、少し情報を加えると次のようになります。
After
「ログイン処理についての相談です。
ログインボタンを押すと認証エラーが表示されます。
昨日までは正常に動作していましたが、本日設定ファイルの認証情報を変更してから発生するようになりました。
一度設定値を元に戻しましたが、同じエラーが発生しています。
ログを見ると認証処理の部分で失敗しているようなので、設定ファイル以外にも確認した方がよい箇所があれば教えていただきたいです。」
この形であれば、
「設定変更後から発生している」
「設定を戻しても改善していない」
「認証処理でエラーが発生している」
という情報が分かります。
質問を受ける側も、次に確認すべきポイントを考えやすくなります。

質問は長ければ良いわけではない

情報を整理することは大切ですが、すべての経緯を細かく書けば良いというわけでもありません。
相談内容が長すぎると、
「結局何を聞きたいのか」
が分かりにくくなることがあります。
そのため、
「何について相談したいのか」
を最初に伝えることが重要です。
たとえば、
「〇〇のエラーについて相談です」
「△△の実装方針について確認したいです」
という一文から始めるだけでも、かなり読みやすくなります。
詳細なログやコードが必要な場合は、その後に補足として共有すると良いと思います。

質問の目的は「答えをもらうこと」だけではない

質問するとき、
「正解を教えてもらう」
ことだけが目的になってしまうことがあります。
しかし、できれば、
「なぜその方法になるのか」
まで理解できると、次回から自分で判断できるようになります。
たとえば回答をもらったあとに、
「今回は〇〇の処理が原因だったという理解で合っていますか？」
と確認するだけでも、自分の理解を深めることができます。
質問を通じて考え方を学ぶことで、自分で対応できる範囲も少しずつ広がっていきます。

質問しやすい環境も大切

質問の仕方を工夫することも重要ですが、チーム側の環境も大切だと思います。
質問するたびに、
「そんなことも分からないの？」
という雰囲気になってしまうと、質問すること自体を避けるようになります。
その結果、分からない状態のまま作業を進めてしまい、後から大きな手戻りが発生する可能性もあります。
分からないことがあれば相談できる。
一方で、質問する側も自分なりに状況を整理する。
この両方があることで、チーム全体として仕事を進めやすくなるのではないでしょうか。

まとめ

エンジニア同士の相談では、技術的な知識だけでなく、
「自分の状況を相手に伝える力」
これも重要です。
相談するときには、
「何をしたいのか」
「現在どうなっているのか」
「本来どうなる想定なのか」
「何を確認したのか」
「自分ではどう考えているのか」
を整理するだけでも、やり取りはかなりスムーズになります。
質問することは、単に分からないことを聞くことではありません。
自分の中で問題を整理し、それを相手が理解できる形にして共有することも、エンジニアにとって大切なスキルの一つだと思います。
困ったときにただ「分かりません」と伝えるのではなく、
「ここまでは分かっていますが、ここから分かりません」
と伝えられるようになるだけでも、質問の質は大きく変わるのではないでしょうか。