この記事はMobility Technologies Advent Calendar 2021の14日目です。
タクシーアプリ「GO」の iOS アプリを開発をしている古屋です。
この記事では GO でなぜバグバッシュを開発のプロセスに組み込んだか、やってどうだったかについて紹介します。
バグバッシュとは
みんなでワイワイプロダクトを触って不具合を出そうという会です。
きっかけ
アプリ開発のQCフェーズで以下のような不具合を起票されることは、きっと皆様も経験されているのではないでしょうか。
これらは開発する上で開発者が確認しておくべきところではありますが、
- 開発途中で仕様が変わってその対応が漏れる
- いつの間にかデザインファイルの画像や文言が変わっている
- スケジュールがぱつぱつで、細かい確認をやらなかった
- iOS/Android各チームでふわっとした仕様をよしなに解釈して実装してしまう
など往々にしてあると思います。
GO でもこのようなことがあり、QCチームから「普通に気付けるレベルの不具合ちょっと多いんですけど...」と言われてしまう状況でした。
この状況を解決するには個々が開発中に意識していればいいだけではありますが、どうしても忘れてしまったり他のことをやりたくなったりしてしまうので、みんなで集まってやる時間を確保するのがいいのではないかとなり、一定以上の規模の案件ではQC前にその機能に対してバグバッシュを実施することにしました。
プロセスに組み込むにあたって
やることは通常のバグバッシュと同様ですが、案件ごとに実施するため月一くらいはバグバッシュを開催することになります。 そのため事前準備にどういうものが必要かや、終わった後に何をすべきかをまとめておき効率的に開催できるようにすることが大切になります。
GOでは以下のように手順書をまとめることで、誰でも開催できるようにしています。
得点の付け方などはDROBEさんのDROBE初のリモートBug Bash大会で、名誉あるバグ王になりましたを参考にさせていただきました。
バグバッシュ手順書
参加するメンバーは基本的には、案件に関わるエンジニア、デザイナー、PdMですが、他案件のメンバーやビジネスサイドの人にも参加してもらえるように声をかけています。
これにより担当していない案件でも仕様の把握ができたり、QCが終わりごろになって「思ってたのと違うんだけど...」のような手戻りを減らせるメリットがあります。
またバグをいくら見つけてもQC開始前に修正する時間がないと意味がないので、QC開始の2日前までには実施できるようにしたり、バグバッシュの事前準備が前日までに完了しているかDSで確認するなどはバグバッシュの成否に影響するので大事にしています。
開催
リアルとリモートのハイブリット開催時の様子
ワイワイやるのみ！ 現在はリモートでのみ開催をしていますが、以前はリアルとリモートのハイブリットでも開催していました。
バグバッシュ中のSlack
バグはもちろん、それ以外でもちょっと気になったらとりあえず投稿というスタイルで活発にやりとりが行われています。
プロセスに組み込んでみて
組み込んで1年くらいになりますが毎月のようにやっていて、毎回10個以上(多いと30個以上)の不具合やデザイン修正をQC開始前に潰すことができ、QCチームの負荷低減にしっかり貢献できています。
また実際に触ってると色々気になるところが出てきたりしますが、複数の職種の人が集まっているのでその場でさっと話して、文言や機能の改善案が出てきたりもしてプロダクトの価値向上に貢献できたり、リモート環境になってワイワイ話すことが減ってきた中で軽い雑談もできるので気分のリフレッシュにもなってとても良かったです。
KPTをしても継続していきたいという意見が大半でした。
バグバッシュの事前準備は多少面倒ではありますが、みんなで集まってやるものだし後回しにできないなというプレッシャーもあり、無事に実施できています。
今後も継続してバグバッシュを行い、品質の高いアプリをリリースしていければと思います！
