テスト自動化の失敗はなぜ起きる？塩漬けからの立て直し方

テスト自動化の失敗は、担当者の能力不足ではなく組織・運用の構造から起きます。「せっかく自動テストを整備したのに、いつの間にか誰も回さなくなった」——そんな状況に心当たりはないでしょうか。導入まではこぎつけたものの、赤い（失敗した）テストが放置され、結局は手動テストに戻ってしまう。多くの現場で起きている、ごくありふれた出来事です。

この記事では、受託開発のPMに向けて、なぜこうした事態が起きるのかを組織・運用の構造から読み解き、塩漬け化した仕組みをどう立て直すかを整理します。フレームワークの選び方やコードの書き方といった実装の話には踏み込みません。焦点は「誰が、どう運用を続けるか」という体制の設計にあります。

自動化は、導入した瞬間がゴールではなく、そこからが運用のスタートです。ところが多くの現場では、導入のプロジェクトが終わると同時に関心も予算も引き上げられ、あとは現場任せになりがちです。この「導入で満足して運用を手放す」構造こそが、塩漬けの温床になります。PMがまず見るべきは、ツールの良し悪しではなく、この運用を支える体制が組めているかどうかです。

テスト自動化の失敗は「よくあること」——まず症状を確認する

テスト自動化の失敗とは、整備した自動テストが保守されず、使われないまま放置される「塩漬け」状態に陥ることを指します。特定の誰かが悪いわけでも、あなたのチームだけが特別に不器用なわけでもありません。原因の多くは、個人の技量ではなく仕組みの側にあります。

こんな状態になっていませんか

まずは、いま自動テストがどんな状態にあるかを確認してみましょう。以下のうち、いくつ当てはまるでしょうか。

• 自動テストを整備したが、実際にはほとんど回していない
• テストが赤いまま放置され、誰も原因を追わなくなった
• 自動化したのに、手動テストの量がいっこうに減らない
• 特定のメンバーしか中身を触れず、その人がいないと止まる
• 上長に「自動化して何が良くなったのか」を数字で説明できない
• 仕様変更のたびにテストが壊れ、修正が追いつかない

このうち2つ3つでも当てはまれば、それはいわゆる「塩漬け」の状態に足を踏み入れているサインです。作ったきり使われず、保守もされず、ただ存在しているだけの状態を指します。

見落とされがちですが、塩漬けは一気に起きるのではなく、じわじわと進みます。最初は一つのテストが赤くなり、それを直す時間が取れずに保留にする。次のリリースで別のテストも赤くなる。そうして「見なくてよい赤」が増えていくうちに、テスト結果そのものが誰にも参照されなくなります。症状のチェックは、この進行がどこまで来ているかを測る体温計だと考えてください。

失敗は能力ではなく構造の問題

こうした状態に陥ると、担当したメンバーは「自分のやり方が悪かったのか」と責任を感じがちです。しかし、原因の多くは個人の技量ではありません。

自動化の目的が曖昧なまま始まった、保守にかかる工数を誰も見込んでいなかった、続ける人を決めていなかった——こうした構造的な要因が積み重なった結果です。だからこそ、立て直しも精神論ではなく仕組みの設計から始める必要があります。

ここを個人の問題と捉えてしまうと、担当者を替えれば直ると誤解しがちです。しかし体制の設計が変わらなければ、次の担当者も同じ壁に突き当たります。犯人探しではなく、続かない構造そのものを見直すことが立て直しの出発点になります。

そもそも維持できる体制か——身の丈で判断する

ただし、すべてのチームがいきなり本格的な立て直しに進むべきだとは限りません。立て直しには相応の工数と体制が要るからです。

先に、自チームがそもそも自動化を維持できる体制かを見極めましょう。判断の目安を整理します。

現状の体制	現実的な選択
保守の担い手を確保でき、予算もある	本格的に立て直す
兼任中心・低予算で保守の余力がない	立て直さず損切り／範囲縮小から入る
一部だけ価値が高いが社内で回らない	対象を絞る・外部と組む

兼任中心で予算も限られるなら、無理に全体を立て直さず、損切りや範囲縮小のほうが正解になるケースもあります。身の丈に合う選択肢から入るほうが、二度目の塩漬けを避けられます。

無理に全体を立て直そうとして、結局また保守が回らずに二度目の塩漬けを招く——これが最も避けたい失敗です。手を広げる前に、続けられる範囲を冷静に見積もることが、遠回りに見えて近道になります。

この記事で扱う範囲

本記事は、ツールの優劣やスクリプトの書き方を論じるものではありません。あくまで「なぜ組織の中で自動テストが続かないのか」「どうすれば運用として定着するのか」という体制・プロセスの視点で整理します。実装の詳細は開発担当に委ね、PMが判断すべき論点に絞ります。

テスト自動化の失敗が起きる6つの構造的な原因

ここからが本題です。テスト自動化の失敗を引き起こす原因は、大きく6つに整理できます。それぞれが先ほどの症状とどう結びつくかを見ていきましょう。

林尚平『ソフトウェアテスト自動化の教科書』は、自動テストの失敗のほとんどは、自動テストに関する知識が足りず、どう設計すればよいかわからないまま進めてしまったことが原因だと指摘しています。つまり、走り出す前の設計と合意が欠けていることが根にあるのです。

原因1・2 目的の曖昧さと対象選定の誤り

第一の原因は、目的が曖昧なまま「自動化そのものが目的」になってしまうことです。ここで押さえておきたいのは、自動化の役割はデグレ（先祖返り）の確認であり、品質そのものを上げる技術ではないという点です。「自動で動いた」こと自体に達成感を覚え、成功と勘違いすると、動いているのに効果が出ない状態が生まれます。

目的が曖昧だと、何をもって成功とするかの基準も持てません。すると、テストの本数やカバレッジの数字だけが独り歩きし、「本数は増えたが誰の役にも立っていない」という状態に陥ります。まず「この自動化で何を楽にしたいのか」を一言で言えるかどうかが、最初の分かれ目です。

第二の原因は、自動化する対象を誤ることです。変わりやすいUIや、一度しか実行しないテストを自動化しても、労力に見合いません。自動化に向かないものを自動化することが、塩漬けの最大の入り口になります。

原因3・4 保守工数の見落としとFlakyによる信頼喪失

第三の原因は、保守の担い手と工数を見込まないことです。スクリプトの作成には手動テストの3倍程度の工数がかかるとされ、さらに作った後の保守が延々と続きます。この保守を誰も引き受けないまま放置すれば、テストはすぐに現実とずれていきます。

保守工数は、導入時の稟議や見積もりから抜け落ちやすいのが厄介な点です。作るコストは見えても、その後何年も続く維持コストは見えにくい。結果として「作る予算は取ったが、直す予算は誰も持っていない」という状態になり、最初のリリースを越えたあたりから綻び始めます。

第四の原因は、Flakyなテストによる信頼の喪失です。Flakyとは、コードや環境を変えていないのに結果が非決定的に揺れるテストを指します。実行のたびに結果が変わると、チームは「どうせまた誤検知だろう」と結果を信じなくなり、赤くても誰も見なくなります。信頼を一度失ったテストは、たとえ後で正しく直しても「また嘘をつくかもしれない」と敬遠され、なかなか元の信頼を取り戻せません。

原因5・6 属人化と短期ROI期待

第五の原因は属人化です。特定の人しか中身を理解しておらず、レビューもドキュメントもない。その人が別案件に移った途端、誰も手を出せなくなります。受託開発ではメンバーの入れ替わりや案件移動が日常的に起きるため、属人化はとりわけ致命傷になりやすい原因です。

第六の原因は、ROIを短期で期待しすぎることです。自動化したテストは複数回繰り返し実行して初めて元が取れます。数回で成果を求めると「効果がない」と早々に見切られてしまいます。導入直後はむしろ工数が増えるのが普通で、その谷を越える前に評価してしまうと、正しく進めていても失敗と判定されてしまいます。

これら6つの原因は、単独で起きるより連鎖して起きるのが実態です。目的が曖昧だから対象選定も甘くなり、保守工数を見込まないから赤いテストが放置され、放置が続くから信頼を失い、属人化した担当者が抜けて誰も直せなくなる——こうして症状が雪だるま式に重なっていきます。だからこそ、どれか一つを潰すだけでは足りず、原因の連鎖ごと断ち切る発想が必要になります。

以下に、6つの原因と現れる症状の対応を整理します。

構造的な原因	現れる症状
①目的が曖昧（自動化の目的化）	動いているのに効果が説明できない
②対象選定の誤り	変わりやすい部分ばかり壊れる
③保守工数の見落とし	仕様変更に修正が追いつかない
④Flakyによる信頼喪失	赤くても誰も見なくなる
⑤属人化	担当者がいないと止まる
⑥短期ROI期待	数回で「効果なし」と見切られる

自動化すべきもの・すべきでないものの線引き

6原因のうち、最も入口になりやすいのが「対象選定の誤り」です。「何でも自動化しよう」という発想こそが、塩漬けを招く根の一つだと言えます。

自動化に向く条件

自動化が効果を発揮するのは、繰り返し実行され、動作が安定していて、壊れると影響が大きい部分です。リリースのたびに必ず確認する基幹の動作や、回帰テストのように何度も走らせるものが典型です。

目安として、自動化したテストは最低でも5回以上実行しないと、スクリプト作成の工数を取り返せません。これは損益分岐点の最低ラインで、保守工数が上乗せされる分、実際の分岐点はさらに後ろへずれます。そのため実務では、20回以上の実行が見込める試験を優先するのが現実的です。「5回を超えれば自動化してよい」と単純に読み替えないよう注意してください。

向かない条件

一方、変わりやすい画面、仕様が流動的な機能、一度きりしか実行しないテストは自動化に向きません。作った先から壊れ、保守だけがかさんでいきます。

加えて、探索的テストやユーザビリティの確認のように、期待結果が事前に定まりきらず、人の判断や気づきが要るものも自動化には不向きです。動作が安定していても、これらは手動で担うのが基本です。

観点	自動化に向く	自動化に向かない
実行頻度	何度も繰り返す	一度きり・数回
安定性	仕様が安定している	仕様が流動的
期待結果	明確に定義できる	事前に定まらない
探索性	手順が決まっている	探索・気づきが要る
対象	基幹・回帰の動作	変わりやすいUI・UX確認
重要度	壊れると影響大	影響が限定的

受託開発では、案件をまたいで再利用できる共通部分——ログイン、決済、帳票出力といった定番の動作——に絞ると、投資対効果が読みやすくなります。逆に、その案件だけに固有で今後使い回さない機能は、たとえ動作が安定していても自動化の優先度を下げるのが賢明です。案件が終われば使われなくなるテストに保守コストをかけ続けても、回収の見込みが立たないからです。まずは繰り返し価値を生む共通部分から着手し、効果を確かめてから範囲を広げるのが安全な進め方になります。どの機能を自動化の線引きに含めるかは、自動化する対象の選び方を判断軸から整理する方法も参考になります。

「全部自動化」が失敗を招く理由

理想論として「すべてを自動化できれば楽になる」と考えたくなりますが、現実には逆です。自動化の範囲を広げるほど保守対象が増え、仕様変更のたびに壊れる箇所も増えます。

どの層をどれだけ自動化するかのバランスも同じで、すべてを一律に自動化するのではなく、層ごとに濃淡をつけるのが定石です。テストの階層構造を意識し、下位の安定した層に自動化を厚く、変動の大きい上位層は手動を残すといった配分が、保守負担を抑えます。この考え方は一般に「テストピラミッド」と呼ばれ、変わりにくく高速に回せる層を土台に据えることで、全体の保守コストを低く保つ狙いがあります。

塩漬けを防ぐ立て直しの手順——保守を運用に組み込む

原因が構造にあるなら、立て直しも構造から手をつけます。ポイントは「作って終わり」ではなく「保守まで含めて運用に組み込む」という発想の転換です。

具体的には、次の5ステップで進めます。

目的とKPIを先に決める

まず「何のために自動化するのか」を言語化します。回帰テストの工数を減らすのか、リリース前確認の時間を短縮するのか。目的が決まれば、達成度を測るKPIも定まります。

自動化の役割はデグレ検出と工数削減にあるため、KPIも「削減できた工数」「検出できたデグレの件数」で測るのが一貫します。ここが曖昧だと、後から「効果があったのか」を誰も判断できません。KPIは欲張らず、まずは一つか二つに絞ると、達成状況を追いやすくなります。

保守工数を最初から運用に織り込む

自動テストは作った瞬間から保守が始まります。仕様変更のたびにスクリプトを直す時間を、あらかじめ運用計画とスケジュールに組み込んでおくことが欠かせません。

保守を「余裕があればやる作業」に位置づけると、まず間違いなく後回しになり塩漬け化します。スプリントやリリースサイクルの中に、テスト保守の枠をあらかじめ確保しておくことが実効的です。保守を日常の運用プロセスに組み込む具体策を、導入前の段階で決めておきましょう。

Flaky対策と属人化回避のルール

赤くなったテストは、まず原因を3つに切り分けます。

• Flaky: コード・環境を変えていないのに揺れる。隔離して再現を調査する
• 仕様変更による正当なfail: 仕様が変わった結果の失敗。テストを更新する
• 真の回帰バグ: 実装のデグレ。プロダクト側を修正する

不安定なテストは見つけ次第すぐに隔離し、赤いまま放置しないことが信頼を守ります。「赤は必ず対応する」というルールを守れる本数だけを維持する、という上限の発想も有効です。属人化を避けるには、レビューを必須にし、命名規約とドキュメントを整えます。誰が見ても構造がわかる状態を保つことで、担当者が替わっても運用が続きます。

ROIは現実的な時間軸で合意する

先述の通り、自動化は複数回の実行を重ねて初めて元が取れます。上長やクライアントには「短期では回収できないが、中期で工数削減につながる」という時間軸をあらかじめ共有しておきます。期待値を最初に揃えておくことで、導入直後に工数が増える谷の時期を「想定内」として乗り越えられます。

以下に、6つの原因と立て直しの打ち手を対応させます。

構造的な原因	立て直しの打ち手
①目的が曖昧	目的とKPIを先に定義する
②対象選定の誤り	向く／向かないの線引きを決める
③保守工数の見落とし	保守工数を運用計画に織り込む
④Flakyによる信頼喪失	隔離・切り分け・修正ルールを決める
⑤属人化	レビュー・命名規約・ドキュメント化
⑥短期ROI期待	現実的な時間軸で合意する

工数やプロセスを定量的に捉える視点を持つと、KPI設定や合意形成の説得力が増します。IPAのソフトウェア開発分析データ集のような定量データは、社内での基準づくりの参考になります。

続けるか・損切りするかの判断軸

すべての自動テストを立て直せるとは限りません。中には、直すより手放したほうが合理的なものもあります。ここで大事なのは、感情ではなく構造で判断することです。

塩漬けになったテストへの向き合い方は、次の4択に整理できます。

• 残す: 効果が見込め、保守できる体制がある
• 削る: 実行頻度が低く、維持コストに見合わない
• 手動に戻す: 変化が激しく、自動化の前提を満たさない
• 外部委託する: 社内では保守が回らないが、価値はある

選択肢	向いている状況	判断のポイント
残す	頻繁に実行・仕様が安定	保守の担い手がいるか
削る	実行頻度が低い	維持コスト＞効果
手動に戻す	仕様が流動的	自動化の前提を満たさない
外部委託	価値はあるが社内で回らない	連携体制を組めるか

損切りは失敗ではなく再設計

一部のテストを手放すことは、失敗の追認ではありません。損切りは、限られたリソースを効果の高い対象へ振り向け直す再設計です。むしろ、続けられないものを抱え込むほうが、全体の信頼と工数を蝕みます。

「せっかく作ったのだから」という気持ちが、かえって塩漬けを長引かせることもあります。過去にかけたコストは戻らない以上、これから先の効果だけを基準に残す・削るを決めるほうが合理的です。損切りの判断には、効果を数字で捉える視点が欠かせません。自動化のROIを測る指標を設定する方法を押さえておくと、残す・削るの線引きが明確になります。

上長にどう説明するか——簡易試算のフレーム

「一度作ったものをやめる」と聞くと、上長は後ろ向きに受け取りがちです。そこで、数字を根拠に選択の理由を構造で説明します。効果の見立ては、次の考え方で概算できます。

手動テスト工数 × 実行頻度 − 保守工数 ＝ 削減効果

たとえば、ある回帰テスト一式を手動で回すと毎回2人日かかり、月2回実行するとします。自動化後の保守が月1人日で済むなら、月あたり「2人日 × 2回 − 1人日 ＝ 3人日」の削減が見込めます（これは説明用の架空の試算例で、実際の値は案件ごとに測ってください）。逆に保守が月4人日かかるなら削減はマイナスとなり、損切りや手動回帰が妥当だと判断できます。

大切なのは、精緻な数字を出すことよりも、判断の根拠を同じ土俵で比べられる形にすることです。ざっくりした概算でも、続ける・やめるの理由を数字で語れれば、感情論の押し引きから抜け出せます。上長への説明は、1枚のサマリにまとめると通りやすくなります。盛り込む項目は次の5つです。

項目	記載する内容
現状工数	いまの手動テスト工数と実行頻度
削減見込み	自動化で減らせる工数
保守コスト	維持にかかる継続工数
回収時期	累計で元が取れる目安の時期
撤退基準	この条件を下回ったら損切りする線

数字に基づく判断であれば、費用対効果の説明責任も果たせます。

保守を誰が担うか——体制で成否が決まる

ここまで見てきて、最終的にたどり着くのは一つの結論です。成否を分けるのは技術力よりも、「保守を誰が継続的に担うか」という体制の設計である、ということです。

保守の担い手を決めない自動化は続かない

どれほど優れたテストを整備しても、保守を続ける人がいなければ塩漬けは避けられません。保守の担い手には、主に3つの形があります。

担い手	特徴	向いている状況
専任内製	継続性が高い	専任を置ける規模
兼任内製	手軽だが後回しになりがち	一時的・小規模
外部連携	保守を任せられる	社内で回らない

重要なのは、担い手を「役割」として明示的に決めておくことです。「気づいた人が直す」という暗黙の運用は、忙しくなった瞬間に誰も直さなくなります。担当と工数枠をセットで割り当てて初めて、保守は運用として回り始めます。担い手が一人に偏ると、その人の離任が即座に塩漬けへ直結します。副担当を置く、あるいは複数人で分担するなど、特定個人に依存しない形にしておくことが、体制としての安定につながります。

兼任QAで保守が回らないときの選択肢

受託開発の現場では、テストを開発者が兼任しているケースが少なくありません。しかし、複数案件を抱え、リリースに追われる中で、保守まで手が回らないのが実情です。

兼任でどこまで抱えられるかには限界があります。開発者は目の前の実装とリリースを優先せざるを得ず、テスト保守はどうしても後回しになりがちです。悪意があって後回しにするわけではなく、優先順位の構造上そうならざるを得ないという点が本質です。だからこそ「頑張って両立する」という個人の努力に頼るのではなく、保守を担える体制そのものを用意できるかを問い直す必要があります。開発者がテストを兼任する体制の限界を見極める視点を持っておくと、無理を続けて塩漬け化する前に手を打てます。

外部と組むという中立的な打ち手

社内で保守が回らないなら、構築や保守を外部と組むのも一つの選択肢です。これは売り込みではなく、体制設計上の中立的な打ち手として検討に値します。

外部と組む場合も、丸投げにせず、どこまでを任せてどこから自社が判断するかの線引きを最初に決めておくことが肝心です。保守の担い手が社外に移っても、目的やKPIを握るのはあくまで自社側です。内製と外注のどちらが自チームに合うかは、テストの内製と外注を判断軸で比較することで整理できます。自動化の保守を「誰が担うか」という問いは、最終的にこの内製・外注の判断につながります。JSTQBが公開するテスト技術者資格のシラバスが示すように、テストは体系的な役割として位置づけられるべきもので、片手間の兼任だけで支え続けるのは構造的に難しいのです。

まとめ：テスト自動化の失敗を構造から立て直す

テスト自動化の失敗は、個人の能力ではなく組織と運用の構造から生まれます。だからこそ、立て直しも精神論ではなく仕組みの設計から始めるべきです。本記事の要点を整理します。

• 失敗の原因は、目的の曖昧さ・対象選定の誤り・保守工数の見落とし・Flaky・属人化・短期ROI期待の6つに集約される
• 自動化は「向く・向かない」の線引きが要で、何でも自動化する発想が塩漬けを招く
• 立て直しは、目的定義・線引き・保守設計・Flaky対策・ROI合意の5ステップで進める
• ただし維持できる体制がないなら、無理に立て直さず損切り・範囲縮小から入る判断も正解になる
• 続けるか損切りするかは、残す・削る・手動に戻す・外部委託の4択で構造的に判断する
• 成否を最終的に分けるのは、保守を誰が継続的に担うかという体制設計

立て直しは、一気に全部を直そうとするほどうまくいきません。まずは効果が高く保守もしやすい一群だけを選んで運用に乗せ、そこで回る手応えを掴んでから範囲を広げる。この小さく確実に前進するやり方が、二度目の塩漬けを避ける最短ルートになります。

まずは、いま塩漬けになっているテストの症状を洗い出し、「保守を誰が担うのか」を明確にするところから始めてみてください。

テスト自動化の保守体制の見直しを検討されている方は、体制設計の相談から始めてみることをおすすめします。現状の症状を整理するだけでも、次の一歩が見えてきます。

次に読むならこの記事

• 大規模システムの品質をどう守る？｜テスト整備を依頼された話
• 開発工数 削減とは？システム開発効率化の基本
• デバッグとは？テストとの違いと効率的な進め方・ツールを解説

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

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

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