テストフェーズ徹底攻略

品質を担保し、DXを加速する

2026年6月

はじめに：テストは「バグ探し」ではなく「本番稼働への保険」である

SAP S/4HANA導入プロジェクトにおいて、テストフェーズは「設計・開発が終わったら試してみる」という受け身の活動として捉えられがちである。しかしこの認識は根本的に誤りである。テストとは、本番稼働というたった一度の「一発勝負」に向けて、「この状態で本番に移行してよいか」という問いに対する客観的な証拠を積み上げる活動である。

「バグが見つからなかった」は「品質が高い」ことの証明ではない。「十分なシナリオを、十分な技術で、十分な人間がテストし、すべて合格した」という事実が、初めて品質の証拠となる。テストの質を決めるのは「何件テストしたか」ではなく「どのシナリオを、どのデータで、どの視点でテストしたか」である。

本ガイドは、SAP S/4HANA導入におけるテストフェーズの全体設計から実行・管理・判定基準まで、実践的に解説する。テストを「作業」としてではなく「DXを成功に導く最後の砦」として位置づけることが、本ガイドの中心的なメッセージである。

第一章　テスト体系の全体設計：「何を・どの順序で・誰が」テストするか

1-1　SAP S/4HANAテストの4層構造

SAP S/4HANA導入においてテストは4つの層（レイヤー）で構成される。各層は互いに依存関係があり、下の層が合格してから上の層に進む「ゲート方式」で管理することが原則である。

テストレイヤー	目的	実施者	完了の定義
①単体テスト（UT）	個別機能・プログラムの動作確認	コンサルタント・開発者	全テストケースの合格。欠陥修正完了。
②統合テスト（IT）	複数モジュール・プロセス間の連携確認	コンサルタント＋業務チーム	エンドツーエンドのシナリオが合格。クリティカル欠陥ゼロ。
③UAT（ユーザー受入テスト）	実ユーザーによる業務適合性の最終確認	業務部門担当者	全UATシナリオの合格。業務部門のサインオフ取得。
④パフォーマンステスト	本番相当のデータ量・同時接続数でのパフォーマンス検証	技術チーム	SLA（応答時間・バッチ完了時間）をクリア。

1-2　テストスコープの定義：「何をテストするか」を先に決める

テストで最も重要な意思決定の一つが「スコープの定義」である。全機能をテストしようとすると時間とリソースが際限なく必要になり、プロジェクトが破綻する。スコープはリスクベースで優先順位をつけるべきである。

優先度	基準	テスト密度
最高優先	業務上のクリティカルパス（出荷・請求・決算）	全シナリオ・異常系含む徹底テスト
高優先	日次・週次で頻繁に使用する機能	主要シナリオを網羅
中優先	月次・四半期に使用する機能（月次締め・棚卸し）	代表的シナリオ
低優先	稀にしか使わない機能（年次処理・特殊取引）	最低限の確認
スコープ外	既存標準機能で変更なし・将来フェーズ実装予定	省略（変更点のみテスト対象）

第二章　テストシナリオの設計：「現実の業務」を再現する

2-1　テストシナリオとは何か：業務フロー全体を「1本の糸」でつなぐ

テストシナリオとは「ある業務上の出来事がSAPのどの画面操作から始まり、どのような処理を経て、どのような結果になるべきか」を記述した、業務フロー全体をカバーするシナリオ文書である。「品目マスタの登録ができること」というテストケースはシナリオではない。「得意先Aから品目Bを10個受注→在庫引当→出荷→請求書発行→入金→売掛金消込」というエンドツーエンドの流れがシナリオである。

2-2　テストシナリオの設計手順

テストシナリオ設計の5ステップ

Step 1：業務プロセス一覧から「テスト対象プロセス」を洗い出す

Step 2：各プロセスについて「正常系（通常取引）」と「異常系（エラー・例外）」のシナリオを識別する

Step 3：各シナリオに「テストデータ（品目コード・数量・金額等）」を具体的に設定する

Step 4：各ステップの「期待結果」を明記する（例：請求書XXXが生成され、金額はYYY円）

Step 5：シナリオ間の「実行順序・依存関係」を整理する（前シナリオの結果を次シナリオが参照する場合）

2-3　異常系テストの重要性：「うまくいかないとき」こそ本番の危機

テスト設計において最も手を抜かれやすいのが「異常系テスト」である。正常系（想定通りの操作・データ）のテストは誰でも思いつくが、「異常系（間違った操作・エラーデータ・権限外操作）」のテストは意識しないと見落とされる。

しかし本番環境でユーザーが最も困惑するのは「うまくいかないとき」である。エラーメッセージが意味不明で操作が止まる、承認フローで誰も承認しないと仕事が進まない、在庫がマイナスになって移動伝票が登録できない——こうした異常系の場面での対処手順を、テストフェーズで確認・文書化しておくことが必要不可欠である。

異常系テストの類型	テスト例	確認すべきこと
入力エラー	必須項目未入力・数値フィールドに文字入力	適切なエラーメッセージが表示されること
権限エラー	権限のないユーザーが機密帳票を閲覧しようとする	アクセス拒否（権限エラー）が正しく機能すること
業務ルール違反	与信限度額を超えた受注の登録	与信チェックが発動し受注が保留になること
在庫不足	在庫がゼロの品目を出荷しようとする	ATP不合格のエラーが出て出荷伝票が作れないこと
会計期間外	締済み会計期間に仕訳を登録しようとする	エラーで登録できないこと（または適切な警告）

第三章　統合テスト（IT）：「モジュールの壁」を越える

3-1　統合テストの本質：SAP は「一枚岩」だからこそ統合テストが難しい

SAP S/4HANAは単一のシステムでありながら、SD（販売）・MM（購買）・PP（生産）・FI（財務）・CO（管理会計）など多数の機能モジュールから構成される。統合テストとは、これらのモジュール間で「データが正しく連携するか」を確認するテストである。

統合テストが難しい理由は、一つの業務イベントが複数のモジュールに連鎖するからである。例えば「出荷処理（SD）」を実行すると、同時に「在庫が減少（MM）」し「売上原価仕訳が自動生成（FI）」される。この連鎖が正しく機能しているかを確認するには、SD担当者とFI担当者が同一のテストシナリオをともに実行する必要がある。「縦割り」でモジュール別にテストするだけでは、統合テストの本質的な課題は捉えられない。

3-2　統合テストのシナリオ設計：E2E（End to End）が原則

統合テストシナリオ	開始	終了	参照モジュール
受注〜入金（O2C）	VA01 受注登録	F-28 入金消込	SD / MM（ATP）/ FI
発注〜支払（P2P）	ME21N 購買発注	F110 自動支払	MM / FI
生産計画〜完成品入庫	MD01N MRP実行	MB31 完成品入庫	PP / MM / CO
プロジェクト〜工事進行基準	CJ01 WBS作成	VF44 収益認識	PS / SD / CO / FI
月次決算サイクル	FB01 手動仕訳	F.07 A/R調整	FI / CO

3-3　欠陥管理：「課題をどう管理するか」

統合テストでは大量の欠陥（バグ・設定ミス・仕様との差異）が発見される。これらを適切に管理しなければ、「どの欠陥が解決されたか」「どの欠陥がまだ残っているか」が把握できなくなり、テストが収束しない。

欠陥管理は「バグ管理ツール」（Jira・ServiceNow・Excel管理表など）を使い、以下の4項目を必ず記録する。

欠陥管理の必須記録項目

① 欠陥ID・発見日・発見者・テストシナリオID

② 欠陥の再現手順（操作手順・テストデータ・実際の結果・期待した結果）

③ 重要度（Critical/High/Medium/Low）と優先度（P1〜P4）

④ 担当者・修正予定日・修正確認者・クローズ日

コンサルタントの視点

Criticalバグ（本番稼働を妨げる欠陥）がカットオーバー前日に残っているプロジェクトは珍しくない。毎週「Criticalバグ残件数の推移グラフ」を経営に提示し、「今週5件→来週2件→再来週0件」という見通しを持つことが、GoサインのNo-Goサインの判断を冷静に行うための必要条件である。

第四章　UAT（ユーザー受入テスト）：「使う人間」が合格を出す

4-1　UATとはサインオフ（承認）を取るプロセスである

UAT（User Acceptance Testing）は、最終的なシステムの「合格証書」を業務部門のユーザーから取得するプロセスである。テクノロジーチームやコンサルタントがいくら「完璧だ」と言っても、業務部門が「これで業務ができる」と確認しなければ、本番稼働に踏み切る根拠がない。UATはこの「ユーザーによる合格宣言（サインオフ）」を正式なプロセスとして設計する必要がある。

4-2　UATの計画と運営

項目	推奨内容
UATの実施者	実際に業務を担当する現場ユーザー（コンサルタントが代理実施は不可）
UATシナリオ	日常業務の主要パターン全て＋月次・年次処理の代表シナリオ
UATデータ	本番に近い実データ（または実データに近いサンプルデータ）
UATの期間	2〜4週間（期間を圧縮しすぎると見落としが多発）
サインオフ条件	Critical欠陥ゼロ／High欠陥が全て修正予定確認済み／業務部門責任者の署名
NGの場合の対応	欠陥修正後に当該シナリオを再テスト・再サインオフを取得

4-3　UATが形骸化する「3つの罠」

実務においてUATは形骸化しやすい。以下の3つの罠に陥ったプロジェクトでは、UATの意味が失われ、結果として本番稼働後に大量の問題が噴出した事例が多い。

• 罠①「コンサルタントがUATを代行する」：ユーザーが理解・使用できるかの確認になっていない。業務部門が「合格した気持ちになっている」だけで実態を把握していない状態が生まれる。

• 罠②「テストデータが非現実的」：架空データ・少量データでのテストでは、実業務の複雑さを再現できない。例えば、1万件の受注が同時に流れるような高負荷シナリオは実データ規模でしか確認できない。

• 罠③「サインオフが儀式化する」：欠陥が多く残っているにもかかわらず、プロジェクト日程を守るために「承知の上でサインオフ」させられるケース。「承知の上での条件付きサインオフ」は明確に記録し、GoサインNoGoサインの判断に反映させなければならない。

第五章　パフォーマンステストと本番移行判定

5-1　パフォーマンステストの設計

SAP S/4HANAが本番環境で「遅くて使えない」という問題は、テストフェーズで少量データ・少数ユーザーでしかテストしなかった場合に発生する。パフォーマンステストとは「本番相当の条件」でシステムの応答速度・処理能力を確認する活動である。

テスト種別	目的	測定項目
ロードテスト	通常の同時接続数での応答時間確認	ピーク時同時ユーザー数でのトランザクション応答時間
ストレステスト	限界負荷時の挙動確認	システムが破綻するユーザー数・応答が著しく遅延するポイント
バッチパフォーマンス	夜間バッチ処理の所要時間確認	MRP（MD01N）・月次決算バッチ・入金消込バッチの所要時間
データボリュームテスト	本番データ量での処理性能確認	3年分・5年分の蓄積データがある状態での照会・集計速度

5-2　本番移行判定（Go/No-Go）：最終的な「開幕宣言」

テストフェーズの最後に「本番移行判定会議（Go/No-Go Meeting）」を開催する。これは「テスト結果を総合的に評価し、予定通りカットオーバーに進むか（Go）、延期するか（No-Go）」を経営が正式に判断する場である。

この会議は形式的なものであってはならない。すべての判断基準に対する客観的な証拠（テスト結果・欠陥管理状況・未解決課題リスト）が提示され、プロジェクトスポンサーが「この状態で本番に移行することのリスクを理解した上でGoを宣言する」という正式なプロセスである。

判定カテゴリ	Go条件	No-Go条件
テスト完了率	全UATシナリオの95%以上を実施・合格	完了率80%未満、または主要シナリオが未実施
欠陥状況	Criticalバグゼロ。HighバグはWorkaround確認済み	未解決のCriticalバグが1件でも存在
パフォーマンス	全SLAクリア（応答3秒以内・夜間バッチ8時間以内）	SLA未達・改善策未確定
サインオフ	全業務部門からの正式サインオフ取得	主要部門のサインオフ未取得
体制	カットオーバー担当者全員のアサイン確認	主要担当者の不在・代替不能
ロールバック	ロールバック手順の動作確認完了	ロールバック手順が未確認・未整備

5-3　テストフェーズで培った「品質文化」を本番後に活かす

テストフェーズが終わり本番が始まっても、「品質を証拠で担保する」という姿勢は失われてはならない。本番稼働後の定期的な業務データ品質チェック、月次の仕訳自動化率モニタリング、四半期ごとのシステム応答時間測定——これらはテストフェーズで培った「客観的な証拠によって品質を語る文化」の延長線上にある。

テストは「リリース前にやること」ではなく「常にシステムと業務の整合性を確認し続けること」である。この認識こそが、SAP S/4HANAを単なる「稼働したシステム」ではなく「DXを継続的に推進するプラットフォーム」として育てていくための、最も重要な組織能力に他ならないのである。

以上