️はじめに
みなさん、こんにちは。
食べログ開発本部 ウェブ開発1部 システム運用改善チームに所属している、スギマルくんと申します。
システム運用改善チームは、特定のページや機能の開発案件は行わず、食べログの一般ユーザーや、カスタマーサポートが触れるページや機能のシステムや運用面の改善を専門としているチームです。
本日は、システム運用改善チームにて実施した、食べログのデッドメソッドを削除したプロジェクトについてお話しします。
このTabelog Tech Blogの記事を通し、多くのエンジニアの方に、食べログのシステムの現状を知ってもらいつつ、技術的負債に立ち向かうメンバーがいることを知ってもらえれば嬉しいです。
食べログのシステムの現状
食べログは、サービス開始から約20年が経過しているサービスで、店舗の紹介ページ、口コミページ、ユーザーページ、予約ページなど、ページや機能も多岐にわたります。また、既にサービスとして多くの方に利用いただいていますが、更なるユーザー体験の向上を目指し、日々新しい改修が進んでいます。
しかし、ページや機能の追加や改修とともに、コード上に不要なメソッド、いわゆるデッドメソッドが大量に蓄積されていることも事実です。
️デッドメソッドがあることで起きる問題点
いくらデッドメソッドが存在しても、ユーザーの食べログの利用に影響はありませんが、前述の通り、食べログでは日々開発が続いています。
食べログに限らず、ウェブサービスの改修時に、サイトのソース全体をgrepして、改修範囲を明確にする作業は多くのエンジニアがしているかと想像します。しかし、使っていないメソッドが存在すると、grepで改修箇所と関係のないファイルが多くヒットしてしまい、調査に不要な工数がかかってしまいます。加えて、デッドメソッドが多いことで保守性が下がり、結果として障害発生のリスクも高まります。
また、サイト上で障害が発生した際、エンジニアは障害を最速で解消する責務を負っていますが、デッドメソッドがあると確認すべき箇所が増え、問題の特定に時間がかかってしまいかねません。
これらの問題を鑑みると、デッドメソッドを残さないに越したことはありません。しかしながら、「最速でリリースをしてユーザーに新しい価値を届けること」と、「新規の開発や改修の度に、デッドメソッドを開発者が消していくこと」の両立は簡単ではありません。デッドメソッド削除による影響調査や、メソッド削除後のテストには、どうしても時間がかかってしまいます。
また、開発をしたエンジニアが「リリースしたあとにデッドメソッドを消そう」と意気込んでいても、すぐに次の案件が始まってしまい、デッドメソッド削除の作業時間確保が難しくなるケースもあるかと思います。
️️デッドメソッド削除開始
「デッドメソッドが大量に残っている」
という状況に対処するため、システム運用改善チームでは2024年の6月から9月にかけて「デッドメソッド削除プロジェクト」を実施しました。
食べログには、一般ユーザーが利用するページと、そうではない管理系のページがありますが、このプロジェクトでは、一般ユーザーが利用する箇所に存在するすべてのデッドメソッドを削除対象としました。
削除にあたり、まず必要なのがデッドメソッドを特定する作業です。食べログには、食べログ上のソースを解析し、未実行のメソッドを特定する独自ツールがあります。今回はそちらを用いて、過去半年の間に実行されていないメソッドの洗い出しを行いました。
（未実行メソッド解析ツールの詳細はコチラに記載しております）
しかし、過去半年間使用されていないメソッドであっても、安易に削除はできません。ごく稀な特定条件下で通るメソッドもあるでしょうし、今後利用されることを前提に先出しで作られたメソッドが存在する可能性もあります。
そのため、王道ではありますが、デッドメソッド削除にあたり該当メソッドの呼び出しが存在しないかを確認すべく、ソースのgrepを地道に実施。そのうえで、本当に削除して問題がないと判断した合計1,134メソッドを「削除可能なメソッド」と判断し、実際のメソッド削除の作業に取り掛かることとなりました。
️️プロジェクトの工夫点
このプロジェクトでは、以下の２点に力を入れることで、効率的な遂行を心がけました。
①タスクとスケジュールの整理
日々、食べログでは最速のリリースを目指して開発が行われていますが、それはデッドメソッド削除も同様です。しかしながら、デッドメソッド削除の作業は単調で地道な面があり、メンバーによっては高いモチベーションを維持できず、作業効率が落ちてしまう可能性もあります。そこで、週1回のリリース曜日を固定するのに加え、チーム全体で具体的な数値目標を短いスパンで設定して「この日のリリースまでにX個のメソッドを消しきろう！」という意識を共有するようにしました。
また、本プロジェクトは5人のメンバーで実施しましたが、5人の食べログ歴や携わってきた案件は様々。そこで、店舗系のデッドメソッド削除はAさん中心、ユーザー系のデッドメソッドはBさん中心、など、各々の特性に合わせたタスクの割り振りを心がけました。
加えて、ミーティングの回数を増やし、会話の機会を無理矢理にでも設けることで
「この機能は私が詳しいので、私が担当します」
など、タスクの自発的な入れ替えができるような空気感の醸成も心がけました。
②他チームとの調整
大量のデッドメソッドを削除するうえで、明らかに削除して問題ないメソッドがある一方、
「確かにこのメソッドは不要に見えるが、本当に削除して良いのか？」
と頭を抱えてしまうようなメソッドも少なくありませんでした。
例えば頻繁に改修が行われる機能に関連するメソッドは、一時的に呼び出し元がないものの、今後コールされる可能性も大いにあります。また、このプロジェクトを通じて、すでにアクセスが全くないページや、使われていない機能の存在も明らかになりました。
それらを削除するうえで、他のエンジニアや企画職など、そのページや機能に明るい方への確認が必要になりますが、他チームの皆さんもお忙しいです。そこで今回のプロジェクトでは、できる限りコミュニケーションの時間を少なくすることを目指しました。
具体的には
「このメソッド使われてないですが消していいですか？」
「このページ、削除していいですか？」
といった形で丸投げはせず、
「このページは、2018年に動線が削除されており、アクセスログを確認したところ、アクセスは一切ないようなので、削除しても大丈夫でしょうか？」
といったように、削除して問題ないかの判断をしていただくために必要な情報を揃えたうえで、削除可能かどうかの確認をするようにしました。
なお、食べログの企画職の皆さんはシステムへの理解や知識も深く、デッドメソッド削除の意義も十分に理解いただいており、やりとりもスムーズにさせていただくことができました。
️️プロジェクトの結果と振り返り
このプロジェクトの結果として、4ヶ月間で1,134メソッド、行数にして9,775行を削除することができました。
デッドメソッドを削除したからといって、食べログの機能そのものに変化があるわけではありません。しかしながら、長い目で見れば、今後のスムーズな開発や障害対応に対し、効果があるのは間違いないでしょう。
また、システムのスリム化により、モジュラモノリス化などの大きなシステム改修に向けての下地を作ることもできました。
デッドメソッド削除はgrepとテストを繰り返す地道な作業でしたが、プロジェクトを通し、どうやったらより早く、安全にプロジェクトを遂行できるかを真剣に考え、向上心を持って取り組むことができたと思っています。また、このプロジェクトを実施するうえで、他チームのエンジニアの方から、何度も「デッドメソッドの削除をしていただき、大変助かります！」と声をかけていただきました。このようなやりとりを通し、デッドメソッド削除は多くの方が求めていた作業だったんだなと再認識するとともに、大きなやりがいを感じることができました。
加えて余談になってしまいますが、デッドメソッド削除の最中に、10年以上前に食べログ上で使われていた機能や、LP（ランディングページ）も目にしました。私が食べログにジョインしたのは約3年前ですが、この作業を通し、食べログの歴史を感じることができ、その点も楽しいポイントだったなと思います。
この記事を読んで食べログのシステム改善に興味を持っていただけましたら、ぜひ下記の採用情報ページをご覧ください。
