見出し画像

[イベントレポート]Data Platform Meetup

インターネット広告の会社で自社プラットフォームのグロースハッカーをしている岡部と申します。

グロースハッカーといいながらも最近は収集したデータを処理して、DASHBOARDにまとめるデータエンジニア的な業務や、DASHBOARDのデザインをより使いやすいものに改良していくUXデザイナー的な業務領域が増えてきました。
自分の業務でBIツールとして主に使っているのが「Google データポータル」です。最近結構データポータルのコンポーネントが増えてきたり、デベロッパプレビューではありますが自作のコンポーネントが作れるような機能が出てきたりしてきたので、DASHBOARDを全体的にアップデートできそうだと感じて、何かこの領域の勉強会的なのないかな〜とconnpassで探していたところ、ちょうどこちらの「Data Platform Meetup」を見つけたので参加しました。そちらのイベントレポートをnoteに纏めました。

各セッション毎に見出しをつけてますので、参加目的やData Platform Meetupの概要等を端折りたい方は、目次から直接そちらにジャンプ可能です。

参加した目的

まえがきでも若干触れましたが、現在自分はGoogleデータポータルを使って収集したデータを処理して営業戦略に活かせるようなデータエンジニアリングを行ってます。収集されたデータを処理して、データポータルに入れこめるような形にし、データポータル内で可視化するという一連の業務を担ってます。
データ収集をはじめてから1年くらい経ち、データも結構溜まってきたところで、社内での公開範囲も広くなった頃「今のままのDASHBOARDじゃ見る人がお目当てのデータを見つけづらいな」と感じました。Googleデータポータル自体巷で無料で使えるがかゆいところには手が届かないと言われているので、仕方が無いなと諦めていた部分もあるのですが、GoogleCloudNext'19で聞いた、テレビ東京のデータエンジニアの方のセッションで、結構力技でも実現できることがあるということに感化され、Googleデータポータル周りのことを調べ始めました。

Googleデータポータルの新機能のリリースを見ていると、月2〜3回程度アップデートがあり、DASHBOARDを作った1年前と比較するとかなり多くの新機能、特にグラフやツリーマップ等のコンポーネントが増えていることが分かりました。ということでDASHBOARDをより使いやすいものを一新しようと思い、他の会社のデータ周りの扱い方や考え方を知りたいと思った矢先に、このイベントを発見しました。

このイベントに参加するにあたって得たかった事は大きく以下3つです。
①データハングリー・データの民主化についての考え方とその実践方法
②データエンジニアではないデータ利用者サイドの要望や活用実績等に基づいた改善事例
③UXの部分

今回のイベント的に③はもしあればという感じだったので、多くは語られませんでしたが、①②についてはかなり多くのインサイトを得ることが出来ました。

Data Platform Meetupの概要

Data Platform Meetupとは

自社のデータプラットフォームを設計/開発/利用している方(データエンジニア/データアナリスト/データサイエンティスト/機械学習エンジニア等)がノウハウを発表したりカジュアルに情報交換できるイベントです。

・DWHの設計〜活用(データレイク・データウェアハウス・データマート)
・データ活用にに関わる組織・仕組みの設計(データアナリストとデータエンジニアの役割分担など)
・BIツールの設計・利用方法
・分析に関する品質担保(ダッシュボードの品質・冪等性の担保など)
・運用を見据えた管理・統制(権限設定・マスキングなど)

といったようなことが語られるイベントです。
当初は30人程度でゆる〜く語り合う予定だったそうですが、イベント公開初日で定員オーバーという予想を超える参加申込があったため、急遽増枠して100人規模のイベントとなったようです。

参加対象

・事業会社でデータ分析・データ基盤業務に携わる方
・データ基盤の運用もしくは開発への経験や興味がある方

懇親会でも何名かの参加者の方とお話しましたが、「アナリスト」や「エンジニア」「データ○○」といった肩書を持った人が多く、当たり前といえば当たり前ですがデータをいじる人が多かったです。
自分はどちらかというと、フロントに近いデータ周りに触れる機会が最近は多かったですが、参加者はより深い部分に日常的に触れている人が多かったという印象です。

データについての基礎知識

今回のセッションの中でデータ加工のフェーズについての用語が出てくることが多かったので、おさらいしておきます。人によって解釈の違いがあるかもしれませんが、一応今回自分が理解した内容です。

●データレイク(Data Lake)
データレイクは、規模にかかわらず、すべての構造化データと非構造化データを保存できる一元化されたリポジトリです。データをそのままの形で保存できるため、データを構造化しておく必要がありません。また、ダッシュボードや可視化、ビッグデータ処理、リアルタイム分析、機械学習など、さまざまなタイプの分析を実行し、的確な意思決定に役立てることができます。
(引用元)https://aws.amazon.com/jp/big-data/datalakes-and-analytics/what-is-a-data-lake/

⇒データレイクは一旦構造化されている/いないに関わらず、色々なところにあるデータをそのまま流し込んで蓄積しているところです。データレイクではどんなデータが価値のあるデータとなり得るのかこの段階では分からないので、どんなデータでも集約させます。つまり元データママの状態のもの。

●データウェアハウス(Data Ware House)
データウェアハウスとは、企業などの業務上発生した取引記録などのデータを時系列に保管したデータベース。また、そのようなシステムを構築・運用するためのソフトウェア。「ウェアハウス」(warehouse)は「倉庫」の意。
(引用元)http://e-words.jp/w/データウェアハウス.html

⇒DWHはデータを分析したい人がSQL等を叩けばデータが取れる状態になっているものです。データレイクの状態だと何がどこにあるのか分からない状態なのですが、DWHではどの情報がどこにあるのかは分かる状態になっています。つまりデータにドメイン情報を反映したもの。

●データマート(Data Mart)
データマートとは、企業などで情報システムに記録・蓄積されたデータから、利用部門や用途、目的などに応じて必要なものだけを抽出、集計し、利用しやすい形に格納したデータベースのこと。「マート」(mart)は「小売店」の意。
(引用元)http://e-words.jp/w/データマート.html

⇒データマートはDWHを特定の目的や用途のために加工したものといって良いと思います。DWHをある目的のために狭めてカスタマイズしたものと自分は捉えています。つまり特定目的・用途向けに加工したもの。

その他詳しい説明は、今回のイベントの登壇者でもあるyuzutas0さんのブログが個人的に分かりやすかったので、紹介させていただきます。


以下各セッションのまとめです。

「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」(Retty 竹野 峻輔さん)

個人的には登壇者の竹野さんが自分と同じ高専生ということが嬉しかったです。(高専生って世の中に少ない分、同志を見つけると嬉しくなるという高専生あるある)
基本的には上記のスライドに発表のすべてがまとまっていますが、これから自分で活かしたいと思ったところを簡単に纏めています。

●データが生む"価値"とは・・・?

Rettyのデータ分析チームのミッションは
・意思決定の最大化
・基盤の仕組みづくり
・データの民主化
の3点とのことですが、それを実現するために大切にしていることは「"価値"のデリバリ」です。

得られたデータにバイアスがかかっていたり、同じデータでも異なる決断が行われることがあるので、データ自体は自然と価値をは生むことはありません。ただし、見る人全てに一つの事実を示す公平なものではあります。

データの一番の"価値"は「データが言語であること」なのです。
英語の価値は世の中の多くの人が英語を話せることにあります。数式の価値は世の中の人が見てすべて同じ解釈がされるということにあります。データもその公平性が価値を発揮する要素の一つです。

そして言語では関心によって新しく言葉が生まれます。例えば遊牧民が多いモンゴルで使われる言葉は、家畜に関する表現が細分化されています。四季が豊かな日本で使われる言葉には四季に関する表現が多いです。(四季に関する表現であまりピントこない人はコチラ。常用はあまりしないけど確かに日本にしか無い表現です。)
そして、データを言語としているプロダクトや組織の関心事は「カルチャー(価値基準)」です。カルチャーがデータの価値を定義します。

但し、カルチャーがデータの価値を決めるとわかったところで「価値のデリバリ」にはつながりません。それらのデータを適切に扱うための「エンジニアリング(実現水準)」が必要です。

そしてこの「カルチャー」と「エンジニアリング」この2つのギャップを「サイエンス」と「デザイン」が埋めます。これがプラットフォームのスコープとなります。

スクリーンショット 2019-09-18 19.57.26

Rettyのプラットフォームとしての取り組みの考え方
①カルチャー(価値基準)とエンジニアリング(実現水準)をつなげる
→ヒト・モノ・コトのつなぎ目に価値が生まれる
②ドメインを持つもの・人がプラットフォームの最前線で開発する
→安易な分割をするとサイロ化を起こす。DWHを「分析者のプロダクト」とするのがRettyでの一つの答え。前線にすべてのノウハウが集まるようにし、そのためのデータの整理・整備を行う

個人的まとめ
・データをつくるだけでは価値は産まない
・組織にデータの価値をデリバリするためにエンジニアリングをする
・デザイン(設計/仕組み化)等を用いて、組織の関心事をより細かく提供できるようなDWHないしデータマートを設計すると良さそう
・ここから必要なことは各自でこうやればデータが取れる、といったデザインではなく組織が必要としているデータそのものを提供できるようなプロダクトデザインとした方が良さそう。

「データレイク構築後の四方山話」(yuzutas0さん)

なんとすごい勢いのある発表でした。スライド見てもらえれば分かるのですが資料はなんと140ページ超え。発表はものすごい速度で進んでいき、中には自分で「なんだこのスライド!?こんなの作った記憶ない」といったスライドもあり会場を盛り上げてました(笑)

このnoteを書くために改めてスライドを見返していたら3ページ目のアジェンダから「こんな内容だったっけ?」と思う程凄まじい走馬灯のような発表でしたが、改めて自分で活かしたい内容まとめました。

●手順書は価値に直結する

スクリーンショット 2019-09-19 11.56.17

※Dev=開発者 Ops=利用者・運用者

自分が作っているデータ基盤も全体的なアップデートが完了次第、Ops向けに手順書を作ろうとしていました。手順書作成って確かに自分がやることを完全に後から見返しても再現できるように作ることを目標に掲げていることが多いのですが、そうなるとDev視点重視になってしまうのでもしかしたら使いづらい手順書となってしまい、データの価値を見いだせなくなってしまうかもしれないので、Ops視点でのGoodのプライオリティを高めたいと思いました。

●DataとOpsをつなげる
当たり前ですが、素晴らしく綺麗な中間テーブルがあっても売上は増えません。一括投資で回収を実感できないデータモデリング設計にするのではなく、必要になった時にその場で改善できるような設計にすることが大切です。
そのためには、継続的改善のカルチャー・プロセスが定着している必要があると感じました。そのような環境であれば失敗は成功の母であると、全員が言える理想的な組織になれると思います。

「データ」と「業務」をつなげる。
「テクノロジー」と「ビジネス現場」をつなげる。
「データを活用すること」で「誰のどんな課題を解決するのか」を問う。

自分が勤めている会社の社長も、世の中のためになるような正しいことを続けていくことでWin-Winをつくることが大切だと言っていたのを思い出しました。データはこの世の「真実」を表し、真実から導き出された行動こそ、Win-Winをつくるために必要なアクションだと考えます。
現場の一人ひとりが主役となって、データを活用してプロダクトや業務をブラッシュアップするという行動の積み重ねが、顧客に本当の価値を届けることの積み重ねになると思います。

スクリーンショット 2019-09-19 18.26.16

データを作ったり、表現したりすることを目的化するのではなくその先に、データを使った人が顧客に価値を生み出すために行動すること、を見据えてデータ基盤を設計していきたいと思いました。

●個人的まとめ
・Devの理想≠Opsの理想
・データを集めたり作ったり意味をもらせるのはDevの仕事だが、そのデータを用いて真の顧客価値を生み出すのはOps側の仕事。(少なくとも自分の組織では)。最終的に価値を生み出すことができることが、データ基盤として一番大事なこと。
・ITの進化が激しいように、その時々で価値を生み出せるデータ基盤になれるように、継続的改善のカルチャー・マインドを定着させることが、価値を生み出せるデータ基盤を作るための近道になると思う。

多分実際にBQやTerraform等を使ってデータをいじっている人とは違う視点かもしれませんが、個人的にはゆずたそさんが例示した失敗例やデータ基盤の設計論を聞いていて、活かせることを纏めました。

「DataPlatform構築プロジェクト推進の事例と学び」(エウレカ 鉄本 環さん)

登壇者の鉄本さんはエウレカのエンジニアの中では一番の古株の方とのこと。マッチングアプリを始めとする恋活はこれからぐんぐん伸びていく市場だと思っており、その中でもペアーズというトップクラスのサービスを運営しているエウレカのデータプラットフォーム構築のプロジェクト推進について特に勉強になりました。

●エウレカにおけるデータプラットフォーム
・データレイクの役割→DWHの可能性を広げること
・DWHの役割→データ活用の下処理の最小化
・データマートの役割→誰でも簡単に正しくデータを使えること

エウレカでは可視化ツールとしてTableauを導入し、なんと全社員が触れる環境を構築しています。データの命名規則も誰もがひと目で分かる形に統一しており、昨今よく耳にする「データの民主化/データハングリー」といった時代にそった構造になっていて、組織として見習いたいポイントだと思いました。

●データプラットフォーム構築プロジェクトの立ち上げの3STEPとプロジェクトの推進について
・立ち上げ

STEP1.データ活用の理想から全体像を描く
ステークホルダー全体から理想を集めてAsIsToBeを明確にして理想をつくる
STEP2.対象データのスコープを決める
→プロジェクト実施に向けた説明とチェックのための定量化データを取り、対象の優先度をステークホルダーと合意することで、開発に集中できる状態をつくる
STEP3.データパイプライン構築のスコープを決める
→価値を考える切り口はDL/DWH/DMで良いが、構築段階では切り口を変える。デリバリのプロとしてSREに参画してもらい、収集/整形/活用のデータパイプライン毎に切り分けることができた。

・推進
チーム構成はスコープに合わせて変化させていける組織にエウレカがなってました。
初期の基盤構築段階でSREを巻き込み長期運用のフォードバックを得る、活用基盤構築でPMを巻き込みデータマートへのフィードバックを得る、さらにそれに加えて必要に応じて人事異動をすることで、データ活用を描いた低レイヤの知識を持ったデータマネジメントに責務をもつSREが誕生し、BIとの架け橋になったとの事例を紹介してました。

プラットフォーム構築の工数を会社として捻出するという判断、プロジェクト立ち上げという時期から他チームのメンバーを含めた多くのステークホルダーを巻き込めるという組織力にはもう脱帽の2文字しか浮かびませんでした。
プロジェクト推進期にやってとかったことでも「柔軟な組織変更が一番効く」ということで、これはもう本当にエウレカの組織力・変化に対応する力の偉大さあってこそだと思いました。

●個人的まとめ
・データの民主化のために、誰もがデータをかんたんに扱うことができる環境を整えること
・全社的に人を巻き込める組織力があると、プロジェクトの立ち上げや推進がうまくいきやすい。できる限り多くのステークホルダーを巻き込むことでそれが実現に近づく。

「大規模サービス開発における分析用データの必要要件」(メルカリ 石田 祥英さん)

最後の発表はメルカリの石田さん。メルカリのBIチームはMercari Engineering Blog等でも紹介されることが多く、自分も時折色々と勉強させていただいております。発表前にうつったデスクトップは何かのスクリーンショットだらけで、何をそんなにスクショを取ったのかという謎は最後まで明かされませんでした(笑)

●メルカリのデータ分析環境
物理環境
生データ全部BQに置いておくからからあとは好きにして!
アグリゲートされたデータではなく、生データをすべてBQから取得できる環境が構築されているとのことです。

組織環境
各機能がチームにアサインされており、チームによって重点項目が異なる

スクリーンショット 2019-09-19 20.22.00

思想
意思決定の目的ありきでデータを活用する
データありきでそのデータを利用するための出口を探すのではなく、「これがしたい」という目的ありきでデータを活用します。

●大規模サービスのデータ三重苦について

スクリーンショット 2019-09-19 20.16.13

データ・アナリティクスが活躍する3つの領域

スクリーンショット 2019-09-19 20.17.07

→どこに三重苦が出現するかまとめると以下のようになります。

スクリーンショット 2019-09-19 20.25.17

●データ三重苦の退治方法

1.広いゆえに見落とす編「あれ?その指標って別なチームがみてるやつでしょ」
全社を横断的にモニタリングする組織がなく、各チームのPM等が自発的に見ていただけだった組織構造であったため、このような問題が生じていました。ダッシュボードの指標や構成等も独自設計で、イベントレベルでの行動モニタリングも行われていなかったため、異常検知への対応も不足している状況でした。
これの解消のために、アナリストチーム内にサービス全体をモニタリングするチームを組成し、イベントレベルまで詳細なダッシュボードを作成しました。ダッシュボード10個に指標が150個ある網羅的なダッシュボードを作成しすることで、KGIを各KPIにMECEに分析してサービス全体のモニタリングを実現しました。

2.重いゆえに遅い編「セグメント切って分析したいけど集計重い」
メルカリでは各チームに目的特化の最適なセグメントを持っていますが、独自のセグメント定義で汎用性の低いクエリが各チーム毎に運用・管理されていたおり、毎回集計したためスピード感が出ていませんでした。
これについてはSQLかけば誰でも中間テーブルを作れるようにすることで解消しました。なんてったってBQには生データがそのまま入ってますからね!
AirFlowを立てて中間テーブルが生成されるスクリプトをテンプレ化し、オンボーディング資料をつくってハンズオンを実施したことで、各チームでセグメント資料とデータセットが作られ、分析粒度の詳細化や透明性が向上しました。

3.混沌故に漏れる編「えっログ埋め込まないでリリースしてたって?えっ」
重要だと思う部分だけテスト設計やログ設計を確認したいたため、施策を出してから後で重要だった部分が見つかること、またテスト設計やログ設計が属人化していて、観点のばらつきが存在している等、カオス故の漏れが点在することがありました。
これは開発フロー自体にテスト設計・ログレビューを必須項目として組み込んだり、テスト設計のフォーマット(効果検証フォーマット)を用意することで解消しました。BI内で数値変動仮説と検証方法のダブルチェックも行いました。(具体的な効果検証は現在進行中とのこと)

●個人的まとめ
・自分の扱うデータ基盤はまだ三重苦が顕著になるほど小規模なものではありますが、いずれは(きっと)大規模になるので、今の段階からこの三重苦の解消方法を意識した組織やデータ基盤を意識することで将来役に立つと思いました。

まとめ

組織環境や持っているプロダクト、担っているミッションや領域は各々違えど、共通しているころは
データが実際に利用されて、実際に何らかの価値を産み出して初めてそのデータやデータ基盤が役にたったといえる状態となる
ということです。
文字にしてみれば至極あたりまえのことなのですが、やはり一番大事でこれを外してしまうと、自己満足のプロダクトで終わってしまう恐れがあるのでデータ基盤を作る際は常に意識し続けようと改めて思いました。

また、データを中心に扱うイベントに初めて参加してみましたが、他のテーマに比較してセッション内で取り上げられていたことを、自社環境で丸々すべて再現することは難しいですが、構築方法や活用方法など援用できる部分はたくさん学べたので、ちょっとずつ活かしていきたいと思いました。

この記事が参加している募集

イベントレポ

この記事が気に入ったらサポートをしてみませんか?