システム開発の見積もりでテスト費用が高い・書かれていないときの判断｜品質を削っていないか確認する

システム開発の見積もりを開いたら、「テスト費」だけが妙に大きい。あるいは逆に、テストの行がどこにも見当たらない——この記事は、その1行を「高い・安い」ではなく「何が含まれていて、含まれていない作業は誰がやるのか」で読み解くための手順書です。相場の何パーセントかを当てにいくのではなく、目の前の見積書1枚を、発注判断ができる状態まで分解します。

この記事の結論｜テスト費用は「高い・安い」ではなく「誰がいつ払うか」で見る

テスト費用の見積もりで最初に押さえるべきことは、金額の大小ではありません。テストという作業自体は、見積書に書かれていても書かれていなくても、必ず誰かが行うという点です。

見積書からテストの行が消えても、テストの作業が消えるわけではありません。消えるのは「ベンダーが有償で引き受ける約束」のほうです。その結果、次のどれかが起きます。

• ベンダーが他の工程（製作など）に溶かして計上している
• 発注側がテストの実施者になる前提で組まれている
• 検収後に不具合として現れ、そのときに追加費用が発生する
• 誰も想定しておらず、稼働後の障害対応として現れる

1つ目なら総額としては妥当ですが、内訳が読めないので他社との比較には使えません。2つ目は、あなたの会社の人件費と稼働時間が計画に入っているかどうかの問題です。3つ目と4つ目は、契約時点では安く見えた見積もりが、検収後に発注側の負担へ移った状態です。

だから見るべきなのは金額ではなく、どのテストをどこまでやるか（範囲）・誰がやるか（実施者）・どの環境でやるか（環境）・その結果に誰がいくら責任を負うか（不具合対応の条件）の4点です。

判定は4状態でおこなう

「高すぎる」「安すぎる」の2択で判断すると、たいてい判断を誤ります。この記事では、テストに関する見積行を次の4状態のどれかに割り当てます。

「高リスク」は、ベンダーが不誠実だという意味ではありません。発注側が引き受けているリスクが、見積書からは見えない状態を指します。安い見積もりほどこの状態になりやすいので、金額が想定より低いときこそ確認が必要になります。

最初に見る3つの行

手元に見積書があるなら、次の3か所を先に探してください。この記事の残りは、この3つを読むための材料です。

1. テストに関する行（「テスト」「試験」「品質保証」「検証」などの語を含む行）
2. テスト環境・検証環境に関する行（サーバー費用、環境構築費として別に立っていることが多い）
3. 検収後の不具合対応に関する記載（見積書の前提条件欄、または契約書の保証期間の条項）

3つ目が見積書に無いのは珍しくありません。その場合は契約書側にあります。見積書にテストの行があっても、3つ目が空欄なら判定は「要確認」以上になります。

この記事で扱わないこと

• テスト費用の金額相場（円）。税区分と契約期間をそろえた公開価格表を十分に収集できていないため、この記事では金額のレンジを出しません
• テスト技法そのものの解説（同値分割、境界値分析など）。発注判断に直接効かないため扱いません
• 特定ベンダーやテストサービスの比較

開発費全体の相場観と工程別の考え方は、開発費用の相場と見積もり妥当性の判断を先に読んでおくと、この記事の位置づけが分かりやすくなります。

見積書に「テスト」はどう書かれているか

実際の見積書でテストがどう表現されるかは、おおむね4パターンに分かれます。最初にやるのは、自分の見積書がどれなのかを見分けることです。

以下に示すのは記載形式の例です。実在の見積書ではなく、金額も書き方を示すために置いた仮の数字なので、相場として読まないでください。

パターン1｜「テスト 一式」

テスト工程　　　　一式　　　1,800,000円

もっとも多い書かれ方です。金額はあるので、総額に対する比率は計算できます。ただしこの1行だけでは、単体テストまでなのか受け入れテストの支援まで含むのか、性能試験が入るのか、テスト環境の費用が別なのかが分かりません。

比率が統計の範囲に収まっていても、含まれている作業が違えば比較になりません。一式表記そのものの読み方は、見積書の「一式」を工程・成果物・工数へ分ける方法で詳しく扱っています。

パターン2｜工程名だけが並ぶ

単体テスト　　　　　0.8人月　　　　640,000円
結合テスト　　　　　1.2人月　　　　960,000円
総合テスト　　　　　1.0人月　　　　800,000円

パターン1より一段細かい状態です。工数と金額が対応しているので、単価も逆算できます。ただしここでも、それぞれの工程が何を指しているかはベンダーごとに違います。「総合テスト」がベンダー社内の確認までを指すのか、発注側の受け入れ確認の支援まで含むのかは、この表記からは読み取れません。後述するテストレベルの対応表で、言葉のズレを埋める必要があります。

パターン3｜テストの行が存在しない

要件定義　　　　　　1,200,000円
設計　　　　　　　　2,400,000円
開発　　　　　　　　4,800,000円
（テストの行なし）

もっとも判断が難しいパターンです。テストが不要な開発はほぼ存在しないため、行が無いことは作業が無いことを意味しません。「開発」の中に含まれているのか、発注側が実施する前提なのか、見込んでいないのかを確認する必要があります。

相見積もりでこのパターンの見積書がいちばん安く出てきたときは、比較の前提が崩れています。他社が計上しているテスト工数を、この見積書は別のところへ移しているか、そもそも見込んでいないかのどちらかです。

パターン4｜別の名前になっている

品質保証費　　　　　1,500,000円
検証作業　　　　　　　800,000円
QA費用　　　　　　　1,200,000円

テストという語を使わない書き方です。指している作業はテストと重なりますが、レビューや品質管理の会議体を含むこともあります。パターン1と同じく、含まれる作業の確認が必要です。

4パターンの見分け方

初期判定に「説明済み」と「判断不能」が現れないことに注意してください。見積書の表記だけで説明済みと判定できることは、実務上ほとんどありません。別紙のテスト計画や、契約書の保証条項と突き合わせて初めて判定できます。「判断不能」のほうは、見積書の書き方ではなく要件や契約条件がまだ存在しないことから決まる状態なので、この表からは判定できません。後述の判定表で拾います。

「テスト」の1行が指しているのは、5つのテストレベルのどこか

見積書のテストという1語が指す範囲は、ベンダーによって違います。この差を埋めるには、業界で共通に使われている区分を基準にするのがいちばん早い方法です。

判断の基準になるJSTQBの定義

ソフトウェアテストの国際的な資格制度であるISTQBのシラバスを、日本の運営組織であるJSTQBが翻訳したFoundation Level シラバス Version 2023V4.0.J02（29〜30ページ）は、テストレベルを5つに分けています。同シラバスの改訂履歴によると、英語原版のCTFL4.0が2023年4月12日公開、日本語版J02は2024年7月10日の改訂です。原典の記述をもとに、発注側の視点で整理すると次のようになります。

シラバスは受け入れテストの主な形式として、ユーザー受け入れテスト（UAT）、運用受け入れテスト、契約および規制による受け入れテスト、アルファテストおよびベータテストを挙げています。

同じシラバスは、テストレベルとは別軸のテストタイプを4つ（機能テスト、非機能テスト、ブラックボックステスト、ホワイトボックステスト）挙げています。このうち非機能テストについては、ISO/IEC 25010の分類として性能効率性・互換性・使用性・信頼性・セキュリティ・保守性・移植性の7つを示しています。性能とセキュリティが「テスト費」に含まれるかどうかは、金額を大きく左右します。

見積書の行とテストレベルの対応表

自分の見積書の各行が、5つのテストレベルのどこを埋めているかを書き込んでみてください。空欄になったレベルが、確認すべき場所です。

この表で最も重要なのは最下段です。受け入れテストは、シラバスでも想定ユーザーによる実施が理想的とされている通り、発注側が主体になりやすい作業です。見積書に「受入テスト支援」の行が無いことは、ベンダーが手を抜いているサインとは限りません。しかしその場合、その作業は消えるのではなく自社へ移ります。何が移るのかを、次に具体化します。

受け入れテストは、自社でやるならあなたの工数

ここは経営判断に直結するので、もう少し踏み込みます。受け入れテストを自社でやる場合に必要になるのは、次のようなものです。

• 業務を分かっている担当者の稼働（本来業務との兼務になることが多い）
• 現場の業務手順に沿ったテストシナリオの作成
• 本番に近いテストデータの用意（個人情報を含む場合はマスキングの作業も発生する）
• 不具合を報告し、修正を確認し、再度確認する往復
• 合格・不合格の判定基準の事前合意

これらは見積書には現れませんが、社内の人件費としては確実に発生します。ベンダーの見積総額が下がっても、社内工数を含めた総コストは下がっていないことがあるのはこのためです。見積もりを比較するときは、この社内工数の見積もりも並べて比較してください。

実際に費用を生んでいるのは、テストの実行ではない

「テストにお金がかかる」と聞いたとき、多くの人はテストを実行する時間を想像します。しかし実際に工数を食っているのは、その前後の作業です。

要因1｜テスト設計とテストケース作成

何をどう確かめるかを決め、確認手順を1つずつ文書に落とす作業です。機能数と条件の組み合わせで増えるため、画面数や機能数が増えると、実行時間よりも先にこの作業が増えます。

要因2｜テスト環境の構築

本番と同じ構成の環境を別に用意する作業です。サーバー、データベース、外部サービスとの接続、証明書などを一式そろえる必要があります。ここで注意したいのは、この作業が見積書では「テスト費」と別の行に立つことが多いという点です。

作業の性質としても、テストの実行とは区別されています。IPAの「ソフトウェア開発分析データ集2022」の収集フォームでは、社内の実績工数を「開発」「管理」「その他」「作業配分不可」の4区分で工程ごとに記録します。テスト環境構築は、インフラ構築や移行と並ぶ「その他」の作業例として挙げられています。この4区分は工程の中の軸なので、テスト環境構築の工数も、割り当てられた工程の比率には含まれます。統計から言えるのは「テストを実行する作業とは別の作業区分として扱われている」ところまでです。

したがって、見積書でテスト費の比率が低く見えても、環境構築が別の行に立っていれば、テストに関わる費用の合計はそれより大きくなります。逆に、環境構築の行がどこにも見当たらない場合は、開発環境をそのまま使う前提なのかを確認してください。本番と構成が違う環境だけでテストを済ませることは、本番で初めて不具合が出る典型的な原因です。

要因3｜テストデータの準備

本番データをそのまま使えないケースでは、個人情報のマスキングや、条件を満たすデータの作成が必要になります。既存システムからの移行を伴う案件では、移行データの検証とテストが重なるため工数が膨らみます。テスト工程の見積もりでは、「移行後のデータでテストするのか、ダミーデータで済ませるのか」を必ず確認してください。移行データで確認していないシステムは、稼働初日に初めて本番データと出会うことになります。

要因4｜不具合の調査・修正・再テスト

見落とされがちな最大の変動要因です。1件の不具合につき、再現確認 → 原因調査 → 修正 → 修正箇所のテスト → 影響範囲の再テストという往復が発生します。発生件数を事前に正確に見積もることはできません。そのため見積書では、不具合対応の工数をどう扱っているかで方針が分かれます。

• 一定の件数を織り込んでいる（超過時の扱いを確認する）
• 実績清算にしている（上限があるかを確認する）
• 織り込んでいない（安く見えるが、追加費用の入口になる）

要因5｜非機能テスト

性能試験、負荷試験、セキュリティ診断などです。これらは専用の環境やツール、外部の診断サービスを必要とすることがあり、機能テストとは費用の桁が変わることがあります。「性能要件が要件定義に書かれているのに、見積書に性能試験の行が無い」状態は、要確認ではなく高リスクとして扱ってください。要件があるのに試験が無いということは、要件を満たしたかどうかを誰も確認しないまま検収を迎えるという意味だからです。

5つの要因が、見積書ではどう見えるか

ここまでの5つを、「見積書のどこに現れるか」の観点で1つの表にまとめます。左が実際に工数を食う作業、中央がそれが見積書から見えなくなる理由、右が見積書上での現れ方です。左と右のズレが、テスト費用の判断を難しくしている正体です。

右列に「別途」「貴社にて」「協議」が並ぶほど、金額としては安く見えます。安く見える理由が右列にあるなら、それは値引きではなく、作業の移動です。

何が増えると、テスト費用が増えるのか

ここまでは作業の種類の話でした。次は量の話です。数量とテスト費用の関係は、単純な比例ではありません。増えるものと増えにくいものを分けて示します。

「件数が10倍だからテスト費も10倍」という見積もりが出てきたら、根拠を聞く価値があります。逆に、対応端末が10種類あるのにテスト費が単一端末想定のままなら、そちらは過小見積もりです。どちらの向きにもズレは起こります。

公開されている統計は「テストは何パーセント」と言っているのか

ここからは数字の話です。使うのは、独立行政法人IPAの調査と、ユーザー企業を会員とする一般社団法人JUASの調査の2つです。データを出しているのが誰かが違うので、数字の意味も変わります。ただし、どちらの比率も、そのまま自分の見積書に当てはめることはできません。その理由も含めて説明します。

IPA ソフトウェア開発分析データ集2022（新規開発270件）

IPA（独立行政法人 情報処理推進機構）社会基盤センターが公開している「ソフトウェア開発分析データ集2022」は、ソフトウェア開発ベンダ35社の協力で収集した累計5,546件のプロジェクトデータを分析したものです。主な統計値は直近6年間（2016年度〜2021年度）のデータを対象にしています。

同書の表A3-3-8「工程別の実績工数の比率（新規開発）」（167ページ）は、次の値を示しています。対象は基本設計から総合テストまでの5工程がすべてそろったプロジェクト270件です。

改良開発（N=580、表A3-3-9）では、結合テストの中央値が20.0%、総合テストが14.2%で、新規開発より総合テストの比率が高くなっています。

中央値だけを見ると判断を誤る

結合テストの中央値20.1%と総合テストの中央値11.9%を足して「テストは約32%」と紹介されることがあります。方向感としては間違っていませんが、中央値どうしの足し算は、合計の中央値ではありません。それぞれ別々の分布の中央値なので、合算値は目安として扱ってください。

より実用的なのは、P25とP75の幅を見ることです。総合テストのP25は6.8%、P75は17.0%で、上位25%と下位25%で2.5倍の開きがあります。つまり「テストが全体の何パーセントか」という一点の数字で妥当性を判定できるほど、実際のプロジェクトはそろっていません。比率は入口の材料であって、判定の基準にはなりません。

JUAS ソフトウェア・メトリクス調査2025

もう1つが、一般社団法人 日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025【ガイドブック】」（2025年4月）です。同協会は、情報システムの開発・保守に取り組んできた企業のアンケート回答をもとにこの調査をまとめています。同書のあとがきによると、2020年の報告書以来4年間調査を中断したのち、活用度の高い項目に絞って改めて実施したものです。

同書の（2-2）「開発フェーズ別の工数と工期」（9〜10ページ）は、次の比率を示しています。

同書は、要約として工期を「20：50：30」、工数を「15：60：25」と示していますが、いずれも5刻みに丸めた値であると明記されています。上の表は5刻みに丸める前の値です（各値は小数点以下を四捨五入しているため、工期比率の合計は101%になります）。なお、工期については対象データ251件のうち開発フェーズ別の工期が明らかな211件を分析対象としたと記載されています。

2つの調査で数字が違う理由

IPAとJUASの数字を並べると混乱しますが、原因ははっきりしています。分母と工程の定義が違うからです。

JUASの同書27ページには、調査票のフェーズ呼称とSLCP（共通フレーム。開発工程の呼び方を業界で揃えるための共通の物差し）の対応表が載っています。この表によると、「設計から統合（結合）テスト」の区分には次のアクティビティが含まれます。

• システム方式設計／ソフトウェア方式設計
• ソフトウェア詳細設計
• ソフトウェアコード作成及びテスト
• ソフトウェア結合／システム結合
• ソフトウェア適格性確認テスト／システム適格性確認テスト（要求を満たしているかをベンダー側で確認するテスト）

つまり、ベンダー側で行うテストの大半は、61%という数字の中に入っています。一方で「ユーザー総合テスト」の区分に対応するのは、ソフトウェア導入支援とソフトウェア受け入れ支援です。

ここを取り違えると、判断が逆向きになります。JUASの「総合テスト26%」を「テスト工程は全体の26%」と読むのは誤りです。26%は、ユーザー側の総合テスト13%と、リリース後数か月のフォロー5%、分類できない業務8%を合わせた値です。26%のうち半分は、そもそもテストではありません。

2つの調査の性格の違いを、表にまとめます。

なお、JUASの最新版である「ソフトウェア・メトリクス調査2026」（2026年4月）は、クラウド・パッケージ・アジャイル開発のメトリクス考案に向けた事前サーベイであり、上記の工程別工数比率を更新するものではありません。この記事では2025年版の数値を使っています。

比率をそのまま見積書に当てはめられない3つの理由

以上を踏まえると、これらの比率を自分の見積書へ直接当てる際には、少なくとも3つの補正が必要になります。

1. 分母が違う。IPAの比率は基本設計から始まります。要件定義を別行で立てた見積総額に対して20.1%を期待すると、必ずズレます
2. 工程名が同じでも中身が違う。「総合テスト」がベンダー確認までなのかユーザー確認を含むのかで、比率の意味が変わります
3. ばらつきが大きい。総合テストのP25とP75で2.5倍の開きがあります。中央値から外れていること自体は異常の証拠になりません

したがって統計の使い方は、「この比率から外れているから高い／安い」ではなく、「この比率から大きく外れているので、理由を聞く」が正しい使い方です。理由に説明がつけば、判定は「説明済み」になります。

テスト費用が少ない・書かれていないことが合理的なケース

テストの行が薄い見積もりのすべてが問題を抱えているわけではありません。次のケースでは、少ないほうが妥当です。

ケース1｜単体テストを開発工数に内包している

前述のとおり、コンポーネントテストは開発担当者が開発環境で行う作業です。実装と一体で見積もるのは一般的な扱いで、単独の行が無くても異常ではありません。確認すべきは、結合以降のテストが別に立っているかどうかです。

ケース2｜発注側が受け入れテストを主導する前提で合意している

自社に業務担当者がいて、受け入れテストを自前でやる方針なら、ベンダー側の受入支援費が薄いのは筋が通っています。この場合に確認するのは金額ではなく、自社側の稼働がスケジュールに織り込まれているかです。

ケース3｜小規模で、影響範囲が閉じている

社内の一部門だけが使うツール、外部連携が無い、扱うデータに個人情報が含まれない——このような条件では、大規模案件と同じテスト体制は過剰です。求める品質水準に対して費用が見合っているかで判断します。

ケース4｜自動テストが整備済みの既存システムへの追加開発

回帰テスト（変更していない部分が壊れていないかを確認するテスト）が自動化されていれば、変更のたびに人手で全機能を確認する必要はありません。この場合、テスト工数が相対的に小さくなるのは妥当です。ただしその自動テストが誰の資産で、契約終了後も使えるのかは別途確認してください。

ケース5｜パッケージやSaaSの標準機能部分

標準機能そのものは提供元がテスト済みです。カスタマイズした部分と、標準機能と自社業務のつなぎ目に絞ってテストするのは合理的です。この場合、カスタマイズ部分のテストが明示されているかが判断のポイントになります。

テストを削った見積もりで、コストはどこへ移るのか

ここがこの記事の中心です。テストの薄い見積もりは「安い見積もり」ではなく、費用の発生タイミングと支払い主体が後ろにずれた見積もりとして読むのが正確です。

検収の前と後で、支払う人が変わる

同じ不具合でも、検収の前に見つかるか後に見つかるかで扱いが変わります。

テストを削るというのは、この表の上から下へ、不具合の発見位置をずらす行為です。発見が下にずれるほど、発注側が負担する要素が増えていきます。

民法が定めている境界

検収後の不具合対応が有償になるか無償になるかは、最終的には契約書の定めで決まります。ただし、その土台にある考え方は民法に書かれています。請負契約の場合、関係するのは次の2つの条文です。第636条が「そもそも請求できるか」、第637条が「いつまで請求できるか」を定めています（条文はe-Gov法令検索の民法・明治二十九年法律第八十九号、2026年8月20日取得）。

民法第636条（請負人の担保責任の制限）

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

つまり、注文者が与えた「指図」によって生じた不適合については、この条文が請求を制限する方向に働きます。ただし条文が言う「指図」は、発注側が出す要望や意見の一般よりも狭い概念で、どこまでが該当するかは個別の判断になります。また末尾のただし書は、請負人がその材料や指図が不適当であることを知りながら告げなかったときには、この制限が働かないと定めています。

要件が曖昧なまま「とりあえずこう作って」と進めた部分は、後から不具合として現れたときに、どちらの責任かという議論に入っていく可能性がある——という水準で理解してください。要件定義とテストの範囲を切り離して考えられない理由がここにあります。

民法第637条第1項（目的物の種類又は品質に関する担保責任の期間の制限）

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。

冒頭の「前条」は、いま見た第636条です。経営判断に効く点は2つあります。第一に、期間の起点は「引き渡し」ではなく「注文者が不適合を知った時」です。第二に、知った後に通知しないまま1年が過ぎると、修補の請求も、報酬の減額も、損害賠償も、解除もできなくなります。同条第2項は、引き渡しの時点で請負人が不適合を知っていた場合や、重大な過失によって知らなかった場合には第1項を適用しないと定めています。

なお、第636条・第637条は請負に関する規定です。契約が準委任であれば、これらの条文がそのまま当てはまるわけではありません。契約類型によって検収後の位置づけが変わる点は、請負と準委任で見積書の見方がどう変わるかで整理しています。

実務上は、検収後の無償対応期間（保証期間）を契約書で個別に定めているケースが多く見られます。見積書のテストの行と、契約書の保証期間の条項は、必ずセットで確認してください。片方だけを見て判断すると、片方に穴があっても気づけません。

「不具合」か「仕様変更」かで請求先が変わる

検収後に「動きがおかしい」となったとき、実務でもっとも揉めるのがこの切り分けです。

• 契約不適合（不具合）＝合意した仕様どおりに動いていない → 契約の定めに従って対応
• 仕様変更＝合意した仕様どおりだが、望んだ動きではない → 追加開発として有償

この切り分けの拠り所になるのが、合意した仕様と、その仕様を確認したテストの記録です。テスト計画書とテスト結果報告書が納品物に入っていないと、「どこまでを確認済みとして検収したのか」を後から示せません。テストの成果物が納品物リストに無いことは、金額の問題ではなく、切り分けの証拠が残らないという問題です。

保証期間が終わった後の不具合対応は、保守契約の範囲の話になります。保守側で何がどこまで含まれるかはシステム保守費用の相場と妥当性の見方で扱っているので、開発の見積もりと保守の見積もりは同じタイミングで並べて確認してください。開発側でテストを削り、保守側で対応範囲も絞っていると、不具合対応の受け皿がどこにも無い状態になります。

発注側に移る4つのコスト

テストが薄い見積もりで、発注側に移りやすいコストを整理します。いずれも見積書には金額として現れません。

1. 自社担当者の稼働。受け入れテストのシナリオ作成、実施、不具合報告、再確認の往復
2. 業務停止・障害対応のコスト。稼働後に見つかった不具合が業務を止めた場合の損失
3. 調査費用。不具合か仕様変更かを切り分けるための調査。契約不適合と認められなければ有償になりうる
4. 意思決定の遅れ。稼働時期がずれることで、当初見込んでいた効果の発現も後ろへずれる

見積総額を下げて得た金額より、この4つの負担のほうが大きくなれば、その意思決定は失敗です。逆に、テスト費が想定より高くても、上の4つを避けられるなら合理的な支出になりえます。テスト費用を金額の大小で判断してはいけないというのは、この意味です。判断に使うのは、削った金額と、削った結果として自社に移る負担の比較です。

確認が必要なケース｜4状態に仕分ける判定表

ここまでの内容を、手元の見積書に当てられる形にまとめます。各行を確認して、状態を割り当ててください。

表の使い方

• 高リスクが1つでもあれば、契約前に埋めてください。特に「非機能テストの欠落」「テストの成果物が納品物に無い」「検収後の保証が無い」の3つは、後から取り返しがつきにくい項目です
• 要確認は質問すれば解消します。次のセクションの質問文をそのまま送ってください
• 判断不能が大半を占める場合は、見積もりの問題ではありません。要件そのものが未確定なら、要件定義を分離して発注する進め方を検討してください。契約書がまだ提示されていないなど、時期的に当然のものは数に入れずに判定してください

10項目すべてを求めるのが常に正しいわけではありません。数百万円規模の案件に大規模開発と同じ体制を求めるのは過剰です。自社の規模とシステムの影響範囲に応じて、上から優先順位をつけてください。影響が社内に閉じるシステムなら「実施者」「不具合対応工数」「検収後の保証」の3つ、外部の利用者が使うシステムなら「非機能テスト」を最優先にする、といった判断になります。

ベンダーへそのまま送れる確認質問8つ

ここまでの確認項目を、そのまま送信できる文面にしました。コピーして使ってください。

依頼メールの文面

次のブロックをそのままコピーし、中ほどの目印の行を「確認質問8つ」に差し替えてお使いください。質問を絞って送る場合は、1文目の件数もあわせて書き換えてください。

お世話になっております。

ご提示いただいたお見積書について、社内で内容を確認するにあたり、
テスト工程の位置づけを整理させていただきたく、以下8つの点について
ご回答をお願いできますでしょうか。

金額の妥当性を疑うものではなく、弊社側で必要になる稼働と、検収後の
役割分担を事前に把握するための確認です。契約書の別紙に反映すべき
項目の洗い出しも兼ねております。

━━ ここに「確認質問8つ」を貼り付けてください ━━

お手数をおかけしますが、ご確認のほどよろしくお願いいたします。

「金額を疑っている」ではなく「社内稟議と契約書の別紙に必要」という立て付けにすると、通常の商習慣の範囲に収まります。

確認質問8つ

質問文は、ベンダーが実務で使う呼称に置き換えてあります（テストレベルとの対応は前掲の表を参照してください）。

8つすべてを送る必要は必ずしもありません。影響が社内に閉じるシステムなら1・6・8の3つ（実施者・不具合対応工数・検収後の保証）、外部の利用者が使うシステムなら5を加えた4つを優先してください。判定表でつけた優先順位と対応しています。

1. 今回のお見積もりでは、単体テスト・結合テスト・システムテスト・外部連携テスト・受け入れテスト支援のうち、どこまでが含まれますか。含まれない工程がある場合、その作業はどちらが実施する想定かも教えてください。
2. テストの成果物として、何を納品いただけますか。テスト計画書、テスト仕様書（テストケース一覧）、テスト結果報告書の3点について、それぞれ納品の有無をお聞かせください。
3. テスト環境の構築費用と利用料は、この見積もりのどの行に含まれていますか。別途になる場合は、想定金額と、環境をいつからいつまで維持するかを教えてください。
4. テストに使用するデータは、どちらが用意する想定ですか。弊社の本番データを使う場合、マスキング等の加工作業は見積もりに含まれていますか。
5. 要件定義書に記載した性能・セキュリティに関する要件について、どの試験で確認する計画ですか。該当する試験が今回の見積もりに含まれていない場合、その理由と、別途実施する場合の概算を教えてください。（要件定義がこれからの場合は、「性能・セキュリティ要件をいつ確定し、どの試験で確認する計画か」に置き換えて送ってください）
6. テスト中に検出された不具合の修正工数は、この見積もりにどのように織り込まれていますか。一定件数を想定している場合はその件数を、実績清算の場合は上限の有無を教えてください。
7. 検収の合格条件を、具体的にどのように定義する予定ですか。テストケースの消化率や、未解決不具合の許容範囲など、判定に使う基準をお聞かせください。
8. 検収後に不具合が見つかった場合、無償で対応いただける期間と範囲を教えてください。あわせて、仕様変更と不具合をどのような基準で切り分けるかについても、考え方をお聞かせください。

相見積もりを取っている場合は、同じ8つの質問を全社へ同じ文面で送ってください。回答の差が、そのまま見積総額の差の説明になります。

回答が返ってきた後、何を見るか

回答が返ってきたら、金額ではなく次の3点を見ます。

• 質問1と質問8の答えが噛み合っているか。テスト範囲が狭いのに保証期間が長い会社と、テスト範囲が広いのに保証が短い会社では、リスクの持ち方がまったく違います
• 質問3・質問4の答えが、自社の作業を発生させていないか。「貴社にてご準備」と書かれた項目は、自社の工数です。合計して、見積総額に足してから比較してください
• 質問6に数字が入っているか。「都度ご相談」だけの回答は、追加費用の入口が開いたままの状態です

複数社から回答が来たら、見積総額の差ではなく、「回答を反映した後の総額」の差で比較してください。テストの安い会社が、回答を反映すると最も高くなることは珍しくありません。

そのうえで、判定表の10項目をもう一度4状態へ割り当て直してください。要確認から説明済みへ動いた項目、動かなかった項目、高リスクのまま残った項目に分かれます。質問したのに動かなかった項目は、要確認ではなく高リスクとして扱い直してください。書面で答えられないということ自体が、その項目の情報が社内に存在しないというサインです。なお「要件がまだ決まっていないので出せない」という回答は、悪い回答ではありません。それは「判断不能」の正確な報告なので、見積もりを詰めるのではなく要件定義の進め方を先に決める合図として受け取ってください。

根拠資料と適用条件

この記事で使った資料の位置づけを分けておきます。どれを根拠にしているかで、主張の強さが変わります。

適用条件として4点補足します。ここは読み飛ばさないでください。

• IPAの比率の分母は、基本設計から総合テスト（ベンダ確認）までの5工程の実績工数です。システム化計画・要件定義と、総合テスト（ユーザ確認）は分母に入りません。一方、同書は各工程の実績工数を「各工程の社内、外部委託の実績工数合計」と定義し、社内工数は開発・管理・その他・作業配分不可の4区分から成ります。したがって5工程の中で発生した管理（PM）やインフラ構築・移行の工数は分母に含まれます。要件定義費やPM費を別行で立てた見積総額に対する比率ではない、という意味に読んでください
• JUASの「総合テスト26%」は、テスト工程の比率ではありません。内訳と、ベンダー側テストが「設計から結合テストまで61%」に含まれる理由は、本文の「2つの調査で数字が違う理由」で説明しています
• 中央値からの乖離は、異常の証拠ではありません。ばらつきの大きさは本文の「中央値だけを見ると判断を誤る」で示したとおりです。乖離は「理由を聞く」きっかけであって、判定結果ではありません
• 民法の条文は請負契約を前提としています。準委任契約や、アジャイル型の開発契約では前提が変わります。また実際の契約では保証期間を個別に定めていることが多いため、まず契約書の定めを確認してください

見積書のテスト工程をレビューする

判定表の10項目を1つずつ突き合わせるのは手間がかかります。koromoでは、受け取った見積書のテキストから項目を確認できる開発見積書のAIレビュー（登録不要）を公開しています。登録不要で、結果を見るまでメールアドレスの入力も必要ありません。テキストの抽出はブラウザ内で行い、送信前に内容を確認できます。

テスト種別・対象範囲・実施環境・実施者の記載、セキュリティや性能に関する試験の有無、外部連携やデータ移行の検証、リリース時の切り戻し（問題が起きたときに元の状態へ戻す手順）の扱いといった観点を含めて確認します。この記事の質問8つに対する回答をそのまま貼り付けて確認する使い方を想定しています。

診断結果は法的・会計的・技術的な最終判断ではなく、ベンダーへ次に何を聞くかを整理するためのものです。現在の見積もりのまま進めるのが合理的、という結論になることもあります。

よくある質問

まとめ

システム開発の見積もりに出てくるテスト費用は、金額の大小で判断する項目ではありません。判断すべきなのは、テストという作業が見積書の中にあるのか、契約の外にあるのか、それとも誰も引き受けていないのかです。

手順をもう一度整理します。

1. 見積書のテストの書かれ方を4パターンで見分ける（一式／工程名／行が無い／別名）
2. 5つのテストレベルへ分解し、空欄になったレベルを特定する。特に受け入れテストは発注側の工数になりやすい
3. 費用を生んでいるのが実行ではなく、設計・環境・データ・不具合対応であることを踏まえて読む
4. 統計は「外れていたら理由を聞く」ために使う。分母と工程定義が違うので、比率をそのまま当てはめない
5. 少ないことが合理的なケースかどうかを先に確認する（内包／自社実施／小規模／自動テスト／パッケージ）
6. テストを削った分がどこへ移るのかを、検収の前後で確認する。契約書の保証条項と必ずセットで見る
7. 各項目を説明済み／要確認／高リスク／判断不能の4状態へ仕分ける
8. 8つの質問を送り、回答を反映した後の総額で比較し、4状態を割り当て直す

最後に、この記事で最も伝えたいことを1つだけ。テストが書かれていない見積もりは、安い見積もりではありません。それは、検収後に発生しうる不具合対応の費用と、自社担当者の稼働が、見積書の外側へ移った状態です。移っていること自体が悪いわけではなく、方針として合意しているなら合理的な選択になります。問題になるのは、移っていることに発注側が気づかないまま契約したときです。見積書のテストの行を読むというのは、その移動が起きているかどうかを、契約前に見えるようにする作業です。