事業に貢献するデータ基盤を作ろう・考え方編 / data_engineering_study_2

Data Engineering Study #2「データ収集基盤とデータ整備のこれまでとこれから」https://forkwell.connpass.com/event/182769/

作成者 ：しんゆう＠データ分析とインテリジェンス
Twitter：https://twitter.com/data_analyst_

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