テストの残業が慢性化する理由と5つの打ち手

2026 8/06

2026年8月6日 2026年8月6日

案件がテスト工程に入ると、決まって残業が始まる。終盤は連日遅くまで残り、リリース直前には徹夜。ようやく出したと思えば、今度はリリース後のバグ対応で消耗する――。もしこの光景に心当たりがあるなら、それはあなたの働き方が悪いからではありません。

多くの受託開発の現場で、テストの残業は特定の案件だけでなく「毎回」繰り返されます。毎回起きるということは、それは個人の頑張りや根性で解決する問題ではなく、仕事の進め方そのものに埋め込まれた「構造」の問題です。個人の残業時間を削ろうと号令をかけても、翌案件でまた同じ山が立ち上がる。これは意志の問題ではなく、工程の並び方や見積もりの立て方が、そもそも終盤の集中を生む形になっているからです。

この記事では、テストの終盤に残業が集中する原因を6つの根本原因に分解し、その山を崩すための5つの打ち手を整理します。少人数で開発とテストを兼任しがちな受託開発のPMが、社内やクライアントへの説明にも使える判断軸としてお読みください。抽象論ではなく、明日から着手できる順序と、上長・顧客への説明ロジックまで含めて具体的に扱います。

テストの残業はなぜ「毎回」起きるのか

開発の遅れからテスト期間の圧縮、残業での物量消化、疲労による見逃し、リリース後のバグ対応、疲労の次案件への持ち越しへと一方向に回り続けるテスト残業の負のサイクルを示した円環図

テストの残業が慢性化する最大の理由は、テストが全工程の最後にあり、上流の遅れをすべて吸収する緩衝材になっているからです。まず、症状を具体的に描いてみましょう。多くの現場で見られる典型はこうです。

開発フェーズは比較的落ち着いているのに、テスト工程に入った途端に時間が溶けていく
リリース1週間前あたりから残業が常態化し、直前は休日出勤や徹夜になる
なんとかリリースしても、その後のバグ対応で数日〜数週間追われ、疲労を抱えたまま次の案件に突入する

テスト工程だけが、なぜか毎回スケジュールの帳尻合わせの場所になっている——このパターンに覚えがあるPMは少なくないはずです。上流の設計や実装が少しずつ遅れても、リリース日は動かせない。すると、しわ寄せの逃げ場は「後ろにある工程」しかありません。その最後尾に置かれているのがテストです。

テスト工程に入ると時間が消える典型パターン

開発中は「作る」という前向きな作業が中心で、進捗も目に見えます。機能が1つ実装できれば、確かに前に進んだ実感があります。ところがテスト工程に入ると、様相が変わります。

想定どおり動くかの確認、動かなかった箇所の切り分け、修正後の再確認。この「確認と手戻り」の往復が、際限なく時間を吸い込んでいきます。1件の不具合を直すたびに、その周辺をもう一度確認し直す必要が生じ、確認したつもりの箇所から別の不具合が顔を出す。

作業のゴールが見えにくいため、「あと少し」がいつまでも終わらないのです。テスト期間そのものが短ければ短いほど、この往復のしわ寄せは残業に転嫁されます。しかも終盤で見つかる不具合ほど、原因が上流の設計に根ざしていることが多く、修正の影響範囲が広がりやすい。だから終盤の1件は、序盤の1件よりも重いのです。

「今回だけ忙しい」が毎回続くなら構造の問題

一度きりの繁忙であれば、たまたま難しい案件だった、で片付けられます。しかし現実には、案件が変わっても同じ時期に同じ残業が発生します。担当者もメンバー構成も違うのに、山が立つ場所とタイミングだけは判で押したように同じ。

単発の事故が「毎回」起きるなら、それはもう事故ではなく仕組みです。同じ場所で毎回つまずくなら、原因は人ではなく道の作りにあると考えるのが妥当です。

だからこそ、個人の頑張りに帰す前に、まず「どの構造がこの残業を生んでいるのか」を切り分ける必要があります。人を責めても道は直りません。逆に、道の形さえ変えれば、同じ人員のままでも山は低くなります。この切り分けが、後述する打ち手の出発点になります。

疲労が次案件に持ち越される悪循環

テスト自動化の分野では、「テストの負のサイクル」という考え方が知られています。林尚平『ソフトウェアテスト自動化の教科書』では、工数削減の圧力でテストが不十分になり、その結果として市場で不具合が発生し、その対応工数が次の製品のテスト工数をさらに圧迫する、という悪循環が指摘されています。

残業もこれと同じ構造です。今回の消耗が次案件の余力を奪い、余力がないから次もまた終盤に無理をする。前倒しで手を打とうにも、そのための余力がすでに前案件で使い果たされている——この入れ子になった消耗が、慢性化の正体です。一度回り始めた消耗の循環は、意識して断ち切らない限り自然には止まりません。

残業を生む6つの根本原因

では、その構造を具体的に分解してみましょう。テストの終盤に残業が集中する原因は、大きく次の6つに整理できます。

後工程へのしわ寄せ：開発の遅れがそのままテスト期間の圧縮になる
手動の物量：同じような確認作業を、毎回すべて人力で繰り返している
兼任：日中は開発に手を取られ、テストは夜や終盤にまとめて集中せざるを得ない
見積もりへの織り込み：最初から残業ありきで工数を見積もり、残業が「前提」として常態化する
手戻りループ：バグを見つける→修正する→再テストする、の往復が終わらず、ゴールが見えない
「全部テストしよう」：優先度を付けず、すべての項目を等しく見ようとして時間が足りなくなる

この6つは、大きく3つの由来に分けて捉えると打ち手が見えやすくなります。原因を由来ごとに束ねておくと、どの打ち手がどの束に効くのかを対応づけやすくなるからです。

スケジュール由来（①④）：期間の設計そのものに残業が織り込まれている
作業量由来（②⑥）：こなす物量が多すぎて時間内に収まらない
体制由来（③⑤）：人の配置や進め方が終盤への集中を招く

残業は単一の原因ではなく、複数の構造が重なって生まれます。どれか1つを潰せば消えるものではない、という前提がまず重要です。たとえば前倒しだけを徹底しても、物量そのものが多ければ終盤は溢れます。逆に自動化で物量を減らしても、見積もりに残業が織り込まれたままなら、空いた時間はすぐ別の作業で埋まってしまいます。

なお、「自分の現場のテスト工数は多いのか少ないのか」を判断する際には、感覚だけで語らず客観的な物差しを持つことが説得力につながります。開発工程ごとの工数分布については、IPAのソフトウェア開発分析データ集のような公的な調査データが参考になります。自社の実績を業界の分布と並べれば、「うちのテスト工程は特別に重い」のか「そもそも見積もりが薄い」のかが切り分けられます。

とくに⑥「全部テストしよう」については、そもそもの前提を押さえておく必要があります。取りうる入力・条件の組み合わせは膨大で、すべてを網羅する「全数テスト」は原理的に不可能です（これはソフトウェアテストの原則の一つとしても知られています）。

だからこそ、限られた時間をどこに厚く配分するかという優先度付け（リスクベース）が避けられません。「全部見る」を目標に掲げること自体が、達成不能なゴールを設定して残業を無限に呼び込む行為なのです。この点は後半で改めて掘り下げます。

長時間化が招く「品質が下がる逆説」と組織の疲弊

残業を続ければ品質が上がる、というのは直感的にはもっともらしく聞こえます。時間をかけるほど念入りに見られるはず、という素朴な期待です。しかし実際には逆のことが起きます。

長時間頑張るほど、かえって品質が下がっていく——これが長時間化のはらむ最大の逆説です。理由は単純で、疲労した状態でのテストは見逃しが増えるからです。集中力が落ちれば、本来気づけたはずの不具合をすり抜けさせてしまいます。深夜に「もう大丈夫だろう」と流した確認が、翌朝に見返すと初歩的な不備だった、という経験は珍しくありません。

問題は品質だけにとどまりません。慢性的な長時間化は組織にも影を落とします。

疲弊が積み重なり、チームのモチベーションや定着に影響する
「残業してでも間に合わせた」ことが評価されると、無理を前提とした働き方が正当化される
PM自身が精神的な負荷を抱え込み、判断の余裕を失う

とくに三つ目は見落とされがちです。PMが疲弊すると、リスクを冷静に見極めて「ここは薄くていい」と判断する余裕そのものが失われます。すると、不安を打ち消すために「念のため全部見る」方向に流れ、それがまた残業を呼ぶ。判断の余裕こそが、山を低く保つための資源なのです。

とりわけ、開発担当者がそのままテストを兼任する体制では、この負荷が特定の個人に集中しやすくなります。兼任がどこまで機能し、どこから限界を迎えるかについては、兼任でテストを担う場合の限界と見極め方で詳しく整理しています。

残業は真面目さの証ではなく、構造が崩れているサインです。そして、この崩れを放置したままリリースを重ねると、リリース後のバグ対応でさらに消耗する悪循環に入ります。バグの流出そのものを抑える体制づくりについては、リリース後のバグを減らすテスト体制の作り方もあわせて参考にしてください。

テストの残業の山を崩す5つのレバー

終盤に集中する急峻な残業の山を、前倒し・見積もり是正・リスクベースで優先度・繰り返しだけ自動化・繁忙期は外部活用の5つのレバーがなだらかに平坦化する構造を、時間軸上の波形で示した図

テストの残業は複数の構造から生まれるため、対策も1つでは足りません。複数のレバーを組み合わせて、山を少しずつ削っていく発想が現実的です。ひとつのレバーで山が消えることは期待せず、それぞれが山の別の面を削ると考えてください。ここでは5つのレバーを挙げます。

レバー①：テストを前倒しする

最も効くのが「前倒し」です。テストを終盤にまとめて集中させるのではなく、開発と並行して早い段階から回していきます。

具体的には、単体・結合レベルのテストは開発と並行して早期に消化し、システム全体やE2E（通しの動作確認）を終盤に集中させないという配分です。早く回すほど、上流での不具合を早く見つけられ、終盤の手戻りループそのものを小さくできます。序盤で見つかる不具合は影響範囲が狭く、修正コストも小さい。終盤に持ち越すほど傷が深くなるからこそ、時間軸を前に倒す価値があります。

前倒しは、①後工程しわ寄せと⑤手戻りループの両方に効く、時間軸としては「今回の案件からすぐ効く」即効性のあるレバーです。特別なツールも予算も要らず、テストの開始タイミングを設計し直すだけで着手できる点が強みです。

とはいえ、兼任中心の体制では「開発が終わってからでないとテストに手が回らない」という声も出ます。ここでのコツは、テストの実行そのものを前倒しするというより、テストの観点や確認項目の洗い出しを設計段階で済ませておくことです。仕様が固まった時点で「何を確認すべきか」を書き出しておけば、実装が終わった機能から順に確認へ移せます。準備だけでも前に倒しておくと、終盤の「何をテストするか考える時間」がまるごと消え、山の立ち上がりが目に見えて緩やかになります。

レバー②：見積もりに残業を織り込まない

残業が「前提」になっている限り、構造は変わりません。見積もりの段階で残業ありきの数字を組んでしまえば、それは自ら残業を予定に組み込んでいるのと同じです。定時内で終わらない量を最初から計画に載せておいて、終盤に残業で回収する——この暗黙の前提が、毎回の徹夜を制度化してしまいます。

とはいえ、「そんなことを言っても顧客が握った納期と金額は動かせない」「残業を織り込まない見積もりを出せば、他社に負けて失注する」——この現実的な懸念は当然です。理想論だけでは現場は動きません。

そこで、一気にゼロを目指すのではなく、次の順序で進めることをおすすめします。

まず現状を可視化する：今の見積もりが実際には何時間の残業を前提にしているかを、過去案件の残業実績として数値で洗い出す
費用対効果として説明する：残業前提の見積もりが、手戻り・品質低下・そこから生じる離職コストといった「見えない追加コスト」を生んでいることを、上長や顧客に根拠付きで示す
次回見積もりから徐々に是正する：可視化した実績を根拠に、次の案件から少しずつ残業前提を減らした見積もりへ移行する

「残業ゼロの見積もりをいきなり通す」のではなく、「残業前提を可視化し、次回から徐々に是正する」のが現実的な入口です。数字という共通言語があれば、顧客・上長への説明ロジックも組み立てやすくなります。「感覚的にきつい」ではなく「過去3案件で平均40時間の残業を前提にしていた」と示せれば、交渉のテーブルに載せられます。

レバー③：リスクベースで濃淡を設計する

すべてを等しくテストしようとするから時間が足りなくなります。そこで、テスト対象に優先順位を付け、力の入れどころにメリハリをつけます。全体を薄く広げるのではなく、重要なところに厚みを寄せる発想です。

これは「やる／やらない」の単純な二値ではありません。テストの深さ・優先度・順序という「濃淡」を設計する作業です。「やらない」の中にも、まったく見ないのではなく「最小限に留める」「後回しにする」といった幅があります。この濃淡の付け方こそが腕の見せどころで、詳しくは後半で掘り下げます。

濃淡を設計するうえで押さえておきたいのは、優先度の判断はPM一人で抱え込まず、開発担当やクライアントと共有しておくと後で揉めにくいという点です。どこを厚く見て、どこを薄くしたのかを事前にすり合わせておけば、仮に薄くした箇所で不具合が出ても「合意のうえでの判断だった」と説明できます。逆に、この共有を怠ると、薄くした箇所の不具合がすべてPMの責任として跳ね返ってきます。濃淡の設計は技術判断であると同時に、関係者との合意形成でもあるのです。

レバー④：繰り返し実行するものだけ自動化する

自動化は強力ですが、他の4つのレバーとは性質が違います。前倒しやリスクベースが「今回の残業をすぐ減らす」打ち手なのに対し、自動化は複数リリースにまたがる回帰テストの累積工数を減らす「中長期の投資」です。時間軸が異なる点に注意が必要です。今回の徹夜を今夜なくす手段ではない、と理解しておかないと期待外れに終わります。

その判断基準になるのが、林尚平『ソフトウェアテスト自動化の教科書』で示される「5回ルール」です。自動化したテストは、おおむね5回以上実行しないとスクリプト作成の工数を取り返せない、という考え方です。

裏を返せば、再実行が5回に満たない単発の確認を自動化すると、かえって工数が増えます。回収に一定回数の再実行が必要という性質上、今回のリリース限りで使い捨てる確認は自動化に向きません。逆に、リリースのたびに毎回流す回帰テストのように、長く繰り返す部分ほど投資が回収されます。だから最初に自動化すべきは、華やかな新機能ではなく、地味でも毎回必ず流す土台の確認です。

いきなり大掛かりに組む必要はありません。まずは「毎回必ず流す1ケースだけ」を、既存のツールで半日ほど試してみる。この最小着手から始めれば、自動化が自分たちの案件特性に合うかを低リスクで見極められます。どこから自動化すべきかの判断軸は、自動化するテスト対象の選び方で整理しています。

レバー⑤：繁忙期の山は外部と一緒に崩す

前倒しやリスクベースで山を低くしても、なお溢れる分は出ます。少人数の受託開発では、そもそも人手の絶対量が足りず、内部の工夫だけでは吸収しきれないピークが残るからです。その繁忙期のピークを、外部の力で平準化するのが5つ目のレバーです。詳しい判断軸は後半で扱います。

以下は、5つのレバーがどの構造に効くかを一覧にしたものです。原因の束（スケジュール・作業量・体制）とレバーの対応が見えると、自社ではどれから着手すべきかを選びやすくなります。

レバー	主に効く構造	時間軸
①前倒し	①後工程しわ寄せ・⑤手戻りループ	今回からすぐ効く
②残業を織り込まない見積もり	④見積もり常態化	次回案件から徐々に
③リスクベースで濃淡設計	⑥全項目を等しく・⑤手戻りループ	今回からすぐ効く
④繰り返しだけ自動化	②手動の物量	中長期の投資として
⑤繁忙期は外部と協働	③兼任・①後工程しわ寄せ	繁忙期ごとに

レバーは単独で使うものではありません。残業が複数の構造から生まれる以上、打ち手も併用が基本です。下の表は、6つの構造それぞれに、どの打ち手が効くかを対応づけたものです。自社の症状に当てはめれば、優先して回すべきレバーの組み合わせが見えてきます。

残業を生む構造	主な症状	崩す打ち手
後工程しわ寄せ	開発遅延ぶんテスト期間が圧縮	前倒し・見積もりで期間を守る／繁忙期は外部
手動の物量	繰り返し確認を人力で消耗	繰り返しの多い所だけ自動化
兼任	日中開発・夜や終盤にテスト集中	繁忙期の山を外部で崩す
見積もり常態化	残業前提の見積もりが定着	残業を織り込まない見積もりへ
手戻りループ	バグ→修正→再テストで終わらない	前倒し＋リスクベースで再テスト範囲を絞る
全項目を等しく	優先度を付けず全部見る	リスクベースで「やらないテスト」を決める

1つの症状に複数の打ち手が並ぶことからも分かるとおり、対策は「併用」が前提です。どれか1つだけを完璧にやるより、複数を6割ずつでも組み合わせるほうが、現場では山が低くなります。完璧を狙って1つに固執するより、六割の手を数本重ねるほうが、少人数の現場では現実的です。

「やる／やらないテスト」の線引き

発生可能性を横軸、影響度を縦軸にとった2軸マトリクスで、両方が高い右上を「厚く見る」、両方が低い左下を「薄く見る・後回し」とし、テストの力の配分を濃淡で示した図

限られた時間をどこに配分するか。その判断の中核が、リスクベースの考え方です。前節でレバー③として挙げた「濃淡の設計」を、ここで具体的な線引きに落とし込みます。

ここで言うリスクは、発生可能性（起きやすさ）と影響度（起きたときの深刻さ）の掛け合わせで捉えます。両方が高いところは厚く、両方が低いところは薄く、というように濃淡を設計します。起きやすくても影響が軽微なら薄く、めったに起きなくても致命的なら厚く——この二軸で見ると、力の配分に説明可能な根拠が生まれます。テスト設計の体系的な枠組みは、JSTQBが公開している知識体系が参考になります。

厚く見るか薄く見るかは、たとえば次のような観点で判断します。

観点	厚く見る	薄く見る／後回し
影響度	障害が事業や顧客に直結する機能	不具合が出ても影響が限定的な機能
使用頻度	多くのユーザーが毎日使う機能	ごく一部・まれにしか使われない機能
変更範囲	今回改修した箇所とその周辺	今回まったく手を触れていない箇所

重要なのは、「やらない」は手抜きではなく設計判断だということです。「やらない」の中身も一律ではなく、まったく見ないものもあれば、最小限に留めるもの、後回しにするものと幅があります。この幅を意識せずに「全部やるか、やらないか」の二択で考えるから、結局は不安に負けて全部やろうとしてしまうのです。

そして、やらない・薄くすると決めたら、その根拠を記録に残しておきます。とはいえ大げさな文書は不要で、既存のチケットやテスト仕様書に「〇〇は変更範囲外のため今回は最小確認」と1行残すだけで十分です。この一手間が、後で「なぜここを厚くテストしなかったのか」と問われたときの説明を支えます。

記録がなければ、薄くした判断はただの手抜きに見えてしまう。逆に一行の根拠があれば、それは正当な設計判断として通ります。リスクの見極めから範囲を絞る具体的な進め方は、リスクベースでテスト範囲を絞る手順で解説しています。

繁忙期の山を「一緒に崩せる相手」の選び方

前倒しやリスクベースで山を低くしても、繁忙期のピークはどうしても残ります。そこを外部の力で平準化するのが、最後のレバーです。

ここでの外部活用は、丸投げとは違います。自分たちで設計した山の「あふれた分」を、一緒に崩してくれる相手を選ぶという発想です。丸投げは「考えることまで委ねる」ことですが、ここで必要なのは「自分たちが設計した濃淡のとおりに手を動かしてもらう」協働です。相手選びでは、次のような判断軸を持つと失敗しにくくなります。

連携のしやすさ：日々のやり取りや不具合報告がスムーズに回るか
立ち上がりの速さ：仕様のキャッチアップにどれだけ時間がかかるか
任せられる範囲：繰り返しの実行だけか、設計から任せられるか

外注をためらう理由の多くは「コスト」です。ここは概算の断定数値ではなく、考え方として整理しておくと上長に説明しやすくなります。天秤にかけるのは、自社で残業をこなす人件費と、外部に任せる費用の比較です。

加えて、平準化によって防げる手戻りや、疲弊による離職のコストも「見えない便益」として勘定に入れると、費用対効果の姿がより正確になります。目に見える外注費だけを片側に置いて「高い」と判断すると、もう片側の残業代・品質低下・離職コストを見落とすことになります。内製と外注をどう天秤にかけるかの物差しは、内製と外注を判断する物差しで詳しく整理しています。