新卒1年目が仕掛けた、ミニバグバッシュで実現するプロダクト品質向上とチーム活性化

自己紹介

こんにちは！

株式会社ZUUでバックエンドエンジニアとして働いている、新卒1年目の舟田と申します。私が所属するチームは、リーダー、フルスタックエンジニア、そして私の3人で構成されており、自社CMSの運用保守を担当しています。

この記事を読むとわかること

新卒1年目のエンジニアがミニバグバッシュを企画・実行した経緯
小規模チームでのミニバグバッシュの実施方法の一例
ミニバグバッシュによる品質向上とチーム活性化の効果

プロダクトの品質向上をチームメンバーと楽しく実施したい方の参考になれば幸いです。

バグバッシュを企画した背景

ここ最近、プロダクトの品質保証を高める取り組みが活発化していました。

直近では、システム開発の標準フローを作成したり、手順書の統合・整理などが行われていました。そんな中で、私もチームに貢献できる新しい方法を模索していました。しかし入社して半年程度では、能力的にできることが限られるので難航していました。そんな中リサーチを進める上で、「バグバッシュ」というイベントの存在を知り、そのプロダクトに関わるメンバーが集まりプロダクトのバグを発見するアプローチに強く惹かれました。特に、自分に足りない知識・経験を周りの人に補ってもらいながら品質改善ができるという点に強く惹かれました。

また、バグバッシュの楽しそうな雰囲気が、チームのモチベーション向上やコミュニケーションの活性化にも繋がると考えました。これらの理由から、私はチームでこのイベントを正式に開催することを決意しました。

バグバッシュとは

エンジニアはもちろん、デザイナーやマーケティング担当など様々な人達で自社プロダクトを触ってバグを見つけよう！というイベントです。

通常、以下のような目的を持って行われることが多いです。

品質向上
実際にプロダクトを操作することで、通常のテストでは見つけにくいバグや問題点を発見し、品質を向上させる。
コラボレーションの促進
開発者、テスター、デザイナー、マーケティング担当者など、様々な部門のメンバーが参加することで、チーム間のコラボレーションを促進する。
プロダクトの理解促進
参加者全員がプロダクトに触れることで、自社製品への理解を深める。
ナレッジ共有
異なる立場や視点を持つ参加者が集まることで、バグの見つけ方や解決方法などの知識を共有しあう。
セキュリティや品質意識の向上
参加者にセキュリティを含めた品質を意識する文化を醸成する。
エンターテイメントの提供によるモチベーション向上
イベント形式で楽しく行うことで、参加者のモチベーションを高めつつ、普段話さない人とのコミュニケーション機会を増やす。

ミニバグバッシュの企画

上で書いたようなバグバッシュは、他部門の様々なメンバーを巻き込み多角的な視点からプロダクトを操作することで品質向上を実現しようとするイベントですが、今回の目的は自チームのコミュニケーション機会増加も大きな目的にしています。

そこで単発のイベントではなく、小規模で定期的におこなうという意図を込めた”ミニ”バグバッシュという名前で開催することにしました。

ミニバグバッシュの開催目的

品質向上
プロダクトの理解促進

プロダクト全体への理解を深める
普段触らない機能に触れる機会を増やす

エンターテイメントの提供によるモチベーション向上

ハイブリッドワーク環境下で減少しがちな日常的な会話の機会を創出
チームの結束力を高める

ミニバグバッシュには以下のような特徴があります：

開催規模: チームメンバー3人で実施
開催頻度: 隔週の頻度で定期的に実行
所要時間: 1回あたり45分程度
探査対象: バグだけでなく、表示文言の修正やデザイン崩れも含める。

事前準備とアジェンダ

自分が所属するチーム内で開催するため、プロダクトへの理解度を揃えるなどの前提知識の共有は不要で、スムーズに進めることができました。ホワイトボードツールとしてFigjamを使用して準備し、検証環境でバグを探すことにしました。

事前準備としておこなったこと

バグ報告フォーマット作成
使用環境の決定
アジェンダ決定
ヤバさの評価基準を決定

バグ報告フォーマット作成

発見したバグを報告する際、情報の粒度をある程度揃えるために、以下のようなフォーマットを作成しました。これにより、共有をスムーズに進めたり、issueを作成する際に情報を再整理する必要がなくなる効果を狙いました。

使用環境の決定

再現性があるバグであることを確認しやすくするために、検証環境でおこないました。

アジェンダの決定

1回を45分としてアジェンダを組みました。

まず集合してから、当日使用する機能を発表し、必要であれば機能の概要を説明します。そしてバグを探した後、発見者がバグを説明しみんなでヤバさを判定します。そして最後に自分が発見したissueを起票して終了にしています。

実施項目	時間	内容
説明	5分	- 本日触る機能を確認 - 必要であれば使用する機能の説明
バグ探索	25分	- プロダクトの検証環境を使用 - 管理画面とユーザー画面の両方を探索
バグ共有とヤバさチェック	10分	- 発見したバグの報告 - 重要度の評価
issueを立てる	5分	- GitHubの対象リポジトリにissueを作成

ヤバさの評価基準を決定

以下を評価基準として、発見したバグのランク付けをしました。これにより全員で対応の緊急度の認識を合わせる狙いがあります。また、いっぱい見つかる方が盛り上がると思ったため、バグ以外の文言や画面の修正、良くするための改善案も数えることにしました。

評価ランク	説明	具体例
SS (スーパーシビア)	一般ユーザーへの重大な影響	サイト全体のダウン主要機能が完全に停止
S (シビア)	一般ユーザーへの高い影響	ログインの不具合重要な機能の一部が動作しない
A (大きな影響)	ビジネスサイドへの重大な影響	管理画面でのデータ操作ができない
B (中程度の影響)	一般ユーザーへの中程度の影響	特定のブラウザでのレイアウト崩れ
C (軽微な影響)	一般ユーザーおよびビジネスサイドへの軽微な影響	スペルミス、色の不一致
Z（影響はないが改善可能）	不具合によるプロダクトへの影響はないが、改善可能な要素	表示されている内容がわかりづらい

実際の様子

こちらはバグ共有・ヤバさチェック中の様子です。弊社はハイブリッドワークを採用しているため、Google Meetで開催しました。

振り返り

この記事を執筆するまでに、合計2回のミニバグバッシュをおこないました。

実際やってみてどうだったかまとめていきます。

目的はどれくらい達成できたか

プロダクト品質の向上

軽微な文言の修正なども色々含めると、1回につき平均9個の修正箇所が見つかった。
実際に修正PRがマージされ、軽微だがプロダクト品質の向上に貢献できた。

機能を触る機会を増やす

存在すら知らなかった機能が色々あり勉強になりました。
自分より経験が長いメンバーからは、よく使う機能であっても触ったことがない設定が色々あり勉強になった、という声がありました。

チーム内コミュニケーション活性化

元々、チームメンバー3名が参加する定期ミーティングは、毎朝のデイリースクラムと週一回の振り返りのみであり、どちらも会話する内容がアジェンダで明確に決まっていました。一方、今回導入したミニバグバッシュでは、アジェンダで、雑談を交えながらタスクの進捗状況について気軽に話し合うことが可能となりました。その結果、フォローアップが発生しやすくなり、チーム内のコミュニケーションが活性化しました。

予想外に良かった点

当初は大きなバグを見つけようと意気込んでいましたが、逆に小さなバグや軽微な修正こそが日常業務では時間を作って取り組みにくい課題であると気づきました。これらを集中的に洗い出し、修正する機会としてミニバグバッシュは非常に有効だと思いました。

改善点

バグ対応の優先度付け

今回は品質向上に貢献することを目的の1つにおいていたため、バグを顕在化させることに加えて、その修正まで行うつもりでした。しかし、バグのヤバさチェック時に、そもそも修正が必要か、いつまでに直すのかなどを決めていなかったので、修正の機会が先延ばしになってしまう問題点がありました。こちらは2回目からチェックするようになったのですが、最初アジェンダを考える際に目的を意識していれば気づけたと思いました。