こんにちは、asken Androidエンジニアの高津です。医療事業部で品質管理も担当するようになりました。
最近はモバイルエンジニアの大澤と協力して、asken社内で品質改善に関する取り組みを色々と行なっています。
大澤が第1回Bug Bash開催に関する記事を書きました。 今回は第2回 Bug Bashを開催した話をします。
なぜ第2回Bug Bashを実施したのか
エンジニアに閉じず、事業部全体で品質改善に取り組む意識を高めたいからです。
第1回Bug Bashは参加者からも好評でした。
第1回実施後に、「団体戦にする」「メンバーをエンジニア以外に広げる」等のTRYをまとめました。第2回Bug Bashを開催し、PDCAを回していきます。
開催準備
団体戦としたため、オンラインとオフラインが混在するとグループワークは実施難易度が高くなります。 そこで、今回はオフライン限定としました。
今回はエンジニアに限定せず、マーケターやデザイナー、栄養士など全メンバーから参加希望者を募りました。
参加者が確定したら、チーム内にエンジニアだけにならないこと、普段接点の少ないメンバーでチームとなることの2つを条件として運営がチーム分けを実施しました。 これはナレッジ共有とコラボレーションの促進を達成することを意識しています。
報告方法や採点基準、表彰に関しては前回と同様で以下の通りです。
バグや要望を見つけた場合、専用のSlackチャンネルで投稿
- 投稿内容はスプレッドシートを同期し、点数管理
- 点数は採点者が以下を基準として判断
- ただし、採点者は2名体制とし、それぞれの採点結果のうち低い方を採用する
点数 | 説明 |
---|---|
0点 | すでに見つかっているバグ 仕様です 修正予定にならない要望 |
1点 | 軽微なバグ バグではないが修正した方がいい要望 |
3点 | ナイスバグ サービスのクオリティに関わるバグ 渋いバグ 見つけにくいバグ、長年見逃されていたバグ |
- 表彰
- バグブラスト賞 (Bug Blast Award)
- "ブラスト"は爆発や大量の発射を意味し、大量のバグを発見した参加者を称賛します。
- バグバウンティ賞 (Bug Bounty Award)
- 検出した障害の価値が最大の参加者に贈られる賞です。
- バグブラスト賞 (Bug Blast Award)
Bug Bash実施
今回のBug Bashはテストに慣れているエンジニアに限定していないので、楽しくバグを見つける雰囲気作りをより意識しました。
運営として当日を盛り上げるために工夫した点は以下のとおりです。
- 普段からファシリテートがうまい2名に司会者を依頼し、常にワイワイした雰囲気作りができた
- 採点結果をまとめたグラフをプロジェクタで表示、リアルタイムに更新したことで盛り上がった
当日は司会者や採点者等を除く18人,計6組でバグ探索を実施しました。 バグ探索メンバーとして参加したエンジニアは8名で、他にマーケターやデザイナー、セールス、栄養士にマネージャーと幅広いメンバーが参加できました。
そのメンバー全員で合計54件の報告となりました。 個人での報告件数トップは6件のデザイナー、次いで5件のマーケターもいました。 ロールやバックグラウンドが異なると視点も変わり、エンジニアだけでは見つけにくいバグがいくつも報告されました。
最多得点を表彰するバグバウンティ賞が1点差だったこともあり、ゲーム的にも大盛り上がりでした!
参加者からのフィードバック
また参加したいという好意的なフィードバックが多く、運営として嬉しい結果となりました。 個人的には、以下のフィードバックが印象的でした。
技術的バグ、仕様バグ、そのほかに「社会的バグ」という新しい観点を得られたのが個人的な収穫でした。 海外のアプリではその辺り進んでますので、今後日本でも当たり前になってくる部分かもしれません。 (性別選択とか、何もケアしていないと普通に問い合わせで指摘が来ます。)
「社会的バグ」はあるべき姿、求められる動作が設計・実装時と現在で変化した結果発生するもの、と理解しています。 今回のBug Bashによりその視点での見直しが必要と認識できたことは良い成果となりました。
次回、開催時にやってみたいこと
参加者からのフィードバックや運営の振り返りから、次回開催時にやってみたいこととして以下をリストアップしました。
- バグ探索と報告を同時に行うのではなく、作戦会議 -> バグ探索 -> チーム内で報告内容検討 -> 報告 の4ステップを複数回実施する方法にしたい
- これまでのバグ報告件数を競う形式だとチーム戦の効果が薄かった
- 作戦会議やチーム内で報告内容検討のステップを通して、ナレッジ共有やコラボレーション促進をより進めたい
- バグ探索に集中していると、他メンバの報告や採点者の解説を聴く余裕がない、との意見もあった
- これまでのバグ報告件数を競う形式だとチーム戦の効果が薄かった
- 司会者や採点者は希望者を募り、ローテーションしたい
- 大きな機能のリリースが計画されたら、その機能のみをターゲットにしたBug Bashもやってみたい
まとめ
参加者を広げることで、社内のBug Bash及び品質改善の取り組みに対する認知を広げることができました。 まだまだブラッシュアップできる余地があるので、第3回も実施したいです。
また、Bug Bash以外の品質改善の取り組みも検討中です。 こちらも実施できたら、ブログで報告しますのでご期待ください。
積極採用中です!
askenではエンジニアを募集しています。 よろしくお願いします。