qa-metrics

無効化されたテストが800件、フレーキーなテストが200件ある4,000件のテストスイートは、スライド上では健全に見えても、本番環境では実態を偽ります。このスキルでは、実際に行動を変える指標を定義します。各指標には計算式、目標値、担当者、そして値が赤信号になったときの具体的な対応を定めるため、ダッシュボードが飾りではなくフィードバックループになります。

クイックガイド

状況	確認する指標	セクション／リファレンス
まだ指標がない。何から始めればよいか	コードカバレッジ、フレーキーテスト率、欠陥流出率	基本原則 + references/rollout.md
カバレッジが高いのにバグが流出する	欠陥流出率 + ミューテーションスコア	カバレッジ指標、欠陥指標
テストが不安定で、開発者がCIを無視している	フレーキーテスト率、合格率	テスト健全性指標
パイプラインが遅く、フィードバックが古い	テストスイートの実行時間、並列化効率	実行指標
自動化への投資を正当化したい	自動化のROI	プロセス指標
チームの段階に合った目標を選びたい	企業の成長段階別の表	現実的な目標の設定
リーダーシップがデリバリーと品質の両方を求めている	DORA + 欠陥流出率	エンジニアリング品質指標（DORA）
ダッシュボードを構築したい	（qa-dashboard へ）	—

---

確認事項

まず .agents/qa-project-context.md を確認してください。存在する場合は、そこに記載された内容を基盤とし、すでに回答されている項目はスキップしてください。その後、以下を確認します。

現状

• 現在、どのような指標を追跡していますか？（「ときどきCIの合格率を確認する」だけでも該当します。）
• テストデータはどこにありますか？（CIシステム、カバレッジレポート、バグトラッカー、スプレッドシート、どこにもない）
• すでにダッシュボードはありますか？誰が、どのくらいの頻度で見ていますか？
• CIパイプラインではどのようなツールを使っていますか？（GitHub Actions、GitLab CI、Jenkins、CircleCI）

ステークホルダー

• 品質指標のステークホルダーは誰ですか？（エンジニアリング、プロダクト、リーダーシップ、顧客）
• それぞれが重視していることは何ですか？エンジニアはフレーキーテスト率、リーダーシップは欠陥流出の傾向、プロダクトチームはリリースへの信頼性を重視します。
• 各指標の担当者は誰ですか？担当者がいなければ、誰も対応しません。

品質上の問題

• どのような品質上の問題を可視化する必要がありますか？（リグレッション、遅いパイプライン、フレーキーテスト、カバレッジのギャップ、インシデント）
• 最近、本番環境で何が問題になりましたか？指標があれば、もっと早く検知できましたか？
• 現在、データなしでどのような意思決定をしていますか？

目標

• チームにとって「健全なテストスイート」とはどのような状態ですか？
• コンプライアンスや契約上の品質要件はありますか？（SLA、SOC2、ISO）
• すぐに実現できる改善と、完全なオブザーバビリティのどちらを目指しますか？指標を支えるインフラへの意欲はどの程度ありますか？

---

基本原則

1. 指標はダッシュボードの飾りではなく、行動につなげるものです

対応計画のない指標は飾りです。すべての指標について、どのしきい値で対応を開始するのか、どのような対応を取るのか、誰が実行するのかを定めてください。フレーキーテスト率が5%を超えた場合、その週のオンコールエンジニアが、特に不安定な上位3件のテストを調査します。曖昧さを残してはいけません。

2. 先行指標と遅行指標の両方を追跡し、先行指標に対応します

欠陥流出率とMTTRは遅行指標です。ユーザーに被害が及んだ後で初めて状況がわかります。フレーキーテスト率、カバレッジの増減、スキップされたテストの件数は先行指標です。問題が起こる前に、欠陥の流出を予測できます。遅行指標は、品質がどの方向に進んでいるかをリーダーシップに伝えます。先行指標は、エンジニアが日々注視するべきものです。結果がまだ変えられるからです。

3. 単一時点の値ではなく、推移を見ます

単一の数値だけでは、ほとんど意味がありません。カバレッジが72%というだけでは何もわかりませんが、3回のスプリントで68%から72%へ上昇したという推移は、状況を物語ります。指標は時系列で表示し、絶対値ではなく変化の方向を評価してください。

4. すべての指標に目標値と担当者が必要です

目標値があれば指標を行動につなげられ、担当者がいれば責任の所在が明確になります。どちらか一方でも欠けると、指標は背景ノイズになります。チームの成熟度に応じて目標値を設定し（目標値の表を参照）、実際に数値を改善できる担当者を割り当ててください。

5. 見栄えだけのメトリクスは、全員の時間を無駄にします

「テストが4,000件あります」と聞くと印象的ですが、そのうち800件が無効化され、200件が不安定だとわかれば話は別です。重要なものを数えましょう。実行され、安定して合格し、実際のバグを検出するテストです。最終的な指標は、ユーザーがビジネスに損害を与えるバグに遭遇しているかどうかです。そこから逆算してください。欠陥流出率はユーザー体験に直接つながりますが、テストコードの行数は何にもつながりません。

---

必須のQAメトリクス

各メトリクスには、定義、計算式、推奨目標、重要な理由、数値が悪化した場合の対応を記載します。

テストカバレッジメトリクス

システムのどれだけが自動テストで検証されていますか？（先行指標）

コードカバレッジ率

自動テストで実行されたコードの割合です（行、分岐、またはステートメント単位）。

Line coverage   = (lines executed by tests / total executable lines) × 100
Branch coverage = (branches executed by tests / total branches) × 100

目標： アプリケーションコードの行カバレッジ：70～85％。分岐カバレッジ：60～75％。重要なパス（決済、認証）：90％以上。

重要な理由： カバレッジによって見落としが明らかになります。テストで一度も実行されていないコードは、バグが検出されずに潜んでいる可能性があります。

数値が悪化した場合： PRでカバレッジが低下した場合は、マージをブロックするか警告します。重要なモジュールで低い場合は、対象を絞ったタスクを作成します。横ばいの場合は、デッドコードなのか、実際にテストされていないロジックなのかを確認します。

注意： カバレッジが測定するのはコードの実行であり、アサーションの品質ではありません。より実態に即した状況を把握するには、ミューテーションテスト（StrykerJS v9.6+、mutmut）と組み合わせてください。Stryker の Vitest ランナーは最近の Vitest リリースを追跡しています。Vitest のバージョンを固定する前に、ランナーのピア依存関係を確認してください。モノレポのCIでは incremental: true を使用し、ミューテーションテストの実行コストを抑えてください。詳しいカバレッジ／ミューテーション分析については、coverage-analysis を参照してください。

要件カバレッジ率

Requirement coverage = (features with at least one test / total features) × 100

目標： P0/P1 の機能は100％、P2 は80％以上。

重要な理由： 周辺コードのカバレッジが高くても、機能自体にテストがまったくない場合があります。追跡可能性を確保するため、テストタグ（@feature:checkout、@story:PROJ-1234）を使用してください。

リスクカバレッジ率

Risk coverage = (high-risk areas with automated tests / total high-risk areas) × 100

目標： 高リスク領域で95％以上。リスク登録簿を管理し、モジュールごとにカバレッジデータと相互参照してください。

---

テスト健全性メトリクス

テストスイートを信頼できますか？（先行指標）

不安定率

コードを変更していないにもかかわらず、テスト実行の結果にばらつきが生じる割合です。

Flakiness rate = (test runs with flaky results / total test runs) × 100

目標： 許容範囲：2％未満。警告：2～5％。重大：5％超。

重要な理由： 不安定なテストは信頼を損ないます。開発者が「たぶん不安定なだけ」と考えるようになると、結果にまったく注意を払わなくなります。不安定さは、テストスイートの信頼性に対する最大の脅威です。

数値が悪化した場合： 不安定なテストはただちに隔離してください。毎週、上位3件を調査します。不安定さの大半は、少数のテストに起因します。よくある原因は、タイミング／競合状態、共有状態、外部依存関係、実行順序に依存するテストです。30日以上不安定なテストは、削除するか書き直してください。

検出： Buildkite Test Analytics、Datadog Test Optimization（旧称 Datadog CI Visibility。Flaky Test Management、Auto Test Retries、Early Flake Detection、Failed Test Replay、Test Impact Analysis を提供します。また、Bits AI Dev Agent を使って不安定なテストを修正するPRを自動で作成できます）、Trunk Flaky Tests、または同じコミットでの実行結果を比較するスクリプトを使用します。

合格率の推移（7日間の移動平均）

Pass rate = (green CI runs / total CI runs) × 100  [rolling 7 days]

目標： 健全：95％超。警告：90～95％。機能不全：90％未満。

7日間の移動平均によって日々の変動が平滑化され、実際の傾向が明らかになります。ビルドが継続的に失敗していると、開発者はパイプラインを無視するようになります。

無効化・スキップされたテストの数

skip、disabled、pending、xit、xdescribe、または同等の指定がされたテストの総数です。

目標： ゼロを目指します。2スプリント以上前からスキップされているテストは、修正するか削除してください。スキップされたテストの割合が全テストの5％を超えた場合に失敗するCIステップを追加してください。

重要な理由： スキップされたテストは、見えないカバレッジの抜けです。合格したテストが500件、スキップされたテストが150件あるテストスイートでは、ダッシュボードには表示されない 150 / (500 + 150) = 23% の抜けがあります。

テストスイートの所要時間

スイートの開始から完了までの実時間です。

目標： ユニット：<5 分。統合：<10 分。E2E：<15 分。全パイプライン：<30 分（実際の予算は各ステージの目標値です。<30 分はその合計であり、別途緩い基準ではありません）。

重要な理由： テストが遅いとフィードバックループが機能しなくなります。結果が出るまで45分かかると、開発者はすでに別の作業に切り替えています。

赤信号になった場合： 最も遅いテストをプロファイリングします（実行時間の50％を占めるのは、テストの10％であることがよくあります）。並列度を上げます。遅いテストはマージ後に実行します。不要なセットアップ／ティアダウンがないか確認します。所要時間を時系列でグラフ化し、急な変化（1週間で20％超の増加）があればアラートを出します。

---

欠陥メトリクス

ユーザーより先にバグを検出できているでしょうか？（遅行指標）

欠陥流出率

本番環境で見つかった欠陥が、発見された欠陥全体に占める割合です。

Defect escape rate = (defects found in production / total defects found) × 100

目標： 優秀：<5％。許容範囲：5～10％。要改善：10～20％。危険：>20％。

計算例： あるリリースで欠陥が合計15件見つかり、そのうち2件が本番環境で発見された場合、2 / 15 × 100 = 13.3%の欠陥流出率となり、「要改善」に該当します。

重要な理由： 最も重要な品質メトリクスです。テストによってユーザーより先にバグを検出できているかを直接測定します。

赤信号になった場合： 流出した欠陥をレイヤー別（ユニット？統合？E2E？レビュー？）に分類します。それぞれに対して、振り返り用のテストを作成します。流出が特定の領域に集中していないかを特定します。そうした領域には、重点的な投資が必要です。

追跡方法： 本番環境のバグにescaped-defectラベルを付けます。スプリントの振り返りで、リリース前の欠陥と流出した欠陥を数えます。

平均解決時間（MTTR）

MTTR = sum(resolution_time for each defect) / number of defects

目標： P0：<4 時間。P1：<24 時間。P2：<1 スプリント。P3：<2 スプリント。

MTTR が長い場合、技術的な難しさではなく、プロセス上のボトルネック（レビューの遅さ、責任範囲の不明確さ、複雑なデプロイなど）を示していることがよくあります。ボトルネックを見つけるために、トリアージ、担当者の割り当て、修正、デプロイの各フェーズに分けて確認します。（これは QA における欠陥の解決時間であり、以下の DORA の復旧メトリクスとは異なります。）

欠陥密度

Defect density = defects found / KLOC  (or per feature shipped)

目標： 独自のベースラインを追跡します。業界のベンチマークは KLOC あたり1～10件の欠陥です。あるモジュールの密度がほかのモジュールの5倍なら、リファクタリングまたはカバレッジの改善が必要です。

重大度の分布

健全な状態：P0 <5％、P1 10～15％、P2 40～50％、P3 30～40％。積み上げ棒グラフで時系列を可視化します。P0／P1 の割合が高い場合、テストで重大な問題を見逃しています。

---

実行メトリクス

CI パイプラインは高速で、信頼性が高く、費用対効果に優れているでしょうか？（先行指標）

CI パイプラインの所要時間

ステージごとの実時間の合計です。目標： Lint：<2 分。ユニット：<5 分。統合：<10 分。E2E：<15 分。全体：<30 分（上記の各ステージの合計と一致し、スイート所要時間の予算とも整合していること）。

赤信号になった場合： 最も遅いステージから最適化します。高速チェック（プッシュごと）と低速チェック（PR のマージ時）を分けます。セットアップ時間と実行時間をプロファイリングします。順次実行されているステージを並列化します。

CI の1回あたりのコスト

CI cost per run = (compute minutes × cost per minute) + fixed costs

1日あたり50ビルドを1回$0.50で実行すると、月額$750になります。依存関係をキャッシュし、スポットインスタンスを使用し、ランナーのサイズを適正化し、変更のないスイートをスキップして最適化します。

並列化効率

Parallelism efficiency = (total sequential time / (wall-clock time × workers)) × 100

目標： >80％。例：4つのワーカーがそれぞれ3分、3分、3分、12分で完了する場合、実時間は12分、逐次実行した場合の合計は21分となるため、効率は21 / (12 × 4) = 44%です。3つのワーカーがそれぞれ9分間アイドル状態になるため、目標を大きく下回ります。ファイル数ではなく推定所要時間に基づいて分割し、遅いテストファイルを分割し、動的な分割（Playwright のシャーディング、Jest の--shard）を利用して改善します。

---

プロセスメトリクス

QA プロセスは時間とともに改善しているでしょうか？（先行指標と遅行指標の両方）

自動化率

Automation rate = (automated test cases / total test cases) × 100

目標： 回帰テスト：90％以上。スモークテスト：100％。探索的テスト：0％（定義上）。全体：70～85％。

手動テストではスケールしません。自動化の効果は積み重なります。一度作成すれば、テストは何千回も実行されます。まず、最も頻繁に実行されるシナリオを自動化します。

テスト作成速度

スプリントごとに追加された新しい自動テストの数（リファクタリングを除いた純増数）。

目標： リリースしたユーザーストーリーごとに、少なくとも3～5件の自動テストを作成します。機能が20件あり、新しいテストが0件のスプリントは、カバレッジの不足が拡大していることを示しています。

自動化の ROI

Manual cost     = (manual time per cycle × cycles per year) × hourly rate
Automation cost = (write time + annual maintenance) × hourly rate
ROI             = (manual cost - automation cost) / automation cost × 100

例： 手動での回帰テスト：1 リリースあたり 8 時間 × 年 26 回のリリース × 75 ドル/時間 = 年間 15,600 ドル。自動化：作成に 120 時間 + 年間保守に 40 時間 × 75 ドル/時間 = 初年度 12,000 ドル、以降は年間 3,000 ドル。初年度の ROI：(15,600 - 12,000) / 12,000 = 30%。2 年目の ROI：(15,600 - 3,000) / 3,000 = 420%。この数値を使って、ステークホルダーに投資の妥当性を説明してください。

---

エンジニアリング品質指標（DORA）

DORA 指標は、リーダーシップ向けのデリバリーダッシュボードで標準的に使われる用語です。これらは欠陥流出率と組み合わせて使います。DORA はデリバリーのスループットを追跡し、QA 指標はデリバリーの品質を追跡します。

指標	測定内容	ベンチマーク（上位 15%）
変更のリードタイム	コミット → 本番環境	1 日未満
デプロイ頻度	リリースの頻度	1 日に複数回
デプロイ失敗からの復旧時間（旧称 MTTR）	変更に起因する障害後にサービスを復旧するまでの時間	1 時間未満
変更失敗率	インシデントを引き起こすデプロイの割合	約 5%（以前の「高パフォーマー」の基準は 15% 未満）
手戻り率	以前の不適切なデプロイに対する、計画外の修正デプロイの割合	低く、低下傾向

DORA 2025 では、5 つ目の指標として手戻り率が正式に定義され、指標群が再編されました。上記の最初の 3 つはスループットです（復旧時間がここに移動したのは、高速なチームほど修正をすぐにリリースするためです）。変更失敗率と手戻り率は不安定性を表します。信頼性（可用性、レイテンシ、SLO に対するエラーバジェット）は別の軸として併せて追跡します。エラー率と可用性は、流出した欠陥がユーザーに与える影響の末端にあたるため、QA／欠陥流出の観点と SRE が交わる領域です。DORA 2025 では、従来の「エリート／高／中／低」という名称付きの階層も廃止され、パーセンタイル分布と 7 つのチーム類型に置き換えられました。この列は、自分が「どの階層に属するか」ではなく、パーセンタイルのベンチマークとして読んでください。デプロイ失敗からの復旧時間への名称変更（2023 年／2024 年のレポート）は、変更に起因する障害と外部障害を区別するためのものです。これは、上記の QA 欠陥 MTTR とは別のデリバリー指標です。

出典：https://dora.dev/research/。Git／CI データから DORA 指標を表示するツール：Sleuth、Faros、LinearB、Jellyfish、Swarmia。

テスト影響分析（TIA）を活用する

TIA は、変更されたコードに基づいて（カバレッジデータを使用して）実行するテストを選択します。テスト範囲と CI コストを引き換えにします。次の項目を追跡してください。

• TIA によって PR ごとにスキップされたテストの割合 — 高いほど CI コストが低くなります。カバレッジを維持したまま割合が上昇しているなら、TIA の効果が出ています。
• スキップされたテストに起因する流出欠陥 — 安全性を確認する指標です。ゼロでない場合は、TIA の選択範囲を狭めるか、常に実行するテストを増やしてください。

ホステッド型：Datadog Test Optimization（TIA）、CloudBees Smart Tests、NCrunch（IDE 内）。自社構築：カバレッジデータと git diff から算出します。coverage-analysis を参照してください。

---

現実的な目標を設定する

目標はチームの成熟度に合わせてください。シード期のスタートアップがエンタープライズ向け指標を追いかけても、労力が無駄になります。

指標	スタートアップ（シード〜シリーズ A）	成長期（シリーズ B〜C）	エンタープライズ（上場／大規模）
ユニットテストのカバレッジ	60%	75%	85%
分岐カバレッジ	45%	60%	75%
E2E カバレッジ（クリティカルパス）	上位 5 フロー	上位 15 フロー	すべての P0／P1 フロー
不安定率	5% 未満	3% 未満	1% 未満
合格率（7 日間）	90% 超	95% 超	98% 超
欠陥流出率	20% 未満	10% 未満	5% 未満
MTTR（P0）	8 時間未満	4 時間未満	2 時間未満
CI パイプラインの実行時間	20 分未満	15 分未満	10 分未満
自動化率	50%	75%	90%
追跡する指標	主要指標を 3〜5 個	ダッシュボード付きで 8〜10 個	アラート付きの全指標

段階的な進め方：

1. まずは 3 つの指標から始めます。コードカバレッジ、不安定率、欠陥流出率です。
2. CI コストや速度が課題になったら、実行指標を追加します。
3. エンジニアが 5 人を超えたら、プロセス指標を追加します。
4. 品質が製品の差別化要因またはコンプライアンス要件になったら、全指標を導入します。

段階的な導入計画（週ごと）、3 種類のダッシュボードレイアウト、データソース抽出表については、references/rollout.md と references/dashboards.md を参照してください。

---

アンチパターン

• カバレッジを品質の証明として扱うこと。 カバレッジが測るのは実行であり、検証ではありません。確かな結果を得るには、ミューテーションテストと組み合わせてください。
• 文脈のないメトリクス。 目標値（80％）、推移（69％から上昇）、内訳（重要なパスは92％、管理機能は40％）がなければ、「カバレッジは74％です」という情報に意味はありません。必ず目標値、推移、内訳を併記してください。
• メトリクスの数字合わせ。 カバレッジの数値を達成するために、些細なテストを追加することです。カバレッジと欠陥流出率を組み合わせて対策してください。カバレッジが高いのに欠陥が流出するなら、そのテストには実効性がありません。
• メトリクスが多すぎること。 25個を追跡しても、どれにも対応できません。まずは3個から始めてください。どのような対応につながるかを明確に説明できる場合にのみ、メトリクスを追加してください。
• 対応せずに測定すること。 誰も開かないGrafanaダッシュボードがその例です。四半期に1度も対応につながらないメトリクスは廃止してください（references/rollout.md のメトリクス半減期チェックを参照）。
• チーム間で比較すること。 決済サービスと管理ツールのカバレッジは比較できません。チーム間の順位ではなく、経時的な改善を追跡してください。

---

検証

重要なのは、機能するフィードバックループです。完了を宣言する前に、データが実際に流れることを確認してください。

1. カバレッジが機械可読な出力を生成する。 カバレッジツールを実行し、HTMLレポートだけでなく、JSON／LCOV（coverage/coverage-final.json、lcov.info）が書き出されることを確認してください。
2. CIの履歴を照会できる。 CIプロバイダーのAPIから直近7日間の実行結果を取得し、そこから成功率と不安定率を算出できることを確認してください。
3. 流出ラベルが存在する。 課題トラッカーで escaped-defect（または同等の）ラベルを検索し、少なくともラベル付けのルールが整備されていることを確認してください。
4. ゲートが実際にブロックする。 カバレッジを低下させるか、.skip を追加する一時的なPRを作成し、CIがそれを失敗として検出することを確認してください。発動しないゲートでは、何も証明できません。

---

完了条件

• 主要なメトリクスについて、カバレッジ率（行とブランチ）、不安定率、欠陥流出率、重大度別MTTRの明確な計算式が定義されている。
• 収集したデータを少なくとも2週間分用いて、各メトリクスのベースライン値が確立され、企業ステージ別の表に沿って目標値が設定されている。
• CI統合によってデータ収集が自動化されている（テストランナーからカバレッジ、CI実行履歴から不安定率、課題トラッカーのラベルから欠陥を取得）。手動作業は不要です。
• 不安定率がしきい値を超えた場合、カバレッジが低下した場合、または重要なテストが失敗した場合に、マージまたはデプロイをブロックする品質ゲートがCIに設定されている（失敗する一時的なPRで検証済み）。
• 各メトリクスに担当者が明記され、定期的なレトロスペクティブのテンプレート（または定例のカレンダー招待）にメトリクス欄が設けられている。意図だけでなく、確認可能な成果物がある。

参照ファイル（references/ 内）

• dashboards.md — エンジニアリング向け（日次）、リーダーシップ向け（月次）、スプリント健全性ダッシュボードのレイアウトと、リリース確信度スコアの重み付け例です。
• rollout.md — 4段階の週ごとの導入計画、データソース抽出表、メトリクス半減期に基づく廃止の実践方法です。

関連スキル

• qa-dashboard — これらのメトリクスを表示するAllure／Grafana／SaaSダッシュボードのUIを構築します。表示方法についてはこのスキルを参照し、測定対象については本スキルを参照してください。
• coverage-analysis — カバレッジのギャップとミューテーションスコアを詳しく扱います。本スキルのカバレッジメトリクスにおけるアサーション品質の入力情報です。
• ci-cd-integration — これらのメトリクスの基となる生データを生成するCIパイプラインを設定します。コスト削減策としてのTest Impact Analysisも含みます。
• release-readiness — go／no-goの判断に品質ゲートとDORAのChange Failure Rate／Failed Deployment Recovery Timeを利用します。
• test-reliability — 不安定率で検出されたテストの不安定さを、テストごとの実行時修復で解消します。
• quality-postmortem — アクション項目の完了率と欠陥流出率を、ポストモーテム側のメトリクスとして組み合わせます。
• qa-project-context — 目標値とベースラインをメトリクス追跡に提供します。