テスト工数の見積もり精度｜外れる原因と改善策

2026 8/06

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

「見積もりどおりに終わったテストが、直近で何件ありましたか」。この問いに即答できるPMは多くありません。テスト工数の見積もり精度は、担当者の経験不足として片づけられがちです。しかし実際の原因は、見積もりの作り方と運用の仕組みの側にあります。

毎回リリース直前にテストが押し込まれ、品質を妥協して出す。その繰り返しなら、勝負はテストを始める前についています。見積もった時点で、すでに足りない数字なのです。

なお本記事は、システムテスト（結合以降の手動テスト）の工数見積もりを想定します。単体テストを開発工数に含めるかどうかは、後述する前提条件で切り分けます。

この記事では、次の4つの問いに答えます。

なぜテストの見積もりは外れるのか
ズレていることに、どうすれば早く気づけるのか
過去の実績データがない場合、何から始めればいいのか
積んだ工数を、顧客や上長からどう守るのか

専任のQAを置けない受託開発を想定し、明日から手をつけられる粒度で整理します。

見積もりが外れる現場で、実際に起きていること

原因を分解する前に症状を言語化します。ズレは見積書ではなく、リリース直前の現場で表面化するからです。

見積もりのズレは「テスト期間の圧縮」として現れる

上流工程の遅れは、どこに吸収されるでしょうか。多くの案件では納期が動かせないため、テスト期間が削られます。要件定義が2週間延びてもリリース日は変わらず、3週間予定していたテストが1週間半に圧縮されます。テストは工程の最後にあるため、あらゆる遅延の受け皿になります。

厄介なのは、この圧縮が「テストの見積もりミス」と区別されない点です。振り返りは「要件が固まるのが遅かった」で終わり、テスト工数が妥当だったかは検証されません。

あなたの見積もりが外れる型はどれか

自分の見積もりのどこに穴があるか、次のチェックリストで数えてみてください。

再テスト（修正確認）の回数を、1件につき1回で計算している
修正の影響範囲を確かめる回帰テストを、別枠で積んでいない
テスト担当者の稼働率を、実質100%として日程に換算している
テスト環境の構築とテストデータ準備を、独立した項目として積んでいない
バグ修正待ち・顧客確認待ちで止まる時間を、日程に織り込んでいない
前回の案件で実際に何時間かかったか、数字で答えられない

3つ以上該当した方は、技法を変えても精度は上がりません。次章の構造的原因から読み進めてください。1〜2つなら、実績記録の章から着手するのが近道です。

ズレの原因を「時間がなかった」で片付けると再発する

案件後の振り返りで、こう言われた経験はないでしょうか。「今回はとにかく時間がなかった」。

この一文で締めくくると、次の見積もりは何も変わりません。時間がなかったのは結果であって、原因ではないからです。どの作業に想定の何倍かかったのか、そこまで分解して初めて次に活かせます。

見積もりの前段にはテスト計画があります。何をどこまで確かめるかが曖昧では、工数の根拠も置けません。テスト計画の立て方を確認するところから始めると、見積もりとのつながりが見えてきます。

テスト工数の見積もり精度を下げる5つの構造的原因

見積もりが外れる理由は「スコープ変更」の一言で片づけられがちです。しかし現場で消えていく工数には、テスト固有の型があります。

ここでは5つに分解します。名前が付けば、自社のズレを分類できます。なお1つ目の再テストは性質の異なる2つに分かれるため、表では2行に分けています。

原因	見積もりで抜けやすい理由	対処の方向性
再テスト①確認テスト	1回で通る前提で計算している	想定検出件数×確認工数×確認回数で積む
再テスト②回帰テスト	確認テストと同じ枠に含めてしまう	再実行ケース数×実行工数×実施回数で別建て
バグ修正待ち	作業していない時間は工数に見えない	待機を前提にした日程バッファへ変換
実効稼働率	人日をそのまま営業日に換算している	実測した稼働率で割り戻す
環境・データ準備	テストケースの実行だけを数えている	準備工数を独立項目として計上
顧客確認待ち	自社の作業ではないため対象外と考える	前提条件として明記し日程に反映

確認テストと回帰テストを1回分で見積もっている

テストケースを100件作り、1件あたり10分で実行できるとします。単純計算では約17時間です。しかし実績はこの数字を上回ります。

上回るのは、単純計算に含まれない作業が積み上がるからです。修正後の確認、影響範囲の再実行、環境準備、待機時間が加わります。程度は体制と対象で異なるため、倍率は自社の実績から出してください。

ここで分けるべきなのが再テストの中身です。修正した不具合そのものを確かめる確認テストと、周囲を壊していないかを確かめる回帰テスト（リグレッションテスト）は別物です。

確認テストの工数は検出件数に比例します。一方の回帰テストは影響範囲の広さと既存テストスイートの規模で決まり、検出件数には比例しません。

確認テスト＝想定検出件数 × 1件あたりの確認工数 × 平均確認回数
回帰テスト＝影響範囲に対する再実行ケース数 × 実行工数 × 実施回数（リリース回数）

確認テストと回帰テストは別物として、それぞれ別の行で積んでください。1本にまとめると、必ず回帰分が抜け落ちます。

前提になるのは、不具合を何件見込むかという想定です。実績が1件もない初回は、次のどちらかで仮置きします。

規模あたりの欠陥密度を暫定値で置く（テストケース件数・画面数・機能数のいずれかを分母にする）
直近の類似案件の概数を、下限〜上限の範囲で置く

どちらの場合も、前提条件に「暫定値である」と明記してください。初回の想定検出件数は当てにいくものではなく、実績との差を測る基準値として置きます。

バグ修正待ちの待機時間が工数に見えていない

不具合を報告したあと、修正が返るまで担当者は何をしているでしょうか。別ケースへ移れれば理想ですが、対象機能全体が止まることもあります。

この待機時間はカレンダー上で確実に消費されます。しかし作業していないため、工数表には現れません。

兼任体制では、待機が切り替えコストになります。テストを中断して実装に戻り、修正が上がればまた戻る。往復のたびに、どこまで確認したかを思い出す時間が生じます。

対処は、待機を工数に足すのではなく日程側のバッファへ変換することです。「修正の反映には平均◯日かかる」という実績があれば、日程に織り込めます。

兼任前提の実効稼働率を100%で計算している

「テスト工数は5人日です」と「5営業日で終わります」は別の話です。混同すると、日程は必ず破綻します。

兼任の担当者は、1日のすべてをテストに使えません。定例会議、問い合わせ対応、別案件の割り込みが入ります。工数を見積もったら、実効稼働率で割り戻して初めて日程になります。

稼働率は一般的な相場ではなく、自社の実測で決めてください。まずは1週間の作業時間を記録し、概算を出します。

ただし1週間の値は暫定です。割り込みや障害対応は週ごとの偏りが大きいためです。2〜3週間分に広げると安定します。暫定のまま使うなら、前提条件に「暫定値」と明記してください。

テスト環境・テストデータの準備工数を別枠にしていない

実行時間だけを数えていると、準備工数がまるごと抜け落ちます。実行前には次の作業が必要です。

テスト環境の構築とデータベースの初期化
各権限・各ロールのテストアカウント作成とマスタデータの投入
外部システム連携のモック作成、または接続設定
異常系を再現する特殊データの生成

準備の比重は、想像以上に大きくなります。Boris Beizerは、トランザクションテストではテストリソースの30%から140%がテストデータの生成・収集・抽出に使われると指摘しました。この指摘は、Lee Copeland『はじめて学ぶソフトウェアのテスト技法』で紹介されています。

幅が広いのは、システムの性質による差が大きいからです。自社がどちら寄りかは、外部データ連携の有無で判定できます。

外部システムと連携し、扱うマスタの種類も多いなら上振れ側とみて厚めに積む
単一システム内で完結し、データの種類が限られるなら下振れ側で置く

初回はこの分岐で仮置きし、実績が出た時点で自社の割合へ補正します。実行工数の付属品として扱うと、確実に不足します。

顧客レビュー・確認待ちのリードタイムが入っていない

受け入れ確認や仕様の解釈確認で、作業が止まる時間があります。「この挙動は仕様どおりか」の回答が翌週になることも珍しくありません。

これは自社でコントロールできない工数のため、見積もりの外に置かれがちです。しかし日程には確実に影響します。

対処は、工数として積むのではなく前提条件として明記することです。「仕様確認の回答は3営業日以内にいただく前提です」と書いておけば、遅延時に日程を見直す根拠になります。契約面での考え方は、IPAのモデル取引・契約書で前提条件の扱いを確認すると参考になります。

一次見積もりには「前提条件」を必ずセットで書く

どの技法で数字を出すかは、テスト工数の見積もり精度を決める主因ではありません。類推法でも係数法でも三点見積もりでも、前提が書かれていなければ結果は同じです。

技法を学ぶより先に、前提を書く習慣をつけるほうが効果が出ます。

見積もりは「数字」ではなく「数字＋前提」で1セット

見積もりを求められたとき、返すのは数字だけになっていないでしょうか。「テスト工数は15人日です」という回答は、一見明快です。

しかしこの数字は、状況が変わった瞬間に根拠を失います。仕様が追加されても環境の提供が遅れても、その15人日がなぜ変わるのかを説明できません。

前提を書いていない見積もりは、外れたときに守るものがありません。

逆に前提があれば、「前提としていた対象画面が12から18に増えたため、再見積もりをさせてください」と言えます。値上げ交渉ではなく、事実の共有になります。

テスト見積もりで明記すべき前提条件

何を書くか迷う場合は、次の7項目から始めてください。崩れやすい前提の大半をカバーできます。

対象テストレベル: どの工程のテストか。単体テストは開発工数に含むか別建てか
テスト対象範囲: 対象の画面・機能と、対象外とするもの
想定不具合件数と再テスト回数: 何件見込み、確認テストと回帰テストを何回行うか
テスト環境の提供時期と提供者: いつまでに誰が用意するか。提供完了をテスト開始の条件とする
顧客確認のリードタイム: 質問への回答期限をどう見込むか
テスト担当者の稼働率: 1日の何割をテストへ充てられる想定か（暫定値なら明記する）
仕様確定のタイミング: いつ以降の変更を仕様変更として扱うか

見積書に記入欄がなければ、提出時のメール本文に書くだけでも構いません。合意の記録が残っていることが重要です。

前提が崩れたら再見積もりする、を最初に合意しておく

前提を書いただけでは足りません。崩れたときにどうするかも、先に決めておきます。

Lee Copelandは探索的テストのアプローチを説明する文脈で、次のように述べています。「『仕事を計画し、計画に従って仕事する』というやり方ではなく、常に『仕事を計画し、計画に従って仕事し、仕事を見直し、計画を見直す』ようにしましょう」。

これは見積もりにも読み替えられます。一度出して終わりという前提が、そもそも無理なのです。

実務では、発動条件を数値で決めておきます。「想定した不具合件数を一定の割合超えたら、再見積もりの協議に入る」といった形です。閾値は自社の実績から設定してください。

ただし、打てる手は契約形態で変わります。準委任なら工数の追加を協議できますが、請負・固定価格では仕様変更と認められない限り追加費用は通りません。

請負の場合は、追加費用ではなく交換条件として切り出すのが現実的です。「テスト範囲を優先度の高い領域に絞る」「リリース日を調整する」の2案を並べ、どちらを取るかを相談します。

前提条件は見積書だけでなく、契約前の合意メモにも残してください。メール1通の記録でも、あとから前提を持ち出す根拠になります。

見積もりのズレは「リリース直前」ではなく途中で検知する

見積もりを完璧に当てるのは不可能です。目指すのは、外れていることに早く気づく仕組みです。リリース直前に発覚すれば、打てる手は残業か品質妥協しか残りません。しかし前半で気づけば、範囲の調整も体制の追加も交渉できます。

消化率だけを見ていると、ズレは最後まで見えない

進捗会議で報告するのは、消化率だけになっていないでしょうか。「予定どおり40%消化しています」は安心材料に見えます。

しかし消化率が計画どおりでも、検出件数が想定を大きく超えていれば後半に再テスト工数が膨らみます。消化した40%の裏で、確認し直すべき作業が積み上がっているからです。

布施昌弘ほか『ソフトウェアテストの教科書』では、テスト実施のモニタリング指標として次の4つを挙げています。

テスト実施率
消化率
不具合検出率
残存不具合予測値

さらに、不具合の検出累計を時系列で描く信頼度成長曲線を使います。曲線はS字を描くのが前提です。飽和に近づいていれば収束、右肩上がりなら追加テストが必要と判断します。

つまり、進捗と品質の2軸を組み合わせて読む必要があります。片方だけでは、ズレは最後まで見えません。

中間チェックポイントの置き方

見る指標の次は、いつ見るかです。日次で全指標を追うのは兼任体制に重すぎるため、区切りを設けます。

タイミング	見る指標	判断とアクション
テスト着手前（開始判定）	環境・データ・対象ビルドの準備完了	未完了なら着手日を後ろ倒しし、日程影響を即共有
全体の3割消化時点	消化率と不具合検出件数	検出件数が想定を大きく超えていないか
全体の5割消化時点	確認テスト・回帰テストの実績工数	1件1回で終わらず回数が想定を超えていないか
全体の7割消化時点	検出の推移＋消化率＋未着手領域の有無	検出が収束せず右肩上がりのままでないか

とくに重要なのが3割時点です。3割消化時点で検出件数が想定を大きく超えていれば、見積もりの前提が崩れている可能性が高いと判断します。

ただし、超過率をそのまま残り7割に掛けて外挿してはいけません。高優先度の領域から実行している場合、検出は前半に偏るためです。あくまでズレを疑うシグナルとして扱ってください。

7割時点も単独の指標では判断できません。曲線が寝ていても、実行が止まっている、未消化領域が残っている場合は収束ではありません。

この時点なら、まだ交渉の余地があります。リリース日の調整、テスト範囲の絞り込み、要員の追加。残り1週間では選べない選択肢です。

消化率をリアルタイムに把握していない現場も多いはずです。その場合は既存の日報や進捗シートに、「その日の消化件数」「その日の検出件数」を書く行を足すだけで足ります。

台帳の整備が難しければ、3割・5割・7割をテスト期間の日付に置き換えて先に固定します。「開始から3日目に見る」と決めておけば、常時計測なしでも運用できます。チェックポイントは既存の定例会議に組み込むのが続けるコツです。

検出件数が想定を超えたときの打ち手

想定を超える不具合が出たとき、全量のテストケースを守ろうとすると破綻します。時間は増えないのに、確認すべき作業だけが増えるからです。

とるべきは優先順位の付け直しです。障害時の影響度と発生しやすさの2軸で並べ替え、影響が大きく壊れやすい箇所に工数を寄せます。

体系的に押さえたい方は、リスクベースドテストで優先順位を付け直す方法を読むと判断軸が整理できます。指標の取り方に不安があるなら、テスト進捗管理の指標の取り方を確認するから始めても構いません。

なお、テストのモニタリングやテスト見積もりという用語には、国際標準に基づく定義があります。社内で言葉をそろえたい場合は、JSTQBのシラバスでテストのモニタリング定義を確認すると共通言語をつくりやすくなります。

テスト工数の実績データをゼロから貯める最小記録セット

ここまでの話には共通の前提があります。想定検出件数も再テスト回数も実効稼働率も、自社の実績がなければ置けません。記録がゼロの会社には、そこが最大の壁です。

公的な定量データも公開されています。IPAのソフトウェア開発分析データ集で定量データの見方を確認すると、業界全体で集計されている指標の参考になります。ただし他社の平均値を自社へそのまま当てるのは危険です。使うべきは自社の数字です。

記録すべきは5項目だけでいい

詳細な工数管理を目指すと、必ず続きません。記録する項目は次の5つに絞ってください。

記録項目	内容	次回見積もりでの使い道
見積もり工数	着手前に出した数字（前提条件込み）	実績との比較の基準
実績工数	実際にかかった工数	超過率の算出
不具合検出件数	検出した件数（重要度別が理想）	確認テスト工数の想定根拠
再テスト回数	確認と回帰をそれぞれ何回行ったか	再テスト係数の算出
中断・待機時間	修正待ち・確認待ちで止まった期間	実効稼働率の算出

記録するのは5項目だけです。ツールの導入も新しい仕組みも必要ありません。

待機時間は分単位で測る必要はありません。「待ちが発生した日数」「半日単位で止まった回数」といった粗い粒度で十分です。それでも負担なら、初回は待機時間を外した4項目から始めてください。

表計算ソフトのシート1枚で足ります。案件名を行にして5つの列を埋めるだけです。記録項目は前章の構造的原因と対応しており、記録がそのまま検証データになります。

1案件目から効き、3案件で自社の癖が見える

記録の効果が出るのは3案件先と思われがちですが、実際には1案件目から使えます。

実績工数が1件でも出れば、次の一次見積もりの妥当性チェックに使えます。「前回この規模で◯人日かかったのに、今回の見積もりはそれを下回っていないか」という照合ができるからです。

費用対効果も1案件で試算できます。次の式に自社の数字を入れます。

持ち出し額＝（実績工数 − 見積もり工数）× 自社の1人日あたり単価

請負なら、超過分はそのまま自社の持ち出しです。一方、記録にかかる手間は案件あたり30分程度です。「記録30分」と「超過◯人日の金額」を並べれば、上長への説明は成立します。

3案件を並べると、さらに景色が変わります。どの案件でも同じ項目が超過していれば、偶然ではなく自社の癖です。たとえば毎回、回帰テストが想定を大きく上回っていたなら、次の見積もりに係数として掛けられます。

記録が続かない現場の共通点

記録を始めたのに2案件目で止まる。この失敗には共通点があります。

項目を増やしすぎる（工程別・担当者別まで細分化してしまう）
記録の担当者を決めていない（全員の仕事は、誰の仕事でもなくなる）
案件終了後にまとめて書こうとする（記憶が曖昧になり精度が落ちる）
記録を見返す場を設けていない（貯めるだけで使わないと形骸化する）

対策は3つです。

記録の担当者はPM本人が持つ。他人に振ると優先度が下がり、必ず止まる
案件クローズ時の振り返りに、30分の枠として組み込む
振り返りの場がない現場は、次案件の見積もりを作るタイミングで前案件の5項目を埋める

使う場面が決まっていれば、記録は目的を持ちます。

記録は外注判断の材料にもなる

実績工数が見えると、副次的な効果も生まれます。「自社でテストすると、この規模でこれだけかかる」という数字を持てることです。

これは内製と外注を比較する土台になります。感覚で「外注は高い」と判断していた状態から、実費との比較へ移れます。上長への説明の組み立て方は、実績工数を使った費用対効果の説明方法を読むと、具体的な流れがつかめます。

見積もりの根拠を顧客・上長に説明して守る

正しく積んだ工数も、説明の仕方によっては削られます。ここでは削られない出し方を扱います。

「バッファ」と呼ぶから削られる

見積書に「予備工数」「バッファ」という行があると、真っ先に交渉対象になります。名前そのものが「なくても何とかなるもの」を意味するからです。

同じ工数でも、内訳に組み込めば扱いが変わります。「確認テスト工数：想定検出件数から算出」「回帰テスト工数：影響範囲の再実行分」と書けば、削るには根拠が必要になります。

バッファは削られますが、内訳のある工数は削るのに理由が要ります。

削られやすい出し方	守れる出し方
バッファとして一括で積む	確認・回帰・準備・待機を項目別に積む
「念のため多めに見ています」	「想定検出件数から逆算した工数です」
合計金額だけを提示する	作業項目ごとの内訳を提示する
前提条件を書かない	前提が変わった場合の扱いを併記する
交渉されたら一律で削る	どの項目を削るとどのリスクが増えるか示す

前提条件つきで出す

数字を提示する場では、前提も口頭に出してください。「環境が◯日までに提供され、確認依頼への回答が3営業日以内という前提です」と伝えます。

そのうえで「前提が変わった場合は、再見積もりのご相談をさせてください」と加えます。この一言の有無で、後半の交渉のしやすさが変わります。

前提条件やスコープ変更時の扱いは、先に挙げたIPAのモデル取引・契約書の考え方が参考になります。書式を流用しなくても、どこを合意すべきかのチェックリストとして役立ちます。

実績データは最強の交渉材料

前章で貯めた記録が、ここで効いてきます。「感覚的に多めに見ています」と「過去の案件では、この規模で想定の1.4倍かかっています」では、説得力がまったく違います。

なお、この1.4倍は説明のための架空の例です。使うべきは自社の記録から算出した数値です。他社の平均値や記事の相場を持ち込むと、その場で根拠を問われて崩れます。

自社データの強みは、相手が反論しにくい点です。同じ会社の、同じチームの記録だからです。感覚論を数字に変える。それが実績記録の最大の使い道です。

テスト工数の見積もり精度が上がると、削減できる工数が見える

ここまでは「当てる」ための話でした。最後に、精度が上がった先に何が見えるかを整理します。

削減対象は「実績が見えている工数」からしか選べない

「テスト工数を削減したい」という相談は多くあります。しかし議論の前に必要な情報があります。どの作業に何時間かかっているか、という内訳です。

内訳がわからないまま進めると、削りやすいところから削ります。多くの場合それはテストケースの件数で、結果として品質だけが下がります。

削減できるのは、どこに何時間かかっているかが見えている工数だけです。

実績が示す典型的な削減候補

記録を続けると、削減候補が浮かび上がります。典型的なのは次の3つです。

繰り返し実行している回帰テスト: 毎回同じケースを手動で流している箇所
環境・データ準備の手作業: 案件ごとに同じ手順を繰り返している箇所
待機時間が集中している工程: 修正待ち・確認待ちで止まりやすい箇所

自動化の投資判断も、実績があって初めて成立します。林尚平『ソフトウェアテスト自動化の教科書』では、計画段階で手動テストと自動テストの作業内容・工数を書き出し、削減の分岐点を見積もることを勧めています。

同書は、自動化したテストを5回以上実施しなければ作成工数を取り返せないとしています。記録した実行回数がこの水準に届くかどうかが、最初の判断軸になります。

つまり、手動で何時間かかり年に何回繰り返しているか、という実績が要ります。記録がなければ、自動化すべきかも判断できません。

精度改善と工数削減はセットで回す

精度が上がる、内訳が見える、削減対象が特定できる。この順序は入れ替えられません。

削減の進め方まで踏み込みたい方は、テスト工数を削減しながら品質を保つ方法を読むと、次の一手が見えてきます。

テスト工数の見積もり精度に関するよくある質問

現場からよく挙がる疑問を、次の3点に整理しました。

なぜ毎回外れるのか
何から始めればよいか
実績がないときはどうするか

テストの見積もりが毎回外れるのはなぜですか

確認テストと回帰テスト、修正待ち、実効稼働率、環境とデータの準備、顧客確認待ちが工数表から抜けているためです。技法ではなく積み方の問題です。

見積もり精度を上げるには何から始めればよいですか

前提条件を書いて出すことから始めます。数字だけの見積もりを「数字＋前提条件」に変えれば、外れたときに守る根拠ができます。

実績データがない場合はどうすればよいですか

初回は欠陥密度や類似案件の概数を暫定値で仮置きし、前提条件に暫定と明記します。1案件分の実績が出れば、次の見積もりの照合に使えます。

まとめ：見積もりが外れるのは能力ではなく仕組みの問題

本記事の要点を整理します。

構造的原因は、再テスト（確認・回帰）・バグ修正待ち・実効稼働率・環境とデータ準備・顧客確認待ちの5つ
確認テストと回帰テストは性質が違う。1本にまとめず、別の行として積む
見積もりは「数字＋前提条件」で1セット。前提がなければ、外れたときに守るものがない
ズレはリリース直前ではなく、3割消化時点で「前提が崩れたシグナル」として拾う
実績記録は5項目でよい。1案件目から照合に使え、3案件で自社の癖が見える

見積もりの精度は、才能ではなく記録の積み重ねで決まります。

まず次の1案件から始めること

新しい仕組みを導入する必要はありません。表計算ソフトに5列の表を1枚だけ作ってください。

次の案件がクローズしたら、振り返りの最後に30分使って埋める。それを3案件続ければ、自社の見積もりの癖が数字で見えます。

記録の結果、自社の工数だけでは品質を担保しきれないと分かることもあります。想定の何倍にも膨らむ、兼任では検出しきれない領域がある、といった形です。その段階まで来たら、テスト体制の見直しについて相談することも選択肢のひとつです。数字が出てからのほうが、社内でも判断しやすくなります。

次に読むならこの記事

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

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

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

よかったらシェアしてね！