固有ID周りが怪しい企業がやってみるとよさそうなこと

固有ID周りが怪しい企業は以下のような対応を順番にしてみるのがいいんじゃないかなと。本当は「プライバシー周り」って書きたかったけど一部固有IDにフォーカスしすぎてるしプライバシーだと足りないところがあったので「固有ID周り」限定にした。
ちなみに先のエントリとは違って端末固有IDではなく固有ID。分かりにくいね。

手順

  • 手順1:全社員に高木さんのブログとtwitterアカウントをフォローさせる
  • 手順2:会社としての大方針を作成する
  • 手順3:社内で固有IDを使っているユースケースを洗い出す
  • 手順4:手順3で洗い出したユースケースを後述の「固有ID利用ユースケースの分類」で分類する
    • このとき、現時点での分類と要件を鑑みて再精査した分類に分ける(「今は全アプリ共通のID取ってるけど自アプリに閉じたIDでいいはずだよね」とか)。
    • 「本当にそのスコープで情報が欲しいの?」「本当に欲しいならそれはビジネスとして妥当なの?」という検証をすべてに適用する必要がある。
  • 手順5:分類した結果単位で対応を検討する
    • 「固有ID利用ユースケースの分類」にも少し記載あり。「DRMなどは業界的にソリューションないから説明/同意のうえで取得だよね」「お問い合わせ用の情報は説明/同意のうえで取得だよね」とか。
    • 基本的には「うちは手を出せないよね」というの以外でIMEI/UDID的なものを使っている個所についてはUUIDベース(注:UDIDじゃないよ)での処理を検討し、どうしてもダメそうなら個別に思案ということになるかなと。
  • 手順6:上記大方針や対応を全社的に周知徹底する

固有ID利用ユースケースの分類

固有ID利用ユースケースは要件ごとに以下で分類してみるといいかも。

  • 当該要素の生存期間
    • 取得開始のタイミングと破棄のタイミング。
    • 「○日間」などが知りたい訳ではなくタイミングが重要(規約同意のタイミングなどとの兼ね合いがある)。
  • 当該要素の通知範囲
    • どの範囲までが当該要素を知っている必要があるのか。
    • 「端末内だけ」とか「自サービス内だけ」とか「自社内だけ」とか「アライアンス内だけ」とか。
  • 当該要素の同定レベル
    • 当該要素でどこまで特定できればよいのか。
    • 「アクションAとアクションBが同じ人らしいことが分かればよい」(経路分析など)とか「自然人としての個人が特定できなければならない」(お問い合わせ用の電話番号など)とか。
  • 当該要素取得要件の発生元
    • 当該要素を何故取らなければならないのか。
    • 「本来とらなくてもよいがとっている」(一般に改善すべき点)とか「自社が提供する機構上必要」(ビジネス自体を見直す必要がある)とか「他社が提供する機構上必要」(DRM等業界としてソリューションがない場合などは説明したうえで取得)とか。