データエンジニアが事業成長をリードする。『SUUMO』のレコメンドAPIはこうして進化した

トップ画像

「どのように開発するか」だけでなく、上流からプロジェクトに携わり「何を開発するか」から検討したい、と考えているエンジニアの方は少なくないでしょう。

一方、実際の開発現場では「WHAT（何を開発するか）」がすでにある程度検討され、エンジニアはその実現方法を具体化させるフェーズから参画し「HOW（どのように開発するか）」を考えるケースが多いのではないでしょうか。

「WHAT（何を開発するか）」を検討するフェーズからボトムアップでアイデアを出し、プロダクトの成長にコミットしたいーー。そんな思いを強く持つエンジニアにとって、理想的な環境とも言えるのがリクルートです。

今回、同社を代表するプロダクトである『SUUMO』のレコメンドAPIのインフラを、機械学習エンジニア（以下、MLE）とデータエンジニア（以下、DE）が連携して改修したプロジェクトを参考に、事業成長にコミットするエンジニアの姿を伝えます。

このプロジェクトでは、エンジニアが主体となって課題を掘り起こし、その課題にフィットする「WHAT」を練り上げていったという経緯があります。その過程でエンジニアは、事業成長という最終目的を見据えつつ、やるべきことを自ら掘り起こしていきました。

エンジニアは自らのスキルや経験を事業の成長にどう活かせるのか。『SUUMO』を管轄する住まい領域のDEである芳賀宣仁さんと鄭中翔さん、MLEの山畠祥子さんと池上顕真さんにプロジェクトの概要を伺います。

※この記事は株式会社リクルートによるSponsoredContentです。

『SUUMO』を支えるデータエンジニアと機械学習エンジニア
「無駄なリードタイム」を削減するために
トレードオフの状況下でも「目的合理性」を優先
リードタイムは1週間から「30分」に短縮
リクルートではエンジニアが主体となって「事業成長のために何ができるか」を考える

『SUUMO』を支えるデータエンジニアと機械学習エンジニア

── まずは、皆さんのポジションやご経歴を教えてください。

芳賀（DE）　リクルートには2016年に新卒入社し、DEとしてSUUMOレコメンドシステムの開発・運用に従事し、リアーキテクチャやサービスマネジメントを担当してきました。現在は住まい領域のデータエンジニアグループのマネージャーとして、住まい領域のデータとシステム全般を見ています。具体的にはレコメンドなどのデータ分析サービスをスピーディーに開発するためのインフラ整備や、システムの安定運用に責任を持っています。

芳賀宣仁（はが・のぶひと）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室データ推進室
販促領域データソリューション1ユニット（住まい）住まいデータソリューション部
住まいデータエンジニアリンググループ

鄭（DE）　私は中途で2019年末にDEとして入社しました。現在は芳賀の配下で、住まい領域のデータ利活用におけるエンジニアリング部分の設計から実装に至るまで幅広く携わっています。

鄭中翔（てい・ちゅうしょう）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室データ推進室
販促領域データソリューション1ユニット（住まい）住まいデータソリューション部
住まいデータエンジニアリンググループ

山畠（MLE）　私は2018年に中途入社し、MLEとして『SUUMO』の物件をレコメンドする機能の開発に携わっています。現在は新築マンションの領域でデータの利活用を促進するチームのマネージャーを務めています。

山畠祥子（やまはた・しょうこ）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室データ推進室
販促領域データソリューション1ユニット（住まい）住まいデータソリューション部
分譲マンションデータソリューショングループ

池上（MLE）　私は2017年に新卒入社し、山畠と同じくMLEとして、賃貸物件のデータの利活用を行うグループのマネージャーを務めています。

池上顕真（いけがみ・けんしん）
株式会社リクルートプロダクト統括本部
プロダクト開発統括室データ推進室
販促領域データソリューション1ユニット（住まい）住まいデータソリューション部
賃貸データソリューショングループ

── 職種としては、芳賀さんと鄭さんがDE、山畠さんと池上さんがMLEになるわけですね。『SUUMO』のレコメンドシステム開発において、双方はどんなふうに役割分担をしているのでしょうか？

池上（MLE）　『SUUMO』では、ユーザーに対して物件を推薦するレコメンド機能が実装されているのですが、誰にどんな物件を推薦するのかというレコメンドロジックの開発と、『SUUMO』内でレコメンドを表示するためのAPIの開発はMLEが担当しています。

芳賀（DE）　一方で、MLEが容易にレコメンドAPIを開発するためのフレームワークやライブラリの開発、インフラ整備を行うのがDEです。

山畠（MLE）　MLEとDEは日頃からお互い密に連携して仕事を進めていますね。

「無駄なリードタイム」を削減するために

── 今おっしゃったフレームワークというのが、今回フォーカスする「GRAF（グラフ）」ですね。そもそも、「GRAFを改修する」という決断の背景に、どのような課題やその先の目的があったのでしょうか？

芳賀（DE）　『SUUMO』のレコメンドAPIはユーザビリティの向上を目的に開発され、KPIもそれに紐づくものとなっています。

開発初期は、さまざまな画面に物件のレコメンドパーツを出していくことを戦略としていました。元々パーツがなかった画面に新規導入するため、ロジック開発からAPIリリースまでの開発期間が長い一方で、リリース後のKPIの上がり幅は大きいことがほとんどでした。

しかし、ここ数年は各画面へのパーツ導入が進み、新規で出せる白地が少なくなってきたため、既存の画面でのロジック自体を磨き込む戦略へ変更していきました。

既存の画面でのロジックの磨き込みは、新規導入に比べ1回あたりのKPIの伸び幅や確度が小さいです。KPIを伸ばし、今後も継続的に事業貢献するために、開発の目標を「ロジック検証のPDCAサイクルを高速で回せる状態を作る」ことに切り替えました。

池上（MLE）　そこで、今よりPDCAサイクルを高速で回すために何をすべきか、DEとともに検討しました。開発プロセスを可視化するVSM （Value Stream Mapping）をつくり、リリースまでのフローを改めて精査しながら、ボトルネックを探りました。

その結果、モデル開発時の特徴量作成、デプロイ、承認プロセスなどで多くのリードタイムが割かれていることが分かりました。それを踏まえ、特に高いリードタイム削減効果が見込まれるデプロイの改善に優先的に着手することを決めました。

── なぜデプロイのリードタイムが長くなっていたのでしょうか？

芳賀（DE）　改修前のGRAFでは、アプリとインフラが密結合してしまっていました。アプリのデプロイにはインフラの設定変更が必要になるため、どうしてもDEの作業が発生せざるを得なかったのです。

そのため、「MLEの依頼を受けて、DEが環境を作って、アプリをデプロイして、その環境をMLEに渡して」といったMLE⇆DE間のタスクスイッチが挟まっていて、これがリードタイムの増大につながっていました。

山畠（MLE）　作業者をスイッチする上では、新たなアサインや作業者の業務調整なども発生しますからね……。

池上（MLE）　タスク管理ツール上で、タスク依頼のチケットを2回、3回にわたって回さなければならない、みたいなこともありました。

山畠（MLE）　マックスで4回だったと思います。そんな事情もあって、1〜2時間程度で完了するデプロイの作業に、1週間ものリードタイムを要していました。

芳賀（DE）　このタスクスイッチをなくすためにアプリとインフラの密結合を解消し、さらにCI/CDを導入しデプロイを自動化することで、MLEだけで開発を完結できるプロセスを整えた、というのが今回やったことの概略です。

グラフィック

具体的には、MLEがGitでプッシュないしはコミットしたタイミングでCIが動いてTerraformで自動的にインフラが構築され、そのインフラ上にDockerのアプリケーション自体をデプロイし、DEが特に手を動かすことなくCIの中だけで環境を構築してMLEにすぐ引き渡せるような仕組みになっています。

── なるほど。「事業に貢献するためにはどうすればよいか」から入り、エンジニアが主体となって「PDCAサイクルを高速で回せる状態を作る」という目標を設定、開発プロセスの丁寧な検証を通じて「無駄なリードタイムの発生」という課題にたどり着いたわけですね。

山畠（MLE）　そうですね。課題の洗い出しから優先順位付けに至るまで、プロジェクトの前提は自分たちで設定していきました。

その上で、「WHAT（何を開発するか）」についてDEを交えて議論した結果、「GRAFを改修すべき」という結論に至りました。

トレードオフの状況下でも「目的合理性」を優先

── 実際に作業を進めた鄭さんとしては、難しかった点もあったのでは？

鄭（DE）　そうですね。従来の構成では、複数のAPIから利用されるコンポーネントの存在を許容していたため、あるAPIが別のAPIに影響を与える可能性がありました。また、全てのAPIが依存していて単一障害点になっていたコンポーネントも存在していました。

これらの課題を解決しつつフレームワークの思想にあった構成をどう実現するのかについて腐心しました。

判断が難しかった点としては、フレームワークそのものも作り変えるか、インフラだけを作り変えるかという部分です。

フレームワークは従来のインフラを前提とした設計で作られており、新しいインフラに移植した場合にシンプルで効率の良い設計であるとは言えませんでした。でも、今回はインフラだけを作り替えることを選びました。

── なぜ「インフラだけを作り変える」と判断したのでしょう？

鄭（DE）　DEとしてフレームワークから作り直してコードをシンプルにしたい気持ちはあったのですが、それをすると「リードタイムの削減」という目的に対して、必要以上に時間がかかってしまうトレードオフの状況がありました。デプロイ部分で無駄なリードタイムが発生していたことは分かっていたため、インフラとフレームワークをともに作り替える不確実性の高い方法は避け、MLEのニーズに確実に応えられる方法を選択しました。

その上で、インフラ開発の際にはMLEが意識しなくてもいいことをなるべく増やし、自動化する上で毎回同じ作業は抽象化したり、簡単にして隠してあげたり、ということを意識しました。

鄭中翔さんインタビューカット

── いかなる時でもプロジェクトの目的を忘れない姿勢が感じられます。一方、MLEは具体的に、どのような形でプロジェクトに携わられたのでしょう？

池上（MLE）　1APIでのフレームワークの動作チェックを行う検証フェーズと、他のAPIも新しいフレームワークに変更する移行フェーズの2段階のフェーズがあったのですが、初期の検証フェーズにおいては、なるべく多くの観点で動作チェックができるAPIの選定や、そのAPIをベースにしたフレームワークへの要求仕様の策定をDEと協同で行いました。また、DEが開発したフレームワークの上にAPIのロジックを実装しました。

フレームワークやAPIの動作に問題がないことを確認した後は、移行フェーズに移りました。

全APIを新しいフレームワークに置き換える移行フェーズでは、初期検証フェーズと同様にインフラを入れ替えるスケジューリングやロジックのモデル開発、あとは40個にわたるAPIの開発を行いました。API開発は数が多いので、DEとの間で分業して行いました。

── 日頃の密な連携が生かされている印象ですね。大規模メディアのレコメンドAPIは事業上ミッションクリティカルな部分かと思いますが、新たな開発を行うにあたっては、社内調整も大変だったのではないでしょうか？

芳賀（DE）　そもそも住まい領域では本番環境でDockerを使ったことがなかったので、新規のインフラを利用することのリスクを低減するために、2ステップの検証フェーズを設けました。まず、自分のグループ内で検証を進めて、既存のインフラから劣化しないことを証明します。その後に、そのインフラを1つのAPIに載せて2ヶ月ぐらい動かして応答速度に問題がないか、エラーが発生しないかを検証し、最後に他のAPIにもこのインフラを導入していく。

いわゆるカナリアリリース（編注：プロダクトやサービスの新機能を一部ユーザーのみが利用できるようにリリースし、新機能に問題がないことを確認しながら段階的に全体に向けて展開していくデプロイ手法）の手法を参考にした部分はあります。

あとは、前回のアップデートからしばらくたっていて、仕様が決まった経緯を知るスタッフも少なくなっていたので、インフラの仕様を固めるにあたって綿密に調査しましたね。

池上（MLE）　そういった理由から、検証期間も結構長めに取りました。

── 歴史のあるシステムなので、いじること自体が難しそうですよね。

芳賀（DE）　先ほどお伝えしたようにアプリとインフラが変に密結合している部分や、インフラ側のコードにアプリの設定値が入り混んでいる部分もあったので、そこをどう切り離すか考えました。

リードタイムは1週間から「30分」に短縮

── そうした改修をへて、どれほどリードタイムが削減されたのでしょうか？

芳賀（DE）　デプロイにかかっていたリードタイムは30分程度にまで削減できています。

芳賀宣仁さんインタビューカット

── すごい改善具合ですね。リリース回数も増えたのでは？

池上（MLE）　そうですね。開発人数も影響してはいますが、私のグループでは、以前は半期で2〜3回実施していたABテストが、今では10回以上にまで増えています。

山畠（MLE）　私のグループでも、ロジックの改善白地が減っている中でも、リリース回数の増加ペースを維持できています。

── そうして目に見える効果が出ている背景に、やはりMLEのニーズを的確に満たす改善がなされたことが大きいように思います。

山畠（MLE）　そうですね。先ほど鄭も言っていた通り、MLEが意識すべきところと意識しなくていいところの棲み分けが上手く設計されているんです。アプリごとに違う仕様だけを我々がいじれるようになってて、それ以外は基本的にいじらなくても大丈夫、という形で。そのいじり方も一つの設定ファイルにまとまっていて、どこをいじればいいかが分かりやすかったです。

── リードタイムの削減以外に、好影響はありましたか？

芳賀（DE）　リリースまわりの承認プロセスも短縮できました。手動で環境を構築していた頃は手動ということもあってリリースタイミングで各領域のプロダクトマネージャーに承認をもらっていたのですが、自動化した後はただCIのボタンを押すだけなので「リスクもないしある程度簡略化してもいいよね」という感じで、合意が取りやすくなりました。

あとは、インフラ自体を再構築することで知識を継承できた側面もあると思います。多くの場合、インフラは一度構築したら4〜5年は使うものですが、その間に担当の異動や退職もありますから、システムがブラックボックス化してしまう場合があります。過去の「歴史」を遡るのは大変でしたが、そうして知識を継承できたことで、システムを改善しやすい環境が整えられました。

リクルートではエンジニアが主体となって「事業成長のために何ができるか」を考える

── 今回のプロジェクトを概観すると、やはりMLEとDEの鮮やかな連携が印象的です。そもそも一般的な企業では、エンジニアに対してトップダウンで「こういうものを作ってほしい」という要求が下りてくることが多いと思うのですが、リクルートでは「何のために」「何を作るのか」から考えていくスタイルですよね。これもリクルートならではなのでしょうか？

芳賀（DE）　おっしゃるように、さまざまな事業領域でボトムアップの文化が根づいていると思います。リクルートのエンジニアには皆、抽象的な要望に対してどんな「WHAT」を考えるか、という思考が染み付いているように思います。

── 山畠さんは中途入社とのことですが、前職とリクルートではやはりこのあたりのカルチャーは違っていたのでしょうか？

山畠（MLE）　全然違いましたね。前職では受託事業という性質もあって、現場に求められるものを形にすることがほとんどで、限定的な関わりが多くなってしまうことにもどかしさを感じていました。

だから、事業的な要請や課題を設定するところからやってみたい、とリクルートに入社したのですが、入社当時は考え方の違いに驚きました。「事業目標を達成するために、何をやるべきか」をボトムアップで考えることが求められましたから。

── 『SUUMO』のように自社プロダクトを持っていることが大きいのかもしれませんね。

山畠（MLE）　それはすごくあると思います。自社プロダクトを自分のアイデアとスキルで改善していきたい方にとって、リクルートはピッタリの組織なんじゃないかと思います。

山畠祥子さんインタビューカット

とはいえ、自分で課題を発見して解決策まで考えるのは簡単ではありません。視座を高く保ち、エンジニアとしての専門知識だけでなくビジネスサイドの視点も必要になります。その両方を高い解像度で持っていないと、筋のいい打ち手は生まれてこないからです。でも、簡単ではないからこそ楽しいし、すごくやりがいのある環境だと感じています。

池上（MLE）　自分自身も、技術的な専門知識とビジネス視点を同時に身につけていくのは簡単ではありませんでした。ただ、当時のマネージャーにもしっかりとフォローいただいたおかげで、それが実現できましたし、中長期的なキャリアについても考えられました。

私も現在、エンジニアのスキルや課題意識によってきめ細やかに育成を行っています。

池上顕真さんインタビューカット

── KPIを伸ばすためにどうすればよいか、そのためにどんな課題を乗り越えなければならないのか、をエンジニアが主体的に考えられる環境はやはり珍しいように思います。そうして事業成長の観点を持ちながらエンジニアリングに携われるのは、大規模な自社プロダクトを抱えるリクルートならではと言えそうですね。

芳賀（DE）　ある意味“両取り”できるのは利点でもありますね。エンジニアとしては技術に振り切りたい気持ちはすごく分かりますし、私もそうでした。ただ、新しい技術を使いたいだけではビジネスに貢献できず、逆にビジネスの都合だけを受け入れ、技術面での進歩や楽しさがないとエンジニアはやる気をなくしてしまいます。その点、ビジネスと技術の丁度良いバランスを自分たちで決められるというのは、リクルートならではだと思います。

── 最後に、『SUUMO』のレコメンドAPIを今後どう進化させていくか、展望について教えていただけますか？

芳賀（DE）　例えば、フレームワークも今はほとんど内製でコードを書いているのですが、これを一般的なウェブのフレームワークに入れ替えることで保守性やメンテナンス性を高められるように思います。

池上（MLE）　自前のフレームワークを持つことにはメリットもありますが、その分運用も大変になるので、今後はオープンソースソフトウェアをうまく使っていきたいですね。

── ありがとうございました。

リクルートのデータ推進室に関するブログ記事はこちら

今回記事の住まい領域に関するLT会を2/9実施予定！
【大公開！SUUMOの裏側～データ組織の取り組みLT会】ご参加ご希望の方はこちら