本連載では、ここまで主に「1人目のQAがやるべきこと」について、経験ベースでお伝えしてきました。
今回は少し視点を変えて、1人目のQAがやるべきではないこと、アンチパターンについてご紹介したいと思います。
やるべきことは組織の状況などによって変化することもありますが、アンチパターンは状況によらずある程度共通する部分がある、と考えているためです。
本記事では、代表的なアンチパターンを4つ説明します。
＜1人目QAとしての立ち回り 連載一覧＞※クリックで開きます
【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方
【第2回】組織に品質保証を浸透させるアプローチ
【第3回】品質保証やQAエンジニアを知ってもらうための取り組み
【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。
【第5回】1人目QAアンチパターン
目の前のタスクに集中しすぎる
一つは、目の前のタスク、「すぐに実施できて達成感が得られそうなタスク」に集中しすぎてしまうことです。
とくに組織にJoinした直後のQAは、できる仕事がたくさんある状態だと思います。
そこで【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqriptsでご紹介したように組織の現状把握をしつつタスクの取捨選択を行うわけですが、このときに個々のタスク、とくに達成感・「仕事をした感」が得やすいタスクを選び取りがちです。
たとえばリリース後に見つかる不具合が多い開発チームに入っていき、テスト設計・実行やリリース前の探索的テストに注力したとします。もちろんこれ自体は良いことです。しかし、そこでバグを見つけたり開発チームに感謝されたりしながら、1か月2か月と過ごしていったとして、それは1人目QAとしてのミッションに沿っているのでしょうか？
会社として、問題のあるチームに入って立て直してほしいという狙いがあれば、動き方としては良さそうです。しかし、広く会社全体の品質保証のやり方を考えてほしい、といった狙いがある場合はどうでしょうか。
目の前のタスクを行って一定の成果が出ることは良いのですが、ついそこにハマってしまう危険もあります。1人目QAとして期待される動きや成果を考慮したうえで、場合によっては広く組織全体にアプローチするようなやり方が必要かもしれません。
得意なやり方、実績あるやり方に頼りすぎる
なんらかの課題に対して、自分の得意なやり方や実績あるやり方を当てはめてしまうというのもよく目にするアンチパターンです。
テスト技術に自信がある、テストプロセスの整備の経験が豊富など、QAエンジニアそれぞれにはなんらかの得意なジャンルや手法があるかと思います。
そして、とくに入社直後のQAの場合は目に見える成果が欲しくなるため、つい自分の得意技で攻めようとしてしまいがちです。しかし、たとえばシステムテストの自動化が得意だからといって、なんでもかんでも自動化によって解決できるわけではありません。
必ずしも得意ではなかったとしても、今自分のいる組織にとって何が必要なのかを見定めるところからスタートするのが良いでしょう。結果として、やるべきことに対して自分のスキルが不足している場合には、社外の有識者を頼ることも一つの選択肢ですし、エンジニア部門のマネージャー等と協力しながら「経験はないけれどもチャレンジしてみる」こともできるかもしれません。
周囲のスムーズな理解を期待してしまう
1人目のQAと周囲の開発者やマネージャーとの間には、物事の見方・捉え方や知識の幅などに多くの違いがあります。とくに1人目として入社した直後のQAと、長く勤めているメンバーとではこの違いが顕著になるでしょう。
QAに限らず、そのロールの1人目として働く場合は「自分がどのような役割なのか」を周囲に理解してもらう必要があります。たとえば、1人目QAの方から「QA＝テストしてくれる人、という認識を持たれがち」といった話も伺います。これが誤解である場合、組織におけるQAの位置づけをもっと違ったものとして考えている場合は、適切に伝えていかなければなりません。
ところが、周囲の理解は簡単に得られるものではありません。QAとしての活動をわざわざ邪魔してくる人はいないかもしれませんが、誤解や無知（にQA側からは見える状態）などは必ず発生します。
そのため、開発者やマネージャーはQAのことを知っているはず、一度説明すれば理解してもらえるはず、といった「周囲のスムーズな理解」を期待するのは危険です。
QAの役割や関わり方など、なんらかの情報を組織の中に広めていくということは、思った以上に時間がかかることです。「簡単にはわかってもらえない」「伝わったと思っても伝わっていないことが多い」という前提を持ちつつ、しつこいくらいに伝え続ける動き方が1人目QAには求められます。
独力でなんとかしようとしてしまう
QAかどうか、1人目かどうかに関わらず仕事全般に通じるアンチパターンですが、とくに1人目QAの方はハマりがちな傾向にあるように思います。
組織1人目のロールの場合、相談できる相手が居ないか、限られることが多いです。
かつ、1人目QA自身も「プロとして呼ばれてきたわけだから、相談しづらいな・・・」と感じてしまうのかもしれません。
いろいろな組織課題を独力で解決しようと考えても、多くの場合解決できないか、時間がかかりすぎてしまいます。それでは組織にとってもメリットがありません。
私自身1人目QAとして働いて感じたことは、品質への興味を持った方は少なくない、という点です。開発者の中にもテストをうまく・効率的に行いたいと考えている方はいますし、マネージャーの中にも品質向上のために試行錯誤した経験のある方が必ずいます。
そうした方々の取り組みや課題を拾い上げて一緒に解決していくことも、1人目のQAとしての価値です。「自分がなんとかする」という責任感もすばらしいですが、いったん脇に置いて「積極的に周りを巻き込んで一緒になんとかする」という考え方に変えてみるのもよいでしょう。
また、社内に相談相手がいない場合は社外を頼るという方法もあります。
昨今は（私も含めて）カジュアル面談プラットフォームなどを用いて「他社QAと情報交換しましょう！」という場を設けている方もたくさんいます。もちろん社内の情報の扱いには注意が必要ですが、純粋な技術課題・組織運営課題として抽象化したうえで社外の方と話をしてみる、経験談を聞いてみるのも有効です。
1対1の会話でなくとも、社外の勉強会やイベント等に参加して他社事例を聞くことも有効です。勉強会などで「今の自分が抱えている問題にピッタリはまるヒントは得られなかった」という方もいますが、私はそのような都合のよい機会はほぼないと考えています。
そうではなく、普段から勉強会やイベント等に参加をして情報を集めておき、いざ自分がなんらかの課題に直面したときに過去見聞きした情報からヒントを得るものです。
書籍や、Web上に公開されている資料なども含めた意味での「他人の知恵を借りる」ことは常に意識しておきたいですね。
1人だからとタスクや情報を抱え込まないのがポイント
今回は代表的な4つのアンチパターンをご紹介しました。
共通する点としては、1人だからといってタスクや情報を抱え込まないようにすべき、という点です。
1人目のQAは周囲から謎の存在になったり、あるいは「テストしてくれる人」のような固定イメージで見られたりすることがあります。そうならないためにも、自分がどのような役割を担いたいのかや何ができるのか、いま何をしているのかなどを常に発信していきましょう。
連載一覧
【第1回】1人目QAの位置づけと、開発組織へのアプローチの仕方
【第2回】組織に品質保証を浸透させるアプローチ
【第3回】品質保証やQAエンジニアを知ってもらうための取り組み
【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。
【第5回】1人目QAアンチパターン
【Sqripts編集部より】
伊藤由貴さんの連載記事『1人目QAとしての立ち回り -品質保証を浸透させるアプローチと工夫-』はいかがでしたでしょうか。
読者のみなさまからの感想や今後の連載のリクエストをぜひお寄せください！
Sqriptsお問い合わせ、または公式XアカウントのDMでも受け付けています。
