Slide 1

Slide 1 text

データビジネスにおける実践的dbt活用例 2022 / 11 / 11 Naoto Sakai @jagabass

Slide 2

Slide 2 text

2 自己紹介 ・株式会社コロプラ (2017/4〜2021/6)   アプリ分析・マーケティングリサーチ・人事データ基盤構築 ・Ubie株式会社 (2021/7〜)   製薬事業におけるデータモデリング・データ分析・組織設計 Naoto Sakai Ubie Discovery / Data Analyst @jagabass

Slide 3

Slide 3 text

3 目次 1. Ubieの組織・プロダクトと製薬事業について 2. 製薬事業におけるdbt活用例

Slide 4

Slide 4 text

4 Ubieとは 社名:Ubie株式会社 代表:阿部吉倫、久保恒太 設立:2017年5月(創業6年目) 従業員:200名(2022年9月現在) 累計調達額:107.2億円 「テクノロジーで人々を適切な医療に案内する」をミッションに持つ、医療 AIスタートアップ企業。

Slide 5

Slide 5 text

5 Ubie全体の組織体制 事業フェイズ・役割に合わせて組織を分割。カルチャーや組織運営スタイルも異なる。

Slide 6

Slide 6 text

6 Ubie全体の組織体制 事業フェイズ・役割に合わせて組織を分割。カルチャーや組織運営スタイルも異なる。

Slide 7

Slide 7 text

7 toC Ubieのプロダクト 症状から受診の手がかりがわかる toB 診察事務を1/3に効率化 導入施設 47都道府県 1000超 利用者数 月間 万人超 700 AI問診エンジンをコア技術として、一般生活者・医療機関それぞれにプロダクトを展開。

Slide 8

Slide 8 text

8 製薬事業について 武田薬品様(遺伝性血管性浮腫) アストラゼネカ様(喘息 ) ファイザー様(過活動膀胱) 出所:PRTIMES、i2.JP 患者・医師向けソリューションを切り口に、大手製薬企業と協業(一部抜粋)

Slide 9

Slide 9 text

9 希少疾患の患者発見プロジェクトにおける事例 ユビー利用による”適切な医療への案内 ” ユーザーのプロファイル • 30代女性 • 20歳の頃から3か月に1回程度激しい 腹痛や下痢に悩まされていた • 手足や顔が腫れることも多く皮膚科を 受診したこともあるが原因はわからず Google検索 ユビー利用 関連病名確認 受診 治療開始 いつもの症状が 出現し不安になり 「手足 腫れる」で検索 ユビーというサービスを発見。 関連病名が調べられるらしい。 早速問診に回答してみる とある難病の可能性が出現。 専門医がいることを知る 長年原因不明だったこともあり、 早速専門医を受診。 どうやらユビーで出てきた病気らしい 薬を処方され、10年以上 悩まされていた症状が 緩和傾向。寛解を目指す 製薬企業との協業で、実際に希少疾患の患者を適切な医療に案内できた事例が続々と出てきている。

Slide 10

Slide 10 text

10 製薬事業におけるデータ利活用体制の全体観 データ利活用にあたってチームだけでなく組織を跨いだ業務が多いのが特徴。 BI チーム 運用 チーム コンサルティング チーム クライアント ・レポーティング ・ソリューション提案 ・分析による提案・報告サポート ・レポート用ダッシュボード提供 ・データ基盤構築 ・プロダクト機能実装 ・マスターデータ更新 Ubie Discovery Ubie Pharma Innovation ※実際はより細分化されています

Slide 11

Slide 11 text

11 目次 1. Ubieの組織・プロダクトと製薬事業について 2. 製薬事業におけるdbt活用例

Slide 12

Slide 12 text

12 なぜdbtによるデータ信頼性担保を重視しているのか ①統計情報だけでなく、一人ひとりのユーザー行動データが極めて重要。   ・1件の数値ズレが情報としての価値を大きく毀損する可能性がある。 ②レポート先が社外である ToBビジネスであり、顧客との信頼関係構築も重要。   ・「先月のデータが少し間違ってました。ごめんなさい 🙏」では済まされない → データマネジメントが事業成長にダイレクトに繋がる。

Slide 13

Slide 13 text

13 課題: 数値異常に気づけない & 問題発生後の調査コストが高い 個別のロジックが多く、レポーティング用テーブル作成クエリが複雑になりがち。 集計条件の見落としによる数値異常が頻発 & 問題特定に時間がかかってしまう。 BI チーム コンサルティングチー ム ・分析による提案・報告サポート ・レポート用ダッシュボード提供 ・データ基盤構築 ・レポーティング ・ソリューション提案 クエリを読み解くのがつらい ... どこが怪しいんだ?

Slide 14

Slide 14 text

14 解決法: 再利用性 & 異常検知力UPを狙った多階層化 階層を細かく分割し、モデルのメンテナンス性 & テストによるデータ信頼性を高めている。 DataLake raw data DataMart layer ダッシュボード用 DWH layer 汎用分析用 Interface layer 不正除去など Component layer fact / dimension Source authorized view dbt tests filtering PII BI tool Looker Studio dbt exposures

Slide 15

Slide 15 text

15 課題: 意図せずダッシュボードを破壊してしまった際のリスクが大きい ダッシュボードの利用者が別組織で活動しており、必要となるタイミングが読みづらい。 ToBビジネスの性質上、「明日以降対応します」が通用しないシーンも発生。 BI チーム コンサルティングチー ム ・分析による提案・報告サポート ・レポート用ダッシュボード提供 ・データ基盤構築 ・レポーティング ・ソリューション提案 明日のプレゼン資料作りたいの にデータが表示されない ...

Slide 16

Slide 16 text

16 解決法: dbt exposuresによる影響範囲の可視化 dbt exposuresにより各データモデルとダッシュボードの紐付きが確認可能。 有識者に確認すべき変更が明確になることで、コミュニケーションコストも低減。 https://docs.getdbt.com/docs/build/exposures このモデルを触ると 次回報告に影響出そうだな。 事前相談しておこう!

Slide 17

Slide 17 text

17 課題: 手入力運用によりデータの状態が不安定 重要なマスターデータは手入力によって更新される運用となっている。 現状ローコストで実装できる入力ツール側の validation機能等では信頼性担保が難しい。 ・プロダクト機能実装 ・マスターデータ更新 運用 チーム 機能改修する余裕が ない... データを上書き しちゃいました... 入力担当者 管理ツール担当者

Slide 18

Slide 18 text

18 解決法: dbt testsによるチェック & dbt snapshotsによる変更履歴の保持 入力ツール上のvalidationのみに頼らず、データモデル側でもテストを書いて想定されるミスを検知。 snapshotsによる履歴管理によって変更状況を補足し、当時の状況をいつでも再現できるように。 dbt snapshots 監査対応など当時のデータが必 要な分析時も安心!

Slide 19

Slide 19 text

19 課題: 分析にあたって仕様ドキュメントの更新漏れが不安 カラム定義などのドキュメント更新はつい忘れてしまいがち。 分析の際に自信を持ってクエリが書けないと、レポーティング事故を恐れて生産性が落ちてしまう。 BI チーム ・分析による提案・報告サポート ・レポート用ダッシュボード提供 ・データ基盤構築 かなり前の情報だ ね。今の仕様は〜 新メンバー 有識者 定義書を参考に クエリを書いたけど数 値に違和感が...

Slide 20

Slide 20 text

20 解決法: 分析者向けドキュメントとしてのdbt testsの設定 日付・イベント別の指標テーブル なのね。イベントはNULL無しで3 種類あるみたい。 上流のテーブルで信頼性が担保されているカラムだとしても丁寧にテストを書く。 ドキュメントは更新漏れがありうるが、テストは常に最新の状態を教えてくれる。

Slide 21

Slide 21 text

21 dbtならではの課題: 特殊なテストにより、モデルの解釈コストが高くなってしまう dbtでは信頼性向上のためのテストがかなり自由に用意できる。 一方その自由度の高さにより、解釈コストの高いモデルが生まれてしまうことがある。 BI チーム ・分析による提案・報告サポート ・レポート用ダッシュボード提供 ・データ基盤構築 custom generic tests STRUCTの中身についてのテス トか...読むの疲れるな〜

Slide 22

Slide 22 text

22 解決法: 便利なテストに頼りすぎず、設計自体を疑う 複雑なテストを書く必要がある場合、モデルの分割が上手く行ってない可能性がある。 「クエリのシンプルさ」だけでなく「テストのシンプルさ」にも目を向けることでより良いモデリングに。 model A model B model C column① not null test column② not null test 【STRUCT】 column① column② not null クエリは一見シンプルでも テストを考慮すると別の選択肢 がありそうだな〜

Slide 23

Slide 23 text

23 まとめ ・分析結果が事業の成長にダイレクトに繋がる toBデータビジネスにおいては、数値ズレの重みが桁違い。  社内に閉じたデータ利活用とは意識を大きく変えて取り組む必要がある。 ・dbtは「アナリスト向けの便利ツール」の域を超えて、事業成長を直接支える武器となりえる。

Slide 24

Slide 24 text

24 おわりに Analytics Engineer & Data Engineer 募集中! Ubie Discovery 採用サイト