お部屋探しアプリで データ負債に挑む

Transcript

1. 2024.03.26 株式会社カナリー 高山綾太 お部屋探しアプリで データ負債に挑む
2. 開発本部⻑ / VPoE ⾼⼭ 綾太 ⾃⼰紹介 2 • 2019年 株式会社カナリーにジョイン • 主にお部屋探しアプリのバックエンド開発に従事しながらプロ ダクト初期のDB設計に関わる • 現在は開発だけでなく、エンジニア組織全体の改善に向けた 取り組みを日々行なっている。
3. 3 会社紹介
4. カナリーが提供するプロダクト 4 今回お話するのはこちら toC アプリ toB SaaS
5. アプリに特化したお部屋探しポータル（サイト） → 累計DL350万件超、物件データ数400万件以上 お部屋探しポータル「カナリー」 5
6. LTテーマ 6 • 「効率的な」DB設計の罠にはまった実例 • ビジネスの特性をDB設計にうまく反映するには
7. ⽬次 7 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び
8. ⽬次 8 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び
9. 簡略化したビジネスモデル 1 . カナリーのビジネスモデル・特徴 9
10. 10 1. 実在の部屋1つに対して、複数の不動産会社からデータを受け取る 2. 原則、不動産会社が入稿した情報をありのまま表示する必要がある 1 . カナリーのビジネスモデル・特徴 お部屋探しアプリにおける、物件データの扱い⽅の特徴
11. ⽬次 11 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び
12. 12 • 建物(棟) > 部屋モデル > 部屋 という3階層のデータ構造 ◦ → それぞれの単位で共通の物件情報を管理すれば 効率的！（データ量/更新のしやすさ） 2 . 初期の物件DB設計 建物 (部屋モデル) 部屋 ・ ・ ・ ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づくべきデータ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形（間取り ×面積） を表すデータ構造 ※ 今回はあまり関係ない 201号室 202号室 301号室 302号室 部屋に紐づくべきデータ をリレーション 賃料/管理費 ・ ・ ・ 303号室 敷金/礼金 ・ ・ ・ 新築フラグ 宅配BOX
13. ⽬次 13 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚から修正 4. 教訓・学び
14. 14 • リリース直後、クライアント（不動産会社）から掲載についてご指摘を頂く、、 3 . 問題発覚から修正 うちが入稿してる 周辺情報には「中学校」があるはずだけど、表示されてない？ うちが入れた最寄り駅とは違う駅が表示されてませんか？ この部屋は「新築」のフラグ立ててないですよ 外観画像が若干違うみたいなんですけど ...
15. 15 • 別会社から、建物単位の異なるデータが入稿されるケースがあった 3 . 問題発覚から修正 A社 入稿データ 渋谷マンション 201 … 最寄駅：渋谷駅 … 渋谷マンション 最寄駅：???（どちらを取る?） … … Canary 建物単位のデータ B社 入稿データ 渋谷マンション 201 … 最寄駅：恵比寿駅 …
16. 16 1. 実在の部屋1つに対して、複数の不動産会社からデータを受け取る 2. 原則、不動産会社が入稿した情報をありのまま表示する必要がある 3 . 問題発覚から修正 再掲）お部屋探しアプリにおける、物件データの扱い⽅の特徴 2つの不動産会社から異なる「最寄り駅」のデータを受け取った場合、 当初のデータ構造ではいずれかの会社の物件情報をありのまま表示することができなくなる ➡ 一見「建物」の単位の情報であっても、最小単位である「部屋」に対して 　情報を紐付けなくてはならなかった（問題発覚）
17. 17 • テーブル構造の大幅な修正を実施 3 . 問題発覚から修正 建物 (部屋モデル) 部屋 ・ ・ ・ ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づくべきデータ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形（間取り ×面積） を表すデータ構造 ※ 今回はあまり関係ない 201号室 202号室 301号室 302号室 部屋に紐づくべきデータ をリレーション 内装画像 ・ ・ ・ 303号室 賃料/管理費 ・ ・ ・ 新築フラグ 宅配BOX Before
18. 18 • テーブル構造の大幅な修正を実施 3 . 問題発覚から修正 建物 (部屋モデル) 部屋 ・ ・ ・ 渋谷マンション 1K/30㎡ 2LDK/45㎡ 建物に紐づいていても問題ないデータのみ をリレーション 外観画像 築年月 建物構造 最寄駅 周辺情報 駐車場 部屋の形（間取り ×面積） を表すデータ構造 ※ 今回はあまり関係ない 201号室 (お部屋探しアプリの特性上 ) 部屋に紐づくべきデータ をリレーション 賃料/管理費 ・ ・ ・ 敷金/礼金 新築フラグ 宅配BOX After ・ ・ ・ 新築フラグ 外観画像 最寄駅 周辺情報 駐車場 ・ ・ ・ 宅配BOX
19. • 良かれと思って作った設計が、一瞬にして大きな負債に • 指摘への一次対応 と 恒久対応（テーブル構造修正）を同時並行で実施 • プロダクト初期 かつ フルタイムのエンジニアも 2-3人ということもあり、難航 ➡ 約3ヶ月間を費やし、主要なテーブル構造の修正が完了。ご指摘もほぼ解消された。 3 . 問題発覚から修正
20. ⽬次 20 1. カナリーのビジネスモデル・特徴 2. 初期の物件DB設計 3. 問題発覚、そして修正 4. 教訓・学び
21. 21 • 「効率的な」データ設計が必ずしも正解とは限らない ◦ 今回の例では、ある種「冗長な」設計でなければ要件に対応できなかった • 自分たちのビジネス（今回の例では「お部屋探しアプリ」）が走り出した時に、どういった データ上の要件が必要になるか、できる限り解像度を高めておく • 設計中に覚えた違和感は無視をせず、一度立ち止まって検証する 4 .教訓・学び
22. 22 最後に ご清聴ありがとうございました！ 22 技術スタック問わず、エンジニアの方を大募集中です。 詳しくはエントランスブックをご覧ください！ https://recruit.canary-app.jp/engineer-entrance-book