bugbashを使ってチームで品質向上に取り組んだ話

はじめに

2023年2月に株式会社Hacobuへ入社して、「MOVO Vista」というプロダクトのQAエンジニアを担当している村上です。
「MOVO Vista」では企業間物流における配送依頼から請求までの業務DX化を支援するサービスを提供しています。

今回はbugbash(バグバッシュ)というイベントを開発フローに導入して良かったことや課題について書いていこうと思います。

こんな方たちにおすすめ

• bugbashをやってみたい
• チームで品質向上に取り組みたい

bugbashとは

職種関係なくみんなでテスト対象をさわって「バグ出し」するイベントです。

チームに分かれたり、バグ種別やバグランクでポイントをつけて順位を競うこともあります。

(bugbashのイメージ画像)

導入しようとした背景

以前からチームの課題として下記を感じていました。

• 担当外の施策の知見が溜まりづらい → 属人化が進んでしまう
• アジャイル開発の期間が短い中、テスト実施後半で不具合が見つかると、不具合起票→修正対応→再確認となりリリースがギリギリor延期になってしまう

他にも、QAだけではなくチーム全体で品質向上に取り組んで行きたいなー何かないかなーと考えているところに「bugbash」というものに出逢いました。

bugbashの内容を見ていると、以前から感じていた課題の解決とともにチームでの品質向上にも繋がるかも！と思い導入に向けて動き出しました。

やったこと

まず前提として課題解決＆品質向上するためには定期的、長期的に継続したいと考えていたので、「できるだけ負担にならないように」を意識してbugbashの内容を決めました。

決めたこと

• 対象者：プロダクト内の開発チーム(PdM、デザイナー、エンジニア、QA)
• 使用ツール：miro
• 実施タイミング：Sprintの真ん中(みんなが時間を確保しやすいデイリースクラムの後に実施)
• 時間：30分
• 不具合だけでなく、ちょっと違和感感じるところや、ここ仕様通りだけどこうした方がいいんじゃないかなどの提案も起票OK
• bugbash後、付箋を精査し不具合、提案はQAが取りまとめて起票する

やらないこと

• チーム分け
• ポイント制＆順位付け
• 出た不具合に対しての振り返り

MOVO Vistaでは2週間Sprintを採用しており、基本的には前半1週間で開発、後半1週間がテスト実施期間となっています。

実施タイミングをSprintの真ん中にしたのは、QAがテスト実施着手するタイミングで行うことにより序盤で大きめの不具合をあらかた検出させたいという意図です。

bugbashは下記流れで行いました。

やってみた結果

実際にやってみて、いくつか良いところが見えてきた。

• テスト実施序盤で大きな不具合は大体見つけられる

  • 開発者もバグ修正の時間がしっかり取れる

  • 下記画像はbugbash導入以降の障害検出パターンの集計になります
    毎Sprintで全体の3~4割の不具合がbugbashで検出できています

    

• PdMも動くものをさわるので、イメージと異なるものがあれば早めに軌道修正できる

• 担当施策以外の機能をさわるので知見がたまる

2回ほどやってみてアンケート取った結果、色々な意見をいただきチーム内もポジティブだったので、開発フロー(Sprint)に乗せて運用することになりました！

下記は1回目のアンケート結果の様子、たくさん意見いただき2回目に活かせました。

Sprintにのせてうまくいくと思ったが…

Sprintにのせて好調のように見えましたが、数回実施してみていくつか課題を感じてきました。
メンバーにもヒアリングし下記のような課題があがりました。

• bugbash中静かになりがち
  • 各々がテスト対象をさわっており、疑問等がない場合はひたすら黙々と実施している
  • 10人程のメンバーでやっているので、人によっては話しづらい空気になっている
• 大きめの施策になると、仕様把握に時間がかかってしまいバグを見つける時間がない
• バグや提案を見つける人に偏りがある

当初の目的の、「知見の偏り防止」「不具合を序盤に見つける」はある程度達成できているものの、盛り上がりにかけており楽しくないイベントになっているなと感じました。

bugbashカイゼン

課題を元にいくつかbugbashのやり方を変えてみました！

変更した点は大きく3つです

• チーム制にした

  • 1チーム3~4人のチームにすることで話しやすい空間を作った
  • Meetのブレイクアウトルームを活用したので、ファシリをする人は各チームの様子を自由にのぞきにいけます

• チーム毎にメインの施策を設定した

  • リリースする施策の中でチーム毎にbugbashするメインの施策を設定した
  • チーム内に1人施策担当者を入れるようにチームを割り振る
  • メイン施策は決めるが、時間が許す限りは他施策も見てOK

• モブテスト形式にした

  • チーム毎にドライバー(施策の知見がないメンバ)を1人、それ以外をナビゲーターに分けた
  • ドライバーはナビゲーターの指示で画面を動かしてみんなでバグを探していく

変更後は下記フローでbugbashを実施しています。

Miroでは下記画像のようなフォーマットを使って実施しています。
付箋の色で種別を分けており、黄色が不具合、ピンクが提案、それ以外がメモやポジティブフィードバックなどです。
bugbashで各チームに付箋を起票してもらい、終了後QAが付箋整理でJiraに起票か対応不要に割り振っていく流れです。

カイゼンした結果

カイゼンしてみて当初の設計より少し実施時間が増えましたが、それ以上に下記よいことがあり有意義なイベントにすることができました！

• 会話が増えた
  • モブテスト形式なので、自然に会話が発生した
  • チームに分けて少人数にしたので話しやすくなった
• 仕様を知らなくても気軽に参加できる
  • ナビゲーターに指示してもらいながら操作するので、仕様知らなくてもOK
  • 説明してもらいながら実際に動かすので仕様把握に使う時間が削減
• チームで実施するので他の人がどんな観点で見ているのかを知ることができる

話は変わりますが、「MOVO Vista」で行ったbugbashの取り組みを他プロダクトにも共有したところ、いいなと思ってくれた他チームが翌週には取り入れてくれて、こちらからアクションを起こすことなく自然な形で横展開することができました！
お客様やチームにとってよさそうなことは「とりあえずやってみる！」ができる環境にあるHacobuは素敵だなと感じました。

今後の展望

今後としてぼんやりと想像しているのは下記です。

マンネリ化してやってる意味が薄くなってきたりしないように今後もアップデートしていきたいです。

• 施策内容によってbugbashのやり方を変える

  • 探索的テストでテストチャーターやセッションベースドテストと組み合わせて実施したりなど

• プロダクトチームを超えて全社でやってみると面白そう

  • その場合はイベント形式でポイント制にして景品も用意すると盛り上がりそう

まとめ

QAだけでなくチームとして品質向上していくには、各職種に説明して納得してもらわないと浸透しないと思うので難しいなと考えていました。

ですが、bugbashなら堅苦しいことなしで気軽に始められてチームとしても品質を意識しながら取り組めるのでQAエンジニアとして導入してよかったなと感じました。

チームで品質に対する取り組みをしたいなと思っている方は、是非bugbashを検討してみてください！！