なぜエンジニアのあなたの質問は伝わらないのか？

はじめに

包み隠さずオープンに伝えると、投稿主は質問が全然上手ではありません。
多分、この記事を読んでいる皆さんの方が何倍も上手です。

ということで本記事は以上です（冗談です）

こちらでは誰よりも質問下手だった投稿主が試行錯誤した結果、導き出した良い質問・悪い質問それぞれの共通点や法則性を提唱します（単なる一般論でしたらすみません）

あなたの質問はなぜ伝わらないのか

結論？

それは、あなたの質問に愛がないからです。

というのは半分冗談として（笑）、よくありそうな悩みを以下に記載します。
拙い文章ですが、皆さんのお役に立てれば幸いです。

この記事に書かれているのは、あくまで一個人の意見です。
知ったからといって、明日から質問力が上達することを保証するわけではありません。

テクニックに走ることによる弊害

「本をたくさん読んだり、質問フォーマットで文章を丁寧に書いてみたけど、全然伝わらない！」

生成AIに聞いてみたりしたら、たとえばこんな答えが返ってくると思います。
Q. 私はエンジニアなのですが、質問はなぜ伝わらないのでしょうか？
A.　以下のような回答が返ってきました。

1. 技術的な用語や専門知識のギャップ：エンジニアリングには多くの専門用語や概念が存在します。相手の知識レベルを考慮せずに質問すると、理解されにくい場合があります。特に異なる専門分野のエンジニア同士でのコミュニケーションでは、このギャップが顕著です
2. 文脈不足：技術的な質問は文脈に依存することが多いです。質問が特定のコードやシステム、状況に関連している場合、それらの背景情報を十分に伝えないと、相手が問題を理解するのが難しくなります
3. 具体性の欠如：技術的な問題はしばしば複雑で、抽象的な質問では問題の核心を伝えにくいです。具体的な例やエラーメッセージ、再現手順などを提供することで、相手が問題を正確に理解しやすくなります
4. 複数の問題を一度に提示：一度に多くの問題や疑問を提示すると、相手がどこに焦点を当てるべきか分かりにくくなります。質問を分割し、一つずつ取り組む方が効果的です
5. 環境や設定の違い：エンジニアリングでは、環境や設定が問題に大きく影響することがあります。質問する際に、自分の開発環境や使用しているツール、バージョンなどの情報を共有しないと、相手が同じ状況を再現できないことがあります
6. 期待する答えが明確でない：質問の目的や期待する答えが不明確だと、相手はどのような答えを返せばよいのか迷います。具体的にどのような情報やアドバイスを求めているのかを伝えると、回答が得られやすくなります

どれも模範回答であると思います。ですが、これらが本当にあなたの問題解決になっているのでしょうか？
中には、上記全てを試したけどうまくいかない、という方もいると思います。

何が根本的に足りないか？

それは、あなたの「一番伝えたいメッセージ」がないからかもしれません。
具体的な例を以下に挙げます。

具体例

ある高名な教育者の講演会があって、そこに参加したAさんとBさんのアンケート用紙に次のような感想が書かれていました。

• Aさん「今朝は久方ぶりに高く晴れた空を見上げながら、秋色に萌ゆる銀杏並木の道を一歩々々、踏みしめるように会場に参りました。初めて拝見した先生の御姿は清々しく、それでいて威厳に実ていました。会場に響き渡る声は美しく澄み渡り、どこまでも凛としていました。このような希有な機会を頂戴しましたこと、心より感謝申し上げます。ご縁がございましたら、また是非とも御話を拝聴させていただきたく存じます」

• Bさん「めちゃくちゃ反省。涙が出ました！やっぱり人は大事にしなくちゃです。ありがとうございました！」

いかがでしょうか？

AさんとBさんの文章の違い

• Aさん
  • 高尚な言葉が並んでいて、文章としてそれらしさのようなものはあります。しかし書かれている事柄に一貫性はなく、後半は定型に近いあいさつ文が並んでいるだけです
  • これを読んだ人が納得や共感を覚える（気持ちや心を動かす）ことは、あまり期待できなそうです
  • 「それっぽいけど、何を言いたいのか分からない」と捉えられやすい

• Bさん
  • 言葉遣いはどちらかといえば雑
  • 内容も断片的で、情報量も十分ではないかもしれません
  • でも、「伝えようとしていること」はちゃんとわかります。

（余談）
私も前職でビジネスメールの書き方について厳しく指導を受けたので、時々Aさんのようなお堅い文章になりがちなので、簡潔に伝えるように注意しています💧

最大の違い

それは、Bさんは頭の中で「伝えるべきこと」がはっきりイメージされていることです。

「伝えるべきこと」が明確に意識できていると、何を書くべきか、どう書くべきかの判断がつきやすく、必要な情報を見極めることができます。

その結果、少しくらい表現が雑でも、構成が整ってなくても、盛り込む情報がきちんと盛り込まれた文章になりやすいので、伝わりやすくなります。

著書「伝え方――伝えたいことを、伝えてはいけない。」より引用

伝えたいことだけで何が伝わるっていうんだ

「それでも、エンジニアとして仕事する上では伝えたいことだけでは伝わらないんじゃない？」
そう思った方もいるでしょう。その通りです。

エンジニアリングの問題は、特定の条件や環境で発生します。具体的な情報（例：エラーメッセージ、発生した状況、使用しているライブラリのバージョンなど）がないと、他のエンジニアがその問題を把握するのが難しくなります。

想いだけでも、（文章を書くための）技術だけでもダメなのです。

相手に具体的な情報を伝えるための例を以下に挙げます。

状況別の具体的な質問例

エラー発生時の質問

• 悪い例: 「このプログラム、動かないんですけど。」
• 良い例: 「このプログラムを実行すると、〇〇行目で『NullPointerException』というエラーが発生します。原因として考えられるのは、〇〇変数がnull値になっていることでしょうか？デバッグログを見ると、〇〇メソッドの呼び出し時にnullチェックが漏れているようです。」
• ポイント:
  • エラーメッセージを正確に伝える
  • 発生状況（入力値、環境など）を具体的に説明する
  • 考えられる原因を推測し、質問することで、より効率的に解決策を探せる

コードレビュー時の質問

• 悪い例: 「このコード、これで合ってるのかな？」
• 良い例: 「この部分で、なぜ〇〇というアルゴリズムを選択したのでしょうか？△△というアルゴリズムの方が、計算量が少ないように思えるのですが。」
• ポイント:
  • 特定のコード部分に焦点を当て、疑問点を明確にする
  • 代替案を提示することで、より建設的な議論を促す
  • コードの意図や設計思想を理解しようとする姿勢を示す

機能追加に関する質問

• 悪い例: 「新しい機能を追加したいんですけど、どうすればいいですか？」

• 良い例: 「既存の〇〇機能に、△△という機能を追加したいと考えています。実現するために、以下のステップで進めることは可能でしょうか？」

  1. 〇〇モジュールを拡張する
  2. △△インターフェースを実装する
  3. 既存のテストケースを修正する

• ポイント:

  • 具体的な機能追加の目的を説明する
  • 実現するための具体的な手順を提案し、共同で解決策を検討する

システム設計に関する質問

• 悪い例: 「このシステム、もっと効率的にできないかな？」
• 良い例: 「現在のシステムでは、〇〇処理に時間がかかっています。ボトルネックとなっているのは、△△モジュールであると考えています。このモジュールを並列処理にすることで、処理時間を短縮できる可能性はあるでしょうか？」
• ポイント:
  • 問題点を具体的に指摘し、改善案を提示する
  • システム全体の構造や各モジュールの役割を理解していることを示す

良い例の共通点

• 具体性: 問題の詳細、エラーメッセージ、影響を受けているコードの部分など、具体的な情報が提供されています。これは、他のエンジニアが問題を理解し、迅速に対処できるようにするために重要です

• 発生状況の説明: 問題が発生した状況（入力値、環境、行なった操作など）が説明されています。これは、他の人が同じ問題を再現しやすくし、正確な解決策を提供するために役立ちます

• 仮説と提案: 自分の考えた原因や解決策の仮説が含まれています。これは、質問者が問題について既に考えを持っていることを示し、他のエンジニアがその仮説を検証したり、改善案を考えるのに役立ちます

• 明確な焦点: 特定の部分や問題に焦点を当てています。広範な質問よりも、特定の問題に絞った質問の方が回答が得やすく、解決も早くなります

• 建設的な姿勢: 単に問題を報告するだけでなく、改善のための意図や他者の意見を求める姿勢を示しています。これにより、建設的な議論が促進され、より良い解決策が見つかりやすくなります

悪い例の共通点

• 抽象的で曖昧: 質問が漠然としていて具体的な情報が不足しています。例えば、「このプログラム、動かないんですけど。」や「このコード、これで合ってるのかな？」では、何が問題なのかが明確でなく、他の人が理解して手助けするのが難しいです

• 詳細な情報不足: エラーメッセージ、発生箇所、状況、使用している環境など、問題を解決するために必要な情報が提供されていません。このため、回答者はまず追加情報を尋ねなければならず、解決までの時間が長くなります

• 自分で考えた形跡がない: 問題の原因や解決策についての仮説や自分で試したことが示されていません。これにより、他のエンジニアは質問者がどこまで問題を理解しているかが分からず、どのようにアプローチすべきか判断しにくくなります

• 曖昧な目的: 質問の目的や求めている答えが不明確です。例えば、「新しい機能を追加したいんですけど、どうすればいいですか？」では、どのような機能をどのように追加したいのかがわからず、具体的なアドバイスを提供しにくいです

• 問題の特定箇所が示されていない: 問題がシステム全体なのか、特定のコード部分なのかがわからないため、回答者がどの部分に注目すればよいかがわかりません。これにより、適切な解決策の提供が難しくなります

まとめ

効果的なエンジニア的質問のポイント

• 問題の特定: 具体的に問題を定義する（一番解決したい問題は何かを伝える）
• 背景の説明: なぜその質問をするのか、理由を説明する
• 解決策への貢献: 自分の考えやアイデアを積極的に伝える
• 質問の構造: 簡潔かつ論理的に質問を構成する
• 相手の立場を考慮: 相手の知識レベルや立場を理解する

おわりに

今回の内容がわかれば、「絶対に質問が伝わる！」、「あなたは完璧で究極なエンジニアになれる！」というわけではありません。

「質問して伝わらないことはコミュニケーション上でよくあること。それでも伝えたいことが相手に伝わるように何回も実践して失敗を繰り返してできるようになります」
（というのを1年目の自分にも言い聞かせたかったです...）

駄文になりましたが、最後まで読んで頂きありがとうございました！

参考記事

• 著書「伝え方――伝えたいことを、伝えてはいけない。」