受入テストで発注側がやるべきこと｜テスト項目の作り方と進め方
システム開発の終盤には、開発会社から納品されたシステムを発注側が確認する「受入テスト」の工程があります。ここで問題がないと判断すると検収となり、多くの契約では代金の支払いが確定します。
ところが、受入テストを「開発会社がテストしたものを最後に触ってみる工程」と捉え、数日だけ画面を操作して終わらせてしまう発注側は少なくありません。その結果、本番運用を始めてから業務に合わない動きや不具合が見つかり、修正費用を誰が負担するかで揉めることになります。
受入テストは、開発会社の作業を点検する場であると同時に、自社の業務でそのシステムが使えるかを発注側が判断する場です。この判断は、業務を知っている発注側にしかできません。
この記事では、受入テストの位置づけ、発注側がやるべきことと開発会社に任せてよいこと、テスト項目の作り方、進め方、不具合が見つかったときの判断と検収の注意点を解説します。
受入テストは何を確かめる工程か
システム開発のテストには、開発会社が行うものと発注側が行うものがあります。開発会社が行うテストは、作ったプログラムが設計どおりに動くかを確かめるものです。一方、受入テストは、納品されたシステムが契約で合意した内容を満たし、自社の業務で使える状態にあるかを発注側が確かめるものです。
| テストの種類 | 主な実施者 | 確かめること |
|---|---|---|
| 単体テスト | 開発会社 | 個々の機能や部品が設計どおりに動くか |
| 結合テスト | 開発会社 | 機能同士や外部システムとのつながりが正しく動くか |
| システムテスト | 開発会社 | システム全体が仕様書どおりに動くか、性能や負荷に問題がないか |
| 受入テスト | 発注側（開発会社が支援することもある） | 合意した仕様を満たし、実際の業務で使えるか |
開発会社のテストが仕様書を基準にしているのに対し、受入テストは業務を基準にしています。仕様書どおりに作られていても、実際の業務の流れに当てはめると手順が足りない、例外的な取引を処理できないといった問題は、受入テストで初めて見つかることがあります。
受入テストは、契約上の意味も持ちます。IPAと経済産業省が公開している「情報システム・モデル取引・契約書」（第二版）では、発注側が検査仕様書に基づいて検査し、合格した時点で検収完了とする形が示されています。さらに、検査期間内に発注側が書面で具体的な理由を示して異議を述べない場合は、検査に合格したものとみなす規定例も置かれています。実際の契約がこのモデルどおりとは限りませんが、自社の契約書で検査期間とみなし合格の規定を確認しておくことは欠かせません。
参考：情報システム・モデル取引・契約書（第二版）／IPA（情報処理推進機構）
発注側がやるべきことと開発会社に任せてよいこと
情報システム部門がない会社では、受入テストのすべてを自社で行うのは難しいこともあります。その場合でも、発注側にしかできないことと、開発会社に支援してもらえることを分けて考えれば、限られた人員で必要な確認ができます。
| 作業 | 発注側が担う | 開発会社に支援を依頼できる |
|---|---|---|
| 合格基準の決定 | どの状態なら業務に使えるかを決める | 基準の書き方や過去の例を示してもらう |
| テストシナリオの作成 | 実際の業務の流れと例外ケースを洗い出す | シナリオを手順書の形式に整えてもらう |
| テストデータの準備 | 実際の業務に近いデータを用意する | 大量データの投入や、個人情報を伏せたデータの作成 |
| テストの実施 | 実際に業務を行う担当者が操作する | 環境の準備、操作方法の説明 |
| 結果の判定 | 合格・不合格を判断し、不具合を報告する | 報告された事象の原因調査と修正 |
ここで注意したいのは、テストシナリオの作成と結果の判定を開発会社に任せきりにしないことです。開発会社が作ったシナリオは、開発会社が理解している仕様の範囲でしか作れません。発注側の業務で当たり前に起きる例外や、仕様書に書かれていなかった前提は、シナリオから漏れやすくなります。
また、受入テストの実施者には、システムを実際に使う現場の担当者を入れてください。発注の窓口になった担当者だけで確認すると、現場の操作感や作業の手順に合っているかが見落とされます。現場の担当者が受入テストに参加できる時間を、開発のスケジュールが決まった段階で確保しておくことが重要です。
テスト項目の作り方
受入テストの項目は、画面や機能の一覧から作るのではなく、業務の流れから作るのが基本です。たとえば受注管理システムであれば、「受注を登録する」「在庫を引き当てる」「出荷指示を出す」「請求書を発行する」という一連の流れを一つのシナリオとして通し、それぞれの段階で結果が正しいかを確かめます。
シナリオを作る手順
テスト項目は、次の順で作ると漏れを減らせます。
- システムが関わる業務を、開始から終了まで書き出す
- それぞれの業務について、通常の流れを一つのシナリオにする
- 通常の流れから外れるケースを洗い出す（取消、変更、返品、締め日をまたぐ処理など）
- 権限ごとの操作を確認する（一般担当者、承認者、管理者など）
- 帳票や出力データの中身を、現行の帳票や手計算の結果と照合する項目を加える
- 各項目に、期待する結果と合格の基準を書く
例外ケースは、現場の担当者に「過去に困った処理」「月末や年度末にだけ発生する作業」を聞くと見つかりやすくなります。日常業務の中では当たり前すぎて誰も文書にしていない処理が、システムで扱えないことに気づくのは、この段階であることが多いです。
期待する結果を具体的に書く
テスト項目の失敗例として多いのが、「正しく表示されること」「問題なく登録できること」といった曖昧な期待結果です。これでは、テストをした人によって合否の判断が変わります。「税込金額が◯円と表示される」「登録後、一覧画面の先頭に表示される」のように、誰が見ても同じ判断ができる書き方にします。
優先度をつける
すべての項目を同じ重さで扱うと、限られた期間で重要な確認が終わらないことがあります。業務が止まる、金額が間違う、個人情報が他人に見えるといった影響の大きい項目を最優先にし、表示の細かな体裁などは後回しにします。優先度を事前に決めておくと、不具合が見つかったときに検収を止めるべきかどうかの判断にも使えます。
テスト項目の量は、システムの規模よりも業務の種類と例外の多さで決まります。項目を増やしすぎて期間内に終わらない計画になっていないか、優先度の高い項目だけで受入テスト期間の半分程度に収まるかを、作成した時点で見積もっておくと安心です。
受入テストの進め方
受入テストは、開発の終盤に急に始めるものではありません。準備は、要件定義が終わった段階から始められます。
| 時期 | 発注側がやること |
|---|---|
| 要件定義の完了時 | 受入テストの期間と参加者を決め、スケジュールに組み込む。契約書の検査期間を確認する |
| 設計の段階 | 業務シナリオと例外ケースを洗い出し始める。テストデータの準備方法を決める |
| 開発の段階 | テスト項目と期待結果を完成させ、開発会社と内容をすり合わせる |
| システムテストの完了時 | 開発会社のテスト結果の報告を受け、未解決の不具合を確認する |
| 受入テスト期間 | シナリオに沿ってテストを行い、結果と不具合を記録して報告する |
| 修正後 | 修正された箇所と、その影響を受けそうな箇所を再テストする |
受入テストの期間は、契約で定めた検査期間の中に収める必要があります。検査期間が短すぎると、十分な確認ができないまま期限を迎えてしまいます。業務の繁忙期と重ならないか、現場の担当者が参加できるかを考慮し、必要であれば契約前に検査期間の長さを調整してください。
テスト環境とデータも事前に決めておきます。本番と同じ構成の環境で、実際の業務に近いデータを使ってテストしなければ、本番で起きる問題を見つけられません。ただし、個人情報を含む実データをそのまま使う場合は、テスト環境のアクセス管理やデータの消去方法を開発会社と取り決めておく必要があります。
不具合の報告方法も統一しておきます。報告には、操作した手順、期待した結果、実際の結果、画面のスクリーンショット、発生日時を含めると、開発会社が原因を調べやすくなります。報告をメールやチャットに散らばらせず、一つの管理表やチケット管理の仕組みにまとめておくと、修正の状況が追いやすくなります。
結果を記録し、再テストの範囲を決める
テストの結果は、項目ごとに実施日、実施者、結果（合格・不合格・保留）を記録します。この記録は、検収の判断材料になるだけでなく、後で不具合が見つかったときに「その時点ではどう動いていたか」を確認する資料にもなります。表計算ソフトで管理する場合でも、テスト項目の一覧に結果の列を加える形にしておくと、進み具合がひと目で分かります。
不具合が修正されたら、修正された項目だけでなく、その修正の影響を受けそうな項目も再テストします。たとえば金額計算の修正であれば、計算結果を使う帳票や集計も確認が必要です。どこまで再テストすべきかは発注側だけでは判断しにくいため、修正の報告を受けるときに、影響範囲と再テストを推奨する項目を開発会社に示してもらうようにしてください。
不具合が見つかったときの判断と検収の注意点
受入テストで見つかった問題は、すべてが開発会社の責任による不具合とは限りません。まず、その問題が次のどれにあたるかを整理します。
| 問題の種類 | 判断の基準 | 扱い |
|---|---|---|
| 仕様どおりに動いていない | 合意した仕様書と動きが違う | 開発会社が修正する |
| 仕様どおりだが業務に合わない | 仕様書の記載どおりに動いている | 仕様変更として扱い、費用と期間を協議する |
| 仕様に書かれていなかった | 仕様書に記載がなく、どちらとも読める | 当時のやり取りを確認し、扱いを協議する |
二つ目と三つ目は、発注側が不具合だと考えていても、開発会社は仕様変更だと考えることがあります。このとき判断の拠り所になるのは、合意した仕様書と、要件定義の過程で残した議事録やメールです。受入テストで揉めないためには、テストの準備と同じくらい、開発中の合意内容を記録しておくことが大切です。
検収を止めるかどうかの判断
不具合が見つかったからといって、必ずしも検収を止める必要はありません。業務が止まる、金額が間違うなど重大な不具合が残っている場合は検収を保留し、修正後に再テストします。表示の体裁など業務に影響しない軽微な不具合だけが残っている場合は、修正の期限を書面で取り決めたうえで検収し、運用を始める判断もありえます。
ここで重要なのが、検査期間とみなし合格の規定です。期間内に具体的な理由を示して異議を伝えなければ合格とみなす契約の場合、テストが終わっていなくても検収が成立してしまう可能性があります。期間内にテストが終わらない見込みになったら、その時点で開発会社に書面で伝え、期間の延長を合意してください。
検収後に見つかった不具合
検収後に見つかった不具合は、契約不適合責任の問題になります。民法では、請負の注文者は、契約の内容に適合しないことを知った時から1年以内にその旨を通知しないと、修補などの請求ができなくなると定められています（第637条）。ただし、システム開発の契約では、検収から一定期間内に限るなど、民法と異なる期間を定めることが一般的です。モデル契約でも期間は空欄の選択式になっています。自社の契約で何か月と定めているかを確認し、その期間内に業務の一巡（月次処理や締め処理など）を確認できるかを考えておくことが大切です。
まとめ
受入テストは、開発会社の作業を最後に点検する工程ではなく、自社の業務でシステムが使えるかを発注側が判断する工程です。業務の流れと例外を知っているのは発注側だけなので、シナリオの作成と結果の判定は開発会社に任せきりにせず、現場の担当者を巻き込んで進める必要があります。
準備として押さえておきたいことを整理すると次のとおりです。
- 契約書の検査期間、みなし合格の規定、契約不適合責任の期間を確認する
- 要件定義が終わった時点で、受入テストの期間と参加者を決める
- テスト項目は画面一覧ではなく業務の流れから作り、例外ケースを現場に聞く
- 期待する結果を、誰が見ても同じ判断ができる形で書く
- 見つかった問題は、不具合、仕様変更、仕様の漏れに分けて扱う
これから開発を発注する段階であれば、まず契約書案で検査期間と契約不適合責任の期間を確認し、受入テストに必要な日数と人員が確保できるかを社内で検討してください。開発がすでに進んでいる場合は、今のうちに現場の担当者と業務の流れを書き出し、テストシナリオの下書きを始めておくと、検収の段階で慌てずに済みます。