障害振り返りの記載項目を考えてみた話

前置き

• もともとQA(品質保証部)やってた時によく振り返りさせられてた
• エンジニア転進＋業界変えたら振り返りの粒度の違いに驚いた
• とはいえかなり細かくするとやらなくなるので、悩みながら粒度は調整
• 何を書かないといけないかが明確に区分けされたことで、導入前よりはマシになった
• ゲーム業界での話
• さらすことで、対外の方に反応ワンチャンいただいて、自分にとっても今後良い振り返りができるようになればいいなという思い

考えてみた振り返り項目

共通項目

No

• 管理用。

状況

• 管理用。以下のステータスを定義
  • 振り返り待ち
  • 振り返り中
  • 再発防止対応中
  • 完了

記載日

• 管理用。

案件名

• 管理用。

担当者

• 振り返り時の責任者。振り返り内容の記載と、振り返りMTG時に説明してもらう人。

事象項目

重篤度（S/A/B/C）

• 大きい障害〜小さい障害までめっちゃ多く発生し、ある程度小さい障害は振り返らない選択を取った。そのための指標。

事象サマリ

• パッとみて、「あ〜あの件ね〜」と分かる記載レベルで記載。

事象詳細（事象についてスクショ撮れる場合はスクショ必須）

• 事象が振り返り時に理解できるレベルで記載。

発生期間

• YYYY/MM/DD HH:mm 〜 YYYY/MM/DD HH:mm
• ユーザの影響度にも関わるので、明確にしておく。

発見経路

• ユーザ報告なのか、開発チーム内で気づけたことなのかを情報として知っておきたいため記載。

対応内容（PR、スクショなど、修正の前後が分かる物）

• どういった修正を行ったかを記載。
• 念のため修正内容の妥当性を確認したかったので書いてもらうようにした。

開発チーム側項目

直接的な原因（作り込み原因）

• 誰がいつ何をして障害の原因を作り込んだかを記載。

作り込み根本原因（なんでそうしたか？）

• 直接的な原因に記載ある事に対し、なぜそうしたのか、なぜ直接的原因が発生したかを記載。
• なぜ？を最低2回追求するようにした。

見逃し原因

• 確認フェーズで見つからなかった原因を記載。
• 実機確認をそもそもしなかったなど
• 仕様書の記載が分かりづらいなどの話であれば、仕様書のURLを貼る。

どのフェーズで見つけるべきだったか？

• どの確認フェーズで誰が見つけるべきだったかを記載。

見逃し根本原因（なんでそうしたか？）

• 見逃し原因、どのフェーズでみつけるべきだったかに記載ある事に対し、なぜそうしたのか、なぜ見逃し原因が発生したかを記載。
• なぜ？を最低2回追求するようにした。

再発防止策

• 上記までの記載内容から、人に依存しない形で再発防止策を記載。
• 気をつけます、頑張りますとか根性論はNG。

再発防止期限

• nextやることを決めたら、それをいつまでにやるかを記載

リーダー確認欄

• 上記までの内容を担保する人のサイン欄。

QA(品質保証部)側項目

検出可能かどうか

• QA側だとどうしても検出が難しいケースがあるので、そもそも検出できるものかどうかを記載。

見逃し原因

• 開発チーム側項目同様

どのフェーズで見つけるべきだったか？

• 開発チーム側項目同様

見逃し根本原因（なんでそうしたか？）

• 開発チーム側項目同様

再発防止策

• 開発チーム側項目同様

再発防止期限

• 開発チーム側項目同様

感想

• 個人的には振り返りMTG時に聞きたいことが前よか聞きやすくなり、MTG中にはだいたい根本原因と再発防止策が明確になった。
• 再発防止を推進する人のやる気がないと、良い再発防止策が出ても意味がなかった（愚痴）

参考

• 改めて誰か項目を公開してないかな？と思い調べていたら良い記事あったので参考文献として……
  エンジニアなら知っておきたい障害報告&再発防止策の考え方