• Twitter
  • Facebook
  • Google+
  • RSS

マルチテナント方式からセルフホスティング方式へ。リクルートはこうして横断プロダクトを横展開する

リクルート社の「データ推進室」はアジリティの高いボトムアップ文化を武器に、領域横断的に各事業領域のデータ戦略・立案を支援しています。今回は内製のデータ処理基盤「Crois(クロイス)」を、不動産情報サイト「SUUMO」のレコメンドシステムへ導入したプロジェクトを事例に、データ推進室のカルチャーをご紹介します。社内開発されたプロダクトを各事業部に展開する難しさを感じたことのあるデータエンジニアの方は必見です。

インタビュー出演者

2021年に7つの中核事業会社および機能会社を組織統合したリクルートでは、各社のデータエンジニアによって組閣された「データ推進室」が領域横断的に各事業領域のデータ戦略・立案を支援しています。前回記事では、そのデータ推進室が持つアジリティの高いボトムアップ文化をご紹介しました。

今回はその文化が実際にどのような形で活かされているか、「横断プロダクト(複数事業領域での利用を想定して開発される​​リクルートの社内プロダクト)」の導入事例をもとに見ていきます。

さて、社内開発されたプロダクトを各事業部に“領域展開”するのは、案外難しいものです。すでに使用されているツールとの兼ね合い、慣習や制度の問題、リソースの問題、そして技術的な問題。さまざまな障壁が立ちはだかり、調整に苦労した経験のある方も少なくないはず。

組織間の連携を強化し、社内システムプロダクトの横展開を促進・効率化させる上では、どのような考え方や動き方が必要になるのでしょうか。内製のデータ処理基盤「Crois(クロイス)」を、不動産情報サイト「SUUMO」のレコメンドシステムへ導入したプロジェクトの裏側について、データ推進室のデータテクノロジーユニット長である阿部直之さん、プロジェクトをメインで推進した鶴谷誠文さん、若月良平さんの3人に話を伺いました。

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

横断プロダクトを技術的負債の解消に活用する

── まずは、Croisというプロダクトの概要を教えてください。

阿部 Croisは、リクルートグループの広告システム開発を担うRCO(リクルートコミュニケーションズ社、現・リクルート社)が開発したデータ分析基盤です。機械学習やデータ分析のジョブ管理を行うためのワークフロー機能を備えています(※)。当初はアドテクのためのデータ処理基盤として使っていました。

※ Croisの仕様について紹介した記事はこちら


阿部直之さん近影

阿部 直之(あべ・なおゆき)
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
データテクノロジーユニット長

── 鶴谷さんは、SUUMOのデータ分析基盤の担当者として、今回の導入プロジェクトをメインで推進されたと伺っています。そもそも、Croisをどのような経緯で知ったのでしょう?

鶴谷 Croisの存在を知ったのは、組織統合のプロセスの中でプロダクトやデータ基盤を各担当者が共有し合う社内勉強会の場でした。


鶴谷誠文さん近影

鶴谷 誠文(つるたに・まさふみ)
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室

── なぜ、SUUMOにCroisを導入する必要があったのでしょうか?

鶴谷 もともとSUUMOのレコメンドシステムには内製のバッチワークフローがありました。しかし技術的負債が積み上がって開発・運用効率が低下し、その改善が課題となっていました。その負債を解消してくれそうなプロダクトとして、Croisに白羽の矢を立てました。

というのも、私自身やチームのメンバーがCroisを触ってみたところ、レコメンドシステムの開発、運用を効率化できる機能群が備わっていることが分かって。不足していた機能も、Croisのモジュール(Crois利用者が個別にカスタマイズできるデータ処理機能)を開発して登録すれば充足できそうで、「これはSUUMOのレコメンドシステムに導入できそうだ」という意見がボトムアップ的に上がってきました。

そこから具体的にCrois開発側の若月さんや他のメンバーと相談を始めた形です。

「車輪の再発明」を避けるためのアイデアとは

── 導入までは、どんなプロセスで進めましたか?

鶴谷 まずシンプルにPoC(Proof of Concept、実証実験)でSUUMOのレコメンドシステムのワークフローの一部をCroisで動かして、出てきた課題をチームやCrois開発メンバーに共有し、毎週1回話し合いました。

こうした技術面の課題解決は比較的順調に進んだ一方、運用面の課題に関しては調整事項も多く、解決に時間を要しました。当時のCroisは複数の事業領域で共同利用する「マルチテナント方式」で運用されていましたが、そのままの方式でレコメンドシステムに導入した場合、他の事業領域でバースト的な負荷がかかると影響を受ける可能性があります。

また利用者の権限では、障害検知やログの参照が一部できないケースがある点も懸念点として挙がりました。そもそも複数の事業領域が利用する中で、障害対応の優先度をどう決めるのか、その点も議論の必要がありました。

── 機能面の課題は解決の道筋が分かったが、運用面の課題は一筋縄に解決できなかったと。

鶴谷 はい。SUUMOのレコメンドシステムはカスタマーにお勧めの物件情報を表示するのですが、もしワークフローに障害があると、ユーザー体験が悪化するだけでなく、収益にも大きく影響します。先ほど説明しましたが、複数事業領域に展開されているシステムは他事業での負荷の影響を受ける可能性があるだけでなく、障害対応の優先度も決めづらい。そのため、安定稼働と障害時の迅速なリカバリをどう担保するのか、という指摘が挙がったわけです。

阿部 その背景として、「自分たちが面倒を見ておらず詳細が分からないサービスを運用するのは心配だ」というSUUMO側の担当者の心理的なハードルもありましたよね。

鶴谷 そうですね。なので、マルチテナント方式で無理に課題解決を図るより、もっと効率的な打ち手を探ったんです。

そこで出てきたアイデアが「CroisをSUUMO側で運用していく」というものです。つまり、SUUMOのレコメンドシステムのAWSにCroisをデプロイし、レコメンド担当者自身がCroisを運用する「セルフホスティング」ができないか、と。

── SUUMO側は、運用を引き受けてまでCroisを使いたかったわけですね。

鶴谷 はい。私たちも「車輪の再発明」はナンセンスだと分かっていましたから。ゼロからツールを開発するよりも、すでに出来上がっていて安定稼働の実績があるCroisに必要な機能を追加して利用した方が合理的であることは明らかです。だから、セルフホスティングのアイデアは、物事を前進させる大きな一歩でした。

若月 もともとCroisには「社内オープンソース化」というアイデアがあって。今回の要望を機に、Croisの開発側でもセルフホスティングへの対応を検討してみよう、という流れになりましたね。


若月良平さん近影

若月 良平(わかつき・りょうへい)
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室

インフラごとデプロイする難しさ

── Croisに技術的な修正を加えて事業部門によるセルフホスティングの要望に対応する、というのは今までのやり方をガラッと変えるわけで、ハードルの高いチャレンジだと思います。でも、会社的には「メリットがある」と判断したわけですよね。

阿部 私は当時、2つの立場がありました。一つはCroisを含む横断プロダクト開発組織の責任者。もう一つはデータ推進室全体のエンジニアリングを事業領域も含めて見る立場です。そこで、何が最適なのかを判断した……というより、Croisを活用していきたい人・横断プロダクトとして成長させていきたい人たちが議論しやすいよう、お膳立てをした形です。方式などを決めたのはあくまで双方のチームの議論の結果でした。

若月 技術的な課題のなかでも解決が難しかったのは、Croisをインフラごとデプロイすること。アップデートの際、Crois本体に追随してダウンタイムなしに適用することはとてもチャレンジングで、各機能の順序性を保つことが一番大変な部分でした。

阿部 Croisは1本のプログラムではなく、大量のマネージドサービスを組み合わせて作られています。そのため、AWSマネージドの機能アップデートも含めて実施し、アップデートの順序性やコンポーネントのバージョン差が出ないよう制御する、といった作業の難度は非常に高いものでした。

若月 マルチテナント環境のCroisでは、毎回リリース順序を決めた上で手作業でリリースを行っており、一定のコストがかかっていました。

ということは、セルフホスティングのために自動デプロイツールを作れば、マルチテナント環境下のCroisにも適用できるし、セルフホスティングでの自律的な運用にもつながるし、どっちに転んでも得がある。

インタビュー出演者

小さなミッションをクリアしながら「関門」を乗り越えた

── そのような経緯でSUUMOのチームによるCroisのセルフホスティングが始まったわけですね。そこへ至るまでに、どのようなアクションを実行されたのでしょう?

鶴谷 まず、デプロイツールが完成するまでの間は、マルチテナント環境のCroisにSUUMOのレコメンドシステムの中で試験的に実行することが可能なバッチを載せて運用し、運用ノウハウを得ました。デプロイツールの開発にはリードタイムが必要ですから。デプロイツールが完成してからは、SUUMOのレコメンドシステムのAWSにCroisをデプロイして環境構築した上で、残りのバッチワークフローをCroisにマイグレーションし、ここでようやくセルフホスティング方式に移行できた形です。

もう一つの施策は、SUUMOのレコメンドシステム担当者が、Croisの開発チームを兼務し、Croisの一部開発タスクを担うようにしたこと。

これによって、セルフホスティングをするのにまず必要となるCroisの仕様理解が進みました。また、兼務した担当者がSUUMO側にノウハウを持ち帰るので、自分たちでトラブルシューティングをしたり、「こういう仕組みで動いているから問題ないよ」と判断したりと、Croisを自律的に運用できるようになりました。人材の交流も双方のチーム間で活発になりましたね。

加えて、SUUMO側とCrois開発チームのコミュニケーションも密になり、「こういう機能を具備すればいいのではないか」「事業側ではこういう課題がある」とレベルの高いフィードバックができるようになりました。

── SUUMOのチームがCroisの存在に注目してから、実際にセルフホスティングで動くようになるまで、どれくらいの期間が必要だったのでしょうか?

阿部 全体で1年ほどです。そのうち半分は、鶴谷さんが事業領域側との調整に費やし、残り半年で開発まわりのタスクをこなしました。

調整に関しては正直、けっこう大変でした。SUUMOではデータの利活用が進んでいて、事業側の期待値も高い。失敗はできません。

そのため、小さなミッションを着実にクリアしていきながら「段階的に」動かす必要がありました。リクルートでは、一度実績が出れば、物事が比較的スムーズに進む風土があります。そこを鶴谷さん側で、半年かけて、小さな実績を積ませるような調整をしてもらった形です。

鶴谷 「関門」は計3つありました。まずは自分たちが運用体制や動作をレビューする。次に、事業領域側のエンジニアやアーキテクトがレビューをする。最後に、その上長である役員が決裁する。

そこで説明責任や安全性の担保が論点になりました。そうした点については例えば、まずはマルチテナント方式でCroisを動かしてノウハウを得るなど、ポイントごとに検証、説明し、「それだったら次に進んでいい」と信頼を勝ち取っていきました。

インタビュー出演者

阿部 期待値が高いからこそ、「登り方」を丁寧に設計する必要があったんですよね。

── そうしたプレッシャーについて、現場はどのように受け止めていましたか?

若月 私たちCroisの開発側にとっても、良い方向だったように感じています。他にあんまりない取り組みのため手探りではありましたが、その分わくわく感を持って進めることができました。

阿部 運用と開発を正しく分離できるパターンを模索した形です。SUUMOとそれ以外の領域でサービスレベルが異なる運用をセルフホスティングとして分離しました。全体のサービスレベルは高い方に寄るため、全ての運用責任をCroisの開発側に背負わせると、横断プロダクトとしてのCroisの進化が止まってしまうおそれがあったんです。いわゆる、Github.comとGitHub Enterprise(GHE)の使い分けに近いイメージでしょうね。

鶴谷 近年、DevOps(開発と運用の統合)がよく言われますが、私たちはあえてDevとOpsを分離させました。エンジニアリングのトレンドからは外れてしまいますが、教科書的な“原理主義”よりも実利を取った形です。これは当事者意識があったからこそ。

もともと、SUUMOのレコメンドシステムは、一定の技術的負債を抱えつつも自分たちで責任を持って運用していました。その開発と運用の効率化という課題を、Croisの力を借りながら乗り越える。そこは最初から「事業領域の中で仕事をしている自分たちでなければできないこと」と自負していました。逆に、事業領域から離れた別の組織に運用責任を課すのは、事業領域の考え方や温度感を押しつける形になってしまいかねない、と。

ただもちろん、すべての領域においてDevとOpsを分離させているわけではなく、ケースバイケースで対応しています。

阿部 リクルートの社内では「圧倒的当事者意識」という言葉をよく使いますが、この「当事者」はあらゆるプロジェクトにおいて大事なキーワードです。当事者だからこそ守れるものがある。組織統合後、当事者として発言して物事を合理化していこう、という動きがより活発になりましたね。

インタビュー出演者

「エンジニア文化」を尊重し、ボトムアップを徹底した

── 現在、プロジェクトはどんな段階にありますか?

鶴谷 ほぼ完了した状態です。SUUMOのレコメンドシステムのワークフローはCroisに切り替わりました。SUUMOレコメンドシステム以外の処理も、Croisに移行し始めています。

阿部 Croisはプロダクトとして「ほどよい抽象化」が出来ていたように思います。使いやすい、しかし特化し過ぎず、ある程度応用が効く。今回の取り組みも含めてそういうプロダクトに育ててもらった、という思いがあります。そして社内でも導入基準が厳しいことで知られるSUUMOの事業領域で実績ができたので、他の事業領域でも導入の話が進んでいます。

鶴谷 一個良いものを入れると、他の人たちも「僕らもこれを使いたい」という力学が働きます。そもそもリクルートはどんなプロジェクトにおいても、蓄積したナレッジを他の事業部に“領域展開”するカルチャー。今回は、導入時に議論される論点はすでに出尽くしていて、それぞれ解決済みなので、他領域ではよりスムーズに導入できると思います。

── 今回のプロジェクトから得られた学びは、どんなものでしょうか。

阿部 現場主導でプロダクトを選定し、担当者同士が話し合ってプロジェクトを進めるやり方は合理的だし、効率も良い。トップダウンで「これを導入しなさい」と指示する方法もありますが、現場のエンジニアたちの納得を得られないまま進めても、使い方の工夫にはあまりつながらない。

エンジニアは、「やろう、やりたい」と思ったときに一番パフォーマンスを発揮します。今回はその主体性を大事にしました。さらに、エンジニアのチームどうしを突き合わせることで、コードを共通言語にした解像度の高いコミュニケーションを促しました。

そうした要素も積み重なって、プロジェクトの規模を考えると、むしろ短期間で進んだ形です。

鶴谷 現場に技術的な裁量が与えられていることは、エンジニアにとってうれしいことでした。

若月 モチベーション維持の観点でも、自分で「正しい」と思えるやり方を貫ける方が良いですしね。

インタビュー出演者

阿部 もちろん、セキュリティやガバナンスといった会社の方針に関わる分野はトップダウンが向いています。しかし、現場主導のプロジェクトをトップダウンで指図することは効果的ではないように思います。

データの領域は、商材の違い、打つ施策の違い、進行に影響する変数、それらに詳しい現場の人が推進した方が合理的です。もちろん、ボトムアップのプロジェクトどうしがコンフリクトを起こすケースはありますが、そこはお互い議論できるような土壌を整えています。

── 最後に、今回のプロジェクトを振り返った所感をお聞かせ下さい。

阿部 プロセスと結論の両方で合理的に進められた、と感じます。

リクルートには、複数の事業領域に導入できる横断プロダクトがCrois以外にも存在します。今回、チーミングや他部署との調整などを通じて出来た「型」は、他の横断プロダクトを導入する際にもそのまま展開できるでしょう。その意味で、リクルート社内でも先進的な取り組みだったと考えています。

特に、領域組織・横断組織が前向きに協業するモデルケースとなりました。いま、Croisという単語が社内のあちこちで話題になっていて、今後自然な形で情報共有も進んでいくのではないか、と感じています。組織統合後にボトムアップ文化を活かした成功事例と言えるでしょうね。

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

インタビュー出演者


「Croisを支える技術」についてより詳しく知りたい方は、データ推進室の公式ブログ記事

株式会社リクルートではエンジニアを募集中!

今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック!

さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中!

株式会社リクルート キャリア採用 Facebookページ 株式会社リクルート 公式Linkedin

🎁 Amazonギフト券が当たる! リクルートに関するアンケート 📝

※アンケートは終了しました。ご協力、ありがとうございました。

関連記事

記事中に登場したCroisについては、次の記事も参照してください。

そのほか旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。


[SponsoredContent] 企画・制作:はてな
取材・構成:星暁雄
撮影:小野奈那子