はじめに
先日、勤務先のスタートアップで本番環境で発生したバグの対応フローを検討する機会をいただいた。SIerで勤務していた時はバグ対応フローが定義されており、そのフローに従ってバグ対応していた。バグ対応の方法は組織文化や、スピードと品質どちらを優先するかによって変わってくると思うが、参考までに自分の考えを書きとどめておこうと思う。また、本記事ではセキュリティ関連のバグは対象としていないので、ご留意ください。
バグ対応フロー
私の考えるバグ対応のフローは以下の通り。
用語説明
まずはフローの中に出てくる用語を説明する。
- バグチケット: バグの原因、対応内容等を記録するチケット。Jira, Redmine, Backlogなど会社で使用している管理ツールで作成する
- 直接原因: 不具合を引き起こしている直接的な原因。例えば、サーバーから500エラーが返ってきた時、Out of memory(OOM)によって500エラーがでているならOOMが直接原因となる。根本原因を考えるためには、なぜOOMが発生したのかを考える必要がある。
- 暫定対応: バグ修正のためのスピード重視の一時的な対応。例えば、上記のOOMの例であれば、サーバーのメモリを増強すれば不具合は発生しないかもしれない。問題の根本は解決していないので、あくまで根本原因を解決するまでの一時的な対応。
- 根本原因: 不具合を引き起こしている真の要因。上記のOOMの例であれば、なぜOOMが起きているのかを考えると、メモリを大量に処理するロジックが実装されていたり、適切にメモリ解放できてなかったり、根っこの原因が見つかる。
- 恒久対応: 根本原因を解決するための対応。恒久対応をリリースすることで、バグ修正としては完了となる
初めのうちは、直接原因と根本原因の区別が難しいと思う。直接原因と根本原因の分析にはなぜなぜ分析という手法がある。IPAの資料にも記載があるので参考にしてください。
https://www.ipa.go.jp/archive/files/000051042.pdf
バグチケットに記載すること
バグチケットには下記を記載する。必要事項は会社ごとで異なると思うので参考程度としてください。
- 不具合内容
- 期待する動作
- 再現手順
- 影響範囲
- ユーザー影響
- 緊急度
- 直接原因
- 暫定対応
- 根本原因
- 恒久対応
- 再発防止
- 対応履歴
各ステップの詳細
バグ検知
バグ検知のステップで重要なのは、バグなのかどうかをしっかりと見極めることだと思う。私が新米の頃は、システムが要件通り動いているにも関わらずユーザーからこういう動きをしてくれないと困ると言われ、誤ってバグと起票することがあった。システムが要件通り動いているのであれば、バグでなく改善依頼である。
そういった事態を防ぐためにも、組織内でバグとは何なのか、起票すべきバグは何なのかを定義しておくことが大事だと思う。
バグチケット作成
バグ検知したらまず行うことはバグチケットの作成だ。バグチケットを起票することで、バグの対応漏れ防止、情報の集約、対応状況の把握ができる。バグ対応には、社外対応を行うカスタマーサクセスの方や進捗確認するPMなど自分以外の人も関係するので、情報共有のためにもすぐにバグチケットを作成することが大事だと思う。
影響範囲、ユーザー影響、緊急度の判断
バグチケットを起票したら次の目標は暫定対応の要否を判断することだ。暫定対応要否を判断するためには、影響範囲 と ユーザー影響 で判断する。
多くのユーザー(影響範囲)の、UXを大きく劣化している(ユーザー影響)のであれば、緊急で修正が必要だ。私は基本的に 影響範囲 と ユーザー影響 で緊急度を判断しているが、Service Level Agreementが存在する企業はその限りではないかもしれないので、適宜判断して欲しい。
また、ユーザー影響は 発生頻度 と 影響度 に分けることができる。不具合の発生頻度が高頻度で、影響度が大きい(ex. コアなユーザー体験が提供できないなど)のであれば、ユーザー影響は大きくなり、緊急で対応が必要になる。
以上のことを念頭に置きながら、バグチケットに不具合の影響範囲、ユーザー影響(発生頻度と影響度を併せて記載するとgood)を記載し、それらを基に判断した緊急度を記載するとよい。
直接原因の調査
緊急度が把握できれば暫定対応要否は判断できるかもしれないが、直接原因も把握できると修正までにかかる時間や、バグの根深さが判断できるかもしれない。直接原因の調査と暫定対応要否の判断は前後するかもしれないが、状況見ながら適宜判断していただければと思う。
暫定対応要否の判断
バグチケットに記載した影響範囲、ユーザー影響、緊急度を基に暫定対応が必要か判断しよう。基本的には 復旧目標 < 恒久対応リリースまでにかかる見積もり時間 となれば暫定対応が必要になる。社内で暫定対応が必要と判断するルールを決めておくとスムーズに決められるかもしれない。
暫定対応の検討 ~ 暫定対応のリリース
暫定対応が必要であれば、対応内容を検討し、実装、テスト、リリースを行う。この時注意することは下記だと考える。
- バグ修正したと思いきや、新しいバグをリリースしないようにすること(二次災害)
- 単体テスト、結合テスト、STG環境でのe2eテストはしっかりと行うこと
* 二次災害を防止
スピード重視で修正をリリースするのは大事だが、新しいバグを生み出さないように気を付けて。
根本原因の調査~恒久対応のリリース
暫定対応を進めていれば時間は稼げるので、その間に根本原因の調査を進める。根本原因が判明すれば恒久対応の検討を進めて、実装、テスト、リリースとなる。恒久対応がリリース後は、(可能であれば)本番環境でバグ修正されていることを確認して、修正は完了となる。
再発防止策の検討、バグチケットクローズ
再発防止策を検討してバグチケットをクローズします。なぜバグが発生してしまったのかを検討し、デイリースクラムなどで話し合うとチーム全体のレベルが底上げされて良いと思う。
終わりに
今回記載したフローは私がSIer時代に教えてもらったフローなので、バグ対応の1つの形にすぎないと思う。もっと良い方法は世の中にあると思うし、これが正解だと主張するつもりもない。
ただ、組織が大きくなるにつれこういったフローを定義しておくと、対応が属人化せずにサービスの品質が安定するので、大事なことだと思う。皆さんの検討材料の1つとして参考になれば嬉しく思う。
参考
情報処理システム高信頼化 教訓作成ガイドブック(IPA)
https://www.ipa.go.jp/archive/files/000051042.pdf
関連記事
機械学習関連の記事も書いているのでもしよかったらどうぞ。
k-meansを改良したk-means++を説明する
https://zenn.dev/sasshi_i/articles/3f4c25113b1866
k-meansをライブラリを使わずに実装する