はじめに
第1回では、データマッピングの要件定義として、目的整理、スコープ設計、ヒアリング方針を整理した。
第2回では、その要件をどのように情報構造へ落とし込むかを扱う。データマッピングは単なる処理活動一覧ではない。処理活動、データカテゴリ、システム、第三者提供先、法的根拠、保存期間などを関係構造として管理し、RoPA（処理活動記録）、データフロー可視化、リスク管理、監査対応に活用できる状態を作ることが目的である。
本稿では、データ処理活動を例に、運用可能なデータマッピング基盤の構築上管理対象とすべきデータ要件やデータ構造をどのように設計するかを整理する。
なお、本稿内の画像は、弊社が提供する「IIJデータマッピング・リスク評価ツール」である米国OneTrustの画面表示である。
1. 設計の出発点 ― データ処理活動中心の設計
データマッピング設計で最初に決めるべきなのは「記録単位」である。
データ処理活動では、個別のデータ処理業務が中心的な記録単位となる。この単位には様々なメタ（属性）情報が紐付くが、その一例を以下に示す。
- データ主体（Data Subject）
- データカテゴリ（Data Category）
- 利用システム（Asset / System）
- 第三者提供先（Third Party）
- 法的根拠（Legal Basis）
- 保存期間（Retention）
データ処理業務を単位とするデータ構造は、データ処理活動、アセット、事業体、ベンダーの各要素をリレーショナルに組み合わせて統合管理するために必要不可欠であり、そうした構造を理解しないままデータマッピングを設計すると、利用価値が低い台帳が出来上がる。
2. 管理粒度の設計
データ処理活動の管理項目の粒度（どれだけ細かくレコードやデータ項目を設定するか）の設計は、運用負荷と可視化品質を大きく左右する。
管理粒度が粗すぎる場合：
- 複数部門で実施されるデータ処理業務が整理されずに混在する
- データ処理活動の責任主体が曖昧になる
- 法的根拠や保存期間が整理できない
などの問題が発生する。
一方、
管理粒度が細かすぎる場合：
- レコード数や管理項目数が爆発的に増加する
- 更新コストが増加し、現場の運用負荷が増大する
管理粒度の統一的な基準や規格は存在しないものの、実務上は以下の粒度基準が参考となる。
- データ処理活動については、「業務目的」「利用データ」「管理責任」が客観的に切り分け可能な単位で管理する。
- データ処理活動の各レコードで管理する項目については、GDPR第30条処理記録で求められる項目や、個人情報保護委員会が公表しているデータマッピングテンプレートの管理項目を基本とし、必要に応じ項目数を増減させる。
例えば「採用管理」と「従業員評価」といったデータ処理活動は、同じ人事部門でも目的・データ・利用者が異なるため、別処理活動レコードとして分離することが望ましい。
この画面では、データ処理活動に紐づく各種データ項目（メタデータ）を確認することができる。
ここでは、各データ処理活動に対して、どのようなデータを扱っているのか、どのように保存・管理されているのか、第三者提供や外部委託の有無などの情報が紐付けられていることを確認できる。
例えば、以下のような情報をデータ処理活動単位で管理する。
- どのようなデータを取り扱っているか（氏名、メールアドレス等）
- 保存期間や保管方法
- 第三者提供・外部委託の有無
- 越境移転の有無
- 処理の法的根拠
さらに、業務要件やリスク管理方針に応じて、独自のカスタム項目を追加することもできる。
例えば、以下のような管理項目が考えられる。
- 「マーケティング利用フラグ」
- 「機微情報フラグ」
- 「外部SaaS連携有無」
- 「AI利用有無」
3. アセット・サードパーティーとの関係設計
データ処理活動だけが登録され、システムや委託先といったアセットやサードパーティーとの関係性が未整備のまま放置されるケースがあるが、そのような管理はデータマッピングの価値を半減させる。データマッピングが提供する重要な価値は「データ処理活動の中で、どのデータが、どこへ、なぜ流れているか」といった、データ処理活動の主体とデータフローを可視化できることである。
そのため、以下のような管理項目の設定と、データ処理活動への紐付け設計が必要となる。
- どのシステムでデータを処理しているか
- どのベンダーへデータ処理を委託しているか
- 越境移転が存在するか
- どのような適法根拠を設定しているか
- 保存期間は何年か
4. ヒアリング設計
データマッピングの質を左右するのは、現場ヒアリングの内容である。例えば、「個人情報を扱っていますか？」といった質問は、どのような処理業務で誰がどのような個人情報を取り扱っているかを具体的に調査する上では不十分であり、以下のように業務起点で具体的な質問を準備する必要がある。
- どの業務で個人データを利用しているか
- 入力元はどこか
- どのシステムと連携しているか
- 外部委託先は存在するか
- 海外移転はあるか
- 削除タイミングは定義されているか
5. ワークフロー設計
データ処理活動の入力フォームだけ整備しても、その更新プロセスが存在しなければ、管理対象のデータは陳腐化し、その価値は損なわれる。
そのため、以下を事前に定義する必要がある。
- 誰がデータ処理活動を登録するか
- 誰がデータマッピング結果をレビューするか
- 誰がデータマッピング結果を承認または却下するか
- どのタイミングで棚卸（既存の管理情報を更新すること）を実施するか
- システム変更時に誰がデータマッピング結果を更新するか
社内での新システム導入、SaaS追加、委託先変更、データの海外移転の発生などを契機に、データ処理活動を見直す運用を設計することが求められる。また、データマッピング上の管理データの最新性と正確性を担保するため、例えば半年あるいは四半期ごとに棚卸を実施することも必要となる。
以下がデータ処理活動業務の評価の流れの入力イメージである。
6. 権限設計
ツール上でユーザ全員が、その権限に関わらず全データを閲覧・編集可能な状態は、悪意あるユーザによる記録の改ざんなどの不正行為の温床となる可能性があり、データの管理及び統制上大きな問題となる。
そのため、以下の観点でユーザ権限を分離する。
- 閲覧
- 編集
- 承認
- 管理
主要なツールでは役割（ロール）や権限（パーミッション）によって権限をユーザ単位で制御でき、かつ部門単位・役割単位でアクセス範囲を分離できる。
7 実務でよくある失敗
データマッピングの実務における典型的な失敗例は以下のとおりである。
- データ処理活動の管理粒度が荒いため、1レコードに複数のデータ処理活動の内容が含まれる・管理項目数を増やしすぎる（現場が回答してくれなかったり、不明や空白のまま提出される恐れがある）
- 更新責任者が明確に定められていない（誰の責任と権限で回答されたかが不明のままとなる）
- 現場ヒアリングを省略する（入力フォームを現場に「投げた」だけで満足する）
- ツールへの入力そのものを目的化する
おわりに
データマッピング設計で最も重要なのは、データ処理活動を中心に、組織・システム・データ・第三者・法的根拠を関係構造として管理する仕組みを設計することである。
ツールは単なるデータ入力・管理の道具ではなく、上記各要素の関係性を維持・可視化するとともに、監査に耐えうる社内統制を実現する情報基盤である。
そのため、ツール導入時には画面入力だけではなく、データガバナンス観点からのツール運用、回答・更新責任、更新プロセスまで含めて設計しなければならない。
第3回では、データマッピングツールの利用を前提とした、設計内容の実装・設定を実現するポイントについて解説する。
