受け入れテスト（UAT）とは？検収前に確認したい5つのポイントと進め方
システム開発を外部に発注した際、本番稼働前の重要な確認工程となるのが受け入れテストです。受け入れテストは、開発会社ではなく発注した側が主体となって実施するテストになります。
しかし実際の現場では、「開発会社がテストを済ませているのだから、こちらは動作を軽く確認すれば十分ではないか」と考えてしまうケースが少なくありません。
受け入れテストで確認すべきことを取りこぼしたまま検収してしまうと、稼働後に見つかった不具合の修正が追加費用の対象になったり、現場から使いにくいという声が上がって定着しなかったりといった事態を招きます。
受け入れテストは、成果物を検収してよいか、本番稼働に進んでよいかを判断する重要な工程でもあります。
この記事では、受け入れテストの基本的な位置づけと確認すべきテストの種類を整理したうえで、発注側が見落としやすい5つの観点と、具体的な進め方を解説します。
初めてシステム開発を発注する担当者の方でも、自社の体制に不足がないかを判断できる内容にまとめています。
お困りなことはありませんか？
「システム開発って複雑そう…」
「システムを導入したいけど、どうすれば？」
そんな不安をお持ちの方、ご安心ください。
私たちが解消します。
豊富な経験を活かして、
あなたに最適な道筋を示します。
まずはお気軽にご相談ください！
受け入れテスト（UAT）とは？発注側が担う最後の確認工程
受け入れテストは、発注側が業務で問題なく使えるかを確認する最終工程
受け入れテストとは、完成したシステムが業務で問題なく使えるかどうかを、実際の運用環境またはそれに近い環境で確認するテストです。
開発会社が実施する各種テストとは異なり、発注した企業やその利用者が主体となって実施する点が最大の特徴になります。
英語のUser Acceptance Testを略してUATと呼ばれることもあり、日本語では検収テストや承認テストという名称が使われる場合もあります。
呼び方は複数ありますが、いずれも「納品されたシステムを受け入れてよいかを判断する」という目的は共通しています。
確認する視点が開発側のテストとは異なる
開発会社が実施するテストは、基本的に「設計書どおりに作られているか」を確認するものです。
一方の受け入れテストは、「設計書どおりに作られたシステムが、本当に自社の業務で使えるか」を確認します。
たとえば受注登録の画面が仕様どおりに動作していても、実際の受注業務では入力項目の並び順が作業手順と合わず、毎回画面を行き来しなければならないといったことが起こります。
これは設計書上は不具合ではありませんが、業務上は明らかに問題です。
こうした業務視点のずれは、実際の業務を知っている発注側でなければ発見できません。だからこそ受け入れテストは、開発会社に任せきりにできない工程となります。
単体テスト・結合テスト・システムテストとの違い
システム開発におけるテストは、確認する範囲によって段階的に分かれています。それぞれの違いを整理すると、以下のとおりです。
| テストの種類 | 確認する範囲 | 主な実施主体 |
| 単体テスト | プログラムや画面を最小単位で動作確認する | 開発会社 |
| 結合テスト | 複数の機能や画面をつないだときの連携を確認する | 開発会社 |
| システムテスト | インフラを含めたシステム全体が要件どおり動くかを確認する | 開発会社 |
| 受け入れテスト | 実際の業務で支障なく使えるかを確認する | 発注側（利用者） |
一般的な受託開発では、単体テスト・結合テスト・システムテストは開発会社側が中心となって実施し、受け入れテストは発注側が主体となって実施します。
単体テストから順に確認する範囲が広がっていき、システムテストの段階でシステム全体としての完成度が確認される流れです。
そして最後に、発注側が業務の観点で確認するのが受け入れテストという位置づけになります。
注意したいのは、システムテストと受け入れテストで似た項目を確認する場合があるという点です。
システムテストは開発者の視点でシステムとしての不備を探すのに対し、受け入れテストは利用者の視点で業務への適合性を判断します。
確認する項目が重なっていても目的が異なるため、システムテストが完了しているから受け入れテストは省略してよい、という判断は成り立ちません。
【初心者でも安心】システム開発の手順を徹底解説！プロが教える成功する7つの工程
V字モデルにおける受け入れテストの位置づけ
システム開発の工程とテストの対応関係を示した図に、V字モデルがあります。
左側に要求分析から詳細設計までの工程を並べ、右側に対応するテスト工程を並べたもので、同じ高さにある工程どうしが対応する仕組みです。
V字モデルにおいて、受け入れテストは最上段の「要求分析」と対応しています。
要求分析とは、システムを導入することで業務がどう変わり、どこが効率化されるのかを整理する工程です。
つまり受け入れテストは、当初期待していた業務改善が実際に実現できたかを判断するテストということになります。
単に画面が動くかどうかを見るテストではない、という点をここで押さえておく必要があります。
お困りなことはありませんか？
「システム開発って複雑そう…」
「システムを導入したいけど、どうすれば？」
そんな不安をお持ちの方、ご安心ください。
私たちが解消します。
豊富な経験を活かして、
あなたに最適な道筋を示します。
まずはお気軽にご相談ください！
受け入れテスト（UAT）で確認する6つのテストタイプ
UATでは目的に応じて6つのテストタイプを確認する
受け入れテストでは、確認したい目的に応じてテストを分類して実施します。代表的なテストタイプは、次の6種類です。
| テストタイプ | 確認する内容 |
| 機能適合性テスト | 業務に必要な機能が漏れなく備わり、業務効率化に役立つか |
| 性能効率性テスト | 想定される利用者数やデータ量で問題なく動作するか |
| 互換性テスト | 他システムとの連携や、利用端末との組み合わせに問題がないか |
| ユーザビリティテスト | 利用者が迷わず操作でき、入力ミスを防げる作りになっているか |
| 信頼性テスト | 停止時間内に保守作業が終わるか、障害時に速やかに復旧できるか |
| セキュリティテスト | 情報漏えい対策や権限設定が運用面まで含めて機能しているか |
これら6つすべてを受け入れテストで一から実施する必要はありません。
性能効率性テストやセキュリティテストは、開発会社がシステムテストの段階である程度確認しています。
ただし、システムテストで使われた環境と実際の運用環境が違う場合は、改めて確認が必要になります。
限られた期間のなかで効果を出すためには、開発会社に任せられる部分と自社で見るべき部分を切り分ける判断が欠かせません。
以下では、そのなかでも発注側が特に力を入れるべき2つを取り上げます。
機能適合性テスト
機能適合性テストは、要件定義で依頼した機能が実際に業務で機能するかを確認するテストです。
機能が存在するかどうかだけでなく、その機能を使うことで本当に業務が効率化されているかまで踏み込んで判断します。
たとえば集計機能が実装されていても、実務で必要な単位での集計ができなければ、結局手作業での加工が残ってしまいます。
要件定義の段階では気づかなかった不足が表面化しやすいのが、このテストです。
ユーザビリティテスト
ユーザビリティテストでは、実際に業務を担当する社員が操作したときに、迷わず使えるかを確認します。
開発者と現場の社員では、システムに対する慣れの度合いが大きく異なります。
エラーメッセージが表示されたときに、現場の担当者がその意味を理解して自力で対処できるかどうかは、稼働後の問い合わせ件数に直結する重要な観点です。
操作手順が複雑すぎないか、必要な画面へたどり着くまでの手数が多すぎないかといった点も、あわせて確認しておきましょう。
受け入れテスト（UAT）を軽視すると起こる2つの問題
UATを軽視すると、検収後の追加費用や現場での定着不良につながる
受け入れテストを形式的な確認で済ませてしまった場合、稼働後にさまざまな問題が発生します。
代表的なものは、次の2つです。
- 検収後の修正が追加費用の対象になりやすい
- 現場で使われないシステムになる
いずれも、発注側の負担が金銭面と業務面の両方で増えるという共通点があります。
しかも、これらの問題は稼働してしばらく経ってから表面化するため、その時点では対処の選択肢がかなり狭まっています。
さらに、テスト結果を記録に残していない場合は、稼働後に見つかった不具合をめぐって開発会社との間で見解が食い違い、責任の所在があいまいになることもあります。
それぞれの内容を詳しく見ていきます。
検収後の修正は追加費用の対象になりやすい
受け入れテストで問題がないと判断して検収書に署名すると、その時点で納品物を受け入れたことになります。
検収が完了した後に見つかった不具合や機能不足の修正は、原則として追加の作業として扱われます。
契約内容によっては契約不適合責任の範囲で無償対応となる場合もありますが、その期間は限られていることが一般的です。
さらに、「業務に合わない」という指摘は不具合ではなく仕様変更として扱われるため、無償対応の対象外となる可能性が高くなります。
検収前に見つければ開発費用の範囲で直せた問題が、検収後には別途見積もりの対象になってしまいます。
現場で使われないシステムになる
受け入れテストを情報システム部門の担当者だけで実施すると、現場の実務との細かなずれを発見できません。
その結果、稼働後に現場から使いにくいという声が上がり、従来のExcelや紙の運用が並行して残ってしまうことがあります。
システムと従来の運用が二重に存在する状態は、導入前より業務が非効率になっている状態です。
システム導入にかけた費用が回収できないだけでなく、現場の負担も増えるという最も避けたい結果を招きます。
お困りなことはありませんか？
「システム開発って複雑そう…」
「システムを導入したいけど、どうすれば？」
そんな不安をお持ちの方、ご安心ください。
私たちが解消します。
豊富な経験を活かして、
あなたに最適な道筋を示します。
まずはお気軽にご相談ください！
受け入れテスト（UAT）で発注側が見落とすと後で困る5つの観点
UATでは5つの観点を事前に確認しておくことが重要
ここからが本題です。受け入れテストで実際につまずきやすいのは、テストの手法そのものではなく、その前提となる準備や取り決めの部分になります。
以下の5つの観点について、自社の状況を確認してみてください。
一つでも当てはまるものがあれば、受け入れテストの体制を見直す余地があります。
1. テスト計画を開発の終盤ではなく初期に立てているか
受け入れテストの計画を、システムが完成しそうな時期になってから考え始める企業は少なくありません。
しかし、受け入れテストの全体計画はプロジェクトの初期段階で立てておくことが望ましいとされています。
理由は2つあります。
1つは、テスト期間と要員をあらかじめ確保しておかなければ、通常業務と並行してテストを実施できないためです。
もう1つは、何を確認するかを早い段階で開発会社と共有しておくことで、開発側のテスト計画もその内容に沿ったものになるためです。
受け入れテストの内容を先に伝えておくと、開発会社がその観点を意識して設計や実装を進められます。
結果として、受け入れテストで見つかる問題そのものが減ることになります。
2. 現場の担当者がテスト参加者に含まれているか
受け入れテストの目的は、業務で使えるかどうかの確認です。
したがって、実際にそのシステムを日々操作する現場の担当者が参加していなければ意味がありません。
情報システム部門やプロジェクト担当者だけでテストを実施すると、システムの動作は確認できても、業務の流れとの整合性までは判断しきれません。
とはいえ、現場の担当者は通常業務を抱えているため、いきなり協力を依頼しても時間を確保できないのが実情です。
だからこそ、テスト参加者の人選と工数の確保はプロジェクトの初期に済ませておく必要があります。
また、運用担当者やシステム管理者にも参加してもらい、日次のバックアップや権限設定といった運用面の作業も確認しておきましょう。
3. 合格の基準と完了条件を事前に合意しているか
受け入れテストで最も曖昧になりやすいのが、どうなったら合格とするのかという基準です。
軽微な表示崩れが1件残っている状態で検収してよいのか、それとも全件修正されるまで検収しないのか。この判断基準を事前に決めていないと、検収の可否をめぐって開発会社との交渉が長引きます。
そのため、不具合を重要度で区分し、どの区分までが検収の条件となるかをテスト開始前に取り決めておきましょう。
たとえば業務が止まる不具合は検収前に必ず修正、表示上の軽微な問題は稼働後の改修で対応、といった形です。
この取り決めは口頭ではなく、テスト計画書などの文書として残しておくことが重要になります。
4. 不具合と仕様変更の切り分けルールを決めているか
受け入れテストを進めると、「思っていたものと違う」という指摘が必ず出てきます。
このとき、それが開発会社の責任で直すべき不具合なのか、発注側が追加費用を負担すべき仕様変更なのかで意見が分かれます。
判断の基準となるのは、要件定義書や設計書にどう記載されていたかです。
記載された内容と異なる動作をしていれば不具合、記載どおりに動いているが業務に合わないという場合は仕様変更にあたります。
ただし、実務ではどちらとも解釈できる曖昧なケースが多く発生します。
そこで、指摘事項が出た際にどのような手順で判断するのか、判断は誰が行うのかをあらかじめ決めておく必要があります。
切り分けのルールがないまま指摘を積み上げると、対応の優先順位がつかず、テスト期間を消化してしまいます。
5. 本番に近いデータと環境で確認できているか
開発中のテストで使われるのは、多くの場合、開発会社が用意した少量のダミーデータです。
実際の業務データは、量も内容もダミーデータとは大きく異なります。
顧客名に旧字体が含まれていた、想定より桁数の多い数値が入力された、過去データの件数が多く一覧表示に時間がかかったといった問題は、実データでなければ発見できません。
また、外部システムとの連携についても、開発中はダミーの接続先を使っていることが一般的です。必要に応じて、本番移行前に実際の接続先との疎通確認も行いましょう。
利用する端末やネットワーク環境についても、実際の業務環境で確認することが欠かせません。
社内ネットワークからは問題なく動いたのに、外出先の回線からは表示が極端に遅いといったケースもあります。
お困りなことはありませんか？
「システム開発って複雑そう…」
「システムを導入したいけど、どうすれば？」
そんな不安をお持ちの方、ご安心ください。
私たちが解消します。
豊富な経験を活かして、
あなたに最適な道筋を示します。
まずはお気軽にご相談ください！
受け入れテスト（UAT）の進め方5ステップ
UATは計画から検収判定まで5つのステップで進める
ここからは、受け入れテストを実際に進める手順を5つのステップで解説します。
- テスト計画を作成する
- テストシナリオとテストケースを用意する
- テスト環境とデータを準備する
- テストを実施して結果を記録する
- 不具合対応と検収判定を行う
この流れは、開発規模の大小にかかわらず基本的に共通します。
小規模な開発であっても手順を省略せず、各ステップで何を決めるべきかを押さえておくことで、後戻りを防げます。
それぞれのステップを詳しく見ていきましょう。
1. テスト計画を作成する
まず、受け入れテストの目的、対象範囲、期間、参加者、合格基準を整理した計画を作成します。
ここで決めた内容が、以降のすべての作業の前提となります。
対象範囲は、売上や請求に直結する機能、停止すると業務が止まる機能から優先的に確認していきます。
計画は開発会社にも共有し、テスト期間中の問い合わせ窓口や不具合の報告方法についても合意しておきましょう。
2. テストシナリオとテストケースを用意する
次に、実際にどのような操作を行うかを具体化します。
受け入れテストでは、機能単位ではなく業務の流れに沿ったシナリオを作ることが基本です。
たとえば「見積作成から受注登録、出荷指示、請求書発行まで」といった一連の業務を、実際の手順どおりに操作していきます。
このとき、途中でキャンセルが発生した場合や入力を間違えて修正する場合といった、例外的な流れも用意しておきましょう。
業務でよく起こるイレギュラーへの対応こそ、稼働後に問題となりやすい部分です。
3. テスト環境とデータを準備する
テストを実施する環境と、使用するデータを準備します。
可能な限り本番環境と同じ構成の環境を用意し、実際の業務データを移行して使用するのが理想です。
可能な限り本番環境に近い構成を用意し、データ量や形式、値のばらつきについても本番に近い条件を再現します。個人情報や機密情報を含む実データを使用する場合は、マスキングや匿名化など必要な安全管理措置を講じましょう。
4. テストを実施して結果を記録する
準備が整ったら、計画に沿ってテストを実施します。
実施にあたっては、確認した内容と結果を必ず記録に残してください。
問題が見つかった場合は、どの画面でどのような操作をしたときに何が起きたのかを、入力内容とあわせて記録します。
再現手順が明確でないと開発会社側で問題を確認できず、対応が滞る原因になります。
問題がなかった項目についても、確認済みであることを記録しておきましょう。
5. 不具合対応と検収判定を行う
報告した問題について、開発会社が修正を行い、修正後に再度確認します。このとき、修正箇所だけでなく、その修正が他の機能に影響していないかもあわせて確認します。
すべての確認が終わったら、事前に決めた合格基準に照らして検収の可否を判断しましょう。
基準を満たしていない項目が残っている場合は、対応方針と期限を文書で確認したうえで判断してください。
システム保守費用の内訳公開｜相場はどのくらい？削減のコツも
受け入れテスト（UAT）の負担を抑えるための工夫
UATは確認範囲を絞り、開発会社の支援を活用して負担を抑える
受け入れテストの重要性は理解していても、通常業務を抱えたなかで十分な時間を割くのは簡単ではありません。
社内のリソースが限られている場合には、次のような方法を検討する余地があります。
- 確認範囲に優先順位をつけて絞り込む
- 開発会社にテストの支援を依頼する
どちらを選ぶかは、開発の規模と社内で確保できる工数によって変わります。
すべてを自社で抱え込もうとして中途半端なテストになるより、範囲を絞って確実に確認するほうが結果的にリスクを抑えられます。
Excel管理から脱却！業務システム開発の費用・期間・進め方を解説
確認範囲に優先順位をつけて絞り込む
限られた期間で成果を出すには、確認する範囲を業務の重要度で絞り込む判断が必要です。
売上や請求など、誤りが直接的な損失につながる業務から優先的に確認していきます。
使用頻度が低い機能や、誤りがあっても後から修正できる機能については、優先度を下げる判断も現実的です。
ただし、優先度を下げた項目については稼働後に確認する時期を決めておき、そのまま放置しないようにしましょう。
開発会社にテストの支援を依頼する
受け入れテストの計画づくりやテストケースの作成を、開発会社に支援してもらう方法もあります。
テストの実施そのものは発注側が行うとしても、準備の部分を支援してもらうだけで負担は大きく変わります。
見積もりの段階で受け入れテストの支援が含まれているかを確認し、含まれていなければ追加を相談してみましょう。
支援の姿勢は開発会社によって差が出る部分でもあるため、会社選びの判断材料としても役立ちます。
お困りなことはありませんか？
「システム開発って複雑そう…」
「システムを導入したいけど、どうすれば？」
そんな不安をお持ちの方、ご安心ください。
私たちが解消します。
豊富な経験を活かして、
あなたに最適な道筋を示します。
まずはお気軽にご相談ください！
まとめ
受け入れテストは、納品されたシステムが業務で使えるかどうかを発注側が判断する最後の工程です。
開発会社が実施する単体テストや結合テストとは目的が異なり、業務を知っている発注側でなければ確認できない観点を扱います。
この記事で紹介した5つの観点は、いずれも準備段階で決めておくべき内容ばかりです。
テスト計画を初期に立てること、現場の担当者を参加させること、合格基準を事前に合意すること、不具合と仕様変更の切り分けルールを決めること、本番に近いデータと環境で確認すること。
これらが整っていれば、受け入れテストは形式的な確認ではなく、稼働後のトラブルを防ぐ実効性のある工程になります。
検収前に見つかった問題は開発費用の範囲で対応できますが、検収後に見つかった問題は追加費用の対象になります。
限られた期間のなかでも、業務上重要な部分から確実に確認を進めていきましょう。
受け入れテスト（UAT）まで見据えたシステム開発なら株式会社アレグビット
システム開発において、受け入れテストは発注側が担う工程です。
しかし実際には、テスト計画の立て方やテストケースの作り方がわからない、社内に十分なリソースがないといった声を多くいただきます。
特に「初めてシステム開発を発注するので何を確認すればよいかわからない」「前回の開発で検収後にトラブルになった」といったお悩みは少なくありません。
株式会社アレグビットでは、開発の初期段階から受け入れテストを見据えた進め方をご提案しています。
システム開発や既存システムの改善についてご興味がある方は、弊社にて無料でご相談いただけます。
- 他社が開発したシステムの改善や機能追加も対応可能
- 小さなPoCや自動化ツールの導入からでもOK
- 技術選定やAIツール導入のご相談のみでも大歓迎です
現在お使いのシステムに課題を感じている場合も、どこから手をつけるべきかという段階からご相談いただけます。
要件定義の進め方やテストの体制づくりを含めて、発注側の立場に立ったご提案をいたします。
まずはお気軽にお問い合わせください。