はじめに
近年、多くの現場で「SET（Software Engineer in Test）」というロールが取り入れられ始めています。テストの自動化を担当する技術職として認識されがちなこの役割ですが、実際には組織ごとに期待値が曖昧で、「結局何をする人？」 といった議論が絶えません。
中には、SETが「QAが足りないから手動テストもやってほしい」「運用もできるでしょ？」と便利屋扱いされるケースもあります。私自身もそのような状況に直面し、強い違和感と危機感を感じています。
この記事では、そうした違和感の根源を掘り下げ、「本来のSETの役割とは何か？」 を再定義したいと思います。
SETとは何者か？
SET（Software Engineer in Test）は、簡単に言えば品質保証に特化した技術職です。QAエンジニアではありませんが、QAを支える立場として、以下のような役割を持ちます：
- テストの自動化（E2E/ユニット/統合）
- テスト基盤やツールの整備
- CI/CDパイプラインへのテスト統合
- テスト結果の可視化
- テストデータやMockの整備
- 品質メトリクスの収集と改善提案
- フレーキーなテストの対策と安定化
つまり、“品質を技術で支えるエンジニア” です。
よくある誤解とその違い
| 誤解 | 本来のSETの役割 |
|---|---|
| 手動テストもできるテストエンジニア | QA観点を理解したうえで、技術的に自動化・効率化を図るエンジニア |
| テストスクリプトを書く人 | テストの価値を評価し、継続可能な品質保証の仕組みを設計する人 |
| QAの下位互換 | テストプロセス全体を支援し、プロダクトの品質を長期的に担保する技術専門職 |
SETは 「実行者」ではなく「仕組みを作る側」 だという意識が重要です。
SETに求められる技術領域
SETの専門性は、単なるテスト自動化スクリプト作成にとどまりません。以下のような技術領域にまたがります：
- Playwright / CodeceptJS / Cypress などによるE2E自動化
- GitHub ActionsやJenkinsを用いたCI/CDパイプライン構築
- TestRailなどのテスト管理ツールとの連携
- DockerやMockサーバーによるテスト環境の構築
- AIによるテストケース生成、リスクベースド分析
- テスト実行結果の可視化、Slack通知、自動レポーティング
現場で起きている問題
実際の現場では、SETの役割が明確に定義されておらず、「テスト自動化ができる人＝何でもできる人」と捉えられてしまうケースが散見されます。その結果、SETが本来担うべき技術的な改善や自動化の設計ではなく、手動テストや運用業務のリソース補填として使われる場面が増えてきています。
これは特定の企業や地域に限った話ではなく、SETという職種そのものがまだ新しく、組織内での立ち位置や認識が定まっていないことに起因しています。
このような状況が続くと、SETエンジニアとして本来の専門性を発揮できず、キャリアとしての一貫性や成長の機会が損なわれるリスクがあります。
自分のスタンス
私は、SETエンジニアは「品質保証がしたい人」ではなく、「品質保証を技術で支えたい人」だと考えています。だからこそ、テストの実行や設計を代行するのではなく、テストを“しやすくする仕組み”を作ることこそが本質的な貢献だと思っています。
SETの役割が曖昧にされ、便利屋的に使い潰されることは、プロダクトにとっても、組織にとっても、そして何よりエンジニア自身にとっても大きな損失です。
まとめ
- SETは「QA≠SET」であるべき存在
- 手動実行や設計業務の代行ではなく、技術による支援が本来の価値
- 組織としてSETの定義と期待を明文化し、分業体制を健全に保つことが重要
SETの価値が正しく理解され、真に力を発揮できる環境が増えていくことを願って、この文章を締めくくります。
最後までお読みいただき、ありがとうございました。