バグ分析会、始めました!初期運用で見えた成果と課題|株式会社カンリー 公式note
こんにちは!株式会社カンリーエンジニア部の影山です。 私は現在、Dev2チームに所属しており、その中でカンリーホームページとカスタムシリーズでQAを担当しています。 なんと前回のテックブログから1年半以上経過してました。月日の流れが早過ぎます。 前回までの記事は以下になりますので、興味のある方はぜひご覧ください! ...
https://note.com/canly/n/n25affb705af5
※このストーリーは、noteで発信した記事を転載しています。
こんにちは!株式会社カンリーエンジニア部の影山です。
私は現在、Dev2チームに所属しており、その中でカンリーホームページとカスタムシリーズでQAを担当しています。
なんと前回のテックブログから1年半以上経過してました。月日の流れが早過ぎます。
前回までの記事は以下になりますので、興味のある方はぜひご覧ください!
私たちのチームでは、チームの品質意識向上の施策の一環として「バグ分析会」を導入しました。
今回はバグ分析会導入の背景や目的、実施方法、そして導入による効果や課題について書いてみようと思います。
導入に際してバグカテゴリの分類等は以下の記事を引用・参考にさせていただきました。この場を借りて御礼を申し上げます🙇♂️
2年近く同じプロダクトを担当していると、「あれ?これ前にも発生していた不具合なのでは...?」とデジャブを感じることが多くなってきました。(実際に過去に発生していた不具合と原因が同系統でした)他にも似たようなことが発生していたことから、新たな施策を進める段階に来たと判断して、バグ分析会導入に向けて活動を始めました。
導入検討するにあたって、現状の不具合に対するフローを考えてみると、修正した不具合を原因から含めて周知できていない状態であることが原因の1つなのではないかと考えました。
不具合が確認された場合は以下フローで進めるのですが、このフローではフロー外の開発者は自発的にバグチケットを参照しに行かないと、どのような不具合だったのか、何が起因で発生したのか、どのような解決方法だったのかが不明となっている状況です。
そのため、類似事象の不具合が発生することが数回に渡って発生することもあり、バグ修正に時間が割かれ、開発効率が低下していました。
「分析会やるぞ!」といきなり言われても開発者は困惑します。(当たり前)
分析会を実施するにあたって、どのような目的や方法で進めるのか、実施した結果どのようなアウトカムがもたらされるのか。私ともう1名のQAエンジニア、EMの3人でディスカッションを重ねていきました。
ちなみに当時の議事録を振り返ると2ヶ月近く議論しています。当時の私の脳内ではカンペキなプラン(スタートまで2週間でイケると思ってた)をイメージしてましたが、実際にチームに導入を考えると考えるべきことはたくさんありました。ままならないね。
簡単ですが決めたことを抜粋して書いておきます。導入を検討中の方がいれば参考にしてもらえると嬉しいです。
検討段階では様々な目的を考えましたが、最終的に柱となる目的と副目的3つに絞ることにしました。
目的と合わせて、実施した結果から得られる効果も考えました。こちらは実際に回数を重ねることで変わってくるものではあるのであくまでも暫定的なものになります。
初めて知ったフレームワークも多かったのですが(というか殆ど初見)、各位で読み合わせた結果、「なぜなぜ分析」と「ImSAFER」のいずれかを予定していました。しかし、分析会参加に障壁を感じて欲しくなかったので「なぜなぜ分析」を軸としつつもあまり形式的な形にならないように進めることにしました。
この辺りは所属するチームの雰囲気で変わるかと思うので参考までに。
準備
進行手順
現在、2チームに導入しておりますがどちらも実施回数はまだ少ないのですが、開発者からは好評いただいており一安心しています。
(心配性なので開催まで不安で悶々とした日々を過ごしていました)
バグ分析会を始めてまだまだ課題もありますが、着実に成果を積み上げこの活動を通じて、チームの品質意識向上だけでなく、プロダクトの品質強化にも繋がっていくことを目指していきます。引き続き試行錯誤を重ねながら、より良い開発チームを目指していきます!
株式会社カンリーでは一緒に働く仲間を募集しています!
カンリーのバリューに共感できる方、ちょっと話を聞いてみたいという方、ぜひご応募ください!