初心者SEが現場に入って最初につまずきやすいことの一つが、質問の仕方です。
分からないことがあるのは当然です。むしろ、分からないまま作業を進める方が危険です。ただし、質問の仕方によって、相手がすぐに答えられる場合もあれば、状況確認からやり直しになる場合もあります。
私自身、現場で質問する側、質問を受ける側の両方を経験してきました。その中で感じるのは、質問がうまい人は「答えを聞く前に状況を整理している」ということです。
この記事では、初心者SEが現場で質問するときに意識したい伝え方を、現役SEの実務目線で整理します。
この記事でわかること
- 初心者SEが質問でつまずきやすい理由
- 現場で伝わりやすい質問の組み立て方
- 質問前に整理すべき情報
- 報告・相談・確認を分ける考え方
質問は早い方がよいが、丸投げは避ける
現場では「分からないことは早めに聞いてください」と言われることがあります。
これは正しいです。分からないまま長時間悩むと、作業が止まったり、間違った方向に進んだりします。
ただし、早く聞くことと、何も整理せずに聞くことは違います。
たとえば、次のような質問は相手が答えにくいです。
- 動きません
- エラーになりました
- どうすればいいですか
- よく分かりません
これだけだと、何が起きているのか、どこまで確認したのか、何を判断してほしいのかが分かりません。
質問する前に、最低限「何をしようとしているのか」「どこで止まったのか」「何を試したのか」を整理すると、相手は答えやすくなります。
失敗例1：目的を伝えずに質問する
初心者の質問でよくあるのが、目的を伝えずに細かい操作だけを聞いてしまうケースです。
たとえば、「この設定はどこで変えますか」と聞かれても、何のために変更したいのかが分からないと、正しい答えを返しにくいです。
設定を変えること自体はできても、その変更が本当に必要なのか、別の方法が安全なのか、影響範囲があるのかは目的によって変わります。
実務では、質問の前に目的を伝えることが大切です。
- 何を実現したいのか
- どの作業の中で困っているのか
- 最終的に何を確認したいのか
- 今の自分の理解はどこまでか
目的が分かると、相手は単に答えを返すだけでなく、より安全な進め方を提案しやすくなります。
失敗例2：試したことを伝えない
質問するときに、試したことを伝えないと、同じ確認を何度も繰り返すことになります。
たとえば、エラー調査で質問する場合、次の情報があるとかなり答えやすくなります。
- どの画面や処理で起きたか
- エラーメッセージの内容
- ログのどこを見たか
- 自分だけで再現するのか
- 直近で変更した箇所はあるか
- すでに試した対応と結果
これらを伝えると、相手は次に見るべきポイントを絞りやすくなります。
開発環境やエラーの切り分け方については「開発環境で動かないときの切り分け方」でも解説しています。
失敗例3：報告・相談・確認が混ざっている
現場では、質問だけでなく、報告や相談も必要になります。
この3つが混ざると、相手が何を求められているのか分かりにくくなります。
| 種類 | 目的 | 伝える内容 |
|---|---|---|
| 報告 | 状況を共有する | 何が完了したか、何が起きたか、現在の状態 |
| 相談 | 方針を決める | 選択肢、迷っている点、判断してほしいこと |
| 確認 | 認識を合わせる | 自分の理解、前提、合っているか見てほしい点 |
| 質問 | 分からないことを聞く | 知りたいこと、試したこと、詰まっている箇所 |
たとえば、「A案で進めてもよいでしょうか」は確認です。「A案とB案で迷っています」は相談です。「A案で対応しました」は報告です。
最初に「相談です」「確認です」と言うだけでも、相手は受け取りやすくなります。
質問前に整理するチェックリスト
私が質問する前に確認しているのは、次のような項目です。
- 何の作業中に困っているのか
- 最終的に何をしたいのか
- どこまで分かっているのか
- どこから分からないのか
- 何を試したのか
- 試した結果どうなったのか
- 相手に何を判断してほしいのか
このすべてを長く説明する必要はありません。大事なのは、相手が状況を再現できる程度に情報を整理することです。
伝わりやすい質問の例
現場で質問するときは、次のような形にすると伝わりやすいです。
確認です。注文一覧画面の検索条件追加について、仕様書では「取消済みは対象外」とあります。実装ではステータスが取消のデータを除外する理解ですが、削除済みデータも同時に除外する認識でよいでしょうか。既存の検索処理では削除済みも除外していたため、同じ扱いにする想定です。
この質問では、目的、確認したいこと、自分の理解、根拠が含まれています。
ここまで整理されていると、相手は「その認識でよいです」「削除済みは別条件です」のように答えやすくなります。
質問が遅れるより、途中で確認する方がよい
初心者のうちは、質問すること自体に遠慮してしまうことがあります。
しかし、分からないまま作業を進めて大きくズレるより、途中で確認する方が安全です。
特に、次のような場合は早めに確認した方がよいです。
- 仕様の解釈が複数ありそうなとき
- 既存処理と違う実装になりそうなとき
- 影響範囲が分からないとき
- 作業時間が想定より伸びているとき
- エラー原因の仮説が立たないとき
レビュー指摘への対応でも、意図が分からない場合は早めに確認することが重要です。関連する考え方は「レビュー指摘を受けた後の直し方」でもまとめています。
AIを使うなら質問文の整理に使う
AIは、質問内容を整理する補助にも使えます。
ただし、案件名、顧客名、個人情報、機密情報をそのまま入力しないように注意が必要です。
たとえば、次のように使うと安全です。
以下の状況を、先輩SEに質問する文章として整理してください。目的、試したこと、確認したいことが伝わるようにしてください。固有名詞は使わず、一般的な表現にしてください。
AIに質問文を整えてもらうと、自分の理解が足りない部分にも気づきやすくなります。ただし、最終的に事実関係が正しいかは自分で確認する必要があります。
まとめ：良い質問は相手の時間を減らす
初心者SEが現場で質問するときは、分からないことをそのまま投げるのではなく、状況を整理して伝えることが大切です。
目的、試したこと、分かっていること、困っている点、判断してほしいこと。このあたりが整理されていると、相手は答えやすくなります。
質問は遠慮する必要はありません。ただし、相手が状況を理解できる形にして聞くことが重要です。
良い質問は、自分の作業を進めるだけでなく、相手の確認時間も減らします。現場で信頼されるSEになるためにも、質問・報告・相談・確認を分けて伝える習慣を身につけておきましょう。
