Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

長期関与で学ぶ知見：Rettyの実例から見るシステム改善の軌跡

マイクロサービス システム設計 アジャイル開発

Retty VPoE(VP of Engineering : 技術部門のマネジメント責任者)の常松です。

2025年2月27日に開催されるEMConf JP 2025向けに本記事と同じタイトルのプロポーザルを出していましたが、強豪ひしめく選考で負けてしまったようです。本記事に話したかったことをまとめて供養します🙏

fortee.jp

はじめに

転職が一般的になりつつある今の時代ですが、「1つのサービスに長年携わることでこそ、システム設計における深い学びが得られる」という意見も増えています。 私が飲食予約サービス「Retty」に関わって6年、その間にEMおよびVPoEとして大小さまざまな課題と向き合い、改善を重ねてきました。

本記事では以下のカテゴリ別に、具体的な事例を通して各局面でどのような判断や実装を行い、何を学んだか。そして今どのようにその経験を振り返っているかを共有します。

  1. スクラムと大規模スクラム（LeSS）の導入：アジャイルを拡張して適用する中での成功と失敗
  2. マイクロサービスアーキテクチャへの移行：モノリスからの脱却と、その後のシステムの柔軟性向上
  3. ライブラリやフレームワークの選定プロセス：技術選択の重要性とチームへの影響
  4. マネージドサービスへの置き換え：効率化とスケーラビリティを実現するための決断

1. スクラムと大規模スクラム（LeSS）の導入

Rettyの開発はスクラムで行っており、複数チームで協働するためのスケーリングフレームワークとして大規模スクラム(LeSS)を採用しています。 LeSSの導入は2019年の10月で、LeSSの実践事例としてもかなりの古株かと思います。

自律し価値を単独でデリバリーできる開発チームが存在することで、デリバリーに関する悩み(デリバリーまでの時間が読めない、開発関連の細かな調整ごとなど)が大きく減ったことが一番の成果だと思います。 5年もLeSSを続けていると「今でもRettyのLeSSは進化している」と感じることは少なくなりましたし、「LeSS以外の開発スタイルが良いのではないか」という話が挙がったこともあります。いっときLeSSを中断したこともありましたが、開発知識が特定チームに閉じたり、リリース関連の調整ごとで揉めたりといった問題が発生して、結局は元に戻しています。

良いことばかりでもありません。開発チームはどのシステム・サービスに携わることがあるため、設計・実装方針がぶれたり、サービスに対してのオーナー意識が希薄になったりしやすいです。もう少し開発人員・開発チームが増えると事業領域を分けて、各チーム・エンジニアが責任を持って見る範囲を絞ることもできると思うのですができていません。「認知負荷が高い」は定期的に寄せられる困り事です。

またLeSSは全体(=全社)で1つのスクラムを行う形のフレームワークです。注力対象が1つの時は強い一体感と素早くPDCAが回る開発サイクルを実感することができます。しかし取り組みたいことが複数あると順番待ちが発生したり、プロダクトや機能の完成度が高まりきらないまま次の開発に進まざるをえないこともあります。運用上の難しさも感じています。

最近ではRettyを卒業したメンバーが、新しい職場でスクラム/LeSSを主導するケースも聞きます。 良い取り組みは広げてもらい、新たに学んだ知見はコミュニティに還元してもらい、自分たちももっとうまくやっていけるようにありたいです。

2. マイクロサービスアーキテクチャへの移行

Rettyはサービス開始から13年が経ち、創業の頃から使っているモノリスのシステムは開発も運用も厳しい状態です。 そこでマイクロサービスへの移行を決め、2018年ごろから開発を継続しています。

いつ移行が終わるのかわからない不安な時期もありましたが、移行は着実に進んでいます。 新規に開発する機能やシステムをマイクロサービスで開発するのはもちろんのこと、既存システムのリプレースも少しずつ進んでいます。 Rettyのシステムでアクセスが多く重要な機能が大きく2つあるのですが、1つ目の山は通過できて、もう一つの一番の大きな山も今ちょうど乗り越えようとしているあたりに来ています。

マイクロサービスは移行を決定した2018年ごろに流行っていたアーキテクチャパターンで、最近ではモジュラモノリス(1つのマイクロサービスに相当する単位を単一プロセス内のモジュールとして構成)を採用する事例を多く聞きます。 当時のRettyが抱えていた課題は「正しい仕様(挙動)が不明瞭で、開発・不具合対応に時間を要する」というものでした。 gRPCとGraphQLを採用したことで厳密な型定義に基づいた開発が可能になり、gRPCインターフェースを定義する際は責務の議論も十分に行われています。 導入時の目的は今でも達成できていると感じています。

一方で移行作業はもっと貪欲に進めた方が良かったという反省もあります。 当初は既存システムのリプレースとして捉え、施策開発の合間に仕様を保ったまま少しずつ進めるようなやり方をしていました。しかし、これではスピードが全然出ません。 今は事業上の最重要課題に合わせ、関連箇所をマイクロサービスに積極的に置き換えていくやり方をとっています。開発生産性の観点からも、事業スピードを上げていく観点からも、この方が望ましいと考えてのことです。 当たり前ではありますが、施策を入れたい箇所が事業上重要な箇所であり、そうでない箇所をどれだけマイクロサービス化したところで事業貢献にはつながりません。

またマイクロサービスの責務をエンジニアが議論し、分割したり統廃合する意思決定は非常に難しいと感じています。 責務を細かく分けるとサービス間でデータを受け渡しする処理ばかりの開発になりますし、たくさんあるサービスの運用工数も増えてしまいます。 一方で責務をまとめると開発は楽になるかもしれませんが、小さなモノリスのように育ってしまい、責務の議論が不十分でもサービス開発が進んでしまいます。 マイクロサービスの当初はエンジニア観点でシステムの責務を整理し、画像の並び順や選定に責務を持つ「画像サービス」があったことがありました。 ただしその後の議論で「飲食店情報の一つとして画像とその並び順がある」「ユーザーからの口コミ投稿に紐づく画像データがある」と認識を改め、画像という切り口で責務を持たせるのをやめました。当たり前のことではありますが、下記を心がけるべきだと考えます。

  • 責務の洗い出しはデータやエンジニア観点ではなく、業務の流れやユーザー体験をベースに考えるべき。
  • 将来起きることを仮定しすぎて責務を細かく分けすぎない。必要になってから考えた方が良い。

3. ライブラリやフレームワークの選定プロセス

マイクロサービス化に合わせて開発言語やフレームワーク・ライブラリも選定し直しています。

フロントエンドはNuxt.js、バックエンドはGo言語を主体とし、一部サービスはKotlinが使われています。 6年も経つと当時の最新が現在の負債になることは当たり前に発生し、開発が活発でなくなったり世の中の趨勢が変わっていることも少なくありません。 将来の流行を当てることは難しいので、最新のバージョンに追従していく努力を怠らず、いざとなったら差し替えられるような開発力を持っておくのが良さそうです。 フレームワークやライブラリは更新時に多大な苦しみをもたらすものがありますが、選定時に見抜くことは困難だと思います。

開発言語もフレームワークも選定は難しいです。エンジニアや開発チームに好きに選んでもらっても、開発組織として決めて統一しても、どちらのケースでも不満の声が届きます。

  • 好きに選んでもらう。統一しない → 「覚えることが増えて大変です」「頭の切り替えが必要なことが多くて、開発スピードが出ません」とか
  • 開発組織として決める。統一する → 「世の中の流行とあっていない」「向いてない言語・フレームワーク・ライブラリで実装する工数が大変」とか

下記が現実的な落とし所かと思います。

  • 複数人で触るシステムはXX言語/XXフレームワーク/XXライブラリを基本線で考えて欲しい
  • 理由がある限りは他の言語でも構わない
    • 既存コードが流用できる
    • 期日があり、別言語だと手早くできる
    • 既存システムが安定稼働しており、手を入れることがほとんどない

4. マネージドサービスへの置き換え

内製開発が必要な先進的だったシステムも、知見が世に広まり整理が進むことでサービス・ツールとして登場し、それらがマネージドサービスとして提供されるような流れがあると思います。 Rettyでも多くのシステムをマネージドサービスへ切り替えてきました。

  • ページキャッシュを扱っていたシステムをFastly CDNへ移行
  • データ基盤でデータを集計・加工する仕組みを内製のものからdbtへ移行

マネージドサービスであってもより管理が楽なものに移行したり、最初のサービス選定時からマネージドサービスに寄せる意識もしています。

運用工数まで鑑みてサービス・ツール選定をすることで、本質的な活動に費やす工数もうまく捻出できていると感じています。

おわりに

6年もの関わりとなると思い出すのも一苦労でした。

多くの成果は一緒に取り組んでくれた同僚のおかげであり、良い経験をたくさん積ませてもらうことができました。 システム改善の大きな山を越えた先に、来年は更なる改善がいくつも考えられ期待できるような状況です。

今後のRettyにもご期待ください。

※本記事はRetty Advent Calendar 2024の3日目の記事でした

adventar.org