誰も教えてくれないテスト自動化が普及しない理由（Zenn） が話題になりました。テスト自動化は「やった方がいい」と分かっていても、ツール導入だけで終わり、メンテされず、壊れたテストが放置され、やがて誰も信用しなくなる——多くの現場で繰り返される失敗です。記事は、普及しないのはツールの問題ではなく、運用・体制・文化の設計が欠けているからだと指摘しています。
一方で受託開発の現場では、「テストを書いたのに保守されず、CI が常に赤いまま放置され、結局手動テストに戻ってしまう」という事故が後を絶ちません。受託でシステム開発を支える立場では、これは 「自動テストを書くか」ではなく、「導入後も定着し、壊れず、運用に組み込まれた状態で引き渡せるか」を設計に組み込む課題だと捉えています。これまで k6 による負荷試験・性能保証受託（GH Media） で扱った 性能の品質保証、Playwright による AI QA 自動化受託（GH Media） で扱った 機能の自動検証、GitHub Actions サプライチェーン継続監査受託（GH Media） で扱った CI の継続運用と接続して、本記事では 「テスト自動化定着支援」を 受託パッケージとして整理します。
なぜ「いま」テスト自動化の「定着」なのか
| 観点 | 導入だけ（従来） | 定着まで設計（2026） |
|---|---|---|
| 目的 | ツールを入れる | 信頼できる安全網を作る |
| 対象選定 | 闇雲に全部 | 効果の高い箇所から |
| メンテ | 放置されがち | 運用に組み込み |
| CI 状態 | 赤いまま放置 | 常にグリーン維持 |
| 体制 | 担当者任せ | チームで維持 |
| 成果 | 形だけ | リリースの安心 |
つまり 「ツールを入れること」と「定着すること」は別物であり、受託でも 「普及しない理由を先回りで潰し、運用に組み込んだ状態で引き渡す」ことが品質の前提になりました。これにより 「壊れず・信頼され続けるテスト」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「全部自動化」から「効果の高い箇所から」へ
闇雲な自動化は保守コストで破綻します。受託では 重要・回帰しやすい箇所を優先し、費用対効果の高いテストから整備します。
構造 2: 「書いて終わり」から「運用に組み込む」へ
メンテされないテストは負債です。受託では CI 常駐・失敗時の対応フロー・担当の明確化まで設計し、壊れない運用を提供します。
構造 3: 「担当者任せ」から「チームで維持」へ
属人化は離任で崩れます。受託では 書き方規約・レビュー・教育を整え、チーム全体で維持できる文化を引き渡します。
受託で提供する「テスト自動化定着支援」5 フェーズ
フェーズ 1: 現状診断（1 週間）
- 既存テスト / CI の棚卸し（赤い放置の有無）
- 手動テスト工数とバグ流出の把握
- 自動化の費用対効果が高い領域の特定
- 体制・スキルの確認
フェーズ 2: 戦略・対象設計（1 週間）
- テストピラミッド方針（単体 / 結合 / E2E）
- 優先対象の選定と目標カバレッジ
- ツール選定（言語 / フレームワーク）
- CI 組み込み・失敗時フローの設計
フェーズ 3: 実装・整備（2〜3 週間）
- 優先領域のテスト実装
- CI への組み込みと安定化（flaky 対策）
- テスト書き方規約・サンプルの整備
- 失敗時の通知・対応フロー構築
フェーズ 4: 定着・教育（1〜2 週間）
- チーム向けの書き方・運用レクチャー
- レビューでテストを必須化
- 壊れたテストの即時対応運用の確立
フェーズ 5: 継続運用（継続）
- カバレッジ・成功率の定期モニタリング
- flaky テストの継続的な改善
- 新機能へのテスト追加運用
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 単体 | Vitest / Jest / pytest | JUnit |
| 結合 | Testing Library / Supertest | 各 FW のテスト |
| E2E | Playwright | Cypress |
| 負荷 | k6 | Gatling / Locust |
| CI | GitHub Actions | GitLab CI |
| 可視化 | カバレッジ / 成功率レポート | Allure |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 改修頻度が高くデグレが怖い | ほぼ更新しない静的サイト |
| 手動テスト工数が膨らんでいる | ごく小規模で目視で十分 |
| 複数人で活発に開発する | 一人で短期に作り切る |
| 長期運用する基幹システム | 短命な検証用 |
| 過去に自動化が定着しなかった | 既に安定して定着済み |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 自動化する領域 | 優先順位の合意 |
| 品質目標 | カバレッジ / 成功率 | 目標水準 |
| CI 運用 | 常駐 / 失敗時フロー | 通知体制 |
| 定着支援 | 教育 / 規約 | 自社で維持する前提 |
| 引き渡し | 規約 / Runbook | 保守体制 |
| 継続保守 | flaky 改善 / 追加 | 運用費用 |
価格モデル — テスト自動化定着支援パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| テスト診断 | 30 万円〜 | 1 システム | 棚卸し + 戦略レポート |
| 導入パッケージ | 120 万円〜 | 中規模 | 実装 + CI + 規約 |
| 定着支援 | 200 万円〜 | チーム横断 | + 教育 + 運用確立 |
| Lite 保守 | 8 万円〜 / 月 | 小規模 | flaky 対応 + 軽微追加 |
| Standard 保守 | 20 万円〜 / 月 | 中規模 | + 定期モニタ + 改善提案 |
顧客側 ROI 試算（業務システム / デグレ削減想定）
| 項目 | 既存（手動 / 放置） | テスト自動化定着 | 差分 |
|---|---|---|---|
| 回帰テスト工数 | 毎回手動で膨大 | 自動で削減 | 工数の継続的削減 |
| バグ流出 | リリース後に発覚 | 事前に検知 | 障害対応の削減 |
| リリース頻度 | 怖くて出せない | 安心して出せる | 開発スピード向上 |
| 改修の安心感 | 壊す不安が常時 | 安全網で安心 | 開発生産性向上 |
| 年間効果 | — | — | 回帰テスト工数の削減 + バグ流出による障害の抑制 |
導入パッケージ（120 万円〜）でも、毎リリースの手動回帰テスト工数削減とバグ流出 1 件の回避で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 全部を一気に自動化する
保守コストで破綻します。効果の高い箇所から始めます。
落とし穴 2: flaky テストを放置する
不安定だと誰も信用しません。安定化を最優先します。
落とし穴 3: CI の赤を放置する
常時赤は無意味化します。常にグリーンを維持します。
落とし穴 4: 担当者一人に任せる
離任で崩れます。チームで維持する体制を作ります。
落とし穴 5: 導入だけで定着を設計しない
放置されて元に戻ります。運用と教育まで設計します。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | テスト / CI 棚卸し + 対象選定 |
| Week 2 | 戦略策定 + ツール選定 |
| Week 3〜5 | 優先領域の実装 + CI 安定化 |
| Week 6〜7 | 教育 + レビュー必須化 |
| Week 8〜13 | モニタリング + 継続運用開始 |
まとめ — 「導入して放置」から「定着させて引き渡す」へ
テスト自動化が普及しないのはツールの問題ではなく、運用・体制・文化の設計が欠けているからです。受託でシステム開発を支える立場では、効果の高い箇所から実装し、CI に組み込み、flaky を潰し、教育と規約で定着させて引き渡す 「テスト自動化定着支援」が、壊れず信頼され続けるテストを成果物として届ける新しい主力サービスです。
弊社ではテスト診断 / 導入パッケージ / 定着支援 / Lite / Standard の各段階で本パッケージを提供しています。「テストを入れたのに保守されない」「CI が赤いまま放置されている」「手動回帰テストに疲弊している」というご相談は お問い合わせフォーム からお気軽にどうぞ。
