受入テストは誰がやる？発注者と開発会社の役割分担、検収条件と見積もりの確認点

「受入テストの担当者を決めてください」と言われたら

外注した業務システムの納品が近づき、開発会社から「受入テストの日程と担当者を決めてください」「テストケースをご用意ください」と連絡が来ることがあります。テストは開発会社がするものだと思っていると、ここで初めて自社の作業だと知ることになります。

先に結論を書きます。受入テスト (受け入れテスト・UAT) は発注者が主体で行い、開発会社はそれを支援します。受入テストの結果で合否を確定させる契約上の手続きが検収です。検収の条件は契約書で決まり、見積書でその前提となる工程が分かります。

本記事では、受入テストで自社が担う範囲と開発会社に任せられる範囲を分け、検収の流れと契約書・見積書で確かめる項目までを扱います。根拠には、IPA (情報処理推進機構) と経済産業省が公開している 情報システム・モデル取引・契約書 第二版 (以下、モデル契約) と民法を使います。見積もり全体の読み方は システム開発の見積もり完全ガイド にまとめています。

受入テストは発注者が主体で行い、開発会社は支援する

「受入テストは誰がやるのか」への答えは、発注者です。テストの基準となるテストケースを作るのも、原則は発注者になります。

モデル契約は、請負で開発したソフトウェアの検収について、発注者が開発会社と協議したうえで、テスト項目・テストデータ・テスト方法・テスト期間などを定めた検査仕様書を作ると定めています (第 27 条)。解説には「検収はユーザが中心となって実施するものであることから、検査仕様書作成は原則としてユーザが行う」とあります。

一方で、同じ条文の第 3 項は、検査仕様書の作成支援を開発会社に委託できるとし、その場合は別の個別契約を結ぶ形にしています。解説も、検査仕様書を作るには開発を担った会社の関与が欠かせない場合が多いと認めています。自社で一から作る必要はありませんが、支援を頼むなら見積もりの別の項目になりうる、ということです。

開発会社がテストしたのに、なぜ自社でも確かめるのか

開発会社も納品前にテストをします。ただし、確かめているのは「仕様書どおりに動くか」です。受入テストで発注者が確かめるのは「自社の業務が新しいシステムで回るか」で、目的が違います。

特に抜けやすいのが、システムの外側にある業務です。今後も使い続ける会計システムへの連携データ、紙や表計算ソフトで続ける手作業、月末だけ発生する締めの処理などは、開発会社の担当範囲に入っていないことがあります。業務の流れ全体を知っているのは発注者なので、そこを通しで確かめられるのも発注者だけです。

FIXIT

えっ、テストって開発会社がやってくれるんじゃないの？

Shiori

開発会社もテストします。確かめているのは、仕様書どおりに動くかどうかです。

FIXIT

じゃあ、こっちは何を確かめるの？

Shiori

自社の業務が新しいシステムで回るかどうかです。そこは発注者にしか判断できません。

受入テスト・システムテスト・運用テスト・ユーザーテストの違い

似た名前のテストが並ぶので、誰が何を確かめるのかで比べます。

システムテストまでは開発会社の品質の確認で、受入テストからは発注者が納品物を受け取るかどうかの判断に移ります。この境目が、次章で扱う検収の入口です。

「運用テスト」「ユーザーテスト」は会社によって意味が違う

運用テストとユーザーテストは、使う会社によって指すものが変わります。運用テストを受入テストと同じ意味で使う会社もあれば、本番移行の前に運用の手順を確かめる工程を指す会社もあります。ユーザーテストも、画面の使いやすさの評価を指す場合と、受入テストを指す場合があります。

モデル契約の総論は、工程を次のように定義しています。「導入・受入支援」は、疑似環境または実環境にソフトウェアを導入し、発注者の受入れレビューとテストを支援する工程です。「運用テスト」は、疑似運用環境などで運用テストを実施し、実運用環境に移行する工程です。第 30 条は、これらを発注者が行い、開発会社が善管注意義務で支援する業務 (準委任) として定めています。

手元の契約書や見積書に「運用テスト」「受入支援」とあれば、どの作業を誰がするのかを開発会社に確かめてください。名前が同じでも中身が違えば、発注者の負担も費用も変わります。

受入テストと検収の関係

受入テストは、発注者が納品物を確かめる作業です。検収は、その結果をもとに合否を確定させる契約上の手続きです。モデル契約の第 26〜28 条では、次の流れになっています。

flowchart TD
  A["納入<br/>(検収依頼書を添えて)"] --> B["検査仕様書に基づいて<br/>発注者が検査"]
  B --> C{"検査の結果"}
  C -->|合格| D["検査合格書を交付"]
  C -->|不合格| E["不合格の具体的な理由を<br/>書面で交付"]
  E --> F["理由が認められれば<br/>開発会社が期限内に無償で修正して再納入"]
  F --> B
  D --> G["検収完了"]
  B -.->|検査期間内に<br/>書面の異議が無い| G

開発会社は、納入物を検収依頼書 (兼納品書) とともに納入します (第 26 条)。発注者は定めた検査期間内に検査仕様書に基づいて検査し、合格なら検査合格書を渡します。不合格なら、不合格となった具体的な理由を書いた書面を速やかに渡します。不合格の理由が認められれば、開発会社は協議のうえで決めた期限内に無償で修正して納入し直します (第 28 条 2 項)。

点線の矢印が、いわゆるみなし検収です。検査期間内に書面で具体的な理由を示して異議を述べないと、検査に合格したものとみなされます (第 28 条 3 項)。解説は、発注者の都合で検収が引き延ばされるのを防ぐための定めだと説明しています。

検収書に押印すると確定すること

検収書への押印は、受け取りの確認だけでは終わりません。契約によっては、押印が次の 2 つの起点になります。

1. 支払いの時期。民法は、請負の報酬は仕事の目的物の引渡しと同時に払うと定めています (民法 633 条)。実際の支払日は契約の支払条件で決まり、「検収完了月の翌月末払い」のように検収を起点にする契約もあります
2. 不具合を開発会社に直してもらえる期間の起点。モデル契約は、契約不適合責任の期間を「検収完了後〇ヶ月／○年以内」とし、起算点を検収完了時にしています (第 29 条 5 項)

FIXIT

ハンコを押すだけなら、届いたその日に返してもいいよね？

Shiori

整理すると、押印が支払いと、不具合を直してもらえる期間の起点になることがあります。

FIXIT

それって、押す前に確かめないと損するってこと？

Shiori

はい。押す前に、支払条件と、不具合を通知できる期限を契約書で確かめてください。

納品物が動かないまま押印を求められている場合の対処は、システム開発の失敗から立て直す で扱っています。

発注者と開発会社の役割分担

受入テストの作業を分けると、発注者が担うもの、開発会社が担うもの、支援を相談できるものに分かれます。

表の最後の行だけは、発注者から手放せません。支援を頼む作業が増えるほど自社の負担は減りますが、その分は見積もりの項目として現れます。

社内に人手を説明するときの見積もり方

利用部門の担当者は通常業務と兼務していれば、テストに割ける人と時間は限られます。必要な人手は、次の式で見当をつけると社内で説明しやすくなります。

1 回目のテスト日数 = テストケース数 × 1 ケースの所要時間 ÷ (担当者数 × 1 日にテストへ割ける時間)
必要な日数 = 1 回目のテスト日数 + 修正を待つ期間 + 再テストの日数

担当者が兼務なら「1 日にテストへ割ける時間」は短く見積もります。人員と時間の割り当ては、現場ではなく事業責任者やプロジェクトの責任者が判断します。計算した日数を示して、先に枠を確保してもらってください。

発注者が確かめる範囲と優先順位

全部の画面を均等に触る必要はありません。新しい業務の流れを順にたどってテストケースを作り、止まると困るものから優先度を付けます。

1. 毎日使う業務 (受注の登録、日次の集計など)
2. お金・在庫・顧客情報が動く処理 (請求額の計算、在庫の引き当て)
3. 外部のシステムとの連携 (会計システムへの出力、取り込むデータ)
4. 権限ごとの見え方 (担当者と管理者で見える範囲が正しいか)
5. 帳票や CSV の出力 (取引先に渡す書式、社内で加工する列)
6. 移行したデータ (旧システムの件数や金額と一致するか)
7. 返品・取消・締め後の修正などの例外業務

例外業務は、ふだんの業務フロー図に描かれていないことがあり、抜けやすい部分です。月に数回しか起きない処理でも、止まると手作業で埋めることになるので、担当者に聞き取って入れておきます。

性能やセキュリティのように、発注者が操作して確かめにくいものは、開発会社のテスト結果の報告を受け取る項目にします。報告の形式と受け取る時期を、計画書に書いておくと抜けません。

受入テスト計画書に書く項目

受入テスト計画書は、何を・誰が・いつまでに・どの基準で確かめるかを 1 枚にまとめたものです。書く項目は次のとおりです。

合否の基準と不具合の扱いは、契約書の検収条件と食い違わないように揃えます。計画書で「軽微な不具合は稼働後に対応」と決めても、契約書に同じ定めが無ければ、開発会社との約束にはなりません。

検収条件を契約書で確かめる

受入テストをいくら丁寧に進めても、検収の条件が契約書で決まっていなければ、合否をめぐって開発会社と揉める原因になります。署名の前、遅くとも受入テストを始める前に、次の条項を確かめます。

検収期間の日数に一律の目安はありません。前章の式で出した日数に、修正と再テストの分を足して交渉します。みなし検収の条項がある契約で期間が短すぎると、確かめきれていない部分まで合格扱いになります。

完成してから一括で受ける検収は、問題の発覚が遅くなります。週次で受け入れていく進め方は AI 駆動開発で失敗しない進め方 で扱っています。

検収後に不具合が見つかったとき

検収後の不具合は、まず 3 つに分けます。

期間の考え方は、民法と契約で異なります。民法では、発注者が不適合を知った時から 1 年以内に通知しないと、修正や損害賠償などを請求できなくなります (民法 637 条 1 項)。モデル契約はこの起算点を検収完了時に置き換え、期間の長さはシステムの特性に応じて当事者が決める形にしています (第 29 条 5 項)。同じ項には、検収完了後の期間に、発注者が不適合を知った時から数えた期間を重ねる選択肢も用意されています。自社の契約で起算点と期間がどう書かれているかによって、通知の期限が変わります。

通知は、不具合の内容と発生した状況 (画面など) が分かる程度に具体的に書くことが求められる、とモデル契約の解説は述べています。受入テストの記録と同じ様式で残しておくと、そのまま通知に使えます。

モデル契約の解説には、契約不適合責任の期間を短くし、その後は保守契約で対応するほうが発注者にとって経済的な局面もある、という指摘もあります。期間が切れたあとの費用は 開発後の保守・運用・追加開発の見積 を、仕様変更の費用の考え方は見積もり完全ガイドの 仕様変更と追加見積 を参照してください。

準委任契約の場合

準委任は、仕事の完成を約束しない契約です。そのため請負のように、完成品を検査して合否を確定させる手続きは法律上の前提になっていません。ただし、成果に対して報酬を払う約束で、成果の引渡しが必要な場合は、引渡しと同時に報酬を払うのが原則です (民法 648 条の 2)。契約形態の選び方は AI 開発の契約は準委任と請負どちらが正解か で扱っています。

見積書で受入テストと検収の項目を確かめる

受入テストの負担と検収の条件は、発注の前なら見積書の段階で見えてきます。見積書と前提条件の欄で、次の項目を確かめてください。

項目が入っていないこと自体は、問題ではありません。入っていなければ自社で担う前提で人手を確保するか、支援を追加で見積もってもらうかを決めます。モデル契約では、検査仕様書の作成支援を頼む場合、開発の個別契約を結ぶときまでに申し込み、支援の個別契約を別に結ぶ形になっています (第 27 条 3 項)。後から頼むと日程にも費用にも響くので、発注前に決めておきます。

テスト工数が薄すぎる見積書の見分け方は、見積もり完全ガイドの 工数が過大 / 過少になっているサイン にまとめています。契約書と見積書を突き合わせる条項は、同じ記事の 契約書で見積もりと突き合わせる条項 を参照してください。

手元の見積書にテスト工程や受入の支援、検収の期間が入っているか判断がつかない場合は、FIXIT の 見積もりのセカンドオピニオン で、工程の抜けや漏れを無料で診断します。まだ見積書が無い段階なら、費用シミュレーター で工程ごとの内訳の概算を先に出せます。

FIXIT の運用 — 見積書のテスト工程と検収の条件を、発注前に読む

FIXIT は AI 駆動開発のクリエイティブスタジオとして、他社から受け取った見積書の診断をお引き受けしています。診断では、テストの工数がどの項目に入っているか、検収にかかる期間がスケジュールに含まれているかといった工程の抜けや漏れを、追加費用の条件とあわせて読みます。

お返しするのは、観点ごとの指摘と、見積書を出した会社にそのまま聞ける質問のリストです。受入テストの支援が別の見積もりになっているのか、そもそも含まれていないのかは、見積書の書き方だけでは分からない場合があるため、質問の形にして確かめられるようにしています。社名や案件名は伏せたままで構わず、診断だけのご利用でも問題ありません。

契約書の解釈そのものは弁護士の領域なので、私たちは法的な判断を代わりに行いません。担当するのは、見積書と工程の中身の整理です。

まとめ

受入テストは発注者が主体で行い、開発会社は支援します。確かめるのは自社の業務が回るかどうかで、テストケースは業務の流れから作り、止まると困るものから優先します。その結果で合否を確定させるのが検収で、押印が支払いと、不具合を直してもらえる期間の起点になることがあります。

発注の前なら、次の一歩は 1 つです。手元の見積書と契約書のドラフトを並べ、受入テストの支援・テスト環境・検収期間・契約不適合責任の期間がどこに書かれているかを確かめてください。書かれていない項目が、自社で担う作業か、追加で見積もってもらう作業になります。

受入テストを工程から外すと、稼働後に何が起きやすいかは システム導入が失敗する 12 の兆候 で、受入テスト期間を含めた納期の考え方は Web システムの費用と納期の実数値 で扱っています。見積書の読み方から相談したい場合は、お問い合わせ からご連絡ください。