QAの見積もり比較｜安さで選ばない7つの評価軸

2026 7/23

2026年7月23日 2026年7月23日

テストの外注を検討し、複数社から見積書を取り寄せた。ところが並べてみると、金額は各社バラバラで、しかも「テスト一式」としか書かれていない。どこがどう違うのか、なぜこの価格差が生まれるのか、判断する材料がない――そんな場面で手が止まっていないでしょうか。

安い会社を選べば予算は通りやすい。しかし、その安さの理由がわからないまま発注すると、後から追加費用が膨らんだり、期待した品質に届かなかったりします。QAの見積もり比較は、額面の安さだけでは正しく判断できません。

複数の受託案件を抱えながら、テストをエンジニアの兼任でしのいでいるPMにとって、外注は「時間を買う」有力な手段です。だからこそ、選定を一度で失敗しないための物差しが要ります。

この記事では、複数社の見積書を横並びにするための前提の揃え方、価格より重要な7つの評価軸、ベンダー2タイプの見極め方、そして見積もり取得時に質問すべき項目までを、比較表とチェックリストで解説します。発注前に自社の選定基準を整理したいPMの方に向けた実務ガイドです。

なぜQAの見積もり比較を額面だけで行うと危険なのか

見積書の金額を単純に並べて安い順に選ぶ――これが最も避けたい進め方です。理由は、同じ「テスト一式」という言葉でも、その中身が会社ごとにまったく別物だからです。

まず押さえたいのは、テストの見積もりは「モノの値段」ではなく「作業範囲の値段」だという点です。範囲の定義が違えば、金額が違うのは当たり前で、安い・高いという比較そのものが成立していないことすらあります。

「一式見積もり」の中身は会社ごとに別物

「テスト一式」という項目には、実は多くの作業が含まれ得ます。しかし、どこまでを含めるかは会社の裁量で決まっており、見積書の表面からは判別できません。

一式に含まれ得る作業には、たとえば次のようなものがあります。

テスト計画の立案とスコープ定義
テスト観点の洗い出しとテスト設計
テストケースの作成とレビュー
テスト環境の構築・準備
テスト実行と結果記録
不具合の起票・再現手順の整理
再テスト（修正内容が直ったかの確認）と回帰テスト（修正による副作用の確認）
テスト結果報告書の作成

ここで注意したいのが、再テストと回帰テストは別物だという点です。再テストは修正が正しく反映されたかを確認する作業、回帰テストは修正が他の機能に悪影響を与えていないかを確認する作業を指します。安い見積もりでは、この回帰テストが範囲外になっていることがあります。

同じ金額の裏で、含まれる作業の数がまったく違う――これが見積もり比較を難しくする最大の要因です。

たとえばA社が上の8項目すべてを含む一方で、B社は「テスト実行と結果記録」だけを一式と呼んでいる、ということが実際に起こります。金額だけを見ればB社が安いのは当然ですが、A社に含まれる設計や報告を自社で肩代わりすれば、外注した意味は薄れます。

見積書の粒度差を見抜くには、項目の「行数」と「単位」に注目すると早いです。作業を1行の「テスト一式」で丸めている見積書と、設計・実行・報告を別行に分けて人日単位で示す見積書では、後者のほうが範囲の輪郭がはっきり見えます。

行数が少ない見積書ほど、含む・含まないの境界があいまいになりがちです。逆に、内訳が細かく分かれているほど、後で「それは範囲外」と言われる余地が小さくなります。粒度そのものが、その会社の見積もり姿勢を映す鏡だと考えてよいでしょう。

安さの正体は3つのパターンに分かれる

見積もりが安いこと自体は悪ではありません。問題は、その安さが「効率化による合理的な安さ」なのか、「範囲を削った見かけ上の安さ」なのかが区別できないことです。安さの正体は、おおむね次の3パターンに整理できます。

安さの正体	見積書での現れ方	発注後に起きやすいこと
スコープを狭めている	対象範囲・テスト観点が限定的	未カバー領域のバグが本番流出
再テスト・回帰テストが別料金	「初回実行分のみ」等の注記	修正のたびに追加請求が発生
テスト設計を省略している	設計工数の計上がない	ケースの網羅性が担保されない

この3パターンは、いずれも「発注前は安く見え、発注後に効いてくる」構造が共通しています。裏を返せば、見積書の注記や工数内訳をていねいに読めば、事前に見抜ける余地があるということです。

額面比較が招く発注後の追加費用リスク

額面だけで選ぶと、発注後に「それは範囲外です」という説明を何度も受けることになります。当初の見積もりは安くても、追加分を積み上げた結果、総額では高くつくケースは珍しくありません。

しかも追加費用は、スケジュールが逼迫した局面で発生しがちです。リリース直前に「回帰テストは別料金です」と言われても、断って品質を諦める選択肢は取りにくく、言い値で追加発注せざるを得なくなります。

発注後トラブルの典型は、次のような流れで進みます。初回は安い額面で受注し、テストを進めるうちに「仕様書に書かれていない挙動が見つかった」「修正が入ったので再確認が要る」といった追加が積み上がっていきます。

一つひとつの追加は小さくても、積算すると当初見積もりを大きく超えることがあります。しかも、そのつど発注可否をこちらが判断する必要があり、PMの管理工数まで奪われます。額面の安さと引き換えに、見えないコストを背負い込む構図です。

工数の見積もりには、そもそも会社間・案件間で大きなばらつきがあることが知られています。IPAが公開する開発規模と工数の実測データからも、同種の作業でも数字が一様でないことがうかがえます（IPA ソフトウェア開発分析データ集）。だからこそ、額面の数字だけを突き合わせても、公平な比較にはなりません。

見積もりを比較可能にする前提を揃える

各社の見積もりを正しく比べるには、まず「同じ土俵」に乗せる必要があります。渡す情報が会社ごとにバラバラでは、返ってくる見積もりもバラバラになるのは当然です。

比較の精度は、見積書を受け取ってからではなく、依頼する前の準備でほぼ決まります。ここに手間をかけるほど、あとの選定はラクになります。

各社に同一条件で渡す最低限の依頼情報

相見積もりを取る際は、全社に対して同じ情報を、同じ粒度で渡すのが鉄則です。最低限、次の情報を揃えて依頼しましょう。

対象システムの概要（機能一覧・画面数の目安）
テスト対象範囲（どの機能を含み、どこを含めないか）
期待するテストレベル（結合・システム・受入のどこを担ってほしいか）
希望する成果物（テストケース・不具合票・結果報告書など）
スケジュールの制約（開始時期・リリース希望日）
現状の資料の有無（仕様書・設計書があるか）

同じ情報を渡して初めて、返ってきた見積もりの差が「実力の差」として読み取れるようになります。

逆に、この情報が曖昧なまま依頼すると、各社は自社に都合よく範囲を解釈します。安く見せたい会社は狭く、手堅く行きたい会社は広く見積もり、比較の土台が崩れます。

依頼情報は、口頭やチャットで小出しにするより、1枚のドキュメントにまとめて全社へ同時に渡すのが確実です。項目ごとに見出しを立て、各社が同じ順序で読める形にしておくと、返答の抜け漏れも減ります。

テスト対象範囲の切り分けは、機能一覧に「含む／含まない／要相談」の3列を用意して印を付けると伝わりやすくなります。たとえば決済連携は含む、管理画面の帳票出力は含まない、外部API連携は要相談、といった具合に、境界を可視化しておくと各社の解釈ずれを最小化できます。

スコープの言語化は3つの軸で行う

依頼情報のなかでも要となるのがスコープの言語化です。次の3軸で整理すると、各社の認識ずれを防げます。

軸	言語化する内容	揃えないと起きること
対象範囲	どの機能・画面を含めるか	各社が想定する範囲がずれる
テストレベル	結合・システム・受入のどこを担うか	見積もりの厚みが不均一になる
成果物	何を納品物として求めるか	報告の質にばらつきが出る

テストレベルの定義は、JSTQBが公開する用語や体系が共通言語として使えます（JSTQB）。ここで押さえておきたいのは、単体テスト（ユニットテスト）は通常、開発側が担い、外注には結合テスト以降を委ねることが多いという実務の前提です。ただし、どのテストレベルを担ってもらうかは案件によって異なります。単体テストまで当然に外注する前提で書くと認識がずれるため、「どこを担ってもらうか」は明示的に指定しましょう。

成果物についても、単に「報告書」と書くのではなく、粒度まで指定すると各社の解釈がそろいます。たとえば「不具合票は再現手順・期待結果・実測結果を含む」「日次で進捗と検出件数を共有する」といったレベルまで書くと、返ってくる見積もりの前提が近づきます。

前提が揃わない見積書はいったん保留する

前提を揃えて依頼したのに、明らかに条件を読み違えた見積もりが返ってきた場合、そのまま比較対象に入れるのは危険です。まずは条件のすり合わせを求め、認識が揃ってから再提出してもらうのが安全です。

すり合わせのやり取りそのものも、実は評価材料になります。こちらの意図を正確にくみ取り、的確な確認質問を返してくる会社は、発注後のコミュニケーションも期待できます。

こうした事前準備の段取りは、比較の精度を大きく左右します。依頼前に整理しておくべき項目は、テスト代行を依頼する前の準備で押さえる5観点でも具体的に解説しています。

価格より重要──QAの見積もり比較で使う7つの評価軸

前提を揃えたら、いよいよ中身の比較に入ります。ここで見積書を突き合わせる作業は、価格ではなく「発注後にどれだけ頼れるか」を測るものです。次の7つの評価軸で各社を採点していきます。

7つの評価軸と採点観点

評価軸	採点で見るポイント
①スコープの粒度	作業項目が具体的に分解されているか
②テスト設計力	観点の網羅性・技法の適用・優先度付けが妥当か
③伴走姿勢	情報格差を埋める提案をしてくれるか
④コミュニケーション体制	窓口・報告頻度・連絡手段が明確か
⑤柔軟性・変更対応	仕様変更や追加への対応方針があるか
⑥不具合報告・再現性	不具合票の様式・再現手順の質が確認できるか
⑦実績・体制の安定性	類似案件の実績と要員体制が示されているか

この7軸は、価格の安さでは測れない「発注後の安心感」を分解したものです。上位の軸ほど品質に直結し、下位の軸は日々の運用のしやすさに効きます。

②以外の軸も、採点で見る勘所を押さえておくと迷いません。①スコープの粒度は、前章で触れた「内訳の行数と単位」を根拠に、作業が具体的に分解されているかを見ます。③伴走姿勢は、こちらが渡した情報の不足を指摘し、補う提案を返してくるかが分かれ目です。

④コミュニケーション体制は、窓口が単独か複数か、報告が定例化されているかを確認します。⑤柔軟性は、仕様変更が起きたときの対応フローが見積もり段階で語られているかを見ます。⑥不具合報告は、票の様式と再現手順の粒度で判断できます。⑦実績・体制の安定性は、類似規模の案件経験と、繁忙期の要員確保の考え方を聞くと差が出ます。

スコープの粒度とテスト設計力を見極める

7軸のなかでも、発注後の品質を最も左右するのが②テスト設計力です。ただ「テストします」ではなく、どんな観点で、どの技法を使い、どう優先度を付けるのかが問われます。

発注側が見積書やヒアリングで確認したいのは、次の3点です。

テスト観点の網羅性：機能・非機能・境界条件などを漏れなく拾えているか
テスト技法の適用：同値分割・境界値分析などを適切に使い分けているか
優先度付けの妥当性：限られた工数のなかで重要な箇所に厚みを置けているか

限られた工数で効果的にテストケースを絞り込む技法の重要性は、Lee Copeland『はじめて学ぶソフトウェアのテスト技法』でも体系的に論じられています。設計力の差は、同じ工数でも「拾えるバグの数」の差になって現れます。

見極めの実践としては、見積書の段階で「テスト観点の一覧」や「テスト設計の考え方」を軽くでよいので提示できるかを聞くのが有効です。設計力のある会社は、まだ契約前でも観点の切り口を言語化できます。逆に「詳細は契約後に」としか答えられない場合、設計を軽視している可能性を疑ってよいでしょう。

伴走姿勢とコミュニケーション体制

③伴走姿勢と④コミュニケーション体制は、日々のやり取りの快適さを決めます。仕様の不明点を放置せず質問を上げてくれるか、報告の頻度や窓口が明確か。ここが弱いと、外注しても結局こちらの手間が増えます。

とくに専任QAを置きにくい中小規模の受託開発では、PMが窓口を兼ねることが多く、やり取りの負担がそのまま自分に返ってきます。報告フォーマットが整い、確認事項を能動的に上げてくれる相手だと、管理コストは大きく下がります。

連携で失敗しないための具体的な進め方は、テスト代行との連携で品質を保つコツで解説しています。窓口の置き方や情報共有の頻度設計は、採点前に目を通しておくと軸④の評価がぶれません。

採点シート化して横並びにする方法

7軸を頭の中だけで比べると印象評価に流れます。次の手順でシート化すると、各社を客観的に横並びにできます。

7軸を表の行に、各社を列に置く
各セルを3段階（◎○△）または5点満点で採点する
見積書とヒアリングの回答を根拠として1行ずつ埋める
空欄が多い会社は「情報開示に消極的」と評価する
合計点と価格を並べ、総合的に判断する

とはいえ、7軸すべてを重み付けして採点するのは、忙しいPMには手間に感じられるかもしれません。その場合は、まず全社を「必須3軸」で足切りし、残った会社だけを詳しく採点するという簡略運用がおすすめです。必須3軸には、①スコープの粒度・②テスト設計力・⑥不具合報告の質を置くと外しにくいです。

この採点シートは、そのまま稟議資料の素材になります。上長に「なぜこの会社を選んだか」を説明する際、点数と根拠が揃っていれば説得力が段違いです。

ベンダー2タイプの中立比較──大手第三者検証と中堅伴走型

QA外注のベンダーは、大きく「大手の第三者検証型」と「中堅の伴走型」に分かれます。どちらが優れているという話ではなく、案件の特性によって向き不向きが変わります。

比較項目	大手第三者検証型	中堅伴走型
強み	大規模・標準化された体制、豊富な実績	柔軟な対応、密なコミュニケーション
向く案件	大規模・長期・網羅性重視の案件	中小規模・仕様変更が多い案件
進め方	プロセスが定型化されている	案件に合わせて設計しやすい
注意点	小回りが利きにくい・単価が高め	体制規模・繁忙期の対応力を要確認
費用感	相対的に高くなりやすい	案件により幅がある

大手第三者検証型が向く案件

標準化されたプロセスと大人数の体制を持つため、大規模で網羅性が求められる案件に強みがあります。品質の均一性や、第三者としての客観性を重視する場面でも安心感があります。

一方で、プロセスが定型化されているぶん、細かい仕様変更への小回りは利きにくい傾向があります。少人数・短期・仕様が動きやすい案件では、手続きの重さがかえって足かせになることもあります。

中堅伴走型が向く案件

案件ごとに進め方を設計しやすく、仕様変更が多い開発や、密なやり取りを求める案件に向きます。PMと近い距離で動いてくれるため、認識合わせのコストが低く済むのも利点です。

ただし、体制規模や繁忙期の対応力は事前に確認しておくべきポイントです。少数精鋭ゆえに、繁忙期に要員を確保できるか、担当が抜けたときのバックアップがあるかは、契約前に必ず押さえておきましょう。

発注後に起きやすいシーンで対比すると、向き不向きが具体的に見えてきます。大手第三者検証型では、仕様変更をその場で反映したくても、変更依頼の手続きを経る必要があり、反映まで時差が生じることがあります。一方で成果物の様式が安定し、報告の質にばらつきが出にくいのは利点です。

中堅伴走型では、仕様変更に素早く追随してもらえる反面、担当個人の力量に品質が左右されやすい面があります。迷ったときの見極めは、「変更の多さ」と「品質の均一性、どちらを優先するか」を自問すると答えが出やすくなります。

自社案件はどちらに向くか

判断の軸はシンプルです。規模と網羅性を最優先するなら大手第三者検証型、柔軟性と対話のしやすさを重視するなら中堅伴走型が候補になります。

規模が大きく、網羅性・客観性を重視 → 大手第三者検証型
中小規模で、仕様変更が多く密な連携を求める → 中堅伴走型
判断に迷う → 両タイプ1社ずつを相見積もりに入れて比較

中小規模の開発でどちらを選ぶかは、中小企業向けテスト代行で大手と中堅を選ぶ判断軸でさらに掘り下げています。

見積もり取得時に必ず質問すべき項目リスト

見積書だけでは読み取れない部分は、質問で埋めます。ここでは3つのカテゴリに分けて、聞くべき項目をチェックリストにまとめます。質問への答え方そのものが、前章の7軸を採点する材料になります。

費用内訳を分解させる質問

「テスト一式」の内訳を作業項目ごとに分解して示してもらえますか
テスト設計とテスト実行の工数は、それぞれどれくらいですか
見積もりに含まれない作業があれば、具体的に教えてください

スコープと追加費用の境界を確認する質問

再テストと回帰テストは、この見積もりに含まれていますか
仕様変更が発生した場合、どの範囲から追加費用になりますか
テストケースの追加が必要になった場合の単価はいくらですか

体制・コミュニケーションを確認する質問

担当窓口は誰で、報告の頻度・手段はどうなりますか
繁忙期でも予定した体制を確保できますか
不具合票のサンプルを見せてもらえますか

これらの回答を採点シートに転記すれば、比較の精度が一段上がります。

とくに「見積もりに含まれない作業」と「追加費用の境界」の2問は、発注後のトラブルを未然に防ぐ効果が大きい質問です。ここを口頭でうやむやにする会社は、後の追加請求でも同じ姿勢を取りがちだと考えておくと安全です。

各質問には、なぜ効くのかと、回答の良し悪しを見分けるコツがあります。費用内訳を分解させる質問は、設計工数の有無をあぶり出すために効きます。実行だけを答えて設計に触れない回答は、設計を省いている可能性を疑うサインです。

スコープと追加費用の境界を確認する質問は、「どこからが有料か」を発注前に文書化させる狙いがあります。境界を即答できる会社は運用が整っており、逆に「ケースバイケース」でかわす回答は、後の追加請求の温床になりやすいと見ておきましょう。

体制・コミュニケーションを確認する質問では、不具合票のサンプル提示を渋るかどうかが分かれ目です。良い会社は既存様式を隠さず見せてくれます。ここで開示をためらう相手は、報告の実務が固まっていない可能性があります。

なお、費用対効果を上長に説明して稟議を通す段階では、テスト外注の費用対効果を上長に説明し稟議を通す進め方が、質問で得た情報を稟議資料に落とし込むうえで役立ちます。

「安さ」の裏を読む──見積書のここを疑う

安い見積書に出会ったら、まず「なぜ安いのか」を確認する習慣を持ちましょう。合理的な安さもあれば、後で高くつく安さもあります。

安い見積書で確認すべき前提

安い見積書を見たら、次の4ポイントを疑ってください。

スコープが狭くないか：対象機能や観点が絞られていないか
再テスト・回帰テストが範囲外になっていないか：初回実行分のみになっていないか
テスト設計工数が計上されているか：実行だけで設計が省かれていないか
成果物が簡略化されていないか：報告書や不具合票の質が落ちていないか

この4点はいずれも、見積書の「注記」や「工数内訳」の欄に手がかりが出ます。総額の数字より先に、まず注記から読む癖をつけると、安さの正体が見えてきます。

注記の読み方には、いくつか定番の着眼点があります。「初回実行分のみ」「別途お見積り」「上記に含まないもの」といった小さな但し書きこそ、発注後に費用が膨らむ入口です。金額の大きさに気を取られると、この一行を読み飛ばしがちです。

発注後に膨らむ費用は、頭のなかで簡単に試算しておくと油断を防げます。たとえば、想定される修正の回数だけ再テストが発生し、そのつど別料金が積み上がるとしたら、総額はどこまで動くか。具体的な金額ではなく「膨らみ方の当たり」を持っておくだけで、安い見積書に対する見方が変わります。

合理的な安さと要注意の安さを見分ける

安さの理由が説明できるかどうかで、判断は分かれます。

判断	合理的な安さ	要注意の安さ
理由	自動化・過去資産の再利用で効率化	範囲や設計を削って見かけ上下げている
説明	何を効率化したか明確に説明できる	「一式」のまま内訳を示せない
追加費用	追加が発生する条件が明示的	発注後に範囲外が続出しやすい

見分けの決め手は「説明できるか」の一点に集約されます。合理的な安さには必ず理由があり、その会社は理由を堂々と語れます。理由を濁す安さは、後で自分に返ってくると考えてよいでしょう。

比べるべきは見積書の総額ではなく、発注後に膨らんだ実費まで含めた「本当の総額」です。

ここで気になるのが「では結局いくらが妥当なのか」という点でしょう。本記事はあえて金額の相場には踏み込まず、評価の「軸」に徹しています。相場感については、テスト代行の費用相場と見積もり感で具体的な数字を確認できます。額面の妥当性はそちらで、選ぶ基準は本記事で、と役割を分けて使ってください。