ナレッジワークで取り組んでいるバグ分析の紹介
ナレッジワークQAエンジニアの岡崎（@rabbit_tail14）です。
ナレッジワークでは、プロダクト開発における初期品質およびアジリティを高めるための取り組みとしてバグ分析を行っています。
この記事では、実際に計測しているメトリクスや、どのように運用しているのかなど、できるだけ具体的に記載していきますので、バグを資産として活用したいと思っている方や、既に活用しているが他社の事例も知りたいと考えている方などの参考になれば幸いです。
バグ分析を始めた背景と目的
バグ分析に取り組む前の状況
私は2022年3月にナレッジワークに入社したのですが、当時はまだバグ分析は実施されておらず、対応完了後にバグチケットを見返すことはほとんど行われていませんでした。
そのため、なぜバグが埋め込まれたのかは基本的に対応者しか把握しておらず、個人の知見にしかなっていない状況でした。
一方で、よく耳にするようなデグレが多い、機能開発時におけるバグが多いといった課題は、一貫性のある設計思想やエンジニア自身の高いスキル・品質意識などによりほとんど見られず、プロダクトの品質は比較的良い状態だったと思います。とはいえ顧客やエンジニアの数が増えたり、機能が増えて複雑性が増したりしてくると、その分バグも増えることが想定されるので潜在的なリスクは感じていました。
バグを資産化し、チームの共有知にする
ナレッジワークは社名にもあるように、ナレッジを非常に大切にする会社です。それなのにバグを資産（ナレッジ）として活用しないなんて勿体ないよなという思いや、今後プロダクトや開発チームがスケールしていった際に直面するであろうバグとの付き合い方をチームの共有知とすべく、バグ分析の実施を提案し開発者とともにバグ分析会を実施することになりました。
当時提案した資料の抜粋ですが、開発者に共感してもらい、一緒にバグ分析の活動を行っていくために、バグ分析を行うことで実現したい未来や、バグ分析を行うことでどんな効果がありそうかといったことをまとめて説明しました。
実現したい未来
・バグによって顧客がやりたいことが妨げられない状態
- 品質面でもナレッジワーク良いよね！
・バグに対する知見を増やし、エンジニアの開発生産性を向上させたい
- 以前よりバグ対応が減って機能開発に集中できるようになった！
バグ分析を行うことでどんな効果がありそうか
・プロダクトの健全性を測れる
・バグの傾向が見えてくる
- 報告元ごとの推移やどんなバグが多いのか等
- 傾向が見えてくると適切な対策を立てやすい
・類似バグの発見・予防
・バグの資産化
- 気をつけるべきポイントを学習できる
- 結果としてバグの埋め込みが減り、リードタイム短縮
メトリクスと活動内容
では具体的にどのようなメトリクスを計測し、どのようなやり方でバグ分析を行っているかを書いていきたいと思います。
なお取得しているメトリクスや活動内容は、チームとして何を解決したいかによって変わってくると思うのでチームメンバーで相談して決定できると良いと思います。
メトリクス
バグ分析を行うようになってから何度かアップデートしていますが、現状では以下のメトリクスを収集しています。
バグ件数：開発環境ごと（qa,stg,prd）のバグ検出数
デグレ件数：開発環境ごと（qa,stg,prd）のデグレ件数とその割合
インシデント件数：インシデントレベルごとのインシデント数
発生要因：バグが埋め込まれた要因
検出元：QA検出 or 開発者検出
バグ対応コスト：Sprint開発におけるバグ対応にかかっているコスト
発生要因はいくつかのパターンに分類し、要因として一番近しいものを選択してもらっています。具体的には以下の分類を用意しています。
対象仕様検討不足
対象仕様書記載ミス
対象仕様理解不足
既存仕様理解不足
暗黙ルール
後でやる忘れ
実装ミス
言語/ライブラリ理解不足
作業ミス
外部要因
連携サービス理解不足
その他（原因不明含む）
バグの管理にはJIRAを利用しており、これらの値を収集できるように項目を追加し、バグチケットの登録・修正時にセットしてもらっています。分析はJIRA上でそのまま行っているのではなく、内容をエクスポートし、専用のSpreadsheet（バグ分析シート）に転記して行っています。
活動内容
バグ分析会という名前でSprintごとに30分の時間を確保し、開発者とQAメンバーで、対象Sprintのバグ傾向や気になったバグの深掘りを行っています。
また、半期ごとに分析レポートの作成および分析結果共有会を行い、半期における傾向や前の半期との比較分析などを行う場も設けています。
バグ分析会の進め方は現状以下のように行っています。
バグ分析会までにJIRAの内容をエクスポートし、バグ分析シートに転記
分析対象とするSprintのバグ傾向やトピックのサマリーを記載したドキュメント（分析サマリー）を作成
分析対象のバグチケットのタイトルをFigjamボードに転記
-- ここまでが事前準備--バグ分析会の冒頭で分析サマリーの内容を共有
Figjamに誘導し、深掘りしたいバグを投票してもらう
お客様環境に近い環境で発生したバグから優先的に、得票数が多いバグについて深掘りを行う
学びや対策、ネクストアクションなどを決め、時間になったら解散
30分という限られた時間の中ですべてのバグを深掘りするのは難しいため、優先度を付けて取り扱う対象を決めるようにしています。
バグ分析からの改善アプローチ
バグ分析を行い始めて継続的にバグの発生要因を計測していったところ、仕様検討不足や仕様理解不足系のバグが上位の要因として計上されていることが分かりました。
そこで、QAメンバーが仕様検討段階や設計段階で仕様に対するフィードバック機会を増やしたり強化することで、これらの要因となるバグの埋め込みを減らせるのではと仮説を立て、改善のアプローチを試していきました。
結果として2023年の上期では以下のような結果となりました。一部前年より増加してしまった部分はあるものの、全体としては10%ほど減少しており、改善活動の効果もあった結果になったのではと思っています。
このように発生要因の傾向を見ていくことで、どの要因を減らしたいのか、そのためにはどのようなアプローチを取ると良さそうかといった適切な対策を立てやすくなりますので、ぜひ皆さんも試してみてください。
Good & Opportunity
弊社では組織施策の一つとして Good & Opportunity と呼ばれる、良かったところと成長余地を挙げる文化があります。
それに倣ってバグ分析に取り組んでいった中での Good & Opportunity を最後に書いてみようと思います。
Good
バグを資産として扱い、共有知化する文化が根付いてきた
分析結果から減らしたいバグ要因を特定し、対策を立てて効果が出たところまで確認できた
開発者とQAメンバーの協業が増え、Whole Teamになってきた
QA主催のバグ分析会とは別にフロントエンドメンバーで個別にバグ分析会が行われるなど、バグ分析の文化が広まった
Opportunity
部分的には効果が出てきているが、プロダクト全体の品質や開発者の生産性に対して如実に表れるような効果を生み出せていない
人数やプロダクトも増えてきてバグ分析会運営のリデザインが必要
より良いメトリクスの探求とバグ分析の効率化
おわりに
今回は弊社のバグ分析の具体的なメトリクスと活動内容を紹介しました。
文中にも記載したように、どのような目的を達成したいのかという部分が非常に大事だと思っており、それによって取るべきメトリクスや、アプローチの仕方も変わってきますので、そういった点に留意して設計いただければと思います。
最後になりますが、ナレッジワークではQAエンジニアをはじめとして、各職種で積極的に採用を行っています。
ナレッジワークに少しでもご興味を持っていただける方は、カジュアル面談フォームからお気軽にお申し込みください！