秘伝のたれを解放する：小規模チームではじめたdbtの導入例

PREVENTで扱うデータは、健診データ・レセプトデータなど、医療に関する専門性の高いデータが多いため、一からデータを扱う際には、医療ドメイン理解と、一定の経験が必要になります。 他部門からのデータ抽出依頼に対しては、データサイエンスチーム全体で対応できるような体制をとっていましたが、当時は、4名の小規模なデータサイエンスチームだったこともあり、各メンバーが秘伝のタレのように伝承した加工ロジックをもとに作業をしていました。

そのため、以下のような課題がありました。

1. 解析知見の属人化とフロー化

   依頼に対してアドホックに解析を行っていたため、解析の知見が蓄積されず、毎回流れてしまうフロー化の現象が起こっていました。上述した通り、その中の一部の知見が「つぎたし」されて、共有されていました。

2. 依頼対応の長時間化

   依頼に対応する場合には、「既存のロジックを理解する」、「要件にあわせて新規にロジックを追加、修正する」という工程が必要になり、出力までに時間がかかっていました。

3. セキュリティリスク

   データには、個人に紐づく医療情報など、センシティブなデータも多いですが、データソースから直接データを加工する必要があったため、各種データの閲覧権限が統制されていませんでした。そのため、過剰な権限となっており、これがセキュリティ上のリスクとなっていました。

4. データ品質の低下

   加工のロジックは、各メンバーにまかされており、それぞれが独自に作業を行っていました。そのため、出力するデータ品質が担保できていませんでした。

どのような状態を目指していたか

上記の課題から、データ品質を担保するだけでなく、チーム全体の業務効率化、依頼への迅速な対応を実現するため、以下の状態を目指しました。

• 既存の加工ロジックを第三者が理解できるようにしておく
• データの公開範囲と権限を明確にして、過剰な権限を減らす
• データ加工ロジックの共通項をぬきだし、汎用性のあるデータウェアハウスを作成する。
• 加工ロジックを共有し、知見が流れるフロー型の仕組みから、知見を蓄積できるストック型の仕組みをつくる
• 他部署メンバーでも、簡単なデータ抽出と加工を行えるようにする

• Python
• dbt Core（開発の実行環境で採用）
• dbt Cloud（本番の実行環境で採用）

1. 導入時のコストと運用コスト

   当時は、データ基盤に（時間的、金銭的）コストをかけておらず、また、運用を担当するデータエンジニア1名の体制だったため、いきなり大きなコストはかけられませんでした。

2. 拡張性

   今後データ量やデータ利用者が増えた場合でも対応できる、拡張性のあるデータ基盤をつくれることも大事な観点でした。

• SQLという使い慣れた言語で、データモデルが定義できるため、学習コストが低いこと
• 開発が盛んに行われ、他社での導入事例も増えていたため、情報が多いこと
• dbt Coreを開発、dbt Cloud（developer）で本番環境実行をすることで、金銭的なコストがほぼかからないこと

導入の成果

• データの依頼から出力までの時間が大きく短縮され、誰が出力しても同じ品質でデータを出力できるようになった
• 解析の知見がデータ基盤に反映されることで、知見がストックされるようになった
• 他部署メンバーが自らデータを抽出できるようになり、社内のデータ活用の意識が高まった
• データ抽出と加工の工数がかからなくなったため、本来の分析業務に避ける工数が増えた
• データマネジメントの観点を導入し、より高品質・高付加価値な生み出すことに時間をつかえるようになった

導入時に苦労したことと、その対応方法についてです。

• 汎用的なデータウェアハウスの作成
  • 苦労点：様々なユースケースに対応できるデータ基盤をつくる必要があった
  • また、データモデリングの理解も必要であったため、学習コストがかかった
  • 対応：解析のユースケースを知るデータサイエンティストと共同しながら整備を進めた
• データドメインの理解とデータカタログ化
  • 苦労点：各データソースのデータドメインを理解し、ドキュメントにする必要があった
  • 対応：データ生成元のビジネスメンバーや、バックエンドメンバーとコミュニケーションをとりながら、データカタログを整備した
• 権限整理
  • 苦労点：他部署メンバーへデータ基盤を公開したことで、データの公開範囲を整理する必要があった
  • 対応：社内のセキュリティ要件や役職によるユースケースを洗い出し、過剰な閲覧権限を避けつつ、データ活用が阻害されない塩梅で権限を整理した

dbtの導入によって、少人数規模のデータチームであっても、目指していた理想形に近いかたちで、データ基盤を作成することができました。一方で、dbt1.8から導入されたunit testsの実装や、ジョブの実行を監視するためのelementaryの活用など、データ品質をより高めるために、運用フェーズでやるべきことは課題として残っています。

今後は、より使いやすく、より高付加価値を生むことのできるデータ基盤を目指し、dbtを中心としたデータマネジメント体制を作っていきたいと思います。