自己紹介とセッションの概要
酒井直人氏（以下、酒井）：では「Ubieにおけるデータ利活用の現在地」を始めたいと思います。はじめに簡単な自己紹介をします。私はUbie Discoveryでデータアナリストをしている、酒井直人と言います。Ubieに入社したのが2021年の7月で、5ヶ月ほど経ったところです。前職ではゲーム会社のデータサイエンス部門で分析チームのリーダーをしていて、アプリのログ分析やマーケティングリサーチなどを行っていました。
Ubieでは現在の職種どおりデータ分析を行う一方で、データマネジメントをデータエンジニアのメンバーと共同して行ったり、To C向けのサービスのUXリサーチのオペレーション業務などを行ったりしています。趣味は前職でゲーム会社にいたのもあって、対戦ゲームが好きです。
（スライドを示して）左の黄色い鳥は、自分がよくSNSのアイコンで使っているものですが、“ジャズ”と言っているように、わりと音楽が好きです。本日はよろしくお願いします。
本日のテーマは、Ubieのデータ利活用体制です。事業や組織の現状と絡めつつ、テーブル設計やデータの品質の担保の仕組みなどについてお話ししていきたいと思っています。
（スライドを示して）これは弊社のデータ系の職種向けの採用資料から持ってきたベン図です。今回お話しするスコープは赤文字のところで、データエンジニアとデータアナリストに被っているデータ基盤開発・運用と、マート整備と活用推進を主に話していきたいと思います。
（スライドを示して）大きくこの3本立てです。最初に組織と事業の現状について、2つ目にデータ利活用の技術的工夫について、最後に現場でのデータ利活用例についてお話しします。「データの話を聞きに来たんだけどなんでそこから？」と思う方もいると思うのですが、Ubieはやや特殊な組織体制を取っていて、前提知識がないとピンと来づらいところもあるかな、というのが背景です。
Ubie社全体の事業構造
では、さっそく組織と事業の現状についてお話ししていきます。まずはUbie社全体についてです。（スライドを示して）図にあるように大きく3つに分かれていて、事業としては医療機関向けの事業と、製薬企業向けの事業の2つに分かれています。加えて、組織は事業フェーズを加味して分割しています。
赤い枠のUbie Discoveryは私が今所属している組織で、0→10のフェーズの事業を限定せずにガンガン回しています。少し重複しますが、Ubie Customer Scienceが医療機関向けで、セールスやカスタマーサクセスを行います。Ubie Pharma Consultingは、製薬企業に寄り添ったコンサルティングサービスを行っています。
この組織の分割については形だけ分けているのではなく、本当にガッツリ分かれています。例えば、Slackのワークスペースを完全に分けていて、Ubie Customer ScienceのメンバーやUbie Pharma Consultingのメンバーとやりとりする時は、共有チャンネルを作って、他社の方と話すぐらいの距離感で接しているぐらいです。距離感はグループ内の別会社ぐらいと説明するのが、わりと一般的なイメージに近いかと思います。
そんな中で事業の状況としては、Ubieは同時多拠点突破を掲げていて、現在日本以外にシンガポールにも拠点を設けてグローバルに展開しています。プロダクトとしては、To C向けの「ユビーAI受診相談」と、To B向けのSaaSの「ユビーAI問診」の2つのサービスがあります。プロダクトとしては2種類ですが、事業としては製薬企業向け事業を細分化したものがいくつかあって、複数のチームで開発を進める流れになっています。
プロダクトの開発状況は、To C、To Bのどちらのサービスもスクラムのアジャイル開発を実施していて、日々機能追加や検証のための新しい施策が実施されています。To CのユビーAI受診相談は、年間600回リリースをしていて、To BのSaaSのユビーAI問診でも150回と非常に高頻度で改善が行われています。そのため、必然的にデータ分析と向き合う機会がかなり多いというのが、Ubieの事業やプロダクトの特徴だと思っています。
Ubie内のデータ組織
（スライドを示して）そんな中でデータの組織がどうなっているのかは、あまり外に発信してこなかったかと思っているのですが、現在はデータアナリストとデータエンジニアのいるチームから、それぞれの事業組織に出向する体制をとっています。
Ubie Discoveryは“ホラクラシー”という、ちょっと変わった組織形態を取っていて、やや説明が難しくなりますが、いわゆるデータ分析組織の枠組みでの事業部別組織と機能別組織を両立しているようなイメージが一番近いかと思います。
ややぼやけているかもしれませんが、図にあるデータ利活用による意思決定の精度・最大化は、チームの中に事業ごとの担当を立てるイメージで、この画像では医療機関向けの事業データ利活用推進に3名、製薬企業向け事業のデータ利活用に2名がそれぞれアサインされています。
（スライドを示して）もう少し具体的に図解したのがこちらです。大学のサークルを掛け持ちしているイメージが実はスッキリするかと思います。自分の例だと、図のBの青い人に該当していて、データ利活用サークルの中で制約事業向けの担当のロールと、医療機関向けの事業の一部をサポートするロールを担当していて、かつそれぞれの事業チームでも分析ロールをそれぞれ割り当てられているイメージです。
データアナリストという職種でもあるのですが、サークルはこのデータ関連に限らず、先ほどチラッと自己紹介でもお話した、To C向けサービスのUXリサーチのロールや、他の会社でいうと人事が担当していそうな、新入社員のオンボーディングの推進も担当しています。
ちなみに、データ系の職種は我々のいるUbie Discoveryのみ在籍していて、専任のデータアナリストが今月（2021年12月）1人入社して、ようやく自分を含めて2人になったところです。そのため、現状は機械学習エンジニアのメンバーが兼務的にアナリスト業務を行っていて、リソースとして余裕がある感じでは決してないというのが正直なところです。
最後に、このような組織や事業環境でどのようなデータ利活用を行っているのかについての本題に入る前に、前提としてどういう意識でやっているのかを少しお話ししたいと思います。前提としてこの事業開発のスピードを担保するところと、データの信頼性を担保するところのバランスを意識しています。
データ活用によって事業開発を早めることはもちろん維持しつつ、一方で、信頼性の高いデータだけを触って分析してほしいというのも正直なところですが、やはり潤沢とはいえないリソースでは、信頼性が高くてかつ扱いやすいデータを各領域で整備するのはなかなか難しく、日々問題に直面しています。
Ubieの技術的・運用の工夫：dbtを用いたデータの品質の管理
このような状況で、Ubieがどのような技術的な工夫や、運用の工夫を行っているかについて、このあと紹介できればと思っています。まずはデータ利活用の技術的工夫についてお話ししていければと思います。ここではデータの信頼性担保を中心に取り上げようと思っています。
（スライドを示して）1つ目に、dbtを用いたデータの品質の管理が挙げられます。弊社はGoogleのBigQueryを用いていて、テーブルの構成としては一番左にあるDataLake層のいわゆるローデータから始まって、Interface層、Component層、DWH層、DataMart層、そしてBIツールに接続するかたちでテーブルを分けつつ、各所でdbt testsを挟んでいます。
突然現れたdbt testsとは何かを手短に説明すると、dbtのツールを用いたもので、例えばテーブルの中の特定のカラムで入ってはいけないカラムにnullがあったり、ユニークであるべき何かしらのIDが重複していたりなど、想定とは異なる挙動があった時に検知できる仕組みだと、いったんは認識してもらえればと思います。
dbtの利用の詳細については、ここでは割愛できればと思います。dbtについて深く知りたい方は、最近は日本語での解説記事も徐々に増えてきている印象なので、後ほどGoogle検索などをしてもらえると、より深く理解が進むかと思います。
（スライドを示して）構成を維持するための工夫としては、GitHub上に設計ルールをドキュメントとして用意して運用しています。これが用意されたのは実は比較的最近で、作ったことによって、どの層にどういう種類のテーブルがあるべきかという共通認識を各メンバーが持てるようになり、全体の構造がすごくわかりやすくなった印象を受けています。
具体例を1つあげると、Interface層のローデータを加工したところです。Interface層はソーステーブルをそのまま使うと、思わぬ罠が潜んでいるようなところがあるので、適切な前処理をかけて安心して使える元データのような立ち位置になっています。
具体的には不正データの除外や、カラム名の明瞭化が挙げられます。Interface層以外のComponent層にもどういう設計をしているかのルールが記載されていて、モデルを設計する際に、信頼性が高くかつ再利用性も高いテーブルが作られやすい仕組みとなっています。
Ubieの技術的・運用の工夫：レビュー体制と異常検知の仕組み
次はレビュー体制と異常検知の仕組みです。新米メンバーのクエリや複雑なクエリのみチェックするような運用フローは、僕のイメージではわりと一般的かと思いますが、Ubieではちょっとした変更の場合でも、GitHub上で相互にレビューをする体制を取っています。
また先ほどお話ししたdbtのテストに関しても、Slackでエラーの通知や、週に1回の同期的なミーティングを行い、そこでメトリクスとしてエラーを確認する時間を設けています。このように、テクニカルなdbtやテーブル構成の話だけではなく、運用面も地味ながら信頼性担保を意識した動きを取っています。
最後に、実際の現場でどのようにデータを活用しているのかについて話したいと思います。先ほどの技術的な工夫の話はわりとデータ信頼性担保寄りでしたが、このあとの話は、どちらかというと事業スピードの担保とバランスの観点について、具体例をあげつついくつか紹介できればと思います。
（次回に続く）
