「ログを開いたけれど、どこから見ればよいのか分からない」
「検索結果をいろいろ試したのに、原因へ近づけない」
新人SEにとって、エラーや不具合の調査は難しく感じやすい仕事です。ログには大量の情報があり、検索結果にはさまざまな原因と対処法が並びます。最初から正解を当てようとすると、どこから手をつければよいか分からなくなります。
調査で大切なのは、勘のよさではありません。推測と事実を分け、確認する範囲を絞り、原因候補を一つずつ減らすことです。
私も銀行システムの開発・保守に25年以上携わり、さまざまな障害や問い合わせを調査してきました。複雑な問題ほど、派手なひらめきよりも、「いつ・どこで・何が起きたか」を丁寧に確認する基本が効きます。
この記事では、新人SEが身につけたい調査方法を、次の3つに分けて解説します。
- ログから対象範囲を絞る
- エラーメッセージを適切に検索する
- 比較によって原因を切り分ける
新人SEの調査は「事象の整理」から始める
ログを読む前に、まず起きている事象を整理します。対象が曖昧なまま調査を始めると、関係のないログや情報へ時間を使ってしまいます。
- いつ：発生日時、最初に起きた時刻
- どこで：本番・テストなどの環境、対象サーバーや画面
- 誰・何に：ユーザー、データ、処理、機能
- 何をしたとき：操作、入力値、実行コマンド
- どうなった：期待結果と実際の結果
- 再現性：毎回・特定条件・一度だけ
「登録できない」ではなく、「テスト環境で新規登録ボタンを押すと、10時15分にエラーコードABC123が表示され、データは登録されない。3回試して3回とも発生する」のように具体化します。
この整理ができると、確認すべきログの種類、時刻、検索語、比較対象が見えてきます。
1．ログは発生時刻と処理を起点に見る
ログを最初から最後まで読む必要はありません。問題が起きた時刻と処理を起点に、対象範囲を絞ります。
最初に確認する5つの情報
- 問題が発生した日時
- 対象の機能、処理、リクエストID
- ERROR、WARN、例外名、エラーコード
- エラー直前に実行された処理
- 同じ処理が正常終了したときとの差
画面に表示された時刻とログの時刻が一致しない場合もあります。端末とサーバーの時刻差、タイムゾーン、処理時間を考え、前後に少し幅を持たせて確認します。
エラー行だけでなく少し前から読む
エラーが記録された行は、原因そのものではなく、処理が続けられなくなった結果を示していることがあります。
たとえば、データ取得の失敗が先に発生し、その後の処理で「値がない」という例外が出る場合です。最後の例外だけを見ると、最初の失敗を見落とします。エラーの数行前から処理の流れを追い、最初に異常が現れた場所を探しましょう。
複数ログは共通の手掛かりでつなぐ
Webサーバー、アプリケーション、データベースなど、複数のログを確認する場合は、時刻だけでなく、リクエストID、セッションID、ユーザーID、処理名などの共通項目で同じ処理を追います。
なお、ログには個人情報、認証情報、業務データが含まれる場合があります。取得、保存、共有、外部サービスへの入力は、必ず現場のルールに従ってください。
2．エラーメッセージ検索は情報を絞って行う
エラーメッセージをそのまま全文検索すると、環境固有のパス、日時、ユーザー名などが混ざり、必要な情報が見つかりにくくなります。また、機密情報を外部へ送る危険もあります。
製品名・エラーコード・特徴的な文言を組み合わせる
検索語は次の順で組み立てると絞りやすくなります。
- 製品名、言語、フレームワーク名
- エラーコード、例外クラス名
- 環境に依存しない特徴的な文言
- 必要に応じてバージョンやOS
検索例：「製品名 ABC123 connection timeout バージョン」
検索結果が少なければ文言を減らし、多すぎれば製品名やバージョンを追加します。日本語で見つからない場合は、エラー原文の英語や例外名でも検索します。
公式情報を起点に適用条件を確認する
検索結果の上位にある解決策が、自分の環境にも正しいとは限りません。まず公式マニュアル、サポート情報、リリースノートを確認し、次の条件を照らし合わせます。
- 製品とバージョン
- OS、ミドルウェア、関連ライブラリ
- エラーが発生する条件
- 対処による影響と前提条件
個人ブログやQ&Aサイトは、原因候補を広げる参考になります。ただし、コマンドや設定変更をそのまま本番環境で試してはいけません。根拠と影響を確認し、必要な承認を得てから実施します。
生成AIへ入力してよい情報か確認する
生成AIは、一般的なエラーの意味や調査観点を整理する用途では便利です。一方で、業務ログ、顧客情報、非公開のソースコード、サーバー名などを許可なく入力してはいけません。
利用する場合は、会社のルールと利用可能なサービスを確認し、機密情報を含まない一般化した質問へ置き換えます。AIの回答も確定事項とはせず、公式情報や実環境で検証しましょう。
3．原因切り分けは正常と異常を比較する
原因切り分けでは、思いついた対処を次々に試すのではなく、一度に一つの条件を変えて結果を比較します。
比較の軸を決める
| 比較の軸 | 確認例 |
|---|---|
| 環境 | 本番だけか、テスト環境でも起きるか |
| ユーザー | 全員か、特定ユーザーだけか |
| データ | 全データか、特定条件のデータだけか |
| 時間 | 常に起きるか、特定時間だけか |
| 変更 | リリースや設定変更の前後で差があるか |
| 経路 | 画面、API、バッチのどこまで正常か |
「全員ではなく一人だけ」「すべてのデータではなく特定形式だけ」と分かれば、確認範囲を大きく狭められます。
一度に変える条件は一つにする
設定、データ、実行ユーザーを同時に変えて正常になっても、どの変更が影響したのか分かりません。一つの仮説に対して一つの確認を行い、結果を記録します。
仮説：特定の入力データが原因 確認：同じユーザーで正常データと異常データを実行 結果：正常データは成功、異常データは失敗 次の確認：二つのデータ項目の差分を比較する
この流れを繰り返すと、調査の根拠が残り、途中で先輩へ相談するときも説明しやすくなります。
変更前に安全性と戻し方を確認する
原因確認のための操作が、データ更新、サービス停止、設定変更を伴う場合は、勝手に実施しません。影響範囲、バックアップ、元へ戻す手順、実施権限を確認し、責任者の了承を得ます。
特に本番環境では、「原因を早く見つけたい」という気持ちより、安全を優先します。調査そのものが新しい障害を起こしてはなりません。
調査が進まないときの相談方法
一定時間調べても新しい事実が増えない場合は、調査メモを整理して相談します。次の内容があれば、相談相手も状況を把握しやすくなります。
- 発生事象と影響範囲
- 発生条件と再現性
- 確認したログ、資料、検索語
- 試したことと結果
- 現在考えている原因候補
- 次に確認しようとしていること
「分かりません」ではなく、「ここまでは分かりましたが、この先の確認方法を判断できません」と現在地を伝えましょう。
新人SEの調査チェックリスト
- 発生日時、環境、操作、結果を整理した
- エラーの直前からログを確認した
- 事実と推測を分けて記録した
- 検索語から環境固有情報を除いた
- 製品バージョンと公式情報を確認した
- 正常と異常を一つの条件で比較した
- 変更操作の影響と戻し方を確認した
- ログやソースコードの取り扱いルールを守った
まとめ：調査力は原因候補を減らす力
新人SEの調査では、最初から原因を当てる必要はありません。確認できる事実を増やし、可能性の低い候補を一つずつ除いていくことが大切です。
- 事象を具体化してから、発生時刻と処理を起点にログを見る
- エラーコードと製品情報で検索し、公式情報と環境条件を確認する
- 正常と異常を比較し、一度に一つの条件を確かめる
まずは、調査を始める前に「いつ・どこで・何をしたとき・どうなった」を書き出してみてください。それだけでも、見るべき場所がかなり明確になります。
コメント