受入テスト（UAT：User Acceptance Test）は、開発会社から納品されたシステムを、発注側が自分たちの業務で使えるかを確かめる最後のテストである。単体テストや結合テスト、システムテストは開発会社が行うが、受入テストだけは発注側が主体になる。
そして受入テストの合否は、多くの契約で検収、つまり支払いの起点に直結している。ここを「開発会社がやってくれるテストの最終確認」程度に考えていると、検査期間が終わった瞬間に合格とみなされ、気づいた不具合を無償で直してもらえなくなる、ということが起こる。
この記事は、受託開発会社として受入テストに立ち会う側から、発注側が受入テストをどう計画し、どこで合否を決め、検収とどう結びつけるかを整理したものである。テスト技法の解説ではなく、発注側の判断の道具として書いた。
この記事でわかること
Photo by Jakub Żerdzicki on Unsplash
- 受入テストとシステムテストの違い（誰が・何を基準に・何のために行うか）
- 受入テストと検収・支払いの関係が、請負と準委任でどう変わるか
- 「検査期間内に異議を出さないと合格とみなす」条項の意味と、発注側が備えること
- テストケースを誰が作るか：発注側と開発会社の分担表
- 受入テストで見つかった不具合を「直してもらえるもの」と「追加費用になるもの」に分ける基準
- 受入テストをどこまでやるかの決め方と、計画に入れる項目
結論：受入テストは「テスト」ではなく「検収の手続き」として計画する
Photo by Dylan Gillis on Unsplash
先に結論を書く。発注側が受入テストで押さえるべきことは4つしかない。
| # | 押さえること | 理由 |
|---|---|---|
| 1 | 合否の基準を、テスト開始前に書面で合意する | 基準が無いと、不具合が「契約どおりでない」のか「業務に合わない」のかを判断できない |
| 2 | 検査期間と、その期間に動ける担当者を先に確保する | 期間内に異議を出さないと合格扱いになる契約が多い |
| 3 | テストケースの中身（業務シナリオ）は発注側が決める | 業務を知っているのは発注側だけ。開発会社に任せると「仕様どおり動くか」しか確認されない |
| 4 | 見つかった不具合を3つに分類して扱う | 無償で直るもの・費用がかかるもの・運用で回避するものを混ぜると、検収が止まる |
以下、それぞれを順に説明する。
受入テスト（UAT）とは：システムテストとの違い
Photo by Romain Dancre on Unsplash
受入テストは、開発工程の最後に置かれるテストである。開発会社が行うテストとは、主体・基準・目的がすべて違う。
| システムテスト（総合テスト） | 受入テスト（UAT） | |
|---|---|---|
| 主体 | 開発会社 | 発注側（利用部門・情報システム部門） |
| 基準 | 要件定義書・設計書どおりに動くか | 業務で使えるか、契約で合意した検査基準を満たすか |
| 目的 | 不具合を出し切る | 受け取るかどうかを決める |
| 使うデータ | テスト用に作ったデータ | できるだけ本番に近いデータ（移行データを含む） |
| 結果の扱い | 開発会社の内部品質記録 | 検収・支払いの判断材料 |
違いの核心は最後の行にある。システムテストは開発会社の品質活動だが、受入テストは取引の手続きである。だから受入テストの計画には、テスト技法よりも先に契約の条件を確認する必要がある。
「総合テスト」「ユーザーテスト」と呼び名が混ざることがあるが、発注側にとって重要なのは名前ではなく、そのテストの合否が検収に使われるかどうかである。契約書や個別契約で、どのテストの結果をもって検収とするかを確認しておく。
UAT環境とは
受入テストは、本番とほぼ同じ構成の検証用環境（UAT環境・ステージング環境）で行うのが一般的である。開発環境で受入テストをすると、本番で使う外部連携先・権限設定・データ量が再現されず、「テストでは通ったのに本番で動かない」が起きる。
UAT環境を誰が用意し、費用をどちらが持つかは見積の段階で決めておく。クラウドの検証環境を受入テストの期間だけ追加で立てる場合、その費用が見積に入っているかは確認したほうがよい。
受入テストと検収・支払いの関係：請負と準委任で変わる
受入テストの意味は、契約形態によって大きく変わる。ここを取り違えると、受入テストで不合格を出しても支払いが止まらない、あるいは逆に、軽微な指摘で検収が何週間も止まる。
| 請負契約 | 準委任契約（履行割合型） | |
|---|---|---|
| 開発会社の義務 | 仕事の完成 | 業務の遂行（作業そのもの） |
| 受入テストの位置づけ | 完成を確認する検査。合格が検収完了・報酬の支払条件になるのが一般的 | 作業の結果を確認する場。不合格でも、それだけで報酬が止まるとは限らない |
| 不具合が出たときの扱い | 契約不適合として修正（追完）を求められる | 修正作業そのものが、追加の作業時間として扱われることがある |
| 発注側が備えること | 検査基準・検査期間・不合格時の手続きを契約で決める | 完了の定義と、修正作業を誰の負担で行うかを決める |
請負と準委任の違いそのものは請負と準委任の違いに、準委任で揉めやすい点は準委任契約の注意点に詳しく書いた。受入テストの計画では、少なくとも「この開発は請負で、受入テストの合格が検収になる」のか、「準委任で、受入テストは作業の確認にすぎない」のかを、発注側の担当者全員が同じように理解している状態を作っておく。
IPAのモデル契約に見る、検収の標準的な流れ
情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書（第二版）」は、請負型のソフトウェア開発について、納入から検収までを次のように定めている（条文の趣旨を要約）。
- 開発会社は、個別契約で定める期日までに、納入物を検収依頼書（兼納品書）とともに納入する
- 発注側は、開発会社と協議のうえ、テスト項目・テストデータ・テスト方法・テスト期間などを定めた検査仕様書を作成する
- 発注側は、個別契約で定める検査期間内に、検査仕様書に基づいて検査する
- 合格なら検査合格書を交付する。不合格なら、具体的な理由を書面で示して修正を求め、開発会社は協議した期限内に無償で修正して再納入する
- 検査合格書が交付されなくても、検査期間内に発注側が書面で具体的な理由を示して異議を述べなければ、合格とみなされる
- 検査合格をもって検収完了とする
この流れから、発注側にとって重要な点が2つ読み取れる。
- 検査仕様書（受入テストの中身）を作るのは発注側とされている。開発会社は作成を支援できるが、モデル契約ではその支援は別途の契約として切り出す形になっている
- 期間内に異議を出さなければ合格になる。テストが終わっていなくても、期間が過ぎれば検収が完了する
自社の契約書がモデル契約と同じ構成とは限らない。ただ、多くの開発契約がこの考え方をベースにしているため、自社の契約書で「検査期間」「みなし合格」「不合格時の手続き」に当たる条項を探し、どう書かれているかを確認しておくとよい。
「みなし合格」で失敗しないために、発注側が先に決めること
受託開発の現場で受入テストが揉めるのは、テストの技術的な難しさよりも、検査期間と体制が足りないことが原因であることが多い。利用部門の担当者が通常業務と兼務で、テストに充てられる時間が想定の半分しかなかった、という状況は珍しくない。
検査期間に関わる失敗は、次の順で起きる。
- 検査期間が、テストの量に対して短く設定されている（見積段階で深く考えずに決まっている）
- 期間の後半になって不具合が見つかるが、書面での異議の出し方が決まっていない
- 期間が過ぎ、契約上は合格・検収完了になる
- 以後の修正は、契約不適合責任の範囲で扱うか、追加費用で扱うかの議論になる
これを避けるために、発注側はテストを始める前に次を決めておく。
- 検査期間は何営業日か（シナリオ数から逆算して決めたか）
- 期間中にテストを行う担当者は誰で、1日に何時間テストに使えるか
- 不合格や指摘を出すときの書式と提出先（メールでよいか、所定の書面か）
- 指摘に対して開発会社が修正し、再テストする往復を期間内に何回見込むか
- 期間を延長するときの手続き（誰が、いつまでに申し出るか）
検査期間の長さに業界標準の日数があるわけではない。「テストする業務シナリオの数 ÷ 1日に回せるシナリオ数」に、修正と再テストの往復分を足す、という逆算で決めるのが確実である。担当者が兼務なら、1日に回せる数は専任の半分以下で見積もっておく。
テストケースは誰が作るか：発注側と開発会社の分担
「受入テストのテストケースを誰が作るのか」は、発注側からよく受ける質問である。結論は、何を確かめるか（業務シナリオと合否基準）は発注側、どう書き起こすか（手順とデータの準備）は開発会社が支援する、という分担が現実的である。
| 作業 | 発注側 | 開発会社 |
|---|---|---|
| 確かめる業務シナリオの洗い出し（月末締め、返品、権限ごとの操作など） | 主担当 | 抜け漏れの指摘 |
| 合否の基準（何ができれば合格か） | 主担当 | 要件定義書との対応づけ |
| テスト手順書への書き起こし | 確認 | 支援（工数として見積に入れる） |
| テストデータの準備（移行データ・マスタ） | 業務データの提供 | 環境への投入 |
| テストの実施 | 主担当 | 立ち会い・質問対応 |
| 不具合の記録と分類 | 主担当（業務影響の判断） | 原因の調査と分類案の提示 |
開発会社にテストケースの作成まで丸ごと任せると、テストは要件定義書・設計書どおりに動くかの確認になる。それはシステムテストでやるべきことで、受入テストで確かめたい「業務で使えるか」は確認されないまま検収に進む。
業務シナリオの洗い出しは、要件定義で作った業務フローがそのまま使える。要件定義の段階で、業務ごとに「何ができれば完了か」を決めておくと、受入テストの合否基準がほぼ自動的に決まる。この考え方は要件定義の進め方と完了ゲートに書いた。
受入テストをどこまでやるか：範囲の決め方
受入テストで全機能・全画面をもう一度テストする必要はない。それはシステムテストの範囲であり、発注側が同じことを繰り返しても、時間を使う割に見つかる不具合は少ない。
受入テストで重点的に確かめるのは、システムテストでは再現しにくいものである。
| 優先度 | 確かめる対象 | なぜ受入テストで見るのか |
|---|---|---|
| 高 | 締め処理・期末処理（月末・年度末・棚卸） | 実際の業務カレンダーとデータ量でしか確かめられない |
| 高 | 移行したデータでの表示・計算 | 旧システムの例外データが新システムの想定外になる |
| 高 | 権限ごとの操作（担当者・承認者・管理者） | 組織の実際の権限設計は発注側しか知らない |
| 高 | 帳票・外部へ出す書類 | 取引先に出す書式の誤りは業務上の影響が大きい |
| 中 | 例外的な業務（返品、取消、訂正、差し戻し） | 頻度は低いが、止まると手作業で回せない |
| 中 | 性能（実データ量での応答時間・バッチの所要時間） | 非機能要件で合意した値を満たすか |
| 低 | 通常の登録・照会画面 | システムテストで確認済みのことが多い |
性能などの非機能要件は、要件定義の段階で目標値を決めていないと、受入テストで合否を判定できない。何を決めておくべきかは非機能要件とは｜発注側が決める3項目にまとめている。
また、設計書のどこを確認していれば受入テストの範囲を絞れるかは、基本設計と詳細設計の違いで触れた「基本設計で見る5点」と対応している。基本設計を承認した内容が、受入テストで確かめる業務の範囲になる。
受入テストで見つかった不具合の3分類
受入テストで出た指摘を、すべて「不具合」として一つのリストに入れると、検収が止まる。発注側にとっては全部が困りごとだが、契約上の扱いは3つに分かれる。
| 分類 | 状態 | 扱いの目安 |
|---|---|---|
| ① 契約不適合 | 要件定義書・設計書で合意したとおりに動かない | 開発会社が修正する（請負なら無償の追完が原則） |
| ② 仕様変更 | 合意したとおりに動いているが、業務に合わない | 追加の見積・スケジュール調整が必要になる |
| ③ 運用で回避 | 業務に影響はあるが、手順や設定で当面しのげる | 検収後の改修や次期開発に回す |
判断の分かれ目は、合意した文書に書いてあったかどうかである。①と②の境界で揉めることが多いが、ここで要件定義書と基本設計書の記述が根拠になる。書かれていない業務ルールは、発注側にとっては「当然」でも、契約上は②として扱われることがある。
実務では、指摘を出す時点で発注側が①〜③の分類案を付け、開発会社が原因調査の結果をもって分類を確定させる流れにすると、議論が早い。検収を止める必要があるのは①のうち業務に重大な影響があるものだけで、残りは検収後の対応として期限を決めて合意する、という整理も現実的である。
受入テストの段階で②が大量に出る場合、問題は受入テストではなく要件定義にある。開発が終盤まで進んでから業務に合わないことが分かった、という状況からの立て直し方はシステム開発の失敗と乗り換え判断で扱っている。
受入テストの計画や、検収条件の書き方で迷っている場合は、シンシアに相談することもできます。受託開発会社として、発注側の検査仕様書づくりから立ち会っています。
検収のあとに見つかった不具合はどうなるか
検収が完了しても、それで開発会社の責任がなくなるわけではない。合意した仕様と違う点（バグを含む）が検収後に見つかった場合、発注側は修正などを求めることができる。これを契約不適合責任という。
ただし、求められる期間には限りがある。
- 民法は、請負について、注文者が不適合を知った時から1年以内に請負人に通知しないと、修正の請求などができなくなると定めている（民法637条）
- IPAのモデル契約は、開発会社が責任を負う期間を「検収完了後○ヶ月／○年以内」と空欄にしており、当事者が個別に決める形になっている
つまり、責任を負う期間は契約書にどう書くかで変わる。発注側としては、契約前に次の2点を確認しておくとよい。
- 検収後、何ヶ月（何年）以内に見つかった不具合まで修正してもらえるか
- その期間が、締め処理・年度末処理など年に1回しか動かない処理を一度は通過する長さになっているか
年度末にしか動かない処理は、受入テストで擬似的に確かめても、本番で初めて分かる不具合が残りやすい。そうした処理がある場合は、受入テストで重点的に確かめるか、責任期間がその時期をカバーするように交渉する。
なお、契約条項の具体的な解釈や、個別の紛争の扱いは、契約の専門家に確認してほしい。この記事は、発注側が受入テストを計画するうえで確認すべき点の整理である。
受入テストの計画に入れる項目チェックリスト
発注前・契約時・テスト開始前の3段階で確認する項目をまとめた。発注前の準備全体はシステム開発の依頼で失敗しない注意点も合わせて確認してほしい。
発注前・見積時
- 受入テストの支援（テスト手順書の書き起こし、データ投入、立ち会い）が見積に入っているか
- UAT環境（検証環境）を誰が用意し、費用をどちらが持つか
- 受入テストに充てる発注側の担当者と時間を、社内で確保できるか
契約時
- どのテストの合格をもって検収とするか
- 検査期間の長さと、延長の手続き
- 期間内に異議を出さない場合の扱い（みなし合格の有無）
- 不合格時の通知方法と、修正・再検査の期限
- 検収後の契約不適合責任の期間
テスト開始前
- 業務シナリオと合否基準を、開発会社と書面で合意したか
- 移行データ・マスタがUAT環境に入っているか
- 指摘の記録フォーマットと、①〜③の分類ルールを決めたか
- 1日に回すシナリオ数と、修正の往復を含めたスケジュールを引いたか
よくある誤解
「受入テストは開発会社がやってくれる」 開発会社が行うのはシステムテストまでである。受入テストは発注側が主体で、少なくとも業務シナリオと合否基準は発注側が決める必要がある。
「テストが終わっていなければ検収は完了しない」 契約によっては、検査期間内に異議を出さないと合格とみなされる。テストの進み具合ではなく、期間と異議の手続きで決まる。
「受入テストで見つかったものは全部無償で直してもらえる」 無償で直るのは、合意した仕様どおりに動かないもの（契約不適合）が原則である。合意した仕様が業務に合わないものは、仕様変更として扱われる。
「受入テストでは全機能をもう一度確かめるべきだ」 全機能の確認はシステムテストの範囲である。受入テストは、締め処理・移行データ・権限・帳票など、実業務でしか確かめられないものに時間を使うほうが効果が高い。
FAQ：受入テスト（UAT）でよくある質問
Q. 受入テストと受け入れテスト、UATは同じものですか？ A. 同じものを指すことがほとんどである。表記の違いであり、英語の User Acceptance Test の略が UAT である。
Q. 受入テストとシステムテスト（総合テスト）の違いは何ですか？ A. システムテストは開発会社が要件・設計どおりに動くかを確かめるテスト、受入テストは発注側が業務で使えるかを確かめ、受け取るかどうかを決めるテストである。
Q. 受入テストのテストケースは誰が作るのですか？ A. 何を確かめるか（業務シナリオと合否基準）は発注側が決め、手順書への書き起こしやデータ準備は開発会社が支援する分担が現実的である。IPAのモデル契約でも、検査仕様書は発注側が開発会社と協議して作成する形になっている。
Q. 受入テストの期間はどのくらい取ればよいですか？ A. 決まった標準日数はない。テストする業務シナリオの数を1日に回せる数で割り、修正と再テストの往復分を足して逆算する。担当者が兼務なら余裕を大きめに取る。
Q. 受入テストでどこまでテストすればよいですか？ A. 締め処理・期末処理、移行データ、権限ごとの操作、帳票を優先する。通常の登録・照会画面はシステムテストで確認済みのことが多い。
Q. 検収のあとに不具合が見つかったら直してもらえますか？ A. 合意した仕様と違う点であれば、契約不適合責任として修正を求められる。ただし求められる期間は契約で決まるため、契約時に期間を確認しておく。
Q. 準委任契約でも受入テストは必要ですか？ A. 必要である。ただし請負と違い、受入テストの不合格がそのまま報酬の支払いを止めるとは限らない。完了の定義と、修正作業の費用負担を契約で決めておく。
まとめ
- 受入テストは、発注側が受け取るかどうかを決める手続きであり、多くの契約で検収・支払いに直結する
- 請負では受入テストの合格が検収になるのが一般的。準委任では意味が変わるため、契約形態を先に確認する
- 検査期間内に異議を出さないと合格とみなされる契約がある。期間と担当者を先に確保する
- テストケースは、業務シナリオと合否基準を発注側が決め、書き起こしとデータ準備を開発会社が支援する
- 範囲は、締め処理・移行データ・権限・帳票など実業務でしか確かめられないものに絞る
- 指摘は契約不適合・仕様変更・運用回避の3つに分けて扱う。検収を止めるのは重大な契約不適合だけでよい
- 検収後の責任期間は契約で決まる。年に1回しか動かない処理を一度は通過する長さか確認する
参考文献・出典
- 独立行政法人 情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」 https://www.ipa.go.jp/digital/model/model20201222.html
- 独立行政法人 情報処理推進機構（IPA）「情報システム・モデル取引・契約書」 https://www.ipa.go.jp/digital/model/index.html
- e-Gov法令検索「民法（明治二十九年法律第八十九号）」第632条・第637条 https://laws.e-gov.go.jp/law/129AC0000000089
