現場で教わった「不具合一次切り分け」の思考フローをまとめてみた

Posted at 2025-07-26

はじめに

私が新人として現場に入って最初に任されたのが「不具合の一次切り分け」でした。

最初は「何から手をつけていいか分からない」「ログってどれを見ればいいの？」という状態でしたが、
経験を積むうちに、だいたい毎回やることがパターン化していることに気づきました。

そこで今回は、現場で教わった「一次切り分け」の思考フローをまとめてみました。

配属されたばかりの新人SE・PGの方

技術サポート・運用保守を担当している方

「まずは一次切り分けをして」と言われて困った経験がある方

「不具合の一次切り分け」とは、発生した問題がどこに原因がありそうかをざっくり分類することです。いきなり修正に入る前に、

再現性があるか

どの層で起きているか（画面／サーバー／DBなど）

ログにエラーは出ているか

仕様通りの挙動か

といった観点で問題を観察・整理しておくことで、調査やエスカレーションの精度が上がります。

以下のようなフローで思考を整理しています。

不具合報告を受ける
↓
現象を確認（再現条件・操作手順・画面キャプチャなど）
↓
再現確認（自分の端末 or テスト環境）
↓
ログ確認（画面ログ、サーバーログ、SQLログなど）
↓
原因の切り分け（有識者がいないと難しい場合が多め）
├── 画面のバグ？（画面上の挙動だけおかしい）
├── サーバー側？（例外発生、APIが失敗）
├── DB？（データ不整合、SQLエラー）
└── 環境依存？（特定端末のみ、特定条件でのみ発生）
必要に応じて開発者 or インフラ担当にエスカレーション

ログインユーザーや権限による差異は？

他ユーザーや他端末では再現するか？

ブラウザ依存・バージョン依存はあるか？

最新リリースで影響を受けているか？

再現性の確認に時間をかけることで、「ただの操作ミス」や「仕様通り」なケースを早期に除外できる

ログのどこを見れば良いかが分かってくる

開発チームや上司に相談する際、「ここまで確認しました」と自信を持って話せる

配属直後、「何から見たらいいか分からない」状態だった私にとって、このフローを身につけたことは大きな前進でした。

不具合対応は慣れも必要ですが、「まず何を見るか」が定まるとずっと楽になります。
この記事が、同じように悩んでいる誰かのヒントになれば幸いです。