10XのSETへ応募する人に求めたい2つのスキル

こんにちは。品質管理部のブロッコリーです。

現在、品質管理部ではQA(Quality Assurance, 品質保証)エンジニア、テストエンジニア、シニアテストエンジニア、SET(Software Engineer in Test)の募集をしています。

この中で、10Xが目指している品質管理部全体の姿については、以前に記事にしています。(記事公開当時は「品質管理部」ではなく「QAチーム」と表現しています)

product.10x.co.jp

品質管理部全体については示したものの、SET職種について明確に何を求めているのか示すことができていませんでした。そのため、SETで応募しようか悩んでいる方にも分かりづらい形になっていたと思います。

そこで10XにおいてSETに求めることを言語化したので、本記事ではそれを紹介していきます。

本記事で言いたいことを3行で

  • ただ単にテストコードを書くことではなく、有効な手段を判断できる人を求めています
  • 実際のコードに対してアプローチできる人を求めています
  • 入社した際には「1人で頑張って」ということはなく、私やtarappoさんを初めとした品質管理部のメンバーと一緒に進めていきます

目次

SET職種に求めること

現時点で、SETに求めることは以下の2点です。

  1. 必要なテストに対して有効な手段を判断できる
  2. 自担当の開発チームのプロダクトコードに対して、テスタビリティに関わるフィードバックができる

求めること1. 必要なテストに対して有効な手段を判断できる

「◯◯の部分の自動テストを作ってよ」

こんなことを言われたら、どのように対処するでしょうか?

ある人は、Unitレベルの自動テストを書くかもしれません。

別の人は、E2E(エンドツーエンド)の自動テストを書くかもしれません。

10XにおけるSETとしては、「言われた部分に対して自分の知っている手段で自動テストを書き始める」という人を求めていません。

SET職種における、求めていない人物像

具体的には、以下の2つの工夫を用いて、有効な手段を判断してもらいたいと考えています。

工夫1. 適切なテストレベルを判断できる

「言われた部分に対して、まずどのような自動テストを書くべきか考える」「自動テストの実装の依頼を受ける前に(新規機能の機能設計を考え始めた段階で)、どのような自動テストで品質保証を目指すか考える」ということを大切にしています。

E2E、API、Unitのそれぞれで行うべき目的は異なるはずです。もしかしたら、手動テストで対応するのが適切かもしれませんし、実はテストが不要な可能性もあります。

このような判断をする前提として、それぞれの手段の得意なところが何か押さえておくことが重要です。

工夫2. テスト設計を用いて、実装すべきテストを削減できる

「自動テストを作ってほしい」と言われたものをただ実装するだけだと、テストケース数が膨れ上がってしまい、自動テストのメンテナンスコストが指数関数的に増えていってしまいます。

そこで、適切にテスト設計を行なって、実装するテストケースを減らす努力も必要だと考えています。

自動テストの作成というのは、テストプロセスでいうテスト実装の自動化に過ぎません。そのため、SETであっても、テスト設計の考えを持ってほしいと考えています。ただし、SETよりもテストエンジニアの方が得意な分野ではあるので、具体的にテスト設計をする時には、テストエンジニアの力も借りて進めてほしいと思います。

参考:ISTQBテスト技術者資格制度 Foundation Level シラバス 日本語版 Version 2018V3.1.J02

以上のことを踏まえて「必要なテストに対して有効な手段を判断できる」人を10Xでは求めています。

「E2Eのテストを実装できる」といったことは大切なことだと理解しています。その上で、自動テストでの実現を考える時に手段の1つとして選択肢に置き、場面に応じて活用できる人を探しています。

求めること2. 自担当の開発チームのプロダクトコードに対して、テスタビリティに関わるフィードバックができる

以前に公開した記事のように、品質管理部では、Shift leftでの品質保証を目指しています。

10x.co.jp

一方、「1. 必要なテストに対して有効な手段を判断できる」はまだまだ後工程であることが多いです*1

品質管理部が求めているのは自動テストを実装する段階で入り込むだけではありません。プロダクトコードがテスタビリティのあるコードになっているのかなど、自動テストのコードのインプットとなるコードの内部品質を高める活動も求めています。

この活動を行うことによって、プロダクトコードがよりシンプルになり、そもそも沢山のパターンのテストコードを書く必要が無くなるかもしれない未来を目指しています。

SETに求めている範囲

10XにおけるSETとしては、以上のようなこともできる人を求めています。

なお、SET職種においては10Xにおける4等級〜5等級相当を想定しています。それぞれの等級によって、求める広さが違います。

4等級の場合、「担当領域やプロジェクトにおけるイシューをリードできる人材」を期待しています。5等級の場合、「Stailer全体でのイシューをリードできる人材」を期待しています。

参考:株式会社10X - Culture Deck

例えば、テスタビリティに関わるスコープを考えてみます。

4等級の場合、テスタビリティに関わるフィードバックのスコープは、「自担当の開発チームのプロダクトコードに対して」と考えています。

5等級の場合、全社でのアーキテクチャ部分まで踏み込んで、テスタビリティを踏まえたアーキテクチャを提案できる人を求めています。

現時点のSET職種では必須でないこと

以下の内容は、SET職種として必要なことだと認めつつも、現状の10XのSETとしては必須としていません。

  • セキュリティについての深い知見
  • CI/CD周りの深い知見
  • テストフレームワークの構築

なお、必須にしていないだけであって、このような部分は取り組んでいきたいと考えています。

「SETで求めること」=「品質管理部の共有スキル」+「SET職種として必要なスキル」

SET職種が品質管理部というチームのメンバーである以上、

  • 品質管理部の共有スキルとして持ってもらいたい部分
  • SET職種の必要スキルとして持ってもらいたい部分

という2つの軸があります。

先ほどまで書いた「SET職種に求めること」に当てはめると、

  • 品質管理部の共有スキルとして持ってもらいたい部分
    • 求めること1. 必要なテストに対して有効な手段を判断できる
  • SET職種の必要スキルとして持ってもらいたい部分
    • 求めること2. 自担当の開発チームのプロダクトコードに対して、テスタビリティに関わるフィードバックができる

と対応づけられると考えています。

「E2E、API、Unitのどの自動テストで行うべきか判断できる」というのは一見すると、SET職種の必要スキルのように見えるかもしれません。

しかし、自動テストに限らずに、「どのテストレベルで行うべきか判断できる」という内容は、品質管理部の共有スキルとして持つべきだと考えています。

まだ本記事のように「QAに求めること」や「テストエンジニアに求めること」といった記事をまだ公開できてはいませんが、「どのテストレベルで行うべきか判断できる」というのは、品質管理部の共有スキルとして求めていきたいです。

10Xで得られる体験

ここまでで、SETに求めることを書いてきました。このような人が入社してくださった際に、どのようなことができるのかも記載しておきます。

  • 得られる体験1. 開発チームの一員として、実際のコードと向き合って業務を行うことができる
  • 得られる体験2. 私やtarappoさんと一緒にテストに対して追求できる

得られる体験1. 開発チームの一員として、実際のコードと向き合って業務を行うことができる

E2EであってもUnitであっても実際のコードに向き合って仕事を行うことができます。

現場で行った事例は過去に紹介しておりますので、具体的なイメージを知りたい方はこちらを参考にしてみてください。

product.10x.co.jp

得られる体験2. 私やtarappoさんと一緒にテストに対して追求できる

入社したら、「じゃあ、1人で頑張って」ということはありません。

開発チームメンバーと一緒に作り上げていくのはもちろん、品質管理部のメンバーと一緒に悩みつつも進めていきます。

特に、社外発表もしているメンバーとしては、tarappoさんと私がいます。過去には以下のような発表実績があります。

tarappoさんによる発表

speakerdeck.com

私の発表

speakerdeck.com

このような知見の持つメンバーと一緒に、テストについて考えていきませんか?

終わりに

今回はSETに求めることを言語化してみました*2

10Xの品質管理部では、SETを含め以下の職種で募集をしています。少しでも興味を持ってくれた方からのご応募をお待ちしております!

また、とりあえず話だけでも聞いてみたいという方がいればカジュアル面談もオープンにしていますので、こちらからどうぞ。

私とテストについて話したい場合はこちらからご応募くださいませ!

youtrust.jp

*1:有効な手段を判断するタイミングが、開発の実装前に(Shift leftして)考えることは可能なはずです

*2:なお、言語化するために、今回はオフラインで品質管理部メンバーが集まって議論しました。

オフラインで集まった時の議論内容