テスト前の「ぽちぽち会」が開発チームを活性化させた話 〜失敗から生まれた最高の習慣〜
はじめに
こんにちは!グロービスで学習管理システムのQAをやっているカロリーナです。
みなさん、受け入れテストが始まってから「あ、これ実装漏れてる...」「この機能、どうやって使うんだっけ?」なんて経験はありませんか?私たちのチームでは、そんな失敗から生まれた「ぽちぽち会」という習慣が、想像以上の効果をもたらしました。
今回は、5回の実践を通じて見えてきた「ぽちぽち会」の効果と、簡単に始められる実践方法をご紹介します。
そもそも「ぽちぽち会」って?
「ぽちぽち会」は、一般的にはドッグフーディング、お触り会、バグバッシュなどと呼ばれる活動の、私たちのチーム版の呼び名です。開発中のプロダクトを関係者みんなで触ってみて、早期にフィードバックを得る活動ですね。
私たちのチームでは、受け入れテスト前に3回、リリース前に2回、合計5回実施してきました。1回あたり30分〜1時間(機能の規模によっては2日に分けて2時間)で、オンラインで実施しています。
なぜ「ぽちぽち会」を始めたのか
正直に言うと、私の華麗なるひらめき!...ではありません(笑)
実は、テストが始まってからいくつもの失敗を経験したからなんです:
- 受け入れテスト開始後に実装漏れを発見
- テスト実行者が新機能の操作方法に慣れていない
- テストのブロッカーとなる大きな不具合が見つかり、修正まで一部のテストが中断
これらはすべて、事前の確認や認識合わせが足りなかったことが原因でした。「これ、もっと早く気づけたはずだよね...」という反省から、ぽちぽち会が生まれました。
実際にやってみた!参加メンバーと進め方
参加メンバー
- PO:1人
- デザイナー:1人
- QA:2人
- 開発エンジニア:9人程度
合計10人以上での開催です。開発エンジニアは2つのグループに分かれて並列開発していたので、自分の担当じゃない機能も見てもらうことで、新鮮な視点でのフィードバックが得られました。
進め方
- 全員でオンライン集合(遠方のメンバーもいるため基本オンライン)
- 実際に機能を触りながら気づいたことを共有
- Notionに箇条書きでフィードバックを記録+その場で口頭でも発言
- 会の最後に、発見した問題への対応方針を全員で合意
数字で見る「ぽちぽち会」の成果
実際にどれくらいの問題が見つかったのか、具体的な数字をお見せします:
発見した不具合数の推移
-
1回目:6件
- 重要な問題:2件(テストのブロッカー1件、明らかなデザイン不具合1件)
- 修正対応しなかったもの:1件
- その他:3件(全て対応)
-
2回目:12件
- 重要な問題:なし(1回目で潰せていた!)
- 起票したもの:10件(デザインや操作性の改善が中心)
- 仕様のままとしたもの:2件
-
3回目:15件
- 重要な問題:2件(仕様漏れ1件、操作不備1件)
- 仕様のままとしたもの:6件
- その他:7件(細かいデザインや操作感の改善)
回を重ねるごとに発見数が増えているのは、参加者が慣れてきて、より積極的に問題を見つけられるようになったからだと思います。そしてグラフを見ていただくと分かる通り、2回目を除いて、毎回重要な問題が見つかっています。
このことからも、定期的にチーム全員でプロダクトに触れることが、いかに重要かが分かります。
期待以上だった!ぽちぽち会の効果
1. 品質面での効果
- 受け入れテスト前に大きなバグを発見・修正できた
- 仕様の再確認と認識合わせができた
- バグではないけど「気になる」ところを改善できた
- 受け入れテスト本番では、よりユーザー視点でのテストに集中できた
2. チームへの効果
ここが実は一番予想外で嬉しかった効果です!
元々、私たちのチームは積極的に発言するメンバーが多くありませんでした。でも、ぽちぽち会では「わいわい話しながら」進められる雰囲気があったからか、普段は静かなメンバーも気軽に意見を出してくれました。
その後、他のミーティングでも積極的な発言が増えているように感じます。もちろん他の要因もあるかもしれませんが、「みんなで品質を作る」という意識が芽生えたのは確かです。
3. プロセス改善への気づき
ぽちぽち会を通じて、今後改善が必要なポイントにも気づけました。例えば:
- 仕様書の記載方法
- デザインレビューのタイミング
- 機能説明の共有方法
これらは次の開発サイクルに活かせる貴重な学びになりました。
簡単に始められる!ぽちぽち会の実践ポイント
最小限の準備で始める
- 30分の時間を確保(最初は短時間でOK)
- 開発メンバー全員に声をかける(役割関係なく)
- 記録する場所を決める(Notionでもスプレッドシートでも)
- 「気軽に触って気軽に発言」の雰囲気づくり
成功のコツ
-
受け入れテストの直前がベストタイミング
- 実装が一通り終わっている
- でも修正の時間はまだある
-
「バグ探し」ではなく「より良くする会」という位置づけ
- 批判的にならず、建設的なフィードバックを心がける
- 良いところも積極的に共有する
-
その場で対応方針を決める
- すぐ修正するもの
- 既知の問題として受け入れテスト時は無視するもの
- 次回以降の改善事項とするもの
他チームへの展開も!
実は、私たちの成功を見て、すでに他のチームでもぽちぽち会を実施し始めています。そちらのチームではさらに多くの関係者を巻き込んで実施しているそうで、好評価とのこと。チームごとにアレンジしながら、最適な形を見つけていけるのも良いところです。
まとめ:失敗から生まれた最高の習慣
受け入れテストでの失敗から始まった「ぽちぽち会」は、今では私たちのチームに欠かせない習慣になりました。品質向上はもちろん、チームの活性化という予想外の効果まで得られたのは、本当に大きな収穫でした。
みなさんのチームでも、まずは30分から始めてみませんか?きっと、想像以上の変化が待っているはずです!
Discussion