テスト工数は開発全体の32％──結合テストと総合テストが担う品質保証の本質

はじめに：テスト工数が増えるのは、想定外ではない

「設計や実装が完了したはずなのに、なぜテストにこれほど時間がかかるのか」
 「本当にテストにこれだけのリソースを割く必要があるのか」

こうした疑問は、開発プロジェクトに関わる事業会社のシステム担当者であれば、一度は感じたことがあるでしょう。

しかし、IPA（情報処理推進機構）が公表する『ソフトウェア開発分析データ集（2022年度）』によれば、 新規開発プロジェクトにおいて結合テストと総合テストにかかる実績工数の中央値はそれぞれ20.1％と11.9％。合計で32.0％に達します。
これは、複数のプロジェクト実績に基づいた“標準的な割合”であり、特別な例ではありません。

参照：ソフトウェア開発分析データ集（2022年度）　A3.3.8 工程別工数：新規開発
https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf

結合テストと総合テストの役割とは

この32％という工数は、単なる「動作確認」ではなく、設計や実装では見落とされやすい不整合やリスクを制御するための構造的なプロセスに費やされています。

結合テスト（20.1%）

• モジュール間や画面・API間の連携整合性の確認
• 呼び出し失敗や例外発生時のエラー制御
• 状態遷移やデータフローの不整合検出
• 多様な組み合わせテストと事前準備が求められる

一般には「結合テストは開発者が行うもの」と思われがちですが、実務ではQA（品質保証）部門やテスト専門チームが関与するケースも多くあります。

特に中〜大規模開発では、仕様の網羅性や例外ケースへの対応など、第三者視点でのテスト設計と評価が求められる領域となるためです。

総合テスト（11.9%）

• 業務シナリオ単位での通し検証
• ロール別の権限制御、画面遷移、入力制御の整合性
• リグレッション（回帰）テストや非機能要件の確認

なぜ結合テストの方が工数が大きくなるのか

一見すると、システム全体を対象とする総合テストの方が広範に思えますが、実際には結合テストの方が工数が大きくなる構造的な理由があります。

• モジュールやAPIなどの連携パターンが膨大である
• “つなぎ目”で仕様の不整合が発覚しやすく、再テストが多発する

このような構造的な負荷が、結合テストにおける20％超の工数比率に反映されています。

工数割合が“少なすぎる”“多すぎる”場合に注意すべきこと

「32％」という数値は一つの目安にすぎません。
この比率から外れる場合、その背景には体制や進め方の問題が隠れていることがあります。

工数が少なすぎる（20％未満など）

想定される背景	リスク
テスト工程を過小評価している	不具合の取りこぼし・品質事故の発生
単体テストで十分と誤解している	結合部の仕様未検証で本番移行
テスト体制が確立していない	属人化・抜け漏れ・曖昧な判断の増加

工数が多すぎる（40～50％以上）

想定される背景	留意点
要件変更が頻発している	結合・総合テストが“二次実装”の場に
システム構成が複雑	外部連携やサブシステム統合などで検証負荷が高い
受入相当の確認まで開発側が担っている	発注側の関与不足／業務定義が不十分で手戻りが連鎖している

発注者として理解しておくべき3つの視点

① 見積に含まれるテスト工数の妥当性を判断する

結合テスト＋総合テストで32％前後が標準的な水準です。
これより極端に少ない・多い場合は、見積根拠や工程内容を確認することでリスク把握が可能になります。

② 要件の曖昧さは“テスト工数”に跳ね返る

業務フローや例外条件が曖昧なまま開発が進むと、テスト段階で不具合が集中し、手戻りによって工数が増大します。
「上流での不確かさ」は「下流でのテスト工数増」として現れます。

③ テスト方針・観点を発注者も共有する

仕様書だけでは拾いきれない業務視点の確認ポイントを発注側も示すことで、仕様とのズレ・想定漏れを抑制できます。

まとめ：32％の工数は品質を守るための“現実的なコスト”

結合テスト・総合テストにかかる工数は、設計や実装だけでは補いきれない業務整合性と品質を保証するために不可欠なコストです。

この工程を「削る」対象ではなく「活かす」対象として捉え、見積妥当性の判断、上流定義の明確化、テスト観点の共有を通じて、発注側としての品質責任を果たすことが、成功する開発プロジェクトの鍵となります。