Data Engineering Study #2「データ収集基盤とデータ整備のこれまでとこれから」https://forkwell.connpass.com/event/182769/
作成者 ：しんゆう＠データ分析とインテリジェンス Twitter：https://twitter.com/data_analyst_
事業に貢献するデータ基盤を作ろう考え方編2020/08/19 Data Engineering Study #2しんゆう ＠data_analyst_
View Slide
注意点• 全て発表開始時点における私見です後日（あるいは発表中に）意見が変わっているかもしれませんがご了承ください• データ整備への理解が広まることへの直接の利害関係者です発表者は本文中に出てくるデータ整備を中心に業務を行っており、データ整備への認識が広まることで利益を得る立場にあります。中立性はできる限り保持するよう考察していますが、バイアスがかかっていたりポジショントークになっている可能性は捨てきれないことは留意してください• 本日の資料はアップロード済みですhttps://speakerdeck.com/shinu/data-engineering-study-2 note・Twitterからもリンクがあります• アーカイブは終了後すぐに公開される予定です
• ビックデータやデータサイエンティストから始まったデータ活用は当初は利用することだけが意識されていたが、近年になりデータを生成して集める仕組みであるデータ基盤に注目が集まりつつある• そこで事業に貢献するデータ基盤を作るためにはどうするのが良いのかの考え方についての基本をまとめた• 姉妹編である「技術編」については他の人が書いてくれると思います今日の話の前置き
自己紹介• しんゆう ＠data_analyst_• フリーランスでデータに関する仕事をあれこれ• 最近主にやっていること：データを使いやすくする人• ブログ『データ分析とインテリジェンス』noteに移行：https://note.com/shinu• 『データアーキテクト（データ整備人）を”前向きに”考える会』主催 #前向きデータ整備人
本日のお話• 何のためにデータ基盤を作るのか• 価値のない基盤を作らないようにしよう• 基盤と利用のバランスをとろう• 基盤と利用の間にはどんな役割があるか• 整備は別の役割として認識しよう• もし整備をしなかったらどうなるか• まとめ：データ基盤と整備のこれからの論点
• 「どんなデータ基盤を作るか」は話題になりやすい一方、「何のためにデータ基盤を作るか」はあまり語られない（気がしている）• あたりまえだからなのかもしれないが、そうではないかもしれないので改めて書いてみる• データの活用はデータ分析プロセスを中心に考えるのがよく、その中でデータ基盤がどういった役割を担っているのかを見てみることにする何のためにデータ基盤を作るのか
• データ分析は目的の決定から始まる一連のプロセスデータ分析は一連のプロセス目的の決定要求 収集 処理 洞察 伝達決定と実行フィードバック
• その中で「収集」フェーズで行うこと収集は必要なデータを集めるフェーズ目的の決定要求 収集 処理 洞察 伝達決定と実行フィードバック• 知りたいことのために必要なデータを集めるフェーズ• 欲しいと思ってからでは間に合わない（例えばログ）こともあるので、事前に準備をしておく必要がある• 準備とは具体的にはタグやセンサーなどを設置してデータを生成したり、集めて保管しておくための仕組み作り
• その中で「収集」フェーズで行うこと収集は必要なデータを集めるフェーズ目的の決定要求 収集 処理 洞察 伝達決定と実行フィードバック• 知りたいことのために必要なデータを集めるフェーズ• 欲しいと思ってからでは間に合わない（例えばログ）こともあるので、事前に準備をしておく必要がある• 準備とは具体的にはタグやセンサーなどを設置してデータを生成したり、集めて保管しておくための仕組み作り ＝ データ基盤
データ基盤とは収集のための仕組み• データ基盤とは、データ分析プロセスにおいて収集フェーズを速やかにかつ正確に行うための仕組みのこと• ただしどの範囲まで「基盤」と呼ぶかは人によるので注意• データ基盤を作る上では次のことを意識しておきたい
良いデータ基盤が無いと意思決定に影響が出る• データ基盤とは、データ分析プロセスにおいて収集フェーズを速やかにかつ正確に行うための仕組みのこと• ただしどの範囲まで「基盤」と呼ぶかは人によるので注意• データ基盤を作る上では次のことを意識しておきたい• プロセスなので良いデータ基盤が整っていないと後が続かない＝ 意思決定が遅くなったり質が落ちる
使われないデータ基盤に価値はない• データ基盤とは、データ分析プロセスにおいて収集フェーズを速やかにかつ正確に行うための仕組みのこと• ただしどの範囲まで「基盤」と呼ぶかは人によるので注意• データ基盤を作る上では次のことを意識しておきたい• プロセスなので良いデータ基盤が整っていないと後が続かない＝ 意思決定が遅くなったり質が落ちる• データ基盤は意思決定に使われて初めて価値に繋がる＝ 使われないデータ基盤に価値はない
• 価値のないデータ基盤を作らないためにはどうしたらいいのかなぜニーズを満たせなかったのかを考える
• 価値のないデータ基盤を作らないためにはどうしたらいいのか• 「せっかくデータ基盤を作ったのに使われない」は問いが違うなぜニーズを満たせなかったのかを考える
• 価値のないデータ基盤を作らないためにはどうしたらいいのか• 「せっかくデータ基盤を作ったのに使われない」は問いが違う• 問うべきは「なぜ利用者のニーズを満たせなかったのか」ではないか• ニーズにあってないのに基盤だけ作っても使われないのは当然なのでとりあえず作ってもダメ（例：ダッシュボード）なぜニーズを満たせなかったのかを考える
• ニーズを聞いていないのならまずは基盤を作るのではなく何が知りたいのかを掴むことことから始める• ニーズはあったのにうまく聞けていなかった、なら改善の余地はあるが、そもそもニーズがない、つまり意思決定にデータを使う気が無いのであれば、基盤作りよりも先にやることがあるまずは何が知りたいのかを掴むこと
• データ活用は一連のプロセスなので• ニーズを捉えることができてもデータ基盤作りとその後の利用（処理・洞察・意思決定）のバランスが悪いとうまく機能しない• ただ、何事もそうだが最初からうまくバランスをとってやるのは難しい。いままでどうなっているかをざっくり見てみると基盤と利用のどちらに偏り過ぎてもだめ目的の決定要求 収集 処理 洞察 伝達決定と実行フィードバック
• 利用先行型• 最初は「まず使ってみよう」から入るのは自然な流れであり、実際にそうなっていた• データ基盤は無くてもPOSや会員情報などのデータはある。しかしデータの準備が大変• いろいろ手続きをしてシステムの人に頼んででかいＣＳＶファイルを何日、時にはそれ以上待って抽出してもらうとか利用先行になるのは自然な流れ利用
• 基盤先行型• よりよく利用するためには基盤がないといけない、と動きが本格化してきたのがこの２年くらい（早いところだと２０１５年頃？）• ところが、基盤を作ることが目的化して利用することとは別になってしまい作っても使われない問題が発生• 作って終りで使われなくても（少なくとも短期的には）仕事になってしまうので利用につなげるモチベーションが少ないのかも基盤作りが目的化してしまう傾向利用基盤
• バランス型• 解決するには基盤と利用をバランスよくやっていくこと• 基盤と利用が個別に扱われがちなので広い視野を持つ• 概念としてはそうなのだが、都合よく人が集まるわけでもなければ両方適度にできる人はもっといない• こうすればいい、という明確な答えは無くともどういったモデルが考えられるかは組織含めて今後の大きな課題の１つ基盤と活用はバランスよく利用基盤
• ところで、この間になんとなく誰かがやっていることありません？• ここまで「基盤」や「利用」という言葉を曖昧に使っていたのでもう少し具体的に何をしているかを考えてみる基盤作りと利用の間にある役割ありません？利用基盤基盤
収集されたデータはこの３つのどこかにあるデータレイクデータウェアハウスデータマートデータの３層構造• 収集されたデータは３層構造のどこかに格納されている• データレイクは生データ• データウェアハウスは統合して整理したもの• データマートは特定の目的のためということにはなっているが線引きはわりとあいまい（特に後者２つ）
データは処理・洞察を経て意思決定に使われるデータレイクデータウェアハウスデータマート処理洞察処理・洞察を経て意思決定へ• 収集されたデータは処理・洞察を経て最終的に意思決定に使われることで始めて価値になる• データ分析プロセスを部分的に抜き出したものであり流れは同じ意思決定
基盤作りはデータレイクに入れるまでが中心データレイクデータウェアハウスデータマート処理洞察基盤はデータレイクに入れるところ• 基盤を作るという話はデータレイクに入れるところまでが中心• タグやセンサーを設置してデータを生成したり、集めたデータをバッチ処理・ETLで処理する• ちゃんと動いているかの監視や権限・コスト周りの運用• アーキテクチャにはDWHやDMも含まれるがあまり踏み込まない意思決定
利用とはすでにあるデータを扱うことデータレイクデータウェアハウスデータマート処理洞察利用とはすでにあるデータを扱う• データを集計したりモデリングしたり、なぜそうなるかを考えたりするプロセスの処理・洞察フェーズ• 「分析」というとここだけを指すこともよくある• すでにデータが存在していてそこからどうするかが主題意思決定
基盤と利用の間が抜けがちになるデータレイクデータウェアハウスデータマート処理洞察基盤と利用の間にある役割とは• 基盤と利用は話題になるがその間にある役割が抜けがち• 具体的にどういったことをしているかを見てみると意思決定
間にある役割は大きく分けて３種類データレイクデータウェアハウスデータマート処理洞察間にある役割は３種類• 基盤と利用の間にある役割を拾ってみると大きく分けて次の３種類• ① 必要なデータを作って利用する人へ渡す• ② ①が速やかに出来るようにDWHやDMを設計・作成して整理• ③ データの追加や修正の企画・設計。基盤を作る人とのコミュニケーション意思決定①②③
「データ整備」と命名データレイクデータウェアハウスデータマート処理洞察「データ整備」と呼ぶことにする• 名前が無いと何かと不便なのでこのあたりの役割を「データ整備」と呼ぶことにする• 基盤作りや利用との境目は明確にできない（例えばメタデータ・集計）• 「整備」は「基盤」と同様にどこまでを指しているかお互いの認識を合わせること意思決定
データ整備は何となくできる人がやっているデータレイクデータウェアハウスデータマート処理洞察基盤＋整備か整備＋利用が多い• 分担があいまいなので、できる人が何となくやっている• 整備は技術よりも段取りとコミュニケーションの比重が高く、エンジニアは避ける傾向• 利用する側がやると整備ばかりになって不満が溜まりがち• マネージャーやマーケターなどがやるとスキル不足で大変意思決定
データ整備は貧乏くじになってはいけないデータレイクデータウェアハウスデータマート処理洞察やらないわけにはいかない• 整備を誰もやらないとまともにデータが使えなくなるのでやらないわけにはいかない• しかし基盤や利用とはやることもスキルも違う上にろくに評価もされず貧乏くじ扱いで押し付け合い• この状態が続くのはデータ活用にとって不幸でしかない意思決定
データ整備は１つの別の役割として認識しようデータレイクデータウェアハウスデータマート処理洞察主張：他とは違う役割と認識しよう• そこでデータ整備は別の役割として認識するのがよい• 兼任することはありえるとしても、別の役割として認識することで違うことをやっていることが伝わる• 求人などでも利用〇割、整備〇割のように伝えることでギャップをかなり埋められる意思決定
• 整備を担当する人をデータアーキテクト、またはデータ整備人と呼んでいる• データアーキテクト（データ整備人）だからこれをやる、あれはやらないという話ではなく大体このあたりの仕事をする人、ぐらいがちょうどいい• まず最初に他とは違う役割がそこにある、ということの認識を持ってもらうところから始める整備する人はデータアーキテクト（データ整備人）
データの流れ（再掲）データレイクデータウェアハウスデータマート処理洞察データの流れを料理に例えてみる• 直接関係している人以外にも整備が何をしているのか知っておいてもらった方がいい• ただし「整備をやらないと大変なことになる」だけだと伝わりづらい• 料理の流れに例えるのがよさそう意思決定
データの流れと料理の流れは一致するデータレイクデータウェアハウスデータマート処理洞察意思決定倉庫卸売小売店下ごしらえと調理味付食べる
基盤作りは生産者データレイクデータウェアハウスデータマート処理洞察意思決定倉庫卸売小売店下ごしらえと調理味付食べる基盤作りは苗を植えて育てたり魚を捕ったりすること
利用は調理することデータレイクデータウェアハウスデータマート処理洞察意思決定倉庫卸売小売店下ごしらえと調理味付食べる利用とは調理をすることにあたる。自分で食べる場合もあれば料理人が提供する場合もある
データ整備は中間業者データレイクデータウェアハウスデータマート処理洞察意思決定倉庫卸売小売店下ごしらえと調理味付食べる「データを整備」とは物流や中間事業者担っているのと同じ
• 整備を魚の場合に例えてみると• スーパーでは生魚そのままで並ぶこともあれば、途中で加工されてサクになったり刺身になったり、つみれになったり• 調理する人が何を作りたいかや能力に応じて選ぶ• アジフライを作りたい人に「たたきがおいしいから」と加工してから渡しても使われないアジフライを作りたい人にたたきを勧めてもダメデータ 料理 魚の場合データウェアハウス 卸売 市場データマート 小売店 スーパー
物流や中間加工業が無かったら料理は大変データレイク処理洞察意思決定倉庫下ごしらえと調理味付食べるもし物流や中間加工業が存在しないと必要になったら農家や漁港まで出かけて食材を手に入れて、まったくの生の素材から加工も全部自分でやらなければならない
整備しなかったら毎回生データを扱うことになるデータレイク処理洞察意思決定倉庫下ごしらえと調理味付食べるデータの整備をやらないと、使おうとするたびに毎回生データを加工しながらデータを作っていく。クエリも長く複雑になるし、元データが変更されるとその都度改修が必要になる
• つまり、データの整備をしないとデータがまともに使えない• ということがちゃんと伝わっていなかったら力不足なので教えてください。他の方法を考えます整備をしないとデータがまともに使えない
• 最後に、今後こういうことも考えていかないとね、という話をして発表を終わりにする• ここから先は未知の領域なので論点だけ。重要度と順番は関係ないが、その中でも最初に議題になりそうなのは↓• 基盤と整備と利用のバランスはどうとったらいいのかデータ活用は基盤と利用と整備のどこか１つでも大きく欠けると他も機能しなくなるのでバランスよく行うのが大事。ではバランスが取れているとはどういう状態で、どうやって評価するか。バランスが取れていないとしたら足りないところを埋めるのか、余っているところから補填するのかデータ基盤と整備のこれからの論点
• 成長に柔軟に対応できる基盤の作り方プロダクトの改修、成長で頻繁に変化していくのを見越したデータ基盤をどう作っていくか。特に初期段階において最低限必要なデータ基盤は何か• 基盤を統合するのか、個別に作って整備でまとめるのか自社他プロダクトの新規開発、他サービスとの統合などが起きた時に１つの基盤に統合するのがよいのか、プロダクトなどの単位で別に持っておいて整備で取りまとめるのが良いのか、あるいはプロダクトごとで切り離しておいて共通ルールの適用を徹底させるのが良いのか• 組織と役割分担基盤・整備・利用の組織を１つにまとめるのかいくつかに分けるのか。データアーキテクト（データ整備人）は別の役割として認識するのが良いのか、わけないでエンジニアやアナリストのどちらかの仕事に組み込むべきか• データ基盤・整備の重要性の啓蒙少ない関係者の中だけでとどまらず、あらゆる人（特に経営者層）には基盤や整備の重要性を理解してもらう必要があるデータ基盤と整備のこれからの論点
• データ基盤・整備の貢献を説明する事業の中で基盤や整備がどれだけ貢献しているのかを説明する努力はしなければならないが、いくらの利益を生んだのかを数値にすることができるのか、できなければどう説明するか• 人材の育成、採用、キャリア長期的に考えた場合企業はどのようなキャリアを提示できるか。マネジメントなのか特定分野のスペシャリストか他領域との組み合わせなのか。この分野で仕事をしていこうとする側にはどういった選択肢があるのか• 収集フェーズの中での位置付け実は収集フェーズはもっと広い領域で〇 データマネジメント特にガバナンスや情報セキュリティ領域も合わせて考えるべき〇 Webやデジタルだけなく紙・画像・音声・動画なども対象であり特性に合わせた収集や管理が必要〇 情報・データを読み解くメディアリテラシーを持ち認知バイアスを回避しないと収集は失敗する〇 収集や保管の際の法的、倫理的な制約と解決方法の考案といったことまで基盤作りや整備を行う上では考えていかねばならないデータ基盤と整備のこれからの論点
• データ基盤・整備の考え方の基本について一通り話した• データ活用はまだまだ始まったばかりであり、データ基盤・整備もこれからが本番。みんなで議論して盛り上げていきましょうデータ基盤・整備はこれからが本番質問・疑問などお気軽にご連絡くださいしんゆう＠データ分析とインテリジェンスTwitter ： ＠data_analyst_
shinu
ynishiuchi
xmile
route06
srmarketing
kuradashi
baystream
junki
takeshisumida_
jobs_progrit
dowanna6
caitiem20
dougneiner
zenorocha
bkeepers
holman
sachag
searls
chriscoyier
gr2m
malarkey
productmarketing