利用者受入テスト・終了判定報告書

これは何か

利用者受入テスト・終了判定報告書は、利用部門が業務の流れで新しい仕組みを確かめた結果と、「テストを終えてよいか」の判断とその根拠を、1つにまとめて残す成果物です。

受入テスト（10-03）の結果を「やりました」で終わらせず、どの場面を通せたか、何が残ったか、残ったものをどう扱うと決めたかを、後から読んでも分かる形にします。

なぜ作るか

• 業務に責任を持つ人が、自分たちで確かめたことを記録に残す
• 事前に決めた終了基準（10-06）に照らして、満たしたもの・満たさないものを並べる
• 残った問題を「受け入れて進む」と決めた場合に、誰が、どんな条件で受け入れたかを残す
• 本番稼働の判断（12-05）に、テストの側の材料として渡す

誰が使うか・いつ作るか

• まとめる人：テストの取りまとめ役と、受入テストを取りまとめる業務の担当
• 判断する人：業務の責任者（業務で使えるか）と、テストの終了を判断すると決められた人
• 使う人：本番稼働の判断の材料をそろえる人
• 一般的には、受入テストの期間中に結果を書き足し、終了の判断の直前に仕上げます。判断のあとは、判断の内容と条件を追記して確定します
• 誰が何を判断するかの分担は、プロジェクトによって異なります

アステリア案件の受入テストの範囲・時期・参加者・結果、終了基準と終了の判断は、正本に記載がありません。未確定 上の業務の担当が受入を判断する役割を持つという記載もありません。未確定

主な項目

一般的には、2つの部分で構成します。

受入テストの結果の部分

• 確かめた業務の場面と、関係する業務の流れ（REQ-001 業務フロー図）
• 参加した人（役割）と、使ったデータの種類
• 場面ごとの結果（通せた・条件付きで通せた・通せない）
• 見つかったことを「不具合・要望・使い方の問題」に分けた数と、主なもの
• 計画していたのに確かめられなかった場面と、その理由

終了判定の部分

• 終了基準の項目ごとの状況（満たす・満たさない）と、根拠にした資料
• 残った問題と、回避策・直す予定・受け入れた人
• 判断の結果（終了・条件付き終了・継続）、判断した人、判断した日
• 条件付きの場合の条件と、それを誰がいつ確かめるか

読み方

1. 場面が「業務の流れ」で選ばれているか。画面ごとの確認の寄せ集めになっていないか
2. 「通せない」「未実施」の場面が、終了判定の部分に反映されているか
3. 見つかったことが、不具合・要望・使い方の問題に分けられているか（要望が不具合に見えていないか）
4. 終了基準の項目ごとに、根拠にした資料が書かれているか

書き方

1. 受入テストの前に、確かめる場面と終了基準を決め、報告書の枠を作っておく
2. 場面ごとに、実施した日・参加した人・結果・見つかったことを書き足す
3. 見つかったことは、障害管理表（TST-003）の番号とつなぐ
4. 終了の判断の前に、基準の項目ごとに状況と根拠をまとめる
5. 判断のあとに、結果・判断した人・条件を追記する（あとで変えるなら版を分ける）

何を書いてはいけないか

• 判断する人が決める前に、報告書の中で「終了してよい」と書いてしまうこと
• 根拠にした資料のない「問題なし」
• 実施しなかった場面を、書かずに済ませること

ほかの成果物との違い

• TST-002 テスト計画・対象一覧：何を・いつ・誰が確かめるかの予定。この報告書は、その結果と判断
• TST-003 障害管理表：不具合を1件ずつ追いかける表。この報告書は、そこから終了の判断に必要なものを引いてまとめる
• TST-004 品質状況ダッシュボード：期間中の傾向を同じ見方で追う。この報告書は、ある時点の判断を記録する
• CUT-005 本番稼働判定資料：テスト・移行・切替・運用・業務の材料を集める資料。この報告書は、そのうちのテストの材料の1つ

よくある失敗

• 結果の数字だけを並べ、どの業務の場面を確かめたのかが分からない
• 要望を不具合と同じ扱いで数え、受入が進まないように見える

関係するUnit・成果物・危機演習

• Unit：10-03 利用部門が確認するテスト、10-06 テストをいつ終了してよいのか、12-05 誰が本番稼働を決めるのか
• 成果物：TST-002、TST-003、TST-004、CUT-005、REQ-001 業務フロー図
• 危機演習：この成果物を直接の題材にする危機演習はありません

いつ使うか

この教材では STAGE 10｜本当に動くことを証明する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。