システム開発の終盤に差し掛かると、開発会社から「単体テスト完了しました」「結合テストに入ります」といった報告が届くようになります。しかし発注者として、そのとき何を確認すればいいのかわからない、という方は少なくありません。
テスト工程での確認を怠ると、納品後に「思っていた動作と違う」「本番でバグが発覚した」という事態が起きやすくなります。逆に、各テストで適切な確認を行えば、こうしたリスクを事前に抑えることができます。
この記事では、システム開発で行われる4種類のテストの目的と違いを整理しながら、発注者として各テスト工程で「何を確認すべきか」「どのエビデンスを請求できるか」を具体的に解説します。
テストの概論や自動化トレンドについてはソフトウェアテストとは？種類・工程、自動化トレンドについてを参照してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
システム開発のテスト工程とは？4段階の全体像
一般的なシステム開発（ウォーターフォール型）では、テストは4つの段階に分かれて実施されます。
テスト | 主な実施主体 | スコープ | 発注者の関与度 |
|---|---|---|---|
単体テスト | 開発者 | 機能・モジュール単位 | 低 |
結合テスト | 開発チーム | 機能間・システム間の連携 | 低〜中 |
システムテスト | 開発会社またはQAチーム | システム全体 | 中 |
受け入れテスト（UAT） | 発注者 | 業務要件との合致 | 高 |
各テストは開発工程と対応関係にあり、「上流工程で定めた仕様を、対応するテストで検証する」という構造になっています（V字モデル）。
なぜテストを4段階に分けるのか
段階を分ける最大の理由は、「不具合を早く発見するほど修正コストが低い」からです。
要件定義段階で見落とされた仕様の誤りを単体テストで発見するのと、本番稼働後に発見するのでは、修正に必要なコスト・時間が大きく異なります。テストを段階的に実施することで、不具合を小さな単位から順に潰していく仕組みになっています。
【工程別】各テストの目的と発注者の関与度
単体テスト（ユニットテスト）
単体テストとは、機能やモジュールを一つひとつ独立して動作確認するテストです。「このボタンを押したとき、この処理が走るか」「この入力に対して、正しい出力が返るか」を機能単位で検証します。
主な実施主体は開発者本人であり、発注者が直接参加することはほぼありません。ただし、テストが実施された証拠（エビデンス）は確認することができます。
発注者が確認すべき成果物:
- テスト仕様書（何をテストするかの計画書）
- テスト結果レポート（実施結果の記録）
発注者のチェックポイント:
- テスト項目数が要件の規模に見合っているか
- 消化率（実施した項目数 ÷ 計画項目数）はほぼ100%か
- バグ件数と重要度分類（Critical/High/Medium/Low）が明記されているか
結合テスト（インテグレーションテスト）
結合テストとは、複数の機能やシステムを連携させて動作を確認するテストです。「注文画面で確定すると、在庫管理システムに正しく反映されるか」「ユーザーAとユーザーBが同時に操作したとき、データが競合しないか」といった連携動作を検証します。
発注者の関与度は低〜中です。業務フロー（実際の業務の流れ）と開発の連携が整合しているかを確認するため、「主要業務シナリオが検証対象に含まれているか」を確認するとよいでしょう。
発注者が確認すべき成果物:
- 結合テスト結果レポート
- 業務フロー対応表（業務シナリオと対応するテスト項目の一覧）
発注者のチェックポイント:
- 自社の主要業務フロー（例: 受注→在庫確認→発送→請求）が網羅されているか
- 他システムとの連携部分が検証対象に含まれているか
システムテスト（総合テスト）
システムテストとは、システム全体を対象に「要件定義書・仕様書通りに動作するか」を検証するテストです。開発会社またはQAチームが主導し、機能要件（何ができるか）だけでなく、非機能要件（どのくらい速いか、安全か）も検証します。
発注者との関与度は中程度です。このテストは「要件定義書との照合」が主目的であるため、要件定義書に記載された全機能がテスト対象に含まれているかを確認することが重要です。
テスト環境（開発・テスト・本番環境の違い）についてはこちらの記事も参考にしてください。
発注者が確認すべき成果物:
- テスト計画書（何をどの順序でテストするかの計画）
- テスト結果サマリー（全項目の合否・バグ件数・残件）
発注者のチェックポイント:
- 要件定義書に記載したすべての機能がテスト対象になっているか
- 未テスト項目がある場合、理由と対処方針が明記されているか
- 非機能要件（性能・セキュリティ等）のテストが計画されているか
受け入れテスト（UAT：ユーザー受け入れテスト）
受け入れテストとは、発注者側が主体となり「業務に使えるか」を最終確認するテストです。開発会社が「正しく作った」と言えるのがシステムテストまでであり、受け入れテストで「発注者が要求したものが納品されている」かを確認します。
このテストは発注者が主役です。実際の業務シナリオを使って操作し、問題がなければ納品を受け入れる判断をします。
受け入れテストの詳細な実施手順・チェックリストについては、システム開発の検収・受け入れテストの進め方を参照してください。
発注者が各テストで要求できる3つのエビデンス
テスト結果を「問題ありませんでした」の一言で済ませることは避けるべきです。発注者は以下の3種類のエビデンス（証跡）を提出するよう開発会社に求めることができます。
テスト仕様書（テスト計画書）
テスト仕様書は「何を、どのようにテストするか」を事前に定めた文書です。テスト実施前に確認することで、「重要な機能がテスト対象から漏れていないか」を事前にチェックできます。
チェックポイント:
- テスト対象の機能一覧が要件定義書と対応しているか
- テスト条件（正常系・異常系の両方が含まれるか）が明記されているか
- テスト実施者と実施時期が計画されているか
テスト結果レポート（消化表）
テスト結果レポートは実施結果の記録です。「計画した件数のうち何件実施し、何件のバグが見つかったか」が確認できます。
チェックポイント:
- 消化率（実施項目数 ÷ 計画項目数）がほぼ100%か
- 残バグがゼロか、またはバグの残件について合意できているか
- バグの重要度分類（Critical/High/Medium/Low）が明記されているか
バグ管理票（課題管理表）
バグ管理票は、発見されたバグの一覧と対処状況を追跡する文書です。修正済み・次期対応・仕様として容認、などのステータスが記録されます。
チェックポイント:
- 重大バグ（Critical / High）がすべて修正済みになっているか
- 修正されていないバグについて、対処方針（次期対応・仕様変更等）の合意があるか
- バグの発見日と修正完了日が記録されているか（対応速度の確認）
テストで問題が発見された場合の対応フロー
テスト中にバグが発見されることは珍しくありません。問題は「バグがあること」ではなく、「適切に対処されているかどうか」です。
バグの重要度分類を理解する
バグの重要度（Severity）は一般的に4段階で分類されます。
重要度 | 定義 | 対処方針 |
|---|---|---|
Critical | システムが起動しない、データが消えるなど業務継続不能 | 即時修正必須（納品不可） |
High | 主要機能が動作しない、データが正しく保存されないなど | 原則修正必須 |
Medium | 一部機能に影響するが回避策がある | 修正推奨（次期対応も可） |
Low | 表示のずれ、誤字など軽微な問題 | 状況に応じて次期対応可 |
発注者として確認すべきは、CriticalおよびHighのバグがゼロになっているかです。MediumやLowのバグが残っている場合は、対処方針（いつ修正するか）について開発会社と文書で合意します。
本番稼働前の合意事項
バグが残った状態で納品を受け入れる場合は、以下を書面で合意しておくことが重要です。
- 残バグの件数・重要度・内容の一覧
- 修正スケジュール（いつまでに修正するか）
- 修正コストの負担（誰が費用を負担するか）
テスト工程のスケジュール管理で発注者が意識すること
テスト工程はプロジェクトスケジュールの末尾に位置するため、前工程（設計・開発）の遅延を吸収するバッファになりやすい特徴があります。「開発が遅れたのでテスト期間を2週間から1週間に圧縮する」という事態は実際によく起こります。
テスト期間の短縮は品質リスクに直結します。発注者として以下のポイントを意識してください。
契約・WBS段階で確認すること:
- 各テスト工程に割り当てられた期間（工数）が明記されているか
- テスト期間の最低ライン（例: 単体テスト2週間）が定められているか
プロジェクト進行中に確認すること:
- テスト結果報告のマイルストーン（いつ、何のテストが完了するか）が設定されているか
- 前工程の遅延が発生した場合、テスト期間を短縮するのではなく納期を延長する選択肢が提示されるか
まとめ｜テスト工程における発注者の正しい関与
システム開発のテスト工程は4段階（単体テスト→結合テスト→システムテスト→受け入れテスト）に分かれています。
発注者として特に重要なのは以下の3点です。
- エビデンスを確認する習慣をつける: 「問題なし」の報告だけで済ませず、テスト仕様書・テスト結果レポート・バグ管理票の提出を求める
- 重大バグ（Critical/High）がゼロであることを確認する: 残件がある場合は、対処方針を文書で合意してから納品を受け入れる
- テスト期間の圧縮を許容しない: スケジュール遅延が生じても、テスト工程を削ることは品質リスクになる
受け入れテスト（UAT）の具体的な実施手順やチェックリストについては、システム開発の検収・受け入れテストの進め方を参照してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
