QA（品質保証）とは？QCとの違いとQAエンジニアの仕事内容

2026 8/08

2026年8月8日

ソフトウェア開発の現場で「QA」という言葉を聞く機会が増えました。求人票には「QAエンジニア募集」と書かれ、社内では「QAチームに見てもらおう」という会話が飛び交います。

QAが具体的に何をする役割なのか、QC（品質管理）やテストと何が違うのか。これを正確に説明できる人は多くありません。

IT業界に入ったばかりの方が最初につまずくのが、「QAはQ&A（質問と回答）の略ではないか」という誤解です。FAQページの「Q&A」と字面が似ているため、無理もありません。

ソフトウェア開発におけるQAは、Quality Assurance（品質保証）の略です。質問と回答とは関係がありません。本記事で扱うQAは、すべて品質保証の意味です。

この記事では、QAの定義、QC・テストとの違いを整理します。QAエンジニアの仕事内容、近接職種との役割分担、QA組織の作り方も扱います。

品質を測る指標、「内製すべきか外部委託すべきか」の判断基準まで、実務で使える粒度でまとめます。読み終えたときに、自社のQA体制に足りないものが、見えている状態を目指します。

QA（品質保証）とは何か

QAの定義：「不良を作らない仕組み」を作る活動

QA（Quality Assurance＝品質保証）とは、製品やサービスが要求された品質を満たすことを、組織的な仕組みによって保証する活動のことです。

ISO 9000では品質保証を、「品質要求事項が満たされるという確信を与えることに焦点を合わせた品質マネジメントの一部」と定義しています。

ここで重要なのは「確信を与える」という表現です。QAの成果物は、良い製品そのものではありません。「この製品は良いと言える根拠」です。

もう少し実務的に言い換えます。QAは「欠陥を見つけて直す」活動ではなく、「そもそも欠陥が生まれにくい開発プロセスを設計し、運用し、改善し続ける」活動です。

バグを1件見つけることには価値があります。同じ種類のバグが二度と作り込まれないよう、レビュー観点を標準化する。こちらのほうが、QAの本質に近い仕事です。

「品質」とは何を指すのか

品質を「バグがないこと」と捉えている限り、QAの活動範囲は狭くなります。ソフトウェア品質のモデルとして、ISO/IEC 25010が広く参照されます。ここでは品質を、次の特性に分解して定義しています。

機能適合性：仕様どおりに正しく動くか
性能効率性：応答時間やリソース消費が妥当か
使用性・互換性：ユーザーが迷わず操作でき、他システムやブラウザ・OSと共存できるか
信頼性・セキュリティ：障害が起きにくく回復でき、不正アクセスやデータ漏えいを防げるか
保守性・移植性：修正や機能追加、別環境への移行がしやすいか

QAが保証すべきなのは、これら全体です。「機能テストは通ったがレスポンスが10秒かかる」「動作はするが業務フローに合っていない」。こうした状態は、機能適合性だけを見れば合格でも、品質としては失格です。

品質特性ごとに、どのテストで確認するのか。システムテストの種類一覧も、あわせて確認してください。

なぜ今、QAの重要性が高まっているのか

QAという概念自体は、製造業で長い歴史を持ちます。ソフトウェア開発では、ここ数年で急速に重視されるようになりました。背景には次のような環境変化があります。

リリース頻度の増加：年数回のリリースから週次・日次のリリースへ移行し、「リリース前にまとめて品質を確認する」やり方が物理的に成り立たなくなりました。
障害の影響範囲の拡大：1件の不具合が数万〜数百万ユーザーに同時に影響し、SNSでの拡散によってブランド毀損へ直結します。
システムの複雑化：マイクロサービス、外部API連携、マルチデバイス対応により、単体では正しくても組み合わせると壊れるケースが増えました。
手戻りコストへの意識：要件段階の欠陥を運用フェーズで直すコストは、要件段階で直す場合の数十倍から百倍以上とされます。早期に品質へ介入する経済合理性が広く認識されるようになりました。

QAは「余裕があればやること」ではありません。開発速度を落とさずにリリースし続けるための、必須インフラになりました。

QAとQC（品質管理）の違い

QAを理解するうえで最も重要なのが、QC（Quality Control＝品質管理）との違いです。日本語ではどちらも「品質」から始まる言葉で、現場では混同されがちですが、目的も、対象も、時間軸も、責任の持ち方もまったく異なります。

一言でいうと「検査」か「仕組み」か

もっとも短く両者を区別するなら、次のようになります。

QCは「作られたものを検査して、不良を取り除く」活動。
QAは「そもそも不良を作らない仕組みを作る」活動。

QCの視点はプロダクト指向です。目の前にある成果物が基準を満たしているか、それを判定します。

QAの視点はプロセス指向です。その成果物を生み出した開発プロセスが、期待する品質を安定して生み出せる構造か。ここを見ます。

工場の比喩を使うと、わかりやすくなります。ライン末端で製品を1つずつ検品し、規格外品をはじくのがQCです。

検品データを分析し、「この工程の温度設定が原因で不良が出ている」と特定する。工程の標準作業手順を改訂し、不良の発生源を断つのがQAです。

QCをいくら強化しても、不良率そのものは下がりません。QAが機能すれば、不良率が構造的に下がります。

QAとQCの違い比較表

比較項目	QA（品質保証）	QC（品質管理）
英語表記	Quality Assurance	Quality Control
目的	不良を作らない仕組みを作る	不良を市場に流出させない
指向	プロセス指向（作り方を見る）	プロダクト指向（成果物を見る）
対象	開発プロセス、標準、体制、教育	成果物（コード、実行ファイル、画面）
時間軸	企画・要件定義から運用・改善まで全工程	主に実装後〜出荷前の検査工程
アプローチ	予防的（Prevention）	検出的（Detection）
主な活動	標準策定、レビュー、プロセス監査、メトリクス設計、改善提案	テスト実行、検査、不具合報告、合否判定
成果物	品質計画書、標準・ガイドライン、品質レポート	テスト結果、不具合票、検査記録
問いの立て方	「なぜこの欠陥が生まれたのか」	「この成果物に欠陥はあるか」
責任の範囲	組織全体の品質水準に対する責任	担当した検査対象に対する責任
効果の現れ方	中長期的・構造的（欠陥の発生率が下がる）	即時的・局所的（今回の不良が止まる）

どちらか一方では成立しない

誤解してはならないのは、「QAが高度でQCが低級」という話ではないことです。QCがなければ、実際の成果物が基準を満たしているか確認できません。いくらプロセスを整えても、確認する手段がないからです。

QAがなければ、QCは毎回同じ種類の不良を見つけ続けます。検査コストが下がりません。

QCが現在の出荷を守り、QAが将来の不良を減らす。この役割分担が両輪として回っている状態が理想です。

日本のソフトウェア業界では、「QA」という言葉が2通りに使われます。活動を指す場合と、職種・部門を指す場合です。「QAをしっかりやろう」は活動、「QAに確認してもらう」は部門にあたります。

文脈で読み分ける必要があります。

QAとテストの違い：テストはQAの一手段にすぎない

現場で最も頻繁に起きている混同が、「QA＝テスト」です。QAチームがテストばかりしている組織は、珍しくありません。それはQA機能の一部だけが実装されている状態です。

テストで分かるのは「欠陥があること」だけ

ソフトウェアテストには、広く知られた原則があります。「テストは欠陥があることは示せるが、欠陥がないことは証明できない」という命題です。テストケースをどれだけ積み上げても、実行していない条件に欠陥が潜む可能性は消えません。

「テストを全部通したから品質は保証されている」。この主張は成り立ちません。

品質を保証するには、テスト結果に加えて一段上の説明が必要です。「どういう考え方でテスト範囲を決めたのか」「未テスト領域のリスクをどう評価したのか」「そもそも要件は正しかったのか」。この説明責任を担うのがQAです。

QAとテストの違い比較表

比較項目	QA（品質保証）	テスト
位置づけ	品質を保証するための活動全体	QAを構成する手段の1つ
目的	品質が要求水準にあることを説明できる状態を作る	欠陥を検出し、動作を確認する
介入する工程	企画・要件定義・設計・実装・テスト・運用	主に実装後のテスト工程（シフトレフト時は設計以降）
主な活動例	要件レビュー、品質基準の策定、メトリクス管理、プロセス改善、リリース判定	テスト設計、テストケース作成、テスト実行、不具合報告
扱う対象	プロセス・組織・成果物すべて	動作するソフトウェアおよびドキュメント
評価される成果	欠陥の作り込み率、流出欠陥数、リリース判断の的確さ	検出欠陥数、カバレッジ、テスト消化率
止められる問題	要件の誤り、設計の欠陥、プロセスの構造的問題	実装された成果物の中にある欠陥

QA ⊃ QC ⊃ テストの包含関係

ここまでの整理を1つの構造にまとめると、次のような入れ子構造になります。

QA（品質保証）：最も広い概念。品質方針の策定、開発標準の整備、プロセス監査、教育、メトリクス設計、リリース判定など、品質を保証するためのあらゆる活動を含む。
- QC（品質管理）：QAの一部。成果物が基準を満たしているかを検査・測定・判定する活動。
  - テスト：QCの中心的な手段。ソフトウェアを実際に動かして期待どおりかを確認する行為。

表にすると、それぞれのレイヤーが担う問いの違いがはっきりします。

レイヤー	答える問い	代表的なアウトプット	関与する職種
QA（品質保証）	この製品をリリースしてよいと、なぜ言えるのか	品質計画書、品質レポート、リリース判定記録	QAエンジニア、QAマネージャー、品質保証部門
QC（品質管理）	この成果物は基準を満たしているか	テスト報告書、検査記録、不具合一覧	テストマネージャー、QCエンジニア
テスト	この機能は仕様どおり動くか	テストケース、実行結果、不具合票	テストエンジニア、テスター、開発者

この構造を踏まえると、「テストは外部に委託し、QAの判断機能は自社に残す」という分業が合理的であることも見えてきます。この点は、記事後半の内製・外注の判断基準で詳しく扱います。

QAエンジニアの仕事内容

ここからは、QAエンジニアが実際に何をしているのか、見ていきます。組織によって守備範囲は異なりますが、成熟したQA組織では次の6領域が中核になります。

1. 要件・仕様のレビュー（最も費用対効果が高い仕事）

QAエンジニアの仕事のうち、最も投資対効果が高いのが上流工程でのレビューです。要件定義書や仕様書の段階で、次のような観点から曖昧さと矛盾を潰します。

テスト可能性：「快適に動作すること」のように検証できない記述になっていないか。数値と条件で書かれているか
網羅性：正常系だけでなく、異常系・境界値・同時実行・タイムアウト時の挙動が定義されているか
整合性：他機能や既存仕様と矛盾していないか。用語の定義がぶれていないか
影響範囲：変更が既存機能のどこに波及するか。移行データやバッチ処理への影響は考慮されているか
受け入れ基準：何をもって「完成」とするかが、開発者・企画・QAで同じ理解になっているか

この段階で1つの曖昧さを潰すことは、実装後の不具合を、数件から数十件減らすことに相当します。

レビューを属人的な指摘合戦にせず、体系立てて実施する。その方法はレビューとインスペクションによる品質作り込みで、解説しています。

2. テスト計画・テスト設計・テスト実行

QAエンジニアの中核業務であり、外部から最も見えやすい仕事です。単に「テストする」のではなく、次の順序で論理的に組み立てます。

テスト戦略の立案：プロダクトのリスクを洗い出し、どこに、どれだけテスト工数を配分するかを決める。全機能を等しくテストするのは無駄であり、障害時の影響度と変更頻度が高い領域に厚く配分する
テストレベルの定義：単体・結合・システム・受入の各レベルで何を保証するかを切り分ける。この切り分けの基本形がVモデルであり、開発工程とテスト工程の対応関係を設計する土台になる
テスト設計：同値分割、境界値分析、デシジョンテーブル、状態遷移テスト、組み合わせテストなどの技法を使い、少ないケース数で高い検出力を得る
テスト実行と記録：計画に沿って実行し、結果を再現手順つきで記録する
結果の分析：検出した欠陥を分類し、傾向から未発見の欠陥がありそうな領域を推測する

とくに5番目の分析が腕の見せどころです。欠陥は均等に分布せず、特定のモジュールに偏在します（欠陥の偏在）。「認証まわりに集中している」とわかれば、そこへテストを追加投入する判断ができます。

3. テスト自動化の推進

リリース頻度が上がるほど、手動テストの繰り返しは破綻します。QAエンジニアは、自動化の対象選定・実装・保守を担います。

自動化に向くもの：仕様が安定した回帰テスト、大量データを使う繰り返し検証、複数環境での同一シナリオ、APIレベルの検証
自動化に向かないもの：仕様が流動的な新機能、見た目や使いやすさの評価、実行回数が少ない例外シナリオ、探索的テスト

自動化の効果が最も大きいのは、回帰テスト領域です。機能追加のたびに、既存機能が壊れていないかを確認する。この作業は頻度が高く、内容も安定しています。

人手でやると膨大な工数を食います。回帰テストの範囲選定と自動化の考え方は、リグレッションテストの戦略にまとめています。

自動化は「作って終わり」ではありません。壊れやすいテスト（フレーキーテスト）を放置すると、失敗が日常になります。誰も結果を見なくなります。

自動化の成否は、書いた数では決まりません。信頼して見続けられる状態を、維持できているかで決まります。

4. 品質メトリクスの設計と可視化

「品質が良い／悪い」を感覚で語っている限り、改善は続きません。QAエンジニアは品質を数値で捉え、意思決定できる形に整えます。

設計時の原則は3つです。指標を必ず「何を判断するための数字か」とセットで定義すること。単一指標で評価せず、個人の人事評価にも使わないことです。

どの指標を使うかは、記事後半の「品質を測る指標」で詳述します。

5. 開発プロセスの改善とフィードバック

QAをQCから分ける決定的な仕事がこれです。検出した欠陥を「直して終わり」にせず、なぜその欠陥が作り込まれ、なぜ前工程ですり抜けたのかを分析し、プロセスに反映します。

典型的な進め方は次のとおりです。

流出した欠陥を原因工程（要件／設計／実装／テスト設計）に分類する
原因工程ごとの件数を集計し、最も多い工程を特定する
その工程の作業標準・チェックリスト・レビュー観点を見直す
改善後、同じ分類の欠陥が減ったかを次のリリースで確認する

ここで重要なのは「人を責めず、仕組みを疑う」姿勢です。「実装者の注意不足」で結論づけた瞬間に改善は止まります。注意力に依存している時点でプロセスの設計が甘い、と捉えるのがQAの発想です。

6. リリース判定（品質ゲート）

リリースしてよいかどうかの判断材料を揃え、判定に責任を持つのもQAの仕事です。判定は「バグゼロかどうか」ではなく、次のような複合条件で行います。

計画したテストが完了しているか（消化率と未実施の理由）
未修正の欠陥が、重要度別に許容範囲内か
残存リスクが特定され、回避策や監視体制が用意されているか
切り戻し手順が確認されているか

「リリースします」と言い切ることではなく、「この条件でリリースすると、こういうリスクが残る」と、経営やプロダクト責任者が判断できる材料を出すことがQAの責務です。

QAエンジニアと近接職種の違い

求人票や現場では、さまざまな呼称が混在しています。QAエンジニア、テストエンジニア、テスター、SDET、QAアーキテクトなどです。

企業ごとに定義が揺れるため、完全な統一は難しいところです。一般的な役割分担は、次のように整理できます。

職種	主な役割	関与工程	求められる中心スキル
テスター（テスト実行者）	作成済みのテストケースを実行し、結果を記録・報告する	テスト実行	正確性、再現手順の記述力、対象業務の理解
テストエンジニア	テスト設計技法を用いてテストケースを設計し、実行・分析まで行う	テスト設計〜実行	テスト技法、仕様読解力、欠陥分析
QAエンジニア	テストに加え、要件レビュー、品質基準の策定、メトリクス管理、プロセス改善を担う	要件定義〜運用（全工程）	テスト技法＋プロセス設計＋データ分析＋対人調整
SDET （Software Development Engineer in Test）	テスト自動化基盤やテスト用ツールを自ら開発し、開発と同水準のコードを書く	設計〜実装〜CI/CD	プログラミング、CI/CD、テストフレームワーク設計
QAアーキテクト	複数プロダクト横断で品質戦略・テストアーキテクチャ・標準を設計する	企画〜全社標準	アーキテクチャ理解、品質モデル、標準化、技術選定
QAマネージャー／テストマネージャー	要員計画、進捗・コスト管理、ステークホルダー調整、リリース判定の主導	計画〜判定	マネジメント、リスク管理、見積り、交渉

採用や委託を検討するときは、肩書きではなく「どの工程に、どの深さで関わってほしいのか」を先に定義してください。

同じ「QAエンジニア募集」でも、求めているものは違います。テスト実行の人手なのか、品質戦略を描ける人材なのか。必要な人物像も単価も変わります。

QAエンジニアに必要なスキルとキャリアパス

必要なスキルの全体像

QAエンジニアは「テストができる人」ではなく、技術・分析・対人という、3方向のスキルを同時に要求される職種です。どれか1つが欠けると機能しません。

スキル領域	具体的な内容	なぜ必要か
テスト技法	同値分割、境界値分析、デシジョンテーブル、状態遷移、直交表・ペアワイズ	限られた工数で検出力の高いケースを設計するため
ソフトウェア開発の知識	アーキテクチャ、データベース、API、ネットワーク、認証の仕組み	内部構造を理解しないと、リスクの高い箇所を推定できないため
プログラミング	1言語以上の実装力、テストフレームワーク、SQL、CI/CDの理解	自動化・ログ解析・テストデータ作成を自力で行うため
データ分析	欠陥の傾向分析、統計の基礎、可視化、指標設計	感覚ではなく根拠に基づいて品質を語るため
品質マネジメント	ISO/IEC 25010、プロセス改善、リスクベースの考え方	個別のテストを品質保証という文脈に接続するため
ドメイン知識	対象業務の商習慣、法規制、ユーザーの利用文脈	仕様どおりでも業務上おかしい、を検知するため
コミュニケーション	指摘の伝え方、合意形成、ドキュメント化、交渉	「品質を守れ」と「早く出せ」の対立を調整するため

とくに軽視されがちなのが、最後のコミュニケーションです。QAは構造的に「開発を止める側」に見られやすく、指摘の伝え方を誤ると対立構造が固定化します。

「この実装は間違っている」ではなく、「この条件でこう動きますが、要件のこの記述と食い違っています」。事実と根拠で語れることが、実務では技法の知識と同じくらい効きます。

資格名	概要	向いている人
JSTQB認定テスト技術者資格	国際資格ISTQBの日本版。Foundation Levelでテストの基本原則・プロセス・技法・管理を体系的に学べる。上位にAdvanced Levelがある	QA・テストに関わる全員（まず最初に取る資格）
JCSQE（ソフトウェア品質技術者資格認定）	日本科学技術連盟が実施。ソフトウェア品質知識体系（SQuBOK）に基づき、品質保証の考え方を幅広く問う	テストより一段広い品質保証の視点を身につけたい人
IVEC（IT検証技術者認定試験）	IT検証産業協会が実施。検証業務の実務レベルをClass1〜7で段階評価する	検証業務の実務スキルを客観的に示したい人
QC検定（品質管理検定）	製造業由来の品質管理手法（QC七つ道具、統計的手法）を問う	データに基づく品質改善の基礎を固めたい人

キャリアパス

QAエンジニアのキャリアは、大きく4方向に分岐します。

マネジメント方向：QAリーダー → QAマネージャー → 品質保証部門長。要員計画、予算、全社品質方針を担う
技術特化方向：SDET → テスト自動化アーキテクト。自動化基盤やテストインフラの設計・実装を担う
戦略・横断方向：QAアーキテクト → 品質コンサルタント。複数組織の品質プロセスを設計・改善する
プロダクト方向：プロダクトマネージャー、テクニカルサポートリード。品質とユーザー体験の知見を製品企画に活かす

QAエンジニアは、仕様・実装・ユーザー影響のすべてに触れます。プロダクト全体を最も俯瞰して理解している人材になりやすい職種です。

この視点は、プロダクトマネジメントや、技術戦略の職種でも高く評価されます。

QA組織の作り方：3つの体制と選び方

QAを担う人を採用しても、組織の置き方を誤ると機能しません。QA組織の形態は大きく3つに分類でき、それぞれに向き不向きがあります。

独立QAチーム型

開発部門から独立した品質保証部門を置き、開発チームの成果物を、第三者の立場で検証する体制です。金融、医療機器、公共システムなど、品質に対する説明責任が重い領域で採用されます。

Embedded QA型（開発チーム内包型）

各開発チームにQAエンジニアを1名以上配置し、スプリントの中で一緒に動く体制です。アジャイル開発やSaaSプロダクトで、主流になりつつあります。

ハイブリッド型（QA CoE＋Embedded）

各チームにQAを配置しつつ、横断的な品質標準・自動化基盤・教育を担う中核組織（CoE：Center of Excellence）を別に持つ体制です。プロダクト数が増えた組織の、到達点となることが多い形です。

比較項目	独立QAチーム型	Embedded QA型	ハイブリッド型
配置	開発から独立した部門	各開発チーム内に配置	各チーム配置＋横断CoE
強み	第三者性が高く、忖度なく品質を判定できる。標準の統一が容易	仕様理解が深く、上流から関与できる。フィードバックが速い	両者の利点を両立。標準を保ちつつ現場対応力も確保
弱み	開発との情報格差・対立が起きやすい。関与が後工程に偏る	開発への同化で第三者性が薄れる。チーム間で品質水準がばらつく	運営コストが高い。CoEと現場の役割分担が曖昧だと機能しない
向く開発手法	ウォーターフォール、大規模開発	アジャイル、スクラム、継続的デリバリー	複数手法が混在する中〜大規模組織
向く業界・領域	金融、医療、公共、組込み、認証が必要な領域	SaaS、Webサービス、スマホアプリ	複数プロダクトを持つ事業会社
必要な人数の目安	開発規模に応じた専任部隊	開発者5〜8名あたりQA1名程度	Embedded＋CoE数名
導入しやすさ	中（既存部門から移行しやすい）	高（1名から始められる）	低（一定の組織規模が前提）

フェーズ別の現実的な選び方

実務上は、組織の成熟度に応じて次のように段階を踏むのが現実的です。

QA専任がいない段階：まずは受け入れ基準の明文化と不具合の記録・分類から始める。いきなり大きな組織を作る必要はない
QA1人目を置く段階：Embedded型で開発チームに入れる。最初の仕事は品質の現状を可視化し、どこが弱いかを特定すること
プロダクトが複数になる段階：チーム間で品質水準がばらつき始めるため、標準・テンプレート・自動化基盤を共有する横断機能を検討する
説明責任が求められる段階：監査や大口顧客の要求が発生したら、第三者性のある検証プロセスを組み込む。外部の検証会社を使う選択肢が現実的になる

よくある失敗が、段階2を飛ばして「QA部門を立ち上げる」と宣言し、人手だけを集めてしまうケースです。何が弱いのかわからないまま人を増やしても、テスト実行の人数が増えるだけでQAにはなりません。

シフトレフトとQA

シフトレフト（Shift Left）とは、品質活動を開発工程の左側＝上流へ前倒しする考え方です。工程を左から右に並べた図で、テストを右端から左へ動かすイメージから、この名前がついています。

なぜ上流に前倒しするのか

理由は単純です。欠陥は発見が遅れるほど、修正コストが跳ね上がるからです。要件定義で矛盾に気づけば、直すのはドキュメントの数行です。

同じ問題を運用開始後に発見すると、実装の修正、テストのやり直し、データ移行、顧客への説明まで発生します。要件段階での修正コストを1とすると、運用段階では、数十倍から百倍以上になるとされています。

シフトレフトの具体的な打ち手

要件レビューへのQA参加：仕様が固まる前に、テスト可能性の観点でレビューする
受け入れ基準の事前定義：実装を始める前に「何ができたら完成か」を全員で合意する
テストケースの先行作成：実装前にテスト設計を行い、その過程で仕様の穴を発見する
静的解析とコードレビューの標準化：実行前にコード上の問題を検出する
CI上での自動テスト実行：コミットのたびに回帰テストを走らせ、壊れた瞬間に検知する

Vモデルは、シフトレフトを設計に落とし込むうえで、有効な枠組みです。開発工程とテスト工程を対応づけると、「要件定義に対応するのは受入テスト」「基本設計に対応するのはシステムテスト」と紐づきます。

各工程でどのテストを設計しておくべきかが、明確になります。詳細はVモデルの基礎と実践的な使い方を参照してください。

シフトレフトだけでは足りない

近年は「シフトライト」も併用されます。本番環境でのモニタリング、カナリアリリース、障害の即時検知など、リリース後に品質を確認・回復する仕組みです。

どれだけ上流を固めても、本番でしか起きない事象は必ず存在します。QAの守備範囲は「リリースまで」ではなく、「運用中も含めた製品ライフサイクル全体」です。

QAで品質を測る指標（メトリクス）

QAが「感想」ではなく「保証」であるためには、品質を数値で語れる必要があります。ここでは実務でよく使われる指標を、計算方法と使いどころ、注意点とあわせて整理します。

指標	計算方法	何が分かるか	注意点
欠陥密度（Defect Density）	検出欠陥数 ÷ 規模（KLOC、機能数、画面数など）	どのモジュールに欠陥が集中しているか。追加テストの投入先の判断材料	規模の測り方を統一しないと比較できない。値の大小だけでは「よくテストされた」のか「品質が悪い」のか判別できない
欠陥除去率（DRE：Defect Removal Efficiency）	リリース前検出欠陥数 ÷（リリース前検出欠陥数＋リリース後検出欠陥数）× 100	開発工程内でどれだけ欠陥を捕まえられているか。QA活動の総合的な有効性	リリース後の欠陥が出そろうまで確定しない。集計期間を決めて運用する
エスケープ欠陥（流出欠陥）	リリース後に本番環境で検出された欠陥の件数・重要度別内訳	顧客に届いてしまった品質問題の実態。QAの最重要指標のひとつ	件数だけでなく「なぜすり抜けたか」の原因工程分析とセットで使う
テストカバレッジ	実行された要素数 ÷ 全要素数 × 100（命令網羅C0、分岐網羅C1、条件網羅C2など）	テストがコードや仕様のどこまで到達しているか。未検証領域の把握	100%でも品質は保証されない。「通過した」ことしか示さず、検証内容の妥当性は測れない
テスト消化率	実行済みテストケース数 ÷ 計画テストケース数 × 100	テスト工程の進捗状況	進捗指標であり品質指標ではない。消化を急ぐと形骸化する
欠陥摘出曲線（信頼度成長曲線）	累積検出欠陥数の時系列推移をプロット	検出ペースが収束しているか。テスト完了判断の材料	収束の見た目は、テスト密度が落ちただけでも作れてしまう
再発率	修正後に再発した欠陥数 ÷ 修正欠陥数 × 100	修正品質と回帰テストの有効性	「同一欠陥」の定義を先に決めておく
平均修復時間（MTTR）	欠陥の検出から修正完了までの平均所要時間	不具合対応プロセスの応答性	重要度別に分けて見ないと平均値に意味がなくなる

まず見るべき2つの指標

指標をいきなり全部揃える必要はありません。QAを立ち上げる段階でまず取るべきは、エスケープ欠陥（流出欠陥）と欠陥除去率の2つです。

この2つは「顧客にどれだけ迷惑をかけたか」と「開発内でどれだけ止められたか」を直接表します。QA活動の価値を、そのまま示す指標です。カバレッジや消化率は、この2つを改善するための、補助指標と位置づけてください。

カバレッジ指標には、C0（命令網羅）・C1（分岐網羅）・C2（条件網羅）があります。それぞれの違いと、どこまでを目標に設定すべきか。テストカバレッジC0・C1・C2の解説記事で、詳しく扱っています。

指標運用でやってはいけないこと

メトリクスは扱い方を誤ると、品質を上げるどころか下げます。とくに次の3点は避けてください。

個人の人事評価に使う：検出欠陥数を評価対象にすると些細な指摘が量産され、混入欠陥数を評価対象にすると欠陥が報告されなくなります。数値が測定対象を歪める典型例です
単一指標を目標値にする：「カバレッジ80%必達」とすると、アサーションのないテストが増えます。指標は複数を組み合わせ、傾向で読むものです
他プロジェクトと単純比較する：規模の定義、欠陥の定義、テストの厳しさが違えば数値は比較できません。比較は同一プロジェクトの時系列で行うのが原則です

欠陥を数える前提として、「バグ」「欠陥」「故障」「エラー」といった用語の定義が、チーム内で揃っていることも重要です。用語がぶれると集計結果もぶれます。この整理はバグ・欠陥・故障・エラーの違いで扱っています。

QAは内製すべきか、外部に委託すべきか

QA体制を整えようとしたとき、企業が直面するのが「自社で人を採るか、外部に任せるか」という判断です。結論から言えば、この問いは二者択一ではなく、QA機能をレイヤーごとに分けて考えるべき問題です。

判断の基本方針：判断は残し、実行は分ける

記事の前半で整理した「QA ⊃ QC ⊃ テスト」の構造を思い出してください。この3層は、外部化のしやすさが大きく異なります。

QA層（品質方針・リリース判定・プロセス改善）：事業判断と密接に結びつくため、自社に残すのが原則
QC層（検査・合否判定）：基準さえ明確なら外部でも実施できる。むしろ第三者性が価値になる
テスト層（設計・実行）：最も外部化しやすい。工数変動が大きい領域でもあり、変動費化のメリットが大きい

内製と外部委託の比較

判断軸	内製（自社QA）	外部委託（テスト代行・第三者検証）
コスト構造	固定費。採用・教育・離職リスクを含む	変動費。必要な時期・量だけ使える
立ち上げ速度	採用に数か月、戦力化にさらに数か月	数週間で着手できることが多い
ドメイン知識	蓄積される。業務理解が深い	初期はキャッチアップが必要。継続委託で蓄積される
第三者性	低い。開発と近すぎると忖度が生まれる	高い。仕様の暗黙の前提を疑える
繁閑への対応	弱い。閑散期に余剰、繁忙期に不足が生じる	強い。リリース前だけ増強できる
ノウハウの蓄積先	自社に残る	成果物（テスト設計書等）の納品で自社に残せる
向いている状況	プロダクトが長期継続、品質が事業の中核、専門人材を確保できる	リリース前の一時的な増員、第三者視点が必要、QA専任がいない

外部委託を検討すべき5つのサイン

次のいずれかに当てはまる場合、外部の力を借りたほうが早く、結果的に安く済むことが多いです。

開発者がテストを兼務している：自分が書いたコードを自分でテストすると、思い込みの盲点がそのまま残ります。実装した本人が想定した条件しか試されないためです
リリース直前だけ人手が足りない：年間を通じて必要ではない工数のために正社員を採用するのは、コスト構造として合いません
回帰テストが機能追加のたびに膨らんでいる：手動の回帰テストは、機能が増えるほど線形以上に工数を食います
本番障害が繰り返し発生している：内部の視点だけでは、すり抜けた理由の構造が見えません
顧客や監査から品質の説明を求められている：第三者による検証記録は、社内資料より説明力があります

委託を成功させるための条件

外部委託が失敗する原因のほとんどは、委託先の能力ではなく依頼側の準備不足です。最低限、次の3つは自社側で用意してください。

合否の基準：何をもって「正しい」とするか。仕様書が不完全なら、優先度の高い部分だけでも明文化する
スコープと優先順位：全機能を均等にテストするのではなく、どこが最も壊れてはいけないかを伝える
窓口と判断者：仕様の解釈に迷ったときに即答できる担当者を決めておく。ここが詰まると検証が止まります

QAのリソース不足は『テスター10』で解決できます

ここまで読んで、「QAの重要性はわかったが、実行する人がいない」と感じた方も多いのではないでしょうか。実際、私たちがご相談をいただく企業の多くが、次のような状態にあります。

QA専任がおらず、開発者がリリース直前に手分けしてテストしている
テスト工数が読めず、毎回リリースが後ろ倒しになる
回帰テストの範囲が年々膨らみ、確認しきれないまま出している
本番で不具合が出るたびに火消しに追われ、原因分析まで手が回らない
QAエンジニアを採用したいが、市場に人がおらず、採用単価も上がり続けている

これらはいずれも、「品質への意識が低い」のではなく「実行するリソースが構造的に足りない」から起きている問題です。意識を高めても人は増えません。必要なのは、必要なときに必要な量だけ、品質検証の力を足せる仕組みです。

テスター10（テスターテン）とは

ソフトウェアテスト代行サービス『テスター10』は、第三者検証サービスです。機能テスト・システムテストをはじめとする、ソフトウェアテストを10万円からご依頼いただけます。

専任のQA組織を持たない企業でも、必要な工程だけをスポットで委託できます。

よくあるお悩み	テスター10でできること
QA専任がいない	テスト計画・テスト設計・実行まで一括で代行。QA機能を外から補完します
開発者の自己テストに限界がある	第三者の視点で仕様の暗黙の前提を洗い出し、内部では気づけない欠陥を検出します
リリース前だけ人手が足りない	必要な期間・必要な量だけスポットで増強。固定費を増やさずに対応できます
回帰テストの工数が膨らんでいる	回帰テストの範囲を再設計し、優先度に応じた実行計画に組み替えます
テスト設計のノウハウが社内にない	テスト設計書を成果物として納品。次回以降は自社でも運用できる資産になります
まず小さく試したい	10万円からの小規模案件に対応。1機能・1画面単位からご相談いただけます

ご依頼の流れ

ヒアリング：対象システム、リリース時期、現在の課題、重視する品質特性をお伺いします
ご提案・お見積り：テストの範囲、レベル、想定工数、成果物をご提示します
テスト設計：仕様をもとにテスト観点とテストケースを設計し、事前に内容をご確認いただきます
テスト実行・報告：実行結果、検出した欠陥、再現手順、リスク評価をレポートとしてご報告します

「まず何から手をつけるべきかわからない」という段階のご相談も歓迎しています。QAリソースの不足や、第三者検証の必要性を感じている方は、テスター10のサービスページより、お気軽にお問い合わせください。

QA（品質保証）に関するよくある質問

Q. QAとQ&Aは違うものですか？

まったく別のものです。ソフトウェア開発における「QA」は、Quality Assurance（品質保証）の略です。製品の品質を組織的に保証する活動や、それを担う職種・部門を指します。

「Q&A」はQuestion and Answer（質問と回答）の略で、FAQページなどで使われます。求人票や社内チャットで見かける「QA」は、ほぼ確実に品質保証の意味です。

Q. QAとQCの違いを一言で説明すると？

QCは「作られたものを検査して不良を取り除く」プロダクト指向の活動、QAは「そもそも不良が生まれない仕組みを作る」プロセス指向の活動です。QCが今回の出荷を守るのに対し、QAは将来の不良発生率そのものを下げます。両者は対立関係ではなく補完関係で、どちらか一方だけでは品質は安定しません。

Q. QAエンジニアとテストエンジニアはどう違いますか？

関与する工程の広さが違います。テストエンジニアは、テスト設計から実行までを担当します。QAエンジニアはそれに加えて、要件・仕様のレビュー、品質基準の策定、品質メトリクスの管理、開発プロセスの改善、リリース判定まで担います。

テストはQAの手段の1つです。QAエンジニアは「テストもする人」と捉えると、実態に近くなります。

Q. QAエンジニアにプログラミングスキルは必須ですか？

必須ではありませんが、あるほど活動範囲が広がります。テスト自動化、ログ解析、テストデータ生成、CI/CDへの組み込みでは、コードを書く場面が増えます。SDETを目指す場合は、開発者と同水準の実装力が求められます。

要件レビューやプロセス改善が中心の役割であれば、実装力より、仕様読解力・分析力・調整力のほうが効きます。

Q. テスト自動化を導入すればQAエンジニアは不要になりますか？

なりません。自動化できるのは「何を確認すべきかが、すでにわかっているテスト」だけです。

何を確認すべきかを決めること、リスクの高い領域を見極めること、仕様の矛盾を発見すること。自動テスト自体を設計・保守することも、人の仕事です。

自動化はQAエンジニアを置き換えません。繰り返し作業から解放し、より上流の仕事に集中させるための手段です。

Q. QA専任がいない小規模チームは何から始めればよいですか？

いきなり体制を作るのではなく、次の3つから始めてください。第一に、機能ごとの受け入れ基準を明文化すること。第二に、発生した不具合を記録し、原因工程で分類すること。

第三に、その分類結果をもとに、最も欠陥が生まれている工程を1つだけ改善すること。この3つを回すだけで、専任者がいなくてもQAの中核が動き始めます。「予防のループ」です。

人手が足りない工程だけを外部委託で補うのも、有効な選択肢です。

Q. QAを外部に委託すると、社内にノウハウが残らないのでは？

成果物の受け取り方を設計しておけば残せます。テスト観点表・テスト設計書・実行結果・欠陥分析レポートを、納品物として明示的に依頼してください。これらは次回以降、自社でも再利用できる資産になります。

「テストをやってもらう」だけの依頼にすると、実行の記録しか残りません。委託の目的を「人手の確保」ではなく、「品質資産の獲得」と定義するのがポイントです。

まとめ

本記事の要点を整理します。

QA（Quality Assurance＝品質保証）は、品質要求が満たされることを組織的な仕組みで保証する活動。Q&A（質問と回答）とは無関係
QCは「作られたものを検査する」プロダクト指向、QAは「不良を作らない仕組みを作る」プロセス指向。QCが現在の出荷を守り、QAが将来の不良を減らす
テストはQAの一手段にすぎない。QA ⊃ QC ⊃ テストという包含関係で捉えると、各活動の役割が明確になる
QAエンジニアの仕事は6領域：要件レビュー、テスト計画・設計・実行、テスト自動化、品質メトリクス管理、プロセス改善、リリース判定
QA組織には3形態ある：独立QAチーム型、Embedded QA型、ハイブリッド型。開発手法と業界特性で選ぶ
まず測るべき指標はエスケープ欠陥と欠陥除去率。カバレッジや消化率は補助指標であり、単体を目標値にしない
内製と外注は二者択一ではない。品質判断は自社に残し、テストの設計・実行は外部化する分業が現実的

QAは、専門部署を作らなければ、始められないものではありません。「見つけた欠陥を直して終わりにせず、なぜ生まれたのかを問い、仕組みに反映する」。この一点を実行し続けることが、規模を問わずQAの本質です。

その仕組みを回すには、人と時間が要ります。QAリソースが足りない、第三者の視点で一度見てほしい、リリース前だけ検証の手を増やしたい。そうした課題をお持ちの方もいるはずです。

機能テスト・システムテストを、10万円からご依頼いただけます。ソフトウェアテスト代行サービス『テスター10』に、ご相談ください。

現状の体制をお伺いしたうえで、内製すべき部分と委託が効く部分の、切り分けからご提案します。

次に読むならこの記事

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する

よかったらシェアしてね！