この連載では、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人目として採用する作戦です。大まかに以下のような特徴があります。
- メリット
- 二人のタイプや志向性がそろうので意見が一致しやすく、物事が進みやすい
- 詳しい人同士での議論や意見交換ができる
- デメリット
- 対応できる業務や課題の範囲が狭くなる
たとえば、QMファンネルのPE：パイプラインエンジニアとしてのスペシャリティを持った人が1人目のQAをしている組織に、同じPE方面が得意な2人目が加わった、とします。この場合は、自動テストやそのインフラ整備はスムーズに進むでしょう。しかし、もしかすると開発プロセスやテストプロセスの改善、利用時品質の向上などの施策は進みづらいかもしれません。中には複数のスペシャリティを持ったスーパーQAエンジニアもいますが、そのような方が採用できるのはレアケースでしょう。
解決したい課題が明確な場合は、この同タイプ作戦で課題に特化したスキルを持つQAに絞って採用するのも一つの手です。
作戦：別タイプで攻める
上記とは反対に、1人目QAとは異なるタイプを2人目として採用する作戦もあります。個人的にはこちらのほうが一般的だと感じています。
- メリット
- 得意分野が異なるので、組織の幅広い課題に対応できる
- デメリット
- それぞれのスキルによっては、相互に相談がしづらい
- 個々の施策においてはスピード感が出づらい
1人目QA、私も1年半ほど続けてみて感じたのですが、「相談・議論相手がほしいなぁ」と思うことが多々あります。先の例で言えば、PE同士であれば自動テストの高度な話を議論できるかもしれません。しかしタイプが異なるとそれぞれ詳しい範囲も違うので、会話にはなれども、議論のレベルに至らない場合もあります。
このように、とくに2人目のQAを採用していよいよチーム・組織化を、という場合にはタイプを考えて検討をすることが大切です。
現実問題：採用できた人の活かし方を考える
タイプで考えましょうと言っておきながら覆すようですが、「採用できた人の活かし方を考える」ほうが現実的な場合も多いでしょう。
今はQAエンジニアの採用、とくにチームの立ち上げに関われるようなリーダー・マネージャクラスの採用は難しいと言われています。そのため、「タイプが違うから見送り」としてしまうのはもったいない場面もあります。
募集要項自体はある程度幅を持たせて出したうえで、採用候補者のスキルや特徴を活かす方向で業務内容を調整するのが現実的です。面接で候補者の方から「どのような人を求めていますか？」と聞かれることもありますが、主体的に動けることや整っていない道を進める人というポイント以外、スキルやスペシャリティに関しては「お持ちのスキルを活かせる業務を一緒に考えましょう」とお答えしています。
2人目の先で考慮する点
前述の通り、私は現在2名体制のチームにいます。ただ、前職などでチームを立ち上げた際には3人目、4人目と拡大していった経験があり、この段階で大事だと感じたポイントがありました。
それは 「物申せる人」をチームに加える ということです。
リーダーになってメンバーを募るときのリスク
1人目QAとして、ある程度経験のある人を採用できた、とします。そしてその後、たとえば1人目に比べると経験が浅い若手メンバーが2人目3人目とJoinして・・・という形でチームができあがっていくこともあるでしょう。
このようなシチュエーションでは、誰のせいでもなく、メンバーがイエスマンになってしまう可能性があります。
当然ながら、1人目のQAが最も社歴が長く、内部の情報という点では一番多く持っています。これに加えて、QAとしても経験も豊富となると、1人目が全部一番詳しい状態のはずです。そうなると、2人目以降で入ったメンバーとしては「1人目の＊＊さんが言っているんだから間違いないだろう」という、良く言えば信頼、悪いく言えば無意識の甘えが出てきます。
1人目QAの意見が全部通ったり、必要以上に発言に重みが出てしまったりすると、チームとして間違った方向に進んでしまう可能性があります。繰り返しになりますが、誰にも悪意がなくともそうなる危険があります。
また、1人目QAの側もすべてを知っているわけではありません。いろいろな取り組みをする中で、「これでいいのだろうか」や「誰かに相談したい」と思うこともあります。そのようなときに、メンバーが「＊＊さんが言うならそれで！」という態度を取り続けてしまうと、1人目QAにとってはチームで仕事をしているのに孤独を感じる状況になることも。
これらの問題を防ぐために必要なのが、「物申せる人」です。
もちろん、なんでもかんでも反対するのはダメです。しかし、1人目QAとして組織を立ち上げている人に対してでも「そこは違うと思う」「もっとこうしたほうがいいと思う」といった意見を言える人、対等に意見を言い合える人が必要です。
物申せる人にもいくつかありますが、
- 1人目QAと同じくらいのキャリア・経験がある方
- 経験は浅いが、（相手を尊重したうえで）意見が言える人
など、どのようなパターンでもよいでしょう。
個人的感覚では、4, 5名のチームになったころにはこうした「物申せる人」を入れたくなります。
まとめ：志向性などQAのタイプでほしい人材や組織の形を描きましょう
今回は2人目とそれ以降のQAエンジニアを採用する際に考えるポイントについて、いくつかご紹介しました。
ここで挙げたものがすべてではありません。しかし、QAエンジニアの職務の幅が広がっている今、単純に「QA募集」ではミスマッチが起こりやすいように感じています。
QAチームを構成するメンバーのスキルや志向性などをどの程度そろえて、もしくはバランスよく分けていくのか等を考えることで、求める人材が具体化できたり、採用のミスマッチが減らせたりといった効果が期待できます。
QAエンジニアの採用をされる場合は、ぜひ参考にしてみてください。
