bugbashを導入して検証工程をカイゼンした取り組み/登壇資料（村上 尭聖）

「開発生産性向上の鍵 〜開発者体験・効率・検証改善・リードタイム短縮の実例〜」
2024年8月29日（木）19:00〜21:00
https://sansan.connpass.com/event/326409/

Transcript

1. bugbashを導入して 検証工程をカイゼンした取り組み 開発生産性向上の鍵 〜開発者体験・効率・検証改善・リードタイム短縮の実例〜 2024年8月29日 株式会社Hacobu 村上 尭聖
2. 目次 Copyright Hacobu, Inc. 2 • 自己紹介 • bugbashとは • bugbash導入 • bugbashカイゼン • 開発生産性向上につながった話 • 今後の展望
3. Copyright Hacobu, Inc. 3 自己紹介 村上 尭聖 (むらかみ あきとし) 株式会社Hacobu テクノロジー本部 Vistaチーム QAエンジニア、SM 経歴 システム開発(SES)→QA(第三者検証)→QA(Hacobu) 趣味 コレクション(チロルチョコ、ハーゲンダッツ、etc.)、特撮、お城
4. bugbashとは
5. Copyright Hacobu, Inc. 5 bugbashとは 職種関係なくみんなでテスト対象をさわって「バグ出し」するイベント バグ種別、バグランクで点数をつけて順位を競うこともある (イメージ図)
6. bugbash導入
7. Copyright Hacobu, Inc. 7 bugbash導入 導入前に感じていた課題 • テスト期間が短い中、テスト実施後半で大きい不具合が見つかると延期のリスク • 担当外の施策の知見が溜まりづらいため属人化
8. Copyright Hacobu, Inc. 8 bugbash導入 そんな中「bugbash」というものを知り 課題解決にアプローチできそう！ 他にも良い効果がありそう！ と思い導入に向けて動き出す
9. Copyright Hacobu, Inc. 9 やらないこと 前提として課題解決＆品質向上を目的にしており、定期的かつ長期的に継続したいと考えていたので、 「できるだけ負担にならないように」を意識してbugbashの内容を決めた bugbash導入 チーム分け ポイント制＆順位付け 単発イベント 1時間以上の実施
10. Copyright Hacobu, Inc. 10 決めたこと bugbash導入 対象者 プロダクト内のスクラムチーム (PdM、デザイナー、エンジニア、QA) 使用ツール Miro 実施タイミング Sprintの中盤のデイリースクラム後 時間 30～60分(テスト対象により変動) その他ルール ・起票するものは不具合と提案 ・bugbash後は付箋を精査しQAがjiraにチケット起票
11. Copyright Hacobu, Inc. 11 bugbash導入 説明、デモ bugbash実施 (終了後) QAがチケット起票 フローとイメージ 黄色付箋：不具合 ピンク付箋：提案 (イメージ図)
12. bugbashをやってみた結果
13. Copyright Hacobu, Inc. 13 bugbash導入 やってみて良いところが見えてきた！ • テスト実施序盤で大きな不具合は大体見つけられる ◦ 開発者もバグ修正の時間がしっかり取れる ◦ 毎Sprintで全体の2~4割の不具合がbugbashで検出 • PdMのイメージと異なるものがあれば早めに軌道修正できる • 担当施策以外の機能をさわるので知見がたまる
14. Copyright Hacobu, Inc. 14 bugbash導入 メンバーからのフィードバックも好評だったので、スプリントの定常イベントとして運営 しかし、数スプリント実施してみて課題が見えてきた bugbash中は静かになりがち 各々がテスト対象をさわっており、不具合や疑問等がない場合はひたすら黙々と実施している 10人以上のメンバーでやっているので、話しづらい空気になっている 大きい施策だと仕様把握に時間がかかる バグを見つける時間がない バグや提案を起票する人に偏りがでてきた 特定の人しか付箋を貼れていない 不具合探しが得意な人、不得手な人が見えてくる
15. bugbashカイゼン
16. Copyright Hacobu, Inc. 16 bugbashカイゼン 当初の課題に対しては、ある程度解決できているが、盛り上がりにかけており楽しくないイベントになって いるなと感じたのでbugbashのやり方を変えてみた！ bugbash中は静かになりがち • 3~4人のチーム制にして話しやすい空間を作った • 不具合、提案の付箋以外にも「ポジティブフィードバック」の付箋を追加 大きい施策だと仕様把握に時間がかかる バグや提案を起票する人に偏りがでてきた • チーム毎にメインの施策や観点を設定した • モブテスト形式にした ◦ チーム毎にドライバーを1人、それ以外をナビゲーターに分ける ◦ ドライバーはナビゲーターの指示で画面を動かしてみんなでバグを探していく
17. Copyright Hacobu, Inc. 17 bugbashカイゼン 黄色付箋：不具合 ピンク付箋：提案 緑付箋：ポジティブフィードバック 説明、デモ チームに分かれ て担当決める bugbash実施 チーム毎に出た 内容を共有 (終了後) QAがチケット起 票 フローとイメージ
18. Copyright Hacobu, Inc. 18 bugbashカイゼン やり方を変えてみてより有意義なイベントにすることができた！ 会話が増えた チームに分けて少人数にしたので話しやすくなった モブテスト形式なので、自然に会話が発生した 仕様を知らなくても気軽に参加できる ナビゲーターに指示してもらいながら操作するので仕様知らなくてもOK 説明や質問をしながら実際に動かすので仕様把握が容易 テスト観点を広げられる チームで実施するので他の人がどんな観点で見ているのかを知ることができる
19. 開発生産性向上につながった話
20. Copyright Hacobu, Inc. 20 開発生産性向上につながった話 bugbashを導入したことで、開発生産性の向上にもつなげることができました！ QAのテスト実施工数が減らせた 序盤で大まかな不具合が潰せるので、テスト後半で修正待ちのブロック項目が少ない 開発者のコンテキストスイッチを減らせた まとめて不具合見つけることで、開発者の不具合修正対応を集約できた
21. Copyright Hacobu, Inc. 21 bugbashありの場合 bugbashなしの場合 開発生産性向上につながった話 QA 不具合起票 開発 修正対応 QA 修正確認 開発 別作業 bugbush QA 不具合起票×3 開発 修正対応×3 QA 修正確認×3 開発 別作業 QA 不具合起票 QA 修正確認 QA 不具合起票 QA 修正確認 開発 修正対応 開発 別作業 開発 修正対応 開発 別作業
22. Copyright Hacobu, Inc. 22 開発生産性向上につながった話 ↙ここでbugbash実施
23. 今後の展望
24. Copyright Hacobu, Inc. 24 今後の展望 他にもまだQAの設計や実施のリードタイムを減らせるのでは と感じているが現状データがとれていない Findy Team+のイシュー分析で QAのリードタイムを可視化して カイゼンできそうな箇所にアプローチしていきたい
25. Copyright Hacobu, Inc. 25 採用情報 https://career.hacobu.jp/