バグ分析会、始めました！初期運用で見えた成果と課題
こんにちは！株式会社カンリーエンジニア部の影山です。
私は現在、Dev2チームに所属しており、その中でカンリーホームページとカスタムシリーズでQAを担当しています。
なんと前回のテックブログから1年半以上経過してました。月日の流れが早過ぎます。
前回までの記事は以下になりますので、興味のある方はぜひご覧ください！
私たちのチームでは、チームの品質意識向上の施策の一環として「バグ分析会」を導入しました。
今回はバグ分析会導入の背景や目的、実施方法、そして導入による効果や課題について書いてみようと思います。
導入に際してバグカテゴリの分類等は以下の記事を引用・参考にさせていただきました。この場を借りて御礼を申し上げます🙇♂️
バグ分析会を導入した背景
2年近く同じプロダクトを担当していると、「あれ？これ前にも発生していた不具合なのでは...?」とデジャブを感じることが多くなってきました。（実際に過去に発生していた不具合と原因が同系統でした）他にも似たようなことが発生していたことから、新たな施策を進める段階に来たと判断して、バグ分析会導入に向けて活動を始めました。
導入検討するにあたって、現状の不具合に対するフローを考えてみると、修正した不具合を原因から含めて周知できていない状態であることが原因の1つなのではないかと考えました。
不具合が確認された場合は以下フローで進めるのですが、このフローではフロー外の開発者は自発的にバグチケットを参照しに行かないと、どのような不具合だったのか、何が起因で発生したのか、どのような解決方法だったのかが不明となっている状況です。
そのため、類似事象の不具合が発生することが数回に渡って発生することもあり、バグ修正に時間が割かれ、開発効率が低下していました。
バグ分析会開催に向けて検討開始
「分析会やるぞ！」といきなり言われても開発者は困惑します。（当たり前）
分析会を実施するにあたって、どのような目的や方法で進めるのか、実施した結果どのようなアウトカムがもたらされるのか。私ともう1名のQAエンジニア、EMの3人でディスカッションを重ねていきました。
ちなみに当時の議事録を振り返ると2ヶ月近く議論しています。当時の私の脳内ではカンペキなプラン（スタートまで2週間でイケると思ってた）をイメージしてましたが、実際にチームに導入を考えると考えるべきことはたくさんありました。ままならないね。
簡単ですが決めたことを抜粋して書いておきます。導入を検討中の方がいれば参考にしてもらえると嬉しいです。
バグ分析会の目的
検討段階では様々な目的を考えましたが、最終的に柱となる目的と副目的3つに絞ることにしました。
チームの品質意識向上
根本原因の特定
分析結果の振り返りとバグの傾向把握
根本原因の対策検討とNextActionの決定
バグ分析会の効果
目的と合わせて、実施した結果から得られる効果も考えました。こちらは実際に回数を重ねることで変わってくるものではあるのであくまでも暫定的なものになります。
プロダクトの健全性を視覚的に測れる
バグのカテゴリを分類して管理することで傾向と改善の推移がわかる
バグ傾向を学習することで対策を立てやすくなる
対策の実践で不具合発生率が抑えられ開発速度の向上が見込める
分析結果から新規のテスト観点の創出
分析方法の決定
初めて知ったフレームワークも多かったのですが(というか殆ど初見)、各位で読み合わせた結果、「なぜなぜ分析」と「ImSAFER」のいずれかを予定していました。しかし、分析会参加に障壁を感じて欲しくなかったので「なぜなぜ分析」を軸としつつもあまり形式的な形にならないように進めることにしました。
この辺りは所属するチームの雰囲気で変わるかと思うので参考までに。
バグ分析会の実施方法
準備
頻度: Sprint終わりのタイミングに30分
30分で終わらなかった場合は別日か次回に持ち越し
参加メンバー: EM、PdM、開発者
分析対象: 対象のSprintで発生したバグで影響範囲が広かった事象が優先対象
進行手順
バグ分析会の目的説明
分析をする都合上、バグを作り込んでしまった開発者に批難が集まるといった事態にならないように、批判や責任追及ではなく、改善を目指す場であることを強調します。
バグの概要説明:
発生した事象をQA側から解説をして、修正担当者には何が原因でバグとなってしまっていたのか、修正したコードを確認しながら解説してもらいます。
原因分析:
上記を踏まえて「原因」の深掘りと「対策」の検討を行います。
「対策」はそもそも対策自体が必要なのかどうかから検討をします。
何回か実施して分かったのですが、必ずしも決定的と思われるような対策をすることができない事象であったり、別件のPBIを対応することで根本解決に至る場合もあるため、対策することが可能なのかどうかから検討を進めていきます。対策案を出し合い、実現可能な対策を決定。次Sprintのタスクとして計上します。
導入してみた結果
現在、2チームに導入しておりますがどちらも実施回数はまだ少ないのですが、開発者からは好評いただいており一安心しています。
（心配性なので開催まで不安で悶々とした日々を過ごしていました）
Good
開発を行う際に分析で得られた結果を踏まえて開発着手してもらえるようになってきた
想定よりも開発者同士で原因や対策について考えていることを積極的に議論されることが多く、各位が情熱を持って開発に臨んでいることがわかった
修正完了時に類するバグカテゴリを選択していくことで、開発者自身がどの傾向で不具合を作り込んでしまっているか認知できるようになってきた
この活動を通してQAに興味を持ったので自発的にソフトウェアテストに関する勉強を取り組み始めた
More
始めたばかりなのでデータを用いた分析結果をエンジニアに還元出来ていない
具体的な対策ではないパターンの継続的なフォローの仕組みが出来上がっていない
まとめ
バグ分析会を始めてまだまだ課題もありますが、着実に成果を積み上げこの活動を通じて、チームの品質意識向上だけでなく、プロダクトの品質強化にも繋がっていくことを目指していきます。引き続き試行錯誤を重ねながら、より良い開発チームを目指していきます！
さいごに
株式会社カンリーでは一緒に働く仲間を募集しています！
カンリーのバリューに共感できる方、ちょっと話を聞いてみたいという方、ぜひご応募ください！
また、投稿時点ではQAエンジニアも募集しております。
カジュアル面談からでも大丈夫ですので、興味のある方は直接ご応募いただくか、私のXにお問い合わせいただいても大丈夫です！
