SET

一言でいうと

テストを書きやすく回しやすくするためのフレームワーク・基盤・ツールを開発する、テスト領域のソフトウェアエンジニアです。

この職種の出自と登場時期

出所は Google です。2011年に James Whittaker が Google Testing Blog で「How Google Tests Software」を連載し、テストに関わる役割を SWE（機能を作る開発者）、SET（テストの基盤と自動テストを作る開発者）、TE（プロダクト全体と利用者への影響を見る役割）の3つに整理しました。ここで SET は「テストを書く、あるいは他の開発者のテストを支える基盤を作るコーダー」と定義されています。2012年には同名の書籍も出版され、この3分類が業界に広まりました。

国内では2016年前後から、Web系の事業会社で SET・SWET という職種名の採用が始まりました。LINE は東京と福岡にQA拠点を持ち、QAエンジニアと SET を別の職種として分けていることを公開しています。名称は会社ごとに揺れており、SWET（Software Engineer in Test の別綴り）、テスト自動化エンジニア、生産性向上チームといった呼び方も同じ役割を指す場合があります。

ミッション

責任範囲は、テストにかかる時間と手間を下げて、開発者が変更を安全に出せる状態を保つことです。自分が全部のテストを書くのではなく、書かれたテストが速く安定して動く土台を用意します。

そのため、成果はテストケース数では測れません。CIの実行時間、テストの安定度（フレーキーテストの比率）、テスト作成にかかる時間の変化といった、開発者側の体験を表す指標で見ることになります。

主な業務範囲

• テストフレームワークの開発。単体・結合・E2Eそれぞれの層で、書きやすい形を用意する
• CIパイプラインの整備。テストの並列化・実行時間の短縮・失敗時の切り分け導線を作る
• テストデータと環境の整備。再現性のあるデータ生成、検証環境の払い出しを仕組み化する
• フレーキーテストの対処。不安定なテストを検知し、原因を特定して除去する
• 開発者への提供と支援。使い方の整備、詰まりどころの解消を通じて利用を広げる

求められる能力

技術面は開発エンジニアと同じ水準が求められます。対象プロダクトの言語でコードを書けること、CI/CDの構成、コンテナ、ビルドシステムを実務で扱えることが条件です。テスト技法の知識も必要ですが、比重は実装側に寄ります。

もう一つ求められるのが、開発者の作業を見て詰まりどころを見つける観察力です。要望として上がってこない不便を拾って優先度をつける判断が、成果の差になります。

この職種に就く人のキャリア経路

多いのは開発エンジニアからの移行です。担当プロダクトのテスト整備や CI 改善を進めた延長で、専任になる流れです。QAエンジニアが自動化を担当するうちに実装側へ軸足を移すケースもあります。

そこから先は、Platform Engineer や生産性向上の担当として対象をテスト以外へ広げる道、QA Architect として品質戦略を設計する道、開発組織のマネージャーへ進む道に分かれます。

隣接職種との違い

採用担当の見極めポイント

• SETの募集にQAエンジニアの応募が集まる状態は珍しくありません。求人票では、コードを書く比率と使用言語を明記してください
• 職務経歴書では、作った基盤が使われたかどうかを確認してください。フレームワークを作った実績と、開発者に定着させた実績は別に評価する必要があります
• 社内に自動化の下地がない状態でこの役割を採ると、テストを書く文化づくりから始まります。開発チームの現状を伝えたうえで、その前提を許容できる候補者を選ぶ必要があります

求人・市場の傾向

国内の母集団は薄く、SETという呼称で検索して集まる件数は限られます。テスト自動化の実務経験がある開発エンジニア、QAから自動化に軸足を移した層まで対象を広げるほうが到達しやすくなります。

求人票では、現在のテストの状況（自動テストの有無、CIの実行時間、フレーキーテストの状態）を具体的に書くと、候補者が入社後の仕事を判断できます。

関連キーワード

テスト自動化 / CI/CD / フレーキーテスト / E2Eテスト / Playwright / テストピラミッド / 開発生産性 / SWET