20230615_LIFULL HOME'Sを支えるエンジニア 組織の開発生産性への組織的な取り組みと実践

LIFULL HOME'S を⽀えるエンジニア 組織の開発⽣産性への組織的な取り組み と実践 20230615 DXD NAGASAWA Tsubasa 1 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

本⽇のコンテンツ 本⽇話すこと • 開発者体験を向上させ事業価値創出していくのために組織的に対応 したことについて 話さないこと • 技術的な込み⼊った話 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

執⾏役員 CTO ⻑沢 翼 ＠nagasawatsubasa 2008年LIFULL⼊社。 フロントからバックエンド、 iOSアプリ、API基盤の刷新や事業系 システムのクラウド移⾏など幅広く担当。 2017年にCTO就任以来、全社技術、及び社内情報システムの戦略 ⽴案やエンジニア組織・⽂化醸成を実施中。 管掌範囲 ・LIFULL HOME'S のエンジニアリング ・ジェネレーティブ AI プロダクト開発 ・社内情報システム ・海外エンジニア拠点(ベトナム/マレーシア ⼦会社)

会社データ (2023年3⽉31⽇時点) 会社名 証券コード 代表者 沿⾰ 株式会社LIFULL 2120（東京証券取引所 プライム市場） 代表取締役社⻑ 井上 ⾼志 1997年3⽉12⽇ 設⽴ 2006年10⽉ 東証マザーズ上場 2010年3⽉ 東証⼀部へ市場変更 2022年4⽉ 東証プライムへ移⾏ 資本⾦ 連結従業員数 主な⼦会社 ( )は議決権⽐率 9,716百万円 1,766名（内、臨時雇⽤者数293名、海外⼦会社783名） LIFULL CONNECT, S.L.U. (100％)

社是 (最も⼤事な価値観) 社是 利他主義

LIFULL HOME'S ⽇本最⼤級の不動産・住宅情報サイトを LIFULL HOME'S を中⼼に 様々なビジネスを展開。 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

国内不動産ポータル初！「LIFULL HOME'S」ChatGPT向けプラグイン提供開始！ 新しい住まい探しを体験できるので、ぜひ触ってみて下さい！

抽象的なリクエストを具体的な条件 に変換することができている良い例

本題

LIFULL HOME'S を⽀えるエンジニア組織の 開発⽣産性への組織的な取り組みと実践

LIFULL HOME'Sのシステムの構成 注⽂住宅 まちむすび 売却査定 まちむすび 不動産投資 不動産アーカイブ Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

LIFULL HOME'S のプロダクト組織は事業・職能の組織を繰り返していた 事業部制 職能制 事業部制 LH事業本部 LH事業本部 LH事業本部 システム境界 賃貸 営 業 プ ロ ダ ク ト 流通 営 業 プ ロ ダ ク ト 分譲 営 業 プ ロ ダ ク ト 賃貸 エ ン ジ ニ ア 企 画 デ ザ イ ナ . 営 業 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注⽂住宅 営 業 プ ロ ダ ク ト アサイン • マーケット固定 アサイン • 担当マーケットは流動的 • 「PJ」としてアサイン アサイン • 担当マーケットは固定 技術的課題 • 技術スタックはバラバラ • 技術的な交流もなし • マーケットに閉じている ので早かった 技術的観点 • 技術に焦点を当てた、進 化はすることができた • ドメイン知識は薄くなる 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

当時、2018年くらい・・ • 事業部制 サイトのメジャーバージョンアップから約10年。負債は溜まっていく⼀⽅。 開発速度が低下。 • LH事業本部 エンジニアが8名いる部署もあればJrメンバー1名の部署もいて、個別での対 応には限界に 賃貸 営 業 プ ロ ダ ク ト 売買 営 業 プ ロ ダ ク ト 注⽂住宅 営 業 プ ロ ダ ク ト アサイン • 担当マーケットは固定 技術的観点 • システムは横断だが、組 織はマーケット別なので、 横断的な動きがしにくい • システムは横断、組織はマーケットなので横断的な対応はしにくい、⾒えな いのでできない • クラウド移⾏からのマイクロサービス化が⼀部で⾏われ、より分かりにくく • システムのリファクタリング/リニューアルの必要性 • 技術視点で事業戦略を語れる必要性 • 組織全体で対応への意識レベルの変化が必要 意識 / 組織構造・⼈ /システム/仕組み Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

意識 / 組織構造・⼈ / システム / 仕組み これらの4つのアプローチをトップダウン戦略として システム 実⾏することを決めて、実⾏していった。 組織構造・⼈ 意識 仕組み Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

システム Before • マイクロサービスにおいて⾞輪の再発明(ログ/デプロ システム イ機構/監視/インフラ構築管理) • 共通システム部分への対応はしにくい After • アプリケーション基盤(インフラ)の構築と集約 • システム開発の利便性を向上させる仕組み Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

組織構造・⼈ Before • 組織⻑がエンジニア職種でないと、システムへのアプ 組織構造・⼈ ローチが発案されにくい • 事業メリットも踏まえた説明ができないため理解され ない After • システム改善が発案されやすい体制 • 説明能⼒のある⼈の配置 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

意識 Before • あまりシステム改善には時間が取れなく、したいとも思 意識 えない、するものだと知らない After • ⼀⼈ひとりが継続的にシステムを改善し続けるという意 思と⾏動を当たり前にできる Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み Before • システム開発やエンジニアに関する指標が乏しい 仕組み • そのため改善のアクションも取りにくい After • 可視化を進め周囲との共通の⾔語をつくる • 改善のアクションも取っていけるように Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

意識 / 組織構造・⼈ / システム / 仕組み システム 組織構造・⼈ 意識 2018 2019 仕組み 2020 2021 2022 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

意識 / 組織構造・⼈ / システム / 仕組み 共通基盤を ⽅針に 共通基盤 開発着⼿ システム 組織変更 組織構造・⼈ インフラ移⾏ TLの配置 来期戦略⽴案へ TLの組み込み リファクタリング ⽂化の仕込み 意識 2018 細かいところはやりながら修正加えていったところもありますが ⼤枠の設計は当初⽅向性通り 2019 売買マーケット アーキテクチャ刷新開始 2020 賃貸マーケット も開始 Product SRE のTF発⾜ リファクタリング の徹底 指標開発 着⼿ 仕組み アプリケーション移⾏ エンジニア指標展開 ダッシュボード作成 2021 プロダクト指標開発 2022

システム Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

システムへの対応(2018年〜 エンジニアがいる主な組織 全社横断の技術の対応をしていく「テクノロジー 本部」で以下の2つのPJに着⼿ 1. LIFULL HOME'S 事業本部 アプリケーション開発基盤構築 2. LIFULL HOME'Sのサイト開発で利⽤でき る共通BFFの開発 テクノロジー 本部 AI戦略室 横断技術 エンドユーザー向 けサービス開発 インフラ 品質管理 セキュリティ UXR R＆D LIFULL HOME'Sの負債やシステムへの関⼼事を低減 させサイト開発に集中できる環境を整える準備。 上記の2システムはトップダウンで全体へ導⼊、その後 の改善はボトムアップで⾏われている。 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

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

システムへの対応: アプリケーション - サービスサイトのシステム刷新 クリーンアーキテクチャ + TypeScriptでシステムを刷新。 共通の機構としてフォークして利⽤可能にした。 移⾏中 SP 賃貸 売買 PC ETCETCETC 旧BFF Backend API 新BFF 新BFF Backend API Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

組織構造・⼈ Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

組織構造・⼈(2019- 事業部制 LH事業本部 事業部制 → 職能別 x マーケット への移⾏ 賃貸 各マーケットにプロダクトマネージャー、プロダクト デザイナー、テックリード(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/

組織構造・⼈ - 事業部制/職能別のメリット・デメリット(⼀部) 事業部制組織 メリット デメリット ・事業単位での意思決定の迅速化 ・事業単位での採算性の明確化 ・事業ごとのナレッジの蓄積/深化 職能別組織 ・全社統⼀的な⽅針の浸透 ・⻑期視点での戦術推進⼒向上 ・⼈材の専⾨性向上/専⾨ナレッジ蓄積 ・会社最適/事業横断視点が薄れやすい ・事業単位での意思決定スピード低下 ・採算性評価が短期利益視点になりがち ・部⾨間の調整コストの増加 職能の思考に偏重しないようマーケットごとにプロダクトマネジメント体制も導⼊ Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

組織構造・⼈ – 戦術計画にTechLead(TL)を組み込む Product Manager 毎年⾏う来期⼤枠の計画を⽴てていくタイミング Tech Lead Product Designer エンジニアは⼊らないことが多かった • 事業の話がわからない • 技術の話をわかりやすくできない • 事業と技術を繋げて語れない テックリードが参加することで進みやすい話 • 技術的負債の開発計画への影響 • 負債返済と短期的でない改修計画 • 現状の開発チーム課題 • プロダクトの品質観点の懸念事項と対応⼯数 配置したTLなら上記が問題なくできるので、計画⽴ • ⼯数を書けない仮説検証⽅法 • など 案メンバーに組み込むようにした Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

組織構造・⼈ – 戦術計画にTechLead(TL)を組み込む 職能別xプロダクトのマトリックス 戦略の中で、システム分離に踏むこ エンジニ ア 企画 営業 エンジニ ア 企画 営業 賃貸 む事ができた。 売買 この「リニューアルをしながら」分 注⽂住宅 離をしていくという計画は、Tech Leadによりボトムアップのアプ ローチ。 リニューアルしながら、 マーケットごとにシステム を分離していく⽅向性 賃貸 売買が先⽴ち、その後賃貸も実⾏。 売買 注⽂住宅 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

意識 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

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

意識 続けていく中で、チームごとにうまく運⽤が考えられ始め、 『毎⽉ 第2・第4 ⾦曜⽇の リファクタリング Day』 『4半期に⼀度の リファクタリング Week』 などの取り組みをしているチームも⽣まれている。 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

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

仕組み Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

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

仕組み – 前提：LIFULLにおける「⽇次採算制度」 全社員が⽇々の活動を記録し組織として振り返るための仕組み。 各最⼩単位の組織ごとに任意の活動時間を取得。これをサービス開発の エンジニアで統⼀。 要件定義・仕様作成 調査・設計 設計レビュー 実装 ソースレビュー テスト仕様書作成 テスト仕様書レビュー テスト実施 リリース作業 リリース後障害対応・不具合 調査 サービス運⽤ MTG 他部署調整 その他 before ミーティング 開発業務 問い合わせ対応 それ以外 after Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み -テクノロジーマネジメント組織の取得数字 PR（G全部） Commits/@PR(AVE) Author（G全部） Commits/@PR(MED) PR/Author（G全部） 1stコミットからの経過時間(AVE) GitHub PR（社員） 1stコミットからの経過時間(MED) Author（社員） 総コミット数/Author PR/Author（社員） 総コミット数/開発時間 リポジトリ占有率 コード変更量/PR プロダクト負債度 @時間x開発しやすさ Code Climate ⽇次採算 負債度信⽤性 開発時間⽐率 開発しやすさ 開発時間⽐率x開発しやすさ 時間x開発しやすさ(占有率x(1-負債度)) 時間x開発しやすさ(占有率x(1-負債度)) リリース回数 Jira Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み -どのように「開発⽣産性」を上げていくのか仮説 開発時間 x 能⼒ x 開発効率 = PR 引き続き強化 ⼀定数 リポジトリ占有率 x 単位リポジトリの開発効率 ⼀つのチームでどれだけ リポジトリを専有してい るか(複数なら掛け算) ⾏数・複雑度・重複度・ テストカバレッジ Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み - 当時のまとめ 傾向的に⾒えたもの 開発時間 > Repo占有率 >= Repo健全度 その他 ・Repo占有率が極めて⾼い場合、チームの習熟度も⾼くリポジトリの複雑 度によらないケースが多い ・そうでなければ、負債度・占有率が⼤きく影響 → 意味のある単位のサービスの分割・リファクタの⽅針は良い 「開発時間」は打ち⼿に変換するまでにはもう少し分解が必要 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み – Githubの部分も様々に分析 プロセスの各⼯程の時間を最⼩組織単位(グループ)ごとに可視化。 企画発案 調査 設計 実装 テスト リリース 成果(outcome) Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み - 上記の部分を⾒つつ、週次で打ち⼿を確認、対応している 最⼩単位のチームでそれぞれ毎週やることを決めて実施 • コードの変更は200⾏以下(PRからマージまでの時間) • レビュー依頼は1時間以内に少しでも返す(PRからマージまでの時間) • オンボーディングの時間短縮のためのドキュメント整備(⽇次採算) • テストデータの整備(PRからマージまでの時間) • 障害頻度を下げるために品質を上げる(⽇次採算) • MTGを減らす • Etc 良かったものはグランドルール化していく Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み – これらの仕組みによって、⽣産性は昨対⽐115%を達成 各チームが⾃分たちで指標を確 認、打ち⼿が打てるようにした 。 また、週次でアクションを確認 しており、しっかりと指標を⾒ る週間もついている。 結果として昨年対⽐で115%ほど ⽣産性は向上した。 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

仕組み -テクノロジーマネジメント組織がさらに取得し始めたメトリクス 開発プロセス全体の数値や、それ以外の部分も取得するために様々な指標を整備中 • 運⽤監視体制指標と障害数を元にしたリスクプロダクト判定数値 • 仮説検証回数(≒デプロイ回数) • サービス開発にかかるリードタイム(検証中) • マーケット別DX Criteriaアセスメント結果

意識 / 組織構造・⼈ / システム / 仕組み 共通基盤を ⽅針に 共通基盤 開発着⼿ システム 組織変更 組織構造・⼈ インフラ移⾏ TLの配置 来期戦略⽴案へ TLの組み込み リファクタリング ⽂化の仕込み 意識 2018 細かいところはやりながら修正加えていったところもありますが ⼤枠の設計は当初⽅向性通り 2019 売買マーケット アーキテクチャ刷新開始 2020 賃貸マーケット も開始 Product SRE のTF発⾜ リファクタリング の徹底 指標開発 着⼿ 仕組み アプリケーション移⾏ エンジニア指標展開 ダッシュボード作成 2021 プロダクト指標開発 2022 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

最近だと前述の物たちに加え、海外の開発拠点との連携し 如何にスループットを上げていくかの取り組みを実施中 Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

To be Continued... Copyright© LIFULL Co.,Ltd. L All Rights Reserved.

End Copyright© LIFULL Co.,Ltd. L All Rights Reserved.