こんにちは、とあるスクラム開発の現場でQA担当をしている者です。
この記事はただの集団 Advent Calendar 2019の14日目の記事です。

13日目の記事はlittle_hand_sさんの議論が噛み合わないと思ったら、「問題解決の5階層」でどこがずれているのか確認するでした。
「FACTから語れ」とはよく言われますが、具体的な認識合わせをするためのコミュニケーションはさぼっちゃいけないですね。
そこをすっ飛ばして抽象的議論で語った気になっていると噛み合わないままで終わってしまうのかなと思いました。
議論するみんながこの「問題解決の5階層」を知っていることは意味がありますね。

私は2019年7月より現在のプロジェクトjoin後、ずっと1人でQA対応していましたが、10月最終週〜11月初旬から一気に5名体制となり
走りながら1ヵ月でチームビルディングをしてきたのでその軌跡を残しておきたいと思います。

※なぜ少しずつの増員ではなく一気に5名体制になったのかについては話が長くなるので割愛します。
※なぜろくな準備もできなかったのかについても、割愛しますｗ

現在のメンバー（join順）

私…統括リーダー。QA経験豊富。テスト大好き。
Aさん…諸事情により0.5人月の契約。テスト経験豊富。
Bさん…別プロジェクトにアサインされていたところを奪った。テスト経験豊富。
Cさん…別プロジェクトにアサインされていたところを奪ったその2。20代前半の新人。前職で多少テストの経験はあるが、畑違い。
Dさん…20代前半の新人その2。別業界から転職してきたばかりでIT経験・テスト経験無し。

前提条件（QA現場の状況）

・1スプリントは1週間
・テストケースは基本的に書かず探索的テストをしていた
・必要性を感じたときのみパターン表のようなチェックリストを作成する

QA2名時代概要

0.5人月契約のAさんが10/28（月）よりjoin。
私とは前の現場で一緒だったこともあり、あまり説明せずともすぐに勘所を理解いただきテスト実行の協力してもらえました。
当初の11月初旬という大規模プロジェクトのリリース目標日に合わせて前半にリソースを集中させたので、11月中旬からは週1〜2回程度の出勤となりました。
11月はスプリントの都合に合わせ火曜日に0.5人日、金曜日終日という出勤体制にしてもらいました。

QA4名時代概要

Aさんのjoin後2週間でベテランBさんと新人Cさんが11/8（金）よりjoin。
Bさんは夏から秋にかけて横断プロジェクトで間接的に関わっていたし、Cさんも正式join前にBさん指導のもと2日間プロダクトの予習をしておいてくれたので、比較的すんなり業務にはいれました。
この2名は本来ネイティブアプリQAとしてのjoinでしたが、POの意向もあり11月中はwebのQAを協力いただけることになりました。

QA5名時代概要

翌週11/11（月）より新人Dさんjoin。ここから5名体制になります。
私とAさんを除き、メンバー同士お互いにほぼ初対面という状態です。
Dさんは初日は研修のみで、その後リリース目前で慌ただしかったこともあり、数日間はひたすら1人でプロダクトの勉強をしてもらいました。
使用した教材は私がjoin時に作成していた「仕様疑問シート」です。
当時プロダクトをさわってみて判明した仕様について、「疑問」「バグ」「わかった」ステータスをつけていたので、追体験する形でみてもらった方が効率的かなと思いました。

この頃の状況をカレンダー形式で表現↓

以下は5名体制になってから行ってきたことです。

11/11週：初動期

5名体制になって最初の週は、リグレッションテストを繰り返し行う必要があり、出勤日がマチマチのAさんと新人Dさんを除く3名で何度もリグレッションテストを行っていました。
そのかたわら、新人Cさんにはjoin後3日目にして小さいストーリーポイントの正常系テストの対応を依頼してみました。
基本的にテストケースをつくらない体制なので、アドホックテストのようになります。
新人には難しいことを依頼している自覚はありますが、Cさんはテスト実行自体の経験はある方なので、お任せしました。
なかなか実直で手堅いテストをする方だということがわかり安心しました。
この週にQAチェック基準を変えた（二段階チェックをするようにした）こともあり、少なくとも仕様記載通りの正常系テストはCさんに委譲するようにしました。
15日（金）には、ベテランBさん、新人Cさん、新人Dさんの3名で機材棚卸し（テスト用検証機＝スマートフォン）と整理をしてもらいました。
機材管理も大切な仕事です。
私も新人の頃随分といろいろな目に合いましたし、管理の方法や人間心理なども考えたので、新人Dさんの経験としても有用だろうと思いました。

11/18週：「見（けん）」の時期

見出しの「見（けん）」とは私の愛読書『うらおもて人生録』（色川武大著）からとっています。
（何かをはじめようとするとき、できあがっている場にはいろうとするとき、まずは「見（けん）」をする）

新人Dさんの学習のみの期間も終わり、月曜には新人Cさんと新人Dさんの2名で正常系テストのダブルチェック体制を敷きました。
その裏で私はチームメンバー用にスキルマップを作成しており、各自入力してもらうよう促しました。
スキルマップ作成の目的は「お互いの得意・不得意を知り、カバーし合える関係をつくるため」です。
また、私やベテランBさんからみて、新人たちがどのような研修を受け何を知っていて何を知らないのかが判然としていなかったため、今後の教育方針を検討する上でも必要だったという理由もあります。
スキルマップの基準値はTest.SSFという業界のスキル標準を参考にして若干アレンジしました。
はじめは入力項目の多いスキルマップを作成してしまいましたが、自分でも入力が途中でイヤになってしまうほどだったのでベテランBさんにも相談して項目はかなり絞りましたw
結果、新人たちも1〜2日あれば業務の合間に入力できるものになりました。

19日（火）に、ようやくメンバー向けにこれまでの1人QA体制で何をしてきたのかを説明する時間をとれました。
このあたりで業務の流れで、ちゃきちゃき新人Cさんが非常にQA依頼へのキャッチアップが早く、私が足止めをするという事件（？）がありました。
これまで通り私が窓口として矢面に立っていた方が新人たちのリスクおよび品質リスクを減らせると思っていたので、チーム内では当面トップダウンで指示をだす方針としたかったためです。
そのときのメンバー向けの説明は
「テストしました、不具合あります」
より
「テストしました。不具合ありません」
という言葉の方が重い。
というものです。この責任は私がかぶることにしたかった。
わかってくれたかな。

20日（水）にはベテランBさん、新人Cさん、新人Dさん、私でスコープ重めのテストを分担して実施するということをしました。
仕様通りの正常系テストは新人たちが実行し、ベテラン組は準正常系や周辺領域をカバーするやり方としました。
新人Dさんはこの日初めてダブルチェックではないテストをしたことになります。
新人たちには、実行したテストパターンを指摘事項とともに詳細報告してもらうようにしました。
結局ポテンヒットのような奇怪なバグを偶然見つけてくれたので、やりがいがあったのではないかなと思います。

21日（木）に出勤日ではないAさんを除く4名でランチにいきました。遅いですね。
またメンバー向けプロダクトの仕様説明会もしました。遅いですね。
これまではテスト後の不具合報告を受けても、私の方で事象をジャッジしてエンジニアに伝えるだけで精一杯で、QAメンバーへのフィードバックをする余裕もなかったのです。

また、この日ベテランBさん、新人Cさんと私で品質ガイドラインを検討すべくブレストを行いました。
手法はVSTePを意識しました。
これも業務多忙にかまけて未完成なので、年明けから続きにとりかかりたいです。

22日（金）には初のQAチームふりかえり会を行いました。遅いですね。
はじめに、スキルマップに入力してもらった内容を元に、「他己紹介」を行いました。
メンバーがそれぞれ他者の紹介をするというものです。
組み合わせはなるべく普段の関係性が薄い者同士を選びました。
5人なので、30分の枠では1人5分しか紹介できませんでしたがなかなか楽しかったです。

ここで新人たちに明らかにしたのですが、実はこの週「新人が分担してテスト実行していた」と思わせていたバックログについて、実は裏でベテランAさん、Bさんにもダブルチェック＋αを依頼しており、こっそり私宛に報告をあげてもらっていました。
やはりベテランの方がテスト観点の目は行き届いているので、不具合報告精度をあげることができます。
また、裏でこっそりやっていたのは、はじめから「ベテランがカバーするよ」という方針を明示的にしていると新人たちの責任感が育たないかな？　という点を懸念してのことでした。
ふりかえりで、ベテランがあげてくれた指摘事項を新人たちが学べたと思うので、これからの自分なりのテスト観点に生かしていってほしいです。

また、この日はベテランAさんと新人Dさんにペアテストをしてもらいました。
Aさんがナビゲーター、Dさんがドライバーです。
実はAさんはテスト経験自体は豊富であるものの、これまで「後輩を育てる」という経験をしたことがほぼなく、本人の意向もあり一緒に新人教育をしていく体制としたのです。
ペアテストは時間はかかるものの（単純に倍以上）、Dさんには仕様調査からの思考の仕方やテスト観点の掘り下げ方など学びがたくさんあったのではないかなと思います。
度々「自分が学んだことを箇条書きで良いので書き起こしておいて」と依頼していたので、近いうちConfluenceにでもアウトプットしてもらおうと思っています。

11/25週：チャレンジの時期

この週からBさんとCさんは本来のネイティブアプリQAとしての体制準備をはじめました。
11月いっぱいはwebQAの協力に専念いただく予定でしたが、アプリもとりかからないとまずい状況になってきたためです。
そのため新人Dさんの独り立ちも急務でした。

26日（火）はAさんが半日出勤日だったので、Dさんのテスト報告へのレビューをAさんに行ってもらいました。
また、本番リリースがあったのでメンバーたちに初の「本番リリース後テスト実行」を依頼しました。
本番リリース後はかける時間も少なくなければいけないし、スプリントで実行するテストよりスコープを広げてみるのでテスト観点も少し違います。
報告結果を元にこの日にすぐQAチームふりかえり会を行い、新人たちに「本番リリース後のテスト」の勘所をお伝えしました。

27日（水）に新人Dさんに初めてチェックリストの作成を依頼しました。
これまで勤怠表など事務作業的なスプレッドシートは作成したことがあると思いますが、ここにきてテスト用のチェックリスト作成は初めてになります。
サンプルとして過去分の資料を示し、「真似してつくってみて」という感じでチャレンジしてもらいました。

28日（木）の夕方に、新人Dさんにとあるテストをふった上で、「6畳の部屋の掃除の話」をしました。
これは私が現在の会社に入ったばかりの頃に副社長（当時は現場マネージャー）から聞いた話で、わかりやすくて気にいっているのでいろんなところで話していますw
仕事を進める上で、6畳の部屋を掃除するときに1畳ずつ掃除していては部屋全体がきれいになるのが遅くなるので、まずは6畳全体をちょっとだけきれいにする。
それから気になるところを掃除していく。という順番の方が良い。
というお話です。

29日（金）はAさん出勤日なので、新人Dさんと2人でテスト実行をバックログ2件分してもらいました。
進捗確認MTGをこまめにいれて、フィードバックを高速にまわすようにしました。

まとめ

スキルも経験も違うバラバラだったメンバーたちで、テストを実行する体制をどのようにつくりあげていったのかについて記述してきました。
じっくり準備する期間はなかったので、新人にははじめに覚えて欲しい内容（テストの腕を磨く）を絞り、ベテランを味方につけるという進め方で走ってきました。

すべて完璧だったわけではありませんが、ベストプラクティスを考えた結果だと思っています。
12月現在も少しずつやり方を変えていったりしていますので、機会があれば書いていこうと思います。
最後までお読みいただきありがとうございました。