コンパウンドスタートアップを目指す estie のデータ基盤の現状

estie データマネジメントプラットフォーム (DMP) チームのソフトウェアエンジニアの和田です。
私については → 入社エントリ

この記事の内容

さーて、今回の estie inside blog は

estie, コンパウンドスタートアップ目指してるってよ
コンパウンドスタートアップを目指す estie のデータ基盤の現状
採用強化中です！

という内容になっております！それでは本編どうぞ！

estie, コンパウンドスタートアップ目指してるってよ

2022 年 1 月、estie は商業用不動産業の各業務フェーズでの課題を解決しつつ、それらのソリューションを相互に連携させる構想を打ち出しました。当時は「マルチプロダクト戦略」と呼称していましたが、この構想はまさしくコンパウンドスタートアップそのものです。
現段階の成果として、2020 年から運用している賃貸領域の市場調査業務のための「estie マーケット調査」に加えて、売買領域の業務課題を解決する「estie物件売買」「estie 案件管理」を最近公表しており、コンパウンドスタートアップ企業としての芽が出つつある状態です。

会社としてコンパウンドスタートアップを目指すことについての詳細については、弊社代表平井の記事「【実践編】コンパウンドスタートアップの作り方」や束原の記事「コンパウンドスタートアップに潜む矛盾と困難、その先に広がる世界」を是非ご確認ください。

estie のデータ基盤の現状

コンパウンドスタートアップを目指す上で、重要なのが「複数のプロダクトが相互に連携すること」です。
今回は、その連携を担う estie のデータ基盤の現状を紹介させていただきます！

データ基盤: Snowflake

estie では、プロダクトで使用するデータを加工する場、および、プロダクトについて社内で分析する場として Snowflake を採用しています（「estie、Snowflake を導入しましたよ」）。
ここでいうプロダクトとは、お客さまに提供している「estie マーケット調査」や「estie 物件売買」だけでなく、各プロダクトで共通的に使用する建物や募集といったデータを作るパイプラインのようなものも含まれます。データ基盤としては Snowflake の 1 アカウントに、それらのプロダクトやチームの全てのデータを乗せています。

プロダクト間のデータのやりとり

コンパウンドスタートアップとして各プロダクトの連携をスムーズに行うためには各プロダクトのデータのやりとりが必要ですが、estie が提供しているプロダクトはお客さまの業務に直結しています。たとえ社内であっても全てをオープンにすることはできません。
そこで、それぞれの DB の中でスキーマを作成し、そのスキーマをインターフェースのように使うことでアクセスコントロールをしています。データアクセス用の View は dbt を使って作成しており、この View の中で公開したくないカラムを落としたり、匿名化・統計化などの必要な加工を行うようにしています。

1 アカウントに全てのデータを乗せているものの、現状はデータメッシュっぽいアーキテクチャを目指しています。どのデータを公開するかを自分たちでコントロールできるようにすることで、各プロダクトチームが自走できる環境を構築しようとしています。

個別のプロダクトに注目した時のデータの流れ

各プロダクトのデータ（RDS の DB のデータ、S3 上のプロダクトのログなど）は Fivetran と Snowpipe を使って取り込んでいます。
同じアカウントに全てのデータを乗せている弊害ではあるのですが、ストレージ統合を自由に使って任意の S3 にアクセスできてしまうとセキュリティ的に問題があるため、S3 上のログを集める仕組みは DMP チーム管理の一つのプロダクトとして、↑ と同じくスキーマを通して各プロダクトチームに提供するようにしています。

プロダクトチームは、チームに向けて公開されているデータを使って、プロダクトの分析を行ったり、プロダクト用のデータを更新するパイプラインを作ることができます。

データ基盤の開発・運用

各プロダクト DB のリソースは Terraform と dbt で管理していますが、これは 1 つの GitHub リポジトリで管理しています。CODEOWNER を設定し、各プロダクトチームで完結して Snowflake のリソースの変更を回せるようにしています。
一方で、role の作成・付与やストレージ統合の作成・参照など、admin 権限が必要になるようなリソースについては自由に変更できるようにするわけにはいかないので、admin 権限用のリポジトリを別で作成し、DMP チームのレビューを必須にする運用としています。

各プロダクトチームは、自分たちの DB リソースを管理することができるので、スキーマを作って別のプロダクトとデータを連携させたいときに、DMP チームを挟まずに実行することができます。これによって、プロダクト間のデータ連携の検討をスムーズにできるようにしています。

データ基盤の全体像

ここまで、まとめますと

estie は snowflake をデータ基盤として、全てのデータを集約している
各プロダクトのデータは、ロールとスキーマを用いてアクセスコントロールしている
各プロダクトのデータは各プロダクトチームで管理され、データメッシュを目指している

という状態です！

設計で迷った部分

データ管理のアーキテクチャは分散か？集中か？ → 分散（データメッシュ）

コンパウンドスタートアップを目指して同時に複数のプロダクトの立ち上げが走る環境において、データ管理を集中的に行うと DMP チームがボトルネックになる可能性が高いと判断し、分散的なデータメッシュのようなアーキテクチャを目指すことに決めました。

Snowflake のアカウントや GitHub のレポジトリを分割するか？ → しない（共通リソースに相乗り）

コンパウンドスタートアップという概念は非常に美しくはありますが、実際に実行に移すのは難易度が高いと予想されます。単発でもプロダクトを立ち上げるというのは大仕事で、そのプロダクトのデータが他のプロダクトと連携されて価値を生むというのはそれ以上に難しいでしょう。綺麗に連携された状態になるまでは、スクラップアンドビルドに近い試行錯誤が必要になるはずです。
そのような環境下で DMP チームが横断的に介入するために、リソースの場所は一元的にまとまっている方が良いだろうと判断しました。

直近の課題

データ基盤はこれで完成ではなく、まだまだ課題があるのでこれからも形を変えていくと思いますが、直近では各プロダクトチームとの連携が大きな課題であると捉えています。

個人的には「こういう構成にしたらうまくコンパウンドスタートアップを実現するデータ基盤ができるかも！」と楽しく進めていますが、分散型のデータ管理形態をとろうとしているので、プロダクトチームから見ると Snowflake, Terraform, dbt といった馴染みのないツールでのデータ管理タスクを積まれているような状態とも言えなくもありません。

各プロダクトチームに、自分たちのプロダクトのデータを正しく管理してもらうために必要な作業を徹底的に軽くして、うまくプロダクトチームと連携をとることを直近の目標としています。