本日開催された「第2回 データアーキテクト（データ整備人）を”前向きに”考える会」に参加しました。
勉強会メモ 第2回 データアーキテクト（データ整備人）を”前向きに”考える会 本日開催された「第2回 データアーキテクト（データ整備人）を”前向きに”考える会」に参加しました。
analytics-and-intelligence.connpass.com
- 全体を通した所感
- t-kurimuraさん：「EurekaのDataPlatform開発状況と"再現性"の実現」
- しんゆうさん：「抽出や集計の依頼を受ける時に気を付けていること」
- midaさん：「データエンジニアとデータアナリストを兼任して良かったこと」
- sotaronさん：「データの価値を失わないための Data Reliability Engineeringについて」
- ぶんけいさん：「意思決定に繋がる Intelligence とは」
全体を通した所感
- 「データエンジニアとデータアナリストを兼任して良かったこと」を聴講して、データ整備や抽出はストレスフルな職務ではある。しかし、データの信頼性がなくなれば、ディレクターとプロダクトエンジニアは厳密にデータ分析を行わずとも職務の遂行はできるので、データ系の仕事の価値は減る。そのため、データの信頼性を担保することは重要。（辛みはあるけども。）
- 「意思決定に繋がる Intelligence とは」を聴講して、マーケティング系指標のレポートを色々作っていたため、自分はデータアナリストと思っていた。ただ、Insight & Intuitionを出す観点で考えると、自分はデータアナリストの領域まで到達していなく、データの調理上手な人に過ぎないなと感じた。
t-kurimuraさん：「EurekaのDataPlatform開発状況と"再現性"の実現」
内容
- DataPlatform基盤
- BigQuery, Composer(Airflow)
- Datalake, DWH, Datamart
- DataPlatfrom公式化
- DataPlatfromに乗せるために満たすべき基準
- 再現性
- 体制
- プロジェクト毎にデータ分析担当が付いている。
- CloudComposerの基盤管理はSREとして別の担当が担う。
- 30分の定例で、DataPlatformの知見をメンバーと共有する。
- 業務フロー
- 一度簡易的な試しのDataMartを作成し、可視化する。
- その後、FBをもらいながら要件を確定して、DWH, Datamartに落とし込む。
- 監査ログから共通化できそうなクエリを共通かする。（例：JOINが良く使われているテーブル同士など）
- Tips
- 永続UDFの活用（Temporary UDFが各SQLに散らばるのを防止）
所感
- 試しのDatamartを作るという位の心持ちの方が、作り直しから発生するストレスがなさそうで良さそう。
しんゆうさん：「抽出や集計の依頼を受ける時に気を付けていること」
内容
- 基本戦術
- 依頼はきちんと聞く
- 邪険にしない。
- 納期をとにかく確認する
- ”なるはや。”のような曖昧な表現は、基本的にいつまでに？を明らかにする。
- あればうれしいがいつでも良い。基本放置しつつ、集計依頼された側から確認を定期的にすると良い。
- 依頼もデータも鵜呑みにしない
- 依頼者のやりたいことを実現することが真の目的。
- 目的を明らかにする。（データが欲しいのか？、分析して欲しいのか？、施策などの提案して欲しいのか？）
- 依頼はきちんと聞く
所感
- 依頼の内容は基本参考程度にして、背景・目的を明らかにして真の依頼に答えるという戦術が、基本的に大事。
midaさん：「データエンジニアとデータアナリストを兼任して良かったこと」
www.slideshare.net
内容
- JapanTaxiに関して
- ログとしては、アプリ利用だけでなく、配車情報、決済情報、位置情報がある。
- BIチームは、データアナリスト３名、データエンジニア１名である。
- 兼任してよかったこと
- データソース・DataLake・DWH・データマートはデータエンジニア。データマート・集計分析・意思決定はデータアナリストという分業
- データエンジニアがビジネスに対して理解が浅いと発生するケースを回避できる
- 理解が浅い場合、データアナリストからの分析要求に対して最適なデータ利用の提案ができない。要求の背景ある課題に対して他に使えそうなデータソースを紹介できない（データアナリストの分析が良くなるチャンスを喪失）。
- PDCAにおけるデータ分析でのメリット
- 分析基盤のエンドポイントとしてデータに関するなんでも相談先として頼られる
- データの存在有無、データの意味や分析のための特徴量として有用性など、必要なときに必要な情報を提供できる存在。
- 兼任のデメリット
- 組織規模が大きくなるほど、仕事量的に兼任が難しくなる。
- 通常の組織では、データエンジニア、データアーキテクト、データアナリストで職種が分かれていくと思われる。
所感
- データドリブンでない施策を行ってしまう理由の一つとして、データ分析の工数がない、データ分析者に依頼すると時間がかかるなどの理由で施策実行までが遅れるから、データ分析を待たずして施策を実行してしまう流れができてしまうという状況が発生する。という問題にとても納得した。そのために、いかに工数を抑えるか？を考えることは大事。
sotaronさん：「データの価値を失わないための Data Reliability Engineeringについて」
内容
Data Reliability Engineerは何か？
- どこかの有名な組織が決めた職種ではない。（ただ、様々な会社で発生する仕事ではある。）
- まだまだ定義が決まっていないが、必要な仕事。
よくないケースの発生を防ぐためにData Reliability Engineerが必要
- A/Bテストのログ欠損により、結果が信頼できず意思決定できない。
- バッチの遅延による最新のデータではなく、間違った判断を生む。
- データの価値、信頼を失わないこと
- データへの信頼が失われると、PMがデータ分析に基づく施策のプロセスがなくなる可能性が起こりうる。
Data Reliability Engineerの始め方
所感
- この方の信頼できるデータ整備へのこだわりを感じた。
- 一つ前の発表と同じく、データが信頼されなくなれば、それが当たり前と受け入れられて、データが軽視された判断が下されてしまう。という常にある危機は意識しないといけない。
- データ基盤における、サービスレベルというものをどのように定量化するか？については、今回の資料を参考にしつつ、さらに各々が模索していく段階だなと感じた。
ぶんけいさん：「意思決定に繋がる Intelligence とは」
内容
- システムを知らなくてもデータが欲しいのは、意思決定したいから。
- 課題が振られてなんか可視化して欲しい。と言われたときに、Intelligenceとは？
- Intelligeneとは？
- 意思決定につながらないと無価値
- Intelligence + Insight & Intuition（直感）
- 読み手に半強制的な行動を伴うもの。
所感
- データ分析とは？のフィクションながらケース問題が面白かった。データをデータとして集計してみるだけでなく、現実に即した形で配置したり可視化しないと、問題の本質を見逃す良いケースだった。
本日開催された「Data Platform Meetup#2」に参加しました。
勉強会メモ Data Platform Meetup#2 本日開催された「Data Platform Meetup#2」に参加しました。
data-platform-meetup.connpass.com
- 全体を通した所感
- 挨拶
- 長部 和仁さん：「プロダクト中心のデータ駆動を推進していくために大事なこと」
- Hashimoto Yuki さん：「データを用意しただけだと使われないので、使ってもらえるようにした努力」
- Inuzuka Shintaroさん：「DWHを活用したクックパッドの機械学習プロジェクト」
- Kurimuraさん：「アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由。(仮)」
- Takeno Shunsukeさん：「DWH デザインパターン 〜 テーブル設計編 〜」
全体を通した所感
- 前半２つのデータ駆動推進、使ってもらえるようにした努力の発表については、泥臭く挑むエンジニア達の姿に感じるものがありました。エンジニアとビジネスサイドという異質の組織間をつなぐ上で発生する場合、人に優しく寄り添うという姿勢の大事さ。
- 機械学習データの活用事例や、アプリログを効率良く活用するためのFirebaseAnalyticsの活用については、純粋に面白そうなのでやってみたい。
挨拶
内容
- 挨拶は、Retty平野さん
- DPMの趣旨
- 事業会社でDMPを担当してる人がノウハウを発表
- 開催の背景
- データレイクが整備されてきた、既存コミュニティで議論されていない内容(DWHの設計など)、課題感が自社内に閉じているのでノウハウの共有の場
- DPMの趣旨
- 会場のご案内は、pixiv高橋さん
- 本日の会場提供頂いたpixivのデータ駆動推進室の方
- データ駆動推進室：https://inside.pixiv.blog/jaggy/6421
- データ活用をサポート業務を担当
- 本日の会場提供頂いたpixivのデータ駆動推進室の方
長部 和仁さん：「プロダクト中心のデータ駆動を推進していくために大事なこと」
内容
- 長部さんの自己紹介
- データ基盤エンジニアの方
- データ基盤にpixiv本体しかない状況から、周辺プロダクト（ECサイトなど）含めてデータを含めて集約にご尽力
- 話すこと
- データ活用が求められる背景
- データ活用のための組織構造について
- pixivではどうしたか？
- 民主化する際の壁
- 分析スキル：担当者がSQLを覚える必要がある
- データ理解：開発者視点での謎のデータ構造への理解
- ガバナンス：それぞれが好きにデータを触れるため、正しくないデータ集計となる可能性
- pixivのデータ駆動推進室のやったこと
- 推進室は直接の分析課題を解決せず、現場が解決する。間接的に支援を行う。
- データ基盤操作のテンプレート化
- BIツールLookerの導入
- 互助会機能を充実：analystチャンネル、データエンジニア交流会、分析わくわくタイム
- 分析わくわくタイム：https://t.co/B8y4pOzAcr?amp=1
- チュートリアルリソースの充実
- 取り組みの結果
- 現在の課題感
- 中間テーブルの管理
- 管理ができない部分の発生
- 非プロダクトへの適用
質問タイム
- Q.学習教材の用意は、非エンジニア向けにも提供した？
- A.ビジネス系の人向けのチュートリアルも行なった。
- Q.BQは従量課金なので、跳ね上がる可能性もあるがどう抑制しているのか？
- A.監視はしているが、個人に任せている。悪いクエリを発行した人は呼び出して注意される！
- Q.推進側のモチベーションの維持ってどうやっているのか？KPIをどう設定している？
- A.データ利活用の課題意識を持っている人が集まってきた感じ。
Q.LookerはLookMLをかけないと使えないが、そのあたりは誰が対応しているのか？
- A.定義も各部署に開発者がコミットするようにしている。データ推進室がレビューなどを行いデータガバナンスを担保している。
個人的に伺った質問
所感
- データ集計の民主化事例として良かった。（自分で取り組んでいるが、他人に勉強してもらうというのはとても大変。）
- Looker導入はコストはかかるので、今すぐに真似できるものではない。ただし、テンプレート化、チュートリアルリソース追加、互助機能は真似していけそう。
Hashimoto Yuki さん：「データを用意しただけだと使われないので、使ってもらえるようにした努力」
内容
- 概要
- （データを用意しただけときに）かつて発生していた要望
- 使い方がわからない、データがわからない
- 分析の仕方が分からない などなど
- そこから、エンジニアがポスピタリティを発揮して使ってもらえるようにした施策を紹介
- ドキュメントを整える
- ユーザガイド
- 機能や、それを使うと出来ることの概要を書く
- データ欠損情報や更新履歴も記載
- 事業部の様子を偵察（事業部が色々があるので、それぞれ偵察しにいく）
- 各事業、プロダクトの担当を選任で設定する
- 各事業部の定例MTGに参加する
- プロダクトの動きを先回りして抑えておく
- 事例共有会
- 実際に分析基盤に使っているアナリストやディレクターに分析事例のプレゼンをお願いする（寿司とかお酒も出したりする。）
- ドキュメントを整える
- 結果
- 年々プレゼンスが高まった。フィードバックもらえたり、リリースしやすくなった。
質問
- Q.事業部制でバラバラの中、一箇所に集める上で、データガバナンスをする上での工夫は？
- A.事業部側からデータ分析基盤に追加依頼をもらう。定型で依頼内容を容易しておいた。マスキングしないといけない個人情報の有無など。
所感
- 使ってもらえるようにしたという施策について納得感があった。
- ツールの利活用推進って内部向けだから簡単なわけもなく。外部ベンダーがフォローアップするような施策をしっかりとやらないと推進できない。システムだけを形だけ導入だけで後は進むということはない！が腑に落ちた。
- ドキュメント、事業部への入り込み、事例共有会など泥臭くやってて大変さが伝わってきた。
Inuzuka Shintaroさん：「DWHを活用したクックパッドの機械学習プロジェクト」
自分が気になったポイント
- DWHを使った機械学習プロジェクト
- 特徴抽出を行う際
- Redshiftに直接接続してしまうと様々な問題
- 推論結果（学習後データの活用フェーズ）の際
- 機械学習プロジェクトで作ったデータを使ってもらうためにdmemoで定義を記載
- dmemo: https://techlife.cookpad.com/entry/2016/08/08/103906
- 特徴抽出を行う際
所感
- 機械学習で作った特徴データの説明もdmemoで管理するのは良さそう。（ユーザ側で発生したものではないので無意識に区別してたけど、活用するという観点では同じデータだった。）
Kurimuraさん：「アプリデータの分析を楽に効果的に！FirebaseAnalyticsとお友達になると良い３つの理由。(仮)」
自分が気になったポイント
- FirebaseAnalyticsの紹介
- FirebaseAnalyticsの活用状況
- 分析系テーブルが大きくなりにくいように、工夫している
- 3ヶ月分のDataMartは、1/10を無作為抽出！
- 2日以上前の後追いログが来るので、遡って更新する必要はある。
- 分析系テーブルが大きくなりにくいように、工夫している
質問
所感
- 前半のFirebaseAnalyticsの紹介ページがすごい良い。完全に理解できた！感じ。（注：完全に理解できた！）
- FirebaseAnalytics、色々と高機能なので、myアプリ作ってみて試してみたい。
Takeno Shunsukeさん：「DWH デザインパターン 〜 テーブル設計編 〜」
内容
- 分析上で発生するつらみ
- Join祭りが辛い。
- 乱立するダッシュボード
- 分析のためのデザイン
- Rettyでの事例：BigQuery上の対応
- 横持ちテーブルで対応
- イベントログ層やエンティティ層（ディメンジョンテーブル/非正規化テーブル）、PVやセッションなどの指標層（ファクトテーブル）
- 誰のためのデザイン
- 分析基盤とは、データ基盤開発者と分析者が関係する
- レポート分析基盤とは、分析者と意思決定者が関係する
質問
- Q.テーブルの設計、ディメンジョンとファクトを分ける。なぜこういうデータの持ち方をするのかというメンバー間の相違をどう解消したのか？
- A.規約にのっかるとこういう便利さがあるというメリットの認識を共有している。
所感
- 〜テーブル設計編〜とあったので、多分○○編などの続編があると期待。洗替え更新や差分更新などの更新編とか。
本日開催された「Data Platform Meetup#1」に参加しました。
data-platform-meetup.connpass.com
- 全体を通した所感
- 挨拶
- 竹野 峻輔さん：「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」
- yuzutas0さん：「データレイク構築後の四方山話」
- 鉄本 環さん：「DataPlatform構築プロジェクト推進の事例と学び」
- 石田 祥英さん：「大規模サービス開発における分析用データの必要要件」
全体を通した所感
- データ基盤ではなく、データプラットフォーム(Data Platform = DP)という表現かっこいいので、使っていこう。
- DPアーキテクトの基本構成は、Google BigQueryと、Cloud Composer(Airflow)。
- DPテーブルの基本構成は、Data Lake(DL), Data WareHouse(DWH), DataMart(DM)の３層構造。
- DPを使いこなす上では、人の巻き込み方、組織体制が重要。
- 利用状況モニタリング、依頼チケットのリードタイム計測など、施策PDCAの考え方も使える。
挨拶
- 平野さん
- データ分析チームのマネジャー
- データアナリスト、データ周りすべてを担当
趣旨説明
取り扱いテーマ
- DWHの設計〜活用（データレイク・データウェアハウス・データマート）
- データ活用に関わる組織・仕組みの設計（データアナリストとデータエンジニアの役割分担など）
- BIツールの設計・利用方法
- 分析に関する品質担保（ダッシュボードの品質・冪等性の担保など）
- 運用を見据えた管理・統制（権限設定・マスキングなど）
背景
所感
- 初めてのData Platform系MeetUpじゃないか？ということで、データアナリストやデータエンジニアにとって非常に貴重会であったと思う。
竹野 峻輔さん：「カルチャーとエンジニアリングを繋ぐデータプラットフォーム」
内容
データにまつわる課題
- データが汚すぎ、パイプライン、ワークフローが長すぎ。
kagglerの時間対応割合のアンケート
- 時間の50%をクレンジングなどデータの準備だけに時間を使っている。
Retty
- 4000万人が利用。
- 2017年にデータ分析チームが発足。
- 2017/11時点で月4000 -> 2019/08で月46000にクエリの数が増大。
ポイント
質問
Q: DWHを分析者のスコープだと思うが、データエンジニアのスコープはどこまでか？
- A: 自動化ツール、例えばテストを簡単に書けるようにする。そのようなツールを提供して分析者に手離れしてもらう。
Q:どういうデータを揃えておくか？
- A: どういうキーワードで流入してくるか？、サイト内アクセスなど。データ分析者が欲しいというものは、基本全部とる。
所感
- 「データ基盤エンジニアが全てやると、データアナリストにドメイン知識などの知見が貯まらない。データ基盤は分析者にとってのプロダクトとする。」
- DPについては、データアナリストをスクラムのPOやPMに据えるのは正しいと思う。
yuzutas0さん：「データレイク構築後の四方山話」
内容
ターゲット
- データは入れたけど、データ基盤をどう進化させていけば良いか困っているデータアナリスト。
コメント
- データを疎通したデータアナリストは、素晴らしい！
- イシュー駆動して欲しい。
質問に答えていくスタイル
- 中間テーブルを作るとき
- 権限管理
- 処理の遅延
- 途中で継ぎ足されたテーブルなどで処理が遅くなっていく
- データ未更新、データが落ちている
- 不整合データをどこで吸収するか
- ETLでクレンジングだけでは足りない。勇気を持って、開発担当者などにFBを返そう。
- 擬似的に履歴データを作りたい
- 日次バッチでスナップショットを取る、できれば、プロダクト側で履歴を持つのが良い。
- 法令的に残っていることが必要な場合が多い。
- 中間テーブルの作成はKPIから効果をブレイクしていく。
質問
- Q: 履歴を持つデータの設計のベタープラクティス
- Q: DWH/DMなどの過去訴求が、大変かつユーザー影響があるけど、どうやるのが良いか？
- A: A/B面作戦で、まずは_tempを作り、データ移行した後に切り替えるのが良い。
所感
- 明日から使える、DPトリビアだらけ。ひたすら感謝。
- DPの利用状況モニタリング、クエリのテスト方法やメタテーブルによる欠損の監視など、もう一度読み込みたい。
- 参考文献も豊富なので、隙がない。
鉄本 環さん：「DataPlatform構築プロジェクト推進の事例と学び」
内容
エウレカの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構築でスクラムを取り組んでいるのはユニークではないだろうか。（たぶんその方が進めやすい気もする。）
石田 祥英さん：「大規模サービス開発における分析用データの必要要件」
- ガチ広告系データエンジニアからビジネス系データアナリストになっためずらしい経歴の方。
内容
大規模サービスデータの三重苦
- 広い（多い）、データ量が数十TBなのでBQでも処理が重い、メルカリのJPだけでも１０００人体制なので意思疎通が大変。
データアナリティクスが活躍する３つの領域
- お客様の行動・事業進捗の把握、UX計画・効果予測、効果振り返り。
メルカリの分析環境
- 物理
- 基本生データ全部がBQにある（恵まれている環境だ。。。）
- 組織
- 職能（Data Analyst）とプロジェクト（売上、出品者、横断的なUX改善）の掛け算。
- 思想
- どの施策を選択するか？、どのお客さんをターゲットにすべきか？などの目的先行でのデータを使った意思決定で進める。
- 物理
横断モニタリングPRJ
- 全体をモニタリングする責任者がいなかった。ので、作った。
- イベントレベルまで詳細なモニタリングダッシュボードを作成。
- 効果としては、追えていなかった数字が見え、新たな問題を築けた。
誰でも中間テーブル
ログ漏れ
- テスト設計、ログレビューを必須とする。
- BIチーム内で仮説や検証をダブルチェック。
- 効果検証フォーマットでチェック。（走る施策多くてレビューが大変そう。。。）
- ABテストでわからないことを明示しておくのが良い。
今後やりたいこと
- 元テーブルと、中間テーブルの数値チェック。
- 体系的なデータマートの整える。など
質問
Q: モニタリングは指標が少ない、絞る方が良いのではないか？
- A: 異常検知や全体的なモニタリングは、カバレッジが重要と思ったので、多い方が良いと思う。
Q: 定義したKPIをどう運用していくか？データマート作成が大変そう。
- A: 常に更新していく方針。更新が多いので、データマートは作成していない。変更があればクエリだけ更新している。Lookerで対応している。
所感
- 横断モニタリングに関して、全部を見てバランスよく判断するのは、難しいと思う。この取り組みついては、今後も注視したいと感じた。
- 施策の効果測定のガバナンスを利かす上でも、テスト設計やログ設計や仮説、検証を、レビューする体制を整えたのは、素晴らしい。
- しかし、同時にBIチームがボトルネックになって、スケールしなくなる気もするけど、どううまく対応しているのだろうか、気になる。
「Bonfire Data Analyst #1」に参加しました。
本日開催された「Bonfire Data Analyst #1」に参加しました。
- 全体を通した所感
- Yahoo!ショッピングにおける人を動かすためのスキルセット
- 内容
- 所感
- 営業から事業部長まで経験したおじさんがデータアナリストに必要なスキルセットを整理してみた
- 内容
- 所感
- メルカリのアナリストのスキルセット
- 内容
- 所感
- スキルのコモディティ化の波を乗り切るには？
- 内容
- 所感
全体を通した所感
- データ活用が進んだ企業でのデータアナリストに求められるスキルは、小難しいツールを使えるという機能面よりは、事業側のKPIにコミットする。または意思決定者に働きかけてアクションさせられるといった、ソフトスキルが重要性が強調されるようになってきているなと感じた。
Yahoo!ショッピングにおける人を動かすためのスキルセット
西村 純 (@jnishimu)さん ◆ ヤフー株式会社 / データアナリスト
内容
- 環境
- Yahoo!ショッピングのデータアナリスト５人。
- 分析用データベース：teradata/Hadoop, BIツール：R&A/MicroStrategy。
- 以前の課題
- データアナリスト側
- 担当者との距離が遠い。
- PMや企画側
- データアナリストは何をしてくれるのか？わかりにくい。
- 分析結果だけでなく、施策まで出して欲しい。
- データアナリスト側
- 改善後
- データアナリストが１PJ毎に担当。
- 改善後に必要なスキル
- 担当PJの成功のために分析する姿勢。
- 疑う：依頼された集計をこなすだけでなく、集計がPJにとって必要なのか問う。もっと最適な集計軸を模索する。
- 提案する：PJに入り込んで、目的に対して、必要な分析軸をデータアナリスト側から提案、さらに施策案も提案する。
- コミュニケーションの頻度を上げる：担当者とのやりとりを１回→５回/週、結果はすぐにフィードバック。
- まとめ
- SQL/BIツールなどのツールの使い方は勉強すれば身につく。PJを成功させるための分析をすることが重要。
- PJゴールをもとに考えて、依頼された分析・集計を疑う。むしろ、分析の提案、施策も提案する。
所感
- BIツールとしてMicroStrategyを使っているのは珍しい。
- 従来のデータアナリストは、ツールを使いこなして集計という高度なツールを使いこなして機能を提供するタイプが多かったように感じたが、最近のデータアナリストは企画側に近く、分析を軸に施策やPJと伴奏するという形が求められている。
営業から事業部長まで経験したおじさんがデータアナリストに必要なスキルセットを整理してみた
小川 晋一郎 (@ogawa4216)さん ◆ 株式会社Hakali / 代表取締役
www.slideshare.net
内容
- リクナビでレコメンド、応募予測に従事していた。
- かなり過去ではあるが、リクルートのデータ分析チームでは、企画から分析依頼がどんどん飛んできて、筋が悪いものも多く辛かった。
- データアナリストの辛い評価：営業は売上だけど、分析アウトプットをもって他人に動いてもらわないと成果が見えない。
- 上記を元に、心穏やかになるためのデータアナリストを考えた。
- まとめ
- データ分析（AI系ではない）はどんどんニーズは増えている。DWHはあるけど、どう使うか？分析するのか？が見えていない企業もある。
- コンサル稼業は単価をどう上げるべきか？労働集約、頭を使うので3件が限界。
所感
- データアナリストは、単純にツールを使いこなせるというよりは、コミュニケーションや共感力などソフトスキルが重要。
- データアナリストの力の発揮しどころは、事業/組織の全体像について関係者と議論しながら、全体像モデルを更新続ける、インタビューを元に課題を整理などを行う。数理モデルというよりは、ビジネスモデル（業務フロー）を元にコンサルや事業企画としてやる側面が強くなっていきそうに感じた。
メルカリのアナリストのスキルセット
松田 慎太郎さん ◆ 株式会社メルカリ / データアナリスト
www.slideshare.net
内容
- メルカリでのデータアナリストの仕事
- 松田さん自身は、Marketing/Growth/CSと広い関係者と仕事。
- メルカリのデータアナリストは、分析の考え方を考える事を大事にしている。
- データアナリストチームは、個々のPJ/Teamの中に入り込む分散体制。
- 目的を持ったもの（例：売上上げる！）をプロジェクトといい、各人はAnalystとして各PJにアサインされる。
- 意思決定者とコミュニケーションが多い。
- 分析テーマとしては、事前と事後、マクロとミクロの２軸で、事業計画、施策シミュレーション、主要指標モニタリング、施策効果分析などがある。（この整理は良かったので、UPされたらもう一度見たい。）メルカリのデータアナリストは”事前：何かをやる前の方針策定”に重きを置いている。
- 参考URL：https://speakerdeck.com/hik0107/simple-data-analytics-leads-impact
- 顧客セグメントは複雑にしすぎると報告者が理解しずらい、コミュニケーションツールと考えた方が良い。
- 結局、メルカリのアナリストのスキルセットとは？
- 評価項目とほぼイコール。
- 問題を探す力
- 問題を定義
- 定量化するスキル
- 伝える力
- 影響力
- 信頼感
- 評価項目とほぼイコール。
- 松田さんが考えるしばらく職にあぶれなさそうな、データアナリストとは？（他の職能との掛け合わせ）
所感
- データアナリスト概論を受講しているような体系化された内容。
- メルカリのようにデータアナリスト文化が進んだ企業に対して、多くの企業ではデータアナリスト像がまだ確定していないので、単純にメルカリの事例やフレームワークを持ち込むと、ギャップが生まれて機能は難しいだろうと感じた。自社のデータ分析スキルフェーズに応じて取り入れた方が良さそう。
スキルのコモディティ化の波を乗り切るには？
田中 祐介さん ◆ ヤフー株式会社 / データアナリスト
www.slideshare.net
内容
- 課題設定力以外はコモディティ化していく
- コモディティ化を避けるためには？
- プロダクト/サービスのゴールを残したまま、ゲームのルールを超えて考えられる、局所解を超えて考えられる。
- 自社のデータ分析に関して弱い部分を見つける。
- 上記を実現すべく、最新技術などの情報を幅広く集める。
所感
- 課題設定力以外はコモディティ化していくという表現がすごくしっくりきた。
- メルカリやヤフーなど、データ分析が強い企業では、ツールが使える＜課題設定、ソフトスキルというような価値観になりつつある現状を理解できた。
勉強会のブログアウトプット、今回初めて取り組んでみたけど、書き漏らしたり間違って理解していることもあるので、この辺りは今後もアウトプットを続けながら改善したい。
テスト
テストだよ。
