このユニットの結論
利用部門が確認するテスト（受入テスト）は、開発の担当が行ったテストを、利用部門がもう一度なぞるものではありません。
実際の業務の流れと、業務で使うデータで、「この仕組みで、自分たちの業務を回せるか」を、業務に責任を持つ人が確かめるテストです。
1. 何の話か
このユニットは、受入テスト（利用者受入テスト）の話です。
テストの段階（10-02）のうち、最後に行うことが多いのが受入テストです。それまでのテストは、主に「決めたとおりに作られているか」を開発の側が確かめます。受入テストは、使う側が「業務として使えるか」を確かめます。
2. なぜ必要か
受入テストをしない、または形だけで済ませると、
- 機能は要件どおりなのに、業務の流れの中では使いにくい・足りないことに、稼働してから気づく
- 利用部門が、稼働の前に新しい仕組みに慣れる機会がない
- 業務の責任者が納得しないまま稼働し、稼働後の問い合わせや不満が増える
- 「作った側が大丈夫と言った」ことだけが、稼働の根拠になる
ということが起きます。
3. このユニットで分かること
- 受入テストで確かめること
- 受入テストを準備するときに決めること
- 受入テストの結果の扱い
- 受入テストで、AIに任せてよいことと人間が決めること
4. 受入テストで確かめること
- 業務の流れ：1つの業務を、始めから終わりまで、新しい仕組みで通せるか（REQ-001 業務フロー図 の流れに沿って）
- 業務のデータ：実際に近いデータで、結果が業務の感覚と合うか
- 例外の場面：取り消し、やり直し、承認の差し戻しなど、よく起きる例外を扱えるか
- 周辺の作業：新しい仕組みの前後で行う手作業・帳票・他の部署とのやりとりがつながるか
- 使い方：手順書や説明を見て、担当者が操作できるか
5. 準備するときに決めること
| 決めること | 内容 |
|---|---|
| 確かめる業務の場面 | どの業務の、どの場面を通すか（業務の担当が選ぶ） |
| 参加する人 | 実際にその業務をしている人。業務の責任者が結果を判断する |
| データ | 実際に近いデータ。個人の情報などは伏せて使う |
| 合否の考え方 | 何ができれば「業務で使える」とするか |
| 見つかったことの扱い | 不具合・要望・使い方の問題を分けて記録する方法 |
| 期間と支援 | 参加する人の業務の時間をどう確保するか。質問に答える担当 |
参加する人は、普段の業務と並行して受入テストを行うことが多いため、時間の確保が大きな課題になります。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- 業務の担当として、P-005 藤本 遥（経理業務リーダー）、P-006 川村 美咲（プロジェクト管理業務リーダー）、P-007 松本 健太（営業・契約業務リーダー）がいる
- P-010 宮田 直人 — テスト・品質管理リーダー
- 成果物に TST-006 利用者受入テスト・終了判定報告書、REQ-001 業務フロー図がある
- M18 本番稼働
アステリア案件の受入テストの範囲・時期・参加者・結果は、正本に記載がありません。未確定 上の業務の担当が受入テストを判断するという記載もありません。未確定
6. THINK — 「開発の担当が代わりにやっておきます」
（教材上の例）受入テストの時期が、利用部門の繁忙期と重なりました。開発の担当者が次のように提案しました。
「利用部門の皆さんは忙しいので、受入テストの手順を私たちが代わりに実行して、結果を報告します。」
問題
この提案を受け入れてよいでしょうか。
判断例を開く
判断
そのまま受け入れるべきではありません。
確認すること:
- 開発の担当が実行して、「業務の感覚で結果が合っているか」を判断できるか
- 利用部門の担当が、稼働の前に新しい仕組みに触れる機会がなくなってよいか
- 受入テストの時期をずらす、確かめる場面を絞る、など、利用部門が参加できる方法はないか
- 最終的に「業務で使える」と判断する人が、自分で確かめたと言えるか
開発の担当が準備や支援をすることは役に立ちます。しかし、業務として使えるかの判断は、業務に責任を持つ人が行います。
7. よくある失敗
- 開発の段階のテストと同じ内容を、利用部門にもう一度させる
- 画面ごとの確認だけで、業務の流れを通して確かめない
- 見つかったことを、不具合・要望・使い方の問題に分けずに扱い、要望が大量の不具合のように見える
- 参加する人の時間を確保せず、受入テストが形だけになる
8. 成果物との接続
- TST-006 利用者受入テスト・終了判定報告書：受入テストの結果と、終了の判断を残す
- TST-002 テスト計画・対象一覧：受入テストで確かめる場面を、計画に入れる
- REQ-001 業務フロー図：確かめる業務の流れの出どころ
テストを終えてよいかの判断は 10-06 テストをいつ終了してよいのか で学びます。
9. AI WORKFLOW — 確かめる場面の洗い出しを手伝わせる
AIは、業務の流れから、受入テストで確かめる場面の候補を挙げる下書きに役立ちます。
指示例:
「次の業務フローから、受入テストで確かめるべき場面の候補を、①通常の流れ、②よく起きる例外（取り消し・差し戻しなど）、③他の部署とのやりとり、に分けて挙げてください。どの場面を選ぶかは決めないでください。」
10. REVIEW — AIの洗い出しを確認する
- 候補が、実際の業務の流れに合っているか（業務の担当が確かめたか）
- 業務で本当によく起きる例外が、抜けていないか
- AIが合否の考え方を決めていないか
11. 人間が判断すること
- どの業務の場面を確かめるか
- 業務で使えると判断してよいか（受入の判断）
- 見つかったことを、稼働の前に直すか、稼働後に回すか
12. 判断演習
あなたは、利用部門で受入テストを取りまとめる担当です。
新しい仕組みで「案件の登録から報告まで」を確かめる場面を1つ選び、その場面で確かめることを3つ挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
受入テストは、業務の流れと業務のデータで、使う側が「業務を回せるか」を確かめるテストです。
業務に責任を持つ人が、自分で確かめて判断します。