ストーリー
田
田中VPoE
ガバナンスの理論は一通り学んだ。ここからはStep 1で使った FreshCart社を題材に、データガバナンス体制を設計してもらう
あなた
FreshCart社はガバナンスがLevel 1でしたね。ゼロからの設計になります
あ
田
田中VPoE
そうだ。現状は個人情報の取り扱いすら曖昧な状態だ。まず緊急対応が必要な領域を特定し、その上で段階的なガバナンス体制を設計してくれ。経営会議で承認を得られるレベルの提案書を作ろう
ミッション概要
| 項目 | 内容 |
|---|---|
| 演習タイトル | データガバナンス体制設計書 |
| 想定時間 | 90分 |
| 成果物 | データガバナンス体制設計書（体制 + ポリシー + プライバシー対応 + ロードマップ） |
| 対象組織 | FreshCart株式会社（Step 1と同じ） |
前提条件
Step 1の前提条件に加え、以下の追加情報を考慮してください。
追加情報
| 項目 | 詳細 |
|---|---|
| 個人情報の保有件数 | 会員50万人分の氏名、住所、メール、電話番号、購入履歴 |
| 決済情報 | クレジットカード情報は決済代行（Stripe）に委託。トークンのみ保持 |
| 越境データ | 海外顧客なし。ただしSaaSの一部（GA4、Braze）がEU圏にデータ送信の可能性 |
| 過去のインシデント | 半年前にメール誤送信（100件）が発生。再発防止策は「気をつける」のみ |
| 委託先管理 | データ処理の委託先リストが最新でない |
| プライバシーポリシー | Webサイトに掲載しているが、3年前から更新していない |
Mission 1: オーナーシップ体制の設計
要件
FreshCart社のデータオーナーシップ体制を設計してください。
- データドメインの定義（最低6ドメイン）
- 各ドメインの役割割り当て（オーナー、スチュワード、カストディアン）
- ガバナンス委員会の構成と運営設計
解答例
データドメイン定義と役割割り当て
| データドメイン | データオーナー | データスチュワード | データカストディアン |
|---|---|---|---|
| 顧客マスター | EC事業部長 | EC開発テックリード | データエンジニア |
| 注文・決済 | EC事業部長 | EC開発シニアエンジニア | DBA |
| 商品マスター | MD部門長 | 商品管理チームリーダー | データエンジニア |
| 在庫・物流 | サプライチェーン部長 | サプライチェーンTL | インフラエンジニア |
| マーケティング | マーケティング部長 | マーケエンジニア | データエンジニア |
| ユーザー行動 | プロダクト部長 | プロダクトアナリスト | データエンジニア |
ガバナンス委員会
| 項目 | 設計 |
|---|---|
| 議長 | CTO（CDO不在のため兼務） |
| メンバー | EC事業部長、サプライチェーン部長、マーケ部長、データチームリーダー、法務担当 |
| 開催頻度 | 月次（初期3ヶ月は隔週） |
| 主要議題 | ポリシー承認、品質レポート確認、インシデント対応、コンプライアンス状況 |
| 事務局 | データチーム（2名兼務） |
Mission 2: ガバナンスポリシーの策定
要件
FreshCart社のガバナンスポリシーを策定してください。
- ガバナンス原則（5つ以上）
- データ分類ポリシー（全データドメインの機密度分類）
- データアクセスポリシー（各機密度レベルのアクセス制御基準）
- データ保持ポリシー（各データの保持期間）
解答例
ガバナンス原則
- データは組織の重要な資産: 全社員がデータの価値を認識し、適切に管理する
- 品質は全員の責任: データ品質の維持は特定チームではなく全社員の責任
- 最小権限の原則: 業務に必要最小限のデータのみアクセスを許可する
- 透明性と説明責任: データの利用目的と責任者を常に明確にする
- 顧客の信頼を最優先: プライバシー保護は法令遵守を超えた顧客への約束
データ分類ポリシー
| データ | 機密度 | 理由 |
|---|---|---|
| 顧客PII（氏名、住所、電話番号） | Restricted | 個人情報保護法の対象 |
| 決済トークン | Restricted | 不正利用リスク |
| メールアドレス | Restricted | 個人識別可能 |
| 購入履歴 | Confidential | 顧客の行動が推測可能 |
| 商品マスター | Internal | 社内業務情報 |
| 在庫数量 | Confidential | 競合優位情報 |
| ユーザー行動ログ | Confidential | 匿名でも行動追跡可能 |
| 集計済みKPI | Internal | 個人特定不可 |
データ保持ポリシー
| データ | 保持期間 | 根拠 |
|---|---|---|
| 顧客PII | 退会後1年 | 個人情報保護法（利用目的達成後速やかに削除） |
| 注文履歴 | 7年 | 税法上の帳簿保存義務 |
| 決済トークン | 退会後即時削除 | PCI DSS準拠 |
| ユーザー行動ログ | 2年 | 分析ニーズとストレージコストのバランス |
| インフラログ | 1年 | セキュリティ監査対応 |
Mission 3: プライバシー対応計画
要件
FreshCart社のプライバシー対応計画を策定してください。
- PIA（プライバシー影響評価）結果（リスク上位5つ）
- 緊急対応項目（1ヶ月以内に対応すべき事項）
- インシデント対応計画（メール誤送信の再発防止を含む）
解答例
PIA結果（リスク上位5つ）
| リスク | 影響度 | 発生可能性 | 対策 |
|---|---|---|---|
| 顧客PIIの不正アクセス | 極めて高い | 中 | RBAC導入、監査ログ、暗号化 |
| メール誤送信（再発） | 高 | 高 | テンプレート化、ダブルチェック機能 |
| 委託先からの漏洩 | 高 | 中 | 委託先管理の見直し、契約更新 |
| SaaSのEU越境転送 | 中 | 高 | GA4/BrazeのデータロケーションSCC対応確認 |
| プライバシーポリシーの不備 | 中 | 確定 | プライバシーポリシーの即時更新 |
緊急対応項目（1ヶ月以内）
- プライバシーポリシーの更新: 3年前の内容を最新の法令に合わせて更新
- 顧客DBのアクセス権限棚卸し: 誰が顧客PIIにアクセスできるか全件確認
- 委託先リストの最新化: データ処理委託先の一覧を更新し、契約内容を確認
- メール送信の安全措置: 一斉メール送信時のBCC強制化、テスト送信フロー導入
インシデント対応計画
| フェーズ | 対応内容 | 担当 | SLA |
|---|---|---|---|
| 検知 | アラート受信、一次判定 | SREチーム | 30分以内 |
| トリアージ | 影響範囲の特定、重大度判定 | データスチュワード + 法務 | 2時間以内 |
| 封じ込め | 漏洩の拡大防止 | カストディアン | 4時間以内 |
| 通知 | 個人情報保護委員会への報告（重大な場合） | 法務 + CTO | 速報3日以内 |
| 復旧 | システム復旧、データ修復 | カストディアン | 状況による |
| 振り返り | 根本原因分析、再発防止策 | ガバナンス委員会 | 2週間以内 |
達成度チェック
| 観点 | 達成基準 |
|---|---|
| 体制の網羅性 | 全データドメインにオーナー・スチュワード・カストディアンが割り当てられている |
| ポリシーの具体性 | 抽象的な原則だけでなく、具体的な基準が示されている |
| 分類の妥当性 | 機密度分類が法令やビジネスリスクに基づいている |
| プライバシーの緊急性 | 法令違反リスクの高い項目が緊急対応に含まれている |
| インシデント対応 | 検知→封じ込め→通知→復旧→振り返りの全フェーズがある |
| 実現可能性 | 300名規模の組織で実現可能な体制設計になっている |
推定所要時間: 90分