こんにちは、株式会社エフェクチュアル プロダクト技術開発部の日山です。
今回はSaaS界隈で流行っているBug Bashを弊社でも実施したので、紹介したいと思います。

Bug Bashとは

一言で言うとプロダクトをみんなで触って、バグをたくさん出すという取り組みです。
弊社では「プロダクトに対して様々な関わり方をするメンバーがそれぞれの立場でプロダクトを触りながらUXを考え、品質の向上を図る」という目的のもと開催しました。
そのためエンジニアだけでなくサービス提供メンバーや営業メンバーなど、部署を問わずに普段の業務から離れてそれぞれの視点でプロダクトを操作して、バグや改善点を探します。

また副次的な成果として「社内メンバーがプロダクトについての理解を深める」という点も期待しています。プロダクトの理解が深まることで、例えば営業であれば、カタログにある情報だけでなくお客様ごとにどの機能や使い方が有益であるかなど、自信を持ってプロダクトを提案できるようになるのではないでしょうか。

社内には「楽しくみんなでプロダクトを触って、バグや改善点を洗い出して、品質を高めていこう！」というスローガンのもと周知を行い、参加者を募りました。
今回は初めての実施ということもあり、基本的なルールは以下のように簡単なものとしました。

• 実施時間は60分、3人1チームとし、バグを見つけたら審査員まで報告する
• 審査員はその場で報告内容を判定し得点をつけ、チームの得点として加算する
• 意見や提案も幅広く許容する
• 参加者はマスク着用の上、アルコール消毒を徹底する
• 終了時に最も得点が高いチームを優勝とする

記録に残すためにチャットツールでの発言にしようかとも考えましたが、競技性を高くして盛り上げる開催にしたかったので、バグを見つけたら前に出て発表する方式を採用しました。
また参加者のモチベーションアップのため、得点の高いチームには景品を用意しました。

部署の異なる3人1チームとしたので、楽しくコミュニケーションを取りながら開催できればよいと思い、お菓子もたくさん用意しました。

第1回 Bug Bashの審査員はCTOの岩田さん（左）、と私日山（右）が担当しました。

手に持っている札が内容を判定する際に使用した得点札です。
3種類以下の得点とし、審査員二人があげた札の得点の合計値がチームに加算される方式です。

• Nice bug：2点
• Good bug：1点
• Not bug：0点

Bug Bashの様子

記念すべき第1回Bug Bashは合計17名、その日社内にいた半数以上の方に参加していただきました。
全員配置についてBug Bashスタートです！

開始するとすぐにバグを見つけようと必死にプロダクトを操作しています。
競技性を高くし、景品を用意したことがやる気につながっているようです。
カタログベースでプロダクトを知っていても、実際に踏み込んで操作するのは初めてという人が多く、初めは操作に苦戦する姿も見受けられました。

バグや改善案を見つけた人は前に出て、審査員の前で発表します。
発生した手順や画面、どこをどのように直したら良いのかを説明していきます。

最初は質問に近い提案が多かったのですが、時間が立つごとにそれぞれの立場での提案が増えてきたように感じました。例えば、サービス提供メンバの場合、入力補助やエラー発生時の動きについて、マーケ担当の場合は情報の見せ方に関して等、視点が異なる提案や意見が多く出たのは良かったと思います。

結果発表

1時間の長い戦いを終えて結果発表です。
合計すると75回の報告があり、審査員は息をつく暇もありませんでした。

今回は得点の高い上位3チームに景品を授与しました。

第三位：チーム②：18点

このチームは大きな得点をとるというよりも、コツコツと小さな改善点を提案し点数を稼ぐチームでした。全員が積極的に発言していました。おめでとうございます。

第二位：チーム⑤：24点

このチームはほとんど触ったことのないプロダクトで苦戦していましたが、後半になって怒涛の追い上げで2位に上り詰めました。おめでとうございます。

第一位：チーム①：27点

このチームはNice Bugを連発し、効率よく得点を稼いでいました。着眼点がすばらしく、我々エンジニアが頭を抱える内容をいくつかありました。おめでとうございます。

Bug Bashを終えて

初めての開催ということもあり、至らない点もいくつかありましたが、参加者からは「楽しかった、またやりたりたい」という声もあがり、とても良い時間だったと思います。
今回の実施について振り返ってみます。

KEEP

• 楽しかった、またやりたいと参加者から言ってもらえた
• 制限時間と得点方式により競争意識が生まれ、短時間で集中して取り組むことができた
• 合計75回の発表があり、活発な回だった
• 部署が違うからこそ出たアイデアやバグが多く、プロダクトの理解が深まったとの声が多かった
• 参加したエンジニアから普段と違う視点でテストができ良い機会だったとの声があがった

Problem

• 報告された内容について振り返る時間を用意していなかった
• 報告時に作業を中断するわけではないため、他のチームの発表内容が分からず、重複した報告がいくつかあった
• ビデオで報告内容を記録していたが、盛り上がった参加者の声で内容が聞き取れないことや画面がぶれており、書き出しに苦労した
• 主催者側のミスがいくつかあった

Try

• ビデオで記録する場合、位置（カメラの場所、パソコンを置く場所、人が立つ場所、審査員の場所）を予め決め、正確な記録を取れることを確認する
• お菓子は作業の片手間で食べられるものが良い（手が汚れない、こぼしにくい）
• 量を見つけた方が得点を稼ぎやすいので、得点幅を増やしてもよさそう（0点、1点、2点、3点）
• 今回の審査員はエンジニアだったので、他の部署の方を審査員にすることも検討する
• Bug Bashの後に発表内容を全体で振り返る仕組みがあった方がよい
• チーム名にもこだわった方がよかった

企画時は1時間は長いかな？と思っていましたが、蓋を開けてみれば参加者からは用意したお菓子に手を付ける余裕がないくらい活発な提案が行われ、1時間という時間があっという間に過ぎてしまいました。
裏を返せば今回の対象プロダクトは、さらに進化の可能性に溢れているということになります。

発表数75回の内訳は、バグが4件、改善系の提案が60件、重複内容が12件でした。
緊急度の高いバグについては対応方針について検討しながら対応を進めています。

当初の目的である「プロダクトに対して様々な関わり方をするメンバーがそれぞれの立場でプロダクトを触りながらUXを考え、品質の向上を図る」という点については達成できたと感じています。
KPTを考察すると、事前の準備が不十分だったことが挙げられますが、第一回目の取り組みとしては成功だったと思います。何よりも楽しく参加者全員で集中的に操作してバグや改善点を洗い出したのは良い時間だったと感じます。

良かった点（Keep）を維持、さらに良くしながら、課題（Program）を改善し、今後も開催していきたいと思います。