QA・テストの修正を何回まで受けるか｜先に決めておく

2026年9月11日

朝比奈蒼

この記事のポイント

✓QA・テストの修正対応を何回まで受けるかを
✓契約前に決めておくための考え方をまとめました
✓再テストの単位の決め方

QA・テストの仕事で修正対応を何回まで受けるか。結論から言うと、回数を決めるより先に、何を1回と数えるかを決めるべきです。回数だけ先に決めても、数え方が揃っていなければ、その回数は機能しません。

この分野の業務委託で稼働が読めなくなる原因は、テストの実行そのものではありません。不具合を報告し、修正されたものを確認し、また別の箇所が壊れて、また確認する。この往復が想定より増えることで、稼働が膨らみます。しかも往復の回数は、こちら側の作業の質ではなく、開発側の状態と、仕様の固まり具合で決まる。つまり、自分では制御できない要因で稼働が伸びるという特徴があります。

正直なところ、この構造を理解しないまま「テスト実施一式」で受けている人が多すぎます。この記事では、修正対応の範囲をどう定義するか、回数の決め方にどんな方式があるか、超えたときにどう扱うか、そして見積もりや契約書に何と書くかを順番に整理します。

修正対応という言葉が、そもそも同じ意味で使われていない

最初に用語を揃えます。ここが揃っていないことが、揉め事のほぼすべての原因です。

QAの現場で修正対応と呼ばれるものには、少なくとも4つの異なる作業が含まれています。1つ目が、報告した不具合が直ったかを確認する作業。2つ目が、修正によって他の箇所が壊れていないかを確認する作業。3つ目が、修正の結果として仕様が変わった箇所を、テストの設計から作り直す作業。4つ目が、報告した内容について開発側から質問を受け、再現手順を追加で調べる作業。

この4つは、かかる時間がまったく違います。1つ目は短時間で済みますが、3つ目は最初にテストを設計したときと同じ規模の作業になります。それなのに、どれも「修正対応」と呼ばれ、同じ1回として数えられてしまう。ここに無理があります。

依頼側から見ると、この違いは見えません。開発側は「1行直しただけ」という認識でいますが、その1行が共通の処理であれば、確認すべき範囲は広がります。だから、こちらから範囲の違いを説明する必要があります。説明しなければ、すべてが同じ1回として処理されます。

用語を揃えるには、契約前の段階で、この4つを別の名前で呼ぶ提案をします。確認、影響範囲の確認、設計のやり直し、調査。名前を分ければ、扱いを分けられます。名前が同じままだと、扱いを分ける根拠がありません。

工程によってテストの目的が違うことを共有する

もうひとつ、前提として共有すべきことがあります。テストは一枚岩ではないという点です。

テストとして一言で表現されるケースもありますが、実際はいくつかの工程ごとに分けられます。工程ごとにQAの方法やテスト手法が異なるため、テストの目線や目的を知ることが、要件に沿ったプロダクトを開発する上では重要です。例として、ウォーターフォール型の開発モデルを例に各テスト工程を解説します。出典: blog.autify.jp

工程ごとに目的が違うということは、修正対応の意味も工程ごとに変わるということです。単体の確認の段階で見つかった不具合の修正確認は軽い。一方、結合の段階や、システム全体を通した段階で見つかった不具合は、修正の影響が広く、確認すべき範囲も広くなります。

さらに、受け入れの段階で「仕様と違う」という指摘が出た場合、それは不具合の修正ではなく仕様変更です。仕様変更に伴うテストは、修正対応の回数に含めるべきではありません。ここを含めてしまうと、仕様が動くたびに無償で作り直すことになります。

だから見積もりの段階で、どの工程を担当するのかを明記します。担当する工程が決まれば、想定される修正対応の重さも見積もれます。工程を書かずに「テストを担当」とだけ書くと、あらゆる工程の作業が飛んできます。

回数を決めないと、なぜ無限に増えるのか

構造を説明します。修正対応の回数が増える要因は、3つあります。

1つ目が、修正による新たな不具合です。ある箇所を直すと、別の箇所が壊れる。この現象は開発では珍しくなく、規模が大きくなるほど起きやすくなります。壊れた箇所を報告すれば、また修正され、また確認が必要になる。この連鎖は、理論上は無限に続き得ます。

2つ目が、仕様の揺れです。テストを進める中で、仕様書に書かれていない挙動が見つかる。開発側に確認すると「そこは仕様を決めていなかった」という答えが返ってくる。そこから仕様が決まり、実装が変わり、テストの設計から作り直しになります。この作業は、当初の見積もりには入っていません。

3つ目が、報告の解釈のずれです。報告した不具合が「仕様通りです」と返され、それに対してこちらが根拠を示し、また議論になる。この往復は、テストの実行時間としては計上されにくいのに、実際にはかなりの時間を消費します。

この3つはどれも、こちらの作業の質を上げれば減るというものではありません。開発側の状態と、仕様の成熟度に依存します。だからこそ、回数の上限か、稼働の上限か、期間の上限のいずれかを設けないと、際限がなくなります。上限を設けるのは、相手を縛るためではなく、双方が予算と工数を見積もれるようにするためです。

何を1回と数えるかを決める

回数を決める前に、単位を決めます。ここが実務のいちばん重要な部分です。

考え方は、リリースの単位で数えるのが最も実務に合います。つまり、開発側から「修正しました」と1つの塊で渡されたものを1回と数える。個々の不具合ごとに数えると、細かい修正が10件来たときに10回として扱うことになり、現実的ではありません。逆に、期間で区切ってしまうと、その期間に何回渡されても1回になり、こちらが損をします。

この方式にする場合、開発側にも協力してもらう点があります。修正をまとめて渡してもらうことです。1件直すたびに個別に確認を依頼されると、確認の準備だけで時間が溶けます。テスト環境の準備、データの用意、前提条件の設定。これらは1回の確認であっても必要な作業なので、まとめてもらうほど効率が上がります。

まとめてもらう依頼は、こちらの都合ではありません。開発側にとっても、確認の結果がまとまって返るほうが、次の修正の計画を立てやすくなります。この説明をすると、たいてい合意できます。

あわせて、確認の対象範囲も定義します。報告した不具合の該当箇所だけを確認するのか、その周辺も確認するのか、全体を通した確認まで行うのか。範囲によって、かかる時間が桁違いに変わります。「修正確認は、報告した項目と、その修正が影響する範囲として合意した項目に限る」という書き方をしておくと、全体の再実行を毎回求められる事態を防げます。

回数の決め方は3つの方式がある

上限の設け方には、大きく3つの方式があります。案件の性質で使い分けます。

回数で区切る方式

もっとも分かりやすい方式です。「修正確認は2回まで。それを超える場合は追加のお見積もりとします」という形で書きます。仕様が固まっていて、修正の規模が読める案件に向いています。

利点は、依頼側が予算を見積もりやすいことです。欠点は、1回あたりの重さがばらつく点です。軽い修正の確認も、大規模な影響範囲の確認も同じ1回として消費されるので、重い回が続くと苦しくなります。この欠点を補うには、1回あたりの想定規模を併記します。「1回あたりの確認対象は、報告項目とその影響範囲を合わせて、おおむね半日程度の作業量を想定」といった書き方です。

稼働の量で区切る方式

回数ではなく、作業時間の上限で区切る方式です。「修正確認および再テストに充てる稼働は、月あたり一定の時間までとし、超過分は別途協議」という形になります。

この方式は、修正の規模が読めない案件に向いています。軽い修正なら回数を多く受けられますし、重い修正なら少ない回数で上限に達します。実態に即しているので、こちらの損は少なくなります。

欠点は、作業時間の記録と共有が必要になることです。何にどれだけ時間を使ったかを示せないと、上限に達したという主張の根拠がありません。記録を取る手間はかかりますが、この記録自体が信頼の材料にもなります。

期間で区切る方式

「テスト期間はこの日からこの日まで。期間内であれば修正確認の回数は問わない」という方式です。開発と並走する形の案件でよく使われます。

利点は、双方が動きやすいことです。開発側は細かく修正を渡せますし、こちらも柔軟に対応できます。欠点は、期間の終盤に修正が集中したときに、こちらの稼働が跳ね上がる点です。この欠点を補うには、期間内であっても1日あたりの稼働の上限を書いておきます。また、期間の延長が必要になった場合の扱いも先に決めておきます。延長の扱いを書いていないと、無償の延長を求められます。

どの方式を選ぶかは、仕様の固まり具合と、開発側の進め方で決まります。仕様が動く案件で回数制を選ぶと、必ず超過します。逆に、仕様が固まっている案件で期間制を選ぶと、こちらの提示額が高く見えて選ばれにくくなります。

差し戻しが増える原因を、こちら側で減らす

上限を決めることと並行して、往復そのものを減らす工夫もします。ここは自分で制御できる部分です。

最も効くのが、不具合の報告の質です。再現手順が曖昧な報告は、開発側で再現できず、質問が返ってきます。質問に答えるための調査は、こちらの稼働です。だから報告の段階で、環境、前提条件、操作の手順、期待した結果、実際の結果、発生の頻度を漏れなく書きます。書く手間より、往復を減らす効果のほうが大きい。

次に効くのが、影響範囲の推定を添えることです。「この不具合は共通の処理に起因している可能性があるため、同じ処理を使う他の画面でも同様の事象が起きる可能性があります」と一言添えると、開発側はまとめて直せます。まとめて直せば、確認も一度で済みます。これは相手の仕事を減らす行為であると同時に、自分の往復も減らす行為です。

もうひとつ、優先度の判断を添えることも有効です。すべての不具合を同じ重さで報告すると、開発側は何から直すか決められません。決められないと、修正が分散し、確認の回数が増えます。事業への影響で優先度を分けて示すと、重要なものからまとまって修正され、確認の回数が減ります。

必要なのは、テストを実行する技術だけではありません。

QAを実施する上で必要となるスキルには、知識や適性だけでなく、実践的な経験なども含めてミッションを達成する能力が求められます。優れたテスト担当者を目指すには、チームにおいてさまざまな視点を持つプレーヤーとしての立ち回りが必要です。出典: blog.autify.jp

立ち回りという表現が使われているのは、この分野の成果が、単独の作業量ではなくチーム全体の進み方で決まるからです。往復を減らす工夫は、まさにその立ち回りにあたります。

上限を超えたときの手順を先に書く

上限を決めても、超えたときの手順が書いていなければ意味がありません。超えた瞬間に、その場の交渉になります。

書くべき手順は3つ。1つ目、上限に近づいた時点で通知すること。超えてから言うのではなく、残りが少なくなった時点で伝えます。「予定していた確認の回数のうち、残り1回となりました」という連絡です。この通知があると、依頼側は社内で予算や日程を調整できます。通知せずに超えてから請求すると、後出しに見えます。

2つ目、超過分の内容と量を示した追加の見積もりを出すこと。何をどれだけ行うのかを具体的に書きます。3つ目、承諾を得てから着手すること。口頭ではなく、メッセージなど記録が残る形でもらいます。

この手順を最初の見積もりの備考に一文で書いておけば、超過は事務手続きとして処理できます。書いていないと、感情のやり取りになります。

例外として、緊急のリリースに関わる確認は、手順を待てない場合があります。この場合の扱いも先に決めます。「緊急を要する場合は先行して着手し、事後に精算する」と書いておけば、動きを止めずに済みます。

見積もりと契約書に書く文言

実際に書く内容を整理します。項目としては次のようになります。

担当する工程。単体、結合、システム全体、受け入れのどこを担当するのか。テストの設計を含むのか、実行のみか。テストの設計を含む場合、仕様変更に伴う設計の作り直しをどう扱うか。

修正確認の単位。何をもって1回と数えるか。まとめて渡してもらう運用にするかどうか。

上限。回数、稼働、期間のいずれかで設定し、その根拠となる想定規模を併記する。

範囲外の作業。仕様変更に伴う設計のやり直し、テスト環境の構築、テストデータの作成、開発側の調査への同席、報告書の体裁を整える作業。これらを含むのか含まないのかを明記します。特にテスト環境の構築は、含まれていると思われがちで、実際にはかなりの時間を要する作業です。

報告の形式と頻度。どのツールで報告するか、日次の共有が必要か、最終的な報告書を提出するか。報告書の作成は、テストの実行とは別の作業なので、分けて書きます。

支払い条件。締め日と支払期日。業務委託の報酬の支払いについては、2024年施行のフリーランス保護新法で、発注者は成果物を受け取った日から起算して60日以内のできる限り短い期間内に支払期日を定める義務があるとされています。制度の内容は公正取引委員会や厚生労働省の案内で確認できます。テストの工程は開発の最後に置かれることが多く、リリースの遅れに引きずられて支払いが遅くなりやすいので、ここは明確にしておく価値があります。

報告の扱いで揉めたときの整理の仕方

報告した内容が「仕様通りです」と返されることは、日常的に起きます。この往復が長引くと、確認の回数に含まれない稼働だけが増えていきます。

整理の順番を決めておくと、この往復は短くなります。まず、どの資料を根拠にしているかを示します。仕様書のこの記載、あるいは既存の挙動、あるいは一般的な利用者の期待。根拠の種類を明示すると、議論の軸が定まります。仕様書に書かれていない挙動について議論しているのか、書かれているが解釈が分かれているのかで、進め方が変わるからです。

仕様書に記載がない場合は、不具合ではなく確認事項として扱います。「不具合」と書くと、開発側は否定から入ります。「仕様に記載がないため、意図された挙動かご確認ください」と書けば、事実の確認として処理されます。同じ内容でも、通り方がまったく違います。

そのうえで、判断が分かれたまま平行線になったら、判断者を明確にします。この機能の仕様を最終的に決める人は誰か。その人に判断を仰いで、決まった内容を記録に残す。こちらが説得する必要はありません。品質の担当者の役割は、事実と影響を示すことであって、意思決定そのものではないからです。

この線引きを持っていると、消耗が減ります。報告の質を上げることには時間を使う価値がありますが、決定権のない議論を続けることには価値がありません。

テスト環境とデータの用意を誰がやるか

見積もりから漏れやすく、実際には大きな時間を食う項目がこれです。修正確認の回数を決めても、毎回の確認のたびに環境の準備が必要なら、回数の重みがまったく変わります。

まず環境です。確認用の環境が常時用意されているのか、確認のたびに構築されるのか、こちらが自分で用意するのか。開発側が環境を用意する場合でも、修正が反映されるタイミングがずれると、こちらは待ち時間を抱えます。待ち時間は作業時間として計上しにくく、しかしその時間は他の仕事に使えません。この点は、稼働の上限を決めるときに考慮すべき要素です。

次にデータです。特定の状態を再現するために必要なデータを、誰が作るのか。会員の状態、注文の履歴、権限の組み合わせ。こうしたデータの作成は、テストの実行とは別の作業です。にもかかわらず、テストの一部として当然のように期待されることが多い。含めるなら見積もりに行を立て、含めないなら備考に明記します。

さらに、環境が不安定な場合の扱いも決めておきます。確認しようとしたら環境が動いていない、データが初期化されている、他の担当者の作業とぶつかっている。この種の待機や再試行が続くと、確認の1回が半日仕事になります。「環境の不具合により確認が実施できなかった場合、その稼働は作業時間に含める」と書いておくのが公平です。

環境の話を先に詰めておくと、依頼側にも利点があります。環境の整備が遅れると全体の日程が押すという事実が、数字として見えるようになるからです。見えれば、社内で優先度が上がります。

リリース直前の駆け込みに備える

この分野で稼働が跳ねる典型的な場面が、リリース直前です。開発の遅れは、その後ろに置かれたテストの期間を圧迫します。しかもリリース日は動かないことが多い。結果として、短い期間に修正と確認が集中します。

備え方は3つあります。1つ目は、日あたりの稼働の上限を先に書いておくことです。「1日あたりの対応時間は一定の範囲とし、これを超える対応は別途協議」と定めておけば、深夜や休日に無制限で巻き込まれる事態を避けられます。上限を書くことは、品質を守る手段でもあります。疲れた状態での確認は、見落としを生みます。

2つ目は、優先度の判断基準を事前に合意しておくことです。時間が足りなくなったとき、何を確認して何を見送るかを、その場で決めるのは危険です。事業への影響が大きい機能、決済や個人情報に関わる箇所、直近で変更が入った箇所。この順で確認するという基準を先に合意しておけば、時間が足りない状況でも判断が速くなります。

3つ目は、見送った項目を記録として残すことです。確認できなかった範囲を明示して報告すれば、リリースの判断は依頼側が行えます。「全部見た」と言えない状態で黙って渡すのが、最も危険です。記録があれば、後日問題が起きたときに、何が確認されていなかったかが分かります。

駆け込みの局面で丁寧な記録を残せる人は、この分野で強く評価されます。混乱している状況ほど、記録を残す相手が信頼されるという傾向が見られます。

呼び方が現場ごとに違うことを前提にする

もうひとつ、実務上の注意点があります。QAという言葉の指す範囲が、組織によって違うという点です。

ただし、実際のソフトウェア開発の現場では、QAとQCを厳密に区別せず、テスト活動や品質管理を含む幅広い活動をまとめて「品質保証（QA）」と呼ぶことが多くあります。QAエンジニアの業務内容が企業によって大きく異なるのも、こうした背景からです。出典: magicpod.com

つまり、同じ「QAをお願いします」という依頼でも、テストの実行だけを指す場合と、品質の基準づくりやプロセスの改善まで含む場合があります。後者を前者の想定で受けると、稼働が何倍にもなります。

だから初回の打ち合わせで、その組織における言葉の使い方を確認します。「御社では、QAの担当者はどこまでの範囲を担当されていますか」「テストの設計は誰が行っていますか」「品質の基準は文書化されていますか」。この3つを聞けば、範囲の実態がつかめます。

言葉の定義を確認するのは、細かいことにこだわっているように見えるかもしれません。しかしこの分野では、定義の違いがそのまま稼働の差になります。確認しない人が損をする構造なので、遠慮せずに聞くべきです。

自動化を持ち出すべきかどうか

修正確認の回数が多い案件では、自動化の話が出ることがあります。繰り返し実行する確認を自動化すれば、往復の負担は下がります。

ただし、自動化を提案するかどうかは慎重に判断します。自動化の仕組みを作る作業は、テストを実行する作業とはまったく別の仕事です。作る手間がかかり、仕様が変わるたびに直す手間もかかる。仕様が動いている段階の案件で自動化を作ると、作ったそばから壊れます。

判断の目安は、同じ確認を繰り返す回数が多く、かつ対象の仕様が安定しているかどうかです。両方を満たすなら、自動化は効きます。片方でも欠けるなら、手作業のほうが早い。

提案する場合は、自動化の構築を別の契約として切り出します。運用中の契約に混ぜ込むと、構築の工数が修正確認の回数に紛れて、どちらの成果も見えなくなります。別立てにすれば、構築の成果を数字で示せますし、次の案件への実績にもなります。

現場を長く見てきた立場からの観察

フリーランスと在宅ワークの市場を20年運営してきた立場から見ると、この分野で長く続く人には共通点があります。範囲を決める会話を、契約の前に自分から持ちかけていることです。範囲の話を切り出すのは気まずいと感じる人が多いのですが、実際には逆の反応が返ってきます。依頼側の担当者も、社内で工数を説明する立場にあるので、範囲がはっきりしているほうが助かるのです。

運営者として見てきた限りでは、往復の多い仕事ほど、間に人が入らない直接の取引が効きます。仲介が入ると、報告と質問のやり取りが伝言になり、往復が増える。伝言のたびに情報が落ち、再現手順の細部が欠け、また確認が必要になる。手数料が乗らないぶん、依頼側は同じ予算でより多くを頼めますし、受け手の手取りは厚くなる。手数料0%の直接取引が効くのは、金額の話だけではなく、やり取りの精度が落ちないという点でもあります。

この分野でどういう依頼が動いているかは、QA・テスト・コードレビューのお仕事のページで業務の内容が整理されています。担当する工程や、求められる成果物の形が案件によって違うことが分かるので、範囲を決める会話の材料になります。品質の話は運用や監視の領域とも接しており、AI・マーケティング・セキュリティのお仕事で扱われている仕事とも隣り合っています。

技術の裏付けを整理したいなら、体系立った資格を通しておくのも一つの手です。ネットワークの基礎を扱うCCNA（シスコ技術者認定）は、環境まわりの不具合を切り分けるときに効いてきます。報告書や仕様の確認文書の書き方に不安があるなら、ビジネス文書検定のような文書作成の体系が役に立ちます。この分野の成果は、報告の伝わり方でかなり左右されます。

自分の稼働をどう位置づけるかの目安としては、職種別の水準を整理したソフトウェア作成者の年収・単価相場のようなページで、市場の水準を確認しておくと判断の助けになります。働き方の形も一つではなく、後半のキャリアで独立する道を扱った定年後のフリーランス独立｜退職金を活かした起業プランと注意点のような選択肢もあります。

最後に、見積もりを出す前の確認の仕方をひとつ。作った見積もりを読み返して、「修正が想定の3倍来たときに、この紙で説明できるか」を確認してください。説明できないなら、単位か上限か手順のどれかが欠けています。欠けている箇所を埋めてから出すと、稼働が読める仕事になります。