Atlassian Community Event Tokyo #68/Jiraダッシュボードで強化するバグ対応課題の洞察力

2024年12月5日に開催された「Atlassian Community Event Tokyo #68」に弊社の佐藤（QA Engineer）が登壇しました。

▼イベント情報
イベントページ
https://ace.atlassian.com/e/mycush/

イベントリポートhttps://augtokyo.atlassian.net/wiki/spaces/AT/pages/1701117955/Atlassian+Community+Event+Tokyo+68+at+docomo+R+D+OPEN+LAB+ODAIBA

▼開発チームの情報発信リンク集
https://linktr.ee/atama_plus_dev

1. J i r a ダ ッ シ ュ ボ ー ド で 強 化 す る バ グ 対 応 課 題 の 洞 察 力 佐 藤 淳 史 2024.12.05
2. 自己紹介 2017.4 ~ 2021.10 銀行系SIerにて、ITエンジニアとして従事 主に顧客向け業務システムの開発を担当 2021.11 QAエンジニアとしてatama plusに入社 趣味：音楽鑑賞、作曲（HIPHOPが好きです！） 2 佐 藤 淳 史 Q A E n g i n e e r a t a m a p l u s 株 式 会 社
3. ⓒ atama plus Inc. 会社概要 3 atama plusとは 社名 atama plus株式会社 代表者 稲田 大輔 設立 2017年4月3日 社員数 150名（2024年5月現在） 資金 調達額 113億円 事業 内容 AI（人工知能）を活用した 教育プロダクトの開発および 提供
4. ⓒ atama plus Inc. ミッション 4 atama plusとは 「基礎学力」の習得 「基礎学力」の習得 「社会でいきる力」の習得 学習を一人ひとり最適化し、「基礎学力」を最短で身につけ、 そのぶん増える時間で、「社会でいきる力」を伸ばす。 そんな新しい学びを数億人の生徒に届け、社会のまんなかから変えていきます。
5. ⓒ atama plus Inc. 5 全国の塾・予備校に AI教材「atama＋」を提供。 一人ひとりの 「得意」「苦手」を分析し、 学習をパーソナライズします。
6. プロダクト組織について
7. ⓒ atama plus Inc. プロダクト組織構成 7 プロダクト組織について • プロダクト組織は、テーマごとにエリアに分かれ、その中に開発チームがある • 各エリアにはプロダクト責任者が存在する エリア チームA チームB エリア チームC チームD Engineer UX QA Engineer UX QA Engineer UX QA Engineer UX QA
8. ⓒ atama plus Inc. 横断品質改善室について 8 プロダクト組織について ミッション：「いいものを タイムリーに 安定的に ユーザーに届ける」 ①プロダクトQA … 各エリア/チームに入り込み、QA業務/品質課題を扱う ②横断QA … 横断的なQA業務/品質課題を扱う (バグ対応や自動テスト推進など) 横断品質改善室(QA職) プロダクトQA 横断QA
9. ⓒ atama plus Inc. 横断QA内におけるバグ対応の役割 9 プロダクト組織について プロダクト組織において、以下の業務に責任を持つ バグ分析を通じた 可視化/課題抽出 報告されたバグの 一次対応 開発チームへの バグのアサイン バグ対応フロー の管理
10. 本題です
11. ⓒ atama plus Inc. アジェンダ 1. バグ分析を始めた経緯・運用の概要 2. カスタムフィールドを活用したバグ分析観点 3. 分析結果の組織内共有 11 Jiraダッシュボードで強化する、バグ対応課題の洞察力
12. ⓒ atama plus Inc. アジェンダ 1. バグ分析を始めた経緯・運用の概要 2. カスタムフィールドを活用したバグ分析観点 3. 分析結果の組織内共有 12 Jiraダッシュボードで強化する、バグ対応課題の洞察力
13. Jiraダッシュボードの活用 どうして始めたの？
14. ⓒ atama plus Inc. 経緯_Before 定常的なバグ分析を実施しておらず、 バグ発生/対応に関する情報が収集できていなかった 14 バグ分析を始めた経緯・運用の概要 バグの発生状況・傾向がよくわからない… バグ対応のプロセス改善が進めづらい…
15. ⓒ atama plus Inc. 経緯_After 段階を踏んで、バグ分析の環境整備を実施 15 バグ分析を始めた経緯・運用の概要 バグチケットの 入力項目の整備 分析ダッシュボード の整備 可視化〜 課題の抽出〜解決
16. ⓒ atama plus Inc. バグチケットの入力 「起票した」「各開発チームでバグ調査/修正を実施した」タイミングで入力を実施 16 バグ分析を始めた経緯・運用の概要
17. ⓒ atama plus Inc. 実際の分析イメージ • 分析ボードは２種類用意 • Custom Charts for Jira (plugin) を利用 17 バグ分析を始めた経緯・運用の概要 月次ダッシュボード 累計ダッシュボード
18. ⓒ atama plus Inc. 累計ダッシュボード • 累計のデータを確認できるダッシュボード • 対象データとして • 毎月のデータ推移 • ストック情報 18 バグ分析を始めた経緯・運用の概要
19. ⓒ atama plus Inc. 月次ダッシュボード • 毎月新しいダッシュボードを用意し、分析を実施 • 月単位でまとめられるデータが対象 • 分析結果/データを同時に確認できる • 情報が散財するより分析作業が楽 • 受け手も確認資料が1つで済む 19 バグ分析を始めた経緯・運用の概要
20. ⓒ atama plus Inc. 今の形に至るまで（こんな時期もありました…） Before • 累計のダッシュボードしか用意しておらず、共有用のデータ作成に時間がかかる… After • 月次ダッシュボードを作成することで、データ準備を効率化 • 月次ダッシュボードの作成は15min程度 （ダッシュボードコピーして、JQLを対象月のクエリに書き換えるだけ） • 分析に時間をかけることができる！ 20 バグ分析を始めた経緯・運用の概要
21. ⓒ atama plus Inc. アジェンダ 1. バグ分析を始めた経緯 2. カスタムフィールドを活用したバグ分析観点 3. 分析結果の組織内共有 21 Jiraダッシュボードで強化する、バグ対応課題の洞察力
22. どんな観点で分析しているの？
23. ⓒ atama plus Inc. カスタムフィールドの活用 • 分析観点をシャープにする上で、 カスタムフィールドの適切な整備が重要だと考えた 23 カスタムフィールドを活用したバグ分析観点 コレ！！
24. ⓒ atama plus Inc. 観点①_アサイン件数・対応したバグの件数/工数 • チームごとに、アサイン件数や対応件数/工数を可視化 • 得られる気づきとして… • リソース調整の必要性 • 他チームと比較したときの 平均対応工数の傾向 24 カスタムフィールドを活用したバグ分析観点
25. ⓒ atama plus Inc. 観点②_事前検知可能な工程 • 対応したバグのうち、どんなバグが事前検知できたか、重大度ごとに収集 • 重大度：重大/高/中/低 • 得られる気づきとして… • 特に「重大/高」なバグについて 早期に検知することで、 コスト抑制になるのでは？ • 工程ごとに どんな観点が見逃されたのか？ 25 カスタムフィールドを活用したバグ分析観点 FT = feature test
26. ⓒ atama plus Inc. 観点③_バグの重大度ごとの対応工数 • バグの重大度ごとに、各対応工数を可視化 • 得られる気づきとして… • 特に重大度の低いバグ対応に コストをかけすぎていないか？ 26 カスタムフィールドを活用したバグ分析観点
27. ⓒ atama plus Inc. 観点④_機能×対応工数 • 機能毎に、バグ対応にどれだけの工数がかけられているのか可視化 • 得られる気づきとして… • 保守コストが一定明らかになり、 機能撤退を促すきっかけに 27 カスタムフィールドを活用したバグ分析観点
28. ⓒ atama plus Inc. 観点⑤_バグ検出タイミング×重大度 • どのような活動が、バグ発見に貢献できているのか可視化 • 得られる気づきとして… • その活動はバグ検知に貢献しているのか？ • その活動は、 重大なバグを発見できているのか？ 28 カスタムフィールドを活用したバグ分析観点
29. ここまでまとめていて改めて思った 「Jiraで分析するのいいなぁ」
30. ⓒ atama plus Inc. 「Jiraで分析するのいいなぁ」コーナー • JQLやCustom Chartsの設定を利用することで、柔軟な分析が可能 • ダッシュボードからチケットにアクセスが容易で、 分析効率がGood！ • データ入力に誤りがあった場合に、すぐに元データを確認/修正できる • 分析中、チケットの中身をすぐに見れる 30 カスタムフィールドを活用したバグ分析観点
31. ⓒ atama plus Inc. 「Jiraで分析するのいいなぁ」コーナー • 記載漏れチケットの監視が楽！！ • JQLで条件指定し、専用ダッシュボードで可視化 • 入力依頼は「ダッシュボード見て埋めてください！」だけ 31 カスタムフィールドを活用したバグ分析観点
32. ⓒ atama plus Inc. アジェンダ 1. バグ分析を始めた経緯 2. カスタムフィールドを活用したバグ分析観点 3. 分析結果の組織内共有 32 Jiraダッシュボードで強化する、バグ対応課題の洞察力
33. どうやって共有しているのか
34. ⓒ atama plus Inc. プロダクト組織構成（再掲） 34 分析結果の組織内共有 • プロダクト組織は、テーマごとにエリアに分かれ、その中に開発チームがある • 各エリアにはプロダクト責任者が存在する エリア チームA チームB エリア チームC チームD Engineer UX QA Engineer UX QA Engineer UX QA Engineer UX QA
35. ⓒ atama plus Inc. ①エンジニア/QAエンジニア向けの共有 • 月に一度、分析結果の共有を実施 • エンジニア/QAエンジニアそれぞれの横断mtgで共有 • 月次ダッシュボードをそのまま活用 • 共有観点 • 各エリア/チームにおけるバグ対応状況 • バグの振り返り（けっこう具体に踏み込んで共有） 35 分析結果の組織内共有
36. ⓒ atama plus Inc. ②プロダクト責任者向けの共有 • 1Qに一度、分析結果の共有を実施 • エリア毎のプロダクト責任者向けに報告を実施 • Confluenceでまとめている • 共有観点 • プロダクト全体としてのバグ発生状況 • エリア・チーム毎の対応状況 • バグ対応フローにおける改善点 36 分析結果の組織内共有
37. 最後に
38. ⓒ atama plus Inc. 今後の展望 バグ分析を踏まえて、次の課題テーマを絶賛検討中 例えば… • 事前検知可能かつ重大なバグの分析により、 より早期に発生を防ぐための仕組みづくりができないかな？ 38 最後に
39. ⓒ atama plus Inc. まとめ • Jiraダッシュボード * Custom Chartsの活用で、効率よく柔軟な分析ができる • バグ発生/対応の可視化が進んだことで • 複数の関係者間で共通認識を持ちやすくなった • データに基づいた課題の抽出がしやすくなった 39 最後に ダッシュボードの活用により、 効率的にチケットの分析をして課題を見つけよう！
40. AIで、一人ひとりに、最短で「わかる！」を。