こんにちは。 品質管理部のtarappoです。
品質管理部！？と思った方もいるかもしれないので補足をしておきます。 2022年10月から10Xはマトリクス組織を採用し、品質管理部が誕生しました。 詳しくは次のCulture Deckとブログ記事をご覧ください。
今までQuality Teamとして活動してきた私たちは、現在品質管理部に所属して私が部長をつとめています。 とはいえ、今回の記事ではその品質管理部がうまれるまえの話ですし、QAチームという表現で書いていきます。
今回本記事で紹介するのは、QAチームが主催したバグバッシュもとい「ドラゴン探しの旅」について話したいと思います。
バグバッシュは各社でもおこなわれているかと思いますが、次のようなものです。
いろいろな職種の方が、日常的な業務から離れて対象となるプロダクトに対して 「バグ」をみつけることを考えながら触ります。 いろいろな視点でプロダクトが利用されることから、 今まで見つかっていなかったようなバグが見つかることもあります。
きっかけ
入社後に「不具合分析」をできるように整えて、不具合分析をおこなったところ「既存バグ」の割合がある程度ありました。 つまり、まだまだ見つかっていない「潜在バグ」があるだろうと思いました。
そこで、この「潜在バグ」がまだどれぐらいあるのかの洗い出しをすることは一定必要だろうと思いました。 また、当時のQAチームはまだまだ他のチームとの連携をあまりできていなかったり、「QAとは？」というのはまだまだ浸透していない状況ではありました。
そこで、次を期待値として今回の記事で話す「バグバッシュ」を開催しようと思いました。
- Stailer自体についてより知ってもらう
- Stailerの動作確認の大変さを知ってもらう
- 既存バグ（潜在バグ）をいろいろな人の視点で洗い出す
- QAチームと仲良くなる！
開催すると決めてSlackの#generalチャンネルに投稿したときの様子は次のような感じです。 reactionは少なめに見えますが、アンケートに回答してくれた人は30名弱いました。
なお、後日時期的に忙しくて参加できなかったけど参加したかったというコメントは結構いただきました*1。
バグの名前
今回はみんなでバグをみつけるわけですが、「バグ」を「バグ」と呼ばないようにしました。
なんて名前にするかという中で、こにふぁーさんのブログを思い出しました。
そこで、今回はドラゴンとあえて呼ぶようにしました。 ブログにもあるとおり、これは今回の「バグバッシュ（以後、ドラゴン探し）」の雰囲気を盛り上げる効果もありますし、テンションがあがるというのもあります。
これは意外と効果があって、ドラゴンをみつけたら次は「ドラゴンハント」をしないとねという感じに盛り上がりました。
事前におこなったこと
いろいろな方にStailerを触ってもらうためには、事前に用意しておくべきものが必要になります。 事前準備をしないで「ドラゴン探し」を実施すると当日ドタバタしてしまうのは目に見えています。
そこでまず最初に次を決めました。
- 開催する場所：オンライン
- 開催時間：2時間（実施時間は1.5時間程度）
本当は物理で集まって開催したかったのですが、時期的にそれは厳しいなと思ったため「オンライン」開催としました。 Stailerではスマホだけでは完結しない操作もあるのですが、オンライン開催に伴いそれらの操作については対象外としました。
時間としても長すぎるとだらけてしまうこともありえますし、また全員の時間を長く確保するのは難しいということもありました。 そこでドラゴン探しの時間自体は「1.5時間程度」とし、前後にオープニングとエンディングを用意して合計2時間としました。
これらを元に事前にやっておくべきことを「主催者側」「参加者側」それぞれリスト化しました。
主催者がおこなうべきこと
当日までにおこなうべきタスクとして次をリストアップしました。
- [ ] 参加者に応じてチーム編成
- [ ] 利用するNotionページの用意
- [ ] 利用するSlackチャンネルの用意
- [ ] 「ドラゴン探し」用のドラゴン発見時の起票に利用するJIRAのtemplateを用意
- [ ] JIRAのKANBANとNotionのJIRA syncの設定
- [ ] 「ドラゴン探し」でドラゴンが見つかって起票されたらSlack通知の設定
- [ ] 「ドラゴン探し」で起票されたバグ一覧を見られるページの用意
- [ ] 作ったSlackチャンネルに参加者を招待
- [ ] どのチームがどのアプリや環境を利用するかを事前に決定しNotionに記載
- [ ] 参加者に利用するNotionページの共有
チーム編成においては、SWEだけのチームは作らないようにしてどのチームもSWE以外の方もいる形としました。
たとえば当日、実際にSlack通知している例は次のような感じです。 こうやって通知されることで、参加者全員どういうのが見つかっているのかがわかりやすくなるようにしました。
参加者がおこなうべきこと
参加者の方には事前に用意しておいたNotionページを共有した上で、次をおこなってもらうようにしました。
- [ ] チームメンバーの確認
- [ ] チームメンバーでチーム名の決定
- [ ] アカウントの用意
- [ ] テストアプリのインストール
- [ ] 事前の動作チェック
チーム名の決め方としては任せましたが、こんな感じ（？）で続々と決まっていきました。
当日
当日は、次のような形でおこないました。
- オープニング（わたし）：今日の趣旨や時間の流れを伝える
- ドラゴン探しの旅に出る：各チーム単位のブレイクアウトセッションを用意
- エンディング（わたし）：ポイント集計と結果発表
ドラゴン探しの旅がはじまると、開始5分以内にはSlackへドラゴン発見の通知が飛んできていました。
QAチームの関わり方
Stailerはなかなか複雑なサービスです。
事前のセットアップ方法についてはドキュメントにある程度書いておきましたが、なにかあればサポートするようにしました。 また、進行中においてもなにかあればQAチームに質問をしてもらうようにしました。
主催はQAチームなので、当日のファシリテーターをおこないました。 この「ドラゴン探し」を楽しんでもらうためにも、オープニングのときから参加者の方への雰囲気作りなどをおこないました。 たとえばテーマにあうような感じのBGMを流したり、Meetの背景をドラゴンが軽くうつっているようなものにしたりしました。
チームのポイントのつけかた
やるからにはチーム戦としておこないたいところです。 そこで、チーム単位でポイントをつけて優勝チームを決めることとしました。
みつけた「ドラゴン」の数で決めるのではなく、「ドラゴン」の種類に応じてポイントをQAチームのメンバーが決めて、その合計ポイントで優勝チームを決めることとしました。
ポイントは1〜3点として、QAメンバー3名がそれぞれ主観で決めたルールにしたがってつけてもらうこととしました。 次があるメンバーの決め方の例です。
- 某メンバー：点数のつけかた「発見難易度」
- 1: 条件なくボタンぽちーで見つかるバグ（既知バグだけであってほしい！）
- 2: QA視点を持ってちゃんと検証したら見つかるバグ
- 3: 頑張らないと見つからないバグ、すごい！ みつけた人はQAチームへ転向を検討しませんか？？
3名がポイントを付けた例は次のような感じです。
今回の「ドラゴン探し」でみつけた潜在バグがすでにあったものか、未検知だったかあとでQAチームでまとめています*2。 その結果を上図の一番右側に記載しています。
ドラゴン探しの結果
今回の「ドラゴン探し」は参加メンバーがある程度いたので2回にわけて実施しました。
その2回でみつけた「ドラゴン」と参加者数は次のような感じです。
| 参加者数 | みつけたドラゴンの数 | |
|---|---|---|
| 1回目 | 13 | 48 |
| 2回目 | 10 | 29 |
実施後に今後の改善もおこなうためにアンケートをおこないました。 結果としては、満足度が非常に高い結果をもらいました*3。
おわりに
アンケート結果からもわかりましたが、今回の「ドラゴン探し」は当初期待していたとおり次のような効果がありました。
- Stailerについてより知ることができた
- Stailerを通して他職種の方と連携できた
- QAチームといろいろとできた
とはいえ、「潜在バグ」を見つけるという行為を「ドラゴン探し」に頼るだけではよくありません。 「潜在バグ」が一定あることは課題であるため、現在はまだある「潜在バグ」をみつけることは別の施策で進んでいく予定です。
また、社内からもまたやりたいという声もあります。 さらに、現在新しく入社してくる方にはQAチーム主催のOnboardingをおこなっていますが、そのときに「ドラゴン探し」の話をするとぜひ参加してみたいという声があがります。 そこで、今回だけのものとはせずに、また開催しようとと思っています。
しかし、次回の「ドラゴン探し」においては、かんたんに「ドラゴン」が見つからないようにしておきたいと思います！ 次に「ドラゴン探しの」記事を公開する際には、みつけたドラゴンの数が変化していることを期待しておいてください。
