開発会社から「来月からUATをお願いします」と言われて、何をどこまでやればいいのか分からず調べている方は多いと思います。UATを検索するとテスト会社やエンジニア向けの解説が並びますが、そこで説明されているのは主に用語の定義と、テストの種類の違いです。
ただ、発注側が本当に知りたいのはそこではありません。誰を何人出すのか、何日かかるのか、出てきた不具合をどこまで直してもらえるのか。UATはシステム開発の工程のなかで、発注側が唯一「実施する側」に回る工程です。ここで手を抜くと、動くけれど業務では使えないシステムを受け取ることになります。この記事では、システム開発のUATを発注側の実務としてどう進めるかを整理します。
この記事のポイント
- UATは開発会社ではなく発注側が主体で実施する最後のテスト
- シナリオは要件定義書ではなく実際に流れている伝票から作る
- 出た不具合は実装バグ・要件漏れ・追加要望の3つに切り分ける
- UATの日数は開発の遅れに関係なく先に確保しておく
目次
システム開発のUATとは何を確かめる工程か
まずは言葉の整理からです。UATがどのテストと何が違うのか、そして誰が責任を持つ工程なのかが分かると、自社が何をすべきかも決めやすくなります。
UATは開発会社ではなく発注側が実施する
UATはUser Acceptance Testの略で、日本語では受け入れテスト、ユーザー受け入れテストと呼ばれます。完成したシステムを、実際に使う人が自分たちの業務のやり方で動かしてみて、これで業務を回せるかどうかを判断するテストです。
ほかのテストとの一番の違いは、実施する主体が開発会社ではなく発注側だという点です。単体テストも結合テストも、開発会社が自分たちの作ったものを自分たちで検証します。UATだけは、頼んだ側が「これで受け取れます」と言うために自分で手を動かします。開発会社は環境の準備やデータの用意、不具合の修正で支援に回りますが、合否を出すのは発注側です。
ここで多いのが、UATも開発会社がやってくれるものだと思っていた、という行き違いです。契約書や見積書に「受け入れテスト支援」と書かれている場合、支援はしますが実施はしません、という意味であることがほとんどです。見積もりの段階で、UATの実施主体と開発会社の支援範囲がどう書かれているかは確認しておいてください。
なお、発注側がテストに人を出すことは、好意でやってあげる作業ではありません。IPAの情報システム・モデル取引・契約書（第二版）は、ユーザー企業とITベンダーが各開発段階で担うべき責務を解説したもので、見直しの論点にもプロジェクトマネジメント義務と協力義務が挙げられています。発注側が必要な人と情報を出すことは、契約上の役割として整理されている、という前提で計画を立てるのが安全です。
システムテストとの違いは確かめる観点にある
UATとよく混同されるのがシステムテスト（総合テスト）です。どちらも完成間近に、システム全体を通して行うテストなので、外から見ると同じことを二度やっているように見えます。違うのは、何を基準に合否を判断するかです。
システムテストは「仕様書どおりに動くか」を確認します。UATは「その仕様で業務が回るか」を確認します。仕様どおりに動いていても、実際の業務では入力項目が足りない、承認の順番が現場と逆になっている、といったことは起こります。それを見つけられるのは、仕様書を書いた人ではなく、毎日その業務をやっている人だけです。
| テスト | 実施する主体 | 確かめること |
|---|---|---|
| 単体テスト（UT） | 開発会社 | ひとつの機能が設計どおりに動くか |
| 結合テスト（IT） | 開発会社 | 機能どうしをつないでも正しく動くか |
| システムテスト（ST） | 開発会社 | システム全体が仕様書どおりに動くか |
| 受け入れテスト（UAT） | 発注側 | その仕様で自社の業務が回るか |
この並びは、上流の設計工程と下流のテスト工程が対になっているという考え方（V字モデル）で整理されています。UATと対になるのは要件定義です。つまりUATで確かめるのは、要件定義で決めたことが実現しているかどうかであり、技術的な作りの良し悪しではありません。工程全体の並びや略語の意味はシステム開発の工程と流れで整理しています。
UATの結果で検収の合否が決まる
UATと検収も、混ざりやすい言葉です。順番でいうと、UATが先で検収が後です。UATは実際に動かして確かめる作業そのもので、検収はその結果を受けて「納品物を受け取ります」と発注側が意思表示する手続きになります。支払いに直結するのは検収のほうです。
この2つを分けて考えないと、困ったことが起きます。UATで不具合が出たまま検収の期限が来てしまい、直っていないのに検収書に押印してしまう、という流れです。検収してしまうと、その後に見つかった不具合の扱いは契約不適合責任の話になり、期間や範囲の制約がつきます。
ですので、UATはいつからいつまで、検収の判定はその何日後、という並びを先に決めておいてください。検収の基準や期間の決め方、支払期日との関係はシステム開発の検収とは？基準と期間の決め方で詳しく整理しています。
発注側が主役になるシステム開発UATの進め方
ここからが実務です。UATで発注側が決めることは、突き詰めると4つしかありません。何を試すか、誰が試すか、出た不具合をどう扱うか、そして何日かけるかです。順番に見ていきます。
シナリオは実際に流れている伝票から作る
UATのシナリオを作るとき、要件定義書の機能一覧を上から順にチェックリストにしてしまう例をよく見ます。これは効率が悪いうえに、見つかるべき問題が見つかりません。機能単位で動作を確認するのは、開発会社がシステムテストで済ませている作業だからです。
発注側が作るべきなのは、業務の流れをひと続きでなぞるシナリオです。私がおすすめしているのは、先月に実際に流れた伝票や申請を何件か持ってきて、それをそのまま新しいシステムに入れてみるやり方です。受注から出荷、請求までを1件通す。申請から承認、差し戻しまでを1件通す。こうすると、機能単位では見えなかった「つなぎ目」の問題が出てきます。
そして、うまくいく想定のデータだけを流さないことが大事です。現場でよく見るのは、きれいなデータばかりでテストして、本番初日に例外で止まるパターンです。シナリオには次のようなものを必ず混ぜてください。
- 途中で取り消された注文、金額がマイナスになる返品
- 承認者が不在で代理承認になるケース
- 月末月初など、件数が集中する時間帯の処理
- 権限の違うユーザー（一般社員・管理者・経理）での同じ操作
- 他システムとの連携が止まっているときの動き
シナリオの本数は、主要な業務ごとに10〜30本ほどが目安です。そのうち3割くらいは例外系にしておくと、本番で慌てる場面が減ります。なお、シナリオを作っている途中で「そもそもこの業務、要件に入っていたかな」と気づくことがあります。それはUATではなく要件の抜けなので、この段階で見つかったら早めに開発会社と扱いを相談してください。
現場担当者は誰から何人出すか
UATの成否は、正直なところ誰にテストしてもらうかでほぼ決まります。情シスの担当者だけでやると、システムとしては動くという確認しかできません。実際にその業務を毎日やっている人が触らないと、業務が回るかどうかは判断できないからです。
集めるのは、各業務につき1〜2名。役職者ではなく、実務を一番よく知っている人を出してもらってください。ベテランだけでなく、入社2〜3年目の人を1人入れておくと、画面の分かりにくさや手順の複雑さが見えてきます。慣れた人ほど、使いにくさを自分の工夫で吸収してしまうためです。
ここで多いのが、業務部門に「空いた時間でお願い」と頼んでしまい、結局誰も触らないまま期限が来るという失敗です。UATは通常業務の合間にできる作業ではありません。参加する人は、期間中は通常業務の2〜4割の時間をUATに使う前提で、部門長に事前に話を通しておいてください。人を出すこと自体を、社内のプロジェクト工数として最初から見積もっておくのが確実です。発注後に自社側でどう体制を作るかは発注後の進行管理と外注管理の進め方でも整理しています。
不具合は3種類に切り分けて差し戻す
UATを始めると、必ず「これ、違うんですけど」という指摘が出てきます。ここで全部をまとめて開発会社に投げると、揉めます。無償で直るものと、追加費用になるものが混ざっているからです。出てきた指摘は、次の3つに切り分けてください。
- 実装バグ（決めたとおりに作られていない）
- 要件定義書や設計書に書かれているのに、そのとおりに動いていないものです。これは開発会社の責任範囲なので、無償で修正されます。指摘するときは、要件定義書の該当箇所を添えると話が早く進みます。
- 要件漏れ（決めそこねていた）
- 業務では必要なのに、要件定義のときに誰も口にしていなかったものです。責任がどちらにあるとは言い切れないことが多く、実務では影響の大きさで判断します。業務が止まるなら今回対応、運用でしのげるなら次回、という整理をその場で決めてください。
- 追加要望（あとから欲しくなった）
- 使ってみたらもっとこうしたい、という改善案です。UATの場では出て当然のものですが、今回の範囲ではありません。要望リストとして別に残し、本番後の改修としてまとめて相談するほうが、結果的に安く済みます。
切り分けたうえで、差し戻す基準も先に決めておきます。私の感覚では、業務が止まる不具合が1件でも残っていれば検収しない、業務は回るが手間が増えるものは期日を約束してもらったうえで検収する、という2段階にしておくと判断が揺れません。重要度の区分と、それぞれ何日以内に直すのかは、UATの開始前に開発会社と合意して書面に残しておいてください。差し戻すかどうかの線引きは、検収・受入テスト確認シートにレッドフラグと判定表としてまとめてあります。
UATに確保する日数の目安
最後は日数です。UATの期間は、実施そのものよりも、不具合が出てから直って再確認するまでの折り返しをどれだけ見込むかで決まります。テストを1周して終わり、という計画にしていると、まず間に合いません。
| 規模 | UATの実施期間 | 合計で見ておく期間 |
|---|---|---|
| 小規模（機能数が少ない・部門内で完結） | 3〜5営業日 | 2週間程度 |
| 中規模（基幹業務の一部・複数部門） | 2〜3週間 | 1〜1.5か月 |
| 大規模（基幹システム全体・他システム連携あり） | 1か月以上 | 2〜3か月 |
合計の期間には、不具合の修正と再テストの折り返しを2回分見込んでいます。あくまで一般的な目安なので、実際の日数は自社の業務量と体制をもとに、個別の計画で確認してください。
そして、これがいちばん申し上げたいことなのですが、開発が遅れたときにUATの期間を削らないでください。実際にはとてもよく起きます。総合テストが延びた分、リリース日は動かせないので受け入れテストを1週間から3日に縮めましょう、という相談が開発会社から来ます。ですが、削られているのは発注側が唯一自分の目で確かめられる時間です。リリース日を動かすか、稼働範囲を絞るか、どちらかで調整するべき場面だと私は考えています。
UATの日程は、開発計画を承認する段階で「この期間は動かさない」と伝えて押さえておくのが確実です。繁忙期に重なっていないかも、その時点で確認しておいてください。月末月初や決算期に当たっていると、現場の人が出てこられません。
- Q. UATの正式名称は何ですか？
- User Acceptance Testの略で、日本語では受け入れテスト、またはユーザー受け入れテストと呼びます。会社によっては受入テスト、承認テスト、検収テストといった呼び方をすることもありますが、指しているものはほぼ同じです。
- Q. UATと単体テスト（UT）は何が違いますか？
- 単体テストは開発会社がひとつの機能ごとに設計どおり動くかを確認する作業で、開発の序盤から行われます。UATは全部つながった状態のシステムを発注側が業務の流れで動かす、最後のテストです。目的も実施する人も別のものと考えてください。
- Q. UATの環境は誰が用意しますか？
- 環境そのものは開発会社が用意するのが一般的ですが、テストに使うデータは発注側が出すことが多いです。実データを使う場合は、個人情報や取引先の情報をどう扱うかを先に決めておいてください。マスキングの要否は契約や社内規程によって変わります。
- Q. アジャイル開発でもUATはありますか？
- あります。ただし最後に1回まとめて行うのではなく、区切りごとに発注側が動くものを確認する形になります。関与の回数は増えますが、1回あたりの負担は軽くなります。どの段階で誰が確認するかは、開始前に決めておく必要があります。
