バグ情報も使い方によっては、チームの効果的なコラボレーションツールになるんですよ

Agile2013、2日目の9:00-10:15に行われたClaire Mossさんのセッション “Big Visible Testing” に参加しました。
Agile2013_BigVisibleTesting_Claireさん

Claireさんは、Oracle社のQAエンジニアで、テスターの立場から現場改善を主導している方です。

Experience Report(事例紹介)ジャンルのセッションで、同じ現場改善の実践者として興味があったこと、「テストの見える化」がどういうものかに非常に興味があったことから参加しました。さらに、渡米中の飛行機内でHenrik Knibergさんの『Lean from the Trenches』を読んでいて、ちょうどバグの見える化が課題だという記述(9.4 Visualizing Bugs)を見つけたところだったので、非常にタイムリーだなとも感じての参加でした。

彼女はかなり熱い実践者でした。

■テスターとしての悩み:課題認識

Claireさんのチームでは当初、バグが見つかった場合にどれを優先的に解決すべきか、チーム内でうまく合意をとれずに苦労したそうです。そのため、コミュニケーション方法の工夫が必要になるのですが、Claireさんは2種類の「見える化」によって実現しました。

■見える化その1:チームメンバーのペルソナ

Claireさんのチームは、Product Manager(ビジネスサイドのメンバー)、UX Designer、Developerで構成されるスクラムチームです。テスターであるClaireさんにとって、彼らはチームメイトであると同時に、テストユーザまたはステークホルダーと見ることもできます。

プロダクト開発では、ステークホルダー分析を行ってニーズ・要望を把握します。Claireさんは、チームメンバーをテストのステークホルダーと捉え、チームメンバーのペルソナを作成することで、テスト・バグに対するニーズ・要望を見える化したそうです。

ペルソナを作成した結果、チームメンバーが次のようなニーズ・要望を持っていることが分かりました。

Product Manager

  • バグの重大性(Severity)は?
  • テストのROIはどれくらいか?
  • (そもそも)プロダクトをリリースできるか?
  • どうやって早く価値を提供できるか?

Agile2013_BigVisibleTesting_BusinessAdvocate-Persona

UX Designer

  • バグがどの機能に多いか?
  • バグを再現できるか?試せるか?
  • 見た目の要望を満たしているか?
  • 機能の正確性を満たしているか?

Agile2013_BigVisibleTesting_UserAdvocate-Persona

Developer

  • 原因は何か?
  • 次に何をすればよいか?
  • 動作するか?

Agile2013_BigVisibleTesting_TechnologyAdvocate-Persona

この時点で、ステークホルダー毎にテスト・バグに対する要望・ニーズに差異があることが分かります。

■見える化その2:ステークホルダーに応じたバグボード

Claireさんは、ペルソナに続いてステークホルダー毎にバグボード(バグを書いた付箋を貼ったタスクボード)を作成しました。ステークホルダー毎の関心事に応じてバグの見せ方を変え、バグのDoD(Definition of Done:完了の定義)を明確化することで、バグ解決をスムーズにしたのです。

具体的には、次のようなバグボードを用意しました。

Product Manager

バグを重大性(Severity)の順に整理し、どのバグから解決すべきかを判断。
Agile2013_BigVisibleTesting_BusinessAdvocate-BugBoard

UX Designer

バグのサイトマップを作成し、どの機能のバグ群を重点的に解決すべきかを判断。
Agile2013_BigVisibleTesting_UserAdvocate-BugBoard

Developer

スプリントボードにバグタスクを組み入れ、どのタイミングでバグを解決するかを判断。

  • スプリントボード上にバグのレーンを用意し、Timebox化して1つずつ解決していく。
  • ストーリーにバグタスクを振り分け、1つずつ解決していく。

Agile2013_BigVisibleTesting_TechnologyAdvocate-BugBoard
Agile2013_BigVisibleTesting_SprintBoard-Bugs&ExploratoryTestingCharters

バグボードを作り分けたことで、各ステークホルダー内外のコミュニケーションが増え、結果としてチーム全体のマインドがポジティブに変わってきたそうです。

■現場の改善ストーリーにこそリアルがある

  • テストのステークホルダーのペルソナを作成する。
  • バグ情報をペルソナ毎に再構成・提供することで、迅速な開発と修正を実現する。
  • これらをテスター主導で実現。

チームメンバーのペルソナを明確化し、それをもとにバグ情報の見せ方を工夫していくストーリー展開が、現場の課題解決を生き生きと伝えていて、非常に参考になりました。

有名な方の理論ももちろん有効です。それ以上に現場での試行錯誤のレポートは、その学習過程が明確なことと、同じように試行錯誤している自分と重ね合わせやすいことから、より身になることが多いと感じました。

■QAの新しいロールモデル

もうひとつ私が注目したのは、一連のバグの見える化を通じて、Claireさんがチームメンバーをコーチングしながら、テストを円滑化していったという点です。Claireさん自身も、一連の活動を通じてチームメンバーをクロスファンクショナルなチームへ育てていったということを話していました。

私がよく耳にするQAエンジニア像は、開発チームから「降りてきた」プロダクトのテストを「押し付けられる」というものです。開発チームと切り離され、どちらかというと無理を押し付けられて難儀しているQAエンジニアたち。

ですがClaireさんのやり方は、QAエンジニア側から開発チームに働きかけて、テストのしやすいプロダクトやチーム構成にしていくものです。これはスタート地点は違うものの、私が取り組んでいるアジャイルコーチの仕事と同じです。

こうしたアプローチは、QAエンジニアの新しいロールモデルとしてもよいのではないかなと思います。

※注:レポート内のスライド画像は、Claireさんの許可を得て掲載しています。

公認レポーター 伊藤 宏幸


もっと知りたい!Agile2013

3 Replies to “[8/6] バグの見える化によるコラボレーションが熱い!:Agile2013 レポート(5)

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です