こんにちは、プロダクトエンジニアリング部の江口です。
私は普段 LIFULL HOME'S 賃貸マーケットの技術負債解消に取り組むエンジニアリングチームのリーダーをしています。
本記事では、賃貸マーケットで長年の課題だった「ユーザー行動ログ送信処理」の技術負債解消について紹介します。技術的な取り組みだけでなく、エンジニアとして技術負債にどう向き合っていくべきかを考えるきっかけにもなった経験をお伝えできればと思います。
何が問題だったのか
賃貸物件の詳細ページは過去にリニューアルされ、新システムへ移行済みでした。しかし、ユーザー行動ログの送信処理だけは旧システムに残ったままで、新システムから旧システムのエンドポイントを叩くことでこの処理を委譲していました。つまり、詳細ページを1回表示するたびに、バックエンドへのリクエストが実質2倍発生している状態です。
これによって、負荷が集中する繁忙期には、DBのパフォーマンスの低下も懸念されました。もちろん、私たちも新システム側でクローラー判定を行い旧システムへのリクエストを抑制したり、ログの生成に関係のないバックエンドへのリクエストを停止したりと、できる限りの負荷軽減策を講じてきました。しかし、これらはあくまで対症療法に過ぎません。この状況を根本から解消するため、私たちのチームがこの問題に決着をつけることになりました。
これまでの試行錯誤の歴史については、ぜひこちらの記事もご覧ください。
なぜこれまで解決できなかったのか
過去にもログ送信処理の移植は試みられてきましたが、以下の理由により断念されてきました。
- 膨大な移植コスト： 約10年前のレガシーなロジックが複雑に絡み合い、2〜3名で1年かけても終わらない規模
- 品質担保の壁： 不動産会社が掲載効果を分析するためのレポート機能に関わるため、集計結果の変動を許容しづらい
- ログの完全一致が困難： 旧システムと新システムでは物件情報データの取得経路に微妙な違いがある
どうアプローチしたか
難易度を下げてから勝負する
このプロジェクトで最も重要だった判断は、「難しい問題を頑張って解く」のではなく、「問題の難易度そのものを下げる」という方針を取ったことです。
具体的には、ユーザー行動ログに依存する周辺システムを、社内でデファクトスタンダードとなっているユーザー行動解析基盤であるTealiumへ先に移行させることで、古いログへの依存を一つずつ断ち切っていきました。
これにより、新システムへの移行時に保証すべきログの属性値（スキーマ）を大幅に削減し、「守るべき範囲」を意図的に狭めることで、テスト工数と不確実性を下げました。
依存先の調査
まず、ログが格納されたS3のバケットポリシーから、アクセスが許可されているアカウントやロールを洗い出しました。中には過去に使われていたと思われるAWSアカウントからの許可や、AWSアカウントレベルでの広いアクセス許可が残っており、具体的にどのシステムからのアクセスなのかがポリシーだけでは判別できないケースもありました。そうした許可については、CloudTrailで実際のアクセス有無を確認しながら整理を進めています。その上で、S3の接続情報をキーにGitHub上のリポジトリを横断検索し、該当するコードを地道に追っていきました。それでも埋まらない部分は、社内のConfluence・Jira・チャットログ・GitHub Discussionsを当たり、マーケットの垣根を越えて担当者に直接確認することで、一つずつ依存先を明らかにしていきました。
最終的に、ログに直接依存しているシステムは20以上にのぼり、さらにBigQueryにも連携されていたため、その先ではアナリストも分析に利用している状況でした。
この調査は、このプロジェクトで最も骨が折れたパートです。
古いログへの依存を一つずつ断ち切る
依存先が明らかになった後は、そのうち賃貸の物件詳細ページのログに直接関わるシステムについて、Tealium経由のデータに切り替えてもらう調整に入りました。しかし、これが一筋縄ではいきませんでした。レガシーなシステムであるがゆえに、主管部署の担当者自身がシステムの仕様を十分に把握できていないケースが多く、「何のデータをどう使っているのか」を一緒に紐解くところから始める必要がありました。
アナリストに対しては、BigQuery上のデータ切り替えについて告知を行いました。実態としては、アナリスト自身もどのデータを使っているか明確に把握しきれていない状況でしたが、データを外部に販売しているような重要度の高い用途については、個別にしっかりヒアリングを行い、影響がないことを確認しました。
また、依存先の洗い出しを促進するため、プロジェクトの進捗や影響範囲を社内に定期的に周知し、「自分のシステムも該当するかもしれない」と気づいてもらえるよう働きかけました。
実装・テスト・移行での工夫
テストでは、旧システムから出力されるログと新システムから送信されるログを突き合わせて比較する方針を取りました。完全一致しない項目については、後続のシステムで実際に使用されていないことを一つずつ確認しています（今後、使われていない項目は削除していく予定です）。
特に重要だったのは、不動産会社向けレポート機能への影響確認です。集計バッチの出力結果を旧ログ・新ログそれぞれで比較し、差分がないことを検証しました。ただ、テスト環境自体にパフォーマンスの課題やCI/CDの課題があり、動作確認を回すだけでもかなりの労力がかかりました。
移行は段階的ではなく、一括で切り替えました。二重にログを保持し続けるコストや、切り戻し時に古いログで後続システムを再実行する運用の複雑さを考慮し、この方式を選択しています。万が一の失敗に備え、リカバリー方針と関係者への対応フローを事前に策定しておくことで、リスクをコントロールしました。
プロジェクト推進の難しさ
このプロジェクトは、技術的な難しさ以上に、推進そのものに大きな負荷がかかるものでした。
自チームでのログ送信処理の移行作業に加え、旧ログに依存する周辺システムについて、Tealiumへのリアーキテクチャのサポートとコードレビューを自ら担いました。各システムの技術スタックも事情も異なる中で、設計方針の提示からレビュー、問題発生時の判断までを一手に引き受ける形です。
さらに、主管部署の担当者がシステムの仕様を把握しきれていないケースでは、仕様の調査や整理から伴走する場面も少なくありませんでした。マーケットや部署の垣根を越えた調整を重ね、関係者全員が同じゴールに向かえる状態を作ることも、このプロジェクトにおける自分の重要な役割でした。
やり遂げて思ったこと：技術負債解消とROI
この取り組みをやり遂げた今、「これは本当に事業に必要だったのか？」と自問することがあります。
バックエンドへの負荷が実質2倍という状態は健全ではなく、実際に繁忙期にはDBへの負荷が問題になっていました。解消すべき課題だったのは間違いありません。一方で、技術負債の解消にはそれなりのコストがかかり、その間ユーザーに直接価値を届ける開発に割けるリソースは減ります。そのバランスをどう取るかは、リーダーとして常に問い続けるべきテーマだと感じるようになりました。
この経験を通じて、技術負債解消は「エンジニアが気持ちよく開発するため」だけではなく、事業のROIを踏まえた上で優先度を判断すべきものだという考えに変わりました。今回のケースはDB負荷という差し迫った理由があったからこそ正当化できましたが、常にそうとは限りません。
今後は、技術負債の解消を特別なプロジェクトとして切り出すのではなく、日常の開発の中で自然に改善していける状態を目指したいと考えています。エンジニアとしての本分は、技術力でユーザーに価値を届け、事業の優位性を築くことにあるはずです。プロダクト開発に軸足を置きながら、健全なコードベースを維持していく——そのサイクルを回せるチームでありたいと思っています。
終わりに
本記事では、LIFULL HOME'S 賃貸マーケットにおける技術負債解消の取り組みについて紹介しました。
このプロジェクトの作業は泥臭いものの連続でしたが、それを完遂できたときの達成感は大きく、負債解消へのインパクトも確かなものでした。同時に、「技術的に正しいこと」と「事業として正しいこと」の間で考え続けることの大切さも学びました。
LIFULL では、こうした課題に一緒に向き合い、ともに成長していける仲間を募集しています。興味を持っていただけた方は、ぜひ以下のページもご覧ください。
