近年のソフトウェア業界では、テスト関連活動を担うエンジニアを「QAエンジニア」と呼ぶようになっています。ただQA（品質保証）という言葉は、旧来から二つの定義が共存しているほか、業界内の通例で更に別の意味付けが行われた結果、定義が曖昧になり誤解を生みがちな状態となっています。
そこで今回は、日本語圏で、QA（品質保証）の言葉がどのように定義されているか、整理して解説します（結論からいうと三流派あります）
国際標準規格での定義：品質マネジメントシステムの実証
IEEEやISOといった国際的な標準規格、およびそれに準拠した知識体系や標準では、古くから体系立てて品質マネジメント、品質保証、品質管理の定義を行っています。
有力な文献として、品質マネジメントの標準規格である、ISO 9000：2015の定義を紹介します。
まずISO 9000では、品質保証の前提として品質マネジメントという用語を使っているので、前提知識としてその用語定義を関連用語とまとめて引用します。
【品質マネジメント（quality management） 】
品質に関するマネジメント。
品質マネジメントには、品質方針及び品質目標の設定、並びに品質計画、品質保証、品質管理及び品質改善を通じてこれらの品質目標を達成するためのプロセスが含まれ得る。
【品質】
対象に本来備わっている特性の集まりが要求事項を満たす程度
【マネジメント】
組織を指揮し管理するための調整された活動
要点をかいつまんで説明すると、望ましい品質を実現するための組織的な活動を「品質マネジメント」と呼び、品質保証は、品質マネジメントの一要素である、と定義しています。
次に、品質保証や類似活動の定義を次のように行っています。
【品質保証（quality assurance）】
品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部。
【品質管理（quality control） 】
品質要求事項を満たすことに焦点を合わせた品質マネジメントの一部。
【品質改善（quality improvement） 】
品質要求事項を満たす能力を高めることに焦点を合わせた品質マネジメントの一部。
別の文献ですが、ISO/IEC 29119-13:2022 Part13のTR版では、次のような記述があります
Software testing is a form of quality control, which, together with quality assurance comprise quality management
（ソフトウェアテストは、品質管理の一部である。品質管理と品質保証を組み合わせて品質マネジメントを構成する）
※()内は本ブログでの意訳
内部解説を含めて、具体的に要点をまとめると、次のようになります：
- 品質管理は、開発成果物が品質目標を満たしているか確認し、品質をコントロールするための活動。具体的には、開発成果物がユーザの要求を満たしているかテストする、コードに品質リスクがないか静的解析する、といった活動が該当する。
- 品質保証は、必要な品質を実現するための方針立て、プロセス、組織体制、その運用活動が、問題なく妥当であると確信を得るための活動。品質管理が適切に行われているか確認するのも品質保証の一部。具体的には、開発者がプロセス定義どおりに活動しているか確認する、プロセス定義が法規制に準拠しているか監査する、といった活動が該当する。
日本的品質管理での定義：顧客満足の実現
一方、日本語圏では、前述のISO等の国際規格とは異なる定義で、品質保証という言葉を使う動きがありました。これは戦後日本で発展した品質管理の方向性の中で成立した定義で、誤用や誤解に基づく定義の揺れではありません。
まず日本人が中心となって定義したSQuBOK（ソフトウェア品質の知識体系）から説明を引用します。
日本では品質保証という用語を『お客様が安心して使っていただけるような製品を提供するためのすべての活動』（飯塚悦功、超ISO企業実践シリーズ総論ＩＳＯを超える）『品質保証は品質管理の真髄である』（石川 馨、日本的品質管理～TQCとは何か）のように、顧客を満足させる活動を総称する意味で使うことが多い。
(日本では）顧客が「安心」「満足」「長く使用できる」ことを目的として品質保証が実施されるようになった。
これに対して、欧米では、契約社会という文化的背景から、品質保証していることの「実証」を重要視して発展してきたと考えられる。
※（）部分は本ブログでの補足追記
また「現代的品質管理総論」（飯塚悦功、永田靖）でも次のような解説を行っています。
顧客が満足する製品・サービスを提供すること、あるいはそのための活動を品質保証という。
海外由来でない日本の標準規格でも、この定義に従って標準化しているものがあります。例えばJISハンドブックでは品質保証に「消費者の要求する品質が十分に満たされていることを保証するために、生産者が行う体系的活動」という意味づけを行っています。
戦後日本で語られてきたこの品質保証の定義では、ユーザの要望を掘り起こすマーケティング活動や、クレーム処理、ユーザテストなども、品質保証活動に含まれます。完全な包含関係ではないですが、テスト活動の一部も品質保証活動に含まれます。
海外の標準規格と比べて、目指すものは似ていますが、その手段はズレがあり、「品質保証にテストが含まれるか」の解釈も変わります。
日本のソフトウェア業界での通例：テストエンジニアの上位職種
最後に、日本のソフトウェア業界の新興企業では、前述とは違う定義で「品質保証（QA）」の言葉を使用しています。そこでは、大まかに「ソフトウェアテストそのもの」あるいは「ソフトウェアテストの上位の活動」という意味で品質保証（QA）の言葉を使用しています。
例えば既存のQAエンジニアの募集要項を引用します。
https://cybozu.co.jp/recruit/entry/career/qa-engineer.html
プロダクトのQA担当者としていずれかの製品を担当していただきます。
- テスト計画、テスト設計、テスト実施
- リファインメントや振り返りへの参加
- テスト効率化および自動化
- 開発・テストプロセスの改善提案と実行推進
書かれている通り、ソフトウェアテストの仕事に対して、QAという呼び名を使用しています。
上記の引用先の企業に限らず、他の日本の新興のソフトウェア開発企業でも、この「品質保証（QA）≒テスト」の意味づけが広く見られます。
こういった業界的なQAの意味づけは、大まかな方向性ですが、「リリースできる品質を実現していると判断するのが品質保証」→「その手段が主にテスト」→「そのため品質保証≒テスト」という思考ロジックで使われることが多い印象を持ちます。
また従来のテストエンジニアよりも難しい・よりスコープが広い・職位が高い仕事であることを表現する方向性で使われる場面も増えています。
この「難しい・よりスコープが広い・職位が高い」の具体例は複数あり、人や組織によってバラバラです。主要なものを以下に挙げます。
- テストだけでなく、レビューや品質メトリクス等を使って、上流工程から品質を作りこむ（より職務のスコープが広い）
- テストに限らず、品質の確保と確認にかかわる作業全般を担当する（テスト以外の業務も担当する）
- 与えられた作業指示通りテストするのでなく、自らテスト要求を分析して必要なテストを実現する（受け身の作業者でなく、テスト全般の責務を主体的に果たしていく）
- 現場のテスト設計を横断的に分析し、改善して、より高度なテストを導く（上級テストアナリストである。組織横断的業務である）
- 開発チームのテストより独立性をもってテストを行い、開発チームが見逃した不具合や品質リスクを取りきる（既存のテストエンジニアより独立性が高い）
- テストの計画、マネジメントを担う（上級テストマネージである）
- ユーザが求めるニーズに精通し、本当に必要な品質要求を特定してそれを実現する支援を行う（テストエンジニアに加えてドメインスペシャリストでもある）
【余談】日本のソフトウェア業界での通例が生まれた背景
余談ですが、ソフトウェア業界でQA≒テストの意味づけが慣用的に広まった背景として、二つの事情があると考えます。
一つ目の事情は、リリースのためのクオリティゲートの役割の高度化です。
近年のソフトウェア開発では、次の要因から、リリース前のテストの高度化が進んでいます。
- 外部のSaaSを組み合わせるなど製品が複雑化する一方で、リリースの高頻度化・開発の高速化が進展。複雑な製品に対し、限られた時間でテストし、リリースできる品質を確保できているか判断しなければならなくなった。
- 品質を確認する責務がチーム全体に分散（例：自動テストを組み込んだCIで開発者もテストの責務を担う）。テストチームが最終段階で徹底的に品質確認するアプローチでなく、他の工程・他の職種と連携しながらテストする全体最適のアプローチが一般化した。
その結果「テストを主軸にリリースのための高度な品質確認を行う役割」の需要が高まってきました。
その中で、標準規格を気にしないまま「品質を保証する（QA）」の字面のニュアンスが単純に合っていると判断して、この役割をQAエンジニアと呼び始めた人が少なくないと感じます。そしてこの役割の需要増大に伴って、このQAエンジニアの呼称が業界に増えてきたのではと考えています。
二つ目の事情は、日本の一部で昔から次の考え方が根強くあることが影響していると思います。
- 本当はソフトウェアテストは難しい仕事である。現在テストの担当者は単価が低く技術的難易度の低い職種とよく見なされているが、本当は高度な技術力が求められる職種である
- 上記を業界的に知らしめるために、「高度な技術力が求められるテストの職種」に新しい職種名を付与して、既存の職種名（＝単価が低く技術的難易度の低い職種の象徴）と区別しよう
例えばテストを担う役職名として英語圏では「Tester」がよく使われています。日本国内では、それに合わせて「テスター」という名前を採用していました。ただ、日本国内では、低単価の第三者検証の急速な普及で、このテスターを「単価が低く技術的難易度の低い職種」とみなすネガティブイメージが業界で形成されました。
それに対し、2010年ごろから、ネガティブイメージを打破して「テストの担う役職は、テスト分析やテスト設計で高度な技術力が求められる職種」であると啓蒙するため、その職種に「テストエンジニア」「テスト担当者」という別の職種名を使う動きがテストのコミュニティや関連団体で生まれました。
一例として、筆者が技術委員として所属するJSTQBでも、この業界的流れに基づいて、英語の「Tester」は「テスター」と訳さず、すべて「テスト担当者」と訳すシラバス翻訳方針が作られました。
2020年頃から目立ってきたテストエンジニア→QAエンジニアの職種名の入れ替えも、このテスター→テストエンジニアの言葉の入れ替えの動きの延長線上にあるのではないかと思います。従来の低単価・低スキルな仕事（＝テストエンジニア※あくまで業界的な印象）と比べ、より高度でスコープが広い仕事（＝QAエンジニア）であることを示すために、QAの言葉を使い始めたということです。
三流派の定義の共存の弊害
以上、日本語圏の品質保証(QA)の定義の三流派をまとめて紹介したのですが、割と弊害がある状態だと思います。
というのも、明確に内容が違うものに対して、同じ名前を使っている結果、詳細情報を読まないと、QAが示す具体的内容を理解できない状態になっているためです。例えばQAエンジニアの募集についても、詳細な募集要項を見ないと具体的にどのような仕事なのか読み取れなくなっています
また、キャリアプラン的にも弊害があります。業界慣例のQA（実質テスト）と、国際規格のQAのキャリアパスは明確に違うためです。前者はテストエンジニアとして成熟すれば担える仕事です。しかし後者は、設計やプログラミングが妥当か、要求定義が妥当かといった問題を分析するために、上流工程の経験・能力も求められます。テストエンジニアの仕事だけしていれば担える仕事ではありません。
ただ、定義の揺れ・乱れの弊害性を認知する人も増えて、最近その定義を整理する動きも生まれています。例えばQMファンネルのような動きです。テストやQAにかかわるイベント、シンポジウムで活発に議論されていますので、「品質保証（QA）」の言葉を扱う人ならば、キャッチアップする価値はあると思います。
