100人超のエンジニア組織の統合、60以上のアプリケーションの基盤集約、日本最大級の不動産・住宅情報サイト『LIFULL HOME'S』を支え続けるエンジニアリング＿長沢翼

100人超のエンジニア組織の統合 60以上のアプリケーションの基盤集約 日本最大級の不動産・住宅情報サイト 『LIFULL HOME'S』を支え続けるエンジニアリング 2024.12.24 株式会社 LIFULL 長沢 翼 1

執行役員 CTO 長沢 翼 ＠nagasawatsubasa 2008年LIFULL入社。「LIFULL HOME'S」のWeb/iOSアプリ開発、API基盤 の刷新、事業系システムのクラウド移行を責任者として実行。 2017年にCTO就任し、事業系システム、社内情報システム領域を担当。 また、ベトナム・マレーシア2社の開発子会社の取締役として国外含 むエンジニア組織の技術力向上及び組織力強化を推進。 生成AI関連では、2023年5月に生成AIの専門組織を立ち上げ社外向け 複数プロダクトをリリース。社内でも生成AIによる業務効率化の取 組みにより約42,000時間の効率化を行う。 LIFULL HOME'S 事業においては副本部長としてプロダクト・新規事業 を管掌。 好きなものはコーヒー。

会社紹介 背景と課題 contents 4つの取り組み - 組織構造・人 - 意識 - 仕組み - システム

生成AIプロダクト開発 LINEアプリである「AI ホームズくん BETA」は様々な情報と連携拡大中

AIホームズくん LINEチャット形式で部屋探し こちらでお試しください

LIFULLエンジニア組織概要 (2024年10月時点) LIFULL HOME'S 事業 本部 横断技術部門 データ系 その他 LIFULL HOME'S アプリケー ション開発 インフラ管理・運用 品質管理・セキュリティ アクセシビリティ --情報システム 研究開発 データ基盤 新規事業 等 生成AI ベトナム開発拠点(子会社) マレーシア開発拠点(子会社) 海外開発拠点 ※組織はデフォルメされております

LIFULLエンジニア組織概要 (2024年10月時点) LIFULL HOME'S 事業 本部 横断技術部門 データ系 その他 LIFULL HOME'S アプリケー ション開発 インフラ管理・運用 品質管理・セキュリティ アクセシビリティ --情報システム 研究開発 データ基盤 新規事業 等 生成AI ベトナム開発拠点(子会社) マレーシア開発拠点(子会社) 海外開発拠点 ※組織はデフォルメされております

本日の話

開発生産性の向上をしていくため 「組織」と「システム」の両面でア プローチした話

背景と課題

現状のLIFULL HOME'Sのシステムの構成 注文住宅 まちむすび 売却査定 LIFE LIST 不動産投資 不動産アーカイブ

現状のLIFULL HOME'Sのシステムの構成 PHP → Typescript Laravel + Go Laravel + Go Symfony Wordpress Spring Rails

開発生産性を向上させていくため これらを緩やかに統合させていくための取り組み

LIFULL HOME'S のプロダクト組織の変遷(ざっくり) 2008年頃 営 業 2014年頃 エンジニア40名超規模 エンジニア80名超規模 エンジニア120名超規模 事業部制 職能制 事業部制 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 賃貸 システム 境界 2012年頃 プ ロ ダ ク ト 流通 営 業 プ ロ ダ ク ト 分譲 営 業 プ ロ ダ ク ト エンジニアのアサイン • マーケット固定 技術的課題 • 技術スタックはバラバラ • 技術的な交流もなし • マーケットに閉じている ので早かった 賃貸 エ ン ジ ニ ア 企 画 デ ザ イ ナ ー 営 業 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注文住宅 営 業 プ ロ ダ ク ト エンジニアのアサイン • 担当マーケットは流動的 • 「PJ」としてアサイン エンジニアのアサイン • 担当マーケットは固定 技術的観点 • 技術に焦点を当てた、進 化はすることができた • ドメイン知識は薄くなる 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい

LIFULL HOME'S のプロダクト組織の変遷(ざっくり) 2008年頃 営 業 2014年頃 エンジニア40名超規模 エンジニア80名超規模 エンジニア120名超規模 事業部制 職能制 事業部制 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 賃貸 システム 境界 2012年頃 プ ロ ダ ク ト 流通 営 業 プ ロ ダ ク ト 分譲 営 業 プ ロ ダ ク ト エンジニアのアサイン • マーケット固定 技術的課題 • 技術スタックはバラバラ • 技術的な交流もなし • マーケットに閉じている ので早かった 賃貸 エ ン ジ ニ ア 企 画 デ ザ イ ナ ー 営 業 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注文住宅 営 業 プ ロ ダ ク ト エンジニアのアサイン • 担当マーケットは流動的 • 「PJ」としてアサイン エンジニアのアサイン • 担当マーケットは固定 技術的観点 • 技術に焦点を当てた、進 化はすることができた • ドメイン知識は薄くなる 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい

LIFULL HOME'S のプロダクト組織の変遷(ざっくり) 2008年頃 営 業 2014年頃 エンジニア40名超規模 エンジニア80名超規模 エンジニア120名超規模 事業部制 職能制 事業部制 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 賃貸 システム 境界 2012年頃 プ ロ ダ ク ト 流通 営 業 プ ロ ダ ク ト 分譲 営 業 プ ロ ダ ク ト エンジニアのアサイン • マーケット固定 技術的課題 • 技術スタックはバラバラ • 技術的な交流もなし • マーケットに閉じている ので早かった 賃貸 エ ン ジ ニ ア 企 画 デ ザ イ ナ ー 営 業 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注文住宅 営 業 プ ロ ダ ク ト エンジニアのアサイン • 担当マーケットは流動的 • 「PJ」としてアサイン エンジニアのアサイン • 担当マーケットは固定 技術的観点 • 技術に焦点を当てた、進 化はすることができた • ドメイン知識は薄くなる 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい

LIFULL HOME'S のプロダクト組織の変遷(ざっくり) 2008年頃 営 業 2014年頃 エンジニア40名超規模 エンジニア80名超規模 エンジニア120名超規模 事業部制 職能制 事業部制 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 LIFULL HOME'S 事業本部 賃貸 システム 境界 2012年頃 プ ロ ダ ク ト 流通 営 業 プ ロ ダ ク ト 分譲 営 業 プ ロ ダ ク ト エンジニアのアサイン • マーケット固定 技術的課題 • 技術スタックはバラバラ • 技術的な交流もなし • マーケットに閉じている ので早かった 賃貸 エ ン ジ ニ ア 企 画 デ ザ イ ナ ー 営 業 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注文住宅 営 業 プ ロ ダ ク ト エンジニアのアサイン • 担当マーケットは流動的 • 「PJ」としてアサイン エンジニアのアサイン • 担当マーケットは固定 技術的観点 • 技術に焦点を当てた、進 化はすることができた • ドメイン知識は薄くなる 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい

当時、2018年くらい・・ 表出していた課題 事業部制 • サイトメジャーVerUPから約10年。負債は溜まり開発速度低下。 LIFULL HOME'S 事業本部 • システムは横断、実組織は事業割なので横断的対応がしにくい、見えない • エンジニアが10名いる部門、1名のみの部門、レベルも様々 賃貸 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注文住宅 営 業 プ ロ ダ ク ト エンジニアのアサイン • 担当マーケットは固定 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい • 技術的施策を計画に織り込めるかどうかも「人」次第 • システム特性かかわらずマイクロサービス化され運用管理に課題 横断でのシステムのリファクタリング/リニューアルの必要性 技術視点で事業計画を語る必要性 一定のレベルの技術判断の必要性 組織全体で対応への意識レベルの変化が必要性 組織構造・人 / 意識 / 仕組み / システム

4つの対応

開発生産性の向上をしていくため 「組織」と「システム」の両面で以 下の4つの課題に対応していく

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

組織構造・人 - 事業部制/職能別のメリット・デメリット(一部) 技術的な横断対応が必要＆技術とビジネスをつなげていける人が重要だったた め、事業部制→職能別 という選択肢を取った。 事業部制組織 職能別組織 メリット ・事業単位での意思決定の迅速化 ・事業単位での採算性の明確化 ・事業ごとのナレッジの蓄積/深化 ・全社統一的な方針の浸透 ・長期視点での戦術推進力向上 ・人材の専門性向上/専門ナレッジ蓄積 デメリット ・会社最適/事業横断視点が薄れやすい ・事業単位での意思決定スピード低下 ・採算性評価が短期利益視点になりがち ・部門間の調整コストの増加 職能の思考に偏重しないようマーケットごとにプロダクトマネジメント体制も導入 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

コンウェイの法則 コンウェイの法則は、簡単に言うと「組織のコミュニケーションの仕方 が、そのままシステムの構造に影響する」という考え方。 たとえば： •部署ごとに分かれてあまり連携しない組織だと、システムもバラバラになりがち。 •チーム同士がしっかり話し合って協力する組織だと、システムも連携しやすいデザインになる。 https://aws.amazon.com/jp/blogs/startup/techblog-microservices-introduction/

• https://aws.amazon.com/jp/blogs/startup/techblog-microservices-introduction/

組織構造・人 – 職能を強め、マトリクス組織に。プロダクトマネジメント導入 事業部制 LIFULL HOME'S 事業本部 • 事業部制 → 職能別xマーケット組織に移行。エンジニアを集約 (100名+) 賃貸 売買 注文住宅 • プロダクトマネジメント導入。各マーケットにプロダクトマネー ジャー、プロダクトデザイナー、テックリード(TL)を配置 営 業 • TLにはシステム観点の改善と事業成長を両面でバランスを取りな プ ロ ダ ク ト 営 業 プ ロ ダ ク ト 営 業 プ ロ ダ ク ト がら、プロダクトマネージャーと会話できる人員を配置。(説明で きる人がいることは大事) 職能別xプロダクトのマトリックス LH事業本部 エンジ ニア 企画 営業 賃貸 売買 https://www.amazon.co.jp/dp/B0814STTHV/ https://www.amazon.co.jp/dp/B098B4NLFJ/ プロダクトマネジメントマネジメント導入においての参考図書 注文住宅 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

• https://www.amazon.co.jp/dp/B0814STTHV/
• https://www.amazon.co.jp/dp/B098B4NLFJ/

組織構造・人 – 戦術計画にTechLead(TL)を組み込む Product Manager 毎年行う次年度の大枠の計画立案 もともとエンジニアは入らないことが多かった • 事業の話がわからない • 技術の話をわかりやすくできない • 事業と技術を繋げて語れない Tech Lead Product Designer テックリードが参加することで進みやすい話 • 技術的負債の開発計画への影響 • 負債返済と短期的でない改修計画 各組織にTLを配置すると上記が解消する(そのような • 現状の開発チーム課題 人をTLにしているため) ので、計画立案メンバーに組 • プロダクトの品質観点の懸念事項と対応工数 み込むようにした。 • 工数を掛けない仮説検証方法 • など その結果、開発環境の改善も、戦略に組み込んでしっ かりと工数をとって対応できることになった。 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

システム健全化への意識向上 職能別組織組成後、目標を整理。 「業務時間の 10% は リファクタリングやシステム改善に時間を使うこと」 を明確にした。他部門へはトップダウンで共有して理解してもらう。 ※それとは別でシステムの刷新などPJ化していたものはあった 実際にあったシーン 個人ではなくチーム全体で10% でもいいですか？ (10人いたら一人を100%、残り を0%など) とあるマネージャー 今は、一人ひとりが通常業務のな かで「当たり前にやること」とい う意識をつけるために全員に10% としてるので、いまはだめです！ 長沢

システム健全化への意識向上 続けていく中で、チームごとにうまく運用が考えられ始め、 『毎月 第2・第4 金曜日の リファクタリング Day』 『4半期に一度の リファクタリング Week』 などの取り組みをしているチームも生まれている。 これによって、エンジニアが前向きに開発しやすい環境を整備されている。 徐々に「文化化」は進んできている。

意識 それも相まって、設立から3年を続けた後、 LIFULL HOME'S 事業本部 ボトムアップの発案で 「Product SRE タスクフォース」 Product SRE タスクフォース テクノロジー本 部 Enabling SRE Platform SRE の設立がされた 対応したいタスクは一覧化し ※Platform SRE と Enabling SRE はすでに役割 ・推定損害額優先度スコア(※1) ・開発効率優先度スコア(※2) として存在していた をそれぞれ算出し優先度づけ ※2 ※1 ・削減見込み時間 削減のインパクト(損害額) ・作業回数/Author(一月あたり) 削減インパクト点数 1回当たりの想定発生分数(削減分数) ・対象範囲 1ヶ月の発生回数 分間の想定損害額

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

仕組み - 各種可視化と指標の探索 当時は生産性が良い悪いもわからない状態 「開発組織の健康状態」を管理し「変化を察知」するために様々な指標 の取得を実施することを決めた。 数字の収集と適切な管理を続けるためには専任の『テクノロジーマネジ メント組織』を設置。

仕組み – 工数を記録していく エンジニアが日々の活動を記録し組織として振り返るための仕組み。 各最小単位の組織ごとに任意の活動時間を取得。これをサービス開発の エンジニアで統一。 ミーティング 開発業務 問い合わせ対応 それ以外

仕組み -テクノロジーマネジメント組織の取得数字 PR（G全部） Commits/@PR(AVE) Author（G全部） Commits/@PR(MED) PR/Author（G全部） 1stコミットからの経過時間(AVE) GitHub PR（社員） 1stコミットからの経過時間(MED) Author（社員） 総コミット数/Author PR/Author（社員） 総コミット数/開発時間 リポジトリ占有率 コード変更量/PR プロダクト負債度 Code Climate @時間x開発しやすさ 負債度信用性 開発時間比率 開発しやすさ 開発時間比率x開発しやすさ 時間x開発しやすさ(占有率x(1-負債度)) 時間x開発しやすさ(占有率x(1-負債度)) リリース回数 Jira 工数記録

仕組み - 一人あたりPR x 開発時間比率

仕組み - 一人あたりPR x リポジトリの複雑度

可視化とプロセスの標準化 エンジニアの開発工程における各プロセスの状況を細かく可視化。 数値が望ましくない部分に着目し、各チームで話し合い、改善策を実施。（毎週回す） 調査 企画発案 設計 実装 テスト リリース 成果(outcome) Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

可視化とプロセスの標準化 可視化して改善を図ることで様々な開発の標準ルールが生まれた(以下一例) • コードの変更は200行以下 • ソースレビュー依頼は1時間以内に少しでも返す • オンボーディングの時間短縮のためのドキュメント整備 • テストデータの整備 • 障害頻度を下げるために品質を上げる • MTGを減らす これらの取り組みで、開発生産性も3年で1.5倍に向上 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

システムへの対応 エンジニアがいる主な組織 全社横断の技術の対応をしていく「横断技術組 織」で以下の2つのPJに着手 1. LIFULL HOME'Sのサイト開発で利用できる共通 BFFの開発 2. アプリケーション基盤「KEEL」の構築 LIFULL HOME'Sの負債やシステムへの関心事を低減させサ イト開発に集中できる環境を整える準備。 上記の2システムはトップダウンで全体へ導入、その後 の改善はボトムアップで行われている。

システムへの対応: アプリケーション - サービスサイトのシステム刷新 クリーンアーキテクチャ + TypeScriptでシステムを刷新。 共通の機構としてフォークして利用可能にした。 移行中 SP 賃貸 売買 PC ETCETCETC 旧BFF Backend API 新BFF 新BFF Backend API

システムへの対応：インフラ - 共通アプリケーション開発・実行基盤 各プロダクト・サービスの独立を保ちながら、プロダクト開発におけ る、共通部分を吸収 各サービスでの本来集中すべきところで クリエイティビティの発揮しどころ 各サービス独自の 部分 各サービス独自の 部分 各サービス独自の 部分 どのサービスでも必要な部分 ・ログ収集 ・NW構築 ・インフラセキュリティ ・デプロイメント ・監視 どのサービスでも必要な部分 ・ログ収集 ・NW構築 ・インフラセキュリティ ・デプロイメント ・監視 どのサービスでも必要な部分 ・ログ収集 ・NW構築 ・インフラセキュリティ ・デプロイメント ・監視 サービス開発 チーム プラットフォーム チーム ほぼ同じカタチに収束しやすい クリエイティビティはあまり必要としない まとめたほうがラク

KEELとは Kubernetes上に構築したLIFULLの内製PaaS - アプリケーション開発の最適化 - 本番環境における5年以上の稼働実績 - LIFULL内の大小60+アプリケーションが稼働中 - マルチテナンシーなシングルクラスタ - プラットフォームとして幅広い機能を担保している - デプロイ、セキュリティ、可観測性、信頼性、パフォーマンス

KEELとは コードジェネレータによる開発者体験の向上 - コマンドを1発叩くだけで開発者は以下の機能を利用可能に

KEELが提供しているもの Kubernetes Cluster - Service Mesh - イベントドリブンなサーバレスワークロード対応 監視基盤 デリバリーパイプライン サイト信頼性や開発者体験を向上させるためソフトウェア

Kubernetes Cluster マルチテナンシーなシングルクラスタ - アプリケーションでリソースプールを共有することでコスト効率を上げる - セキュリティの統制 IstioによるService Mesh - Retry, Timeout, Circuit BreakerやObservabilityを提供 - KEELによってLua, WebAssemblyで拡張機能が配布 Knativeによるサーバレスワークロード対応

可観測性について

取り組みの詳細は外部へ色々発信しています 「LIFULL KEEL」で検索！ CNDT2023の登壇動画 https://cloudnativedays.jp/cndt2023/talks/1976 リードエンジニアのインタビュー記事 https://corp.lifull.com/n/n88d5a90a3527 LIFULL Creators Blog カテゴリ：「KEEL」 https://www.lifull.blog/archive/category/KEEL

• https://www.lifull.blog/archive/category/KEEL
• https://cloudnativedays.jp/cndt2023/talks/1976
• https://corp.lifull.com/n/n88d5a90a3527

当時、課題を設定した4つのテーマ 組織構造・人 意識 仕組み システム

4つのテーマのタイムライン 共通基盤を 全社方針に KEEL基盤 開発着手 システム 組織変更 組織構造・人 インフラ移行 TLの配置 来期戦略立案へ TLの組み込み リファクタリング 文化の仕込み アプリケーション移行 売買マーケット アーキテクチャ刷新開始 リファクタリング の徹底 賃貸マーケット も開始 Product SRE のTF発足 意識 指標開発 着手 エンジニア指標展開 ダッシュボード作成 プロダクト指標開発 仕組み 2018 2019 2020 2021 2022 2023

開発生産性の向上をしていくため 「組織」と「システム」の両面でア プローチした話でした。

End