バグバッシュをアプリ開発のプロセスに組み込んだ話

この記事はMobility Technologies Advent Calendar 2021の14日目です。

タクシーアプリ「GO」の iOS アプリを開発をしている古屋です。

この記事では GO でなぜバグバッシュを開発のプロセスに組み込んだか、やってどうだったかについて紹介します。

バグバッシュとは

みんなでワイワイプロダクトを触って不具合を出そうという会です。

きっかけ

アプリ開発のQCフェーズで以下のような不具合を起票されることは、きっと皆様も経験されているのではないでしょうか。

• 文言、画像が違う
• iOSとAndroidで挙動が違う
• なんかデザインがおかしい
• 正常系のフローが試せない

これらは開発する上で開発者が確認しておくべきところではありますが、

• 開発途中で仕様が変わってその対応が漏れる
• いつの間にかデザインファイルの画像や文言が変わっている
• スケジュールがぱつぱつで、細かい確認をやらなかった
• iOS/Android各チームでふわっとした仕様をよしなに解釈して実装してしまう

など往々にしてあると思います。

GO でもこのようなことがあり、QCチームから「普通に気付けるレベルの不具合ちょっと多いんですけど...」と言われてしまう状況でした。

この状況を解決するには個々が開発中に意識していればいいだけではありますが、どうしても忘れてしまったり他のことをやりたくなったりしてしまうので、みんなで集まってやる時間を確保するのがいいのではないかとなり、一定以上の規模の案件ではQC前にその機能に対してバグバッシュを実施することにしました。

プロセスに組み込むにあたって

やることは通常のバグバッシュと同様ですが、案件ごとに実施するため月一くらいはバグバッシュを開催することになります。 そのため事前準備にどういうものが必要かや、終わった後に何をすべきかをまとめておき効率的に開催できるようにすることが大切になります。

GOでは以下のように手順書をまとめることで、誰でも開催できるようにしています。

得点の付け方などはDROBEさんのDROBE初のリモートBug Bash大会で、名誉あるバグ王になりましたを参考にさせていただきました。

参加するメンバーは基本的には、案件に関わるエンジニア、デザイナー、PdMですが、他案件のメンバーやビジネスサイドの人にも参加してもらえるように声をかけています。

これにより担当していない案件でも仕様の把握ができたり、QCが終わりごろになって「思ってたのと違うんだけど...」のような手戻りを減らせるメリットがあります。

またバグをいくら見つけてもQC開始前に修正する時間がないと意味がないので、QC開始の2日前までには実施できるようにしたり、バグバッシュの事前準備が前日までに完了しているかDSで確認するなどはバグバッシュの成否に影響するので大事にしています。

開催

ワイワイやるのみ！ 現在はリモートでのみ開催をしていますが、以前はリアルとリモートのハイブリットでも開催していました。

バグはもちろん、それ以外でもちょっと気になったらとりあえず投稿というスタイルで活発にやりとりが行われています。

プロセスに組み込んでみて

組み込んで1年くらいになりますが毎月のようにやっていて、毎回10個以上(多いと30個以上)の不具合やデザイン修正をQC開始前に潰すことができ、QCチームの負荷低減にしっかり貢献できています。

また実際に触ってると色々気になるところが出てきたりしますが、複数の職種の人が集まっているのでその場でさっと話して、文言や機能の改善案が出てきたりもしてプロダクトの価値向上に貢献できたり、リモート環境になってワイワイ話すことが減ってきた中で軽い雑談もできるので気分のリフレッシュにもなってとても良かったです。

KPTをしても継続していきたいという意見が大半でした。

バグバッシュの事前準備は多少面倒ではありますが、みんなで集まってやるものだし後回しにできないなというプレッシャーもあり、無事に実施できています。

今後も継続してバグバッシュを行い、品質の高いアプリをリリースしていければと思います！

We're Hiring!

興味のある方は 採用ページ も見ていただけると嬉しいです。

Twitter @mot_techtalk のフォローもよろしくお願いします！