受入テストは、開発会社が作った機能をもう一度なぞる工程ではありません。発注者が実際の利用者と、受注、承認、請求、月末締め、例外対応を最後まで通し、自社の仕事を任せられるか判断する工程です。開発会社は準備と修正を支援しますが、合否を決めるのは発注者です。
月末最終営業日の17時、経理担当が請求対象を確定しようとしたら、承認待ちの案件だけ一覧から消えている。個別の登録テストは全部通っていても、締め作業は終わりません。受入テストで確かめるのは、ボタンが動くことではなく、担当者が席に座ってその日の仕事を終えられることです。
受入テストの五つの判断。画像を押すと拡大できます
受入テストは、誰が責任を持って進めるのか？
発注者の責任者が合否を決め、業務担当と運用担当が試し、開発会社は準備と修正を支援します。
情報システム専任者がいない会社でも、役割は分けられます。経営者または事業責任者が受入責任者を置き、業務を知る人、権限を管理する人、稼働後に問い合わせを受ける人を参加させます。
| 役割 | 受入テストで行うこと | 行わないこと |
|---|---|---|
| 受入責任者 | 範囲、合否、延期、条件付き受入を決める | 件数だけ見て自動承認する |
| 業務担当者 | 通常、月末、例外のシナリオを操作する | 開発会社の説明を聞くだけで終える |
| 管理者 | 権限、マスタ、承認経路を確認する | 管理者権限だけで全操作を試す |
| 運用担当者 | 障害連絡、復旧、バックアップ、問合せを試す | 稼働後に初めて手順を読む |
| 開発会社 | 環境、データ、操作支援、証拠、修正を担う | 発注者に代わって最終合否を決める |
デジタル庁の標準ガイドライン実践ガイドブックは、設計・開発を事業者へ任せきらず、発注者自身が要件を伝え、関係者を調整し、テスト計画と結果を判断する立場を示しています。小さな会社では役職を兼ねても、合否を決める人と修正する人を同じにしないことが要点です。
開発会社のテストと、受入テストは何が違うのか？
開発会社は仕様どおり動くかを確認し、受入側はその動作で自社の業務が成立するか判断します。
開発会社の単体・結合・総合テストが終わってから、受入テストへ進みます。受入テストで開発途中の基本不具合を探し続ける状態なら、前工程の完了条件を見直します。
| 比較 | 開発会社のテスト | 発注者の受入テスト |
|---|---|---|
| 主な問い | 設計・仕様どおり動くか | 自社の業務と運用が成立するか |
| 主体 | 開発会社 | 発注者 |
| データ | 技術的な境界値、組合せ | 本番に近い匿名化した業務データ |
| シナリオ | 機能・連携単位 | 受注から請求、月末、例外まで |
| 結果 | 不具合と修正結果 | 受入、条件付き受入、延期 |
| 証拠 | テスト結果、ログ | 業務結果、照合表、承認記録 |
IPAの情報システム・モデル取引・契約書（第二版）は、契約時に仕様、プロジェクト管理方法、検収方法を受発注者が共通理解のもとで話すことを期待しています。納品直前に初めて「何ができれば検収か」を決めるのでは遅いため、見積・契約段階で受入条件を置きます。
受入テストでは、どの業務を確認するのか？
日常、締め、例外、権限、外部連携、移行、障害復旧を業務の開始から終了まで確認します。
画面ごとに「登録できる」「検索できる」と並べず、一つの仕事をつなげます。販売管理なら、顧客登録、見積、受注、在庫確認、出荷、売上、請求、入金消込までのうち、今回の範囲を一続きにします。
最低限、次の七つを用意します。
- 普段最も多い通常業務
- 月末・年末・締め日の処理
- 差し戻し、取消、訂正、再申請
- 権限がない人、退職者、代理承認者
- 会計、在庫、メールなど外部連携の停止
- 移行データと新規データが混ざる期間
- 障害時の連絡、手作業、復旧、再開
経済産業省のシステム管理基準は、ユーザ受入テスト計画の観点として、業務フロー、本番移行とフォールバック、バックアップ、現行システムとの処理結果比較を挙げ、ユーザと運用担当者の参加を求めています。通常画面だけではなく、戻す場面まで受入対象です。
テストケースは、どの粒度で書けばよいか？
操作手順ではなく、前提、入力、期待する業務結果、証拠、合否を一つのシナリオに書きます。
「案件登録ボタンを押す」だけでは、仕事の結果を確かめられません。次の形で一行を作ります。
| 項目 | 記載例 |
|---|---|
| 前提 | 承認者が休み、代理承認者が設定済み |
| 入力 | 値引き8％の見積、取引先A、希望納期 |
| 操作 | 営業が申請し、代理者が承認、経理が確認 |
| 期待結果 | 正しい代理者へ届き、未承認では請求へ進まない |
| 証拠 | 申請画面、承認ログ、請求対象外の一覧 |
| 合否 | 期待結果をすべて満たせば合格 |
数値や固有名詞は、自社の実際のルールへ置き換えます。値引き率を使わない会社なら、発注額、与信、個人情報の閲覧権限など、自社で承認が必要な境界を選びます。
月末や承認者不在は、どう試せばよいか？
日付、役割、未処理データを本番に近づけ、締め前後と代理承認の一連の結果を比較します。
月末テストでは、当月分、翌月分、未承認、取消、過去月訂正を混ぜます。経理担当者が普段使う一覧や帳票を出し、件数と金額を現行結果または手計算と照合します。
承認者不在では、単に代理者がログインできるかを見ません。申請が正しい代理者へ届く、期限超過時に保留または上位者へ回る、元の承認者が復帰しても二重承認にならない、まで確認します。
確認中に口頭で補う必要が出たら、その手順も成果です。ただし、誰がいつ補うか決めず「運用でカバー」とだけ書くのは不合格です。画面修正、手順追加、対象外のどれにするかを決めます。
性能や障害対応は、業務担当者も確認するのか？
技術計測は開発会社が行い、業務担当者は待てる時間と障害中に仕事を続けられるか確認します。
一覧表示が何秒なら許容できるか、同時利用人数は何人か、停止中に紙や表計算へ戻れるかは、業務側の判断です。開発会社は測定方法、ログ、負荷条件を示し、発注者は事前に決めた要求と照らします。
IPAの非機能要求グレードは、可用性、性能・拡張性、運用・保守性、移行性、セキュリティなどを、ユーザと開発者が段階的に確認するための資料です。すべてを最高水準にせず、停止時の損失と費用を比べて必要な水準を選びます。
たとえば、昼の受注ピークに一覧が30秒止まると電話を切らなければならないなら、担当者が「遅い」と言うだけでなく、何人がどの操作をしたとき、何秒以内なら業務を続けられるかを書きます。その条件を開発会社の負荷テストと受入シナリオで分担します。
不具合が残ったときは、誰が受入可否を決めるのか？
受入責任者が業務影響、回避策、修正期限を見て、受入、条件付き受入、延期を決めます。
不具合件数だけでは決めません。誤請求、権限外閲覧、データ欠損、二重登録、復旧不能は、件数が一件でも業務影響が大きい場合があります。表示のずれなど業務を止めない問題は、修正日と暫定手順を合意して条件付き受入にできることもあります。
| 判定 | 条件 | 残すもの |
|---|---|---|
| 受入 | 合否基準を満たし、重大な未解決がない | 結果、証拠、承認 |
| 条件付き受入 | 業務継続でき、回避策と修正日がある | 対象、期限、責任者、再確認 |
| 延期 | 業務停止、誤処理、権限・データ問題が残る | 再計画、再テスト範囲 |
| 対象外 | 契約範囲外と双方で確認した要望 | 追加要望の記録、見積 |
修正後は、そのケースだけでなく影響する周辺を再テストします。請求金額の丸めを直したなら、一件の表示だけでなく、明細合計、請求書、会計連携、月次集計まで戻って確かめます。
社内では、テスト開始前に何を決めるべきか？
責任者、参加者、シナリオ、合否、証拠、日程、再テスト、延期条件を開始前に決めます。
受入責任者は、システムに詳しい人ではなく、業務影響を引き受けて稼働可否を決められる人にします。小さな会社で経営者が兼ねる場合も、実操作は経理、営業、管理の担当者へ割り当てます。
テスト日程には修正と再テストの時間を含めます。納品日前日の午後に全シナリオを詰め込むと、問題が見つかっても日程を守るため受け入れるしかありません。
開発会社へは、どの情報と成果物を求めるのか？
業務例、権限、締め日、連携先を渡し、環境、データ、結果、証拠、修正一覧を求めます。
発注者からは、実際の帳票、匿名化データ、通常と例外の手順、誰が何を承認するかを渡します。完成したテスト仕様書でなくても、月末に使うExcelと確認メールを見せればシナリオを作れます。
開発会社には、受入環境、初期データ、操作説明、既知の制約、開発会社側のテスト結果、受入中の問い合わせ窓口を求めます。受入後に残る不具合は、一覧、重大度、回避策、修正予定、再テスト結果まで同じ表で管理します。
関連記事と相談先は、どこから確認できるか？
要件、見積、開発方式の記事を往復し、受入条件を発注前の資料へ入れてから相談できます。
Heygoodは、納品前に画面を見せて終わりにしません。実際の担当者と月末・例外・障害のシナリオを作り、開発会社のテスト結果と受入結果を分けます。発注前なら合否条件の整理から、開発中なら受入計画の立て直しから相談できます。