システム開発の見積書を並べて比較していると、ある欄で必ず手が止まります。テストの工数です。画面ごと・機能ごとの実装工数は細かく分かれているのに、テストだけ「テスト一式」とまとめられている。金額は全体の2〜4割を占めることもあるのに、内訳がない。
高いのか安いのか判断できないので、結局そのまま通す。あるいは「テストが高いので削れませんか」と言って、削ってはいけないものを削ってしまう。どちらも見積書を読み解く手がかりがないことから来ています。
テスト工数は、実は掛け算2つで概算できます。 発注する側がこれを持っていると、見積書に対して具体的な質問ができるようになります。
1つ目の掛け算:何件テストするのか
最初に出すのは金額でも時間でもなく、テストケースの件数です。
推定ケース数 = ストーリーポイント × テスト密度ストーリーポイントは、開発する機能の規模を示す数字です。アジャイルで進めている現場なら既に持っています。テスト密度は、そのチームが過去に1ポイントあたり何件のテストケースを書いてきたかという係数です。
密度の出し方は単純で、過去数スプリントの総テストケース数を、同じ期間に消化した総ストーリーポイントで割ります。3〜5スプリント分のデータがあれば、係数として十分に安定します。
ここが重要な点です。テスト密度は業界標準の数字ではなく、そのチーム固有の数字です。同じ規模の機能でも、扱うドメインや品質要求によって必要なケース数は変わります。だから「一般的にはこのくらい」という比較には意味がなく、そのチームの過去実績と比べることにだけ意味があります。
2つ目の掛け算:1件あたりどれだけかかるのか
件数が出たら、次は実行にかかる時間です。
推定実行時間 = ケース数 × 複雑度別の所要時間すべてのケースを同じ重みで数えると外れます。単純な入力チェックと、外部システムを跨いだ一連の業務フローの確認では、1件の重さが違うためです。複雑度で3段階程度に分け、それぞれの所要時間を掛け合わせます。
複雑度ごとの所要時間も、やはり過去実績から出します。感覚で置いた数字を掛けると、それは検算ではなくただの別の見積もりになります。
発注側が見積書に対して聞くべきこと
この式が手元にあると、質問の形が変わります。「テストが高いので下げてください」ではなく、次の2つを聞きます。
「テスト密度は、御社の過去実績のどのくらいですか」
答えられる相手なら、見積もりが実績から出ていることが分かります。答えが「一般的にこのくらいです」だった場合、その見積もりは経験則というより、根拠のない安全側の数字である可能性があります。逆に極端に低い密度が返ってきたら、テストが薄い前提で価格を作っている疑いを持てます。
「複雑度の高いケースは、全体の何割を見込んでいますか」
ここが実務上いちばん効きます。複雑度の内訳が答えられない見積もりは、件数の粒度で考えられていません。そして開発の途中で「思ったより結合が重かった」という理由の追加請求が発生しやすいのは、この部分の見立てが甘いケースです。
見積書を安く見せる最も簡単な方法は、複雑度の高いケースを少なく見込むことです。契約時点では安く、検収前に膨らむ。 この形を避けるための質問だと考えてください。
「テストを削る」の正しい削り方
予算が合わないときにテストを削ること自体は、判断としてありえます。問題は削り方です。
| よくある削り方 | 実際に起きること |
|---|---|
| テスト工数を一律で2割カット | どのケースが消えたか誰も把握していない |
| 「自動テストは後回し」 | 手動での回帰確認が毎回の保守コストとして残る |
| 対象機能を絞ってケース数を減らす | 削った範囲が明示され、リスクを引き受けられる |
削ってよいのは3つ目だけです。件数ベースで考えていれば「どこを削るか」を指定できます が、金額ベースで削ると何が消えたか分からない。掛け算2つで内訳を持つことの実務的な価値は、値切るためではなくここにあります。
なお、ケース数を増やせば品質が上がるわけでもありません。カバレッジを満たしていてもバグが止まらないことは珍しくなく、件数は必要条件であって十分条件ではないという前提は共有しておく必要があります。
見積もりの前提が崩れる場面
この方法には効かない場面もあります。過去実績がない場合です。初めて組む相手、初めて触る領域では、テスト密度の係数そのものが存在しません。
その場合に取れるのは、最初の数スプリントを「係数を測る期間」として扱う進め方です。全体を一括で見積もらず、最初の区切りで実績を出してから残りを見積もり直す。進め方をアジャイル型にするかウォーターフォール型にするかの判断は、この係数が手元にあるかどうかでも変わってきます。
もうひとつ、自動テストを含む見積もりでは、書く工数と維持する工数が別であることを確認してください。テスト自動化が定着しない理由の多くは、初期構築だけが見積もられ、壊れたテストを直し続ける時間が誰の担当でもなかったことにあります。
次にやること
手元にある見積書を1つ開き、テスト工数が「一式」と書かれているかどうかを見てください。 一式になっていたら、上の2つの質問をそのまま投げます。返ってくる答えの具体性が、そのまま相手の見積もり精度の目安になります。
社内に過去の開発実績があるなら、直近3スプリント分のテストケース数とストーリーポイントを集計してみてください。自社の係数が1つ手に入るだけで、次の発注から見積書の読み方が変わります。
開発の見積もりレビュー、品質要件の設計、既存プロジェクトのテスト工数の妥当性確認については、グリームハブの開発・AI・自動化のご相談で承っています。案件の規模と現在の体制によって見るべき点が変わるため、お問い合わせから個別にご相談ください。
