SAPのテストデータ管理：マスキングした本番規模のデータ

SAPのテストデータ管理とは、実在の人物の情報をさらすことなく、すべてのテストシステムに本番と同じように振る舞うデータを用意する方法です。私のルールはシンプルです。マスキングしたデータを、ボリュームと現実性の両方で本番レベルにすることです。

少なく手作りのデータは、重要な不具合を隠します。マスキングしていない本番データは、顧客、仕入先、従業員のレコードを、本番より管理の甘いシステムに置くことになります。

テストデータは、より大きなテスト計画の一部です。私のSAPテストとはのガイドでは、テストの種類、その責任者、SAP Activateでの位置づけを解説しています。

テストが見つけられるのは、そのデータが引き起こせる問題だけです。未決済明細が5件の顧客と5万件の顧客では振る舞いが違いますし、テストクライアントで誰も作成していない価格条件が、テストクライアントで失敗することは決してありません。

私が最もよく目にしてきたテストの失敗は、結合テスト（SIT）とユーザー受入テスト（UAT）でのテスト不足です。貧弱なテストデータは、それが静かに起こる原因の1つです。テストケースは実行され、結果は緑に見えますが、壊れたはずのケースには、壊れるためのデータがなかっただけなのです。

だからこそ、私は本番レベルのデータにこだわります。それは次の4つを意味します。

1. ボリューム。 テーブルのサイズを本番に近づけ、レポート、ジョブ、検索が現実的な行数に対して実行されるようにします。
2. 多様性。 本番に実際に存在する変わったレコードです。ブロックされた仕入先、分納、貸方票、外貨、古い未決済明細などです。
3. 履歴。 年齢分析、減価償却、年度末処理が意味を持つだけの、締め済みの期間が必要です。
4. 整合性。 コピーとマスキングの後も、伝票がモジュールをまたいで正しくつながっていることです。

ボリュームが最も重要になるのはパフォーマンスです。パフォーマンステストは本稼働前に実施しなければならず、私の経験では、多数のユーザーが同時に作業する同時実行テストこそが重要です。

ほとんど空のデータベースでの同時実行テストは、ほとんど何も証明しません。そうしたテストの組み立て方は、私のSAPパフォーマンステストのガイドで解説しています。

テストシステムにある本番データも、個人データであることに変わりはありません。テストシステムや品質保証システムは通常、本番よりアクセスできる人が多く、マスキングはまさにそのリスクを塞ぐためにあります。

ほとんどの組織が基準にしているのはEUの一般データ保護規則（GDPR）で、多くの国の法律も同様の考え方に沿っています。GDPRの前文第26項は、すべてのSAPチームが知っておくべき区別を示しています。

1. 仮名化したデータは個人データのままです。 対応表のような追加の情報を使って個人に結びつけられるなら、規則は引き続き適用されます。
2. 匿名データは適用範囲外です。 もはや誰も特定できないデータは対象になりません。

実務上の帰結はこうです。ほとんどのマスキングが生み出すのは、匿名データではなく仮名化したデータです。マスキングしたテストシステムにも、アクセス制御、利用目的、保存期間のルールが必要です。監査人に尋ねられてからではなく、最初のコピーの前に、データ保護責任者にマスキングのルールを合意してもらってください。

よく使われる経路は5つあります。テストフェーズごとに必要なものが違うため、ほとんどのプログラムは複数を組み合わせます。

適合性を決めるポイントで比較したのが次の表です。

方法	得られるもの	ボリューム	プライバシーへの対処	最適な用途
システムのフルコピー	本番の正確なコピー。すべてのクライアントとテーブル	全量	コピーの後、ユーザーがアクセスする前にマスキングを実行する必要がある	パフォーマンステスト、模擬変換、カットオーバーリハーサル
クライアントコピー	システム内またはシステム間で1つのクライアントをコピー。マスタデータとトランザクションデータも含めるかはコピープロファイルで決まる	全量、またはカスタマイジングのみ	アプリケーションデータをコピーする場合はシステムコピーと同じ	新しいテスト用またはトレーニング用のクライアント、クライアントを既知の状態に戻すこと
SAP Test Data Migration Server（TDMS）	期間や組織単位で選択した縮小コピー。スクランブル処理つき	縮小	ツール内のスクランブルルール	すでにライセンスを持つ既存のSAP Business Suite環境
パートナーの選択的コピーツール	選んだビジネスオブジェクトやデータの一部を必要に応じてコピーし、転送中にマスキング	縮小、対象を絞る	ツール内のマスキングルールをコピー中に適用	定期的な更新、回帰テスト用のデータ、不具合の再現
作成または移行したデータ	スクリプト、移行ロード、手入力で作成したデータ	作った分だけ	ゼロから作れば実在の個人データはない	初期の単体テスト、本稼働前のグリーンフィールドのプロジェクト

システムのフルコピーとクライアントコピー

システムのフルコピーは、テストに使えるデータとして最も現実的なものです。同時に、本番が抱えるプライバシーのリスクもすべてコピーします。フルコピーを使うなら、マスキングを実行して確認するまでシステムはロックしたままにします。

クライアントコピーは、クライアントの作成とリセットに日常的に使うツールです。重要な判断はコピープロファイルです。設定だけを移すのか、マスタデータとトランザクションデータも一緒に移すのかがそこで決まるからです。

SAP Test Data Migration Server

SAP Test Data Migration Server（TDMS）は、本番データから縮小した非本番システムを作成し、機密性の高い項目をスクランブルします。SAP Business Suiteとともに発展してきた製品で、SAP Help Portalにある現在のドキュメントはリリース4.0 SP14のものです。

現在のS/4HANAリリースに対するTDMSの対応範囲や、名前の挙がった後継製品について、SAPの公式な発表は見つけられませんでした。TDMSに頼るつもりなら、RISE with SAPを含め、自社の移行先リリースと導入形態に対応しているかどうかをSAPに書面で確認してください。

SAP Landscape Transformationとシェルコピー

SAP Landscape Transformationは、SAPが選択的データ移行で使う分析と変換のツール群です。SAP Learningでは、シェル変換を、マスタデータとトランザクションデータを含めずに作成した本番システムのコピーを、S/4HANAに変換するものと説明しています。

同じ考え方はテストデータにも役立ちます。シェルからは業務データを含まない本番のリポジトリと設定が得られ、そこにテストに必要なデータだけを入れていけます。

いくつかのパートナー製品は、選んだ業務データをSAPのテストシステムにコピーし、その途中でマスキングします。ベンダー自身のサイトで主張を確認できたものを、順不同で挙げます。

1. EPI-USE Labs Data Sync Manager。 SAP ABAP環境間でデータをコピーしマスキングするスイートで、軽量なクライアント、オブジェクト単位のコピー、定義済みルールによるマスキングを含みます。EPI-USE Labsは、Data Sync ManagerがSAP S/4HANAおよびS/4HANA Cloudとの統合の認定を受けており、RISE with SAPでも動作するとしています。
2. SNP Kyano Test Data Organizer。 システム全体ではなくテストに必要なデータを抽出し、提供する際に機密データをマスキングします。SNPはTest Data OrganizerがRISE with SAP Private Cloud Editionに対応していると説明しています。
3. Qlik Gold Client。 選んだトランザクションデータを本番から非本番の環境へコピーして同期します。既存のシステムには静的マスキング、転送中のデータには動的マスキングを適用します。
4. Natuvion DCS Protect。 個人データを見つけ出し、テスト、品質保証、開発、トレーニングの各システムで匿名化または仮名化を適用します。Natuvionはこれをテスト移行と継続的な運用の両方に向けたものと位置づけていますが、そのページではS/4HANAに触れていないため、対応範囲は直接確認してください。

購入する前に、各ベンダーに自社のシステムで次の問いに答えてもらってください。

1. 現時点でどのS/4HANAリリースと導入形態に対応していますか？
2. データが本番を出る前にマスキングしますか、それとも移行先に着いてからですか？
3. 接続されたシステム間でマスキングの一貫性は保たれますか？　S/4HANAでマスキングした顧客が、CRMやデータウェアハウスの同じ顧客と一致しますか？
4. 本番のボリュームで、1つの会社コードの更新にどれくらいかかりますか？
5. カスタムテーブルや項目を追加したとき、マスキングのルールは誰が保守しますか？

テストフェーズごとに、データが必要な理由は異なります。S/4HANAプログラムでテストデータを計画するとき、私は次の表から始めます。

テストフェーズ	データが果たすべきこと	通常の出どころ
単体テスト	開発者が1つのオブジェクトが動くことを証明できる	作成したデータ、またはマスキングした小さなデータの一部
結合テストのラウンド	モジュールとインターフェースにまたがるプロセスの連鎖全体を実行できる	マスキングした本番レベルのコピー、または選択的コピー
ユーザー受入テストのラウンド	業務ユーザーが自分たちのケースだとわかるよう、自分たちのデータと同じ姿である	マスキングした本番レベルのデータを、各ラウンドの前に更新
回帰テスト	実行ごとに結果を比較できるよう、安定している	固定でリセット可能なデータセットと更新計画
パフォーマンステスト	同時実行の結果が意味を持つよう、本番のボリュームに合っている	マスキングしたフルコピー、または本番規模のボリューム
模擬変換とカットオーバーリハーサル	実際のデータの形で移行を証明する	本番のフルコピー。コアチーム以外の人がアクセスする場合はマスキング

UATには特に注意が必要です。ユーザー受入テストの責任者は業務部門であるべきで、私の考えでは最低でも6〜8週間が必要です。

マスキングした名前であっても、ユーザーには見覚えのあるデータを渡してください。自分たちの顧客、品目、価格表です。進め方は、私のSAPユーザー受入テストのガイドで解説しています。

模擬変換も同じ考え方です。ブラウンフィールドのシステム変換では、私は3回の模擬変換を計画し、それぞれ本番の最近のコピーで実行すべきです。

私の経験では、データ移行はプログラム工数の30〜40パーセントを占めます。こうした実行のためのデータへのアクセスは、移行チームと一緒に計画してください。模擬ロードがどう組み合わさるかは、私の記事SAPのデータ移行が失敗する理由で説明しています。

2つの環境、2つの更新計画

プログラムの期間中、私はプロジェクト用と通常業務（BAU）用の2つの環境を別々に運用します。そうすれば、本番保守の変更とプロジェクトの変更を分けてテストできます。

それぞれの環境に独自のテストデータ計画が必要です。BAUのテストには今日の本番に近いデータが必要です。保守での修正は今日の問題に対応するものだからです。

プロジェクトのテストには新しい設計に合ったデータが必要で、それは変換したコピーや選択的なロードかもしれません。それぞれに別の更新カレンダーを持たせ、一方の更新が、もう一方がまだ必要としているテストデータを消してしまうことがないようにしてください。

テストはプログラム工数の約35パーセントを占めます。テストデータは、SITの前の週ではなく、その工数の中で計画してください。

私なら次の順序で進めます。

1. 原則を書面で合意する。 マスキングした本番レベルのデータとし、プログラムのスポンサー、データ保護責任者、業務の責任者が承認します。
2. 個人データと機密データを洗い出す。 顧客、仕入先、従業員、銀行口座情報、連絡先、自由記述の項目、添付ファイル、そしてそれらを保持するカスタムテーブルです。
3. マスキングのルールを書く。 項目ごとに、何を置き換え、何を残し、何を削除するかを決め、接続されたシステム間で置き換えの一貫性を保ちます。
4. データを各テストフェーズに対応づける。 上の表を出発点にし、まずパフォーマンステストと同時実行テストのためにボリュームを見積もります。
5. コピーの方法とツールを選ぶ。 ボリュームが重要な場面ではフルコピー、速度と頻度が重要な場面では選択的コピーを使い、自社のリリースへのツールの対応を確認します。
6. 更新カレンダーを決める。 環境ごとに1つの計画を持ち、SITとUATの各ラウンド、各模擬変換の前に更新するよう日程を組みます。
7. マスキングを確認するまでアクセスをロックする。 マスキングのチェックに合格するまで、コアの技術チーム以外の誰も新しいコピーにログオンしません。

そのうえで、これをゲートにしてください。各サイクルの戦略、開始基準、終了基準は私のS/4HANAテスト戦略のガイドにまとめてあり、テストデータの準備状況はすべてのラウンドの開始基準に含めるべきです。

具体的な次の一歩はこうです。現在、本番データのコピーを保持しているすべての非本番システムを書き出し、どれがマスキングされているかを確認してください。

S/4HANAプログラムのテストデータのアプローチやテスト計画について独立した視点が必要であれば、こちらからご連絡ください。

SAPのテストデータ管理とは何ですか？

SAPのテストシステムのデータを計画し、作成し、コピーし、マスキングし、更新する方法です。目的は、見るべきでない人に実在の個人データをさらすことなく、ボリュームと現実性の両方で本番と同じように振る舞うデータを用意することです。

SAPのテストに本番データを使ってもよいですか？

マスキングした後に限ります。それでもアクセス制御が必要です。GDPRでは仮名化したデータも個人データのままなので、マスキングしたコピーにも利用目的、アクセスのルール、保存期間のルールが必要です。最初のコピーの前に、データ保護責任者とマスキングのルールを合意してください。

SAP TDMSはS/4HANAでもまだ使えますか？

SAP Help Portalにある現在のTDMSのドキュメントはリリース4.0 SP14のもので、TDMSはSAP Business Suiteとともに発展してきた製品です。現在のS/4HANAリリースへの対応範囲について、SAPの公式な発表は見つけられませんでした。TDMSを前提に計画する前に、SAPに書面で確認してください。

SAPの選択的なテストデータを作成するツールには何がありますか？

SAP Test Data Migration Serverと、EPI-USE Labs Data Sync Manager、SNP Kyano Test Data Organizer、Qlik Gold Clientといったパートナー製品です。Natuvion DCS Protectは、テストシステム内のデータの匿名化と仮名化に特化しています。それぞれ、自社のS/4HANAリリースと導入形態に照らして確認してください。

SAPのパフォーマンステストにはどれくらいのテストデータが必要ですか？

本番レベルのボリュームです。パフォーマンスの問題は、実際のテーブルサイズと多数の同時ユーザーのもとで表面化するため、少ないデータセットでのテストはほとんど何も証明しません。パフォーマンステストと同時実行テストには、マスキングした本番のフルコピーを使うのが一般的です。