Recommended
More Related Content
What's hot
What's hot (20)
Similar to オープンセミナー岡山 これから始めるデータ活用
Similar to オープンセミナー岡山 これから始めるデータ活用 (20)
More from syou6162
More from syou6162 (20)
Recently uploaded
Recently uploaded (10)
オープンセミナー岡山 これから始めるデータ活用
- 2. 今日お話すること ● データ活用は珍しいことではなくなってきた ● 一方でまだ悩んでいる人も多いのではないか ○ データ活用するにはどういったことが必要か分からない ○ データ活用の文化が自社にはまだまだない ● 本発表ではデータ活用にあたり登壇者がチーム内外で行なった等身大の取り組み をご紹介します ○ 約一年半ほどの取り組み ○ 技術的な側面 ○ コミュニケーション/文化的な側面 2
- 3. このトークのゴール ● データ活用をしていくと、どういういいことがあるか分かる ○ それをエンジニアがサポートしていくメリットも分かる ● どうやってデータ活用を進めていけばいいか、イメージが湧く 3 ● 自分がデータ基盤をやり始めたとき、右も左も分からなかった ... ● データエンジニアリングのコミュニティの方にたくさん教えてもらった ● データ活用、データエンジニアリングに興味を持つ人の参考にちょっとでも なったら嬉しいです!
- 4. 自己紹介 ● 吉田 康久 ○ Twitterやはてなidは@syou6162 / id:syou6162 ● 前職: NTTコミュニケーション科学基礎研究所 ○ 自然言語処理や機械学習の研究に従事 ● 株式会社はてな ○ アプリケーションエンジニアとして入社 ○ はてなブックマーク ○ サーバー管理/監視システムMackerel ■ 教師なし学習による異常検知機能開発 ● 2020年2月よりMackerelチームのCRE(Customer Reliability Engineer) ○ 主にデータ基盤整備 / データ分析 4
- 6. MackerelチームのCREについて ● CRE: Customer Reliability Engineer ○ 日本語に直訳すると「顧客信頼性エンジニア」 ○ 2017年に発足 ● ミッション: 顧客に寄り添い、顧客が抱える真の課題にフォーカスし、その課題を技術 を軸として顧客と共に解決を図る ● キーは「カスタマーサクセス」と「エンジニアリング」 ○ ユーザーの課題をエンジニアリングで解決 ■ 例: テクニカルサポート ○ ユーザーの課題をエンジニアリングで発見 ■ 例: データ分析やデータ基盤 6 実行委員長の@a_knowさんも 同僚です!
- 12. 最近は活用の幅が少し広がりつつある プロダクトの価値全体を最大化 プロダクト サクセス ハイタッチ テクニカル サポート データ分析基盤 セールス / マーケティング 開発チーム プロダクト オーナー
- 13. 注意: 私のトークでは話さないこと ● 大規模なチーム、すでにデータ基盤がある程度形になっている状況下でのデータ整 備人 ○ データ整備人の担当領域がすでに明確に決まっているケース ● チームメンバー全員で↓くらいの規模での話をします(Mackerel Day 2の集合写真) 13 データ整備人の定義によると このくらいの割合で働いています データエンジニア = 3 データ整備人 = 4 データアナリスト = 3
- 14. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 14
- 15. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 15
- 17. なぜデータ活用をやるか ● 様々な観点があるけど、本発表では「解像度」という観点で話します ○ 大局観 ○ 個別ユーザー ● より包括的なことを知りたい方はDMM.comを支えるデータ駆動戦略を読まれるとい いかもしれません 17
- 18. 解像度: 大局観 18
- 19. 解像度: 大局観 19 ● 昔から使ってくれているユーザーの売上はどんどん減ってる ● 広告を増やしたり、営業大量増員して売上は上がっているが、利 益率が悪化 ● 穴の空いたバケツに水を頑張って入れている状態
- 20. 解像度: 大局観 20 ● 昔からのユーザーが継続的に使っている ● 広告を出しまくったり、営業を大量採用しなくてもいいので、利益率 もよい ● 理想に近い形
- 22. 解像度: 個別ユーザー ● 解約の一年ほど前に、Webの閲覧状況が急激に悪化していた ○ 例: 解約アンケートを取ってみると、キーマンの退職があった ○ 閲覧状況が悪化し始めたタイミングでヒアリングをすれば、解約が防げた可能 性があった、かも 22
- 23. 個別ユーザーの解像度を上げる ● 銀の弾丸ではない ● 劇的に生活が変わるわけではない 23 「手厚さ」と「見れるお客さんの数」は 基本的にトレードオフ データ分析で解像度が上がるこ とにより、トレードオフをある程度 緩和できる ● 例: 同じ手厚さをより多くのお客 さんに提供できる ● 例: 同じお客さんにより手厚い サポートを提供できる
- 24. データ活用で解像度を上げよう ● 大局観 ○ 事業構造を分解して、収益や顧客満足度のボトルネックを探す ○ 1つの指標を外の指標で分解する ○ 例: KPIをツリーに分解 ● 個別ユーザー ○ 売上よりも早めに分かる指標(先行指標)を元に、優先して見るべきユーザーを 決めてアクションを取る 24
- 25. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 25
- 34. データ活用にエンジニアリングは必須 & 面白い 34 データの生成 データの貯蓄 データの活用 アプリケーションエンジニア : ユー ザーの行動をイベントとして発生 させる SREやデータエンジニア: イベントをストレージに記録する。必要 な場所にデータを転送する データ整備人: 必要なデータを使いやすいよ うに整備する
- 35. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 35
- 36. どこからやるか / どうやるか ● やりたいこと、やれるといいことは山のようにある ● 例: ○ KPIツリーの分解 ○ オンボーディング率改善 ○ A/Bテスト ○ BigQueryにデータ転送すればいい? ○ みんなが見たくなるようなイケてるダッシュボードを作ろう ○ 統計学勉強しないといけない? ● やり方もいろいろある ○ 簡単にできそうなところからやる ○ 一番大変そうなところからやる 36
- 37. ● 「イシュー度」が高い問題からやろう ○ 問いても仕方ない問題ばかり問いていても、データ活用は継続できない どこからやるか / どうやるか 37 出典: イシューからはじめよ プロダクトオーナーと会 話しながらイシュー度の 高い課題を検討 解の質はデータ活用で 後から上げられる
- 38. Mackerelチームの場合 ● 「主要KPIのダッシュボードの構築」から取り組むことにした ○ その計算をするためのデータパイプラインの整備も含む ● 理由 ○ このダッシュボードは絶対見られる ○ 主要KPIを分解しないと、細かい施策の善し悪しや影響度が分からない ○ 見たい指標を計算するためには、(後述する理由のため)データパイプラインの 整備が必須だった 38
- 39. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 39
- 40. ステップ1: 主要KPI計算のためのデータパイプラインの整備 ● 当初: BigQueryもデータウェアハウスもないゼロからのスタート ○ ゼロからって、それって本当? ○ そんなことはない! ● 経営陣向けの主要KPIダッシュボード(スプレッドシート)は存在 ○ これが最初のデータ基盤 ○ 最初は解の質が低くてもよい、あとから上げていけばよい 40 データレイク RDBからtsvにしたのをシートにコピー データウェアハウス 生データを(何段階かで)集計 データマート グラフ表示用のシート
- 43. 着手以前の状況 43 Aさん: XXXの分析したかった けど、KPIダッシュボードが壊れ るのは怖い... 詳細分析はまた今度にしよう スタート地点のRDB のテーブル ゴールの主要KPIダッ シュボード Aさん: XXXを追加分析したい から変更を加えよう!! Bさん: ダッシュボード、壊れ て見れなくなってる?!
- 44. ● チームメンバーと一緒に既存のKPI算出までのフローを「全部」追った ○ スプレッドシートの依存関係を可視化 ● 今回やるスコープを決める ○ 全部一気にやるのは無理 ○ まずはKPI系から着手 改善: データワークフローの可視化 44 経理系(請求書関係) KPI系 => まずこちらから!
- 45. 改善: ワークフローの簡素化と(部分的な)自動化 ● スプレッドシートをスクリプトに置き換え ○ 依存関係のグラフを見ながら、後段に影響が出ないように ■ 現在はスクリプトもSQLに置き換えた ○ 「このデータって今見ていますか?」というのを利用者にヒアリング ■ 利用者: プロデューサー、経営陣、経理部、事務チーム ■ 削れるところは可能な限り削ってシンプルに ● 自動化が理想的ではあるものの、特殊なプランも存在する ○ エンジニアなので自動化は大好き... ○ 完全な自動化に必要以上には拘らない 45
- 46. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 46
- 47. ステップ2: データ基盤で出せる価値を感じてもらう ● データ基盤を整備しても、分析によって価値を生まなければ無意味 ○ データ分析の文化醸成はまだまだこれから、という段階 ● データ基盤 / データ分析でどこで価値が出せそうか、分析を進めたい人がどこにい るか、ひたすらヒアリングやミーティング聴講 ○ 主要KPIのデータフロー整備の経験が生きた 47
- 48. 価値が出る & 分析可能なところはどこか ● 例えばこういうミーティングに参加 ○ 来期以降の施策を考えるリーダー合宿 ○ ペルソナ策定会 ○ カスタマージャーニーマップ作成会 ○ プロダクトエンゲージメントスコア作成会 ○ デザイン相談会 ● ミーティングの前にアジェンダが出ていれば、簡単な分析やダッシュボードを持ち込 む ○ データに興味を持ってもらう! 48 事例: ジャーニーマップ 会話例: この設定でつまずく人が多 いって本当ですか? 条件に合うユー ザーの利用統計見ませんか ?
- 49. 意思決定の場所に自分から行く 49 会話例: こちらのデータソースを使 うと、より適切に効果を測定できそ うですね 会話例: この施策については定量 データよりも定性データのほうが 適切かも? ペルソナに近いユーザーにインタ ビューしてみませんか ? 会話例: このKPIを計測する データは今はないです。 リリース前にログを仕込んでお きましょう メルカリさんの事例を参考にさせてもらいました 会話例: 最初はこの分析やった ほうがよさそうに思っていたけ ど、優先度低いことが分かりま したね。 今回はこの分析やらないことに しましょう
- 50. 分析したい人が分析できるスキルを: ペアプロ & SQLレクチャー会 ● 「この分析をしたいのであれば、ここに生データがあって、こういう感じで分析ができ ますよ」という簡単な分析を私が示す ○ 私で全部はやらない ○ 深掘り分析をしたい人に伴走する ● SQLのペアプロ ○ 東京と京都をGoogle Meetで画面共有しながら ● 頻出題材については、SQLレクチャー会に取り入れる ○ 参考1: 営業さんまで、社員全員がSQLを使う 「越境型組織」 ができるまでの 3+1のポイント | リブセンス ○ 参考2: SQLレクチャー会をチーム内でやっている話 - yasuhisa's blog 50
- 51. SQLレクチャー会のポイント ● 業務課題に寄り添った例題や練習問題の設計をする ○ データへの理解とSQLへの理解を切り分けできる ● 付与する権限は最低限に絞る ○ 「何か変な操作をしてデータ基盤壊してしまったら嫌だな...」という心理的な障壁 を下げる ● 教える / 教わるという構図にしない ○ SQLを書いているときに苦労しているところはデータ基盤の改善できるポイント の宝庫 51 ● SQL未経験の営業事務の方を対象 ● 週1の勉強会を3ヶ月程度で ● 多段のJOINやウィンドウ関数を使った分析をマスターしてもらえた !
- 52. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 52
- 53. ステップ3: 監視環境の整備 ● データ活用が進み始めると、データ基盤側で問題が起き始める ○ 使われないのが一番よくないので、うれしい悲鳴ではある ● 問題例 ○ (テーブルが壊れていて)ダッシュボードが見れないんだけど! ○ 最新データが先週のっぽいけど、データ更新止まってない? ○ 同じ会社名のデータが2つ入ってるんだけど、どうして? 53 データ基盤もある種のサービス運用。 監視を適切に導入しよう !
- 54. 監視: データ転送 ● 2種類の監視を設定 ○ バッチの失敗自体を監視(mkr wrapを利用) ○ バッチの処理時間が想定以上に長くないかを監視(horensoを利用) 54
- 55. 監視: 投入されたデータの性質 ● データの性質の監視とは? ○ 重複を許さないはずのnameカラムに、重複したデータが入っている ○ 値が0から100の間に収まるはずのカラムに、マイナスの値が入っている ● RDBでは便利な制約をかけることができてデータを守ることができた ○ ユニーク制約、チェック制約 ● 転送元がRDB以外だと、制約をかけられないことも多い ○ 例: スプレッドシート、Salesforce 55
- 56. 監視: 投入されたデータの性質 ● 満たして欲しい制約と期待する結果を書く ● アラートが出たらなるべく元データを修正しにいく 56
- 57. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 57
- 58. ステップ4: 自走できる環境に近づける ● 初期は分析者が少人数だったので個別回答で何とかなったが、明らかにスケールし ない... ○ 解決案: データに対する知識をメタデータに持たせていこう ● BigQueryの{テーブル, カラム}のdescriptionに{テクニカル, ビジネス}メタデータを記 述、Data Catalogでメタデータに対する検索 58 カラムAとB、似てるけどどっちを使うといいですか ? XXXを調べたいけど、どのテーブルを見ればいいですか ? この料金って税込ですか、税抜ですか ? データ整備人(私) 分析したい人
- 60. 課題: どうやって継続的にメタデータを管理するか ● サービスは生き物であり、メタデータも日々変化 ○ 変化に「継続的」に追従したい ○ 管理すべきテーブルやカラム数は普通に多い ● データ整備人の気合と根性だけでは無理 ○ 根性ないので、早々に諦めました... 60
- 63. メタデータ付与、実践! ● 既存カラムへのコメント付与 ○ 私が付与 ■ 元アプリケーションエンジニアでもあるので、低コストで調査可能 ○ 全テーブル / 全カラムにまんべんなく付与するのはコスパが悪いので、発行さ れたSQLの統計量を元に利用回数の多いものから着手 ■ データドリブンに改善 ● 新規のカラムの追加 / 既存カラムの変更 ○ 実装直後で一番知見があるので、開発チームへ依頼 ○ Pull Requestのテンプレートに確認項目を追加 63 typeカラム: 0は仮登録、1は登録済み、2は退会 XXXカラム: 2020年より前はNULL、YYY施策で 集計値が入るようになった。集計条件は〜
- 64. 開発チームがメタデータを付与するインセンティブ ● 「ALTER TABLE時はメタデータも付与してね!」とお願いするのは簡単 ○ 面倒な雑用を押し付けているだけ? ● 開発チームへのメリットを提示 ○ 開発チームに最近入ったメンバーにとっても、DBにメタデータがあることは開発 タスクへのオンボーディングを早める意味でも有用 ○ エンジニアへのデータ調査依頼の削減 ○ SREなど普段アプリケーションのコードを触らない人もいるので、そういった人た ちに向けても重要な情報を提供できる ● データ整備人だけでなく、「チーム」でメタデータを育てていく環境を作ることを意識 64
- 65. RDBからBigQueryへのメタデータの組み込みフロー 65 開発チーム + 私で コメントDDLを付与 メタデータを 自由に検索 ● コメントDDLはtblsを使うと便利 ○ スキーマ情報をjsonで取り扱える ● tblsで抽出した情報をjqで加工、bqコマンドでスキーマを流し込めば完成! ○ 詳細はこちら ○ コメントの付与率をMackerelで可視化することでモチベーション維持 付与率を可視化 BigQueryだけで何とか するのは大変しんどい !!
- 67. アジェンダ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 67
- 68. ステップ5: チーム外に範囲を広げていく ● せっかく知見が溜まってきたので、社内の他チームにも展開したい ● 知見共有する場を作ろう ○ ダッシュボードの作り方や、その活用状況、必要な情報をどのように集めている か ○ 社内で「誰がどういったデータ活用をしているか？」を知ることで、チーム間で データ活用の相談をよりしやすくする ○ 技術面だけでなく、よいチーム文化やコミュニケーションの取り方 68
- 69. 突撃! 隣のダッシュボード ● Hatena Developer Blogに詳細まとめてます ● 話題内容の例 ○ チーム内のダッシュボードの大まかな種類やその発展の歴史 ○ 継続的にデータを見る人が増えない問題とその解消法 ○ 分析を含めた学習サイクルが高速に回せていない問題 ● 参加者の声 ○ 自チームがどの段階にいるのか、どうやったら次に進めそうか分かってよかっ た ○ 他部署が持っている面白いデータの存在を知れて、その後のコミュニケーショ ンに繋がった ○ 他職種の人がどこで困っているか分かってよかった ○ AS-ISだけでなくTO-BEを考える機会になった 69
- 70. データ活用の3つの壁 ● 突撃! 隣のダッシュボードの中で企画職の方が上げてくれた課題の分類 70 ● 必要なデータが正しく存在するか ? ● データを正しく取得できるか ? ● データを正しく分析できるか ? (出張版)SQLレクチャー会やデータ分析会を 開催して、壁を乗り越えるのをサポート
- 71. まとめ ● 自己紹介 / 会社紹介 ● なぜデータ活用をやる必要があるのか ○ なぜエンジニアがサポートする必要があるのか ● どこからデータ活用を始めるのか ● データ活用への道の具体例 ○ ステップ1: 主要KPI計算のためのデータパイプラインの整備 ○ ステップ2: データ基盤でできること / 出せる価値を感じてもらう ○ ステップ3: 監視の整備 ○ ステップ4: 自走できる環境に近づける ○ ステップ5: チーム外に範囲を広げていく 71
- 72. このトークのゴール ● データ活用をしていくと、どういういいことがあるか分かる ○ それをエンジニアがサポートしていくメリットも分かる ● どうやってデータ活用を進めていけばいいか、イメージが湧く 72 ● 自分がデータ基盤をやり始めたとき、右も左も分からなかった ... ● データエンジニアリングのコミュニティの方にたくさん教えてもらった ● データ活用、データエンジニアリングに興味を持つ人の参考にちょっとでも なったら嬉しいです!