ゼロから構築！6年間で1,760%成長した「いい部屋ネット」を支えるデータ分析基盤

2025/11/6に開催されたData Engineering Summitの登壇資料です。
「いい部屋ネット」の成長を加速するために、Red Frascoのデータエンジニアは何をしてきたのか、5年間の軌跡をステップに分けて説明します。

参考URL：https://data-engineering-summit.findy-tools.io/2025

Transcript

1. ゼロから構築！ 6年間で1,760%成長した 「いい部屋ネット」を支えるデータ分析基盤 Data Engineering Summit ~生成AI時代のデータ基盤構築~
2. 自己紹介 2 杉山 隆(Takashi Sugiyama) 株式会社Red Frasco データエンジニア 趣味: バスケットボール
3. Red Frascoについて 3 Web広告 SEOコンサル システム開発 ＋ ＋ 不動産業界に特化、クライアント自社HP集客を全面的にサポート
4. Red Frascoの強み 4 開発・集客(SEO/Paid Ads)・データを組み合わせて成果を最大化 有料流入 (Paid Ads) 無料流入 (SEO) 反響数 流入 × = + CVR (サイト品質) データ 分析基盤 データフィード連携、コストモニタリングなど 物件数モニタリング 順位モニタリングなど モニタリング 各種レコメンド施策 コンテンツの生成など
5. 5 本日話すこと
6. いい部屋ネットとは 6 大東建託パートナーズが運営する 賃貸物件をお探しの方向けの不動産ポータルサイト
7. 7 お問い合わせ数 最大 1,760% 2025年9月時点 ★2020年04月プロジェクト開始
8. プロダクトを改善するうえでの前提 8 1発のホームランを狙うのではなく、何度も打席に立つことが重要 改善目標ライン 改善目標ライン ホームランを狙う 効果 時間 ★途中効果が悪くなったとしても すぐに方向性を転換 数週間〜数ヶ月の開発 効果 時間 不確実性 打席に立つ回数を増やす
9. プロダクト改善とデータ分析基盤の関係 9 データ 分析基盤 PLAN 機能・開発の 優先順位決定 DO 小さな開発 & リリース CHECK 検証 & 評価 DO 全体リリース & 再評価 検証設計 定量データから 注力箇所・課題箇所の特定 改善結果の評価 得られた知見の収集 効果検証の評価 全体インパクトの試算 何度も打席に立つためには、各フェイズでデータ分析基盤が必要不可欠
10. 本プロジェクト開始前の状況 10 データ分析環境がない、ゼロからのスタート
11. 本日話すこと 11 いい部屋ネットの成長を加速するために、データエンジニアは何をしてきたのか、 5年間の軌跡をステップに分けて説明します STEP 01 STEP 02 STEP 03 プロダクトのゴール設定 現状把握と課題特定。プロダクトのKPI を定め、改善サイクルの前提準備 データ意思決定文化の 定着化 プロジェクトメンバ全体が同じ目線で 会話できる環境を構築 データを用いた プロダクト改善 データを活用し、 プロダクトに対して改善施策の実施
12. スモールスタートで道を切り拓く 12 早く 無駄無く 効果実感 • プロダクト改善をするうえでデータ意思決定文化の早期定着化が必須 • 一度に全ての機能を作ろうとすると軌道修正がしづらい、小回りが効かない →拡張性を意識したうえで、必要な機能・必要なデータ収集のみを実施 • データ組織はコストセンターになりやすい →早期に少しずつ成果を出しながら効果実感をしてもらう 1 2 3 データ意思決定文化の定着化が急務 手戻りのリスクを避け、早期に成果を出すために小さくスタート
13. 導入から現在までの道のり スモールスタートで構築し、 組織の成長に併せて段階的に機能を追加することに STEP 01 STEP 02 STEP 03 プロダクトのゴール設定 現状把握と課題特定。プロダクトのKPI を定め、改善サイクルの前提準備 • データ精査 • データ品質改善 • 最小限のデータ収集 • KPI設定 データ意思決定文化の 定着化 プロジェクトメンバ全体が同じ目線で 会話できる環境を構築 • 施策毎の最小限のデータ収集 • ダッシュボード構築 • プロダクト向け • マーケ向け • データ監視 データを用いた プロダクト改善 データを活用し、 プロダクトに対して改善施策の実施 • データ活用 • バッチによるレコメンド • リアルタイムによるレコメンド • コンテンツ • IaC+CI/CD整備 13
14. STEP 01: 最小限でのデータ分析基盤 14 まずは、サイトの現状分析+KPI設定が行える環境の準備が急務 データ分析基盤はスモールスタートで構築 ポイント 構成図 収集するデータ・環境選定 • 最低限のデータからアドホック分析を通じてプロダ クトの現状分析とKPI設定が必要 将来の拡張性 • 将来、データの種類が増加することを想定する必要 がある アプリケーション システムデータ Cloud Storage VPC Network Cloud Composer BigQuery
15. STEP 01: この時点でのデータ分析基盤の構成 15
16. STEP 02: データ起点の意思決定の範囲を拡大 16 KPIの設定や改善のためデータ準備が完了したので、 データの活用を適用範囲をプロジェクト全体に拡大 STEP 01 STEP 02 STEP 03 プロダクトのゴール設定 現状把握と課題特定。プロダクトのKPI を定め、改善サイクルの前提準備 • データ精査 • データ品質改善 • 最小限のデータ収集 • KPI設定 データ意思決定文化の 定着化 プロジェクトメンバ全体が同じ目線で 会話できる環境を構築 • 施策毎の最小限のデータ収集 • ダッシュボード構築 • プロダクト向け • マーケ向け • データ監視 データを用いた プロダクト改善 データを活用し、 プロダクトに対して改善施策の実施 • データ活用 • バッチによるレコメンド • リアルタイムによるレコメンド • コンテンツ • IaC+CI/CD整備
17. STEP 02: 適用範囲の拡大にむけた方針 17 場所 環境 データ起点の意思決定の文化を定着化させるために、目線を合わせる “環境”と“場所”を提供 ゴール • プロジェクトメンバーが、共通でデータを確認できる基盤 → 改善に必要なデータの追加とダッシュボードの構築 • 定期的にデータを確認し、データによる意思決定を習慣化 → プロジェクト全体でデータを確認、議論できる会議体の開催 • プロジェクト全体が、データを起点にした意思決定を実施
18. STEP 02: 定着化に向けた役割分担 18 データチーム内で分担し、定着化に着手 場所 データアナリスト主導 • KPI進捗定例会 • KPIのモニタリングからの課題抽出 • プロダクト全体定例会 • プロダクト課題のチーム間連携 • 課題に対するデータ分析結果の共有 • マーケティング定例会 • プロダクトのCVベースの広告評価 環境 データエンジニア主導 • プロダクト外のデータ連携の強化 • Web広告データ • SEOデータ • CRMデータ • ダッシュボードの構築 • KPI指標のモニタリング • 各チーム向けダッシュボード
19. STEP 02: 定着化に向けた役割分担 19 データチーム内で分担し、定着化に着手 場所 データアナリスト主導 • KPI進捗定例会 • KPIのモニタリングからの課題抽出 • プロダクト全体定例会 • プロダクト課題のチーム間連携 • 課題に対するデータ分析結果の共有 • マーケティング定例会 • プロダクトのCVベースの広告評価 環境 データエンジニア主導 • プロダクト外のデータ連携の強化 • Web広告データ • SEOデータ • CRMデータ • ダッシュボードの構築 • KPI指標のモニタリング • 各チーム向けダッシュボード
20. STEP 02: ダッシュボードもスモールスタート 20 リッチなダッシュボードよりも、意思決定に必要な情報の提供と監視/運用を意識 • ダッシュボード構築 • ダッシュボードの描画は必要最低限 • セキュリティ対策 • GKEによる運用負担の軽減 • 監視/運用 • KPI含めた重要指標の低下の検知 • サーバーレスにでコスト最小限に ポイント 監視機能 ダッシュボード環境 各種システム構成
21. STEP 02: やっぱり、サービスレベルあがると大変 21 定着化は進んだものの、他チームへのデータ提供により、 サービスレベルがあがり、思った以上に運用が大変に… • アクセス管理の複雑化 • チーム/アカウントごとにアクセス可能な データセットを分けていたが、この頃は 手作業で管理していたため、管理が複雑に… • 監視 • 問題ない場合が多く、オオカミ少年化 • 閾値の調整を何度か行った 監視通知の例
22. STEP 02: プロダクトの改善スピートアップに貢献 22 “環境”と“場所”の提供により、ダッシュボードを利用した意思決定が定着 チームを跨いだ施策も実施され、プロダクトの改善も加速 KPI改善 ✓ ダッシュボードをベースにした会議の実施 ✓ ダッシュボードを利用した課題抽出 施策実施 ✓ 定量的な数値による施策評価 ✓ Webマーケ x 開発などのチーム間を またいだ施策の実施 プロジェクトの変化 KPIの成長は年々加速 プロダクトの変化
23. STEP 02: (余談)ダッシュボードはリッチになりました 23 各チームのデータ利用が活発化し、ビジュアライズの要件も増加 現在は、ダッシュボードをTableauに移行中 初期構築時 現在
24. STEP 02: この時点でのデータ分析基盤の構成 24
25. STEP 03: データを用いたプロダクト改善を実施 25 UI改善が一段落したことにより、データを活用した施策を実施 Before After
26. STEP 03: データを用いたプロダクト改善を実施 26 プロダクトにデータを用いた施策を複数行ったが、 その中の一例である、物件のレコメンド機能の取り組みを紹介する STEP 01 STEP 02 STEP 03 プロダクトのゴール設定 現状把握と課題特定。プロダクトのKPI を定め、改善サイクルの前提準備 • データ精査 • データ品質改善 • 最小限のデータ収集 • KPI設定 データ意思決定文化の 定着化 プロジェクトメンバ全体が同じ目線で 会話できる環境を構築 • 施策毎の最小限のデータ収集 • ダッシュボード構築 • プロダクト向け • マーケ向け • データ監視 データを用いた プロダクト改善 データを活用し、 プロダクトに対して改善施策の実施 • データ活用 • バッチによるレコメンド • リアルタイムによるレコメンド • コンテンツ • IaC+CI/CD整備
27. STEP 03: 賃貸情報サイトのデータ特性 27 賃貸情報サイトは、物件/ユーザーどちらも他の商材とは異なるユニークな特性あり • すべての商品の在庫が1つ • 入居者が退去するまで、在庫は復活しない → 商品の移り変わりが激しい • 検討期間が短く、訪問回数が少ない • 入居が決まれば、年単位で再訪がない → ユーザー接点が短期的で行動データが蓄積しにくい 80%超のユーザーが2回まで訪問 訪問回数 1回 2回 3回以上 物件の掲載期間 -10日 -20日 -30日 -60日 -90日 90日~ 60%超の物件が30日で掲載終了 物件データ ユーザーデータ 32% 17% 12%
28. STEP 03: レコメンド機能の検討 28 ユーザー/物件ともにコールドスタート問題への対応が必須 コスト観点から#1にて実施 # 対応案 データ連携 期待される効果 実装にかかるコスト 1 物件データでレコメンドモデルを作成する、 ユーザーの行動ログは使用しない バッチ or リアルタイム 中 中 2 ユーザーの行動ログをリアルタイムに 取得・分析する リアルタイム のみ 大 特大
29. STEP 03: 実際のレコメンド画面 29 トップ 検索 物件一覧 物件詳細 フォーム レコメンドパーツ
30. STEP 03: レコメンドロジック 30 物件データをベクトル化し、物件間の距離が近いものをレコメンド 特に近い要素を推薦理由として表示し、ユーザーへの伝わりやすさを意識 物件A # 物件 推薦理由 1 物件B 面積がより広い 2 物件C 立地が近い 3 物件F 築年数がより浅い 4 物件H 家賃がより近い 5 物件O 同じ市区町村 ... 物件A 物件B ベクトル化 (a1 , a2 , ..., an ) (b1 , b2 , ..., bn ) 距離を計算 ベクトル化 推薦理由 推薦物件 ロジックイメージ レコメンドイメージ
31. STEP 03: 計算時間短縮の活動 31 いくつかの対策を行うことで計算時間を短縮することに成功 1. 計算対象レコードの削減 • 同じ都道府県の物件であること • 10km圏内の物件であること 2. 並行処理 • 都道府県単位で1.の処理を並行して実施 3. 処理を行う基盤 • 当初はBigQueryでは実行していたが、処理が遅いため Dataproc上でApach Sparkを動かすように変更 計算時間短縮のための工夫 短縮結果 2時間 東京都だけで 全都道府県で 1時間
32. STEP 03: システム構成 32 2. 物件データを取得 3. おすすめ物件の算出 4. CSVファイルで出力 5. アプリケーションの BEがデータを取得 1. 物件データが 連携されたら即実行 まずは単純なバッチ処理で構成
33. STEP 03: レコメンドの導入結果 33 本施策により物件の閲覧数が+17%となり、レコメンドの有効性を確認 また、適応面をサンクスメールにも拡大し、CV数の増加に寄与 物件閲覧数 + 17 % CVユーザー + 16 % 詳細画面レコメンドの効果 サンクスメールレコメンドの効果
34. STEP 03: 施策深度の進化 34 リアルタイムレコメンドに着手 対応案 データ連携 期待される効果 実装にかかるコスト 1 物件データでレコメンドモデルを作成する、 ユーザーの行動ログは使用しない バッチ or リアルタイム 中 中 2 ユーザーの行動ログをリアルタイムに 取得・分析する リアルタイム のみ 大 特大 実施済
35. STEP 03: リアルタイムレコメンドに必要な要素 35 データ取得 データ返却 • ユーザーのリアルタイム行動ログ、及びログを取得するシステム • システムはアプリケーションと密に連携するため、UXに悪影響を 与えないようにする • 算出したおすすめ物件をアプリケーションに連携するシステム • データ取得を行うシステムと同様、UXに悪影響を与えないようにする 1 2 予測モデル • 行動ログを分析し、おすすめ物件を算出するモデル 3 1 2 3
36. STEP 03: APIの注力ポイント 36 ①データ取得と②データ返却のために、APIを構築 UXに悪影響を与えないよう、リクエストレイテンシーの向上に注力 プログラミング言語の選定 当初Pythonで記述していたが、思った通りのレイテンシーが出なくGo言語に書き換えた データの保存場所には、コストや拡張性、インフラ管理が容易…等の理由から 当初はFirestoreを使用していたが、大規模なトランザクションに対応するためBigtableに変更した データベースの選定
37. STEP 03: ①データ取得 37 システム構成図 VPC Network Cloud Run Bigtable Cloud Armor Pub/Sub Dataflow BigQuery Cloud Load Balancing API Gateway 1. 2. 3. # サービス 説明 1 Cloud Run APIの実行環境。オートスケーリング機能、 サーバーレスによるインフラ管理工数の 削減…いったメリットがある 2 Bigtable レコメンド提供時に使用するデータを格納 3 Pub/Sub Dataflow BigQuery 将来的に分析に使うことも考慮し、 BigQueryにもデータを保存 利用しているサービスについて
38. STEP 03: ②データ返却 38 VPC Network Cloud Run Bigtable Cloud Armor Vertex AI Cloud Load Balancing API Gateway 1. # サービス 説明 1 Vertex AI Bigtable Bigtableから取得した行動ログをもとに、 Vertex AI上のモデルからおすすめ物件を 取得 システム構成図 利用しているサービスについて
39. STEP 03: 予測モデル 39 モデルは、Googleが開発したレコメンデーションシステム構築のための TensorFlow向けライブラリである TensorFlow Recommendersを使用 TFRSでは、推薦タスクを大きく2つに分けてモデル化 Retrievalで絞り込まれた候補の中から、 最も適した順に並び替える ユーザーとアイテムを共通の埋め込み、空間に マッピングし、「どのアイテムがこのユーザーに 合いそうか」を高速に検索 Retrieval 1 2 3 1. Retrieval(検索)モデル 2. Ranking(ランキング)モデル Ranking
40. STEP 03: リアルタイムレコメンドの導入結果 40 懸念点であったAPIのリクエストレイテンシーは、目標値を大幅に下回る結果となった リアルタイムレコメンドの効果でCV数が5.6%アップ リアルタイムレコメンドの効果 リクエストのレイテンシー 実測値 20ミリ秒以内 (99パーセンタイル値) 1秒以内 目標値 CV数 + 5.6 %
41. STEP 03: IaC+CI/CD 41 分析基盤構築が落ち着いたこのタイミングで実施 IaC • Terraformを使用 • 既存のリソースから、gcloudコマンド やTerraformer等を用いてHCLコード にエクスポート CI/CD • GitHub Actionsを使用 • GitHubを使っているからという単純な理由 反省点 整備に1人/月ほど掛かったので、なるべく早い段階で導入しておくべき (分析基盤構築をミニマムでやっていたので、なかなか着手できなかった…) (遅くともSTEP 01の後くらいにやるべきでした)
42. STEP 03: データ分析基盤の現在の構成 42
43. STEPごとのまとめ 43 STEP 01: プロダクトのゴール設定 ✓ データ意思決定文化の定着のため、最小限のデータ収集とゴール設定を行う ✓ 将来の拡張性を考慮し、アドホック分析環境ができる環境の構築(BigQuery + Cloud Composer) STEP 02: データ意思決定文化の定着化 ✓ データの提供だけでなく、データを確認・判断する機会を同時に提供する ✓ ただのデータ可視化だけでなく、データの監視と通知ができる環境の構築 STEP 03: データを用いたプロダクト改善 ✓ まずはバッチ処理のレコメンドから始め、効果が確認できたらリアルタイム処理を実装 ✓ APIはUXを考慮し、リクエストレイテンシーを最小化
44. まとめ 44 いい部屋ネットの成長を加速するために、データ組織は何をしてきたのか プロジェクトに関わる全メンバーの データに基づく意思決定の文化定着 蓄積したデータを活用した プロダクトへのデータ活用のチャレンジ 1 2
45. 45 お問い合わせ数 最大 1,760% 2025年9月時点 ★2020年04月プロジェクト開始
46. まとめ 46 適切なタイミングで適切な施策を リリースすることが重要 早く、無駄無く、効果実感を意識 データ分析基盤を構築する上で意識したこと スモールスタート プロダクト状況の把握 1 2
47. 集客 今後の展望 47 データ施策の適応面を広げつつ、既存施策の効果を並行して高めていく プロダクトにインパクトを与える改善施策を推進していく 入稿システム (他社製品) 入稿システム (自社製品) データ変換 いい部屋ネット 有料集客 (Paid Ads) 無料集客 (SEO+メールなど) CRM トップ 検索 物件一覧 物件ライブラリ 店舗詳細 本日お話をしたレコメンドの適応面 実施済の適応面 本日お話した適応面 ▼判例 物件詳細 フォーム
48. 今後の展望 48 プロダクト改善のみに限らず、 ビジネスデータを収集して、ビジネス全体にも価値をもたらしたい 現在 今後
49. WE ARE HIRING!! 一緒に働く仲間を募集中です！ まずは採用ページを見てください！！ Red Frasco 採用
50. THANK YOU FOR YOUR ATTENTION!!