アナリストによる高度な分析フェーズ前のデータ利活用　Ubieのデータアナリストが語る、事業ごとの運用体制

データ活用事例1：製薬企業向け事業

酒井直人氏（以下、酒井）：1つ目の事例が、製薬企業向けの事業です。（スライドを示して）少し簡略化していますが、データ活用面での全体感はこのようなイメージです。真ん中のUbie Pharma Consultingのメンバーが製薬企業に向けてソリューション提案を行い、案件をいただいてから定期的にレポーティングを行うという流れになっています。

それを我々Ubie Discoveryがデータ分析によってサポートを行う体制です。この事業に関してはビッグデータの中のほんの一部だけが対象になる場面が多々あり、1件のズレで提案の実施可否や手段が変わったり、そもそもレポーティングの数値に誤りがあると顧客との信頼関係にヒビが入ったりします。当たり前のことですが、なかなか影響が大きいのがこの事業の特徴です。

（スライドを示して）そういった中で実際にどういう方法でデータ分析をサポートしているかと言うと、このようなかたちでかなり厳しい運用体制となっています。

具体的には、本当にガチガチに計算されたデータマートの数値のみをBIツールを通して提供していて、事業スピードの担保とデータ信頼性のバランスでいうと、データ信頼性特化型のような運用になっています。製薬企業に用いるデータを独自で集計して運用していくのは、先ほどお話しした観点で、事故の元になるということが背景としてあります。

スピードを重視したい場面はもちろん、社内での意思決定の場でもあるので、そういう場合はアナリストがアドホック分析にリソースを割くことで、信頼性を維持しつつスピード感もなるべく落とさない運用となっています。

データ活用事例2：To C向けプロダクト開発チーム

次が、「ユビーAI受診相談」というTo C向けのプロダクトを開発しているチームの事例です。この例では社外のステークホルダーにデータを提供するのではなく、プロダクトの改善のためにデータ分析をするという、一般的な活用方法になっています。

（スライドを示して）図にもあるように、同じプロダクトに対して複数のチームがスクラム開発をしていて、それぞれが分析を行いながらプロダクト改善を行っています。

このユビーAI受診相談チームは、日頃の分析をアナリストがメインで行っているわけではなく、開発チームのメンバーが主体的に分析を行っています。左にSlackのスクショを載せていますが、ソフトウェアエンジニアがRedashで自分でSQLを書いて可視化して、示唆も共有して議論を進めていくような動きは、Ubieでは日常茶飯事になっています。

新しく入社したメンバーのアナリストが大きめの分析にしたりもしています。ですが、アナリストはどちらかというとデータ基盤の整備にリソースを割いて、開発チーム内でアナリストがいなくてもある程度回せる環境作りに今は力を入れています。

右のスクショは、先ほどお話したInterface層を整備してWHERE句で除くべき条件がいろいろあるのはありがちだと思いますが、そういうものがなく、簡単に集計できるものを提供して、なるべく集計ミスが起こりにくくする動きを取った時のものを参考として載せています。

こういう状況のため、扱えるデータはかなり広い範囲になっています。先ほどの製薬事業はBIツールだけでしたが、これはローデータ以外の部分もすべて自由に触っていいぐらいの広さになっています。というのも、日々仕様がどんどん変わっていく中で、毎回信頼性を担保したデータマートの構築をアナリストが行うようなスタイルをやっていくと、ぜんぜん間に合わないぐらいの事業スピード感であるところが要因です。

裏を返せば、先ほどお話した製薬企業向け事業と比べると、やはりちょっとした集計ミスは発生してしまう危険性はあるのですが、影響範囲はあくまで社内の小さめの意思決定にとどまるところも多いので、リスクは一定許容する運用となっています。

データ活用事例3：医療機関向け事業

3つ目の事例は、医療機関向け事業です。この事業はTo B向けのSaaSの事業ということもあって、医療機関という顧客とのやり取りと、プロダクトの改善の両方が日々行われています。To C向けのサービスと同様にプロダクトの改善のための分析は行いつつ、Customer Success活動のためのデータ提供を、社内の別組織のUbie Customer Scienceに対して行うようになっています。

この事業に関しても、To C向けのユビーAI受診相談チームと同様に、エンジニアやBizDevのメンバーがプロダクトの改善のために分析を行います。

一方で、Ubie Customer Scienceの営業系の組織や、オペレーションまわりのユーザーサポートのメンバーが、SQLを書かずに個別の医療機関のデータを確認したいシーンは多くなっています。

そのため、アナリストが扱いやすいダッシュボードを整理して全社的に共有する動きをとっているのも、この事業の特徴かと思っています。（スライドを示して）ちなみに、これはデータポータルというGoogleが出しているサービスを使ったもので、そこをアップデートすると全社的にこういう使い方をしてほしいところを記載して共有する動きをとっています。

というところで、医療機関向け事業のデータの運用体制は、このようにやや複雑な構成になっていますが、1つ目の事例の製薬企業向けの事業はけっこうガチガチに計算されたBIツールしか見ないくらいの感じですが、2つ目のTo C向けのサービスがわりとゆるめで、ローデータ以外はぜんぜん大丈夫な感じで、医療機関向け事業はハイブリッドな運用となっています。

（スライドを示して）Ubie Discoveryのメンバーに対しては、青枠のInterface層から出たBIツールまでゆるめに広く共有していて、Ubie Customer Scienceのメンバーに対しては、BIツールとDataMart層の一部をAuthorized Viewで共有しています。

背景としては、組織がはっきりと分かれていて、独自の定量手法が乱立した場合に別組織から統制が取りづらく、コミュニケーション上混乱を生むよくない流れになるリスクが高いところがあります。なので指標の一貫性を保ちつつ、ある程度データを利用した活動を行えるように、定量指標やセグメントの分類のルールを定義したテーブルを共有するに留めています。

医療機関とのコミュニケーション時にデータの信頼性は大事になりますが、製薬企業向け事業ほどガチガチにしなくてもそれ自体がレポーティングのようなやり取りをしているわけではないので、多少のリスクは許容できるところもあります。サクセス活動のために、一定の自由度を残してUbie Customer Scienceのメンバーにも動いてもらう運用になっています。

現状は開発スピードと信頼性担保のバランスが優先事項

事例は以上で、まとめに入りたいと思います。Ubieのデータの利活用の現在地としては、アナリストが高度な分析をガンガン回して意思決定を向上させていくフェーズではなく、今は事業開発のスピードやデータの信頼性の担保のバランスを意識した動きに注力するフェーズになっています。

事業スピードが速くて、アナリストのリソースもかなり限られているという中では、やはり高度な分析で価値を出していくよりも、ちょっとした分析を社内で素早く複数回せるようにしたり、必要に応じた信頼性担保のための環境作りをするのが、一番ROI（Return On Investment）が高いという判断をしています。

アナリストによる意思決定精度向上注力フェーズもいずれ訪れると思いますが、もう少し先になりそうな印象を持っています。またフェーズが進んで分析による価値提供部分などでおもしろいテーマが出てきたら、このようなイベントや各種noteなど、弊社メンバー記事で発信していくのでぜひご覧いただければと思います。私の発表は以上です。ありがとうございました。

質疑応答：Interface層→component層の転送方法は？

司会者：酒井さん、ありがとうございました。それでは質疑応答に入りたいと思います。「Interface層→component層はどうやって転送しているのだろう？」という質問がきています。

酒井：僕の図が説明不足だったのかもしれませんが、Interface層にあるテーブルを加工して、Component層のテーブルを新たに作っています。形式でいうと、Interface層はほとんどテーブルではなく、Viewで作られています。

Component層の説明をしていないので、手短に説明をします。例えば、いろいろな行動ログが何種類かある中の特定の行動のみのComponent層のテーブルを作るSQLを書いて、dbtで実際テーブルを作っているのですが、そのモデルをこのComponent層のデータセットに配置します。

転送というよりは、それを順々に作っていってテーブルが積み上がっているかたちです。dbt特有というよりは、データパイプラインの一般的なやり方と考え方から大きくズレないかなと思います。回答になっているかわからないですが、もしわかりにくければTwitterなどでメンションをもらえれば、もう少し詳細にお話ししたいと思います。

質疑応答：ツールの使い分けは？

司会者：ありがとうございます。まだコメントがきていないようなので、僕のほうから質問します。（スライドを示して）今画面には、BIツールでRedashやTableau、データポータルなどいろいろ映っていますが、このあたりの使い分けはどのようにされているのでしょうか？

酒井：それでいうと、僕も入社してまだ5ヶ月ぐらいでしたが、たぶん歴史的経緯がいろいろあるんじゃないかなと正直なところ思います。もともと使っているツールをリプレースするのはコストが高いので、残している部分もあります。それ以外のところで社内の使い分けで言うと、現場の開発メンバーのSQLを書くような場面では比較的Redashがよく使われています。

データポータルは先ほど別のスライドに載せたのですが、全社的にみんなが見るダッシュボードを作る時に権限設定などをしやすく、またビジュアル的にも管理しやすいので、よく使っています。

Tableauはこの中ではわりとリッチめの可視化ができる場面があったり、設定が細かくできたりするので、状況による使い分けだと思うのですが、正直なところ、僕の認識ではわりといろいろなツールをみんなが使い始めたのがきっかけかなと思います。

司会者：なるほどです。ちなみにHostedのRedashが2021年11月に終了しましたが、酒井さんとしてはこのあたりは何か影響があって大変だったりしましたか？

酒井：それで言うと弊社のメンバーがすごいスピードでRedashを移行してくれたので、私自身は特に問題がなくスムーズにできました（笑）。

スライド17

質疑応答：“信頼性”の数値化・測定はしているのか？

司会者：頼もしいですね。では「“データの信頼性”という言葉が何回か登場しましたが、この“信頼性”は何らかの数値指標で定量化したり計測したりされているのでしょうか？」という質問ですが、こちらはどうですか。

酒井：これに関してはものによるところで、自分自身はものすごくシビアなところをあまり見ていないので、詳細を話しづらくて恐縮です。ただ、ものによってはSLO（Service Level Objective）・SLA（Service Level Agreement）みたいなところで、何パーセントという設定をして、日々確認するものが多く存在します。

他のところではdbt testsでnullがあったりなかったり、カラムがユニークかどうかは必要なところでテストを用意して、それのエラーがあるかどうか判断する場面が多いので、現状すべてを数値管理しているわけではないのが正直なところです。

ものによって、顧客に提供する数値など管理しているということも一応想定していますが、他のメンバーがわりとそこに注力していたので、まだ私からはしゃべれないのが現状です。他のメンバーの発表などで触れているところがあったと思います。弊社のデータエンジニアで“sotaron”という名前で活動している田中聡太郎が発信していた記憶があるので、少々お手数ですがその資料もご覧いただけるとうれしいです。

質疑応答：エンジニアが自発的に分析を行う仕組みがあるのか？

司会者：ありがとうございます。次は「アナリストではなく、エンジニアが分析を自発的に行うために何か仕組みがあるのでしょうか」という質問です。

酒井：これは明確に仕組み化されているかというよりは、各メンバーが本当に主体的に動く文化からくるものかなと私は思っています。世でデータの民主化を推進するみたいなことがよくあるかと思いますが、こちらからデータの民主化を働きかけずに「なんならささっとクエリを書いて出しちゃおうぜ」という空気感が本当に自然にあるところです。

僕が前職のやや大きめの会社にいた時はそのあたりで苦労したのですが、そんなこともなく、むしろガンガン勝手に動くという表現が一番近いかと思っています。

質疑応答：レイヤーの使いわけの詳細は？

司会者：ありがとうございます。今度は「Interface層、Component層、DWH 層、Datamart層をどう使い分けているか、をもう一度お話してもらえませんか」ということです。

酒井：気になるかなと思ったのですが、話すとこれだけで時間がかかってしまうので割愛しました。

今答えられる範囲で言うと、使い分けとしては、Interface層は元データを加工して、明らかに異常なデータを弾いていて、Componentレイヤーは各イベントの中で特定のイベントのログだけを落とします。

DWH層はやや複雑なものを扱いやすいものにしていて、DataMart層では本当にBIツールで可視化するためのメトリクスや、Tableauでドリルダウンするためのテーブルになっています。

質疑応答：医療データならではの難しさはあるのか？

司会者：では次に、「Ubieのデータアナリストをしていて、医療データならではの難しさを感じることはありますか？」という質問です。

酒井：僕が触っている範囲が実はそれほど医療寄りではないところなので、僕自身はそこまで感じないです。医療データならではのすごく広い話になると、個人情報まわりなどに（難しさを）感じるので、いわゆるTo Cサービスでセンシティブな情報を取り扱う場合は、管理的な難しさがあるのかなと思います。日々の分析で私は医療の範囲はやらないので、今のところはないという回答になります。

質疑応答：集計のミスをしないための運用方法は？

司会者：ありがとうございます。次に「製薬企業向けのデータについて、集計のミスがないようにしている運用を知りたいです。例えば、とある診療行為を絞り込む集計ができていなかった例にも気づくことができるのでしょうか」という質問です。こちらはどうでしょう。

酒井：どのようなデータを扱っているのかに関してはNDAの関係などであまり触れませんが、集計のミスをしないようにする運用は、結局BIツール側でアドホックなSQLを書いて提供する運用を取らないスタイルに集約されていると思っています。

（スライドを示して）今ちょうど映っている各レイヤーの中では、それぞれ社内の社員のレビューを通すし、dbtのテストも通します。最終提供時点のTableauで、ものすごく複雑なカスタムクエリを書くことはなくて、DataMart層のテーブルをBIツールに食わせるような運用ばかりなので、集計のミスがないようにする運用に関しては、そもそもそうならないように作成していくためにレイヤーを分けたり、dbtのテストを書いたりしています。

それから、まだすべてできるわけではないですが、dbtのテストの中に「このテーブルのこの数字と他のテーブルのこの数字が一致しているべきだ」というテストが書けるので、そういったものを充実させることによって、「こことあっちの数字が違うよね」という状況が排されたりします。

ほかには、どちらかというと集計ミスより各々が違うデータを見てしまっている方がリスクとしては大きいので、「そもそも見るべきダッシュボードはこれですよ」と、運用のところでカチッと定めたものを提供することで対策しています。これは回答になっているかわからないのですが、大丈夫ですか？

司会者：大丈夫じゃないでしょうか。定義も人によってまちまちだったりすると、同じことを言っているんだけど、みんな別の定義で集計しているみたいなことは起きがちですよね。

酒井：そうですね。