Asanaを議事録として使ってみよう！〜バグバッシュでの活用事例〜
こんにちは、AsanaアンバサダーのTannyです。普段は株式会社Mobility Technologiesで、タクシーアプリ『GO』の法人向けサービス『GO BUSINESS』のプロダクトマネージャー（PdM）を担当しております。
先日、Asanaの活用事例を眺めていたところ、会議の議事録として活用する例を見つけました。会議の議題をタスクとして登録しておき、持ち帰り課題となったものは残タスクとして残しておくというものです。
なるほどこれは便利そう！というわけで、今回は弊社の開発チームで実施している「バグバッシュ」という活動で、Asanaを議事録として活用してみることにしました。通常の会議とは少し性質が異なりますが、非常に有効に活用できたので、その内容をご紹介します。
会議の結果などを通常のドキュメントツールで管理していて、事前準備や残タスクの管理に課題を感じている方のヒントになれば嬉しいです！
やったこと
「バグバッシュ」の準備項目や実施結果を管理するAsanaテンプレートを作成した。
バグバッシュで見つけたバグをAsanaのタスクとして起票して、そのままバグチケットとして管理した。
その結果どうだったか
Asanaテンプレートをコピーして利用することで、準備項目の抜け漏れがなくなった。
見つけたバグがもれなくタスクとして起票されるので、バグの管理が容易になり、改修漏れがなくなった。
バグバッシュとは
バグバッシュとは、みんなでワイワイプロダクトを触って不具合を出そうという会です。品管チームでのテストを開始する前に、開発チーム内でプロダクトを触っておくことで、「デザインが違う」とか「正常系のフローが実行できない」といった単純なバグを先に見つけることができます。
バグバッシュについての詳細は、iOSエンジニアの古屋さんが弊社の開発ブログで紹介しているので、こちらも併せてご覧ください。
バグバッシュは以下のように準備し、実施しています。
準備
(エンジニア) テスト用のアプリを開発環境に配信する
(参加者) アカウント作成など、事前準備を実施しておく
実施
アプリを触ってバグを見つけまくる！
バグを見つけたらSlackで報告する
終了したら、Slackを読み返してバグかどうか確認し、得点をつける
得点は後で集計して、表彰する
バグをAsanaに起票して、エンジニアが改修を進める
これを本格的に実施し始めてから1年半くらいになります。今では毎月のようにやっていて、毎回10個以上(多いと30個以上)の不具合やデザイン不備をテスト開始前に発見することができています！
これまでのバグバッシュにおける課題
バグバッシュの実施前後の時期、エンジニアはテスト直前で大忙しなので、バグバッシュの準備やファシリテーションはPdMが実施しています。これを何度か実施していく中で、以下のような課題に気づき始めました。
準備
準備事項をGoogleドキュメントで管理しているので、アプリの配信忘れなど、必要な準備作業が漏れていることがある。
実施
Slackに記載されたバグをAsanaのタスクに起票するのが面倒。起票し忘れることがある。
エンジニアが個別にAsanaのタスクを起票するので、バグの改修状況を確認しづらい。
得点の集計作業が地味に面倒。（得点は1~3点の範囲で付けます）
そんな中、「これをAsanaで管理したら便利なのでは🤔」と気づいたので、Asanaのテンプレートを用意し、実際のバグバッシュで活用してみることにしました！
バグバッシュでAsanaを活用する
バグバッシュは何回も実施するイベントなので、Asanaのテンプレートを用意しました。ちなみに、2022年4月にテンプレートの形式が新しくなり、相対日付などを利用できるようになっています。今回はこの新しい形式でテンプレートを作成しています。
これまでのバグバッシュで利用していたドキュメントなどを参考にしつつ、出来上がったテンプレートがこちらです！（実際のものとは一部の項目が異なります🙇♂️）
このテンプレートの内容について、簡単にご紹介します。
「事前準備」セクション
バグバッシュでテストを実施するために必要な準備項目を記載しています。アプリの配信などのタスクは担当エンジニアに割り当てて、「誰が配信するんだっけ？」というようなモレを防止しています。
参加者に事前に確認しておいてほしい「参考情報」などはタスクの説明欄に記載しています。ドキュメントツールと遜色ない情報が記載できるのも、Asanaの良いところですね。
また、新しいテンプレートの「相対日付」機能を利用して、事前準備の期限は「バグバッシュのn日前」という形でテンプレート上では定義しています。
「タイムスケジュール」セクション
バグバッシュの時間割を記載しています。バグ出しに夢中になっていると残り時間を忘れてしまいがちなので、Asanaに記載しておくと便利です。
会議の議事録として使う際も、会議のスケジュールを記載しておくと良さそうですね。
「発見したバグ」セクション
バグを発見したら、こちらのセクションに追記していきます。カスタムフィールドとして「種別」「対象システム」の欄を設けているため、そのバグがどういうタイプのものか、パッと見て判断できます。Slackだと人によって書き方が異なってしまいますが、こうしておけば表記を統一できる上に、ソートや検索も実施できます。
バグを見つけ終わった後は、カスタムフィールドの「得点」欄に得点を入力していきます。最後に「作成したユーザー」でソートをかけることで、参加者ごとの得点計算が自動で完了します！これまではSlackの履歴を辿りながら得点を集計していたので、非常に便利になりました。
バグバッシュが終わった後の対応
バグバッシュが完了したら、バグの改修を進めます。既にAsanaのタスクとして起票されているので、担当者の割り振りや他のプロジェクトへの割り振りなども自由自在！いつものバグチケットと同じように管理することができます。
また、これらのタスクはバグバッシュのプロジェクト上にも残り続けるので、バグの改修状況も簡単に確認することができます。
実際に活用してみた感想
このAsanaテンプレートを、実際のバグバッシュで利用してみました。結果としては、非常にスムーズに導入でき、これまで感じていた課題を全て解決できたと思います🙆🏻♂️
PdM目線では、事前の資料準備をテンプレートの複製だけで実施できるようになり、バグバッシュ終了後の集計作業も一発で終わるようになりました。これであれば準備の負担感もないですし、むしろ他のメンバーにお願いしても良さそうです。
改修することになったバグチケットも、エンジニア自身が開発用のBacklogに紐づけるだけで良いので、後の対応が非常に楽です。また、改修方針などはAsanaのコメント上でやりとりできます。バグの再現方法なども起票者に質問しやすくなりました。このように、Asanaを議事録として使うことで、その会議で出てきた課題をAsanaのタスクとしてシームレスに扱えるのが非常に便利な点でした。
ちょっとした課題としては、Asanaではプロジェクトをフォルダ階層で管理するような仕組みがないことが挙げられます。過去のプロジェクトを後から参照したい場合は、別のドキュメントツールからリンクを貼っておくのが良いと思います。
おわりに
これまでのAsanaの活用方法としては、プロダクトの課題管理表やスクラム開発のBacklogなど、1つのプロジェクトを長期間利用するケースがほとんどでした。なので今回のように、プロジェクトを1回のイベントだけで使い終わるケースはありませんでした。
ですが、Asanaは非常に柔軟なツールなので、バグバッシュのような会議用のボードとしても便利に活用することができます。皆さんの業務でも、フィットしそうな事例があれば、今回の例を参考にして活用してみてください！