はじめに
不具合が発生した時の対応について、まとめてみました。
やり方は色々あると思うので、これがあっているという訳ではありませんが、自分がこれまでやってきたことが少しでも誰かのためになればと思い書いてみました。
不具合発生時の流れ
- 再現確認・発生手順の明確化
- 再現時のログを取得する
- 上長、リーダーに報告
- どこが問題かの切り分け
- 原因調査
- 上長、リーダーに報告
- 対策検討・工数見積もり
- 上長、リーダーに日程調整
- 実装資料の作成
- 実装/コードレビュー
- 改修評価
- 修正したソースをコミット
※報告する相手は現場による
#1. 再現確認・発生手順の明確化について
不具合の報告を受けたら、その現象が本当に再現するかを確認します。
どういう条件、環境のもとで不具合が発生したのか、しっかり報告者からヒアリングして、
出来るだけその環境に近づけて確認します。
#2. 再現時のログを取得する
1.で再現できたら、その時のログを取得しましょう。現場によってはログを吐き出してないところもあると思います。
その場合は、自分でログを吐き出すなりして、ログを取得しましょう。このログの情報は、4.で切り分けする時に必要になってきます。
#3. 上長・リーダーに報告
ここは、誰に報告するかは現場によってくると思いますが、一旦必ず現状を報告しましょう。
そのまま、切り分け、原因まで自分で調べてからすぐにわかるなら良いですが、緊急性の高いものだったり、時間がかかりそうなら一旦現状を報告しましょう。
#4. どこが問題かの切り分け
組み込み系だとどこのモジュールなのか。Web系だとざっくりですが、フロントなのかサーバーサイドなのか。
2.で取得したログの情報、ソースコード、(その他設計・実装資料など)を頼りに、どこでおかしくなっているのかを切り分けて行きます。
#5. 原因調査
4.で切り分けができて、うちに問題があった場合、実際のどこの処理でこけているのか、問題が起きていのか原因を調査します。
#6. 上長・リーダーに報告
原因がわかったならば、その内容をすぐに報告しましょう。
#7. 対策検討・工数見積もり
まず、原因から対策方針を検討してきます。
対策方針が決まったら、自己完結せずにレビューをしてもらいましょう。レビューしてもらうことでその方針が問題ないか早めに気づくことができます。
対策方針が定まったら、工数を見積もっていきます。ここで、見積もる時に無理な見積もりはやめましょう。急いで修正してデグレを引き起きしてしまう方がなおさら最悪です。8.で調整ができるのであれば、自分が本当にできる工数 + リザーブ(2日)
で見積もるとよいかと。
#8. 上長、リーダーに報告し、日程調整
7.で見積もった内容を報告。
もし、それでもっと早く仕上げてくれってなった場合は、人をかけるなりして対応しましょう。
#9. 実装資料の作成
自分の場合、こんな感じで資料に残して実装資料を作成しています。
めんどくさいと思うかもしれませんが、後から見返したときになんでこんな実装したんだっけとか、
意味の無いな実装をしないようにするためです。
- 原因
- 混入経緯(いつ混入?わからなくても予測)
- 他に似たような問題がないか(機能又はソース)
- 再発防止策(原因と混入経緯から作り込みによる防止/確認時に置ける防止策)
- どのように修正するか
- その修正での影響範囲
#10. 実装/コードレビュー
実装が完了したら、ミスや考慮漏れを防ぐためにその内容をレビューしてもらいましょう。
レビューを依頼するときは、どのような観点で見て欲しいかを事前に伝えておくと、レビューの
質がよくなります。