QAメンバースキルとQAチーム構成

2022年3月10日にJaSST東京でJATQB-ALTMのチュートリアルのパートの１つを受け持つことになりました。

そこでは、JSTQBテストマネージャーシラバスの７章「スタッフのスキルーチーム構成」について解説とワークをやる予定です。

久しぶりにシラバスを読み直してて、これはQAチームを作って、メンバーを迎え入れてチームを大きくしていく時に役立つノウハウだなって思ったので、「QAメンバースキルとQAチーム構成」ってタイトルでこの章に書いてあることを私の私見を交えてnoteに書くことにしました。

「QAチームは本当に品質を保証しているかという議論があるかもしれませんが、その用語はテストチームに当てはめる一般用語になってしまってるので」　実戦アジャイルテスト　P.60

このnoteでは、上記に引用する記述もあるくらいなので（笑）、QAのことをソフトウェア開発の組織で主にテストを専門にする組織と、各プロダクトの開発チームにアサインされるQAメンバーのこととして記載します。なのでテストとQAはこのnoteの中では同義だと思ってください。

「スタッフのスキル - チーム構成」の概要

7.1 イントロダクション

この節で、QAマネージャーはQA組織をどうやっていくのかってことが書かれてます。シラバスに書いてあることを以下に引用します。

有能なテストマネージャは、スキルが適切に混在するように、チームメンバの求人、採用、維持を行う。スキル要件は、時間経過と共に変化する可能性があるので、最初に適切な人を採用することに加えて、テストチームを保持し、最高の仕事の水準を維持するために、適切なトレーニングと成長機会を提供することが重要である。チームのスキルだけでなく、テストマネージャは、プレッシャーが厳しかったり、進みが速かったりする環境で効果的に機能するように自身のスキルセットを維持する必要がある。
（JSTQB アドバンスレベル　テストマネージャーシラバス　P72）

JSTQBのシラバスにて、この章の「学習の目的」は以下の通りになっています。

7.2 個人のスキル 

TM-7.2.1 （K4）スキルアセスメントスプレッドシートを使用して、ソフトウェアシステムの使用、ドメインおよびビジネスに関する知識、システム開発領域、ソフトウェアテスト、対人関係スキルに関する、チームメンバの強みと弱みを分析する。 

TM-7.2.2 （K4）チームのスキルに関するアセスメント結果を分析し、トレーニングとスキル開発計画を策定する。 

 7.3 テストチームの力学 

TM-7.3.1 （K2）特定の状況でテストチームのリーダとなるために必要なハード面とソフト面のスキルについて説明する。 

 7.4 組織内におけるテストの適合 

TM-7.4.1 （K2）独立テストのオプションを説明する。 

 7.5 モチベーション 

TM-7.5.1 （K2）テスト担当者のモチベーションを上げる要因、および下げる要因について、例を挙げて説明する。 

 7.6 コミュニケーション 

TM-7.6.1 （K2）テストチーム内、およびテストチームとステークホルダとの間のコミュニケーションを、効率的に行うための要因を説明する。

個人のスキル（QAメンバーの成長機会をどう作るか）

この節は自分たちのQAチームにいるQAエンジニアの成長機会をどう作るか？ってことが書かれています。

スキルアセスメントスプレッドシート

QA組織のメンバーが必要な知識、経験がどの程度あるかっていうのをスプレッドシートにまとめて行くとよさそうです。

JaSST東京チュートリアルの資料より引用

こう言うものを作り、自分たちQAチームの強み弱みを把握できるとよいです。シラバスには以下のように書いてあります。

スキルアセスメントスプレッドシートを作成する場合、テストマネージャは仕事で重要なスキルだけでなく、職位に適切なスキルもすべてリストする必要がある。それらのスキルの一覧を作成したら、得点システム（たとえば、5段階評価で5がその領域で期待するもっとも高い評価など）を使用してチームの各個人を評価できる。評価により、各個人の強みと弱みを確認し、その情報に基づいて個人またはグループのトレーニング計画を作成する。テストマネージャは、特定の領域のスキルを改善するために各人の能力目標を設定し、個人のスキルを評価するために使用する特定の基準を定義する。（JSTQB アドバンスレベル　テストマネージャーシラバス　P74）

以下のシラバスに書いてある項目でQAメンバーのスキルをスプレッドシートにまとめると良さそうです。（あくまでシラバスに書いてある例です。）

・テスト対象のシステム／サービスの利用経験
・テスト対象システムやサービスが使われるドメイン／ビジネスの知識
・開発プロセス（要求分析、アーキテクチャ、設計、コーディング）
・ソフトウェアテストのスキル
・テストマネジメントのスキル
・ソフトスキル（対人関係スキル）

トレーニングとスキル開発計画

スキルアセスメントスプレッドシートは、トレーニングおよびスキル開発計画のベースのデータになります。シラバスではここで把握したチームの効率と効果に最大の影響をおよぼす「弱み」に対処するところから始めるのがいいって書いてあります。対処する方法としては以下が書いてあります。

・外部のトレーニングコースを受講する
・社内でトレーニングセッションを開催する
・自己学習（本、オンラインセミナー、Webにある情報）
・クロストレーニング
　　- スキルを身につけたい人とそのスキルを持って仕事してる人と組ませる
　　- 身近にいるその専門領域が強い人に教えてもらう
・メンタリング
　　- 初めて役割を担う人をその役割の経験がある上級者と組ませる
　　- 上級者は、日々アドバイスや支援を提供する役割を務める

チームの力学（QAチームの作り方）

この節では、プロダクト／サービスのQAチームをできるだけ最善にするために必要なことが書かれています。QAエンジニアを採用する、また、プロダクトのテストにQAエンジニアをアサインするという場合、その人だけがQAとして必要なスキルを完全に全て兼ね備えてる必要はなく、メンバーそれぞれの強みを活かし、弱みを補う、つまりQA組織でこれらの知識、経験が相互に補完できるようにしていくと良いQA組織になるってことです。

QAチームを作った時のメンバーのバランスのことをチームの力学と呼ぶようです。以下のようなことで力学がわかりそうです。

・新しく参画するメンバーがチームのスキルを補完できるか？
・性格が合うかどうか？
・メンバー1人1人が自分の価値と必要性が認識できるか？

チームの力学が醸成されると、メンバーが勝手にクロストレーニングを非公式に行い、（お互いに助け合うことで）仕事量の平準化を自分たちで行うようになるものであり、そういうチームを目指すとよさそうです。

チームを作るにあたり、まずはそのチームのマネージャーになる人が必要ですが、こんなスキルがある人が良さそうです。

テストマネージャー（QAマネージャー）はこんな人がいい！

・プレッシャーの高い状況にうまく対処できる（ストレス溜め込まない）
・スケジュールや期待度の問題に対処する
・プレッシャーをチームメンバも同じように感じていることを理解する
・新しいチームメンバーに役割を与えることができる
・コミュニケーションと渉外スキル（論争の起こりそうな状況を和らげる）

そして、QAチームメンバーをアサインするのですが、以下のようなアセスメント項目で、チームの力学を考慮して決めるのがよさそうです。全部が完璧な人をアサインするわけではなく、今のQAチームの力学からどの項目に強い人が必要かを考慮して決めることが大事になりそうです。

テクニカルスキル（ハードスキル）のアセスメント項目

 • 要件ドキュメントからテストケースを抽出できる
 • テクニカルドキュメント（要件、コードなど）をレビューできる
 • レビューコメントを明確で分かりやすく、目的に沿った形式で記述できる
 • 特定のシナリオでさまざまなテスト技法を適用できる
 • バグチケットを、事実が正確にわかり、かつどう問題があるのか書ける
 • バグの分類、根本原因を周りが理解できるように示せる
• ツールを使用してAPIをテストできる
• SQLを使用してDBを検索および変更してテストできる
• 複数のテストを実行して、テスト結果を収集するツール使える
• 自動テストを実行し、エラーのトラブルシューティングができる
• テスト計画、テスト仕様を記述できる
• テストサマリレポートが記述できる 

 対人関係スキル（ソフトスキル）のアセスメント項目

• スケジュールが遅れているテストプロジェクトに関する情報を提示できる
• 欠陥がないと思っている開発者に欠陥レポートを説明できる
• 同僚をトレーニングできる
• 効果的でないプロセスに関して、問題をマネジメント層に提示できる
• 同僚のテストケースをレビューし、その同僚にコメントを提示できる
• 同僚からテストのやり方を教えてもらうことができる
• 開発者を称賛できる

組織内におけるテストの適合 （QAの独立度合い）

QAの独立度合いは、高くても低くてもメリットとデメリットがあるので、デメリットに対処することで、しっかりメリットを享受できるようにしないといけないです。

私の見解としては、大規模な開発は、統制の取れたQAチームが独立していたほうがよいと考えます。人数が多いときに統制が取れずバラバラになってしまうと収集不能になってしまうからです。ただし、QAチームの独立度合いが高くなるほどQAメンバーの中では開発の人の顔も知らないという人が増えてしまいます。開発全体から得られる情報のパスが少なくなってコミュニケーションの齟齬がでるのがデメリットです。

アジャイル開発のように少ない人数でチームを構成し、各自が自律して動いていくチームでは、QAメンバーが開発チームの一員となったほうがよいです。ただし、QAチームの独立性の度合いが低いほど、本来の目的からの乖離が生じる（つまり、開発者と同じ視点で見てしまうようになり、違う視点で見るとすぐわかるような問題に気付かなくなる）のがデメリットです。たとえば、アジャイル開発では、開発スピードに合わせてテストもスピードを速くして行うため、目的に合う部分だけに特化してテストする場合が出てきます。意図的に省略してるテスト内容がある場合、そこでテスト漏れが起きる可能性があるので、省略箇所を意識できるように、テストする内容をマネジメントしないと、テストし忘れてリリースしてしまったということになりかねません。

モチベーション（QAメンバーのやる気アップ）

メンバーのモチベーションを上げる要因について、シラバスに書いてあるのはこんな感じです。

・達成した仕事に対する評価
 • マネジメント層から認められる
 • プロジェクトチーム内および同僚からの敬意
• 責任と自己裁量を増やす
 • 成し遂げた仕事に対する適切な報酬（給与、責任や評価の増加を含む）

とにかくメンバーが「やる気が失せるー」っていうような気持ちにならないようにするのが大事なので、どんなことがあるとやる気が失せるか理解して、そうならないようにするのがQAチーム運営で大事になりそうです。

どんなことが起きるとやる気が失せるのか、シラバスに書いてあるのは以下になります。

・一生懸命テストしてるのに、それを無視してリリースしてしまう

QAのメンバーが「良い品質のものをお客さんに使って欲しい」という気持ちでテストしてるときに、（まだテストしてる最中なのに）「QAはちょっと時間かかるからとりあえずリリースしちゃいました」ってリリースされちゃったら、テスト実行しているQAメンバーは物凄くやる気失せますね。

このためには、最初にプロダクトのリスクについてチームとして意識合わせをするのが大事です。テストしているQAメンバーも納得していれば問題にはなりません。エンジニアやプロダクトマネージャーもリスクがあり不安であればテストが終わるまで待つってことができます。早くリリースすることでお客さんに喜んでもらうのも品質であり、そのバランスを合意することがやる気にも大きく左右します。

・テストしたことに対する正当な評価が得られない

QAチームが必要であることが認められていない開発組織では、テストしてバグが見つからなかったら、「結局バグがでないから、テストをやってもやらなくても一緒じゃないの？」というようなことを周りが言い出す可能性があります。バグを見つけてたとしても、よっぽどインパクトがない限り「結局QAって何のテストしてくれてたんだっけ？」って思われてしまう場合もあります。

このためには、テストを実行していることを周りに共有してわかってもらうことが大事です。そして、テスト実行した範囲が増えていくほどリスクが軽減していることを伝える、もしくはリリース後に「あそこはどうだったけ？」ってみんなが忘れてしまってる時に「その範囲はQAがテストしたときはどうった」というファクトを素早く伝えられるようにしておくことで、「QA大事だなー」と思ってもらえると思います。まぁ、信頼は1日でできるものではないので、地道な積み重ねが必要です。

・QAがプロジェクトの価値向上に貢献できる機会がない

「QAって大事だなー」って思ってもらえる機会っていうのもすぐにできるものではないです。例えば、ユーザーストーリーマッピングをするような機会を小耳に挟んだら「QAも参加していいですか！」と言って自ら積極的に関与していく姿勢が必要です。参加したら、過去のテストしたときに得た知識と経験で品質面での意見を言う勇気が必要です。QAメンバーには意見を言えるまで知識と経験が無い場合は無理して意見を言う必要はないですが、その場には参加し、メモを取る係を率先するなどして役に立つようにして、さらにそこでの話を理解しておいて、設計に入った段階や実装に入った段階、テストに入った段階で齟齬が起きてないかと言う観点で意見を言うようにすれば良いわけです。QAの人たちが早い段階での指摘と求められている品質の程度を理解していくことで、最後にテストしてからバグチケットとして問題を報告する量を減らすことにつなげられます。早い段階で問題のタネを潰していき、リリース直前の段階でテストを始めてからのバグチケットをどれだけ減らすことができたかがプロジェクトの価値向上に貢献していることになるので、それを（ウザくない程度に）アピールすることも大事です。

コミュニケーション（QAが周りに伝えるべきこと）

QAって仕事は、「もうリリースしても安心だよね」って周りに思ってもらえるために、安心情報をいろいろな方法で提供をするのが一番大事な仕事です。実質的にはテストをしてる時間が一番長いかもしれませんが、それは「安心だ！」って言えるファクトを集めることが目的であり、その目的に沿ってこそ価値が出ます。

QAチームがコミュニケーションする場合、以下の３つに関することがコミュニケーションすべきことになります。

・QAからのアウトプット：テスト計画やテストケースや欠陥レポートなど
・開発のアウトプットのフィードバック：仕様書に対する疑問質問など
・情報収集と情報拡散：日程の確認やデプロイの有無といったこと

QAの仕事をするという意味において、周りの人たちとコミュニケーションをすることが、結果的に「プロダクト」および「ソフトウェアシステム開発に使用するプロセス」の両方の品質向上につながるようになってるか？って考えてコミュニケーションの内容をいいものに成長させていくことが必要だと思います。

コミュニケーションする相手は以下の４方向あります。

・外向きコミュニケーション：チームメンバーでないステークホルダー
・内向きコミュニケーション：チームメンバー
・上向きコミュニケーション：上層部や部門長
・下向きコミュニケーション：部下

方向が別でも相手にとって適切なコミュニケーションを行い、メッセージを効果的に発信し、理解してもらえてることを確認するのは共通して必要であり、そのために各方向で知りたいこと、その人たちの知っているベースの情報を理解して、その前提に合わせてわかりやすく伝えるのが大事です。

このシラバスでは最後に一言こう書かれています。

テストマネージャーにとって、品質を推進する組織を表す専門的な品質のドキュメントを作成することが重要である。
（JSTQB アドバンスレベル　テストマネージャーシラバス　P79）

このシラバスは「テストマネージャーシラバス」ですが、こういうドキュメントを作るっていうのは、もうQAとしての活動になってますね。

テスト結果やリスクの軽減度合い、バグの発生傾向、バグの原因分析なんかで説明することになると思います。開発の情報とバグの相関とっていくっていうのもできるとさらにいいかもしれないです。例えば、複雑度などのコードメトリクス、行数、デプロイの回数などですね。そう言うデータと相関をとるようにしていくってなると統計の知識も必要になります。

品質を推進する組織としてのドキュメントも1回作ればいいわけではなく、地道な積み重ねが必要であり、わかりやすく必要な情報が伝えられるようにフィードバックサイクルを回していくのが必要になるかと思います。

以上