2005年の開設以来、月間約1億人が利用する日本最大級のレストラン検索・予約サイト『食べログ』。独自のコンテンツや投稿された口コミ・写真をもとに、あらゆるジャンルの人気レストラン、目的や予算にぴったりのお店を見つけることができることから、長年多くのユーザーに親しまれてきた。

特に2008年にリリースした『食べログアプリ』は累計ダウンロード数が1000万件を超えるなど、サービスの人気を支え続けている。

世の中では新たなWebサービスやアプリが立ち上がっては消えていく中で、なぜ食べログはNo.1アプリの座を維持し続けられているのか。

同アプリの開発部で基盤チームリーダーを務める太田定志さんに話を聞くと、ユーザーが欲しい情報を届ける「速さ」と、それを実現するためにアプリ開発チームが「週1リリース」を可能に
する体制の工夫が見えてきた。

株式会社カカクコム 食べログシステム本部 アプリ開発部 基盤チーム チームリーダー　太田定志さん

2018年8月にカカクコムに入社し、Androidアプリ開発を担当。Androidアプリの設計刷新、Kotlin化を進めながら、テストや自動化などに従事。現在はリーダーとしてチームビルディングや業務効率化施策を行う

「価値ある飲食店情報」をスピーディーに届ける『食べログ』

特に「速さ」だけにこだわっているわけではないのですが、あえて言うなら「ユーザーに価値ある情報を速く伝えられる」ように、開発を進めています。

例えば、今だとコロナ禍の影響によってお店の営業時間が変更になったり、コロナ対策をどのように行っているかだったり、飲食店の状況が日々変わっていますよね。それらの最新情報をいち早く、分かりやすい形で表示できるようにすることで、ユーザーにも店舗側にも役に立つアプリになるのではと考えています。

他にも、例えばアプリでお店を検索したときに、検索がうまくいかずに何もヒットしないと、ユーザーにとってはがっかりする体験になってしまいますよね。かといって、検索には引っかかるけれどロードに時間がかかっても、ストレスになってしまう。

そこで食べログアプリでは、「ユーザーが欲しい情報を、いかに速く適切に表示してあげられるか」の取り組みには、かなり力を入れています。

開発を開始してからリリースされるまで、いわゆるリードタイムを短くすることで、常に細かな機能をアップデートできるようにしています。

リードタイムが短いほど、企画側が考えた機能追加だったり、先ほどお話した最新情報の掲出だったりをすぐにユーザーに届けることができますから。また、ABテストなどの施策の効果検証についても素早く回せるため、検証から結果反映が早くなるという点もメリットになります。

もともとアプリチームでは2週間に1回の頻度でリリースをしていたのですが、2年前からはリリースを1週間に1度のペースに縮めました。その結果、改善ペースが早まり、より一層ユーザーに情報を届けるスピードも上がりましたね。

そうですね。週1のサイクルでリリースを行っているサービスは、そこまで多くはないと思います。

特にスマホアプリのリリースは、AppleやGoogle側の審査の待ち時間もありますし、一度リリースしてしまうとしばらくは修正ができないため、しっかり検証作業を行なわなければならず、スピードを出しづらいんです。また、リリースや検証作業にばかり集中していると、肝心の開発作業が遅れてしまう懸念もありますしね。

でも、『食べログ』チームでは「今の時代、情報発信や機能の改修はなるべく速い方がいい」という共通認識があります。そのため「できるだけマイクロリリースを行なうことで、検証作業の負荷を下げる」こと、そして「徹底した業務効率化を行なう」ことで、この週1リリース体制に切り替えました。

「ECRS」のフレームワークで、業務スピードを半分に短縮

2週間に1回のペースだったものを週1に変えるとなると、単純に1週間あたりの開発チームの作業量が倍になってしまいます。それをまず改善するために、業務効率化のフレームワーク「ECRS」に則って、チームの業務を一から見直していきました。

『食べログ』アプリは歴史が長い分、改めて内容を見直してみると「これはなくてもいいのでは？」「省略したり、まとめたりできるのでは？」というものがいくつもあったんです。それらを可視化して、整理をしていきました。

例えば、以前は機能をリリースした後の2〜3日は、アプリが強制終了してしまう「クラッシュ」が起きないかどうかをウォッチしていて、問題ないことを確認できたら全体に配信するという工程がありました。

クラッシュの有無は、数年前であれば必須のチェック項目でしたが、最近ではシステムが向上したこともあり滅多に起きない事象なんです。ですから「2〜3日見なくても、次の日に問題なければすぐ全体に配信しても大丈夫だろう」と。それだけで1〜2日分の時間が節約されるわけです。

その他にも、10分しかかからないような細かい作業も一つ一つチェックして、「これはいる／いらない」「自動化できる／できない」を精査していきました。

その結果、開発チーム全体の作業時間をほぼ半分に効率化することに成功したんです。以前は7日間かかっていた作業が、3～4日ほどでできるようになりました。

毎週決まった曜日（iOS:木曜、Android:金曜）にソースコードの修正を締め切って、リリース前の検証を行います。
そして翌週の月曜には段階的リリースを行い、最低限クラッシュなどがないことを確認したら翌日の火曜日には全体公開を行っているんです。

そのような決まったサイクルでリリース作業は行い、プロダクトの改善は、その他の修正のタイミングと合わせてリリースをするようにしています。

毎週リリースタイミングがあるので、無理にスケジュールに当てはめる必要もない。コストの低い改修はすぐ反映できるような形になっているため、無駄なく開発が進められるようになったと思います。

リーダーとしては「改善のアイデアをいかに効率よく出せるか」を重視していましたね。

今回こうして週1リリース体制をつくるにあたって、業務効率改善のためのチームを組んだのですが、そのメンバーは自主的に手を挙げてくれた人のみを選びました。やる気のあるメンバーで進めると、改善のアイデアも出やすくなりますし、実際の行動にも移しやすいですからね。

また、これは業務改善のためにやっていることなので、開発メンバーの時間を取り過ぎては本末転倒です。なので定例会議を最低限にしたり、もしも忙しくて作業できないメンバーがいたら皆でフォローし合ったりしながら、進められるように意識していました。

「品質とスピード」は本来両立できるもの

そもそも本当にその「速さ」に価値があるのか、機能の本質を考えることではないでしょうか。単純にスピードを上げるだけではなく、価値ある速さを考えることが大事なのだと思います。

『食べログ』アプリの改善も「リリースのスピードを早めたい」ではなく、「ユーザーにいち早く価値ある情報を届けたい」ところからスタートしていますから。

また、一般的にスピードと品質って対比されがちですが、これらは本来両立できるものだと思っています。どちらかを犠牲にするのではなく両方と向き合って、品質を高めスピードアップする方法を、開発者側は考える必要がありますよね。

初めに「何に対して効果を出したいか」と目標を設定して優先順位を付けていくことが大事だと思います。

私たちの場合は「リリース頻度を1週間早くする」という明確な目標値がありましたから、すべての作業をそれ基準に考えられました。そのため、やるべきこと、やらなくていいことの判断もしやすかったように思います。

ただ、プロダクトにおける優先順位付けってかなり難しくて、一概に「これがベスト」だとは言い切れないものですよね。開発チームの事情もあれば、企画チームの意向もあるし、経営側からのオーダーもあるはずです。

そのためにも、プロダクトとして価値検証やユーザーインタビューなどを実施して、チーム全体で「ユーザーが求めるものは何なのか」という視点をすり合わせておくことも必要。

食べログチームでは、そういった「そもそもの共通認識」が揃っていることが良かったのではと思います。プロダクトチームは、全員がユーザーの方向を向いているべきですから。

取材・文／キャベトンコ　編集／大室倫子