仮名加工化の実践データ分析基盤における挑戦と学び

©2023 10X, Inc. 自己紹介 • 水谷優斗 ◦ 各種id: @tenajima •
株式会社10X データ基盤チームデータエンジニア ◦ 2023年2月入社 ◦ 小売企業企業へのダッシュボードの提供、社内データ基盤の運用 • 経歴 ◦ Fringe81(現Unipos) にデータサイエンティストとして新卒入社 ◦ データサイエンティストとして広告基盤の改善に取り組んだり、 HR SaaSのデータ活用に取り組んだり ◦ 2021年4月頃からデータ分析基盤の作成、社内のデータ活用に取り組むようになる • 趣味 ◦ 野球とワンピースはじめにに

©2023 10X, Inc. 提供プロダクトお客様アプリ • 数万SKUから商品からスムーズにカゴを作成できるUX • キーワード・カテゴリ検索・お気に入り・注文変更・購入履歴といった基本機能
• 商品の受け取り方法を選択 • 注文状況・配達状況の確認や通知 • Web(オプションにて提供) 数万点のSKUからスムーズにお買い物ができるUXを提供主な機能 3

©2023 10X, Inc. 提供プロダクトスタッフアプリ • ピッキングリストを自動生成 • 移動距離最短化、複数スタッフに並行作業可能 •
バーコード照合でのヒューマンエラー防止をサポート • 多様な受け取り方法に対応ミスが少なく効率的な業務オペレーションシステムを提供主な機能 4

©2023 10X, Inc. 目次 5 1. 仮名加工化とは 2. 仮名加工化の導入背景 3.
データ分析基盤の設計 4. 直面した困難 5. 挑戦と学び

©2023 10X, Inc. 個人情報について • 個人情報とは生存する個人に関する情報であって、次のいずれかに該当するもの ◦ 情報それ自体で特定の個人を識別することができるもの ◦
他の情報と照合することによって特定の個人を識別できるもの ◦ 個人識別符号が含まれるもの仮名加工化とは https://keiyaku-watch.jp/media/hourei/kojinjoho/ https://www.ppc.go.jp/files/pdf/report_office_zirei2205.pdf ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500

©2023 10X, Inc. 個人情報について • 個人情報とは生存する個人に関する情報であって、次のいずれかに該当するもの ◦ 情報それ自体で特定の個人を識別することができるもの ◦
他の情報と照合することによって特定の個人を識別できるもの ◦ 個人識別符号が含まれるもの仮名加工化とは https://keiyaku-watch.jp/media/hourei/kojinjoho/ https://www.ppc.go.jp/files/pdf/report_office_zirei2205.pdf ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ユーザーIDにテーブル単位で紐づく情報は基本全て個人情報

©2023 10X, Inc. 仮名加工情報について • 一定の措置を講じて個人情報を加工し、他の情報と照合しない限り特定の個人を識別できないようにした情報仮名加工化とは https://keiyaku-watch.jp/media/hourei/kameikakojoho/ https://www.ppc.go.jp/files/pdf/report_office_zirei2205.pdf
ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID 住所購入金額 xxx111222 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 仮名加工情報元の個人情報

ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID 住所購入金額 xxx111222 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 ① 情報それ自体で特定の個人を識別できるもの仮名加工情報元の個人情報

ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID 住所購入金額 xxx111222 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 仮名加工情報元の個人情報 ① 情報それ自体で個人を識別できるものをを落とす

ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID email_address 住所購入金額 xxx111222 hoge@sample.com 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 仮名加工情報元の個人情報 ② 他の情報と照合することで個人を識別できるもの

©2023 10X, Inc. 仮名加工情報について • 一定の措置を講じて個人情報を加工し、他の情報と照合しない限り特定の個人を識別できないようにした情報　仮名加工化とは https://keiyaku-watch.jp/media/hourei/kameikakojoho/ https://www.ppc.go.jp/files/pdf/report_office_zirei2205.pdf
ユーザーID 氏名 email_address 住所購入金額 aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID email_address 住所購入金額 xxx111222 hoge@sample.com 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 仮名加工情報元の個人情報 ② 管理ルールを定めて適切に取り扱うようにする

©2023 10X, Inc. 仮名加工情報と匿名加工情報の違い • 一定の措置を講じて個人情報を加工し、特定の個人を識別できないようにした情報であって、当該個人情報を復元できないようにしたもの • 仮名加工情報は「他の情報と照合しない限り特定の個人を識別できない」状態に止まるため、自社にとっては原則として引き続き個人情報である
• 匿名加工情報は自社にとっても完全な非個人情報である仮名加工化とは項目匿名加工情報仮名加工情報未加工の個人情報個人情報かどうか個人情報でない個人情報個人情報データの粒度粗い中細かい情報漏洩リスク低い中高い

©2023 10X, Inc. 今回仮名加工化の対象したカラム例仮名加工化とは user_id email_address aaa-bbb-ccc hoge@sample.com ddd-eee-fff
fuga@sample.com https://keiyaku-watch.jp/media/hourei/kojinjoho/ event_date user_id 2024-06-19 aaa-bbb-ccc 2024-06-19 ddd-eee-ff order_id address xxx-yyy-zzz hoge県fuga市piyo町 1-2-3 アパート1号室 ooo-ppp-qqq A県B市C町456 マンション 2号室 event_date order_id 2024-06-19 xxx-yyy-zzz 2024-06-19 ooo-ppp-qqq

©2023 10X, Inc. メリット: 漏えい等の報告に関して • 取り扱う個人データが漏えい等をした場合個人情報保護委員会への報告等を実施しなければならない • しかし、仮名加工情報が漏えい等をした場合には、この義務が課されない
◦ やらなくて良いというニュアンスではなく、漏えいした仮名加工情報から個人を識別できる情報に戻して誰の情報が漏えいしたかまで特定することができないしやってはいけないというニュアンス仮名加工化の導入背景

©2023 10X, Inc. データ分析基盤における仮名加工情報のイメージ仮名加工化の要件を満たすデータ分析基盤の設計ユーザーID 氏名 email_address 住所購入金額
aaa-bbb-ccc 山本hoge hoge@sample.com 千葉県西東町323 4,300 ddd-eee-fff 渡辺fuga fuga@sample.com 埼玉県米麺市456 12,500 ハッシュ化されたユーザーID 住所購入金額 xxx111222 千葉県西東町 4,300 yyy333444 埼玉県米麺市 12,500 仮名加工情報元の個人情報

©2023 10X, Inc. データ分析基盤における仮名加工化の要件 • 要件1:(当たり前だが)ハッシュ化なので復号できないようにする ◦ 生のidとハッシュ化されたidのマッピングをどこにも持っていないようにする • 要件2:
仮名加工化されたテーブルは、そのことが分かるようにする • 要件3: 小売企業側での規程の整備 ◦ 小売企業側に仮名加工情報に関する社内規程を整えてもらう必要がある ◦ 規程と技術的対応の両方が揃って初めて法的に仮名加工情報となる仮名加工化の要件を満たすデータ分析基盤の設計

©2023 10X, Inc. 要件1: ハッシュ化なので復号できないようにする • 生のidとハッシュ化された id のマッピングをどこにも持っていないようにする ◦
生のidとハッシュ化されたカラムの両方を持つテーブルがないかのカスタムジェネリックテストを dbt で実装し、CI でチェックする • 本番環境のソルトを使ってマッピングを作ることを防ぐ ◦ 本番用のソルトにアクセスできる人を制限する ◦ 後述します仮名加工化の要件を満たすデータ分析基盤の設計

©2023 10X, Inc. 要件1: ハッシュ化なので復号できないようにする • ソルトの管理に関する課題 ◦ dbt Cloud
IDE 経由で本番のソルトにアクセスできてしまう • 課題が起きていた背景 ◦ dbt Cloud に project が30近くある ◦ 大きく分けると stailer のアプリケーションで使うものと、分析基盤のためのもの ◦ それぞれ開発用と本番用があり、結果 30近くになる ◦ dbt Cloud のデフォルト Group の Member は全ての project に対して IDE で開発できる権限を持っている ◦ 分析基盤用の project で dbt Cloud の IDE を使うとソルトにアクセスできてしまう状態にあった仮名加工化の要件を満たすデータ分析基盤の設計 https://dev.classmethod.jp/articles/dbt-cloud-default-group-owner-member/

©2023 10X, Inc. 要件1: ハッシュ化なので復号できないようにする • 要求事項 ◦ ソルトは決められた人しかアクセスできないようにする •
やったこと ◦ データ分析基盤に関係ある人のみ project にアクセスするように整理 ◦ prod の cloud IDE を使えないようにする( prod は job の管理に集中) ◦ データ分析基盤の prod と dev 環境のソルトの分離 ▪ 開発は滞りなくできるようにする ▪ prod のソルトにアクセスできるのは限られた管理者と prod のService Account のみにする仮名加工化の要件を満たすデータ分析基盤の設計 https://docs.getdbt.com/docs/cloud/manage-access/enterprise-permissions

©2023 10X, Inc. 要件2: 仮名加工化されたテーブルはそのことが分かるようにする要件3:小売企業側での規程の整備 • BigQueryのラベルを活用し、テーブルごとにラベルをつける ◦
テーブルひとつづつラベルをつけるのではなく、 dbt_project.yml を用いて効率的に指定 ◦ 「小売企業の社内規程が完了しているよ」「ハッシュ化が完了しているよ」という二つのラベルが揃って法的に仮名加工情報となる仮名加工化の要件を満たすデータ分析基盤の設計

©2023 10X, Inc. 分析基盤開発者向けのレイヤーの詳細 • ここは生のidが存在する • このレイヤーにアクセスできる社員は限られる(分析基盤開発者のみ) • 生のidとハッシュ化されたidの対応を作ることを禁止する
◦ 開発者でも本番環境のソルトにアクセスできる社員はさらに絞ることで規制する ◦ この部分は開発者のソルトアクセスもさらに手放してガバナンスと実行をより分けて行ったほうがいいと考えています仮名加工化の要件を満たすデータ分析基盤の設計

©2023 10X, Inc. 困難1: そもそもの影響範囲が大きい • 課題: ECサイトの分析基盤おいて既存のuser_idとorder_idを無くして、別名でカラムを作り直すことの影響範囲の大きさたるや ◦
user_idとorder_idという名前を残さなかった理由 ▪ データユーザーに対してしれっと変更すべきではないと考えた ▪ 対応漏れがあった時にエラーが出て気づけるようにしたかった • やったこと ◦ 粛々とやるしかない、これはやるしかない直面した困難

©2023 10X, Inc. 困難2: 既存の業務に支障が出る場面がある • 課題 ◦ コネクテッドシートのクエリでエラーが出るようになる ◦
小売企業のオペレーションにどうしても必要な生 id が存在する ◦ push 対象の user_id を抽出できなくなる • やったこと ◦ 本当に生の id が必要な場面なのか、 join key として必要なだけなのかを切り分ける ◦ push に必要な要件は洗い出して push のためのテーブルとして切り出す ▪ 仮名加工情報は本人の連絡に使えないため ◦ 社内のアクセス権限の見直し ▪ push のテーブルにアクセスできる人は？開発者向けのレイヤーにアクセスできる人は？直面した困難

©2023 10X, Inc. 困難2: 既存の業務に支障が出る場面がある • 意識した点 ◦ 影響が出る点を 100%
漏れなく洗い出して対応しきるのは不可能と一定諦める ◦ 絶対に漏れてほしくないオペレーションや、テーブルはビジネスユーザーから声をあげてもらうしかない ◦ 「声をあげてもらったものは絶対対応するから、この日までに絶対教えて、後から言われて業務に支障が出るのは皆さんの責任になるからね」と声を上げて自分ごと化してもらう ◦ オペレーション上クリティカルそうに思われるものはこちらから声をかけつつ、基本は上記のスタンスをとる直面した困難

©2023 10X, Inc. 課題3: data vaultの前の世代の分析基盤も運用していた • どんな分析基盤か? ◦ 一般的なdimensional
modeling ◦ dim/factを用いてmartを作る ◦ 共通化するロジックがあれば intermidiateで共通化する直面した困難

©2023 10X, Inc. 課題3: data vaultの前の世代の分析基盤も運用していた • やったこと ◦ 可能な限り小売企業に出しているダッシュボードは消すコミュニケーション
◦ その後爆弾処理班のような気持ちでリネージを一本一本ハッシュ化 • 根本課題 ◦ レイヤーの責務分離を行えていなかった ◦ レイヤーの依存ルールの制定が行えていなかった • 根本対応 ◦ この世代の分析基盤自体を撤退 (予定) 直面した困難

©2023 10X, Inc. 何が挑戦だったか • この組織規模で仮名加工化を行うこと ◦ 利便性とガバナンスは一定トレードオフの関係を持っている ◦ データ活用のアジリティを保ちながら不必要なリスクを低減させること
• 法的な要件を満たしたながらも現実的な運用ができること ◦ 分析基盤の中身を最初からハッシュ化してしまうという考えもあったが、生の id が必要な場面もある ◦ 細かい部分で法的な解釈が不安になることもある ▪ 世古先生に相談しながら進めさせていただきました挑戦と学び https://www.leact.law/case/10x

©2023 10X, Inc. 何が学びだったか • レイヤードアーキテクチャを意識することの大切さ ◦ dim/fact を用いて mart
を作るのは一般的だが、 dim/fact は mart の開発にも、データユーザーのデータ分析にも使われることを改めて認識する必要がある ◦ 同一のレイヤーの参照が増えたり、後ろのレイヤーのモデルを前のレイヤーが参照することによりリファクタリングの難しさが格段にあがる ◦ dbt はここのソリューションを提供していないし、 data vault を使っても business vault のなかでリネージ迷宮が生まれることは簡単に起きてしまう ◦ チーム全体でこの点を認識することが重要挑戦と学び

©2023 10X, Inc. 何が学びだったか • レイヤードアーキテクチャを意識することの大切さ ◦ dim/factを用いてmartを作るのは一般的だが、 dim/factはmartの開発にも、データユーザーのデータ分析にも使われることを改めて認識する必要がある
◦ 同一のレイヤーの参照が増えたり、後ろのレイヤーのモデルを前のレイヤーが参照することによりリファクタリングの難しさが格段にあがる ◦ dbt はここのソリューションを提供していないし、 data vault を使っても business vault のなかでリネージ迷宮が生まれることは簡単に起きてしまう ◦ チーム全体でこの点を認識することが重要挑戦と学び

©2023 10X, Inc. いつも心に置いておきたいこと • 現在負債と感じるものは先人たちが考えたベストプラクティス ◦ このプロジェクトや、先のプロジェクト (metabase から
Tableau への移行)でたくさんの負債と向き合った1年ちょいだった ◦ なんでこんな作りにしたんだと怒るのは簡単だが、常にリスペクトを持って取り組むことを意識 ◦ 現時点で自分が思う最適な設計を将来のチームに渡す気持ちで行う ▪ しかし、将来の自分が過去の自分にキレてるかもしれない ◦ 少なくともここ半年はずっとレイヤードアーキテクチャの責務を考えている ◦ リファクタリングはずっと必要だろうから、リファクタリングしやすい基盤こそが最強に近いものだと考える挑戦と学び

仮名加工化の実践 データ分析基盤における挑戦と学び

仮名加工化の実践 データ分析基盤における挑戦と学び

More Decks by tenajima

Featured

Transcript

仮名加工化の実践データ分析基盤における挑戦と学び

仮名加工化の実践データ分析基盤における挑戦と学び