estie VPoEの青木信（kirin_shi）です。
【 プロフィール】 青木 信（あおき しん）
1991年生まれ横浜育ち。
東京大学数理科学研究科修士課程を修了後、2016年にアクセンチュア デジタル（当時）に入社。
"ビッグデータ"を軸足に、官公庁関連のデータ基盤刷新プロジェクト、小売業界のCRM基盤構築プロジェクト、通信業界のグループ会社全体への機械学習プロジェクトなど複数の案件に従事。2019年11月よりestieへVPoEとして参画。
コロナ禍でとてもかわいいハリネズミのerizoと棲み始めた。
最近は、世にも珍しい（？）2人のVPoE青木がいる体制となり、主に技術面をリードする職責を担っています。
本記事では、Whole Product構想についてVPoP久保が熱く語ったこちらの記事を受け、その中心となるデータ基盤の技術的なチャレンジについてより深くご紹介します。
これまでのestieにおけるデータの役割
Whole Product構想の話を理解するために、まずはestieという会社の「データ」との関わりの特殊性に触れたいと思います。
データ自体が売り物
estieという会社では創業以来、データが重要かつ独特な役割を担ってきました。
多くのスタートアップでは「データ基盤」という単語で思い浮かべるユースケースは、事業KGI/KPIのモニタリング、分析を元にした社内意思決定の支援、プロダクトの機能/顧客の状態把握といったものではないでしょうか。
estieでは、上記のようなデータ活用に加えて、いわば「データ自体を売り物」にしてきました。例えば、estie proでは、建物・募集・入居テナントといった情報と、利用しやすいWebアプリケーションUIをセットにして提供しています。
高品質なデータを創出するデータパイプライン
サービスに最新データを届けるために、データの専門チームが自動化されたデータパイプラインを構築し、改善してきました。
現状のオフィス不動産業界では、多くの情報はPDFやFAXでの配布、打ち合わせや飲み会の場での口伝でやりとりされています。estieで取り扱うデータの多くも一度以上手入力のプロセスを経てestieの元に集まっているデータであり、ソースとなるデータの品質が高くない状態です。
このような低品質データから高品質なデータを創出するために、estieのパイプラインではいくつかの工夫を取り入れています。
- 複数データソースの統合
- 日本では誰も保持していない網羅的なデータを作成するため、とあるソースからのデータを正しくETLするだけでは十分なデータを得られません
- そのため複数の企業から少しずつの情報を受領し、それらを統合することで網羅的なデータセットの構築を目指しています
同一ビル・区画を推定するマッチングアルゴリズム
- 各ソースからの情報には、同一のビルが異なる表現をされているレコードが含まれます
- 業界全体に共通化されたID基盤（小売り業界でいうJANコードや個人でいうマイナンバー）が存在しないため、オフィス名や住所を元にした名寄せ処理が必要です
- 区画についても、分割/統合して柔軟に貸し出せるため、部屋番号でユニークにすることが困難です
- 部屋番号なしで、入力に揺れがある重複する情報をユニークにするために、同一区画を推定する曖昧なマッチングのアルゴリズムを適用しています
- 重複可能性のあるデータ（部屋番号はなく、入力の揺れがある）をユニークにするために、同一区画を推定するマッチングのアルゴリズムを適用しています
社内アプリケーションによるデータ修正作業の民主化
- オフィスビルが売買されてオーナーが変更された場合など、機械では同一であることが判定不能なものとなってしまいデータが重複することがあります
- このデータを修正するために、SQLやPythonなどの技術的なスキル無しに利用可能なツールを運用し、修正作業を社内全員に開かれた（民主化された）ものにしています
- 詳しくは卵料理はデータチームの救世主となるか - estie inside blogもご覧ください
Whole Product構想のコアデータ構築の技術的な課題
ここまではestieがこれまで取り組んできた事業と、そのために必要だったデータとの向き合い方についてご紹介してきました。
ここからはWhole Product構想を経て、このようなデータとの扱いがどう変わっていくか、どんな課題があるかに触れていきます。
コアデータは土地と建物
estieが追い求める「Whole Product構想」-マルチプロダクト戦略から1年後の今- - estie inside blogでご紹介したとおり、「コンパウンド・スタートアップ」ではデータを中心にサービスを統合していきます。
Whole Product構想を実現するに当たり、estieではそのコアデータを「土地と建物（それに紐づく様々なデータ）」と仮説づけています。
建物やその区画については、これまでestie proへの高品質なデータ提供のために構築してきたパイプラインが応用出来そうです。
しかし、実際に昨年より複数プロダクトを開発しユーザに使って頂き、それらのプロダクトのためのデータ準備もデータチームで担うなかで、今後も全プロダクトのコアとして使うことを見越すと、今の基盤・チーム体制では対応しきれない課題も見えて来ました。
[課題1] 取り込むデータ種類の増加
サービスの拡張に伴いユースケースを満たすために必要な、建物に紐付くデータの種類はどんどんと増加していく見込みです。
これらのデータは正しく取り扱うために深いドメイン知識を必要とするもので、実際にestieで新しいデータを取り込むに当たっては、SWEが不動産業界の専門書を読み込んだり、社内外のドメインエキスパートにヒアリングしたりしながら、理解を深めて開発を進めています。
現実世界にあるビルや建物、契約をモデリングする不動産コアデータの世界では、エッジケースと感じるデータも多く存在し、それらを正しく扱うためのデータモデリングが必要です。
これまでも以下のような当初想定していない「エッジケース」があり、都度学びながら修正してきました
- 階数は整数で表現される
→中二階といわれる、1.5階のようなフロアを持ったビルがある - ビルには1社の所有者が存在する
→区分所有で特定のフロアや持ち分で所有権を保持することがある - 賃料は契約中は一定である
→期間中徐々に変化する賃料（段階賃料）、契約中一定期間ごとに賃料免除となる期間（レントホリデー）など、さまざまな賃貸借契約の形態がある
今後、取り込むデータの種類が増える中で、爆発的に増加が見込まれるドメイン知識に対応して行きたいと考えています。
[課題2] サービスのユースケースに合わせた変換の増加
各サービスでは、建物や募集といったコアデータを、ユースケースに合わせて加工して利用する必要があります。
- エリア毎などの粒度で集約されたデータが利用したい
- オフィス割合が一定以下の建物は除外して利用したい
- 同一のビルでも所有者が複数いる場合には別物として扱いたい
- 権利関係から、一部のソースからのデータをフィルタリングして利用したい
といった、それぞれのサービスの性質に合わせた加工が多く必要になります。
[課題3] データ品質定義の複雑化
ユーザが業務を完結させるために必要なデータ品質はサービスにより異なります。
サービスによっては、estie proでは重視されていなかったカラムの情報が重視されたり、物件情報が欠損していることがより問題視されることがあります。
データ品質は 評価軸も多く、会話の中で「データ品質」を述べた際に、指し示す内容が異なることも多い概念です。例えばデータマネジメントの教科書的な存在であるDMBOK 第２版では以下のように多くの評価軸が上げながら、「データ品質が高いかどうかは、目的とデータ利用者の要求によって決まる」ため、重要なデータや評価軸を識別することが重要だと述べています。
| 品質の評価軸 | 説明（抜粋） |
|---|---|
| 正確性 | データが「現実」の実態を正しく表している程度を意味する |
| 完全性 | 必要なデータが全て存在するかどうかを意味する |
| 一貫性 | データたちがデータセット内やデータセット間で一貫して表現されている状態であり、データセット間で一貫して関連付けられている状態を意味する |
| 一意性 | エンティティがデータセット内に複数存在しないことを意味する |
| 有効性 | データが定義された値ドメインと一致するかどうかを意味する |
コアデータが複数のプロダクトで利用される中で、それぞれのデータ品質への要求を理解しながら優先度付け、重要度が大きいトピックにフォーカスする必要があります。また、新しいプロダクト立ち上げに際しても、現状のデータ品質を把握出来ることがサービス立ち上げ速度向上につながります。
また、estieではデータの加工プロセスが複雑であるが故に、各プロダクトユーザからの「この募集はもう終了しているのではないか？」「この募集の賃料は高すぎないか？」といった疑問に答えるために、プロダクトに提供しているデータの”トレーサビリティ”も重要です。
これからの進め方と技術的なチャレンジ
estieでは以下のようなデータ基盤とチームに体制をシフトして、これまで触れてきたような課題に立ち向かおうとしています。
複数チームがコラボレーション可能なデータ管理基盤
従来のデータ専門家チームが全ての外部データからのパイプラインを中央集権的に管理をする体制を脱却し、各サービスのSWEが自前でドメイン知識を元にデータパイプラインを開発するチーム体制、アーキテクチャへと変更していこうとしています。
既存のコアデータを元に、各サービス向けに扱いたい形への加工は各サービスで実現しやすくするとともに、サービス独自のデータもそれぞれの開発チームでパイプラインを構築していきます。
中央集権的なアプローチを脱却するといっても、それぞれのプロダクト開発チームでデータパイプラインを完全独自で作るわけではなく、データ基盤は共通化することで以下のポイントを抑えるようにしています。
- 社内での車輪の再発明を防ぎ、ユーザへのデータ提供を高速化
- 将来的な他プロダクトで利用可能とするための一貫性や検索可能性の実現
- データセキュリティなどの担保
分析しやすい環境への移行
これは、Compound Startupの例としてよく名が挙がるRipplingのようなユーザ自身のデータ(Ripplingの場合は従業員データ)を扱うプロダクトとは、一味違う問題ではないかと思います。
全プロダクトのコアとなる土地と建物について、品質を定義しトレーサビリティを保ちやすい仕組みとして、コアデータ基盤全体を網羅的に分析しやすい環境へと移行しようとしています。
技術的には、ご紹介していた既存のデータパイプラインはS3+Amazon Aurora(MySQL)という構成なのですが、社内で元々データ分析に利用していたSnowflakeベースの基盤へと移行しています。
今回は、基盤の話をメインにご紹介しましたが、あわせて品質定義のためのData Science観点も盛り込みながら品質の定義や分析活動を進めていっています。
まとめ
- estieでは創業以来「データが売り物」であり事業のコアだったが、Whole Product構想を実現する上で、より複数プロダクトを支えるために土地と建物を中心にしたコアデータの重要性が上がっている
- プロダクトが増えると取り込むデータにまつわるドメイン知識の必要量が増え、それぞれに必要な形への加工の必要性も高まり、コアデータへの品質要求の複雑度も上がっている
- それらの課題に取り組むために、中央集権的なデータ基盤アプローチを辞めて複数チームがコラボレーション可能で、容易に統一的に分析しやすいデータ管理基盤をSnowflake上に構築していくチャレンジ中
最後に
最後までお読み頂き有難うございました。
Whole Product構想を実現するための技術的な課題は、他にも沢山あるのですが、今回は特に根幹をなすデータ領域にフォーカスしてご紹介しました。
もっと他の課題も聞いてみたいという方、こんな課題も出てくるのでは？と気になった方、この課題自分ならばこんな解き方をしそうと思った方、一緒に解いてみたいと思った方、是非情報交換しましょう！（TwitterのDMやカジュアル面談フォームなどお気軽にご連絡ください！）
