このユニットの結論
テストの結果は、テストデータの質で決まります。
本番のデータをそのまま使えば安全の問題になり、適当に作ったデータでは本番の問題が見つかりません。目的ごとにデータの作り方を決め、個人情報は作り変え、本番相当の量と偏りを持たせ、誰がどのデータをいつ使ったかを管理する。それがテストデータの管理です。
1. 何の話か
このユニットは、テストに使うデータをどう用意し、どう扱うかの話です。
10-02 小さい単位から全体へテストする で学んだ各段階のテストは、どれもデータを必要とします。部品のテストには少量の決まったデータ、つなげたテストには複数システムで整合したデータ、性能のテストには本番相当の量のデータ。目的が違えば、必要なデータも違います。
2. なぜ必要か
テストデータを管理しないと、
- 本番のデータをテスト環境に複製し、開発者やベンダーが本番の個人情報を見られる状態になる（08-05 開発者は本番データを自由に見てよいのか）
- 少量のきれいなデータでテストし、本番の量と汚れで初めて問題が出る
- テストのたびにデータが変わり、同じテストを繰り返せず、結果を比べられない
- 複数のシステムのテストデータが整合しておらず、連携のテストが始められない
ということが起きます。
3. このユニットで分かること
- 目的ごとのテストデータの種類
- 本番データを使うときの作り変え（マスキング）
- データの整合と、版の管理
4. 目的ごとのデータ
| 目的 | 必要なデータ | 作り方（一般的な例） | 注意 |
|---|---|---|---|
| 部品のテスト | 少量で、結果が決まっているデータ | 手で作る。境目の値（0、上限、空、異常な形）を含める | 本番の複製は不要 |
| つなげたテスト | 複数のシステムで整合したデータ | 業務の流れ（顧客 → 契約 → 案件 → 工数 → 請求）に沿って一式作る | システムごとにばらばらに作ると整合しない |
| 利用者の受入テスト | 業務部門が自分の業務として確かめられるデータ | 本番を作り変えたもの。業務部門が読める内容 | 個人情報の作り変えが必須 |
| 性能のテスト | 本番相当の量と偏り | 本番を作り変えて複製するか、本番の分布に合わせて生成する | 量だけでなく偏り（特定の顧客に件数が集中 など）を再現する |
| 移行のリハーサル | 本番の全量 | 本番から移行の処理で作る | 環境と権限を本番と同じ厳しさで扱う |
5. 作り変えと、整合と、版
本番データの作り変え（マスキング）は、個人を特定できる項目（氏名、住所、連絡先、口座）を、形を保ったまま別の値に置き換えることです。形を保つ（桁数、文字の種類、存在する郵便番号）ことで、テストとしての価値を残します。作り変えの規則は文書にし、作り変える前のデータに触れる人を限ります。
整合は、複数のシステムにまたがるテストデータを一式として作ることです。顧客がいて、契約があり、案件があり、工数が付き、請求がある。この一式を「テストデータの組」として番号を付け、どのテストがどの組を使うかを TST-002 テスト計画・対象一覧 に書きます。
版は、テストデータを環境ごとに固定し、テストの前に決まった状態に戻せるようにすることです。どの環境にどの版のデータが入っているかは DEV-004 環境・リリース対応表 と合わせて管理します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件のデータとテストに関する記載
- 10年分のデータ移行。最重要データチェーン：顧客 → 契約 → 案件 → 要員 → 工数 → 原価 → 売上 → 請求 → 会計 → 経営分析
- データ正本：顧客・契約は営業管理システム、社員・組織は人事マスター、工数は勤怠・工数管理SaaS
- 成果物に TST-002 テスト計画・対象一覧、DEV-004 環境・リリース対応表、SEC-003 本番特権アクセス管理表 がある
- P-010 宮田 直人 — テスト・品質管理リーダー、P-012 石井 稔 — セキュリティ責任者
アステリア案件でテストデータがどう作られ、本番データがどう作り変えられ、誰が扱えたかは、正本に記録がありません。記録なし
6. THINK — 「本番のデータをコピーすれば早い」
テスト環境の準備で、ある担当者が次のように提案しました。
「本番のデータベースをそのままテスト環境にコピーしましょう。一番早いし、本番と同じデータでテストできます。」
問題
この提案をそのまま認めてよいでしょうか。
判断例を開く
判断
「本番と同じデータ」は、テストには良くても、安全には最悪です。
確認すること:
- テスト環境を見られる人（開発者、ベンダー、外部の作業者）は、本番の個人情報を見てよい人か
- 個人情報の項目を、形を保ったまま作り変える規則と仕組みがあるか
- 作り変える前のデータに触れる人と手順が、本番と同じ厳しさで管理されるか
- テスト環境の守りは本番と同じか（多くの場合、テスト環境の方が緩い）
- 本番のデータに、取引先との契約で複製を禁じられているものはないか
早さのために作り変えを省くと、テスト環境が「守りの緩い本番」になります。作り変えの仕組みを先に作ることが、結局は早道です。
7. よくある失敗
- 本番データを作り変えずにテスト環境へ複製し、個人情報が守りの緩い環境に置かれる
- システムごとにばらばらにデータを作り、連携のテストで整合しないことに気づく
- 少量のきれいなデータだけでテストし、本番の量と汚れで初めて問題が出る
- テストのたびにデータが変わり、同じ不具合を再現できない
8. 成果物との接続
- TST-002 テスト計画・対象一覧：テストごとに、使うデータの組と作り方を書く
- DEV-004 環境・リリース対応表：環境ごとに、入っているデータの版を管理する
9. AI WORKFLOW — 個人情報の項目の洗い出しを手伝わせる
AIは、データ定義書から、作り変えが必要な項目（個人を特定できる項目）の候補を挙げる下書きに役立ちます。
指示例:
「次のデータ定義書の項目一覧から、個人を特定できる可能性のある項目（氏名、住所、連絡先、識別番号、生年月日、口座 など）の候補を挙げ、項目ごとに理由を添えてください。作り変えの方法は提案せず、候補の列挙にとどめてください。」
10. REVIEW — AIの候補を確認する
- AIが挙げた候補に抜けがないか（名前が一般的でない項目、組み合わせで特定できる項目）
- 候補のうち、本当に作り変えが必要かを、個人情報の扱いを決める担当と確かめたか
- データ定義書を AI に渡してよいか（定義書自体に実データが含まれていないか）を事前に確かめたか
11. 人間が判断すること
- 目的ごとに、本番の作り変えを使うか、生成したデータを使うか
- 作り変える項目と規則
- 作り変える前のデータに触れてよい人
セキュリティ例外承認は、AIへ最終委任しない事項です（正本の方針）。
12. 判断演習
「請求書を発行する機能」のテストに必要なデータを考えてください。
部品のテスト・つなげたテスト・性能のテストのそれぞれで、どんなデータが要るかを書き、そのうち本番のデータを作り変えて使うべきものはどれか、作り変える項目は何かを書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
テストの質はデータで決まる。目的ごとに作り方を決め、本番データは形を保って作り変え、複数システムで整合した組を版で管理する。