こんにちは、メルカリのQAエンジニアのFunakiです。今回は品質改善と可視化のための取り組み、特にバグ管理（Bug Management）に焦点を当てて、QAチームがどのような活動を行っているのかをご紹介します。
我々は2018年頃からバグ管理の取り組みを始め、試行錯誤を重ねてきました。製品の品質に関する課題を抱えた方や、品質の可視化を進めたいと考えている方にとって、当ブログが現状を改善するきっかけになれば幸いです。
なぜBug Managementを実施しているのか？
我々はプロダクトの品質を推測するために、バグチケットの管理や可視化するすることを目指しています。品質を推測するために、品質の可視化するための環境構築(ダッシュボード)や、バグのチケット管理ルール(Bug Management Guideline)を作成しています。
もともと、メルカリでは各開発チームが独自にバグの管理をしていました。多くのチームではJIRAを使用してしましたが、JIRA以外で管理をしているチームもありました。
また、チームストラクチャの再編により軽微なバグの担当者がいなくなり、長期間未対応のまま放置されることがありました。
それらの影響でバグチケットの全容が十分に把握できなくなっていました。
これらの問題を改善していくためにBug Mnagement を実施しています。
Bug Management Guideline とは？
我々はバグチケットを健全に管理出来るようにして、品質の見える化をするために、Bug Management Guideline を作成して開発チームへ展開をすることにしました。
ルールを作ると、守らなければならない事項が多くなりがちで、結果として誰もルールを守れなくなることがあり得ます。そうならないよう、私たちは以下の最低限の目標を設定しました。
目標:
1. バグ管理環境をJIRAへ統一
2. バグの発生状況や修正の優先順位が判断できること
3. バグが長期間放置されないこと目標1を達成するために、まずは各開発チームが使用しているバグ管理ツールを調査し、JIRAを使用していないチームにはJIRAへ変更をお願いしていきました。
目標2を達成するために、バグ修正の優先順位やバグの発生傾向などを分析が出来るように、バグチケットに情報を記載するフィールドを追加しました。
目標3を達成するために、バグチケットの有効期限を設定しました。有効期限が切れたバグチケットが無いか定期的チェックし、期限が切れたチケットはクローズするか、優先順位を上げてすぐにに修正するかを判断するルールを策定しました。
Bug Management Guideline を作成し、各チームが共通の環境とルールを使用することで、Bugチケットの全容が把握するための準備が整いバグチケットの状態の可視化をすることが出来るようになりました。
バグチケットの状態の可視化
JIRAにもチケットの情報を可視化するダッシュボードの機能がありますが、我々がチェックしたい情報を可視化する事は出来ませんでした。そのため、当初はJIRAで管理されたバグチケット情報をLookerで可視化していました。
JIRAのバグチケットの情報は直接Lookerで利用することが出来ないため、JIRAのバグチケット情報をtroccoを利用してBigQueryにインポートし、BigQueryの情報からLookerで様々なグラフを作成してダッシュボーを構築していました。
以下の画像は、取り込まれたデータの流れと作成したダッシュボードのサンプルです。
過去の取り組みについて少し紹介した関連記事については、以下のURLをご覧ください。
関連記事: メルカリのQAエンジニアの取り組み2020
可視化(ダッシュボード)の改善
ダッシュボードは開発チーム毎に作成し運用していましたが、メルカリの開発体制やメンバーが頻繁に変動するため維持管理が大変でした。さらに、troccoやBigQueryの環境はQAチームが構築した環境では無かったため、環境のメンテナンスやアクセス権管理、グラフの更新・追加のためのデータ変更が複雑になってしまいました。そのため、メンテナンスがしやすい環境に切り替えることを検討しました。
バグ管理を更に効率化する方法を調査していたところ、データ取得が手軽で、グラフの資料作成も簡単に行える新しい手法を見つけました。具体的には、「Jira Cloud for Sheets」というスプレッドシートのアドオンと、「Looker studio」 というデータの分析や管理、レポート作成が簡単に行えるBIツールを使うことに決めました。
Jira Cloud for Sheetsは、JIRAの開発元であるAtlassianが提供している拡張機能で、JIRAで管理しているバグ情報をスプレッドシートに直接取り込むことが可能になります。スプレッドシートに取り込んだJIRAの情報は、関数を使い情報を分類したり、集計することで自分たちの知りたい情報を作成することができま。
またJIRAは今の情報しか取得することが出来ません。そこでGoogle Apps Script（GAS）を使用して集計データの履歴を日別に作成しました。履歴を作成したことで、バグチケットの作成や対応件数の傾向を確認することが出来るようになりました。
Looker Studioは、スプレッドシートからデータを直接読み込んでグラフや表を好きなレイアウトでダッシュボードを作成することが出来ました。そのため、他チームに依存することが無くなったため、任意のタイミングでダッシュボードメンテナンスが可能にりました。
また、データの取得や表示データの更新は、アドオンの機能やGASのスケジューリング機能を使って定期的に実行しているため、毎日自動的に情報が更新されるようになっています。
これらの改善により、マニュアルでのメンテナンスが最小限になり、バグ追跡と分析もスムーズに行えるようになりました。
今後の Bug Management
Bug Management Guidelineを作成し、Looker Studioでの可視化のおかげで、バグチケットが修正されずに残っている場合や、いつ何件のバグチケットが作成され、クローズされたかなどが一目でわかるようになりました。定期的にバグチケット作成からの経過時間をチェックし、優先順位の見直しをすることで、バグチケットが長期間放置されなくなりました。
これらの取り組みにより、適切にバグチケットが管理することができるようになりつつあります。しかし、開発体制の再編や新しいメンバーの増加など影響で、取り組みがリセットされないようにBug Managementの周知が必要です。さらに、バグ発見の傾向や件数から製品の品質を推測し、バグの作り込みを防止する施策の検討などを続けていく予定です。
