安定と刺激の間で生きたい。

データ分析の日常を淡々と描いた物です。

本日開催された「Data Platform Meetup#1」に参加しました。

data-platform-meetup.connpass.com

全体を通した所感

  • データ基盤ではなく、データプラットフォーム(Data Platform = DP)という表現かっこいいので、使っていこう。
  • DPアーキテクトの基本構成は、Google BigQueryと、Cloud Composer(Airflow)。
  • DPテーブルの基本構成は、Data Lake(DL), Data WareHouse(DWH), DataMart(DM)の3層構造。
  • DPを使いこなす上では、人の巻き込み方、組織体制が重要。
    • 利用状況モニタリング、依頼チケットのリードタイム計測など、施策PDCAの考え方も使える。

挨拶

  • 平野さん
    • データ分析チームのマネジャー
    • データアナリスト、データ周りすべてを担当

趣旨説明

  • 取り扱いテーマ

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

    • Rettyのデータ分析チームは2年目。
      • 現在は、データ活用の拡大のために、DMの開発など。
    • 近年のデータ系勉強会については、組織やアーキテクト、機械学習的な話が多く、DWHなどのData Platformの話題が少ないという課題感があった。
    • そのため、ノウハウが社内に閉じていて、もっと議論をしたいということで、エウレカさんの鉄元さんと話をして、共感を得て、開催に至った。

所感

  • 初めてのData Platform系MeetUpじゃないか?ということで、データアナリストやデータエンジニアにとって非常に貴重会であったと思う。

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

speakerdeck.com

内容

  • データにまつわる課題

    • データが汚すぎ、パイプライン、ワークフローが長すぎ。
  • kagglerの時間対応割合のアンケート

    • 時間の50%をクレンジングなどデータの準備だけに時間を使っている。
  • Retty

    • 4000万人が利用。
    • 2017年にデータ分析チームが発足。
    • 2017/11時点で月4000 -> 2019/08で月46000にクエリの数が増大。
  • ポイント

    • 大事にしていることは、価値のデリバリ
    • データが生む価値とは?データだけでは価値をうまない。データは(共通認識のための)言語である。そして、RettyではUser Happyを目指す。
    • Platformを作る上で、カルチャーとエンジニアのギャップをうまく繋ぐのが大事。
    • Platfromのスコープは、カルチャーとエンジニアをサイエンス、デザインでつなぐ。
    • 事例
      • 安易な(職務スコープの)サイロ化は良くない。
      • データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。
      • ドメインを持つ人が最前線で開発するのが重要。

質問

  • Q: DWHを分析者のスコープだと思うが、データエンジニアのスコープはどこまでか?

    • A: 自動化ツール、例えばテストを簡単に書けるようにする。そのようなツールを提供して分析者に手離れしてもらう。
  • Q:どういうデータを揃えておくか?

    • A: どういうキーワードで流入してくるか?、サイト内アクセスなど。データ分析者が欲しいというものは、基本全部とる。

所感

  • 「データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。」
    • DPについては、データアナリストをスクラムのPOやPMに据えるのは正しいと思う。

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

speakerdeck.com

内容

  • ターゲット

    • データは入れたけど、データ基盤をどう進化させていけば良いか困っているデータアナリスト。
  • コメント

    • データを疎通したデータアナリストは、素晴らしい!
    • イシュー駆動して欲しい。
  • 質問に答えていくスタイル

    • 中間テーブルを作るとき
      • キー情報をそぎ落とすと。。。元の意味が知りたい場合に大変。(idが違うのに同じ属性値など)
      • データ利用者と中間テーブル利用率が重要。
      • アナリストが作ったが、使われないテーブルが多い。
        • 利用者のPVとUUで可視化すると良い。パレート図で可視化するSQLを資料に公開!
    • 権限管理
      • Read Onlyの本番用スキーマと自由に加工可能なSandboxスキーマを提供。
      • クラウドサービスに権限管理のTipsがある(GCP)。
      • 権限はTerraformで管理すると良い。サンプルも資料に公開!
    • 処理の遅延
      • 途中で継ぎ足されたテーブルなどで処理が遅くなっていく
    • データ未更新、データが落ちている
      • PythonSQLをラップしてunittestでチェック実行。
      • メタテーブルで更新の正常監視。
    • 不整合データをどこで吸収するか
      • ETLでクレンジングだけでは足りない。勇気を持って、開発担当者などにFBを返そう。
    • 擬似的に履歴データを作りたい
      • 日次バッチでスナップショットを取る、できれば、プロダクト側で履歴を持つのが良い。
      • 法令的に残っていることが必要な場合が多い。
    • 中間テーブルの作成はKPIから効果をブレイクしていく。

質問

  • Q: 履歴を持つデータの設計のベタープラクティス
  • Q: DWH/DMなどの過去訴求が、大変かつユーザー影響があるけど、どうやるのが良いか?
    • A: A/B面作戦で、まずは_tempを作り、データ移行した後に切り替えるのが良い。

所感

  • 明日から使える、DPトリビアだらけ。ひたすら感謝。
  • DPの利用状況モニタリング、クエリのテスト方法やメタテーブルによる欠損の監視など、もう一度読み込みたい。
    • 参考文献も豊富なので、隙がない。

鉄本 環さん:「DataPlatform構築プロジェクト推進の事例と学び」

speakerdeck.com

内容

  • エウレカアーキテクチャ

    • BigQueryとComposer。
    • Data Lakeの役割はDWHの可能性を拡げること。
    • DataWareHouseが要。前処理工程を減らす。時差計算、非正規化など。
      • 日付分割パーティション
      • TimeStampの罠、二重に時差を考慮してしまう。 DATETIME型に直しておくと良い。
    • DMは、誰でも触れる環境。
      • 誰でもわかる命名が大事。
  • エウレカのData Platformチーム

    • BIを起点に、Data Platformチームを作る。
    • BIメンバーが開拓した活用データを仕組み化していく仕事。
  • DPプロジェクト立ち上げ

    • データ活用の理想から全体像を描く。
      • AsIs-ToBeを作って、ギャップをRoadMapに落とし込む。
    • 対象データのスコープを決める。
      • チケット対応のリードタイムを可視化して、重要度とリードタイムの幅を見て、データ基盤を整備するか判断する。
    • データパイプライン構築のスコープ

      • SREも巻き込む。
    • 体制の作り方

      • フェーズごとに他チームを巻き込む。
        • 基盤構築段階でSRE, 活用基盤構築時点でPM。
      • スクラムを組んで対応している、POもいる。
      • Data Platformは長期目線のプロジェクトなので、現場メンバーは短期目線と長期目線の板ばさみ。
        • プロジェクト専任のBIメンバーを作って、現場の短期ニーズを吸収して、BI内で検討できるようにした。
  • 今後やっていくこと

    • 収集の強化。
    • ログ送信基盤の刷新やログQAの強化。
    • サービス:Pairs Engageの立ち上げ。
      • 用語の定義の徹底、セグメントや指標など。
      • DWHを後回しでDL→DMで速度優先。

質問

  • Q: DPのスクラムオーナーをどうやって見つけるか?
    • A: プロダクトに対する気持ちが強い人が向いている。
  • Q: DPのプロジェクトについてかかった期間
    • A: 半年ほど(すごい早い!)。

所感

  • DPのプロジェクトに立ち上げに関して、アーキテクチャだけでなく、フェーズと体制、動き方とかが体系的に整理されている。
    • これは初めて見た知見でとても参考になった。特にDP構築でスクラムを取り組んでいるのはユニークではないだろうか。(たぶんその方が進めやすい気もする。)

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

  • ガチ広告系データエンジニアからビジネス系データアナリストになっためずらしい経歴の方。

speakerdeck.com

内容

  • 大規模サービスデータの三重苦

    • 広い(多い)、データ量が数十TBなのでBQでも処理が重い、メルカリのJPだけでも1000人体制なので意思疎通が大変。
  • データアナリティクスが活躍する3つの領域

    • お客様の行動・事業進捗の把握、UX計画・効果予測、効果振り返り。
  • メルカリの分析環境

    • 物理
      • 基本生データ全部がBQにある(恵まれている環境だ。。。)
    • 組織
      • 職能(Data Analyst)とプロジェクト(売上、出品者、横断的なUX改善)の掛け算。
    • 思想
      • どの施策を選択するか?、どのお客さんをターゲットにすべきか?などの目的先行でのデータを使った意思決定で進める。
  • 横断モニタリングPRJ

    • 全体をモニタリングする責任者がいなかった。ので、作った。
    • イベントレベルまで詳細なモニタリングダッシュボードを作成。
    • 効果としては、追えていなかった数字が見え、新たな問題を築けた。
  • 誰でも中間テーブル

    • SQLを書けば、アナリストが誰でも中間テーブルをできるようになった。
    • オンボーディング資料を作って、ハンズオンを実施。
    • SQLとDAGスクリプトを書いてPushすれば反映される仕組み。CircleCI経由で。
  • ログ漏れ

    • テスト設計、ログレビューを必須とする。
    • BIチーム内で仮説や検証をダブルチェック。
    • 効果検証フォーマットでチェック。(走る施策多くてレビューが大変そう。。。)
      • ABテストでわからないことを明示しておくのが良い。
  • 今後やりたいこと

    • 元テーブルと、中間テーブルの数値チェック。
    • 体系的なデータマートの整える。など

質問

  • Q: モニタリングは指標が少ない、絞る方が良いのではないか?

    • A: 異常検知や全体的なモニタリングは、カバレッジが重要と思ったので、多い方が良いと思う。
  • Q: 定義したKPIをどう運用していくか?データマート作成が大変そう。

    • A: 常に更新していく方針。更新が多いので、データマートは作成していない。変更があればクエリだけ更新している。Lookerで対応している。

所感

  • 横断モニタリングに関して、全部を見てバランスよく判断するのは、難しいと思う。この取り組みついては、今後も注視したいと感じた。
  • 施策の効果測定のガバナンスを利かす上でも、テスト設計やログ設計や仮説、検証を、レビューする体制を整えたのは、素晴らしい。
    • しかし、同時にBIチームがボトルネックになって、スケールしなくなる気もするけど、どううまく対応しているのだろうか、気になる。

「Bonfire Data Analyst #1」に参加しました。

本日開催された「Bonfire Data Analyst #1」に参加しました。

yj-meetup.connpass.com

全体を通した所感

  • データ活用が進んだ企業でのデータアナリストに求められるスキルは、小難しいツールを使えるという機能面よりは、事業側のKPIにコミットする。または意思決定者に働きかけてアクションさせられるといった、ソフトスキルが重要性が強調されるようになってきているなと感じた。

Yahoo!ショッピングにおける人を動かすためのスキルセット

西村 純 (@jnishimu)さん ◆ ヤフー株式会社 / データアナリスト

speakerdeck.com

内容

  • 環境
  • 以前の課題
    • データアナリスト側
      • 担当者との距離が遠い。
    • PMや企画側
      • データアナリストは何をしてくれるのか?わかりにくい。
      • 分析結果だけでなく、施策まで出して欲しい。
  • 改善後
    • データアナリストが1PJ毎に担当。
  • 改善後に必要なスキル
    • 担当PJの成功のために分析する姿勢。
    • 疑う:依頼された集計をこなすだけでなく、集計がPJにとって必要なのか問う。もっと最適な集計軸を模索する。
    • 提案する:PJに入り込んで、目的に対して、必要な分析軸をデータアナリスト側から提案、さらに施策案も提案する。
    • コミュニケーションの頻度を上げる:担当者とのやりとりを1回→5回/週、結果はすぐにフィードバック。
  • まとめ
    • SQL/BIツールなどのツールの使い方は勉強すれば身につく。PJを成功させるための分析をすることが重要。
    • PJゴールをもとに考えて、依頼された分析・集計を疑う。むしろ、分析の提案、施策も提案する。

所感

  • BIツールとしてMicroStrategyを使っているのは珍しい。
  • 従来のデータアナリストは、ツールを使いこなして集計という高度なツールを使いこなして機能を提供するタイプが多かったように感じたが、最近のデータアナリストは企画側に近く、分析を軸に施策やPJと伴奏するという形が求められている。

営業から事業部長まで経験したおじさんがデータアナリストに必要なスキルセットを整理してみた

小川 晋一郎 (@ogawa4216)さん ◆ 株式会社Hakali / 代表取締役

www.slideshare.net

内容

  • リクナビでレコメンド、応募予測に従事していた。
  • かなり過去ではあるが、リクルートのデータ分析チームでは、企画から分析依頼がどんどん飛んできて、筋が悪いものも多く辛かった。
  • データアナリストの辛い評価:営業は売上だけど、分析アウトプットをもって他人に動いてもらわないと成果が見えない。
  • 上記を元に、心穏やかになるためのデータアナリストを考えた。
    • 依頼者に翻弄されにくくなるためのスキルセット
      • 共感してもらえる力、理由は、相手が共感してくれると相手が納得して先に進めてくれるから。
      • 問題設定(ヒアリング・ファシリテート、事業課題/組織課題の構造理解)
      • 問題解決(ツール使う力)
    • 野良データアナリストの単価(なかなかナマナマしい)
      • コンサル会社若手:200万/月
      • ドクター会社一人前(製薬会社と協業して論文を書けるレベル):年収5,000万円〜
      • 施策の効果検証のためにSQLを書くレベル:時給3,000~5,000円
      • 単発のデータ分析(課題整理、KPI設定、簡単な分析手法を使える):30〜50万円/月
  • まとめ
    • データ分析(AI系ではない)はどんどんニーズは増えている。DWHはあるけど、どう使うか?分析するのか?が見えていない企業もある。
    • コンサル稼業は単価をどう上げるべきか?労働集約、頭を使うので3件が限界。

所感

  • データアナリストは、単純にツールを使いこなせるというよりは、コミュニケーションや共感力などソフトスキルが重要。
  • データアナリストの力の発揮しどころは、事業/組織の全体像について関係者と議論しながら、全体像モデルを更新続ける、インタビューを元に課題を整理などを行う。数理モデルというよりは、ビジネスモデル(業務フロー)を元にコンサルや事業企画としてやる側面が強くなっていきそうに感じた。

メルカリのアナリストのスキルセット

松田 慎太郎さん ◆ 株式会社メルカリ / データアナリスト

www.slideshare.net

内容

  • メルカリでのデータアナリストの仕事
    • 松田さん自身は、Marketing/Growth/CSと広い関係者と仕事。
    • メルカリのデータアナリストは、分析の考え方を考える事を大事にしている。
    • データアナリストチームは、個々のPJ/Teamの中に入り込む分散体制。
    • 目的を持ったもの(例:売上上げる!)をプロジェクトといい、各人はAnalystとして各PJにアサインされる。
    • 意思決定者とコミュニケーションが多い。
    • 分析テーマとしては、事前と事後、マクロとミクロの2軸で、事業計画、施策シミュレーション、主要指標モニタリング、施策効果分析などがある。(この整理は良かったので、UPされたらもう一度見たい。)メルカリのデータアナリストは”事前:何かをやる前の方針策定”に重きを置いている。
    • 結局、メルカリのアナリストのスキルセットとは?
      • 評価項目とほぼイコール。
        • 問題を探す力
        • 問題を定義
        • 定量化するスキル
        • 伝える力
        • 影響力
        • 信頼感
  • 松田さんが考えるしばらく職にあぶれなさそうな、データアナリストとは?(他の職能との掛け合わせ)
    • データの民主化に伴って施策事後の分析は、データアナリストからPMが行うようになっていくだろう。
    • 例えば、離脱した人の分析などデータが存在しない場合に対して、UX観点での分析ができる。
    • データアナリストやPMが使いやすいデータを届けられる、データユーザーのニーズを理解したデータパイプラインを作れるエンジニア。
    • KPIを事業計画を落とし込める、上位意思決定者とグリップできるビジネスプランナー。
    • 定義がふわふわしているアナリストを会社に価値を定義してまとめられるアナリストマネジャー。
    • 機械学習をプロダクトに活かして落とし込めるPM。

所感

  • データアナリスト概論を受講しているような体系化された内容。
  • メルカリのようにデータアナリスト文化が進んだ企業に対して、多くの企業ではデータアナリスト像がまだ確定していないので、単純にメルカリの事例やフレームワークを持ち込むと、ギャップが生まれて機能は難しいだろうと感じた。自社のデータ分析スキルフェーズに応じて取り入れた方が良さそう。

スキルのコモディティ化の波を乗り切るには?

田中 祐介さん ◆ ヤフー株式会社 / データアナリスト

www.slideshare.net

内容

  • 課題設定力以外はコモディティ化していく
  • コモディティ化を避けるためには?
    • プロダクト/サービスのゴールを残したまま、ゲームのルールを超えて考えられる、局所解を超えて考えられる。
    • 自社のデータ分析に関して弱い部分を見つける。
    • 上記を実現すべく、最新技術などの情報を幅広く集める。

所感

  • 課題設定力以外はコモディティ化していくという表現がすごくしっくりきた。
  • メルカリやヤフーなど、データ分析が強い企業では、ツールが使える<課題設定、ソフトスキルというような価値観になりつつある現状を理解できた。

勉強会のブログアウトプット、今回初めて取り組んでみたけど、書き漏らしたり間違って理解していることもあるので、この辺りは今後もアウトプットを続けながら改善したい。