エンジニア兼ライターのmegayaです。

noteでは安定したサービスを提供するために、QA体制を整えていくプロジェクトがスタートしました。

そのQAプロジェクトの一環として、社内でbug bash(バグバッシュ)が開催されました。僕もこのイベントに参加したのですが、これが楽しかった…！！

bug bashとは「会社の様々な部署の人たちがチームに分かれてバグを探すイベント」です。チームで時間内でバグを探し得点をつけて、最後に表彰を行います。

ゲーム感覚でプロダクトの打鍵ができるため、楽しくバグ探しをすることができるのです。

今回はnote社でbag bushをやってみたので、その様子を紹介します。

bag bashを行うキッカケ

bug bashを開くことになったキッカケはQAプロジェクトの読書会です。

14章にbug bashが紹介されており、「社内でやってみよう」という声があがって開催に至りました。

（終わってから「楽しかった」とみんなが口にしていた）

bug bashを通して体系的にQAを学ぶことができ、サービスを見返すキッカケにもなりました。社内のエンジニアからも大好評でした。

個人的に参加して特によかった点は、「QAに対して当事者意識が芽生えた」ことです。今までぼんやりと見過ごしていたサービスの違和感に目が向くようになりました。

見つけるものは「バグじゃなくてもいい」という安心ルール

note内では以下のルールでbug bashが行われました。

1. 3人1組のチームに分かれる

2. 制限時間10分で、チームごとに割り当てられた機能や画面を操作してバグを探す

   1. 例：Aチームはログイン画面、Bチームは記事一覧画面

3. 発見した不具合を動画やスクリーンショットを撮ってGithubのissueに記録

4. 10分経過したら、参加者全員で集まってチームごとに一番クリティカルだと思うバグを発表する

5. CTOが1〜3点で得点を発表する

   1. 緊急で直した方が良いものほど高得点

6. 手順2〜5を4回繰り返す

7. チームごとの総得点を発表し、優勝チームに賞品贈呈

「制限時間10分でバグを見つける」と聞くとハードルが高く感じるかもしれません。

しかし、今回のbug bashでは「メッセージの文言がわかりづらい」や「文字の色が見にくい」などの要望やアイディアもOKというルールでした。参加者の心理的ハードルが下がるありがたい措置です。

また、アイディアなどもOKというルールがあることで、「普段から気になっていたけど見過ごしていた」ような小さなサービスのほころびを伝える機会にもなりました。

今回のイベントでは技術書やプロテイン（運営の趣味）なども優勝賞品として用意されているため、参加者としてのモチベーションもあがりました。運営の本気度がわかるぬかりないイベント内容です。

（「iOSアプリ開発 自動テストの教科書」と「WEB+DB Vol.99」は、外部委託としてQAプロジェクトに協力いただいているtarappoさんより献本いただきました。ありがとうございます）

bug bashを通してバグを見つける嗅覚を養う

10分間のバグ探しは各チームにわかれて行います。ここからはそれぞれのやりかたでバグを発見していくことになります。

制限時間が10分というのはちょうどいい塩梅でした。「時間内に1つもバグが見つからなかったらどうしよう。チームのお荷物になってしまう……」という焦りがあるため、すぐに制限時間に達してしまいました。

イベントのわいわい感があって楽しいけれど緊張感はあるという絶妙な空気でした。ハッカソンなどに近い雰囲気かもしれません。

「バグを探す」という視点でサービスを見つめ直してみると、意外にも気になる点がいくつも見つかりました。普段からサービスに触れているため、慣れができてしまって細かい部分を普段は見逃していたのです。

サービスを利用しているユーザーは、不具合が起きたときに要望を出すのではなく、使うこと自体をやめてしまうことが大半です。自分たちが気づかないうちに機会損失をしていることが山ほどあるのだということを痛感しました。

また、今回のbug bashでは様々なブラウザやアプリでサービスに触れる良い機会にもなりました。

僕自身はPCのChromeやiOSアプリを利用しているため、Safariやスマホのブラウザで触ることはほとんどありません。プラットフォームの差異によって様々なバグが見つかったため、普段から意識するべきだと実感しました。

じっくりとバグ探しをしてみると、サービスをなんとなくで見ているのかが身にしみました。bug bashは体系的にバグを見つける嗅覚を養う練習にもなるのでしょう。

得点発表で感覚を共有できる

バグの得点発表では「おー！3点だ！」「あー、これは2点か〜！」といった歓声があがり、アクティビティ的な楽しさがありました。

得点発表は楽しいだけではなく、バグの粒度を共有する大事な場です。CTOの今さんがバグに得点をつけていくため、「noteとしてどんなバグがクリティカルだと考えているのか」が可視化されます。

また、バグの発表があるごとに、「これは直した方がいいね」「これは〇〇チームで修正を担当するのかな？」とチームを横断して議論する良い機会にもなっていました。

イベントの参加者から大好評

10分間のバグ探しを4回繰り返したことで、予想以上にバグや要望が多く見つかりました。参加者はQAの大事さが身にしみたのではないでしょうか。

▼参加者の声▼

参加したエンジニア / デザイナーからも大好評でした。普段は別部署で関わりがない人と協力できるのもbug bashの一つの魅力なのでしょう。

運営の一人であるEMのれつさんの、「楽しくポジティブにバグを見つけて、プロダクトへの理解を深める良い機会になったので継続的にやっていきたい」という言葉でbug bashは幕を閉じました。運営側としても大満足の結果だったようです。

bug bashは終わってからが本番

bug bashをただのイベントで終わりにするのではなく、QAプロジェクトのチームがバグを分類していき各チームに振って順次修正されていきました。

「楽しかった、よかったね」で終わるのではなく、次のアクションにもしっかりつなげられていくのは最高ですね。

また、自分自身としてもbug bashに参加したことで、サービスを定期的に見る時間をとるようになりました。参加前は自社サービスへの小さな気づきを見つけても、「まあ、自分が言わなくてもいいか」と思ってしまっていました。しかし、当事者意識を持つことで、自分が進言するべきだと思えるようになりました。

QAに触れるはじめの一歩として、bug bashは良い機会でした。参加してよかった。

▼エンジニアの記事をもっと読みたい方はこちら

▼noteを一緒に作りませんか？