DevOps時代のテストエンジニア採用面接
背景
社内外のテスト自動化チームの人たちと話すと、テスト自動化エンジニアの採用は難しいという話題がよく出る。どこのチームもテスト設計が出来て、自動化も得意で、CI周りの構築もやって、といったパーフェクトなテスト自動化エンジニアを求めているが、実際には採用はなかなか進んでいないようだ。
このブログポストでは、このテスト自動化エンジニアの採用にまつわる問題を「候補者の得意領域、不得意領域の話を引き出す面接を意識すること」を軸に少し一般化し、僕自身が気をつけていることについて書く。
テスト自動化エンジニアの採用が大変な理由
多岐に渡るテスト自動化のスキルセット
テスト自動化エンジニアの採用が大変な理由は、一言で言えば、DevOpsが当たり前の昨今では、多岐に渡るスキルセットを評価する必要があることだ。
例えば、ソフトウェアテストの資格試験であるISTQBでは、ソフトウェアテストの「Core」のスキルとしてテストマネージメント、テストプロセス、テスト技法、ソフトウェア品質特性などを挙げられている。また、「Specialist」のパスとしてアジャイルテストやテスト自動化エンジニアが示されている。
これらに加え、XPやTDD、継続的デリバリーなどにみるアジャイルでのテスト自動化への考え方、Jenkinsなどのパイプライン自動化、DockerやKubernetesなどのインフラ自動化なども周辺技術としてある。
採用面接におけるありがちな罠
はっきり言ってしまえば、これらの多岐に渡るスキルや知識を評価することは想像以上に難しい。候補者の得意・不得意なスキル領域について客観的な評価ができなかったり、うまく話が引き出せない可能性があるからだ。下記に採用面接における例を示す。
この例での面接官のAさんのスキルをみてみる。スキル領域①〜⑤を通して特に苦手な領域もなく、特にスキル領域①で高いレベルを持っている。
候補者のBさんとCさんのスキルセットをみてみる。BさんはAさんと同様のスキル領域①が得意だ。一方で、Cさんはスキル領域①は苦手だが、スキル領域③と⑤で高いレベルを持っている。
この例の場合、Bさんの方がCさんに比べ評価されやすいと僕は考えている。認知バイアスがかかるため、Aさんは自分自身が高いレベルをもつスキル領域①を重視して評価しやすいからだ。人間は自分が努力をして手に入れたものに対して、より多くの価値を見出す傾向がある。そのため、自分自身の得意な領域と不得意な領域について、客観的な目で評価するのは難しい。
また、面接官は自分が得意な領域について、より多く、深く質問してしまいがちだ。プログラミングについて詳しい面接官は、ついついプログラミングについての質問をしてしまう。しかし、面接は面接官の得意な領域について質問する場ではなく、候補者に得意な領域、不得意な領域について話してもらう場だ。候補者から得意、不得意な領域な話を引き出せるように面接を組み立てる必要がある。
テスト自動化エンジニアの採用で気をつけていること
スキル領域を定義する
異なるスキル領域について客観的に評価するためには、事前にテスト自動化エンジニアに求めるスキル領域とスキルレベルを定義することが必要だ。例えば、僕個人は
- テスト要求分析スキル（機能要求、品質要求含む）
- テスト設計およびテスト優先順位づけスキル（テスト設計、リスクベーステストなど）
- プログラミングスキル（構造体、アルゴリズム、エラーハンドリングなど）
- 自動テストの設計スキル（Keyword Driven Tesing, Data Driven Tesing, PageObject Patternなど）
- 問題解決スキル（自動テストの保守性、Flakyテストなどの問題をどのように解決するか？）
をテスト自動化エンジニアに必要なスキル領域として定義している。事前にスキル領域を定義することで、質問や評価が特定の領域に偏るリスクを軽減できる。
また、それぞれのスキル領域の得意なチームメンバーと、質問や回答についてのレベル感について合意しておくことも重要だ。前述のように、スキルAが得意なメンバーとスキルBが得意なメンバーでは、スキルAが得意な候補者の評価が割れやすい。事前にメンバー間でレベル感について議論しておくと、スムーズに結論を導き出せる。
面接の冒頭にチームを紹介
候補者から、得意・不得意なスキル領域の話を引き出すためには、面接の冒頭でチームを紹介することも重要だ。募集しているポジションのチームがどんなチームで、どんなスキル領域が得意なテスト自動化エンジニアに来て欲しいかを丁寧に伝える。すると、候補者は面接の質問に対し、自分のスキルセットや今までの経験について的確にアピールできるようになる。
例えば、「開発者しかいないチームでテスト専門スキルの高いエンジニアにチームに来て欲しい」場合、それを伝えれば候補者は今までの経験の中でも、特にテスト要求分析やテスト設計の経験についてアピールしやすくなる。
単純にテスト自動化エンジニアのポジションと言っても、そのチームは様々だ。開発エンジニアとテストエンジニアが一緒のチームもあるだろうし、独立したテストエンジニアのチームもあるだろう。Scrumでバリバリやってるというチームもあれば、ウォーターフォールでやっているチームもある。また、もう既に何十万件のテストケースを自動化したチームもあれば、これからテスト自動化を始めるチームもある。
自分たちのチームがどんなチームで、どんなエンジニアにチームに来て欲しいかを伝えることで、候補者もそのチームに対しよりポイントをついた話をすることができるようになる。
候補者の得意なスキル領域を引き出すオープンクエスチョン
候補者の得意なスキル領域の話を引き出すため「あなたの得意なスキル領域はどこですか？」とダイレクトに質問する方法もあるが、一般的なオープンクエスチョンから候補者の得意なスキル領域へ質問をシフトしていくのもオススメの方法だ。
例えば、僕はしばしば「あなたが今まで経験したバグの中で一番大変だったものを教えてください」というオープンクエスチョンをする。この質問の面白いところは、「一番大変」と感じる領域が候補者によって完全に異なることだ。そして、この質問の回答に候補者があげる領域は、本人が自信のある領域である場合が多い。
バグを発見した苦労話を聞かせてくれるエンジニアは、テスト技法について自信があるだろう。バグの根本原因を特定した苦労話を聞かせてくれるエンジニアは、インフラが得意だったりする。バグ修正の苦労話を聞かせてくれるエンジニアはプログラミングに自信があったりする。
エンジニアは大体みんなバグで苦労をした経験がある。そのバグに対して「大変」と感じる視点の違いを、一般的なオープンクエスチョンから引き出すことができる。
スキルレベルを判断するための質問
候補者から得意・不得意な話を引き出した後には、それぞれのスキル領域についてのスキルレベルなのかを判断する必要がある。
- 得意なスキル領域は実務で活用できるレベルなのか？
- 不得意なスキル領域も、ある程度の知識はあるのか？
「知っている」ことと「出来る」ことには大きな差があるため、この違いを見極める必要がある。
僕がしばしば面接で実施するのは、異常系がごっそり抜け落ちている仕様に対してプログラムを書いてもらい、続けてそのプログラムのテストを実施してもらうというものだ。本来の目的は「異常系の仕様の抜け漏れを見つけてもらう」ことなのだが、そのことは候補者には隠した上で、２〜３行の正常系の仕様に対しプログラミングとテストを実施してもらう。
プログラミング自体はシンプルなので５分程度で終わる。しかし、テスト駆動開発やエラーハンドリングなどのテクニックを使いこなすエンジニアは、ここで異常系の仕様がごっそり抜け落ちていることに気付く。また、テストの実施の最中に、境界値分析などを用いてテスト設計をすることで仕様の抜けもれに気付くケースもある。
この問題は、こちらから特にスキル領域やテクニックの指定はしないので、候補者が普段どんなスキルを使いこなして業務を遂行しているのかを知るのに役立つ。特に、テスト駆動開発や境界値分析など名前くらいは知っているというエンジニアも多いが、そういうレベルではこの問題の仕様の抜け漏れを発見することはできない。
稀にプログラムを書く前段階ですべての異常系の仕様の抜け漏れに気付くエンジニアもいる。そういうエンジニアは数百人に一人にしかいないので貴重な存在だ。
まとめ
テスト自動化エンジニアの採用戦略について「候補者の得意領域、不得意領域を引き出すこと」を軸にみてきた。テスト自動化エンジニアのポジションに必要とされるスキル領域は多いため、優秀なエンジニアの採用はなかなか大変だ。しかし、チームと候補者のスキル領域がうまくマッチすると、劇的にチームが改善される可能性のある重要なポジションだ。
