はじめに

近年、多くの現場で「SET（Software Engineer in Test）」というロールが取り入れられ始めています。テストの自動化を担当する技術職として認識されがちなこの役割ですが、実際には組織ごとに期待値が曖昧で、「結局何をする人？」 といった議論が絶えません。

中には、SETが「QAが足りないから手動テストもやってほしい」「運用もできるでしょ？」と便利屋扱いされるケースもあります。私自身もそのような状況に直面し、強い違和感と危機感を感じています。

この記事では、そうした違和感の根源を掘り下げ、「本来のSETの役割とは何か？」 を再定義したいと思います。

SETとは何者か？

SET（Software Engineer in Test）は、簡単に言えば品質保証に特化した技術職です。QAエンジニアではありませんが、QAを支える立場として、以下のような役割を持ちます：

つまり、“品質を技術で支えるエンジニア” です。

誤解	本来のSETの役割
手動テストもできるテストエンジニア	QA観点を理解したうえで、技術的に自動化・効率化を図るエンジニア
テストスクリプトを書く人	テストの価値を評価し、継続可能な品質保証の仕組みを設計する人
QAの下位互換	テストプロセス全体を支援し、プロダクトの品質を長期的に担保する技術専門職

SETは 「実行者」ではなく「仕組みを作る側」 だという意識が重要です。

SETの専門性は、単なるテスト自動化スクリプト作成にとどまりません。以下のような技術領域にまたがります：

実際の現場では、SETの役割が明確に定義されておらず、「テスト自動化ができる人＝何でもできる人」と捉えられてしまうケースが散見されます。その結果、SETが本来担うべき技術的な改善や自動化の設計ではなく、手動テストや運用業務のリソース補填として使われる場面が増えてきています。

これは特定の企業や地域に限った話ではなく、SETという職種そのものがまだ新しく、組織内での立ち位置や認識が定まっていないことに起因しています。

このような状況が続くと、SETエンジニアとして本来の専門性を発揮できず、キャリアとしての一貫性や成長の機会が損なわれるリスクがあります。

私は、SETエンジニアは「品質保証がしたい人」ではなく、「品質保証を技術で支えたい人」だと考えています。だからこそ、テストの実行や設計を代行するのではなく、テストを“しやすくする仕組み”を作ることこそが本質的な貢献だと思っています。

SETの役割が曖昧にされ、便利屋的に使い潰されることは、プロダクトにとっても、組織にとっても、そして何よりエンジニア自身にとっても大きな損失です。

SETの価値が正しく理解され、真に力を発揮できる環境が増えていくことを願って、この文章を締めくくります。

最後までお読みいただき、ありがとうございました。