Slide 1

Slide 1 text

2024.03.26 株式会社カナリー 高山綾太 お部屋探しアプリで データ負債に挑む

Slide 2

Slide 2 text

開発本部⻑ / VPoE ⾼⼭ 綾太 ⾃⼰紹介 2 ● 2019年 株式会社カナリーにジョイン ● 主にお部屋探しアプリのバックエンド開発に従事しながらプロ ダクト初期のDB設計に関わる ● 現在は開発だけでなく、エンジニア組織全体の改善に向けた 取り組みを日々行なっている。

Slide 3

Slide 3 text

3 会社紹介

Slide 4

Slide 4 text

カナリーが提供するプロダクト 4 今回お話するのはこちら toC アプリ toB SaaS

Slide 5

Slide 5 text

アプリに特化したお部屋探しポータル(サイト) → 累計DL350万件超、物件データ数400万件以上 お部屋探しポータル「カナリー」 5

Slide 6

Slide 6 text

LTテーマ 6 ● 「効率的な」DB設計の罠にはまった実例 ● ビジネスの特性をDB設計にうまく反映するには

Slide 7

Slide 7 text

⽬次 7 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び

Slide 8

Slide 8 text

⽬次 8 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び

Slide 9

Slide 9 text

簡略化したビジネスモデル 1 . カナリーのビジネスモデル・特徴 9

Slide 10

Slide 10 text

10 1. 実在の部屋1つに対して、複数の不動産会社からデータを受け取る 2. 原則、不動産会社が入稿した情報をありのまま表示する必要がある 1 . カナリーのビジネスモデル・特徴 お部屋探しアプリにおける、物件データの扱い⽅の特徴

Slide 11

Slide 11 text

⽬次 11 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び

Slide 12

Slide 12 text

12 ● 建物(棟) > 部屋モデル > 部屋 という3階層のデータ構造 ○ → それぞれの単位で共通の物件情報を管理すれば 効率的!(データ量/更新のしやすさ) 2 . 初期の物件DB設計 建物 (部屋モデル) 部屋 ・ ・ ・ ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づくべきデータ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形(間取り ×面積) を表すデータ構造 ※ 今回はあまり関係ない 201号室 202号室 301号室 302号室 部屋に紐づくべきデータ をリレーション 賃料/管理費 ・ ・ ・ 303号室 敷金/礼金 ・ ・ ・ 新築フラグ 宅配BOX

Slide 13

Slide 13 text

⽬次 13 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び

Slide 14

Slide 14 text

14 ● リリース直後、クライアント(不動産会社)から掲載についてご指摘を頂く、、 3 . 問題発覚から修正 うちが入稿してる 周辺情報には「中学校」があるはずだけど、表示されてない? うちが入れた最寄り駅とは違う駅が表示されてませんか? この部屋は「新築」のフラグ立ててないですよ 外観画像が若干違うみたいなんですけど ...

Slide 15

Slide 15 text

15 ● 別会社から、建物単位の異なるデータが入稿されるケースがあった 3 . 問題発覚から修正 A社 入稿データ 渋谷マンション 201 … 最寄駅:渋谷駅 … 渋谷マンション 最寄駅:???(どちらを取る?) … … Canary 建物単位のデータ B社 入稿データ 渋谷マンション 201 … 最寄駅:恵比寿駅 …

Slide 16

Slide 16 text

16 1. 実在の部屋1つに対して、複数の不動産会社からデータを受け取る 2. 原則、不動産会社が入稿した情報をありのまま表示する必要がある 3 . 問題発覚から修正 再掲)お部屋探しアプリにおける、物件データの扱い⽅の特徴 2つの不動産会社から異なる「最寄り駅」のデータを受け取った場合、 当初のデータ構造ではいずれかの会社の物件情報をありのまま表示することができなくなる ➡ 一見「建物」の単位の情報であっても、最小単位である「部屋」に対して  情報を紐付けなくてはならなかった(問題発覚)

Slide 17

Slide 17 text

17 ● テーブル構造の大幅な修正を実施 3 . 問題発覚から修正 建物 (部屋モデル) 部屋 ・ ・ ・ ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づくべきデータ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形(間取り ×面積) を表すデータ構造 ※ 今回はあまり関係ない 201号室 202号室 301号室 302号室 部屋に紐づくべきデータ をリレーション 内装画像 ・ ・ ・ 303号室 賃料/管理費 ・ ・ ・ 新築フラグ 宅配BOX Before

Slide 18

Slide 18 text

18 ● テーブル構造の大幅な修正を実施 3 . 問題発覚から修正 建物 (部屋モデル) 部屋 ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づいていても問題ないデータのみ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形(間取り ×面積) を表すデータ構造 ※ 今回はあまり関係ない 201号室 (お部屋探しアプリの特性上 ) 部屋に紐づくべきデータ をリレーション 賃料/管理費 ・ ・ ・ 敷金/礼金 新築フラグ 宅配BOX After ・ ・ ・ 新築フラグ 外観画像 最寄駅 周辺情報 駐車場 ・ ・ ・ 宅配BOX

Slide 19

Slide 19 text

● 良かれと思って作った設計が、一瞬にして大きな負債に ● 指摘への一次対応 と 恒久対応(テーブル構造修正)を同時並行で実施 ● プロダクト初期 かつ フルタイムのエンジニアも 2-3人ということもあり、難航 ➡ 約3ヶ月間を費やし、主要なテーブル構造の修正が完了。ご指摘もほぼ解消された。 3 . 問題発覚から修正

Slide 20

Slide 20 text

⽬次 20 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚、そして修正 4. 教訓・学び

Slide 21

Slide 21 text

21 ● 「効率的な」データ設計が必ずしも正解とは限らない ○ 今回の例では、ある種「冗長な」設計でなければ要件に対応できなかった ● 自分たちのビジネス(今回の例では「お部屋探しアプリ」)が走り出した時に、どういった データ上の要件が必要になるか、できる限り解像度を高めておく ● 設計中に覚えた違和感は無視をせず、一度立ち止まって検証する 4 .教訓・学び

Slide 22

Slide 22 text

22 最後に ご清聴ありがとうございました! 22 技術スタック問わず、エンジニアの方を大募集中です。 詳しくはエントランスブックをご覧ください! https://recruit.canary-app.jp/engineer-entrance-book