インターン生ぶりのインシデントに対して一人で内省する

原因分析

直接的な要因

• コードのバグ

  • 互換性を無視してクエリに修正を加えてしまっていた

根本的な要因

• レビュー漏れ

• 互換性を考えた動作確認

• 互換性を考えたテストの作成

• PRの粒度が大きく、レビューコストが高くなっていた

• 受け入れ条件がしっかり書かれていない

再発防止策(個人的に考えられる施策)

• 受け入れ条件が丁寧に書かれているべき

  • 受け入れ条件をオーナーが責任を持って書く？

  • そもそも受け入れ条件をしっかり書かずに開発を続けているチームに課題感がある

    • 今思えば、受け入れ条件をしっかり書かなかったからバックログやタスク分割に漏れがあった

    • 小さいインシデントで良かったが、今後大きいインシデントに繋がる恐れがある

      • これはgaku-sanに壁打ちしたい

• PRの粒度は小さく保つ

  • これは個人で意識すればやれるレベルのエンジニアが集まっているので、意識と声掛けで収束できそう

インシデント対応中の自身の内省

良かったこと

• 修正PRをすぐ着手し始めたこと

• インシデントレポートに投稿したこと

悪かったこと

• 意思と意図を持たずに取り急ぎのPRを作成したため、レビューされた時即回答することができなかった

  • 元々の既存コードを完全に理解できていなかったので、今回のPBIで起こらないようにしたいな

• 今何をやっているかをスレッドに遠慮なく書かなかったため、作業が暗黙知になりかけた

  • 周りがサポートしてくれた

NextAction

• 既存コードを理解できていれば対応もスムーズだったので、今のPBIドメインは理解しておく

  • 土日の勉強に持っていく

  • コードレビューで極力疑問を無くす

    • 「自分に聞かれたら綺麗に言語化できるか？」を問うようにする。

  • もし既存コードを理解できていない状態でPRを出す時は、焦らず仕様とコードを理解してから出す

• sqlcを使ったテーブルアサートはリポジトリから取ってきたドメインを引数に入れるのではなく、expectedとして用意する必要がある。早急に修正PRを出す必要がありそう

• インシデント時は今自分が何をやっているかを大袈裟に書き出す