【Data Management】暴走するデータ利活用への楔
はじめに
この記事は、シアトルコンサルティング株式会社 Advent Calendar 2021の23日目の記事です。
今年も残すところあと数日になりましたね！
お正月休みに向けてラストスパート！張り切っていきましょう！
５Ｇ（マネジメント）- 山口チームのＴＬを担当させて頂いている山口です(* ᴗ ᴗ)⁾⁾
今回はちょっと技術系から少し外れて、知らない人向けに「Data Management」という概念についてお話しようと思います。
ゴール
Data Managementという考え方があるんだな〜
データ利活用が人を傷つけたりしないように歯止めをかける考え方なんだな〜
というのが伝われば良いかなと思っています(* ᴗ ᴗ)⁾⁾
(ちなみに、Data Management自体が、歴史の浅いものなので、色々な考え方があります。私の一意見と思っていただければ幸いです)
目次
-
Hadoop Clusterという概念
- 企業がデカくなるとデータもデカくなる
- BIG DATAを取り扱う為のコロンブスの卵
- Hadoopのメリット・デメリット
-
暴走するデータ利活用
- 企業がデカくなると野望もデカくなる
- 無尽蔵に広がるアイディア（活用例）
- 個人情報は守らなきゃね
- 喧嘩しないようにしないとね
- 忘れちゃならない人の道
-
Data Managementの役割
- Data Managementとは何か？
-
守りたいものってなに？
- Need to Knowな権限管理
- MECEな責任の所在
- Fool Proofな暴走をどこで捉えるか
- 法律やセキュリティのお話
- Globalなお話
- まとめ
1. Hadoop Clusterという概念
Data Managementのお話をするにあたり、まずはHadoop Clusterという概念について知る必要があります。
1-1. 企業がデカくなるとデータもデカくなる
まず、今回お話するのは、グループ会社や子会社、果ては兄弟会社なんかもいる巨大企業グループで取り扱うデータのお話です。いわゆるBIG DATAと呼ばれるものです。
ちょっとしたシステムのログですら1日あたりペタを超えます。
ログ以外にも様々な顧客データや決済情報などなど、、総量は天文学的な数字になります。
それでも、基本はそれぞれの会社で管理するので、取り扱うのにソコソコのサーバーで問題ありません。
しかし巨大企業グループ全体のデータを1つのBIG DATAとして扱うのであれば、すべてのデータを1つのサーバーに集めなければなりません。果たしてそんな化け物ツヨツヨサーバー、どうしたらいいのでしょうか？
1-2. BIG DATAを取り扱う為のコロンブスの卵
皆さんが大量のデータを一つのＤＢに格納しようと思い、手持ちのサーバーでは容量が足らないときどうしますか？
普通に考えると、そのサーバーを強化しますよね。もしくは外付けＨＤＤにでもデータを退避させるでしょうか。(根本的な解決にはなりませんが）
しかし、サーバーの強化はある一定の数値(容量や計算力)を超えるととんでもない金額になっていきます。とてもじゃないですが、そんなツヨツヨサーバーを買うのは現実的ではありません。ソコソコサーバーでも十分高い。
さて、そんな中、１つのツヨツヨサーバーにかかる費用で、大量のソコソコサーバーが買えることに気づいた人がいました。
その人は考えました。
「ソコソコサーバーを繋ぎ合わせて１つのツヨツヨサーバーのように使えばBIG DATAに耐えきれるぞ」
(たぶん、その為に考え出された訳ではないですが、ご容赦ください）
そう、これがHadoop Clusterです。
前述した「ある一定の数値」のギリギリのサーバーを大量に繋ぎ合わせ、１つの超高性能なサーバー(DB)に見立てて扱うことです。
某コロナで一気に知名度が上がった「クラスター」という言葉と同じ「クラスター」です。アレは「発生源」という意味ではなく、「集団」「群れ」という意味なんですね。
1-3. Hadoopのメリット・デメリット
低コストかつ、超容量であることはわかったけど、他にはどんな特性があるか確認していきましょう。
◆メリット
まず、容量を増やすことが、安価かつ容易であること。（スケーラビリティ）
Clusterとは複数のサーバーの集合体ですので、そのClusterに使用される台数を増やすことだけで良いからです。
次に、回復力が高いこと。
万が一、１つのサーバが死んでも、代わりをすぐに用意できること。
理由はスケーラビリティと同じです。
最後に、扱えるデータの種類、扱い方が多様であること。（分散ファイルシステム）
SQLを使用し、いわゆるDB LIKEに扱えるHadoopですが、
Hadoopはあくまで、サーバーなので、ORACLE やMySQLのようなRDBではなく、ただのファイルシステムです。
WindowsでいうExplorer、MacでいうFinderみたいな普通にDirectoryという考え方が管理されるものになります。
その為、String、Intなどのいわゆるデータだけでなく、TextやCSV,TSVファイル、Jarファイルなんかも格納することができます。
また、DB LIKEに扱うために、「このDirectory階層は"DB"と呼ぼう、その下の階層を"Table"と呼ぼう」と決めるだけなので、"Table"の配下にさらに"Table"的な分割がされていきます。それをPartitionと呼び、その分け方は無限大です。
◆デメリット
遅い。いわゆるDBと比べ、とにかく遅いです。(対象としているデータが膨大なので当然っちゃ当然ですが)
1つのサーバーとして取り扱う、とはいうものの、結局大量のサーバーの集合体なので、目当てのデータがどのサーバーにあるかを探さないといけません。
場所取る。それはもうめっちゃ場所取ります。(ビル数階が全部サーバールームとか)
余談ですが、某仮想コインのマイナーたちはこのClusterの技術を使って計算しているらしく、巨大な土地にサーバーを大量においているんだとか。
電気代がすごい。
大量のサーバーを動かすので電気代がすごい。
熱もすごいので空調代もすごい。
ま、いろんな意味でカネがあるところでしか使えないシロモノってことですね。
さて、次の章では、
そんなHadoop Clusterを有効活用しようとする人たち=Data Science、Data Analysisとその問題点について話していきます。(* ᴗ ᴗ)⁾⁾
2. 暴走するデータ利活用
ここからはHadoop Clusterを準備して、そこにデータを格納しました人たちが次に何をするのか、というお話です。
2-1. 企業がデカくなると野望もデカくなる
企業がデカくなると野望もデカくなります。
一つ一つのServiceでも十分な売上を上げていても、もっとできることがないか!?と考えちゃうのが人の世の常ですね。
そこで、このClusterに格納したBIG DATAをどう扱うのか、というのが「データ利活用」にです。
テストに出るので覚えておいてください。
2-2. 無尽蔵に広がるアイディア（活用例）
例えば、某クレジットカード会社では、クレジットカードを使った人にポイントを付与して、そのポイントが使えるマーケットを用意しました。
このとき、そのままであれば、ポイントはそこで使われて終わりです。
データ利活用という考え方では、このポイントをもっと別のことでも使えるようにしたら、もっとこのクレジットカードを使ってくれる人が増えないかと考えます。
あくまで一例ですが、
ポイントが貯まる一方で使わない人を抽出して、その人達に向けて「ポイントを現金のように投資に使ってみないか！？」と広告を出したり、
その広告を受けてポイント運用を始めた人達に向けて「本当に投資やってみない！？」と広告を出したりです。
そんなデータ分析→データ利活用→その結果をさらに分析→データ利活用、という貪欲なサイクルの中で、無尽蔵なアイディアが世界を席巻しています。
ちょっとマイナスイメージな言葉を使っていますが
もちろんデータ利活用をすることは良いことです。1つより2つ、2つより3つを合わせることで、それは足し算ではなく掛け算となり、イノベーションを巻き起こします。
しかし、新しいこと、というのは既存のルールの外であることが多々あります。データ利活用もその一つであると言えるでしょう。
ルールの外で暴れまくるイノベーションは人を傷つけてしまうことがあります。
ということで、いよいよ本題、Data Managementについてです。
2-3. 個人情報は守らなきゃね
まず、真っ先に問題視されるのが個人情報です。
当然ですね。企業を信用して個人情報を渡しているのに、それを勝手にグループ会社間で共有されて、しかもそれデータ利活用に使用されるなんて、Userからしたら「聞いてない！」「ふざけんな！」ってなりますよね。
でも、この個人情報という考え方は、Data Managementという考え方においては、一般的な個人情報より大きく、かつ、厳格に捉えます。
例えばこんな事例があったとします。
全国展開するチケット販売を行うServiceが、アイドルイベントを運営しているServiceの登録情報を利活用し、
その中から東京に住む人をターゲットにしてコンサートチケットの訴求をした。
これはいかがでしょうか？
そう、Data Management的にはアウトです。
Data Managementでは「東京に住んでいること」、これは個人情報と捉えます。
兎にも角にも、万が一にも個人を特定できてはいけない。
訴求をする場面でも、可能な限り、ランダムに選択されたターゲットでなければならないのです。
このように個人情報が漏れないよう、「どのようなターゲットについて、どのようなことを使用としているのか」を常に監視ししています。
2-4. 喧嘩しないようにしないとね
例えばこんな事例があったとします。
Userにアンケートを取るServiceが◯◯ビール社より、「◯◯ビールが好きかどうか」というアンケートを取りました。
クーポンを配布するServiceが、△△ビール社からの依頼で、その「◯◯ビールが好き」と答えたUserを利活用し、そのUserをターゲットにして「△△ビール無料クーポン」を配った。
これは完全に利益相反取引に該当します。
◯◯ビール社からの依頼で得た情報を、△△ビール社の利益の為に使用しています。
絶対にダメ、ＮＧです！！
このように「どこから得た情報をどこの為に使おうとしているのか」も常に監視しなければなりません。
2-5. 忘れちゃならない人の道
個人情報、利益相反取引、は暴走するデータ利活用の最たる例ですが
気づきにくいレアものＮＧ例を一つあげておきましょう。
例えばこんな事例があったとします。
マッチングアプリに登録している既婚者に、不倫マンガの広告を表示する。
確かに、興味あ・・・・ってオイッΣ ・・・・ってなりますよね。
これは商道徳的にアウトです。
こんな商売ばかりしていたらUserさんは離れてしまいます。
(第一、全部バレてると思うと夜も眠れませんよね)
大げさな例えをしましたが、
誰が、何に怒るかなんてわからないので、「これは誰かが怒り得ないか？」と常に監視する必要があります。
3. Data Managementの役割
さてはて、Data Managementが、実際にどのような観点でデータ利活用の暴走を食い止めているか語ってきました。
ゴールに定めた
Data Managementという考え方があるんだな〜
データ利活用が人を傷つけたりしないように歯止めをかける考え方なんだな〜
というところはクリアできましたでしょうか？
最後にもう少し本質的なお話をしてこの場は〆させていただきたいと思います。
3-1. Data Managementとは何か？
Data Managementをもう少しだけ掘り下げていきます。
少しめんどくさい内容になってきますのでここで終わりでもＯＫです。
中〆とさせていただきますね。ヨーォッシアトルゥッ！
3-2. 守りたいものってなに？
データ利活用(Data Science, Data Analysis)が、攻めだとするならば
Data Managementは、守りです。
では、Data Managementが守りたいものってなんだっけ・・というお話です。
3-2-1. Need to Knowな権限管理
Need to Know これは「必要な分だけ知る」という考え方です。
BIG DATAの中には、膨大な量、膨大な種類のデータがあります。
それらすべてを、誰でも使えるようにしていたら、前述した観点でのチェックは不可能です。とてもチェックしきれません。
まずは、目的に沿ったデータの権限しかUserに与えないこと。そこから始まります。
見えてはいけない人に、見せてはいけないデータは見せない、これがNeed to Knowです。
3-2-2. MECEな責任の所在
MECEとは、「Mutually Exclusive, Collectively Exhaustive」の略で、「モレなく、ダブりなく」という意味です。ミーシーや、ミッシーと読みます。
Data Managementを行う上で、
データそれぞれに、誰に使わせて良いのか、誰に使わせてはいけないのか、それはなぜか、という理由を考えなければいけません。
しつこいようですが、BIG DATAには、膨大な量、膨大な種類のデータがあります。その為、Data Managerが理由を考えることは不可能です。
Data Managerは、データそれぞれのOwner(責任者)に対し、説明を求め、整理を行うことを主とします。
しかし、その責任者がいない、または複数いるとどうでしょうか。
Data Managerは誰に説明を求めればいいのかわからず、結果、Managementが破綻します。
そのデータは「データ利活用不可」の凍結資産となります。
それを回避するべく、データにはそれぞれ、MECEな責任の所在を明らかにしておく必要がある、ということです。
3-2-3. Fool Proofな暴走をどこで捉えるか
Fool Proofとは、日本語でいうと「対愚か者仕様」ですね。
お化粧をする方にはわかりやすかもしれませんが、耐水仕様こと、Water ProofのProofです。Foolは愚者ですね。
要は、悪いことをしようとしてなくても、うっかり悪いことをしてしまう、ようなことがないようにしよう、という思想です。
Fool Proofの観点から、BIG DATAへの権限管理は、まず厳格に設定しておき、そこから緩めていくという手法を取った方が良いとされています。
これは、Data Managementとは、漏れのないルールを作る仕事である、という風に言い換えられるかもしれません。
Userの動きをすべて監視することは不可能です。
では、どこでFool Proofな暴走を捉えるか。
「章2 暴走するデータ利活用」で、ＮＧ例に挙げさせて頂いたものの共通はわかりますでしょうか？
答えは「グループ会社から見て外部に迷惑がかかること」です。
言い換えると「利活用したデータが外部に出ていく時」です。
ここです。このタイミングが、最後の砦であり、ベストタイミングではないかと思います。
(これは特に色々な意見があると思いますがご容赦ください)
外部に出ていくところで、「本当にそれってやっていいの？」と刺すことで、Fool Proofとなりえるでしょう。
3-2-4. 法律やセキュリティのお話
ここまで「本当にそれやっていいの？」というのをベースに話して来ましたが
ここでは「そもそもやっちゃだめ！」というレベルの話をします。
要はルール違反ですね。国の。
やろうとしていることが法律に違反しているとか、セキュリティのガイドラインに則っていないとか、論外なものがあります。
3-2-5. Globalなお話
国のルール違反は、問答無用でアウトです。
ただし、BIG DATAがGlobalなデータである場合、これがとてもややこしくなります。
なぜなら、国によってルールもまた違うからです。
Ａ国では良いことが、Ｂ国ではダメ、などはザラです。
そのあたりの取りまとめ、落とし所を考えるのもData Managementの責務の一つといえるでしょう。
(特に金融関係は、どこも独自のルールがあり大変です)
これ以上は、ちょっと重い話になるので、割愛します。
興味があったら直接聞いてください笑
4. まとめ
いかがでしたでしょうか？
ゴールは達成できましたか？
エンジニアの血と汗と涙の結晶たるシステムですが、
それが運用に乗った後も、冒険は続いていくんですね〜
上流に行くにつれて往々にしてプログラミングからは離れることになってしまいますが
ユーザーのすぐ横で働けて、すぐお礼が聞けて、とてもやりがいのある仕事と思います。
興味があったら是非チャレンジしてみてください。
皆様メリークリスマス！ 良いお年を！