退行テスト工数を 90% 削減した実装パターン — 選別・自動化・運用の 3 層設計
「テスト工数が膨らみすぎて、リリースが詰まる」
「テストに時間を取られすぎて、肝心の開発が前に進まない」
そんな空気、現場で感じたことありませんか？私の周りでは、ほぼ毎四半期どこかで耳にしています。
機能追加のたびに退行テストで 2〜3 日が消える、テスト項目書がメンテされず必要なテストが分からない、自動化したいが何から手を付けるか決まらない——業務システムの現場でよく聞く声です。
私は過去のプロジェクトで 退行テスト工数を 90% 削減 した経験があります。本記事では、そのときの考え方を 選別・自動化・運用の 3 層 に分けて整理してみます。
前提: 自動化は「一回作って終わり」ではない
テスト自動化は単発プロジェクトでは失敗します。テストコードもプロダクトコード同様メンテされ続ける前提で設計しないと、半年後に壊れたテスト群だけが残ります。本記事の 3 層は次の重みです。
| 層 | 目的 | 比重 |
|---|---|---|
| 1. 選別 | 残すテスト・捨てるテストを決める | 30% |
| 2. 自動化 | 残したテストを実行可能な形にする | 40% |
| 3. 運用 | 壊れない・腐らない仕組みにする | 30% |
「自動化」だけでなく 選別と運用にも同等のエネルギーを割く のが鍵です。
第 1 層: 選別 — 残すテスト・捨てるテストを決める
既存のテスト項目書をそのまま自動化するアプローチはほぼ失敗します。形骸化テスト・粒度バラバラ・重複——この 3 点が混在しているためです。まずは 「捨てる」判断 から入ります。
残すテストの選別基準（4 つの観点）
| 観点 | 残す判断基準 |
|---|---|
| 重要度 | 業務影響が大きい機能（受注確定・請求計算・権限制御など）に紐づくか |
| 変更頻度 | 直近 1 年で 3 回以上修正された箇所か |
| 不具合実績 | 過去に重大不具合が出た領域か |
| 代替手段の有無 | 型・契約・スキーマで担保できる項目はテスト不要 |
この 4 観点でテスト項目書を棚卸し、残す候補を絞ります。私の経験では もとの項目数の 30〜40% に絞り込んでも、業務インパクトの大きい部分はほぼカバーできました。
「型で担保できることはテストしない」原則
必須項目の入力チェックは DB の NOT NULL とフォームバリデーション、型エラーは型システム、一意制約違反は DB UNIQUE 制約で担保すれば自動テスト不要。そもそも壊れない設計にする ほうが、長期メンテコストが下がります。
第 2 層: 自動化 — 何を、どのレベルで自動化するか
選別段階で残ったテストを、できる限り 下層（ユニットテスト）に寄せる のが自動化の鉄則です。E2E に寄せると実行時間と維持コストが指数的に増えます。
自動化対象を絞り込む 4 観点
| 観点 | 内容 |
|---|---|
| 対象の純粋性 | 副作用（DB / ファイル / API）が少ないコードから自動化 |
| 入出力の明確さ | 入力に対して出力が一意に決まるロジック |
| 修正頻度 | 修正されにくいコア部分（投資対効果が高い） |
| 失敗時の影響範囲 | 失敗が一発でわかる粒度で書く |
実務では ビジネスロジック層（DB / UI を分離した純粋関数）から手を付ける のが最速。Repository Pattern や Hexagonal Architecture で層を分離していれば、ここはテスト天国です。
手動テストを「止めない」段階移行
完全自動化を一気にやると品質が落ちます。手動テストを止めずに自動化テストを並行で増やす のが安全。Phase 1 (手動 100% + 自動化 0%) → Phase 2 (手動 100% + 自動化 30%) → Phase 3 (手動 50% + 自動化 60%) → Phase 4 (手動 10% + 自動化 80%) の順で進めます。並行期間に 二重実行で結果を突合 し、確認できた領域から手動を止めます。
第 3 層: 運用 — 壊れない・腐らない仕組み
CI に乗せる、毎コミットで走らせる
自動化テストは CI で毎コミット実行 が基本です。リリース前にまとめて実行する運用だと、すぐに壊れたテストが放置されます。
- GitHub Actions / GitLab CI / Jenkins いずれでも可
- 失敗したらマージブロック（強制）
- 実行時間は 目安 5 分以内。超えるならテスト分割や並列化を検討
カバレッジを「強制」する
カバレッジは ビルド失敗の閾値 として CI に組み込みます。たとえば「カバレッジ 80% 未満ならビルド失敗」のように。
カバレッジ 100% は不要。むしろ意味のないテストを増やす副作用がある。80% 前後で、テストが書かれていない箇所をレビューするほうが効果的。
テストコードもレビューする
プロダクトコードのレビューと同じレベルで、テストコードもレビューします。テストコードのレビュー観点:
- テスト名から「何をテストしているか」が読める
- 1 テストにつき 1 アサーション（原則）
- 壊れたときに原因がすぐに分かる粒度
- 実行が独立している（順序依存なし）
工数削減の実績と内訳
参考までに、私が関わった案件での内訳を紹介します。
| 段階 | 工数 | 効果 |
|---|---|---|
| Before（全手動） | 約 80 人時 / リリース | 基準値 |
| Phase 1（選別） | 約 40 人時 / リリース | −50%（不要テストを削減） |
| Phase 2（自動化） | 約 16 人時 / リリース | −80%（半分自動化） |
| Phase 3（運用安定） | 約 8 人時 / リリース | −90%（手動は重要箇所のみ） |
選別段階だけで 50% 減、というのが意外な発見でした。自動化に飛びつく前に、残すテストを絞る だけで効果が出ます。
さいごに
テスト工数削減は、ツール選定ではなく 設計と運用の問題 です。
- 選別: 全部自動化しない、捨てる勇気を持つ
- 自動化: ピラミッドの下層に寄せる、段階移行
- 運用: CI で毎コミット実行、カバレッジ強制、テストコードもレビュー
もし、いま手元のプロジェクトでテストの重さに困っているなら、まずは「残すテスト」を選ぶところから始めてみてはどうでしょうか。自動化に走る前のこの一歩で、景色がかなり変わります。
ユニットテスト自動化の取り組み事例 も合わせてどうぞ。
関連記事
- 「テスト工程が消滅した」— AI駆動開発 vs 従来開発を全工程で比較してみた — AI 駆動開発でテスト工程をさらに圧縮した話