JICS2014レポート(1) 1/14前編

2014/01/14に学術総合センターで行われたJICS2014に行ってきました。当日取ったメモを公開します。間違いや発言意図と違うなどありましたらご指摘お願いします。

ビッグデータとアイデンティティ

城田真琴さん
  • ビッグデータ=ビッグリスク?
    • 企業のビッグデータへの取り組み状況
      • 日米英独中の中では日本の取り組みが遅れている。中国は「すでに」「試験的に」を加えると50%超え。日本は10%未満
  • ビッグデータリスクの事例
    • 事例1: Target(米、大手スーパーマーケットチェーン)の例
    • 購売行動に合ったクーポンを送っている
      • 毎年4月に水着を購入する顧客 → 7月に日焼け止め、12月にダイエット本
      • 女子高生に妊婦向けクーポン → 「高校生に妊娠を勧めるのか!」とクレーム → 実際に妊娠していた
      • sensitiveな情報をなんでも把握してもいいのか、さらにクーポンを送ってもいいのかと物義をかもした
      • ここから学べること: 法にふれないからと言って何でもしていいのか
        • 消費者の気持ちを推し量るべき
        • Target自体はプライバシー/コンプライアンスに対して保守的な企業であった
        • 購売履歴と関係ないクーポンを混入させるように工夫
        • 法令遵守は必要条件であって十分条件ではない、顧客の信頼を得ることが重要
    • 事例2: フロリダのDisney World「MyMagic+」
    • RFIDの入ったMagicBand(リストバンド): ホテルのルームキー、チケットとして機能
    • 相当の個人情報、プライバシー情報を収集している
      • 事前にWebで全員の名前、誕生日、ファストパス希望情報を入力
      • 入園後、売店で何を買ったか、どのアトラクションで遊んだか、位置情報、待ち時間、ミッキーと握手をしたか(ミニーか)などの情報を収集
    • 利用者のメリット
      • 好きなキャラクターが建前を読んでくれる
      • アトラクション、レストランの予約ができるFastPass+
    • 学ぶべきこと
      • サービス開始に際に収集する情報の内容・目的・オプトアウト方法・第三者提供の有無、動作の仕組などをFAQとして詳しく公開している → 利用の有無は利用者にゆだねる
        • 透明性を確保することが重要
  • ビッグデータ活用の高度化に向けた事業者側の狙い
    • 現在: 自前で収集したデータの活用
    • 次のステップ: 他社データの利用
    • 自社(単一)→自社(複数)→他社(単一)→他社(複数)
      • 右に行くほど、得られる価値も大きいがリスクも大きくなっていく
    • 目指すのはあらゆるチャネルからのデータを活用した真のCostomer 360degree view
      • お客様のことをもっとよく知りたい → その人に最適なサービスを提供・推奨できます
    • 困難を極めるマルチデバイス時代の消費者行動の全体像の把握
    • ポータルサイトとの連携
      • O2O online2offline: ネットとリアルの消費者行動の結びつけ
      • Y!J + CCC / Y!J + SAISON
      • 事例: Y!J + SAISON
        • Y!ロコでキープ(お気に入り) → そのお店で買物 → クレジットカード情報とY!IDをひもづけると2000ポイント
        • 本当に買物をしたかどうか、クレジットカードの決済履歴でわかる
      • 事例: Amex「Link, Like, Love」
        • クレジットカード番号とFBアカウントのひもづけ
        • いいね!、4sq チェックイン → クーポン券(Amexカードで決済したら15%引など)
  • 参考) インセンティブの違いによる個人情報の提供許容度
    • ハードルが低い: 年齢、性別、居住エリア
    • ハードルが高い: 電話帳情報、友人知人の連絡先、FBなどSNSのID
  • 事例
  • 活用の進展
         自社データ       他社データ
 ネット  Web              Web Giant(G, FB, Y!)
         ↑↓        //
 リアル  リアル店舗  ←→ ポイントカード業者(CCC, ロイヤリティーマーケティング等)
  • ビッグデータ活用の高度化に向けた法規則動向
    • EU 「オプトインでないと勝手に収集してはいけない」
      • 2012/5 クッキー法: 事前に同意を得ないとクッキーを出してはいけない
    • 米 「プライバシー憲章」
      • クッキーのオプトアウトサイト: どんな情報を収集して何に使うのか書いている
      • 透明性を担保
    • Do Not Trackを使ってブラウザによる意志表示
      • 広告会社がちゃんと自主規則してくれるか → 業界まかせ
      • CA州 オンラインプライバシー保護法(CalOPPA)
        • DNTに対する対応方法をちゃんと書かないとUSD2500の罰金
        • 例: LinkedIn: 使わない、DNTも使わない
        • trackingしてるなら「してる」と正直に書け、という法律
    • 将来像
      • 消費者本人が自分のデータを管理し、提供先を選択
      • 自分のデータを電子データとしてダウンロード → パーソナルデータストア → 提供したいところを選んで提供
      • 英: midata、米: Smart Disclosure、日: 情報銀行??
    • 行動トラッキングに対する受容性
    • パーソナルデータの利活用に関するWG
  • まとめ
    • 事業者の狙い: customer 360度view　　　　　　 ←┓
    • 消費者は常にトラッキングされることを好まない ←┛ ギャップ
    • 将来的には英米のように自分でコントロールできるようになっていく
Pat Patterson 「Identity in the Cloud」
  • Pat Patterson@Salesforce @metadaddy
  • Safe Harbor
    • salesforceのプレゼンのときに必ず見せている。今日の講演の情報を元にSFの株を買わないでね、という内容
  • Identityのこれまでの問題: 会社の中で従業員のアクセス管理
    • 社内、firewallのみ
      • 財務情報は関係する社員だけが扱える、社員が必要な情報にアクセスできる、など
      • わかりやすい世界だった
    • いまは、社内ネットの外からのアクセスが必要
      • 今日この会場から社内ネットにアクセスした人、挙手! → 20人くらい / 200人くらい
    • IT部門もID技術を連携して社外からのアプリ使用を行えるようになってきた
      • アプリはインターネットの外にあるので、firewallだけ心配していればよいという時代は終わった
      • 企業によってはインタネットも社内も信頼度(level of trust)は変わらないところもある
      • 多くの企業が協業しているパートナーとデータ(の少なくとも一部)を共有する必要がある
      • IDを持っているのは人間だけではない。製品もAPIをアクセスする
      • ID数は社員数よりオーダーが違ってくる
      • many apps, many access, from any of locations in the world
  • Solutions?
    • identity platform: salesforceの設計思想を紹介
      • cloud-based
        • 2014現在、起業しようとするときにサーバーやCRMを買う必要はない。ID管理のためのサーバーを買うなんて考えられない
      • interoperability
        • たった1社のみのアプリを使うとは考えられない
      • mobile-enabled
        • モバイルが一番のアクセス元になるはず
      • internet scale
        • millions of customers, partners, devices: 社員数とは桁が違う
      • single point of control (一元管理)
      • Webの民社化
        • 規模を問わず、あらゆる企業が利用可能(大手企業だけがID管理できるのがこれまでの世界)
      • core application platform
        • identityはアドオンではなくコア
  • SFの相互運用性に関する戦略
    • マルチテナントシステム → 標準化がキー戦略
    • SSOの標準は依然としてSAML2.0
    • OAuth 2.0: APIに対して安全なアクセス
      • SAMLと協調して動く必要がある
      • モバイルアプリはOAuth2を使ってAPIアクセス
      • 例: ユーザーログインは企業内でIdPを使ってログインする → SAMLと連動してトークンを送る必要がある
    • SAMLは古くなった。XMLベースなのでintegrationが難しい
    • → そこでOpenID Connectだ
      • OAuth2と親和性がよく、新しいアプリから使いやすい
  • Internet scale
  • SF ID Platformを絵にすると
    • central control of identity and policies
    • 中小企業の場合、リポジトリとして扱うことができる
      • 大手ならADやLDAPかも。SAMLを使ってplatformに持ち込める
      • SFではADからのintegrationはカンタン
    • G+, FBからのidentityを持ち込むこともできる
    • 顧客コミュニティーにとってはすでに持っているIDの活用が重要
    • いったんSF identity controlに加えれば、社員/パートナーがアクセス可能
    • identity platformがSFのコアにある。SF上の行動はすべてID platformによってgovernされる
  • クラウドの中核にはidentityがある
    • デモ: SF岡本さん
    • グーグルIDでログイン → OpenID Connectを使っている
      • IDトークン内のemailで突合してログインさせるデモとなっている
      • 連携の取り消しもできる
    • 社外パートナーからのアクセス: ポータルIDを発行しケース(問合せ対応)データだけを見せることが可能
      • FBアカウントとポータルIDをひもづけ
      • FBアカウントはnative APIとして登録
    • Salesforce IdPを他のRPと連携させて使うとも可能