【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. まとめ
いかがでしたでしょうか？
ゴールは達成できましたか？
エンジニアの血と汗と涙の結晶たるシステムですが、
それが運用に乗った後も、冒険は続いていくんですね〜
上流に行くにつれて往々にしてプログラミングからは離れることになってしまいますが
ユーザーのすぐ横で働けて、すぐお礼が聞けて、とてもやりがいのある仕事と思います。
興味があったら是非チャレンジしてみてください。
皆様メリークリスマス！ 良いお年を！