SAPのユーザー受入テスト：誰が責任を持ち、どう進めるか

SAPのユーザー受入テスト（UAT）は、業務ユーザーが設定済みのシステムで自分たちのプロセスを実行し、本稼働前に正式に受け入れるフェーズです。責任者は業務部門で、IT部門と導入パートナーがそれを支援します。S/4HANAプログラムでは、私はUATに最低でも6〜8週間を計画します。

私が最もよく目にするテストの失敗は単純です。UATと結合テスト（SIT）でのテスト不足です。スケジュールが遅れるとこの2つのフェーズが圧縮され、そのすき間が本稼働後に表面化します。

以下では、誰が何をするのか、準備、スクリプト、不具合のトリアージ、そして意味のある承認について解説します。UATが他のテストの種類の中でどこに位置するかについては、まず私の概要記事SAPテストとはをお読みください。

ユーザー受入テストの責任者は業務部門です。これが私の立場であり、スケジュールが厳しくなっても動かすべきではありません。

理由はその名前にあります。受け入れとは、システムで業務を回せるかどうかについての業務上の判断であり、それを下せるのは業務を回している人だけです。IT部門やパートナーがUATを承認したなら、誰も何も受け入れていません。

SAP自身の方法論も同じことを言っています。S/4HANA Cloud Private Edition向けのテスト戦略のガイダンスでは、UATをRealizeフェーズに置いています。パートナーの設定の専門家が手動のテストケースを準備し、顧客の業務部門の専門家がそれを実行して結果を文書化します。

現実的な作業分担は次のようになります。

役割	UATで責任を持つこと	責任を持たないこと
業務のプロセスオーナー	シナリオの範囲、受入基準、自分のプロセスの最終承認	設定やコードの修正
キーユーザーとテスト担当者	スクリプトの実行、結果と証跡の記録、指摘事項の提起	不具合を「不具合ではない」と単独で判断すること
UATリード（業務側）	日々の計画、進捗、トリアージの議長、スポンサーへの準備状況の報告	技術的な修正
導入パートナー	スクリプトの起草、テストシステムの準備、不具合の修正、再テストの支援	受け入れ
社内のIT部門	環境、アクセス、他システムとのインターフェース、移送	受け入れ
データチーム	テストデータのロードと更新、照合の支援	業務シナリオの設計

UATリードはパートナーではなく業務部門から出すべきです。パートナー主導のUATは、構築したものが動くことの証明へと流れていきます。それは、業務部門がそのシステムで業務を回せるかどうかとは別の問いです。

UATには最低でも6〜8週間が必要です。それより短いと、業務部門は正常系を一度テストするだけで、修正を再テストする時間がなく、本当の問題が潜んでいる例外ケースにはたどり着けません。

この期間が機能するのは、UATが安定したシステムで始まる場合だけです。SAPのガイダンスでは、業務プロセスは連携が設定され、そのプロセスのためのデータが移行されてからテストすることになっています。つまり、合意した終了基準に照らして、まずSITを終えなければなりません。これらのサイクルのつながりは、私のS/4HANAテスト戦略のガイドで示しています。

最初のテスト担当者がログオンする前に、次のものがそろっているべきです。

1. 承認済みのプロセス設計。 スクリプトはそこから書かれます。設計が承認されていなければ、スクリプトも固まりません。
2. 開始基準を満たし、記録していること。 SITが完了し、未解決の重大な不具合がなく、管理された修正を除いてテストシステムが凍結されていること。
3. 本番環境と同じ姿のテストシステム。 設定、インターフェース、ロール、権限が本稼働時と同じ状態であること。
4. 現実的なテストデータ。 マスキングした本番レベルのデータを、テスト開始前にロードし照合しておきます。方法は私のSAPテストデータ管理のガイドで解説しています。
5. 通常業務から外れたテスト担当者。 名前を挙げ、上司と稼働時間を合意し、それを書面にします。
6. 新システムのトレーニングを受けたテスト担当者。 使用するFioriアプリとトランザクションの短いウォークスルーを、UATの最中ではなくUATの前に行います。
7. 1つのテスト管理ツール。 スクリプト、結果、証跡、不具合を、並行する複数のスプレッドシートではなく1か所で管理します。

UATが静かに失敗するのは、たいてい5番目の項目です。月次決算の合間にUATをこなすよう求められたテスト担当者は、月次決算を優先しますし、それは正しい判断です。

UATスクリプトは業務シナリオであって、トランザクションの一覧ではありません。「受注を登録する」は画面をテストします。「与信保留中の新規顧客から注文を受け、保留を解除し、出荷し、請求する」は業務をテストします。

スクリプトは承認済みのプロセス設計から作成し、それぞれに業務の言葉で明確な期待結果を示してください。テスト担当者がコンサルタントに尋ねなくても合格か不合格かを判断できるようにすべきです。

次の4種類のシナリオをカバーします。

1. コアのフロー。 受注から入金、購買から支払、記帳から報告のように、業務を動かし続ける日々のプロセス。
2. 例外。 返品、与信ブロック、分納、価格変更、取消、却下される承認。
3. 期末処理。 財務チームが実際に行う月末と年度末の手順を、実際に行う順序で。
4. ロールの確認。 各テスト担当者が本稼働時に持つロールで作業し、権限のギャップを今のうちに洗い出します。

スクリプトの起草はパートナーに任せ、その後キーユーザーに自分たちの言葉で書き直してもらってください。業務部門が助けなしにスクリプトをたどれないなら、それは構築チームのために書かれたものです。

SAP Cloud ALMでは、手動のテストケースはプロセスを起点に作成され、テスト計画がそれらをサイクルにまとめます。テスト担当者は各ステップを合格または不合格に設定し、実際の結果を記録し、テスト実行から不具合を起票します。これでスクリプトと不具合のつながりが保たれます。

テスト管理にまだSAP Solution Manager 7.2を使っているプログラムでは、そのメインストリームメンテナンスが2027年末に終了することに注意してください（SAP Support）。新しいプログラムはCloud ALMで計画してください。

UATの指摘事項がすべて不具合というわけではありません。すべてを不具合として扱えばパートナーは手一杯になり、すべてを変更要求として扱えば本当の障害が隠れます。

UAT期間中は毎日トリアージ会議を開いてください。業務側のUATリードが議長を務め、パートナーの機能リードとIT部門の代表が参加します。新しい指摘事項はすべて、種類、重大度、責任者が決まった状態で会議を出るようにします。

ほとんどの指摘事項は、シンプルな分類でカバーできます。

指摘の種類	意味	対応者	承認への影響
不具合	システムが承認済みの設計どおりに動かない	パートナーが修正し、テスト担当者が再テスト	重大と高の不具合は承認を妨げる
変更要求	設計は満たしているが、業務部門が今になって別のものを求めている	設計責任者がコストと時期を踏まえて判断	それなしではプロセスが回らないと業務部門が言わない限り妨げない
データの問題	マスタデータまたはトランザクションデータが誤っている、または欠けている	データチームが修正し、テスト担当者が再テスト	同じデータで本稼働するなら妨げる
トレーニングまたは操作の問題	システムは動くが、テスト担当者が使い方を知らなかった	トレーニングリードが教材を更新	妨げないが、トレーニング計画に反映する
権限の問題	ロールにアクセス権が足りない、または多すぎる	セキュリティチームがロールを調整	影響を受けるロールについて妨げる

重大度の定義は、UATが始まる前に業務の言葉で合意してください。重大な不具合とは、回避策がなくプロセスが止まるものです。高の不具合とは、回避策はあるものの、業務部門がその量をさばき続けることはできないものです。

変更要求の列に注意してください。UATで変更要求の長いリストが出るのは、たいてい業務部門が設計にきちんと関わっていなかったことを意味し、次のウェーブの前に直すべき問題です。

SAP Activateのトレーニングでは、ユーザー受入テストが完了して承認された時点でRealizeフェーズが完了するとしています。その承認は、メールのやり取りではなく文書にしてください。

業務の各プロセスオーナーが自分のプロセスについて署名します。承認には次のことを記録すべきです。

1. 何をテストしたか。 実行し、合格し、不合格となったシナリオと、テストツールに保管した証跡。
2. 何が未解決のままか。 未解決のすべての不具合と、その重大度、責任者、目標日。
3. 何を回避策つきで受け入れたか。 1件ずつ名前を挙げ、業務部門が運用することに合意した回避策を記載します。
4. 誰がいつ署名したか。 委員会ではなく、プロセスごとに名前のある1人。

終了基準はUATが始まる前に書き、結果が出てから変えないでください。それでも業務部門がギャップを抱えたまま本稼働したいと言うなら、それを署名された決定として記録します。このゲートがフェーズの移行にどう組み込まれるかは、私のSAP品質ゲートのガイドで解説しています。

UATの承認は本稼働の判断そのものではありません。その判断の材料になるものです。

私が譲らない本稼働の基準は、事前に合意した詳細なカットオーバーチェックリストです。UATの承認はその中の1行で、データの照合、トレーニング、カットオーバーリハーサルと並んでいます。

承認の後は、受け入れたものを守ってください。ここから本稼働までのすべての修正と移送には再テストが必要です。それを管理下に置く方法は、私のSAP回帰テストのガイドで説明しています。

長い文書は必要ありません。必要なのは、毎回同じ問いに答える1つの計画で、UATが始まる前に書かれ、業務部門が署名したものです。

シンプルな構成で十分です。

セクション	内容	責任者
範囲	対象範囲のプロセス、組織単位、ロールと、明示的に対象外とするもの	業務のプロセスオーナー
スケジュール	開始日と終了日、サイクル、再テストの期間、期末処理の実行	UATリード
チーム	プロセスごとのテスト担当者、通常業務からの解放、パートナーとIT部門のサポート窓口	UATリードと各部門の上司
開始基準	SITの終了基準を満たしている、テストシステムが凍結済み、データがロードされ照合済み、テスト担当者がトレーニング済み	UATリードとプログラムマネージャー
環境とデータ	テストシステム、対象範囲のインターフェース、マスキングした本番レベルのデータ、更新計画	IT部門とデータチーム
スクリプト	プロセスごとのシナリオ一覧、期待結果、プロセス設計へのリンク	パートナーが起草し、キーユーザーが承認
不具合のプロセス	指摘の種類、重大度の定義、毎日のトリアージ、再テストのルール	UATリードがトリアージの議長
報告	日々の進捗、重大度別の未解決の不具合、スポンサーへの阻害要因の報告	UATリード
終了基準	重大度別の未解決の不具合の上限、合格したシナリオ、合意した回避策	業務のプロセスオーナー
承認	プロセスオーナーごとの署名欄、受け入れた回避策の一覧	業務のプロセスオーナーとスポンサー

テンプレートはウェーブをまたいで同じものを使ってください。2回目のロールアウトでは、最初のウェーブのスクリプトと教訓を再利用し、ゼロからやり直さないようにします。

今月中に業務部門からUATリードを指名し、各プロセスオーナーに、時間を確保したテスト担当者を推薦してもらってください。そのうえで、SITの後にUATとして6〜8週間を計画に入れ、スケジュールが厳しくなってもそれを守ってください。

UATをパートナーが進めている、あるいは何度も圧縮されているなら、私はプログラムがこれをきちんと立ち上げる支援をしています。こちらからご連絡ください。

SAPのユーザー受入テストとは何ですか？

業務ユーザーが設定済みのSAPシステムを実際のプロセスに照らしてテストし、本稼働前に正式に受け入れるフェーズです。SAP Activateでは、結合テストの後、Realizeフェーズで行われます。キーユーザーがシナリオのスクリプトを実行して結果を記録し、指摘事項を提起し、プロセスオーナーが承認します。

SAPプロジェクトのUATは誰が責任を持ちますか？

業務部門です。プロセスオーナーが範囲を決めて承認し、キーユーザーがテストを実行します。導入パートナーはスクリプトを起草して不具合を修正し、社内のIT部門は環境、アクセス、インターフェースを提供します。IT部門もパートナーも、業務部門に代わってシステムを受け入れるべきではありません。

SAPのUATにはどれくらいの期間をかけるべきですか？

S/4HANAプログラムでは最低でも6〜8週間を計画してください。それだけあれば、コアのフロー、例外、期末処理の手順を実行し、修正を再テストする時間が残ります。それより短いUATは、たいてい正常系を一度テストするだけで、残りは本稼働後に見つかることになります。

SAPのSITとUATの違いは何ですか？

結合テスト（SIT）は、プロセスとインターフェースがモジュールやシステムをまたいで連動することを確認するもので、主にプロジェクトチームが実行します。UATは、業務部門がそのシステムで自分たちのプロセスを回せることを確認するもので、業務ユーザーが実行します。SITはUATが始まる前に終えるべきです。

UATの承認には何を含めるべきですか？

テストしたシナリオとその結果、未解決のすべての不具合とその責任者と期日、業務部門が受け入れた回避策、そしてプロセスオーナーごとの署名です。終了基準はUATが始まる前に合意してください。ギャップを抱えたままの承認は、記録された業務上の決定であるべきです。

SAP Cloud ALMはUATに使えますか？

使えます。SAP Cloud ALMは、プロセスから作成する手動のテストケース、サイクルごとのテスト計画、ステップごとの合格または不合格の記録、テスト実行からの不具合の起票に対応しています。SAPのガイダンスでは、パートナーの専門家がテストケースを準備し、顧客の業務部門の専門家がそれを実行して結果をそこに文書化します。