職種・体制

Enabling QA

（いねーぶりんぐきゅーえー）

登場（海外）: 2019年
更新: 2026-08-23

一言でいうと

自分でテストを実行するのではなく、開発チームが自分たちで品質を担保できる状態をつくることに責任を持つ QA の役割です。

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

先に断っておくと、ここで示す2019年は Team Topologies が enabling team を定義した年であり、Enabling QA という呼称そのものが初めて使われた年ではありません。呼称の初出を特定できる一次文書は確認できていないため、本ページは概念の出所として2019年を扱います。

出発点は組織設計の理論にあります。Matthew Skelton と Manuel Pais が2019年に IT Revolution Press から出した『Team Topologies』が、チームの型を4つに整理しました。ストリームアラインドチーム、プラットフォームチーム、複雑なサブシステムチーム、そしてイネイブリングチームです。公式サイトはイネイブリングチームを「ストリームアラインドチームが障害を乗り越えるのを助け、欠けている能力を検知するチーム」と定義しています。

Enabling QA は、この型を品質保証の領域に当てはめた呼び方です。QA が全件のテストを担当するのではなく、テスト設計・自動化基盤・品質の判断基準を開発チームに渡し、チーム側で回せるようにしていきます。

国内でこの呼称がいつ求人票に現れたかは、一次情報で確認できていません。そのため本ページでは国内の登場時期を確定しない扱いにしています。日本語での使用例としては、2025年2月の記事「QA組織の理想がイネイブリングQAとは限らない」が、イネイブリングQAを「QAエンジニアが開発者や他のロールがQA出来るようにして皆で品質高めていこうという動き」と説明したうえで、インプロセスQAを残したハイブリッド型のほうが現実的ではないかと論じています。国内では、理想形として語られる一方で運用の是非が議論されている段階だと読めます。

ミッション

責任範囲は「品質を上げること」ではなく「開発チームが品質を上げられる状態にすること」です。同じ不具合を止めるにしても、自分がテストして見つけるのか、開発者が自分で見つけられる仕組みを残すのかで、成果の測り方が異なります。

そのため、Enabling QA の成果はテスト実施件数では測れません。開発チームが自分たちで書いたテストの比率、リリース後に発見される不具合の推移、QA へのエスカレーション件数の減少といった、チーム側の自走度を表す指標で見ることになります。

主な業務範囲

テスト設計の型づくり。観点表・テストケースの粒度・受け入れ基準の書き方を標準化する
テスト自動化基盤の整備。CI に載せる仕組みを用意し、開発者が自分でテストを追加できる形にする
開発チームへの伴走。特定のチームに一定期間入り、その場で設計レビューやペア作業を行う
品質指標の設計と可視化。どの数字を見て品質を判断するかを決め、継続的に追える形にする
不具合の傾向分析。個別の修正ではなく、発生源になっているプロセスの改善提案につなげる

求められる能力

技術面では、テスト自動化のコードを自分で書けることが土台になります。E2E テストのフレームワーク（Playwright / Cypress 等）、CI/CD パイプライン、API テスト、テストデータ管理の知識が中心です。開発チームのコードを読み、どこにテストを置くべきかを提案できる水準が求められます。

非技術面で大きいのは、教える力と、手を出さずに待てることです。目の前の不具合を自分で直したほうが早い場面でも、チーム側が自分でできるように手順を渡す判断が必要になります。相手の力量に合わせて渡し方を変える設計力、開発者と対立せずに品質の話ができる関係構築力も見られます。

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

多いのは QA エンジニア・テストエンジニアからの移行です。手動テストの実務を経て自動化に軸足を移し、そこから他チームへの展開を任される流れが一般的です。SET（Software Engineer in Test）や開発エンジニアから、テスト基盤の担当としてこの役割に入るケースもあります。

その後は、QA アーキテクトとして全社の品質戦略を設計する道、QA マネージャーとして組織を作る道、開発生産性やプラットフォームの担当として品質以外の領域まで対象を広げる道に分かれます。

隣接職種との違い

職種	責任の中心	Enabling QA との違い
QAエンジニア	担当プロダクトのテスト設計と実施	自らテストを実施して品質を担保する。Enabling QA は実施主体を開発チームへ移すことに責任を持つ
SET	テスト自動化のためのツール・基盤の開発	成果物がツールと基盤。Enabling QA は基盤に加えて、使いこなす状態づくりまでを範囲に含む
テストエンジニア	テストケースの作成と実行	実行が中心。Enabling QA は実行の前段にある設計と教育に重心がある
QAマネージャー	QA組織の要員配置と品質方針の決定	対象が QA 組織そのもの。Enabling QA が働きかける相手は開発チームである

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

求人票に Enabling QA と書かれていても、実態は人員不足のなかで QA が全件テストも兼務している場合があります。開発チームが自分でテストを書いている比率と、QA が実施しているテストの割合を数字で聞いてください
職務経歴書では「他チームを支援した」と書かれた範囲を掘ってください。ドキュメントを配布しただけなのか、特定チームに入って自走まで見届けたのかで、再現できる成果が異なります
開発チーム側に受け入れる用意がない状態でこの役割を採ると、提案が通らないまま孤立します。誰が導入の意思決定をするのか、開発責任者が合意しているかを募集前に確認しておく必要があります

求人・市場の傾向

この呼称そのものを掲げた国内求人はまだ少なく、「QAエンジニア」「品質改善」の募集のなかに役割として含まれている形が中心です。したがって、Enabling QA という語で検索して母集団を作ろうとしても件数は伸びません。

母集団を作るなら、テスト自動化の実務経験があり、他チームへの展開や勉強会の運営を担ってきた人まで対象を広げてください。求人票の側で「テストを実施する人ではなく、開発チームがテストできる状態をつくる人を探している」と明記すると、志向の合う候補者を選別しやすくなります。