運営を長年続けるうちに開発コードが膨大になり、身動きが取りづらくなる。大規模なサービスにはよくある課題です。しかし、根本的な解決に向けて大ナタを振るうには「痛み」も伴うため、なかなか踏み切れない、という企業も多いのではないでしょうか。
リクルートでは今回、『ホットペッパーグルメ』と『じゃらん』という大規模サービスのアプリのリプレイスを実施。リプレイスに際して、Flutter、Kotlin Multiplatform Mobile（以後、KMM）という新しい技術要素を導入しました。Flutterは今やクロスプラットフォーム開発に欠かせないフレームワークとして磐石の地位を固めつつあります。一方、後発のKMMも、クロスプラットフォーム開発とネイティブアプリ開発、双方の利点を兼ね備えたSDK（Software Development Kit）として今注目を集めています。
いずれも過去の導入事例が少なく、その背景にチャレンジングな決断がありました。
リプレイスを経て、組織・技術の両面でさらに進化しつつある2つのアプリ。チャレンジングな決断の背景に、どのような課題、そしてどのような試行錯誤があったのでしょうか。
今回はリプレイスプロジェクトを牽引してきた、朏島一樹さん、砂川辰徳さんにご登場いただき、リプレイスの経緯や開発組織の変貌ぶり、リプレイスを経て見えてきた課題など、さまざまなトピックについてお伺いしました。
※この記事は株式会社リクルートによるSponsoredContentです。
- 「アルファ版」のSDKを導入した理由
- Flutterを「段階的に」導入する手法、Add-to-appとは
- 開発期間のずらし、スコープの明確化…フルリプレイスのリスク回避術
- リスクがあるなかでも新たな技術を取り入れる「メリット」
「アルファ版」のSDKを導入した理由
── まずはお二人の自己紹介をお願いします。
朏島 2014年にアプリケーションエンジニアとして入社し、2018年まで『Airレジ』等の「Air ビジネスツールズ」の開発に従事していました。その後『ホットペッパーグルメ』を含む飲食事業領域に異動し、現在は飲食事業領域、ビューティー事業領域、事業開発領域の開発組織を統括しています。自身の統括領域には、社外のパートナーも含めて現在数百名ほどのエンジニアが所属しています。
朏島 一樹（はいじま・かずき）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 販促領域プロダクトディベロップメント2ユニット（飲食・ビューティー・事業開発） 飲食・ビューティー・事業開発領域エンジニアリング部 部長
砂川 2018年にサーバサイドエンジニアとして入社し、当初は朏島とともに『Airレジ』のリアーキテクティングを検討していました。その後、旅行事業領域に異動し「じゃらんステージプログラム（『じゃらん』の会員限定サービス）」の基盤を構築しました。2021年からは、旅行事業領域の開発組織を統括しています。もともとサーバサイドエンジニアなので、アプリ開発に触れるようになったのは実はマネジメントを始めたタイミングからです。
砂川 辰徳（すながわ・たつのり）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 プロダクトディベロップメント室 販促領域プロダクトディベロップメント1ユニット（住まい・マリッジ＆ファミリー・自動車・旅行） 販促1U領域エンジニアリング部 旅行プロダクト開発グループ グループマネージャー
── ありがとうございます。『じゃらん』と『ホットペッパーグルメ』。まずは2つのアプリの技術仕様について教えてください。
砂川 リプレイスを実施するにあたって、『じゃらん』はFlutterのフレームワークを採用しました。ただ、全ての機能をFlutterで作っているわけではなく、現状はトップ画面や「遊び・体験」予約の検索機能など一部の機能についてのみFlutterを取り入れています。iOSとAndroidそれぞれのネイティブのソースコードで書いた部分もありながら、一部はFlutterで動いているという状態です。
朏島 『ホットペッパーグルメ』ではKMMを採用し、現在はiOSとAndroid、KMMエンジニアの3チーム制で開発を行っています。KMMではアプリのビジネスロジック部分などを開発し、UIはiOSとAndroidでそれぞれ開発しています。
── Flutterは当時安定版のリリースから間もない、導入事例も少ないフレームワークだったかと思いますが、なぜその技術選択へ至ったのでしょうか？
砂川 大前提として、サービスの課題感（後述）にフィットしていたからだと思います。
『じゃらん』では、開発の効率化が課題として挙がっていたので、Flutterを導入することでクロスプラットフォーム開発により開発を効率化できる、という期待感がありました。
あと、全てをFlutterにリプレイスすることは当初から志向しておらず、既存のシステムを生かしつつ新機能の追加や機能改修を行う方針だったので、段階的（部分的）に導入できるというFlutterの特徴も魅力的でした。
併せて、ホットリロードやホットリスタートでビルド時間の短縮につながったり、ウィジェットが充実していたりするのも、開発効率化の観点ではメリットでしたね。
ただ、ご指摘の通り、導入当時Flutterはバージョン1.0、安定版がリリースされて1年未満という新しいフレームワークでした。実績の少ないフレームワークを導入するのは大変でしたが、後でお話しするAdd-to-appなどさまざまな手法を駆使し、リスクを減らしながら進めていきました。
── KMMはFlutterよりも後発で、いまだ導入事例も少ないSDKですよね。
朏島 そうですね。導入した当初はFlutterよりも前段階のアルファ版だったので、導入がうまくいかなかったら、あるいは導入後にクローズしてしまったら、という懸念はありました。
実は『ホットペッパーグルメ』にもOS間での機能差分の発生や二重開発による工数の圧迫といった課題が生じており、それらをクロスプラットフォームの技術で解決しようとしていました。ただ、同じクロスプラットフォームの技術でもReact NativeやFlutterのように技術スタックが丸ごと違うものを採用するのは、開発リソースが少なかったため難しい。
併せて、ビジネスサイドから「操作性やUXの観点でUIは各OSの標準に則ったものにしたい」という要望が寄せられていたので、ロジックの共通化をしながらOSごとにUIを作り替えられるKMMが候補に上がりました。
KMMは言語としてはKotlinのため、開発者体験として近いAndroidエンジニアに対応してもらうこともできますし、サーバーサイドでKotlinを扱う部署もあったので、いざとなれば協力してもらえるという目論見もありました。
Flutterを「段階的に」導入する手法、Add-to-appとは
── リプレイスを先行して実施したのは『じゃらん』だとお聞きしました。リプレイスを決断するまでの経緯をお聞かせいただけますか？
砂川 前段となる改修プロジェクトがスタートしたのは2019年で、『じゃらん』のアプリがリリースされてから約10年がたった頃でした。
当時の課題としては、さまざまな機能が追加されてシステムが大規模化。多くのエンジニアが開発に加わることでコードが複雑化していました。結果として、アプリのビルド時間が増えて非効率になっていたり、開発時間も増加傾向にありました。
もう1つ、長年の開発でiOSとAndroidそれぞれのアプリの機能に微妙な機能差分が生じてしまっているという課題もありました。
── 決定打となるような出来事はあったのでしょうか？
砂川 現場のエンジニアがそういった課題を検討していたところに、ブラウザ版にしかなかった「遊び・体験」予約の機能をアプリへ実装するという案件が持ち上がったんです。それを契機にFlutterを導入し、先ほどお話ししたような諸々の課題を段階的なリプレイスという手段で解決していく足掛かりにできないか、と模索し始めたのがきっかけですね。
── リプレイスは現場の課題を解決するための手段だったということですね。具体的に、リプレイスに付随するどんなソリューションで課題解決を目指したのでしょう？
砂川 やはりクロスプラットフォーム開発への期待感が高かったですね。1つのソースコードをiOSとAndroid両方に対応させられるので、単純に開発工数を削減できます。また、同一のソースコードから生成することでOS間の機能差分の発生も防ぐことができます。
── 確かに、機能差分を解消する上でクロスプラットフォーム開発は有効な打ち手だと感じます。先ほど、Flutterを「段階的（部分的）」に導入したと伺いましたが、具体的にどのような手順で進められたのですか？
砂川 3つのステップに分けて実施しました。全ての機能がiOS/Androidそれぞれのプロジェクトで開発されているところに、まずは「遊び・体験」機能だけをFlutterで追加開発しました。このように、Add-to-appという手法でFlutterのコードを既存システムに組み込めるので、万が一Flutterの導入がうまくいかなくても、Flutterのコードだけを取り除けばよく、元に戻すコストが低くて済むというメリットがあります。
次に、iOS/Androidそれぞれのプロジェクトを1つのFlutterプロジェクトに統合し、各OSのネイティブのソースコードとFlutterのソースコードを混在させます。
最終段階として、段階的なリプレイスによりFlutter実装の範囲を拡大していきます。
現在はそうした一連のプロセスの道半ばです。組織的には、既存のチームとFlutterチームがあり、改修規模が大きく工数面でメリットが必要な機能はFlutterチームでリプレイスと改修を行い、軽微な機能更新などは既存のチームで開発する方針を取っています。
── そもそも、『じゃらん』ほどの大規模なサービスがFlutterのような新たな技術を取り入れることに対して、上層部やビジネスサイドとの合意はスムーズに取れたのでしょうか？
砂川 確かに、「大丈夫なのか」という声も社内の一部ではありました。
ただ、リクルートの基本的なスタンスとして「開発側がベストだと考える方法に任せる」という社風があります。もちろん他部署や決裁者と会話を重ねながら合意形成をする必要はありますし、他の選択肢との違い、リスクとリターンを徹底的に検証した上で提案を持ち掛けます。
でも、そうして課題へのフィット感＝合理性を示しながら「これがベストな打ち手です」と説得すれば、たとえFlutterのような新しい技術でも柔軟に検討してもらえるんです。
併せて今回は、先ほどお話ししたような「段階的に進める」というやり方で導入時のリスクを低減できるという点が大きかったように思います。
開発期間のずらし、スコープの明確化…フルリプレイスのリスク回避術
── 『ホットペッパーグルメ』のリプレイスについても聞かせてください。こちらは『じゃらん』と違ってフルリプレイスだそうですが、このような大きな決断に至ったのはなぜでしょう？
朏島 『ホットペッパーグルメ』のアプリはリリースから10年以上たつ中で、大規模で複雑な仕様となっていました。当時は全体をカバーできるほど開発リソースが潤沢ではない部分もあり、少人数の限られた人しか触れないというような状況でした。結果的に、バグが頻発したり軽微な機能追加にも時間がかかったりしていました。
『ホットペッパーグルメ』のような大規模サービスであれば、通常は、フルリプレイスはリスクも大きく、効率的ではないので「避けるべき」という判断になるかと思います。『じゃらん』のように日々の業務を進めながら段階的に実施するのが常道かもしれません。
ただ、当時はさまざまな条件から、負債を細々と解消するのが難しい状況でした。一朝一夕に体制を強化することもできませんし、組織・技術両面の課題を解決するためにも「大ナタを振るう」必要があったので、社内で議論を重ねた末にフルリプレイスを決断しました。
── フルリプレイスはどのように進めたのですか？
朏島 フルリプレイスが決定した後にKMMの導入が決まり、そこからおよそ20カ月かけてアプリを0から作り直しました。開発はAndroidが先、次にiOSという順序で、時期は意図的にずらして行いました。
その理由としては、KMMとAndroidは相性が良いので、Androidを優先して開発することで、不具合があった場合にiOS版は別途技術要素の見直しができ、リスクを最小限に収められるというのが1つ。
もう1つは機会損失の回避です。『ホットペッパーグルメ』では通常、半年で数十件の新規案件に対応していますが、当然ながらリプレイス期間はそれらの実施に制限がかかります。ただ、開発期間をずらすと、片方のOSで仮説検証できるので、機会や売上などへの影響を回避できるわけです。
── その他、ビジネスに支障が出るのを防ぐために気を付けた点はありますか？
朏島 スコープを明確化して、リプレイス対象のボリュームを絞ることは心がけていましたね。リプレイスは、どうしても後からやりたいことがたくさん出てきて、工数や工期が間延びしがちです。今回はフルリプレイスなのでなおさら。
そのため、事前にビジネスサイドと相談し「新しいものは作らない」「画面も現状から変更しない」などの基本方針を取り決めました。今回は、内部ロジックはきれいに直してデッドコードも削除するけれど、外部挙動は変えない、というスタンスを貫きました。
それに、リプレイスに先駆けて、効果の少ない画面を調査・整理するという作業を進めていました。これもリプレイス対象のボリュームを減らすための工夫です。
── ビジネスサイドとのすり合わせはどのように行ったのでしょうか？
朏島 「そもそもアプリは必要なのか、ブラウザ版ではダメなのか」という根本的な議論から始めました。実際、ブラウザ版のユーザーも多いですし、先ほどお話ししたような組織課題もあったので、できる限りスコープを絞って開発を効率化させたいという思いもありました。
ただ、結果的に、機能追加や周辺サービスとの連携強化といった今後の事業戦略、またユーザーロイヤリティなどの観点から、やはりアプリは「必要」という結論にまとまりました。もちろんその際は、アプリを大きく改修するための工程や手法、先ほどもお話ししたようなフルリプレイスを実施する上でのリスクの回避策など、さまざまなトピックにわたって細かく意見をすり合わせました。
今回のリプレイスに関しては、そうやってビジネスサイドと綿密に連携しながら進めていますし、お互いに開発現場をフラットに見て「やるしかない」と合意できていました。向いている方向が同じだったからこそ、落としどころを探ることに注力できましたね。
リスクがあるなかでも新たな技術を取り入れる「メリット」
── ここまでリプレイスの経緯をご紹介いただきましたが、結果的に、それぞれどのような効果が得られましたか？
砂川 まだ道半ばではありますが、Flutterの段階的な導入でも、機能開発の生産性を向上させられたことは大きいですね。
また組織的には、若手を積極的にFlutterエンジニアとしてプロジェクトに参画させ、成長の機会を提供できました。プロジェクトで得られた知見を登壇などで頻繁に発信し、私たちの取り組みを周知できたのもよかったです。情報をまとめる作業自体が自身の仕事内容の整理にもなりますし、人に伝えるという普遍的なビジネススキルの獲得にもつながっています。そうした積極的な発信活動が功を奏して、中途採用の応募者のなかにもFlutterエンジニアの方が増えてきています。
朏島 『ホットペッパーグルメ』も、アプリのコードの整理が進み案件を回しやすくなりました。まだまだ改善の余地はあると思いますが、並立して実施できる案件数の増加や開発工数の削減など、おおむね狙った効果は出ているように思います。
その他、組織的には、オーナーシップを持ちやすくなり、サービス改善のため主体的にプロジェクトへ関われる流れも出てきました。他チームとの連携も積極的に進んでおり、例えば、最近始動したアプリ版の検索機能を改善するプロジェクトでは、企画やデータサイエンティストとプロジェクトチームを編成しています。こうした動きは以前はあまり見られませんでしたね。おかげで部署間のシナジーも生まれ、企画サイドからの提案を具現化しやすくなったり、他部署発のプロジェクトに良い意味で「巻き込まれ」やすくなったり、相乗効果でサービスを磨いていけている実感があります。
ただ、KMMはまだ進化途上の技術要素ですので、今後アップデートが増えることも予想され、我々もKMMの扱い方を日々模索しています。そうした試行錯誤を積み重ねながら、より良いシステム構成やチーム編成に進化させたいです。
── なるほど。組織・技術の両面から大きな成果が得られているわけですね。では、少し論点を変えて、2つのリプレイスの「違い」と「共通点」を、お二人はどう整理していますか？
砂川 フルリプレイスか段階的なリプレイスかという「手法の違い」、FlutterかKMMかという「採用した技術要素の違い」はありますが、案外共通点が多いかもしれませんね。
── 確かに。共通点の一つとして、例えばどちらも開発現場の声がプロジェクトに大きな影響を与えていますよね。
朏島 そうですね。どちらも現場の課題感がリプレイスのきっかけとなっています。
砂川 確かに、『じゃらん』側も開発の非効率という現場の課題があり、現場のメンバーが中心となって技術選定からリプレイスプロジェクトの進行までを推進しました。
役職にかかわらず、やりたいことがあれば自ら手を挙げて起案できる。今回のようなチャレンジングな案件にも関われるところにリクルートの組織文化が現れていると思います。
── その他、今回のリプレイスプロジェクトからどのようなリクルートの企業文化が読み取れると思いますか？
朏島 リスクとリターンを天秤にかけ、数字をもとに判断する。そうやってある種、合理的に意思決定するのはリクルートならではかもしれません。今回の技術選定においても、KMMでなくKotlinやSwiftでビジネスロジックまで書くといった選択肢もありましたが、リスクを取ってでも新しい技術を導入することで得られるメリットが大きいという会社の判断がありました。「合理性を重んじる」ことを「リスクを減らす」というニュアンスで捉えられることもありますが、私たちはそうは考えてはいません。
実際、ある程度リスクはあってもそれを適切に見積もり、開示できれば許容される文化がリクルートにはあります。そこは、私たち技術者にとって「プロジェクトの進めやすさ」だけでなく、新たな技術を採用したり、未経験の領域に飛び込んだりする際の「負荷の低さ」を感じます。
それに、明確な理由やロジックを前提にするからこその安心感があります。目標や要件がはっきりしていて、流行りの技術やツールを「なんとなく」導入したり、ゴールを設けずプロジェクトを進めたりということが少ないので、目指すビジョンに齟齬なく到達できます。
── とはいえ、実際は想定通りに進まないプロジェクトもあると思いますが……。
朏島 実は今回のプロジェクトも決して順風満帆とは言えなかったんです。コロナ禍で事業展望が変わったり、開発も想定通りに進まなかったり。でも、その都度、皆で対応しながらなんとか着地させられましたし、作業内容についても常に改善の意識を持って対応できました。そして、そうやってプロジェクト全体を通じて得られた「学び」と主体的な働きかけこそ社内では重視されていたように思います。ロジックと併せて、サービス成長にかける熱量やチャレンジに対する貪欲さを重んじるリクルートの文化を改めて実感しました。
── ありがとうございます。新規プロジェクトを合理性と熱量の両輪で推進していく、リクルートのエンジニアの姿が思い浮かびました。では最後に、今回のリプレイスプロジェクトを通して見えてきた課題と今後の展望を教えてください。
朏島 組織的な話で言えば、「開発体制のブラッシュアップ」です。既存のチームにKMMチームが加わって体制が大きくなり、確かに開発効率は向上しました。一方、チーム間のコミュニケーションフローは整理しきれていない面もあるので、まだまだ効率化の余地はあると思っています。
砂川 『じゃらん』の方では旅行体験を向上させるべく、さまざまな機能追加を予定しています。たとえ機能が増えてもユーザーに対してより速く、より充実した価値を提供できるように、Flutter導入による開発効率化を見越して、開発チームの体制を強化していきます。
そして、先ほどもお伝えしましたが『じゃらん』のリプレイスプロジェクトは道半ばですので、Flutterを導入して良かったのかどうかの検証はこれからです。今後の更なる施策はそれを踏まえて、検討したいですね。
リクルートのテックに関するブログ記事はこちら
株式会社リクルートではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフト券が当たる！ リクルートに関するアンケート 📝
※アンケートは終了しました。ご協力、ありがとうございました。
Amazon.co.jp は、本キャンペーンのスポンサーではありません（株式会社はてなのキャンペーンです）。
関連記事
リクルートの他部署に関連したSponsoredContent、および旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・構成：森嶋良子
撮影：関口佳代
