はじめに
過去にデータの可視化やデータエンジニアリングについて以下のような記事を書いてきました。
1.データの可視化は健康診断
2.「はじめての分析」で見落としがちなポイント
3.「はじめての分析」で見落としがちなポイント②
4. データの品質について考える
5.データレイヤーと内製化
2023年の9月～12月にかけて、海外カンファレンス2つを含めた多数のカンファレンスに参加しました。
その中で匿名化やガバナンスといったキーワードが時折挙げられており、思うところがあったので記事にしました。
DXの成熟とガバナンス
企業のDXの成熟度が低いうちは、スピード感・早期の成功事例の創出が重要なポイントになります。
別に大きな成功でなくて構いませんが、事業部門を巻き込んだ成功体験であることが大事かなと思います。
一方で成熟度が高まってくるとともに重要になってくるのがガバナンスです。
成熟度が高まっているということは取り組みが全社規模にスケールしているということですからこれは当然の話かなと思います。
ガバナンスはどうしてもスピード感とトレードオフになりがちですから、これから成熟度をあげていこうという企業にとっては悩みの種です。
ガバナンスのための最低限の枠組みをまとめることで「スピードを落とすことなく成功事例の創出ができる（だけど後になって困らない）」のではないかと考え、所属会社においていつくかのサービスを立ち上げたりもしました。
ガバナンス関連では、データの品質について考えるという記事を以前に書きました。
これは品質を保つという観点でのガバナンスですね。
今回はデータの取扱い（セキュリティ）の観点でのガバナンスについて触れたいと思います。
参考にしたのは経済産業省と総務省が策定したDX時代における企業のプライバシーガバナンスガイドブックです。
なお、マネジメントという言葉とガバナンスという言葉はコンテキストによって使われ方がまちまちです。
本記事の内容はガバナンスなのか？とも思うのですが、参考文献にあわせてガバナンスとしています。
ファイブセーフモデルによる データガバナンスのフレームワーク
ファイブセーフモデルは、イギリスの統計局（ONS）において、機密情報を利用した研究を規律するために2003年から運用されてきたフレームワークで、現在はEU全域で、統計の個票データ活用時の安全対策ルールとして広く採用されています。
内容については以下です。抜粋しているというよりは、ほぼこの表に集約されています。
(出典：DX時代における企業のプライバシーガバナンスガイドブック)
これをデータ利活用基盤に適用すると、以下のイメージになります。
(出典：DX時代における企業のプライバシーガバナンスガイドブック)
たとえばデータ利活用基盤によくある要件で、「情報を匿名化してほしい」というものがあります。
匿名化を入口要件に対応させようとしているのか、出口要件に対応させようとしているかで論点が変わってきます。
匿名化という言葉に反応しDWHなどが持つデータマスキングなどの機能で対応させようとしてしまう例もありますが、
DWHのデータマスキングは基本的に出口要件を実装するための機能です。
本当にその実装が適切かどうか、入口/出口どちらの要件に対応させようとしているのかを考えるようにしましょう。
入口要件は、 データの種類に応じて定義する
そもそも利活用基盤に蓄積していいものか、蓄積するとしてどこまで加工するか（匿名化する、除去するなど）というのが論点になります。
法的要件や企業の方針、システムの位置づけへの適合性をもとに判断することになります。
個人情報はこう、とか、業務トランザクションはこう、とか決めていくイメージですね。
入口要件で匿名化が必要な場合は、基盤自体に匿名化の機能を持たせてしまっては実現ができないケースもありますから（個人情報はクラウドに出してはダメなど）、外付けのような形でエコシステム化するアプローチが視野に入ってきます。
私の所属会社にはDataSpider Servistaという製品がありますが、こういったオンプレミスで動作するETL製品を導入することはひとつの選択肢ですね。
出口要件は、基本的にはプロジェクト（利用目的・用途）と人（利用者）に応じて定義する
たとえば、BI表示用であればどう、だとか、社内のこのロールは、グループ企業社員は、という形で定義していきます。
従って出口要件で匿名化する場合は、きめ細かく設定が必要な場合もあります。
出口要件での匿名化は基盤内にインクルードされるケースが多いです。
DWHにおけるデータマスキングなどは出口要件の実装に利用されることは既に書きましたが、DWHやBIが持つ行レベルセキュリティもこの用途で利用されます。
基盤自体は入口要件/出口要件への適合性の他に、アクセス制御やセキュリティ(アクセス元の制限)、証跡のモニタリングに関する機能が必要となります。
まとめると以下のような形になります。
このような枠組みで整理することで、データの取り扱いに関するルールの制定やワークフローの整備にも繋げることができます。
繰り返しになりますが、この考え方はデータ分析基盤以外にも適用できるものだと思います。
データにまつわるサービスを具現化する際の整理の一助にもなるかなと思って書いていますので、ぜひそういった機会があればこの記事を思い出していただければ幸いです。
今回の記事は以上になります。
最後まで読んでいただきありがとうございました。