システム開発のテスト工程（単体・結合・システムテスト）の基本
開発会社から「単体テスト」「結合テスト」と報告を受けても、何を確認しているのか分からず困っていませんか。各テスト工程の違いと、発注者が確認すべき観点を具体的に解説します。
受託開発の進行報告で「単体テストが完了しました」「現在結合テストを実施中です」といった言葉を聞いても、それぞれのテストが何を確認しているものなのか、発注者側にはイメージしづらいことがあります。「テストをしていると言われているのに、リリース後に不具合が見つかった」という事態を避けるためには、各テスト工程がどこまでを保証するものなのかを理解しておくことが欠かせません。
システム開発のテストは、一般的に「単体テスト」「結合テスト」「システムテスト」という段階を経て進められます。それぞれ確認する範囲や目的が異なり、どの工程で何を見ているかを把握しておくことで、進行報告の内容を正しく理解し、必要な確認を開発会社に求められるようになります。
この記事では、システム開発における主要なテスト工程の基本を、発注者の視点で分かりやすく解説します。
この記事の要点（30秒でわかるまとめ）
- テストは**「単体テスト→結合テスト→システムテスト」という段階**を経て進む
- 各工程は確認する範囲が異なり、後工程になるほど実際の業務に近い形で確認する
- 発注者が直接関わるのは主にシステムテスト以降（受け入れテスト）
- 「テスト済み」という報告を受けた際は、どの工程のテストかを確認することが重要
テスト工程全体の流れ
結論：システム開発のテストは、小さな単位から徐々に範囲を広げていく段階的な構造になっており、各工程で確認する内容が異なります。
| 工程 | 確認する範囲 | 主な実施者 |
|---|---|---|
| 単体テスト | 個々の機能・プログラム単位の動作 | 開発エンジニア |
| 結合テスト | 複数の機能・モジュールを連携させた動作 | 開発エンジニア・テスト担当 |
| システムテスト | システム全体が仕様通りに動作するか | テスト担当・開発会社 |
| 受け入れテスト（UAT） | 実際の業務で問題なく使えるか | 発注者（現場担当者） |
これらの工程は後工程になるほど「実際の使われ方」に近づいていきます。検収・受け入れテストで確認すべきポイントでも触れているように、発注者が最も重点的に関わるべきは受け入れテストの段階ですが、その手前の工程がどう進められているかを理解しておくことも、全体の品質を把握するうえで役立ちます。
単体テストで確認されること
結論：単体テストは、個々のプログラムや機能が仕様通りに動作するかを、最も小さな単位で確認する工程です。
たとえば「入力された金額を正しく計算する」「必須項目が未入力の場合にエラーを表示する」といった、機能単位での動作確認が行われます。この段階では画面全体の使い勝手や、他の機能との連携は確認対象になりません。単体テストは開発エンジニアが開発と並行して実施することが多く、発注者が直接目にする機会は少ない工程です。
結合テストで確認されること
結論：結合テストは、複数の機能やモジュールを連携させた際に、データの受け渡しや処理の流れが正しく動作するかを確認する工程です。
単体では正しく動いていた機能同士を組み合わせたときに、想定外の不具合が発生することがあります。たとえば「見積作成機能」と「承認フロー機能」を連携させた際に、承認待ちのデータが正しく引き渡されるかどうかは、結合テストの段階で確認されます。見積作成から承認までのように複数機能が連携する仕組みでは、この結合テストの範囲が特に重要になります。
システムテストで確認されること
結論：システムテストは、要件定義書に記載された機能・性能要件を、システム全体として満たしているかを確認する工程です。
結合テストが機能同士の連携を見るのに対し、システムテストはシステム全体を通した業務フローが仕様通りに動くかを確認します。また、非機能要件（同時アクセス時の性能、セキュリティ面の確認など）も、この段階で検証されることが一般的です。要件定義書のレビューで確認すべきチェックポイントで整理した非機能要件の観点は、システムテストでどこまで検証されるかを確認する際にも活用できます。
発注者が確認すべきポイント
結論：発注者としては、各テスト工程の進行報告を受けた際に「どの範囲まで確認済みなのか」を明確にしてもらうことが重要です。
「テストが完了しました」という報告だけでは、単体テストの完了を指しているのか、システムテストまで含んでいるのかが分かりません。進行報告を受ける際は、どの工程のテストが完了し、どの工程がこれから実施されるのかを具体的に確認するとよいでしょう。また、受け入れテスト（UAT）の段階では、実際に日常業務で使う担当者に操作してもらい、仕様通りであっても「使いにくい」「業務フローと合わない」といった問題がないかを確認することが、リリース後のトラブルを防ぐうえで特に重要です。
よくある質問（FAQ）
Q. すべてのテスト工程を発注者が確認する必要がありますか？ A. 単体テスト・結合テストは開発会社側の専門的な作業であり、発注者が詳細を確認する必要性は低いです。発注者が重点的に関わるべきは、システムテスト以降、特に受け入れテストの段階です。
Q. テスト工程でバグが見つかった場合、スケジュールに影響しますか？ A. 発見されたバグの内容や量によっては、修正にかかる時間がスケジュールに影響する可能性があります。テスト工程で一定数の不具合が見つかることは一般的であるため、スケジュールにはあらかじめ調整の余地を持たせておくことをおすすめします。
Q. テスト項目書はどのように確認すればよいですか？ A. テスト項目書には、何を確認する目的で、どのような手順でテストを行うかが記載されています。要件定義書に記載した機能や非機能要件が、テスト項目として網羅されているかを確認するとよいでしょう。
Q. 受け入れテストで問題が見つかった場合、どう対応すればよいですか？ A. 問題の内容を具体的に記録し、開発会社と修正方針・スケジュールを協議することになります。軽微な修正か、仕様の見直しが必要な問題かによって対応の進め方は変わります。
まとめ
システム開発のテストは、単体テスト・結合テスト・システムテスト・受け入れテストという段階を経て、徐々に実際の業務に近い形で品質が確認されていきます。発注者としては、各工程がどこまでを保証するものかを理解し、進行報告を受けた際に「どの範囲まで確認済みか」を具体的に確認する姿勢が重要です。
Irwin&co株式会社では、各テスト工程を経た開発プロセスのもとで、案件継続率95%という実績を積み重ねています。テスト工程を含めた開発の進め方について不安がある場合は、開発事例やお問い合わせから、お気軽にご相談ください。
執筆者プロフィール
アーウィン 海Irwin&co株式会社 代表取締役
生成AIを活用したシステム開発・コンサルティング・研修サービスを提供するIrwin&co株式会社を創業し、IT専任者のいない中小企業を中心に、業務システムの構築とSaaSからの移行を支援している。「SaaSの標準機能に業務を合わせるのではなく、業務に合わせたシステムを自社の資産として持つ」という考え方のもと、不動産をはじめとする業界で、生成AIを前提とした業務システムの設計・開発を数多く手がける。