なぜ食べログはフロントエンドのリプレースを進めているか。- 大きな改善を行うときに大事なこと-
食べログが大規模サービスとして成長していくなかで、どのように技術的・組織的課題と向き合ってきたのか。裏側エピソードを大公開。2021年4月15日に開催されたエンジニアHubウェビナー「食べログエンジニアに聞く！大規模サービスの裏側エピソードを限定公開」より、全文書き起こしレポートをお届けします。
※2021年4月15日に開催されたエンジニアHubウェビナー「食べログエンジニアに聞く！大規模サービスの裏側エピソードを限定公開」より、全文書き起こしレポートをお届けします。
食べログフロントエンドのチームの辻と申します。
前職では、フロントエンドとサーバーサイドの両方を行なっていましたが、フロントエンド領域により深く関わっていきたいと考え、食べログの開発者として2018年にカカクコムに転職しました。
食べログでは、フロントまわりの機能開発に加えて、リファクタリングや自動化の環境改善、コーディング規約の整備などを行なっています。2019年からはリーダーになり、採用やチームビルディングにも取り組んでいます。
今回は2020年から開始しているReact/TypeScriptへのリプレースプロジェクトについてお話しをさせていただきます。
株式会社カカクコム 食べログシステム本部 辻 祐子
2018年にカカクコムに入社。2019年にフロントエンドチームリーダーになり、フロントエンド開発や環境改善業務を行いながら、チームビルディングや採用にも携わる。現在は食べログフロントエンドをReact/TypeScriptへリプレースするプロジェクトに従事。チームブログの運営にも携わっている。
現在、多くの画面はjQueryやBackbone.jsで実装されていますが、これらをReact/TypeScriptでリプレースしています。
より詳しい戦略や使用技術、プロジェクトの詳細などは、ブログにも書いていますので、ぜひ御覧ください。
【食べログ フロントエンドエンジニアブログ】
https://note.com/tabelog_frontend
PC、ガラケーを経て、スマホ中心の時代へ。大規模サービスの技術的負債
本日は、そもそもなぜリプレースが必要なのか、また大きな改善に取り掛かるにあたり、どのようなことに気をつけていくべきかなど、より根本的な話しができればと思います。
まずは、リプレースに至った経緯からお話します。
食べログは、2005年から始まった歴史あるサービスです。システムも組織も巨大、かつ複雑な機能が多くあります。
フロントエンドは場当たり的な実装も多く、技術的負債がボトルネックになることもあり、品質、工数、納期、全てにおいて問題を抱えていました。
リプレースプロジェクト開始前から機能をモジュールに切り出したり、ライブラリのバージョンアップをしたり、地道なリファクタリングは常に継続してきたのですが、その速度よりもずっと早く、世間のフロントエンドのデファクトが変わっていき、差が開いていきました。
このまま差が開き続けると、バージョンアップできなくなったり、ユーザーが求める時代に合ったUIを作れなかったり、パフォーマンスやSEO要件が満たせず検索順位が下がってしまうリスクがありました。
また、フロントに対してモチベーションが高い人が「最新技術に触れないなら…」と辞めてしまい、そのせいで品質を保てなくなるといった悪循環が起きかねません。フロントエンドの課題を放置しておくと、いずれサービスや組織全体が深刻な状況に陥っていくと考えました。
この状況をどうにか解決したいと思い、リプレースを進めています。
このような経緯から、以下の3点をプロジェクトの理想のゴールとしています。
（1）改修時や機能追加時に、迅速にリリースができるアプリケーションにしたい
（2）大人数で運用しても壊れにくいアプリケーションにしたい
（3）継続的に、世間の標準的なフロントエンド技術に追従できるつくりにしたい
すでに世間との差が開いてきているところもありますので、速やかにこの理想の状態に近づけていく必要があります。
理想のゴールをインセプションデッキとして明文化。
次に、この大きな改善に取り掛かるにあたり、気をつけたことや取り組んだことについてお話しをします。
先ほどお話したように、フロントエンドとして理想のゴールは設定したのですが、まだこれでは不十分です。リプレースの影響は、食べログシステム全体に及ぶため、食べログ全体としての具体的な理想像を明確にしておく必要があります。
また、食べログは大規模システムなので、リプレースプロジェクトは長期で、コストも大きなものになります。そのため、これだけのコストをかけて改善し、フロントエンドとしての理想的な状態が達成されたときに、食べログ全体にどういう影響があるのかをインセプションデッキとして一枚のドキュメントにまとめました。
インセプションデッキとは、プロジェクトの目的や背景、マイルストーンなどの全体像を端的に伝えるためのドキュメントになりますが、今回はプロジェクトのゴールおよび達成で得られる各ステークホルダーのメリットも記載しました。
フロントエンドエンジニアにとって、デザイナーにとって、企画にとって、プロダクト開発エンジニアにとって、何が嬉しいことなのか。そして一番大切なエンドユーザーにとって、どんなベネフィットがあるのかなど明確にし、インセプションデッキにまとめることで、「何のためにやるのか」という一番大事な部分の共通認識をメンバー間ですり合わせることができました。
どのようなメリットがあるかが分かりやすく伝われば、他のチームや各ステークホルダーの協力も得やすくなります。アーキテクチャや技術選定の指針にもなりますし、どのコンテンツから着手するかなど優先順位もつけやすくなります。
使用技術は、実現したいゴールとマッチするものを。
リプレースプロジェクト全体を通し、このインセプションデッキを軸に進めています。使用技術も、実現したいゴールとマッチするものを選定しています。
たとえば、インセプションデッキで定めた「壊れにくい／迅速にリリースができる／世間のデファクトに追従しやすいアプリケーションにする」というゴールに最適なものはなにか？ということ。この観点から、静的型言語であるTypeScriptや、TypeScriptと親和性が高いReactなどを採用しました。
システムのリプレースは「新しい技術を試してみたい」、「人気の技術を導入してみたい」ということがモチベーションになり、始めることがあるかもしれませんが、「使用技術は実現したいゴールとマッチするものを選定する」ということが大切だと思います。
長期的なプロジェクトにおいては尚更だと感じています。
そのためにも、各ステークスフォルダーと解決したい課題が何なのか、インセプションデッキ等を利用して、認識をすり合わせておくことがスムーズな改善につながると考えています。
まだリプレースは始まったばかりですが、すでにインセプションデッキで示したゴールに近づいていることを日々実感しています。
サーバーサイドとフロントエンドが疎結合になったため、バグや影響範囲の調査がしやすくなり、納期の短縮に繋がりました。また型チェックやカバレッジの高いUnit test、snapshot testを導入したおかげで、品質も安定性も向上。それらのおかげでリファクタリングやライブラリのバージョンアップも安全に素早くできるようになり、世間の標準的な技術スタックにも追従しやすい状態になりました。
さらに、リプレースの取り組みをフロントエンドチームのブログ記事で積極的に発信しているのですが、それを見て弊社に興味を持ち、応募してくださる方が増えていて、採用やチームメンバーのモチベーション向上にも効果を感じています。
最後にまとめさせていただくと、大きな改善をする時には、なぜやるのか、どんな課題を解決したいのか、どういう状態がゴールなのかをとにかく明確にしていくことが大切だと考えます。また、技術選定やアーキテクチャ設定設計をする際も、それらのゴールからブレないようにしておくこと。そして、決めたゴールは進めながら、何度も見返すことが必要だと思います。
Q&Aコーナー
※こちらと併せてぜひご覧ください
【1】食べログのエンジニアが、コロナ禍で向き合った課題。
【2】食べログに見る、成長し続けるサービスの「業務的負債」との向き合い方
【3】なぜ食べログはフロントエンドのリプレースを進めているか。
Q：相違をなくすためのコミュニケーションツールは？
A：関戸さん
Teams／Confluence／概念図。概念図はパワポで作成し、Confluenceへ貼り付けています。
Q：カカクコムでも1年前から在宅勤務をしているとのことですが、リプレースではコミュニケーションがより早く濃くできることが重要なのではと考えています。コミュニケーションの部分を在宅勤務でも円滑にする工夫はされていらっしゃいますか。
A：辻さん
おっしゃる通り、1年前から在宅勤務になっていています。コミュニケーションは不安もありましたが、やってみたら意外と問題なくできている、というのが素直な感想です。
オフィス出社時は朝会だけでしたが、在宅勤務になってからは夕会も実施するようにして、コミュニケーションするタイミングを増やしました。
また朝会や夕会の後に雑談タイムもつくっています。作業に集中したい人は抜けてもOKですし、ちょっと雑談したい人はその場に残り、音声チャットをつないだまま話をします。「ちょっと音声チャットいいですか」と声をかけるほどではないけど、聞いたほうが早いような細かい質問も出てきて、チーム内ですごく好評です。そこから「これは、みんなで話した方がいいね」といったことが抽出されることもあります。
Q：即対応が必要で概念図を作成したとのことでしたが、他にも共通認識を持つために気を付けているポイントは何ですか。
A：関戸さん
もちろん、資料とか設計書は重要なので作りますが、個人的には「最終的にはどうコードに現れるか」だと思います。コードが概念図の通りになっているか、気になってすごくチェックしていました。ですので、概念図もコードと一緒に管理できるような仕組みが検討できればいいのかなと考えています。
Q：フロントエンドとバックの繋ぎについて、何か工夫されていることはありますか。
A：辻さん
すごくあります。 OpenAPIのスキーマからAPIクライアントを自動生成していたり、MSWの利用時にOpenAPIのスキーマを参照して自動でモックしたりなど。プリズムの利用によるスタブサーバーの自動化などを行っています。工夫したところとしては、railsとのリクエストパラメータ情報の受け渡しです。リプレース序盤であり、まだReactは部分導入なので、ルーティングは現在もrailsで管理しています。ルーティングをフロントエンドで管理していないので、リクエストパラメータはフロントエンド（React側）からは参照できません。HTMLの中にjsonとしてパラメータ情報を埋め込んでもらい、リプレースが進んでReactでルーティングを管理するようになってもAPI設計に変更がないようにしています。
Q：新しい技術を選定する＝学習コストがかかる、だと思うのですが、フロントエンドチームで行っているフォローや学習の取り組みに関して教えてください。
A：辻さん
Reactについてはもともとできるメンバーがいたので、その方に聞いたことと、みんなで最低限の知識を揃えるために課題図書などを読みました。あとは公式ドキュメントの読書会を行ったりしました。加えて、モブプロやペアプロを行っていているので、最近入社した方もその場で質問ができて、学習のタイミングにもなっているのかなと思います。
