テスト工数を削減できない理由｜テストマネージャーが説明できる「削る基準」の作り方
- AIソリューション
- ソフトウェアテスト・品質保証
Introduction
「品質は落とさず、テスト工数を20%削ってほしい」。PMなど意思決定者から急に求められても、「何かあったら怖いので削れません。」では通りません。一方で、根拠のない削減はただのリスク先送りです。
テスト工数の見直しが止まるのは、現場の判断力が足りないからではありません。多くの場合、「何を残し何を削り、何を効率化し、何を保留するか」の判断材料が整理されていないことが原因です。
テストマネージャーは多くの現場では意思決定者ではなく、情報提供者です。必要なのは、1人で削減の正解を出すことではありません。意思決定者がリスクと工数のトレードオフを見て判断できるように、材料をそろえることです。
この記事では、テスト工数削減の議論を前に進めるために、次の内容を解説します。
•テスト工数を削減できない主な理由
•テストケースを削減する前に確認すべき3つの視点
•「残す・削る・効率化・保留」に仕分ける判断基準
•AIを使って、意思決定者に説明できる見直し表を作る方法
•テストマネージャーが意思決定を進めるための実務上のポイント
目次
テスト工数を削減できない理由
テスト工数を削減できない理由は、単にテストケース数が多いからではありません。本質的な原因は、「削ってよいもの」と「残すべきもの」の基準が曖昧なまま議論していることです。
判断基準がない状態では、関係者はリスクを引き受けられません。
その結果、以下のような状態になりやすくなります。
・どのテストケースが重要なのかわからない
・ケースを削った場合にどんなリスクが出るのかが見えない
・PM・開発・QAがそれぞれ異なる観点で判断し、情報と認識が揃わない
テスト工数削減で最初に必要なのは、テストケースを削るだけの作業ではありません。
まずは、削る／削らないの判断材料を整理することです。
テスト工数削減は3ステップで進める
テスト工数削減は、次の3ステップで進めます。
1.判断材料を集める
テストケース、プロジェクト、関係者の3つの視点で情報を整理します。
2.方針を仮置きする
対象ごとに「残す・削る・効率化・保留」へ分類します。
3.判断論点を提示する
意思決定者が判断すべきリスクや保留条件を明確にします。
ポイントは、最初から削減可否を決めにいかないことです。
まずは「判断できるもの」と「判断材料が足りないもの」を分けます。
削減判断に必要な3つの視点
テスト工数を見直すときは、次の3つの視点で判断材料を整理します。
| 3つの視点 | 確認する判断材料 | 判断ポイント |
|---|---|---|
| テストケース視点 | 優先度、テスト網羅率、トレーサビリティ、過去障害との紐づき | 残すべきケース、重複・形骸化したケースを見分ける |
| プロジェクト視点 | 事業影響、許容できない不具合、削減時に残るリスク | 削ってよい範囲、残すべき防御線、保留すべき対象を判断する |
| 人的視点 | 開発・QA・PMが持つ情報、未確認事項、責任者 | 判断材料が揃っているか、誰に確認すべきかを明確にする |
※トレーサビリティとは、「そのテストがどの要件・仕様変更・不具合履歴に紐づいているか」を説明できる状態です。紐づきが不明なテストは、削減または効率化の候補になります。
「残す・削る・効率化・保留」に仕分ける
3つの視点で集めた情報をもとに、見直し対象を4つに分類します。
| 見直し方針 | 判断の意味 | 例 |
|---|---|---|
| 残す | 品質判断に必要なため、実行対象に残す | 決済、認証、重要導線、過去障害に紐づくケース |
| 削る | 重複・形骸化しており、削減候補にできる | 同じ観点を複数回確認しているケース、根拠が不明なケース |
| 効率化 | 実行自体は残すが、頻度や方法を見直す | 毎回実行をやめる、自動化する、代表ケースに絞る |
| 保留 | 判断材料が不足しており、現時点では決めない | 事業影響、変更影響、許容リスクが未確認のケース |
重要なのは、「削る」だけを削減策にしないことです。品質上残すべきテストでも、毎回フル実行する必要がない場合はあります。たとえば、重要機能のテストは残しつつ、実行頻度を下げる、代表ケースに絞る、自動化するなどの方法があります。この場合は「削る」ではなく「効率化」として扱います。
判断材料が足りないものは、無理に削りません。「保留」とし、誰が何をいつまでに確認すれば判断できるのかを明確にします。
AIを使ってテスト工数見直し表を作る
ここまで整理した情報は、AIに渡して「テスト工数見直し表」のたたき台にできます。
ただし、AIに削減可否を決めさせるのではありません。
AIの役割は、次の3つです。
・判断材料を表形式に整理する
・不足情報や未確認事項を見える化する
・意思決定者に判断してほしい論点を整理する
AIに渡す情報は、最初からきれいな資料でなくても構いません。
議事録、チャット、テストケース一覧、リリースメモなどから、次の情報を貼り付けます。
・見直し対象の一覧
・今回の変更内容やリリース対象
・過去の不具合履歴や気になっているリスク
・PM・開発・QAが持っている判断材料
・未確認事項、回答待ちの内容
AIに渡す時の注意点
このとき、「重要」「影響が大きい」「リスクが高い」といった曖昧な表現だけで渡すと、AIの整理結果も曖昧になります。可能であれば、売上影響、CV影響、過去障害、変更影響、利用頻度など、判断に使える情報を具体的に書きます。
たとえば、次のように書き換えます。
・「重要な機能」⇒「購入完了に関わる機能」
・「影響が大きい」⇒「売上・CVに影響する可能性がある」
・「リスクが高い」⇒「過去3か月で同じ領域の障害が2件発生している」
・「変更影響あり」⇒「APIレスポンス項目と画面表示ロジックに変更がある」
AIに渡す情報を具体化しておくと、「残す・削る・効率化・保留」の根拠が明確になり、上位層やPMに説明しやすい見直し表を作りやすくなります。
インプット例
■テスト工数議論 議事録メモ
– 対象：会員ランク表示、ヘルプ画面、注文履歴一覧
– テストケース視点：会員ランク表示は優先度未整理 / ヘルプ画面は重複あり / 注文履歴一覧は毎回実行
– プロジェクト視点：会員ランク表示の事業影響は未確認 / ヘルプ画面の影響は小さい / 注文履歴一覧は重要だが効率化余地あり
– 人的視点：会員ランク表示の変更影響は開発回答待ち / ヘルプ画面はPM確認済み / 注文履歴一覧はQAと開発で効率化認識あり
この程度のメモでも、見直し対象ごとに方針を仮置きできます。
重要なのは、完璧な情報を集めることではなく、判断できるものと未確認のものを分けることです。
プロンプト例
あなたは、テスト工数見直しの判断材料を整理するテストマネージャー支援アシスタントです。
以下の情報をもとに、意思決定者に説明できる「テスト工数見直し表」のたたき台を作成してください。
目的：
– テスト工数の見直し議論を前に進める
– 判断材料が足りない箇所を明確にする
– 見直し方針を「残す・削る・効率化・保留」のいずれかで仮置きする
– 意思決定者に判断してほしいことを明確にする
整理の視点：
1.テストケース視点
– 優先度 / 変更影響 / トレーサビリティ / 重複や形骸化の有無
2.プロジェクト視点
– 不具合発生時の事業影響 / 許容できる不具合の範囲 / 工数削減時に残るリスク / リリース判断に必要な防御線
3.人的視点
– 各ロールが持っている情報（開発/ QA / PM） / 判断材料の有無と内容 / 確認すべきキーマン
出力形式：
以下の列を持つ表形式で出力してください。
|見直し対象 | テストケース視点での根拠 | プロジェクト視点での根拠 | 人的視点での確認事項 | 見直し方針（残す / 削る / 効率化 / 保留） | 意思決定者に判断してほしいこと（期限・保留条件）|
出力ルール：
– 不足情報がある場合は「未確認」と書いてください。
-保留の場合は、解除条件と期限も入れてください。
入力情報：
[ここに、インプット情報を貼る]
アウトプット例：テスト工数見直し表
AIに3つの視点の情報を渡すと、このような「テスト工数見直し表」が出力されます。
この表で見るべきなのは、AIが出した方針そのものではありません。重要なのは、各対象について次の情報がそろっているかです。
・なぜその方針なのか
・何が未確認なのか
・誰がいつまでに判断するのか
・判断後に、残す・削る・効率化のどれに進むのか
※以下は実際の出力例
| 見直し対象 | テストケース視点 | プロジェクト視点 | 人的視点 | 見直し方針 | 意思決定者に判断してほしいこと |
|---|---|---|---|---|---|
| 会員ランク表示 | 優先度未整理でテスト網羅性・必要性の判断不可 / トレーサビリティ未確認 | 事業影響が未確認のため削減リスク評価不可 | 開発から変更影響の回答待ち / QA側の重要度認識未整理 | 保留 | 影響度（売上・顧客体験）の位置づけ明確化（期限：開発回答後即日〜2営業日以内） / 影響大の場合は残す、軽微なら削減検討 |
| ヘルプ画面 | テストケース重複あり / 一部形骸化の可能性高い | 事業影響は小さいため不具合許容度が比較的高い | PM確認済み（低重要認識） / QAで重複整理可能 | 削る（必要に応じて効率化） | 削減許容ラインの明確化（どの程度まで未検知許容か）（期限：本スプリント内） |
| 注文履歴一覧 | 毎回実行されており回帰対象として固定化 / 重複・過剰網羅の可能性あり | 重要機能のため品質担保必須 / ただし工数効率化余地あり | QA・開発で効率化認識あり（自動化・観点削減の余地） | 効率化 | 効率化手段の採用可否（自動化投資・回帰頻度低減）（期限：次回リリース計画確定まで） / 最低限担保すべき防御線の定義（例：クリティカルパスのみ必須実行） |
意思決定者に情報を伝えるときのまとめ方
AIが返した「テスト工数見直し表」は、そのまま提出するものではありません。たたき台として使い、人間がレビューしながら、不足情報の補完、表現の調整、判断論点の明確化を行い、上位層やPMに出せる形に仕上げます。
見直すときに確認したいのは、主に次の3点です。
・根拠に抜けや飛躍がないか
・保留の条件や期限が具体化されているか
・意思決定者に判断してほしいことが、提案型で明確になっているか
AIは整理まで、人間は提出物として仕上げるところまでを担います。
テストマネージャーの役割は、削ることではなく判断材料をそろえること
テスト工数削減というと、テストケースを減らすことに意識が向きがちです。しかし、テストマネージャーの役割は、単独で削減可否を決めることではありません。
テストマネージャーが担うべき役割は、大まかに次の3つです。
・テスト対象の優先順位と実施方針を整理する
・工数削減によって残る品質リスクを見える化する
・意思決定者がリスクとコストを比較できる形で論点を整理する
この役割を明確にすると、工数削減の議論は「QAが削るかどうか」ではなく、「プロジェクトとしてどのリスクを取るか」という意思決定に変わります。
まとめ
テスト工数削減は、テストケースを単純に減らしたり、優先度を下げたりするだけの作業ではありません。「テストケース視点」「プロジェクト視点」「人的視点」の3つで判断材料を整理し、対象ごとに「残す・削る・効率化・保留」に仕分けながら進める意思決定プロセスです。判断材料が不足しているものは、無理に削る必要はありません。保留にして、誰が何をいつまでに確認すれば判断できるのかを明確にします。
テストマネージャーに求められるのは「情報提供」であり、削減の正解を1人で出すことではありません。
関係者がリスクと工数のトレードオフを見て判断できるように、判断材料を整理し、意思決定に必要な論点を明確にすることです。
価値の高いケースをスピーディに回す―「ネムラナイ」サービス
テスト工数見直し表で判断材料をそろえると、「何を削れないか」ではなく、「どのテストを優先して守るべきか」も見えてきます。
そのときに次の論点になるのが、整理で見えてきた価値の高いテストを、誰が・いつ・どう回すかです。
SHIFT AIテストセンター「ネムラナイ」 は、AIエージェントが24時間体制でテストを実行するサービスです。回帰テスト（リグレッションテスト）の負荷が集中しやすいプロジェクトでも、価値の高いテストケースを、SHIFTの品質基準に沿って、スピーディに回せる体制づくりの選択肢になります。
▶「ネムラナイ」 のサービス詳細・お問い合わせはこちら
https://contents.shiftinc.jp/nemuranai/
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
