負債解消を絶対に止めない。30年モノのシステムに立ち向かうLIFULLの実践知

大規模かつ長期的な技術的負債の解消に取り組むエンジニアのモチベーションを維持することは、容易ではありません。「いつ終わるんだろう」「目立ちにくく、大変な作業なのに評価されにくい」「自分のスキル向上やキャリアにつながっていくか不安」…負債解消に関わるメンバーのしんどさを組織でフォローしきることは簡単ではなく、かといって放置してしまえば進捗の悪化や中断を招いてしまいます。

1997年から物件プラットフォーム「LIFULL HOME’S」を提供しているLIFULL社は、2011年ごろに最初の大規模なリアーキテクチャに取り組んでから今に至るまで、技術的負債に苦しんできた企業です。2017年に「長期的に負債を返済し続けられる組織をつくらねば」と動き出し、約8年をかけてやっと実現できつつあるといいます。

日常的な改善と大規模プロジェクトを両輪で回し続けるための取り組みの中心には、課題を「可視化」し、負債解消を「止めない」工夫、エンジニアの「モチベーションを下げない」仕組みがありました。現体制ができあがるまでの歩みや取り組みを、CTOである長沢翼さんと、プロダクトエンジニアリング部長河津隆洋さんに詳しく伺いました。

• keyboard_arrow_down 経営層と合意を得るための「可視化」と「伝え方」
• keyboard_arrow_down 進捗を止めないために、フェーズを区切る
• keyboard_arrow_down モチベーションを維持するための「称賛」と「評価」
• keyboard_arrow_down 大事なのは「伝える」「止めない」の2つ

――今日はよろしくお願いします。今から約30年前の1997年から動いている「LIFULL HOME’S」の技術的負債とこれまでどう向き合ってきたのか、最初に全体像を教えてください。

長沢：最初に大規模な負債解消に取り組み始めたのは、2011年頃です。当時のLIFULL HOME’Sはマンション、戸建て、賃貸、売買といったマーケットごとに分かれていて、これらを1つのサイトに統合するという大規模リニューアルでした。

その後2014年にオンプレミスからAWSへ移行。また、モノリシックなアーキテクチャから一部マイクロサービスに切り出しました。マイクロサービスの採用によって柔軟性が向上した一方で、各チームが同じような課題に個別に取り組むことになり「車輪の再発明」が頻発してしまいました。

次第に開発生産性が落ち、現場の「このままでは厳しい」との声も強くなってきて。私が2017年にCTOに就任した頃から、河津とも「本格的に技術的負債を解消しないといけないね」という話を始めました。改修に数年かかる大規模な負債にも、日常的に手元で改善していける負債にも、継続的に取り組み続けられる組織をつくろうと、動き出したのです。

――2017年から、負債を解消し続けられる組織づくりに取り組んでいたのですね。

長沢：当時はまだ事業部制で、チームや担当者によって負債への向き合い方にバラつきがあり、エンジニア全体で負債解消に取り組めるような体制づくりが必要でした。

体制変更を見据えて、まずは現状を把握しつつ、目指す組織像や負債解消の重要性について経営層と合意形成を進めていくために、「開発生産性の可視化」に取り組み始めました。

――経営層への説明においては、やはり客観的なデータが重要になりますよね。

長沢：その通りです。技術領域に肌感覚がない人に、負債の状況や緊急度、重要度を言葉だけで伝えきるのは非常に難しいことです。経営層や他職種の方も日常的に使っている「生産性」という指標を用いれば、言葉だけで説明するよりも、直感的に理解しやすいはず。そう考え、3つの指標を可視化しました。

具体的には、日々の業務データから「開発時間」を出し、開発生産性を割り出すために「1人当たりのプルリクエスト数」を集計。そして負債の存在が開発生産性を下げていることを証明するために、各プロダクトの「ソースコードの複雑性」を計測しました。

――開発生産性の指標を「1人当たりのプルリクエスト数」に絞ったのはなぜですか。

河津：この指標を決めるのには、マネージャー陣全員で10時間くらい議論しましたね（笑）。

長沢：本当にそうですね（笑）。他に、書いたコードの行数とか、リリース数という案も出ていました。しかし前者では「とにかくコードを書けばいい」という誤った方向に進みかねません。かといって後者を測るとしても、リリースの日程が外部要因で変わることも多く、開発者でコントロールできない要因が指標に含まれてしまう。

プルリクエスト数は開発者自身でコントロール可能な領域であり、かつ「レビューを通ったプルリクエストの数」を計測すれば、一定の品質が担保されると考えました。

――なるほど。少し話が逸れますが、この指標を用いて改善目標を設定して運用するとなると、「レビューを緩くしてプルリクエストの数を増やす」など品質に影響が出るおそれがあるような気がします。

河津：もちろんその可能性は念頭においていて、レビュー品質を担保する仕組みもつくりました。ただ運用し始めて8年近く経った今でも、危惧したような問題は起きていなくて。当社の働き方ガイドラインにある「一点の曇りもなく行動する」という言葉から、ズルいことをするのはよくないという共通認識があったおかげなのかな、と捉えています。

長沢：これを言っては元も子もないように感じるかもしれませんが、性善説に基づく運用が功を奏すかどうかは、やはり「採用」でカルチャーフィットを最優先にしている点が強く作用しているように思います。

――ここで「採用」が強く影響するのですね。話を戻して、開発生産性の可視化における「ソースコードの複雑性」の計測について教えてください。

長沢：循環的複雑度を測定できるツールを活用しました。リポジトリごとにソースコードを一覧化して、開発者の労働時間、チームの人数など様々な変数と組み合わせて分析しました。

変数ごとの相関関係を分析していると、例えばチームの人数が少ないほど、またコードの複雑性が低いほど1人当たりの生産性が高いなど、これまでの経験知を裏付ける結果が出てくるんです。こういった相関関係を1つひとつグラフ化して、経営陣にも直感的に理解してもらえるように整えました。

――こうして開発組織やシステムの現状を可視化したうえで、どのように経営層の承認を得たのですか。

長沢：「売上や利益を上げるために必要な開発量」を算出し、それを実現するには開発生産性の向上、つまり負債解消が不可欠だと説明しました。

算出した開発量を「今の状態のまま開発するのは困難である」と説明するために、「現状」「必要な開発量」「開発生産性」「技術的負債」の関係をツリー構造で示しました。そして「必要な開発量をこなすためには、技術的負債の解消に取り組み開発生産性を上げなくてはならない」と伝えたうえで「3年で開発生産性を1.5倍に引き上げる」と具体的な目標も盛り込みました。

経営層には、開発生産性の可視化を始めたころから逐一状況を共有しながら進めていました。1回の説明でスパッと承認を得るというよりは、少しずつ現状を伝えながら理解を深めてもらい、何度も説明して最終的に「技術的負債を解消し続けられる組織づくり」の方針を承認してもらう、というプロセスでした。

――全体像を可視化し計画を立て、経営層の承認を得て、負債解消に着手したのですね。具体的にはどのような体制をとっていますか？

長沢：2019年に、プロダクトを横断的に見るプロダクトエンジニアリング部を立ち上げ、エンジニア全体で負債解消に取り組めるような体制にしました。

その上で負債解消においては、専門チームによる集中的な改善と、10％ルールでの日常的な改善を組み合わせることで、全体のバランスを取っています。

数年単位で取り組むような大規模な負債や、プロダクト開発を大きく妨げているような負債には、トップダウンで専門のチームを編成してプロジェクト化しています。

河津：比較的小規模な負債に関しては、各メンバーがリソースの10%を負債解消に充てています。継続的に負債を返して「退行を遅らせる」ことが目的です。このパーセンテージは、これまで15年近く当社の開発に携わってきた経験から「10%くらい割けば、負債が生まれるペースに対しては少し遅いものの、手をつけられないような状況にはならないだろう」と考察し設定しました。

LIFULLのプロダクト開発においては、プロダクトごとに「プロダクトマネージャー」「テックリード」「プロダクトデザイナー」の3職種がついて開発を進める体制にしています。この体制によって、テックリードからプロダクトマネージャーに「生産性を高めユーザーに届ける価値を最大化するためには、ここで負債を返しておくべき」といった助言がしやすくなっています。

ただ、チームごとの負債解消だけでは部分最適になってしまいます。そうならないように、各チームの負債をボトムアップでリスト化し、マネージャー層が集まってRICEスコア（※1）で優先度を決め、優先度の高いものは部内の「タスクフォース」として順番に取り組んでいます。

（※1）RICEスコア：Reach,Impact,Confidence,Effortの4要素で評価するフレームワーク

――実際に負債解消を進める上で、特に進捗を止めないために工夫されている点はありますか？

長沢：重要なのは「フェーズを区切る」ことです。10％ルールに該当しないものはフェーズを区切ってプロジェクト化することで、止まらずちゃんと進められています。

例えば個人情報データベースの刷新のような3年程かかる長期プロジェクトでは、全体を8つくらいのフェーズに区切り、「このフェーズはここまで」とゴールを明確にして進めています。

――フェーズを区切るのは、誰が担当していますか。

長沢：プロジェクトをコントロールする人ですね。大規模な負債解消プロジェクトでは基本的にエンジニアのうち1人が、プロジェクトマネージャーの役割を担っています。

プロジェクトマネージャーを担当する人の選出に関しては、必要なスキルセットを言語化し、それに合う人にマネージャーからお願いする、という方法をとっています。

もちろん最初から、これら全てが完璧に揃っている必要はありません。過去の行動からこうしたスキルを身につけていけそうで、かつ本人にもやる気があれば声をかけてみています。

――初めてプロジェクトマネジメントに取り組む人は、どのようにサポートしていますか。

長沢：定期的にコミュニケーションをとりながら、先述のスキルセットの中で本人が苦手そうなところを支援しています。たとえば他部門とのコミュニケーションにおいて「キーパーソンが誰なのかわからない」「コミュニケーションの機会を作り出すのが難しい」等の場合は、最初にきっかけをつくるためのMTGやランチをマネージャーが設定したりしています。

また、失敗を検知しリカバリーする方法として、プロジェクトが始まるときに「PoNR（回帰不能点）」 を設定し、対策やそうなった際の動き方を徹底的にすり合わせています。プロジェクトが動き出してからは、PoNR以外は切り戻せるように進めつつ、最初に区切ったフェーズの中で進捗や成果を確認するポイントを設けています。

――初めての挑戦でもプレッシャーがかかりすぎないよう、失敗を許容できるようにしているのですね。 10％ルールの負債解消については、進捗を止めないためにどんな工夫をしていますか。

河津：10％ルールの負債解消の中でも、手元でサッと直せるもの以外、例えば依存関係が複雑なものなどは、各チームのエンジニアやテックリードがフェーズを区切っています。

止まったり遅れたりしがちな状況としてよくあるのは、メインの新規開発にどうしてもフォーカスしないといけなくなって、負債解消に割けるリソースが一時的に10％を切ったとき。こうした状況では、遅れを放置せず、必ずリプランニングをして再開するようマネージャーから求めることで、形骸化を防いでいます。

――負債解消は短期的には成果が見えにくいですよね。現場のエンジニアのモチベーションは下がってきませんか。

長沢：そうですね。特に年単位の長期プロジェクトにアサインされていると、メンバーによってはモチベーションを保つのが難しくなってしまうこともあると思います。非常に重要な取り組みなのですが、作業自体は目立ちにくく大変な作業の繰り返しになってしまいますからね。

モチベーション低下の背景としてよく挙がるのは3つ。全体像が見えなく、進捗が感じられないこと。自分が組織に必要なのかわからなくなったり、自分のやっていることの意義が感じられなくなったりすること。自分のキャリアにつながるような仕事ができているかわからない、といった不安。このあたりかなと捉えています。

――モチベーションを維持するためにどんな工夫をしているのでしょうか。

長沢：まず「進捗が感じられない」という課題に対しては、これも「フェーズを区切る」のが効果的です。フェーズを区切って進捗を感じられるタイミングをつくることを徹底し、達成感を得やすくしています。

同時に、プロジェクトが計画通りに進んでいるかがはっきりわかることで、評価もしやすくなります。計画通り進められていれば評価もされますし、機能開発に関わるエンジニアたちと評価に差が出るということはありません。目標となる成果をプロジェクトの進捗などに定め、適切な評価がなされるように制度を設計しています。

――「自分は組織に必要なのか」「意義が感じられない」という思いは、どのようにフォローしていますか。

河津：負債解消プロジェクトの進捗や難しさを組織のみんなに伝えて、称賛を得る機会をつくっています。

LIFULLでは、全社総会や部門総会を月に1回開催していて、毎回MVPを表彰しています。月1回という頻度は、一般的にはかなり高いと思います。しかしこの頻度だからこそ、事業に大きな影響を与えた成果以外にも、しっかりとスポットを当てることができています。

総会では機能リリースに関する発表だけでなく、負債解消の長期プロジェクトの途中経過も積極的に発表してもらっています。フェーズをしっかりと区切っているからこそ、途中経過としての発表のタイミングも計りやすくなっています。発表するための準備には労力を要しますが、発表後「今まで知らなかったけどこんなことをしてくれてたんですね、ありがとうございます」というDMが届いて、モチベーションが上がったという話も聞きました。

自分のやっていることやその意義を多くの人に知ってもらえることは、働くモチベーションに意外と大きな影響があると感じています。

――「キャリアの形成に繋がらないのでは」という不安に対してはいかがでしょう？

長沢：負債解消の経験が、いかに市場価値につながる貴重な経験であるかを伝えています。

大規模なデータベース移行や長年稼働してきたシステムの刷新といった大掛かりなプロジェクトはもちろん、それ以外の負債解消においても、影響範囲を慎重に調査し、安全性、将来性、コストなど様々な観点から最適な手段を選択し、着実に実行していく能力が求められます。これは座学だけでは身につかず、実際に経験しないとなかなか体得できない、非常に高度なノウハウです。

そうした大規模な負債解消のプロジェクトを経験できる機会自体は、そもそも非常に少ない。1つの会社にとっては、クラウド移行のように一度きりだったり、あるいは数年に一度あるかないかの大きなイベントですよね。ということは、必然的に大規模な負債解消をやり遂げた経験を持つエンジニアは、市場全体で見ても母数が限られているわけです。

今、「レガシーシステムを刷新したい」「大規模な負債解消を進めたい」と考えている企業がたくさんあっても、それを実際にリードできる経験者はなかなか見つからない。だからこそ、その経験を持つエンジニアの市場価値は非常に高いのです。需要に対して供給（経験者）が少ないから。特に、プロジェクトマネージャーとして計画から実行までマネジメントした経験があれば、その価値はさらに高まります。

このような市場の現状を伝え、市場において求められている人材であるという事実を補足することで、キャリア形成への不安はある程度解消できると考えています。

――プロダクトエンジニアリング部では、どんな工夫をしていますか。

河津：10%ルールで取り組む負債は、小さいものはメンバー個人、大きいものはチームで選んでいるので、ネガティブな感情はあまりないと思います。強いて言えば、機能開発が逼迫した際は、負債解消の割合を柔軟に調整し、メンバーに負荷がかかりすぎないようにしています。

むしろ課題になるのは、組織全体での負債解消が本当に進んでいるのかが、メンバーには伝わりにくいこと。メンバーは自分の関わる領域に注目しているため、自分の手元で進んでいないと「組織全体で負債解消が進んでいないのでは」と誤解してしまうことがあります。

このような誤解を防ぎ計画的に返済を進めるためには、負債の全体像を可視化し、進捗をメンバーに伝えることが不可欠です。

そこで、現場のエンジニアに「課題だと感じる負債」を、どんな小さいものでもいいから挙げてもらってリストアップし、「負債解消計画書」を作成しました。この計画書は全員に公開し進捗を記していっているので、計画書を見れば、システム全体の負債と今なにがどこまで進んでいるのかを一覧ですぐに把握できます。また、負債計画書に関連するミーティングの議事録も公開しています。

メンバーから「負債解消は進んでいるのか」と質問された際に、計画書や議事録を確認してもらえるようにした結果「何をやっているんですか？」「全然進まないですよね」なんて声も、最近はあまり聞かなくなりました。

――技術的負債を組織で解消していくことにおいて、最も大切なことは何だと思いますか。

長沢：やはり「伝える」と「止めない」の2つですね。どちらが欠けても上手くいかない、両輪だと考えています。

「伝える」ことは、経営層や他職種を巻き込んで負債解消への理解や協力を得るため、そして開発者にモチベーションと主体性を高く持ち続けてもらうために不可欠です。「伝える」ためには、「可視化」が強力な武器となります。システムの内部状況を客観的なデータとして可視化することで、経営や他職種と具体的な根拠に基づいて会話できるようになり、説明に詰まることもなくなります。また、開発組織内においても、負債の全体像や改善計画、進捗を伝え、認識を合わせる上で「可視化」は非常に有効です。

同じくらい重要なのが「止めない」ことです。どんなに綿密に練られた計画も、続かなければ意味がありません。10％ルールやフェーズごとの区切りも、続けるための仕組みです。

この「伝える」と「止めない」が両輪となって初めて、技術的負債を放置しない「文化」が組織に根付いていくと考えています。そうすれば、最終的には私や河津がいなくなっても、自然と動き続ける状態になりますよね。負債解消が当たり前に回る組織を目指しています。

河津：そしてその文化を、エンジニアだけのものではなく、プロダクトに関わる人たち全員の文化にしていきたいです。経営層や他職種の人に対して、例えばプルリクエストとかGitHubといった専門用語を使った時点で「あなたたちに理解してもらう気はありません」という態度を示してしまうことになる。だから、可視化した数値を用いて、伝わりやすい言葉で対話して、共通認識をつくっていく努力が不可欠だと思います。そうやって「負債解消」を会社の文化にしていきたいですね。

取材：古屋江美子、光松瞳
執筆：古屋江美子
編集：光松瞳