2人目QAがスクラムチームで自律的に動けるように1人目QAがやったこと

はじめに

• そんなに目新しいことは書いてないと思います。
• 2人目 QA がスクラムチームで自律的に動けるようになったのは、1人目 QA がどうこうしたからというよりも、本人のスキルやマインドセットが大きな要因だった可能性もあります。
• 本記事は備忘録的な側面もあり、整理が十分ではないです。あらかじめご了承下さい。

想定読者

• 2人目 QA を迎えるにあたってどんな準備をすればいいか悩んでいる人
• QA の育成に悩んでいる人

前提情報

• あなたは何をしている人？
  • QA として複数の受託開発案件に並列参加し、一連のテストプロセスの遂行を担ったり、仕様レビューや E2E テストの作成および運用（mabl）などを駆使してアジャイル開発のテストにトライしている人。JSTQB FL 持ち。QA 歴たぶん3年目。
• 2人目 QA は何者？
  • インターンで来られた社会人2年目の方。
  • １年目はプログラマーとして仕事をされていた。開発経験はほぼ無し。
  • QA の経験は無し。しかし興味があり、半年間トライしてもらうことになった。
• タイトルに書かれている『自律的に動ける』とは？
  • 他人からの指示がなくてもプロジェクトにおいて必要だと感じたことを自分の判断で取り組めたり、周囲に働きかけができる状態を指しています。

本題「2人目QAがスクラムチームで自律的に動けるように1人目QAがやったこと」

プロジェクトの目的と体制の全体像を伝える

自分が関わる QA の業務だけでなく、それを取り囲むプロジェクトそのものの目的や現在の状況、またそれを実現するために現在組まれている体制や会議体を伝えました。

QA の業務だけを切り出して伝えると、伝えた範囲の QA 業務しかやることの選択肢として思い浮かばなくなると思ったので、それ以上の全体像を伝えて、それを踏まえた自分なりの QA のやるべきことを考えてもらいやすくする意図がありました。

結果としては「こういう QA のやり方が良いと思うのだけどどうか？」といった意見を出してもらえるようになりよかったです。

自分（1人目QA）がやっていることを参照可能にする

仕様レビュー、テストケースの作成および実施、バグ起票、自動E2Eテストの作成および運用、リリース判断およびリリース作業を主にやっていました。これらの業務の取り組み方や考え方をできる限り他人（2人目QA）が参照可能になるように頭の外に書き出しました（自分の場合は miro を使いました）。また、自分が困った時に参照する資料やブログなどのリンクも共有していました。

2人目QAが QA の仕方について困った時、自分がすぐにサポートできないことが2人目QAの作業のボトルネックになってしまうのを防ぎたい意図がありました。また自分の参照可能にした情報を駆使して2人目QAがどんどん自分で仕事を進められるようにしたい意図がありました。

結果としては、わからないことがあっても参照可能にした内容を取っ掛かりに、自力で解決方法を見つけてどんどん仕事を進めてもらえていた印象です。「自分で調べてね」という姿勢が強すぎると1人で悩む時間が長くなってしまう恐れもあったので、以降に書いているデイリーの取り組みや、制限時間の設定などでカバーするようにしていました。

アウトプットをレビューする/してもらう

1人目QAと2人目QA同士で、テスト観点や自動E2Eテストといったアウトプットに対してレビューを行っていました。気になったところ、不足を感じたところ、良いと感じたところを伝え合っていました。

レビューされること/することを通じて私（1人目QA）と同等以上のスキル（ここで言っているスキルとは、テスト観点の導出や自動E2Eの設計スキルを指しています）を効率よく身に着けてもらうことを意図していました。

結果、かなり効率よくスキルを身に着けていった印象です。

QA 内でデイリーをする

スクラムイベントの中にデイリースタンドアップというものがあります。これは毎日15分程度で行う MTG で、各自の進捗や抱えている障害をチームの課題として取り組めるようにするためのものです。このスクラムチーム内でのデイリーとは別に QA だけが参加するデイリーも行っていました。主に、その日やったこと、明日やること、困っていること、それ以外に話したいことを話します。

スクラムチームのデイリー以外でもこういった時間を取ったのは、実装者や PO にとっては細かすぎたり専門的過ぎる QA やテストに関する話を気軽に共有できる場を作って、QA やテストならではの問題を早めにキャッチアップ・解消しておきたかったのが意図でした。理想を言えば、QA が困っていることを気兼ねなくスクラムチームに向けて話せるのが良い気がしますが、慣れないうちは違う役割のメンバーに対して QA やテストの困りごとを伝えるのは難しいと思ったため別途機会を作った方がいいだろうという判断でした。

結果、全体に共有する前にもう少し整理できた方がいい議題を整理できたり、日々の細かい QA やテストに関する工夫などを聞けて、2人目QAのスキルアップを把握できたり、学びを得ることができ、かなり有意義な時間になっています。また、同期的にやりとりできる時間が毎日あることで、テキストのやり取りでは難しいディスカッションも早めに行えて便利でした。

ここからは「QA未経験者の育成を行う」という観点で取り組んでいたことを書きます

2人目QAの方に、いつまでにどれくらいのことができるようになっていてほしいかを整理しておく

ひと月スパンでマイルストーンを設定した"やれるようになってほしいことロードマップ"を最初に作りました。このロードマップをベースにお願いする業務範囲やレクチャーする内容を調整していました。このロードマップは本人にも見せて、本人の意向と異なる場合は、ロードマップを調整するなどしていました。

結果としては、このロードマップがあったおかげで、場当たり的に業務をお願いしたり、レクチャーしたりをしなくて済んだのですごく重要な作業だったと感じています。自律的に業務に取り組めるようになった現時点ではこのロードマップは使っていません。

自分でもやり方に悩みそうな仕事は、先に自分でやってみる

自分でも進め方のイメージができてない仕事を"お試し"として未経験者に振ってみても効率が悪いということに気づきました。振られた側もどこからとっかかればいいかわからないためです。ある程度自分で進めてみて「あぁここが難しいな」というような躓きポイントを明確にしてから振ってみると、そこを起点に振られた側が試行錯誤ができるようになり、より早く期待値以上の成果を出してもらえるようになりました。

おわりに

自分は育成担当ではないのですが、QA 未経験者と一緒に QA をやる経験が上手くいったので、その時にやったことを覚えておこうと思いこの記事を書きました。誰かの参考にもなったらうれしいです。
整理が不充分なため、わかりずらい内容もあったと思います。わかりずらかった点や気になった点があればぜひ X でツッコミいただければと思います。