仕事で質問する前にどこまで調べる？SEの相談目安と質問文の作り方
仕事で質問する前に、答えまで出す必要はありません。試し方を変えても新しい手掛かりが増えないときは、分かったことと相手に聞きたいことを一文ずつ書き、そこで相談します。障害や納期への影響が見えた場合は、原因を調べている途中でも先に共有します。
障害や期限が迫る場面では、調査完了を待たず共有する
本番障害、顧客への影響、個人情報や権限の問題、締切に間に合わないおそれがある場合は、調査完了を待たずチームのルールに従って共有します。「原因は未特定」でも、発生時刻や影響範囲は伝えられます。質問の準備より初動連絡が先です。
普段の不明点でも、権限がなくて画面を開けない、仕様を決めた担当者しか答えられないと分かったら、その時点で相談します。検索を続けても、自分の権限や決定権は増えません。
https://ryman-money.tokyo/log-analysis/最初に目的と期待する状態を一文にする
「SQLが分かりません」だけでは、相手もどこから聞けばよいか迷います。「対象日のデータを取りたいが、終了日当日の行だけ抜ける」なら、期待した結果と実際の違いが伝わります。使っている技術の名前より、何を実現したいかを先に書きます。
設計書や公式資料を読み、再現手順とエラーメッセージをそろえます。その際、事実と予想は分けます。「データが存在することは確認済み。日付条件が原因ではないかと考えている」と書けば、相手が確かめ直す必要のある箇所も分かります。
同じ確認を繰り返したら調査を区切る
同じ検索語で同じページに戻る。条件を変えて試しても、結果から新しいことが分からない。自分にない権限が必要になる。この状態が続くなら、そこまでに分かったことを短くまとめて相談する区切りです。
| 現在の状態 | 次の動き |
|---|---|
| 新しい手掛かりがあり、低リスクで確認できる | 確認する内容と区切りを決めて続ける |
| 同じ確認を繰り返し、判断材料が増えない | 目的と試した結果をまとめて相談する |
| 権限・仕様判断・他担当の確認が必要 | 誰に何を確認したいか示して依頼する |
| 本番影響や期限への懸念がある | チームの連絡ルールに従い早く共有する |
チームで「最初の30分で一度共有する」と決める方法もありますが、30分がどの職場でも正解というわけではありません。軽い疑問と障害を同じ扱いにせず、先輩やリーダーと普段の相談目安を決めておくと迷いが減ります。
質問文は「目的・事実・試したこと・仮説・質問」の順に
質問は、目的、分かった事実、試したことと結果、仮説、聞きたい点の五つで組み立てます。短く伝えて、ログや詳しい手順は別のメモへ置けば、相手が最初から長文を読み込まずに済みます。
以下は架空の社内相談です。ログやデータを添える場合は社内の取扱いルールに従い、機密情報や顧客データを社外の質問サイトやAIへそのまま貼らないでください。
対象日の注文だけ抽出したいのですが、終了日当日のデータが取得できません。対象データが存在することと、実行時の検索条件は確認済みです。終了条件を変更すると件数が変わるため、日時の境界の扱いが関係していると考えています。仕様書の「終了日を含む」が、翌日0時未満という理解でよいか確認したいです。使用した条件と件数をメモにまとめています。
この相談なら、相手は日付境界の仕様に答えればよいと分かります。相手に答えてほしい点を一つに絞ると、回答もその後の作業も進めやすくなります。
再現例は小さくし、分からないことは残してよい
コードを見てもらうなら、関係する処理、入力、期待結果、実際の結果に絞ります。サイボウズの開発者コミュニティでも、実現したいこと、試した内容、エラー情報や実行コードを伝える方法が案内されています。社内でもログを丸ごと送るより、どの入力で何が起きるかを示すほうが、相手が試すまでの負担を減らせます。
再現のために、承認なしで本番データを書き換えてはいけません。再現できない場合は、発生したときと今で条件が違う箇所や、まだ試していないことを伝えます。不明な部分を、もっともらしい推測で埋める必要はありません。
回答を受けたら、理解した内容と次の行動を返す
回答をもらったら、「終了日は翌日0時未満で判定し、境界のデータも試験します」のように、理解した内容と次の作業を返します。解釈が違っていれば、手を動かす前に相手が訂正できます。
解決後のメモには、結論と、判断に使った資料や条件を残します。「日付の条件はこうする」とだけ残すより、どの仕様に基づく答えかまで分かるほうが、次の案件で使えるかを見極められます。