LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

SETとは何か — 手動テスターとQAエンジニアとの3つの違い

SET（Software Engineer in Test）とは、開発とテストの両方に通じ、テスト自動化フレームワークの構築や品質基準の設定に注力するエンジニアを指します。従来の手動テスター・QAエンジニアとは異なり、コードを書いてテストを自動化することを主な職責とします^*1。

SETと他の職種の違いは主に3点あります。第一にコーディング能力の要求水準です。手動テスターはテスト仕様書に沿った確認作業が中心で、プログラミングを必要としません。SETはテスト自動化フレームワーク（Selenium・Appium・Cypress等）を自ら構築・改修できる開発力が前提となります。

第二に担う範囲の違いです。QAエンジニアは品質保証プロセス全体を設計・管理する広域な役割を持ちます。SETはその中でも「テスト自動化の設計・実装・維持」に集中する専門職です。テストをコードとして管理し、CI/CD（継続的インテグレーション/継続的デリバリー）パイプラインに組み込む作業がSETの中心的な仕事になります。

第三に開発チームとの協働スタイルです。SETは開発フェーズの早い段階から参画し、テスタビリティ（テストしやすい設計）の観点で開発チームにフィードバックします。テストの「実行」よりも「自動化基盤そのものの品質」に責任を持つ点が、従来のQA職と大きく異なります。

手動テストが限界を迎えるメカニズム — 回帰コストの増大

アジャイル開発やCI/CDの普及により、リリースサイクルが週次・日次へと短縮されています。手動テストのみで品質を担保しようとすると、リリースのたびに全機能の動作確認（回帰テスト）を人手で繰り返すことになります。

機能が増えるにつれて回帰テストの工数は比例的に増加します。開発チームが新機能の実装を続けるほど、テストチームが消化しなければならないテストケースも積み上がります。結果として「テストが終わらないのでリリースが遅れる」か、「テストを省略してリリースするため品質が下がる」かの二択を迫られるケースが生まれます。

手動テストに依存したままCI/CDを導入しても、デプロイの自動化とテストの手動実行の間にボトルネックが残ります。自動化されていないテストが品質ゲートとして機能せず、バグが本番環境に流れ込むリスクが高まります。SETが不在の状態でリリース速度だけを上げようとすると、こうした品質劣化が起きやすくなります。

手動テスト中心の開発で発生する具体的なリスク

テスト自動化が進まないまま開発が継続する状況では、以下のリスクが具体的に生じます。

• デグレード（機能の退行）の見逃し：新機能追加の際に既存機能が壊れていても、手動テストで全件を確認する工数がとれず、本番リリース後に発覚します
• テスト工数の属人化：テストケースが個人の経験に依存するドキュメントで管理されると、担当者が変わった際の引き継ぎコストが膨らみます
• リリースサイクルの頭打ち：開発速度が上がっても手動テストがボトルネックとなり、スプリントをまたいだテスト待ちが常態化します

これらは開発チームが大きくなるほど顕著になります。テスト自動化基盤を持つチームと持たないチームでは、機能追加のスピードと品質安定性の両立において、時間が経つほど差が開きます。

SETが担うテスト自動化の範囲：単体・結合・E2E・基盤開発

SETが担うテスト自動化の範囲は、テストの「レベル」と「基盤整備」の2軸で整理できます。テストレベルには単体テスト・結合テスト・E2Eテストがあり、いずれにおいても自動化を設計・実装・維持する役割を担います。

テストレベルごとの自動化の役割

• 単体テスト（Unit Test）：個々の関数・クラスが仕様通りに動作するかをコード単位で検証します。SETは単体テストのカバレッジ基準の設定や、テスタブルな設計への誘導を開発チームと共に担います
• 結合テスト（Integration Test）：複数モジュールやAPIの連携動作を確認します。マイクロサービス構成では特に複雑になるため、モック（テスト用の代替オブジェクト）やスタブの設計がSETの専門知識となります
• E2Eテスト（End-to-End Test）：ユーザー操作をシミュレートして画面から機能全体を検証します。Selenium・Appium・Cypress等のフレームワークを活用し、主要ユーザーシナリオを自動実行できる状態にします

テスト基盤開発：自動化を維持するための仕組みづくり

SETの役割はテストケースを書くだけでは終わりません。テスト基盤自体を設計・開発・維持する工程が中心的な職責です。

テストフレームワークの選定・構築（使用言語・ライブラリ・テストデータ管理の設計）から始まり、CI/CDパイプラインへの組込み、テスト結果の可視化ダッシュボードの整備、フレーキーテスト（Flaky Test：不安定に失敗するテスト）の検出と対策まで、自動化基盤そのものを「動かし続ける」エンジニアリング作業が伴います。

こうした基盤整備には、Java・Ruby・Python等のプログラミングスキルに加え、AWS等のクラウド上でテスト実行環境を構築・管理するインフラ知識も必要です。開発とテストを横断する技術領域を一人でカバーできる人材であるため、市場での需要が採用供給を上回る状態が続いています^*2。

SET人材が不足する理由 — 開発力×テスト知識の両立が希少

SET人材が市場で不足する背景には、求められるスキルセットの広域性と育成の難しさがあります。「開発ができる」「テストを理解している」のどちらかだけでは不十分で、両方を実務レベルで持つ人材が希少です。

開発エンジニアとQAエンジニアの間に挟まれた希少領域

開発エンジニアはコードを書くスキルを持ちますが、テスト設計・品質基準・テスタビリティへの意識が薄いケースがあります。一方でQAエンジニアはテスト設計と品質保証の知識はあるものの、自動化フレームワークをゼロから構築できる開発力を持つケースは多くありません。

SETはこの両方の知識を重ね合わせる必要があります。採用市場において、両方の素養を実務レベルで兼ね備えた人材は希少で、求人に対して応募が集まりにくい領域です。

育成にかかるリードタイム

社内育成を選択する場合、既存の開発エンジニアにテスト自動化を習得させるか、QAエンジニアに開発スキルを身につけさせるかの二通りのアプローチが考えられます。いずれも実務で使えるレベルに達するまでには、育成開始から一年を超えるリードタイムを想定する必要があります。

経済産業省「IT人材需給に関する調査」（2019年）では、高位シナリオで2030年に約79万人のIT人材不足が見込まれています^*2。テスト自動化専門人材の絶対数はこの中でもさらに限られており、採用競争は激しい状態にあります。

内製育成の失敗パターン

「開発エンジニアにテスト自動化も担わせる」という方針をとる組織では、自動化の優先度が機能開発に押されて下がりやすくなります。テスト自動化は効果が中長期にわたって現れるため、短期的な機能要求の前で後回しにされるリスクがあります。専任でSETの役割を担う人員を確保しないまま自動化を進めようとすると、フレームワークが未完成のまま塩漬けになるケースが生まれます。

外部で補う選択肢：業務委託・受託・自動化基盤の構築委託

SET人材の採用が難しい状況でも、外部支援を活用することでテスト自動化を前進させることができます。主な選択肢は「業務委託（SES形式）」「自動化基盤の受託開発」「テスト自動化丸ごと委託」の3種類です。

3つの中で内製移管を前提に選ばれやすいのが「自動化基盤の受託開発」です。フレームワーク・CIパイプライン・テストコードをセットで納品してもらうことで、受託終了後も自社エンジニアが保守・拡張できる状態を引き継げます。外部委託を「一時的な代替」ではなく「自動化基盤を整える投資」として位置づけると、長期的な費用対効果が高まります。

進め方の4ステップ：対象選定→FW構築→CI組込み→内製移管

テスト自動化を外部支援で立ち上げ、最終的に内製移管するまでの流れは、以下の4ステップが実務上の標準です。

1. 自動化対象の選定：すべてのテストケースを自動化しようとすると工数過大になります。まず「頻繁に実行される」「手動コストが高い」「デグレード検出に重要」の3軸で優先度の高いテストを選定します。主要ユーザーシナリオのE2Eテストと、コアロジックの単体テストが最初の対象として選ばれやすいです。
2. フレームワーク構築：選定した対象に対応するテスト自動化フレームワークを設計・実装します。フレームワーク選定（Selenium・Appium・Cypress等）・使用言語・テストデータ管理の設計・レポーティングの仕組みをここで決めます。設計の選択肢とトレードオフを開示してもらえるパートナーを選ぶことが大切です。
3. CIパイプラインへの組込み：構築したテストフレームワークをCI/CDパイプラインに統合し、プルリクエストやデプロイのタイミングで自動テストが実行される状態を作ります。GitHub Actions・Jenkins・CircleCIなど既存のCI環境に合わせた設定が必要です。テストが失敗した場合のデプロイ停止ルールも合わせて整備します。
4. 内製移管：フレームワーク・CIパイプライン・テストコードの設計意図を自社エンジニアに引き継ぎます。設計書・メンテナンス手順書・フレーキーテスト対策のガイドラインを納品物として契約に含めておくことで、移管後の保守がスムーズになります。スポット的な技術サポート契約を一定期間継続することも、移管リスクを下げる選択肢です。

4ステップを通じて大切なのは、第1ステップの「対象選定」に時間をかけることです。自動化の対象を絞り込まずにフレームワーク構築を始めると、後から対象が拡大してフレームワークの再設計が必要になります。外部パートナーと対象選定を共同で行い、スコープを合意してから実装に入る進め方が、手戻りを防ぎます。

内製採用と外部活用の比較

「SET人材を採用で確保する」か「外部支援でテスト自動化を進める」かを判断する際の参考として、以下に主要な観点を整理します。

二択で判断する必要はありません。外部支援でテスト自動化基盤を先に作り、その基盤が稼働している間に採用・育成を並行して進めるハイブリッドな進め方が、多くの開発組織に合っています。基盤が整った状態でSETを採用すると、入社後の立ち上がりが早くなり、即戦力化のリードタイムも短くなります。

委託時の注意点：保守・フレーク対策・属人化回避

テスト自動化を外部委託する際は、受託開発の完了後に発生しやすい3つの問題を事前に対処しておくことが大切です。

保守コスト：アプリ変更に追従する仕組みを設計する

テスト自動化で陥りやすい落とし穴が「作ったが保守できない」状態です。アプリの画面設計やAPIが変わるたびに、テストコードも更新が必要になります。E2Eテストはとくに画面要素に依存しやすく、UI変更のたびにテストが失敗するようになります。

委託先にフレームワーク設計の際にPage Object Model（画面ごとにロケーターを集約するデザインパターン）など保守しやすいアーキテクチャを採用しているかを確認します。また、テストコードの変更を行うための手順書を納品物に含めることで、自社エンジニアが保守できる状態を作ります。

フレーキーテスト対策：不安定な自動テストは信頼を失わせる

フレーキーテスト（Flaky Test）とは、同じコードに対して実行するたびに合否が変わる不安定なテストを指します。タイミング依存・非同期処理の待ち時間設定ミス・テストデータの競合などが原因として発生します。

フレーキーテストが多い自動化基盤は、開発チームから「信頼できない」と判断され、テスト結果が無視されるようになります。委託先がフレーキーテストの検出・修正プロセスを持っているかを選定段階で確認し、フレーキー率の報告を契約に含めることが大切です。

属人化回避：一人のSETに依存した基盤を作らない

受託したSETが一人でフレームワークを設計・実装すると、そのエンジニアが離脱した後に基盤のメンテナンスができなくなります。設計ドキュメント・テストコードのコメント・セットアップ手順書を整備し、複数人が理解・保守できる状態で納品される契約条件にしておくことで、属人化リスクを下げられます。

まとめ：QA自動化人材不足に対処する3つの判断軸

本稿ではSETの役割・手動テストの限界・自動化範囲・人材不足の背景・外部支援の活用方法を整理しました。要点を3つに集約すると次のとおりです。

第一に、SETは「テストするエンジニア」ではなく「テスト自動化基盤を開発・維持するエンジニア」です。手動テスターやQAエンジニアとは役割が根本的に異なり、開発力とテスト設計の両方を持つ希少人材です。採用難は構造的な要因によるもので、市場環境が短期間で変わる見込みは小さいです。

第二に、手動テストへの依存はリリース速度の向上とともに回帰コストの増大を招きます。テスト自動化基盤がない状態でCI/CDを推進しても、品質ゲートがなく本番障害のリスクが高まります。

第三に、外部委託で自動化基盤を先に構築し、フレームワーク・CIパイプライン・保守手順を整えてから内製移管する進め方が、採用難の中で現実的な解決策です。委託先の選定では、フレーキーテスト対策・ドキュメント納品・属人化回避の3点を確認することが大切です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：技術解説・採用情報等に基づく（SET：Software Engineer in Test の役割定義）
2. *2　出典：経済産業省「IT人材需給に関する調査」（2019年）

Tweet