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

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

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

勉強会メモ Data Platform Meetup#2 本日開催された「Data Platform Meetup#2」に参加しました。

data-platform-meetup.connpass.com

全体を通した所感

  • 前半2つのデータ駆動推進、使ってもらえるようにした努力の発表については、泥臭く挑むエンジニア達の姿に感じるものがありました。エンジニアとビジネスサイドという異質の組織間をつなぐ上で発生する場合、人に優しく寄り添うという姿勢の大事さ。
  • 機械学習データの活用事例や、アプリログを効率良く活用するためのFirebaseAnalyticsの活用については、純粋に面白そうなのでやってみたい。

挨拶

内容

  • 挨拶は、Retty平野さん
    • DPMの趣旨
      • 事業会社でDMPを担当してる人がノウハウを発表
      • 開催の背景
        • データレイクが整備されてきた、既存コミュニティで議論されていない内容(DWHの設計など)、課題感が自社内に閉じているのでノウハウの共有の場
  • 会場のご案内は、pixiv高橋さん
    • 本日の会場提供頂いたpixivのデータ駆動推進室の方
    • データ活用をサポート業務を担当

長部 和仁さん:「プロダクト中心のデータ駆動を推進していくために大事なこと」

speakerdeck.com

内容

  • 長部さんの自己紹介
    • データ基盤エンジニアの方
    • データ基盤にpixiv本体しかない状況から、周辺プロダクト(ECサイトなど)含めてデータを含めて集約にご尽力
  • 話すこと
    • データ活用が求められる背景
      • 技術的大きく動いた要素、クラウドDWHと機械学習技術である。
      • 専門職レベルでなくても、機械学習技術を活用できる時代。
      • ピクシブでは、レコメンドでの活用が大きなテーマとなっている。
    • データ活用のための組織構造について
      • 中央集権的な構造と、各部署にデータ活用担当のいる民主化構造に分かれる
        • 中央集権的な場合、分析スキルを持つ人が一つの組織に集まっている。
        • 民主化の場合、各組織の分析したい当事者が分析を行う。それぞれメリデリが分かれる。
    • pixivではどうしたか?
      • 民主化の方を選択した。
      • プロダクトが多く、特有のドメイン知識が多く、中央集権で分析するのは無理があった。
    • 民主化する際の壁
      • 分析スキル:担当者がSQLを覚える必要がある
      • データ理解:開発者視点での謎のデータ構造への理解
      • ガバナンス:それぞれが好きにデータを触れるため、正しくないデータ集計となる可能性
    • pixivのデータ駆動推進室のやったこと
      • 推進室は直接の分析課題を解決せず、現場が解決する。間接的に支援を行う。
      • データ基盤操作のテンプレート化
      • BIツールLookerの導入
      • 互助会機能を充実:analystチャンネル、データエンジニア交流会、分析わくわくタイム
      • チュートリアルリソースの充実
    • 取り組みの結果
      • 機械学習エンジニアに対して、アドホックなデータ集計や分析依頼がこなくなった(素晴らしい!)
    • 現在の課題感
      • 中間テーブルの管理
      • 管理ができない部分の発生
      • 非プロダクトへの適用

質問タイム

  • Q.学習教材の用意は、非エンジニア向けにも提供した?
  • Q.BQは従量課金なので、跳ね上がる可能性もあるがどう抑制しているのか?
    • A.監視はしているが、個人に任せている。悪いクエリを発行した人は呼び出して注意される!
  • Q.推進側のモチベーションの維持ってどうやっているのか?KPIをどう設定している?
    • A.データ利活用の課題意識を持っている人が集まってきた感じ。
  • Q.LookerはLookMLをかけないと使えないが、そのあたりは誰が対応しているのか?

    • A.定義も各部署に開発者がコミットするようにしている。データ推進室がレビューなどを行いデータガバナンスを担保している。
  • 個人的に伺った質問

    • Q.現在の体制までに持ってこれた期間は?
      • A.去年から始めたという感じ。
    • Q.BIツールである程度の要望は対処できるが、BIで汎用化できない集計分析依頼はSQLを使わないと出来ないと思われるが、これを全て各部署で対応できているのか?
      • A.各部署にエンジニアがいるので、その方はSQLは書けるので、そちらで対応してもらっている。

所感

  • データ集計の民主化事例として良かった。(自分で取り組んでいるが、他人に勉強してもらうというのはとても大変。)
  • Looker導入はコストはかかるので、今すぐに真似できるものではない。ただし、テンプレート化、チュートリアルリソース追加、互助機能は真似していけそう。

Hashimoto Yuki さん:「データを用意しただけだと使われないので、使ってもらえるようにした努力」

内容

  • 概要
    • データの流れ
      • ユーザのアプリ、サービスのサーバー → EC2 → Redshift(機械学習用にも使う) → redash
    • DBの状況
      • テーブル700、平日70000クエリ、休日30000クエリ
    • データの種類
      • アクセスログ、イベントログ(DOMイベントなど)、インプレッションログ
  • (データを用意しただけときに)かつて発生していた要望
    • 使い方がわからない、データがわからない
    • 分析の仕方が分からない などなど
  • そこから、エンジニアがポスピタリティを発揮して使ってもらえるようにした施策を紹介
    • ドキュメントを整える
      • ユーザガイド
      • 機能や、それを使うと出来ることの概要を書く
      • データ欠損情報や更新履歴も記載
    • 事業部の様子を偵察(事業部が色々があるので、それぞれ偵察しにいく)
      • 各事業、プロダクトの担当を選任で設定する
      • 各事業部の定例MTGに参加する
      • プロダクトの動きを先回りして抑えておく
    • 事例共有会
      • 実際に分析基盤に使っているアナリストやディレクターに分析事例のプレゼンをお願いする(寿司とかお酒も出したりする。)
  • 結果
    • 年々プレゼンスが高まった。フィードバックもらえたり、リリースしやすくなった。

質問

  • Q.事業部制でバラバラの中、一箇所に集める上で、データガバナンスをする上での工夫は?
    • A.事業部側からデータ分析基盤に追加依頼をもらう。定型で依頼内容を容易しておいた。マスキングしないといけない個人情報の有無など。

所感

  • 使ってもらえるようにしたという施策について納得感があった。
    • ツールの利活用推進って内部向けだから簡単なわけもなく。外部ベンダーがフォローアップするような施策をしっかりとやらないと推進できない。システムだけを形だけ導入だけで後は進むということはない!が腑に落ちた。
    • ドキュメント、事業部への入り込み、事例共有会など泥臭くやってて大変さが伝わってきた。

Inuzuka Shintaroさん:「DWHを活用したクックパッド機械学習プロジェクト」

speakerdeck.com

自分が気になったポイント

所感

  • 機械学習で作った特徴データの説明もdmemoで管理するのは良さそう。(ユーザ側で発生したものではないので無意識に区別してたけど、活用するという観点では同じデータだった。)

Kurimuraさん:「アプリデータの分析を楽に効果的に!FirebaseAnalyticsとお友達になると良い3つの理由。(仮)」

speakerdeck.com

自分が気になったポイント

  • FirebaseAnalyticsの紹介
  • FirebaseAnalyticsの活用状況
    • 分析系テーブルが大きくなりにくいように、工夫している
      • 3ヶ月分のDataMartは、1/10を無作為抽出!
    • 2日以上前の後追いログが来るので、遡って更新する必要はある。

質問

  • Q.Firebaseの時間の定義

所感

  • 前半のFirebaseAnalyticsの紹介ページがすごい良い。完全に理解できた!感じ。(注:完全に理解できた!)
  • FirebaseAnalytics、色々と高機能なので、myアプリ作ってみて試してみたい。

Takeno Shunsukeさん:「DWH デザインパターン 〜 テーブル設計編 〜」

speakerdeck.com

内容

  • 分析上で発生するつらみ
  • 分析のためのデザイン
  • Rettyでの事例:BigQuery上の対応
    • 横持ちテーブルで対応
    • イベントログ層やエンティティ層(ディメンジョンテーブル/非正規化テーブル)、PVやセッションなどの指標層(ファクトテーブル)
  • 誰のためのデザイン
    • 分析基盤とは、データ基盤開発者と分析者が関係する
    • レポート分析基盤とは、分析者と意思決定者が関係する

質問

  • Q.テーブルの設計、ディメンジョンとファクトを分ける。なぜこういうデータの持ち方をするのかというメンバー間の相違をどう解消したのか?
    • A.規約にのっかるとこういう便利さがあるというメリットの認識を共有している。

所感

  • 〜テーブル設計編〜とあったので、多分○○編などの続編があると期待。洗替え更新や差分更新などの更新編とか。

本日開催された「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

内容

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

所感

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

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