QA・テストの見積もりの作り方｜あとで足せない項目

2026年7月4日

朝比奈蒼

この記事のポイント

✓QA・テストの見積もりの出し方を
✓手法の使い分けと項目の立て方から整理します
✓報告といった内訳の作り方と

結論から書きます。QA・テストの見積もりで失敗する原因は、作業量の読み違えではありません。見積書に書いていない作業が発生し、それを後から追加できないまま吸収してしまうことです。テストケースを何本作るかの計算は、経験を積めばそれなりに当たるようになります。当たらないのは、待ち時間、仕様の読み解き、不具合の切り分け、再テストの回数といった、見積書の行に立てにくい項目のほうです。

QA・テストの見積もりの出し方を調べている人が本当に知りたいのは、換算式ではなく「どこまで書いておけば後で困らないか」だと考えています。この記事では、見積もりの目的の整理、手法の使い分け、内訳に立てるべき項目、そして着手後には足せなくなる項目の扱い方を、順に具体化します。

見積もりは金額表ではなく、前提の合意書

見積もりを金額を伝える書類だと考えていると、必ず削られます。実際に機能しているのは、前提条件を文章として残す部分です。何を、どの状態で受け取り、どこまでを範囲とし、何が起きたら再見積もりになるのか。この四つが書かれていない見積書は、着手後の交渉材料をひとつも持っていません。

テスト見積の目的は、予算取りのため、プロジェクト計画のため、テストを遅延なく推進するため、など様々あります。また、お客様やプロジェクト管理者だけでなく、見積に基づいて作業を行うQAエンジニアにとっても非常に重要なものです。出典: sqripts.com

ここで押さえたいのは、見積もりが発注側だけのものではないという点です。作業する側にとっての見積もりは、途中で範囲が動いたときに立ち戻る基準です。基準として機能させるためには、金額の根拠になった前提を、金額と同じ場所に書いておく必要があります。

発注側が見積もりに何を期待しているか

発注側が見積もりを求める動機は、多くの場合「社内で予算の承認を取るため」です。承認を取る人は現場の担当者ではなく、テストの中身を知らない上席であることが普通です。つまり見積書は、中身を知らない人が読んで判断できる形になっている必要があります。

この事情を理解していると、内訳の粒度が決まります。細かすぎる作業単位に割ると、読む側は判断できません。逆に一行で総額だけを出すと、削る余地の判断ができず「もう少し安く」という漠然とした差し戻しになります。判断できる単位、つまり「これは削れる」「これは削れない」を発注側が自分で選べる単位に割るのが正解です。

精度と早さのどちらを求められているか

相談の初期段階で求められる見積もりは、精度よりも桁の把握です。この段階で細部を詰めようとすると、確定していない情報を待つ時間だけがかかります。概算であることを明示し、幅を持たせて出す。そのうえで、精度を上げるために必要な情報を列挙して返す。この形にすると、情報が揃わない責任が受け手側だけに残らなくなります。

見積書の有効期限と提出後の扱い

見積もりを出したあと、返事が来ないまま時間が経つことがあります。数か月後に「あの見積もりで進めたい」と連絡が来た場合、前提としていた条件が変わっている可能性が高くなります。開発が進んで対象が増えていたり、環境が別のものに置き換わっていたりします。

対策として、有効期限を書いておきます。期限を過ぎた場合は、条件を確認したうえで再提示する旨を添えます。期限を書くことは相手を急かす行為ではなく、前提が古くなることを双方が理解するための仕組みです。提出後に相手から質問が来た場合も、質問と回答を記録に残しておくと、着手時点で認識のずれが残りません。

概算と本見積もりを分ける

相談の初期に求められる概算と、契約の直前に出す本見積もりは、書類として分けます。概算には「現時点の情報に基づく参考値です」と明記し、本見積もりで確定する項目を列挙します。この二段構えにしておくと、概算の数字が独り歩きして予算として固定される事態を避けられます。

概算の段階で桁が合わない場合は、その時点で範囲の相談に入ります。本見積もりまで進めてから金額が合わないと分かると、双方の時間が無駄になります。早い段階で桁を共有することは、断る判断を早くするためにも有効です。

テストの見積もりが難しいと言われる理由

開発の見積もりと比べて、テストの見積もりが当たりにくいのには構造的な理由があります。理由を分かっていると、どこに幅を持たせるべきかの判断が早くなります。

作業量が対象物の品質に左右される

開発は作るものが決まれば作業量がおおよそ決まりますが、テストは対象の品質によって作業量が変わります。不具合が少なければ実行は順調に進み、多ければ切り分けと報告に時間を取られ、再テストの回数も増えます。同じ機能数でも、実際にかかる時間が大きく変動します。

この変動を吸収する方法は二つあります。ひとつは、不具合の件数に上限を置いた前提を書くこと。もうひとつは、実行と再テストを分けて見積もり、再テストを実費精算にすることです。どちらも、対象の品質という自分では制御できない要因を、契約の形で切り分ける工夫です。

終わりの条件が曖昧になりやすい

どこまでやれば完了なのかを、発注側が言語化できていないことが多くあります。「品質が担保されたら」という表現は、条件ではなく願望です。完了条件を「作成したテストケースをすべて実行し、結果を報告した時点」と定義できるかどうかで、見積もりの意味が変わります。定義できない相手には、定義する作業自体を最初の工程として提案します。

上流の遅れが下流のテストに集中する

開発の遅れは、リリース日が動かない限りテスト期間の圧縮という形で現れます。見積もりの段階で十分な期間を確保していても、着手が後ろにずれれば実質的な期間は短くなります。「着手日が遅れた場合、日程の見直しを相談させていただきます」という一文を前提に入れておくと、遅れの調整を交渉として扱えるようになります。

見積もりの手法は四つを使い分ける

手法を知っておく意味は、精度を上げるためだけではありません。発注側に根拠を説明できるようになるためです。

他にも手法は様々ありますが、ここでは私のこれまでの経験上、多様なテスト見積のシーンに適用できるより汎用性の高いものに絞ってご紹介します。出典: sqripts.com

過去の類似案件から推し量る方法

似た規模、似た性質の案件の実績を基準に、差分を加減して出す方法です。もっとも早く出せて、実績が溜まっているほど精度が上がります。弱点は、比較対象を自分で選ぶため、都合の良い案件を無意識に選んでしまうことです。

対策として、比較に使った案件の条件を見積書の前提に書きます。「画面数が同程度で、外部連携を含まない案件の実績を基準としています」と書いておけば、外部連携が出てきた時点で再見積もりの根拠になります。

作業を分解して積み上げる方法

機能ごと、画面ごとに確認項目を洗い出し、それぞれの所要時間を足し上げる方法です。根拠が明確で、発注側が削る判断もしやすくなります。弱点は、洗い出しの作業自体に時間がかかることと、分解した単位に入らない作業が抜け落ちることです。

積み上げで出すときは、必ず「分解した作業以外にかかる時間」を別枠で立てます。打ち合わせ、環境の受け取り、質問の往復、報告書の作成。これらは機能単位に割れないため、独立した行にしないと消えます。

基準となる数値から換算する方法

画面数やテストケース数といった基準値に、一項目あたりの所要時間を掛けて出す方法です。説明が簡単で、発注側にとって理解しやすい形になります。弱点は、項目の難易度差が均されてしまうことです。単純な入力チェックと、複数の条件が絡む業務ロジックの確認では、同じ一項目でも所要時間が大きく違います。

換算で出す場合は、難易度の区分を先に決めます。単純、標準、複雑の三区分程度に分け、それぞれの構成比を前提として書いておくと、実物を見たときのずれを説明できます。

複数の見立てをすり合わせる方法

一人で出した数字は、その人の得意分野に引きずられます。複数の見立てを持ち寄って差が大きい箇所を議論すると、前提の食い違いが表面化します。一人で受ける案件でも、この方法は使えます。楽観的な条件で出した数字と、悲観的な条件で出した数字を両方作り、差が大きい箇所だけを重点的に詰める。差が出る箇所が、そのままリスクの高い箇所です。

内訳に立てるべき項目

どの手法で出すにしても、内訳の項目は共通です。ここに漏れがあると、後から足せません。

テストの設計にかかる時間

仕様を読み、確認する観点を決め、手順書やチェックリストの形にする工程です。実行時間だけを見積もって設計を含め忘れる例が多く、これが最初の欠落になります。設計は成果物が残るため、独立した行として立てやすい項目でもあります。

環境の受け取りとデータの準備

検証環境の確認、アカウントの発行待ち、テストデータの作成。データの準備は軽視されがちですが、条件分岐の多い機能を確認するには相応の数のデータを作る必要があります。既存データが使えるのか、自分で作るのかで所要時間が変わるため、前提として明記します。

実行にかかる時間

作った手順に沿って動かし、結果を記録する工程です。ここだけは比較的読みやすい部分ですが、一巡目と二巡目では速度が違います。一巡目には不明点の確認が挟まるため、同じ項目数でも時間がかかります。区別せずに平均で出すと、序盤で遅れが出て焦ることになります。

不具合の報告と切り分け

現象を見つけてから報告するまでの間に、再現条件の絞り込みという作業が挟まります。どの操作から発生するのか、特定の環境だけか、データに依存するのか。この切り分けは、報告の質を決める重要な工程であると同時に、時間が読みにくい工程でもあります。

修正後の再確認

不具合が直ったかを確認し、その修正が他に影響していないかを見る工程です。回数によって総量が変わるため、「一巡までを範囲とする」といった上限を前提に書きます。上限を書かないと、直らない限り無限に続く約束になります。

報告書の作成と会議への参加

実施結果をまとめ、判断材料として提出する工程です。定例会議への出席を求められる場合は、その時間も見積もりに入れます。会議は稼働として認識されにくいため、内訳の行として見せることに意味があります。

内訳を組み立てる手順を具体例で追う

抽象的な説明だけでは動けないので、よくある依頼を例に、内訳ができるまでの手順を追います。想定するのは「会員登録と問い合わせフォームを追加したので、リリース前に確認してほしい」という依頼です。

手順の一段目は、対象を数えられる形に割る

最初にやるのは、対象を数えられる単位に割る作業です。会員登録なら、登録画面、確認画面、完了画面、確認メール、ログイン、パスワード再設定。問い合わせフォームなら、入力画面、確認画面、送信完了、管理側への通知。この時点では時間を考えず、対象を並べることだけに集中します。

割った結果が発注側の認識と合っているかを、この段階で一度確認します。「今回の範囲はこの単位で認識しています」と共有すると、抜けと過剰の両方が早く見つかります。発注側が想定していなかった画面が出てくることも、逆に「その画面は今回の対象外です」と削れることもあります。

二段目は、確認の観点を決める

割った単位ごとに、何を見るかを決めます。入力値の制約、必須項目の挙動、エラーメッセージの内容、画面遷移、データの保存内容、メールの文面と到達。観点を先に決めておくと、項目数の見当がつき、難易度の区分もできます。

ここで難易度を三区分に分けます。単純な入力チェックは軽く、条件が複雑に絡む箇所は重く見ます。重い箇所には、切り分けに時間がかかる可能性があることを前提として添えます。この区分が、後から範囲を削る相談をするときの材料になります。

三段目は、機能に紐づかない作業を別枠で立てる

環境の受け取りと初期確認、テストデータの作成、仕様の不明点の確認、報告書の作成、定例会議への参加。これらを独立した行として並べます。この別枠こそが、着手後には足せなくなる部分です。機能単位の内訳に埋め込むと、金額の交渉で機能ごと削られたときに一緒に消えます。

別枠に立てておけば、発注側が「報告書は簡易でよい」と判断することもできます。判断させるためには、見える場所に置く必要があります。

四段目は、前提と再見積もりの条件を書く

最後に、この見積もりが成立する条件を文章にします。環境がいつ提供されるか、仕様の資料は何が存在するか、質問への回答はどのくらいで返るか、再テストは何巡までか、仕様変更が入った場合はどうするか。ここまで書いて、はじめて見積もりが基準として機能します。

四段目まで書き終えたら、内訳を上から読み返して、発注側が判断できる単位になっているかを確認します。読み返して意味が取れない行は、相手も読めません。

この四段の手順は、案件の規模が変わっても同じです。規模が小さいほど省略したくなりますが、小さい案件ほど前提が口頭で済まされ、後で揉めます。手順を省くのではなく、それぞれを短く書くのが正しい省略の仕方です。

あとで足せない項目こそ、先に書く

ここが本題です。着手後に追加を申し出ても通りにくい項目には、いくつかの共通した特徴があります。成果物として目に見えないこと、発注側の都合で発生すること、そして時間が読めないことです。

質問の往復で発生する待ち時間

仕様が不明な箇所を質問し、回答が返るまで作業が止まる。この時間は、作業していないため請求しにくく、しかし別の作業に切り替えられるとも限りません。対処は、待ち時間そのものを請求することではなく、回答の期限を前提に書くことです。「質問への回答は原則として翌営業日中にいただける前提で日程を組んでいます」と書いておけば、遅れの原因を事実として指摘できます。

仕様を読み解き、書き起こす作業

資料が断片的な場合、既存の挙動を確認して仕様として整理する作業が発生します。本来は発注側の資産になる作業ですが、テストの一部と見なされて無償で吸収されがちです。着手前に資料の有無を確認し、不足していれば整理工程を独立した行として立てます。着手後に「思ったより資料がなかった」と言っても、通りません。

不具合か仕様かを判断する相談

見つけた現象が不具合なのか意図した動作なのかを、発注側に確認する往復です。一件あたりは短くても、件数が積み上がると無視できない時間になります。判断基準を先に決められない案件では、この往復が常態化します。「仕様の判断が必要な事項は一覧にしてまとめて確認する」という進め方を前提に書いておくと、細切れの中断を減らせます。

環境が壊れたときの復旧

テストの過程でデータが想定外の状態になり、初期状態に戻す必要が出ることがあります。戻す手順が用意されていない場合、復旧作業に時間を取られます。「環境の初期化手順をご提供いただける前提です」と書くだけで、無い場合の追加交渉ができます。

範囲外の機能についての質問対応

作業を進めていると、範囲外の機能について意見を求められることがあります。断りにくい相談ですが、積み重なると相応の時間になります。範囲を明記した見積書があれば、「範囲外のため別途お見積もりします」と自然に言えます。

精度を上げるために、実務でできること

見積もりの精度は、技術ではなく記録で上がります。

実績を自分の手元に残す

案件ごとに、見積もった時間と実際にかかった時間を残します。項目単位で残せると、次の見積もりで使える基準値になります。ずれが出た項目には理由を一言添えておくと、同じ条件の案件で再現できます。この記録は、条件を交渉する場面でも根拠として機能します。

前提条件を必ず文章で書く

金額の隣に、その金額が成立する条件を書きます。環境の提供時期、資料の有無、質問への回答速度、再テストの回数、仕様変更が発生した場合の扱い。これらを書いた見積書は、着手後の交渉で事実の確認だけで済むようになります。書いていないと、記憶の食い違いを埋める作業から始まります。

幅で出し、幅が縮む条件を示す

情報が足りない段階では、点で出さずに幅で出します。そのうえで、幅が縮む条件を並べます。「要件一覧を確定いただければ下限側に寄せられます」という書き方は、発注側に情報提供の動機を与えます。幅を出すこと自体は、精度が低いことの表明ではなく、不確実性を管理していることの表明です。

見積書の文面そのものを整える

見積書は社内で回覧される書類です。誤字や項目名の揺れがあると、内容以前に信頼を落とします。書類としての体裁を整える力は、実務では思っている以上に効きます。文書の基本的な作法を体系的に確認したい場合は、ビジネス文書検定のような資格の出題範囲が実務の型として役立ちます。

自動化を含む場合は別の見積もりとして扱う

テストコードの作成や継続的な実行の仕組みづくりを含む依頼は、手動の確認とは別の見積もりにします。作業の性質が開発に近く、成果物の保守という論点が加わるためです。作って納品して終わりにできず、対象が変わるたびに修正が必要になります。

見積もりに立てるべき項目も変わります。実行環境の構築、対象の選定、コードの作成、失敗したときの原因調査の運用、そして引き継ぎ。特に引き継ぎを範囲に含めるかどうかは、後から揉めやすい論点です。作った本人しか直せない状態のまま契約が終わると、保守の相談が無償で続くことになります。範囲に含めるなら手順書の作成時間を立て、含めないなら契約書にその旨を書きます。

見積もりの単位をそろえる

内訳を作るときに、単位が混ざっていると読みにくくなります。ある行は機能単位、別の行は工程単位、さらに別の行は日数。読む側は比較ができず、削る判断もできません。

単位をそろえる方法は二つあります。工程で並べて、その中で対象の内訳を注記する形。あるいは対象で並べて、それぞれに含まれる工程を注記する形。どちらでも構いませんが、一つの見積書の中では統一します。

実務では、工程で並べるほうが交渉に強くなります。対象で並べると「この機能は今回外します」という削り方になり、金額が機械的に減ります。工程で並べると「報告書は簡易版にする」「探索的な確認は短くする」という削り方になり、範囲を保ったまま調整できます。どちらの削り方が自分にとって望ましいかを考えて、並べ方を決めます。

見積もりを伝えるときの順序

出来上がった見積もりをどう伝えるかで、通り方が変わります。金額を先に見せると金額の話になり、前提を先に見せると条件の話になります。

前提、範囲、内訳、金額の順で示す

まず何を前提としているかを示し、次に今回の範囲を示し、その範囲を実現する内訳を並べ、最後に金額を置く。この順序にすると、読む側は金額に至るまでの理由を追えます。逆の順序で出すと、最初に目に入った金額が基準になり、内訳は削る理由を探す材料として読まれます。

削れる箇所を自分から示す

予算に収まらない可能性があると分かっている場合は、削れる候補を自分から出します。「報告書を簡易版にする」「探索的な確認の時間を短くする」といった候補を示すと、発注側は判断に集中できます。何を削ると何が失われるかを併記しておくと、削った結果の責任の所在も明確になります。

自分から削る候補を出すことには、もうひとつ効果があります。削れない項目がどれかを、同時に示せることです。環境の準備や再現条件の切り分けを削ると成果の質が落ちる、という説明は、削る候補を出した後のほうが説得力を持ちます。

断る場合の見積もりも同じ形で出す

条件が合わずに受けられないと判断した場合でも、見積もり自体は同じ形式で出しておく価値があります。前提と範囲が書かれた見積書は、条件が変わったときに相手から声がかかる材料になります。金額だけを伝えて断ると、次はありません。

見積もりがずれ始めたときの動き方

どれだけ丁寧に作っても、ずれるときはずれます。重要なのは、ずれに気づく時期と、報告する早さです。

進捗を件数ではなく比率で見る

実行した件数だけを追っていると、残りの難易度が見えません。全体に対する消化の比率と、残っている項目の難易度構成を合わせて見ると、期間内に終わるかどうかが早い段階で分かります。難しい項目を後ろに残す進め方は、終盤に破綻します。難易度の高い項目から着手すると、ずれの発見が早くなります。

ずれた時点で即座に共有する

期間の半ばを過ぎてから遅れを報告すると、対処の選択肢が残っていません。前倒しで気づいた時点で、事実と選択肢を添えて共有します。「現時点の消化率から見て、当初の日程では範囲を消化しきれません。範囲を絞るか、日程を延ばすかのご判断をお願いします」という形で、判断を求める形にします。

黙って残業で吸収する対処は、その場は収まりますが、次の見積もりの基準を自分で下げることになります。吸収した分は記録に残らないため、次回も同じ条件で依頼されます。

実績を次の見積もりに反映する

案件が終わったら、ずれた項目とその理由を必ず記録します。切り分けに時間がかかったのか、環境の準備が遅れたのか、仕様の確認が想定より多かったのか。この記録が溜まると、類似案件の見積もりが早く、そして当たるようになります。

内訳を見せることが、次の依頼につながる

検証や品質保証の仕事がどのような形で発注されているかは、QA・テスト・コードレビューのお仕事の募集内容から傾向が読み取れます。実行だけを切り出した依頼と、設計から任せる依頼では、見積書に立てるべき行がまったく違います。募集の文面から、どちらの想定で発注されているかを読み取る練習をしておくと、初回の相談が短く済みます。

隣接する領域の発注状況も見ておくと、依頼の背景が推測しやすくなります。AI・マーケティング・セキュリティのお仕事のように、開発以外の工程とまとめて発注される案件では、テストが全体の一部として扱われるため、内訳を明示する重要性がさらに上がります。自分の条件が市場の水準からどれだけ離れているかを把握しておきたい場合は、ソフトウェア作成者の年収・単価相場で職種別の水準を確認できます。

20年この市場を見てきた立場から言えば、見積もりの内訳を細かく見せる受け手ほど、二回目以降の依頼が来ています。理由は単純で、発注側にとって「何にいくらかかるか」が分かる相手は、社内の説明が楽だからです。総額だけを出す相手は、値引き交渉の対象にしかなりませんが、内訳を出す相手は範囲の相談ができる相手になります。値引きの交渉と範囲の相談は、見た目が似ていて中身がまったく違います。

もうひとつ、取引の構造が見積もりに与える影響も見ておく価値があります。仲介の手数料が乗る取引では、発注側の予算のうち一定割合が仲介に流れるため、受け手に渡る額を確保しようとすると作業を詰め込む方向に傾きます。手数料0%の直接取引では、同じ予算のまま準備や報告の工程を内訳に立てやすくなります。運営者として見てきた限りでは、内訳をきちんと立てられた案件のほうが、途中で範囲が崩れる確率が明らかに低くなっています。金額の大小より、内訳を立てられる関係かどうかのほうが、働きやすさに直結しています。

働き方の選択肢を広げる観点では、経験を積んだ人ほど見積もりの精度が資産になります。定年後のフリーランス独立｜退職金を活かした起業プランと注意点で扱われているような、時間の使い方を自分で決める働き方に移る場合、見積もりの精度がそのまま生活の安定につながります。読み違えを吸収する体力に頼らない働き方をするために、内訳と前提を書く習慣は早い段階で作っておくべきです。