バグの傾向Dashboardを作って皆で眺めた話

ども。コヤマンです。2024年1月より株式会社ナレッジワークでQAエンジニアをしています。
本記事ではjoinしてすぐ作ったバグ傾向Dashboardを使って社内イベントをしたお話を紹介します。
※2024年4月23日に開催するEncraftという弊社のイベントでこのあたりのお話をします。

ナレッジワークの開発文化

品質へのこだわりが非常に高く、CTO自らが全社ミーティングで「品質が高いことはバフなんです。」と言い切るほど熱意を持っており、実際開発（Team Topologiesでいうところのストリームアラインドチームの各チーム）に1名以上のQAエンジニアを配置、さらにプラットフォームチームにも1名アサインをするほど、品質について高い意識を持っています。
そして私がjoinする前まで「バグ分析会」という名目でインシデントやバグの分析をする会が開催されておりました。

バグ分析会のリニューアル

2024年1月当初、QAチームが持っていたテーマの１つがこのバグ分析会のリニューアルでした。
そもそも実施していた内容をさらにアップデートして、もっと意義深いものにしたい、という要望が挙がっていたこともあり、joinしたての私がシュッと取り組むにはちょうどよい?テーマでした。

バグ傾向Dashboardを作った

最初に取り組んだのは、2024年1月からOKRとして追い始めた指標 「severity:highのbug close率」　でした。
バグの情報はJIRAにあることはわかっていたのでGoogle SheetsにJira Cloud for Sheetsを入れてデータを定期取得できるようにしてからLooker StudioでシュッとDashboardを作りました。
便利な世の中になったもんです。
※GASを使ってAPI経由で情報を取得してGoogle Sheetsにさえ入れられれば同じように使えますので、JIRAでなくともAPIで情報が取れるissue管理システムならば同じように使えます。便利！

実際のDashboardはこんな感じです。
Open/Close Chart

Bug Status

Reaction Time

Looker Studioの計算フィールド機能を使って
・statusをOpen/Closeに単純化する→これでclose率を簡単に出すことができる
・発生システムの単純化
・データから新規プロジェクトを除外する
・日付計算を行い「ライフタイム」「リードタイム」「ペンディングタイム」を定義
といった形で手を入れたあたりが工夫ポイントです。
あとは期間で絞れるようにしたり、分析方法などの解説スライドのリンクを入れたりなどの細々とした改善をしました。

Looker Studioのレポート(Dashboard)は所謂ピボットテーブルのように、対象の要素を選択するとその情報に絞られるようになっているため
・severity:highだけの情報に絞りたい
・2024/1〜2024/3の期間だけに絞りたい
・自分のチームの情報だけに絞りたい
といったことが、グラフをクリックするだけでできるようになっています。

各グラフは 「この情報からどう改善するインサイトを得られるか」をイメージして
・プロダクト改善をするために必要な情報
・プロセス改善をするために必要な情報
を掘れるようにする、という狙いで作ってあります。

リニューアル→バグふりかえり会

「どう改善していくかを自分で掘れるダッシュボード」を作ったので、皆で見て触る会を設定しました。
議論の幅を広げるために「バグふりかえり会」と名付けて全エンジニアで参加する会として
・会の目的の共有
・全体の品質についての傾向ベースでの話
・Q毎に発生したインシデントの話と傾向
の話をした後、各チームに分かれてDashboardを触りながら改善ターゲットを決める会です。
最初なので各チームのファシリは各チーム担当のQAメンバーにお任せして
「改善ターゲット」「施策」「結果を測るメトリクス」を出してもらうようにしました。

時間がタイト(20min)だったので「時間もっと欲しい！」というご意見を多くいただきましたが、各チームなりにターゲットを決めて施策を出していたのは本当に素晴らしく、中には「severity:mediumのclose率を上げていく」というターゲットを設定したチームもあり、品質上げることについてのこだわりを強く感じました。みんなカッコいい！

情報は誰がために(Act for People)

※Act for Peopleとは弊社のスタイル（行動指針）の１つです
QAという職種は色々な改善を行うのですが、改善を行うことで「開発者」も「お客様」も嬉しくなる、という側面を持つと思っていると筆者は感じています。
QAはテストなども実施し、不具合情報だけに留まらず色々な情報を持ちます。その情報を誰にどう伝えればハッピーになれるのか。それをちゃんと考えることが大事なのです。
筆者は「テストは知るための技術」とよく表現するのですが、「知ったことを誰かに有用になる形で提供する」ということも同じくらい大事だと思っています。

これからも様々な情報を集めて、社内に社外に発信していきたいと考えております。
本記事が誰かのイネーブルメント(=できるようになる)の一助となれば幸いです。