この連載では、1人目QAとしてのチームの立ち上げ、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。
前回の記事ではQA組織立ち上げの流れや組織の形について解説しました。
今回は2人目以降のQAエンジニアを採用する際に私が考えたポイント等についてご紹介します。
私が所属している部署ではQAエンジニアの採用を行っており、現在は2名体制で動いています。現時点では「10名、20名とどんどん拡大！」という状態ではないため、すでに大きな体制を構築している会社さんとはフェーズが異なるという前提でお読みください。現職のQA組織は小規模ですが、前職で採用含めてチームを作った経験もあるため、そこで得た知見とあわせてお伝えします。
これから2人目以降のQAを採用しようとしている会社さんや採用に関わっている1人目QAの方にとって、何かヒントになれば幸いです。
2人目の採用にあたって考えたこと
私は今の会社に入るにあたり、「QAチームを作るところもやってほしい」と言われていました。開発組織の規模を考えても、また部署で唯一のQAである自分が病気等で離脱する可能性などを考えても、チーム化するというのは自然な流れだったと思います。
そのため、入社直後から2人目のQAエンジニアの採用活動もスタートしたわけですが、採用にあたってはただ求人を出せばいいわけではありません。
- 現状の開発組織において、どのような形で品質保証をしていきたいのか
- そのためにはどのような体制にしたいのか
- どのようなスキル・経験を求めるのか
などを整理し、それに応じた募集文面や媒体の選定などが必要です。
現状の開発組織での品質保証の形や体制などは、組織のこと・開発プロセスのことを把握していない段階で決めることは困難です。この時点ではあくまでも方向性程度で問題ありません。社内には「QAを採用したい！」と思った主な人物（開発部長やCTOなど）がいるはずなので、その方と相談をしつつ、ある程度「こうあるべきではないか」という仮説を設定する、くらいのニュアンスです。
そして前回の記事に書いたようなヒントをたよりに、体制や開発チームとの関わり方を決めていきます。このとき、いきなり理想の体制にはならないことにも注意が必要です。
たとえば開発チームが複数ある組織で、かつ理想として「各開発チームに担当のQAが1人ずつ付く形にしたい」と考えたとします。開発チームが5つあったとしたら、いきなりQAを5人採用するのは難しいですよね。
この場合、最初は開発チームの外から支援するタイプのQA組織として立ち上げて、QAエンジニアの採用が進んだら担当制に変えよう、といった中長期的なプランを描くことになります。
QAエンジニアのタイプについて考える
2人目以降のQAエンジニアとしてどのような人を採用する際にもう一つ、私はよく「QAエンジニアのタイプ」で考えます。
ここで言うタイプ、というのは特定の定義を指しているわけではありません。QAエンジニアの分類の仕方を総称して、タイプ、と表現しています。
たとえば、過去の連載でも何度か触れた「QMファンネル」で言うところのスペシャリティもタイプといえるでしょう。QMファンネルとは、テストエンジニアとSETとQAを整理してバランスをよくするためのものです。
- テストに強みがあるのか
- 自動テストや開発スキルに強みがあるのか
- スクラムマスターやマネージャーなどの方面から組織にアプローチするのが得意なのか
など、その人の得意分野で分けるというのが一つの方法です。
他に、私が個人的に使っているタイプとして、志向で分けるというものがあります。
QAエンジニアは、大きく以下2つの志向性があるのではないかと考えています。
①組織・プロセス志向
②プロダクト志向
もちろんこれはあくまでも一例なので、ご自身で考えていただいても大丈夫です。
このタイプわけを使って、2人目およびそれ以降のQAエンジニア採用を考えます。
作戦：同じタイプで攻める
1人目のQAと同じタイプを2人目として採用する作戦です。大まかに以下のような特徴があります。
- メリット
- 二人のタイプや志向性がそろうので意見が一致しやすく、物事が進みやすい
- 詳しい人同士での議論や意見交換ができる
- デメリット
- 対応できる業務や課題の範囲が狭くなる
続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。
