品質は誰の仕事か — 専任テスターから全員品質へ

「品質を担保するのは誰か」 という問いへの答えは、 この数十年で大きく作り変えられてきた。 1980〜90 年代の 「専任テスターが完成品を手動で検査する」 体制から、 テスト自動化と SDET の台頭を経て、 2010 年代以降は 「開発者自身がテストを所有する」 文化へ。 そして現在では、 その 「全員品質」 が機能の正しさだけでなく、 性能とセキュリティまで飲み込んでいる。 本記事では、 この職能変遷の軌跡を辿る。

専任テスター・手動 QA の時代

1970〜90 年代の伝統的なウォーターフォール型開発では、 テストは開発の最終工程に置かれる独立したフェーズだった。 開発チームがコードを書き終えた後、 別部門の QA チームがテスト計画書・テストケース仕様書に基づいて 手動でシステムを検査する体制が一般的だった。

QA (品質保証) はプロセス全体の品質を担保する活動、 QC/テストは成果物の欠陥を検出する活動として 概念上区別されることが多いが、 実務では両者を含めて 「QA 部門」 と呼ぶことが多かった。 特に航空宇宙・防衛分野では、 開発チームから完全に独立した組織がテストを行う IV&V (Independent Verification and Validation) が制度化され、 IEEE 829 に代表される詳細なテスト計画・テストケース・テスト報告書の作成が重視された。 この時代のテストは 「バグを見つける関門」 として開発の後工程に位置づけられ、 テスト担当者と開発者の間には 明確な組織的・文化的分断があった。

テスト自動化の台頭

1990 年代後半〜2000 年代にかけて、 GUI 自動化ツール (Mercury Interactive 社の WinRunner/QuickTest Professional など) や、 xUnit ファミリー (xUnit の誕生 と その拡散 を参照) の普及により、 繰り返し実行される回帰テストを自動化する動きが広がった。 自動化の普及は同時に、 テスト担当者に求められるスキルセットを 「手動で UI を操作する能力」 から 「テストコードを書くプログラミング能力」 へとシフトさせた。 この変化が、 次に述べる SDET という職種を生む土壌となった。

SDET の登場 — テスターもエンジニアである

2000 年代、 Microsoft は SDET (Software Development Engineer in Test) という職種名を大きく打ち出した。 SDET は単にテストを実行するのではなく、 テスト自動化フレームワーク・ツール・インフラをコードとして開発する ソフトウェアエンジニアと位置づけられた。 これは 「テスターもエンジニアである」 という認識の転換を象徴する動きだった。

Google も同時期に類似する専門職を設けたが、 名称と役割分担がやや異なっていた。

職種	主な役割	主な担い手企業
SDET	テスト自動化基盤・ツールの開発、 コードとしてのテスト設計	Microsoft
SET (Software Engineer in Test)	開発チームに埋め込まれ、 テスト容易性の高いコードとテストインフラを構築	Google
TE (Test Engineer)	製品横断的な品質・リスク分析、 探索的テスト、 ユーザー視点の検証	Google

Google における品質エンジニアリングの実態は、 James Whittaker ら (元 Google) による書籍 『How Google Tests Software』 (2012 年) に詳しい。 同書は、 Google が 「専任テスター」 を最小化し、 開発者自身にテストの一次責任を持たせつつ、 SET/TE が横断的に品質を支援する体制を描いている。

その後、 Microsoft も含め業界全体で 「専任のテスト職を段階的に縮小し、 開発者にテストを統合する」 流れが強まった。 Microsoft では 2014 年前後に、 独立した職種として存在していたテストディシプリン (SDET/STE) を大幅に縮小し、 開発 (Software Engineer) とテストの役割を統合する組織再編を行ったことが 当時広く報じられた。 これは 「テスト専門職の消滅」 というより、 「テスト責任を開発者自身に統合し、 専任テスターは横断的な品質戦略・複雑な自動化基盤の設計に特化する」 という 役割の再定義であったと理解するのが適切である。 2010 年代半ば以降、 SDET/SET という肩書き自体は各社で縮小・再編されていくが、 「テストはコードであり、 エンジニアリングスキルを要する」 という考え方自体は定着した。

開発者がテストを所有する文化へ

現在では、 多くの組織で 「テストを書くのは機能を実装した開発者自身」 という原則が一般化している。 この背景には次の要因がある。

1. TDD/BDD の普及 —— 開発と同時にテストを書く実践が浸透 (TDD、 BDD を参照)
2. CI/CD パイプラインの一般化 —— 自動テストがマージ・デプロイの必須ゲートとなり、 開発者がテストの成否に直接責任を持つ構造になった
3. マイクロサービス・小規模チーム化 —— 機能単位でチームが完結するため、 品質もチーム内で完結させる圧力が働いた

これにより、 「品質は専任 QA の仕事」 から 「品質はチーム全員の責任」 への価値観の転換が進んだ。 ただしこれは専任の品質専門職が不要になったことを意味せず、 QA エンジニア・SDET は 「品質戦略の設計者」 「探索的テストや複雑な E2E シナリオの専門家」 「品質文化の推進者」 として役割を再定義しつつ存続している。

Shift-Left / Shift-Right

「シフトレフト」 はテスト活動を SDLC のより早い段階 (左側) に移動させる考え方で、 Larry Smith が 2001 年に Dr. Dobb’s Journal 誌に寄稿した記事 「Shift-Left Testing」 で提唱したとされる。 要件定義・設計段階からテスト可能性を検討し、 コーディング中に単体テストを書き、 欠陥を可能な限り早期に、 安価なうちに検出することを目指す。

一方 「シフトライト」 は、 本番環境 (右側) でも継続的に品質を検証する考え方で、 2010 年代に普及した。 カナリアリリース、 フィーチャーフラグ、 A/B テスト、 そして Netflix が 2011 年頃に公開した Chaos Monkey (Simian Army) に代表されるカオスエンジニアリングなどが含まれる。 これは 「本番前にすべての欠陥を潰す」 ことの限界を認め、 「本番でも観測・実験しながら品質を維持する」 という考え方への拡張である。 Shift-Left と Shift-Right は対立概念ではなく、 テストを開発ライフサイクル全体に分散配置する戦略として 補完的に捉えられる。

探索的テストと context-driven testing 学派

探索的テスト (Exploratory Testing) は、 テスト設計・実行・学習を同時並行的に行う手法で、 事前に詳細なテストケースを固定せず、 テスターが製品を探索しながら次のテストを考案していく。 この用語は Cem Kaner が 1988 年の著書 『Testing Computer Software』 の中で提唱したとされる。

探索的テストは 「非構造的で管理不能」 という批判を受けやすいが、 これに対する回答として、 James Bach と Jonathan Bach が 2000 年前後に提唱したのが セッションベーステスト管理 (Session-Based Test Management, SBTM) である。 探索的テストを 「セッション」 という時間区切りの単位で管理し、 各セッションの目的 (チャーター) と結果を記録することで、 探索的テストに追跡可能性と説明責任を持たせる枠組みである。

コンテキスト駆動テスト (Context-Driven Testing) は、 Cem Kaner、 James Bach、 Bret Pettichord らが中心となって 2000 年代初頭に確立した学派で、 「テストのベストプラクティスはコンテキストに依存し、 万能の正解は存在しない」 という立場を取る。 3 人の共著 『Lessons Learned in Software Testing』 (2001 年) はこの学派の代表的文献である。 Michael Bolton は後に James Bach と共に 「Rapid Software Testing (RST)」 方法論を発展させ、 コンテキスト駆動学派の中心的論者の一人となった。 この学派は、 テストを 「チェック (checking: 事前に決めた期待結果との照合、 機械的に自動化可能)」 と 「テスティング (testing: 人間の知識・判断による調査的活動)」 に区別する視点を提示し、 自動テストと探索的テストの役割の違いを明確化した。

ISO/IEC/IEEE 29119 をめぐる論争

コンテキスト駆動学派の影響力を語る上で欠かせないのが、 2013 年に発行された国際規格 ISO/IEC/IEEE 29119 をめぐる論争である。 この規格はテストプロセス・テストドキュメント・テスト技法を標準化しようとするものだったが、 「テストのベストプラクティスはコンテキストに依存し、 単一の標準プロセスを万能な正解として押し付けるべきではない」 と考えるコンテキスト駆動学派から強い反発を招いた。

2014 年、 テスト専門家 James Christie がカンファレンス CAST 2014 で行った講演をきっかけに、 参加者の Karen Nicole Johnson が請願運動を提案したことから、 “Stop 29119” と呼ばれる反対キャンペーンが立ち上がった。 James Bach をはじめとするコンテキスト駆動学派の論客が中心となって この規格の策定プロセスの排他性・単一プロセスの押し付けを批判し、 国際的な議論に発展した。 なお、 この論争とは別の系譜として ISTQB (International Software Testing Qualifications Board) が 2002 年に設立され、 テスト技術者の資格認定制度 (ISTQB Certified Tester) を国際的に普及させてきた。 ISTQB のシラバスは体系化されたテストプロセス・技法 (同値分割、 境界値分析など) を教育する枠組みとして広く使われており、 コンテキスト駆動学派としばしば対比的に語られる。

アジャイル QA とテスト四象限

アジャイル開発の普及に伴い、 QA の役割もスプリント内に統合される形へと変化した。 この文脈での代表的文献が、 Lisa Crispin と Janet Gregory による 『Agile Testing: A Practical Guide for Testers and Agile Teams』 (2009 年) であり、 続編 『More Agile Testing』 (2014 年) と合わせてアジャイル QA の実践書として広く読まれている。

Crispin & Gregory の著書で紹介され普及した 「テスト四象限」 は、 元々 Brian Marick が考案したモデルで、 テストを 2 つの軸で 4 象限に分類する。

	ビジネス (顧客) 向け	技術 (チーム) 向け
チームを支援	Q2: 機能受け入れテスト、 ストーリーテスト、 プロトタイプ	Q1: 単体テスト、 コンポーネントテスト
製品を批評	Q3: 探索的テスト、 ユーザビリティテスト、 UAT	Q4: 性能テスト、 セキュリティテスト、 非機能テスト

この図式は、 自動化すべき領域 (Q1・Q2 の多く) と、 人間の判断が必要な領域 (Q3・Q4 の一部) を整理し、 アジャイルチームがテスト活動全体をバランスよく計画するための共通言語となった。

呼称の変遷 — QA から Quality Engineer へ

役割の実態変化は、 職種名の変化にも表れている。 近年多くの企業で 「QA エンジニア」 に代えて QE (Quality Engineer) という呼称が採用される傾向が強まっている。 これは単なる言い換えではなく、 「欠陥を見つけて報告する (保証する) 役割」 から 「品質を作り込む仕組み自体を設計する役割 (エンジニアリング)」 への重心移動を反映している。 QE は、 テスト自動化基盤の設計、 CI/CD における品質ゲートの設計、 可観測性の整備、 開発チームへのテスト技法のコーチングなど、 より上流かつ横断的な役割を担うことが多い。

Q4 が実体を持つ — 性能テストという非機能の砦

テスト四象限の Q4 に置かれた性能テストとセキュリティテストは、 機能的正しさとは独立した 「非機能要件」 を検証する活動として、 「全員品質」 の一角を占めるようになった。 性能テスト には、 想定負荷での応答を確認する 負荷テスト、 限界を超えた負荷での挙動を見る ストレステスト、 急激なトラフィック増加への耐性を見る スパイクテスト、 長時間稼働でのリーク・劣化を見る 耐久テスト、 リソース追加時の性能向上を見る スケーラビリティテスト がある。

代表的なツールには、 老舗 OSS の Apache JMeter、 Scala DSL でシナリオを書く Gatling、 JavaScript でスクリプトを書き 2021 年に Grafana Labs が買収した k6、 Python で分散負荷を生成する Locust、 軽量高スループットな wrk・Vegeta などがある。 重要なのは、 レイテンシを平均値だけで語らないこと —— p50・p95・p99 といったパーセンタイルでテールレイテンシを把握することが不可欠とされる。 サービス視点の RED 法 (Rate・Errors・Duration、 Tom Wilkie 提唱) とリソース視点の USE 法 (Utilization・Saturation・Errors、 Brendan Gregg 提唱) を組み合わせた分析、 Google の SRE プラクティスで体系化された SLO とエラーバジェットとの連動、 そして本番トラフィックを複製して検証する トラフィックミラーリング/ダークローンチ といった shift-right 的手法が、 現代の性能テストを支えている。

セキュリティテストというもう一つの非機能

DevSecOps は、 shift-left の考え方をセキュリティ領域に適用したもので、 セキュリティ検証を開発ライフサイクルのできるだけ早い段階に組み込む。 自動化ツールは、 ソースコードを解析する SAST、 実行中のアプリケーションを外部から検査する DAST、 実行時にコード内部を計装する IAST、 依存ライブラリを検査する SCA の 4 分類に整理され、 検出された脆弱性は CWE (脆弱性の型分類) と CVSS (深刻度スコア) で優先順位付けされる。

セキュリティ文脈のファジングでは、 カバレッジ誘導型ファザーの先駆けである AFL (Michał Zalewski)、 LLVM の libFuzzer、 Google が 2016 年に開始した継続的ファジングサービス OSS-Fuzz が重要な役割を果たしてきた。 自動化ツールを補完するのが、 ホワイトハッカーによる手動主体の ペネトレーションテスト、 そして HackerOne や Bugcrowd が仲介する バグバウンティプログラム — 期間限定の集中検査と、 常時稼働の継続的検査という補完関係にある。 設計段階で攻撃経路を洗い出す 脅威モデリング では、 STRIDE (Loren Kohnfelder と Praerit Garg が 1999 年に考案) や Adam Shostack の著書 『Threat Modeling: Designing for Security』 (2014 年) が広く参照される。 本番環境での WAF・RASP は、 テストや静的解析をすり抜けた脆弱性への最後の防衛線として機能する shift-right security の実例である。

業界横断の共通言語となっているのが OWASP Top 10 で、 2021 年版から約 8 年ぶりの大幅改訂となる OWASP Top 10:2025 は、 17 万 5 千件超の CVE データの分析を踏まえて再構成された。 長らく 1 位だった 「アクセス制御の不備」 (SSRF を統合) は引き続き 1 位を維持し、 「Software Supply Chain Failures」 と 「Mishandling of Exceptional Conditions」 が新設され、 サプライチェーン攻撃や例外処理の不備という近年の攻撃傾向が反映されている。

まとめ — 全員品質は、 正しさだけでなく非機能も含む

QA の歴史は、 「独立した検査部門による関門」 から 「開発プロセス全体に浸透した品質活動」 への移行の歴史である。 SDET/SET という職種の登場は 「テストもエンジニアリングである」 という認識を確立し、 探索的テストとコンテキスト駆動学派は 「テストは機械的チェックだけでは代替できない知的活動である」 ことを理論化した。 そしてテスト四象限が示すように、 現在の 「全員品質」 は機能的な正しさだけでなく、 性能とセキュリティという非機能要件までを含む。 自動化されたチェックと人間による探索的テスティングを組み合わせ、 開発ライフサイクル全体 (shift-left/shift-right) に品質活動を分散させる体制が、 現在の主流となっている。

次記事では、 この 「全員品質」 の体制が、 数百人・数千人規模の組織や、 巨大化したコードベースというスケールの中でどう維持され、 どこで軋みを生むのかを見ていく。 テストを大規模に運用する —— 品質の分散配置が組織の規模というもう一つの変数と出会う場所へ。