アイキャッチ

出前館の新・レコメンド機能で加速するユーザー体験。確実に「速さ」を伸ばすMVP開発の裏側

スキル

No.1プロダクトに“スピード戦略”あり!

「速い」をつくる技術

No.1のプロダクトには、必ずユーザー体験の「速さ」を向上させるためのこだわりと戦略がある。サービスのどこを速くするか、どのような技術でその速さを実現するか。各社のプロダクトの成長を支える「速さ」をかなえるテクノロジーと開発体制とは?全5プロダクトの「速い」をつくる技術を公開!

昨年(2020年)は、コロナ禍の影響でフードデリバリーの市場が一気に拡大。すでに日本上陸していた『Uber Eats』の他にも、『Wolt』や『foodpand』など海外勢の参入が目立った。

その一方で、日本生まれの元祖フードデリバリーサービス『出前館』も目覚ましい成長を遂げている。

『出前館』は2000年に出前仲介サイトとしてサービスを開始し、およそ20年間で築いた加盟店との信頼関係を強みに、国内最大級の加盟店舗数を誇る。さらにその数はコロナが加速した2020年3月から約1年で3倍も増加し、今や加盟店の数は9万5000店を超えるという。

さらに調査会社ショッパーズアイによるデリバリーサービスのインターネット調査(2020年9月)では、「信頼できる」「配達員の質」「お得に利用できる」の3部門でランキング1位を獲得。サービスの質にも定評がある。

そんな出前館が、このフードデリバリー戦国時代にさらなる成長を目指すべく、ユーザー体験の「速さ」を後押しするための施策をリリースした。コロナ禍で見えた「新しい出前のかたち」と、それを後押しする技術とは?

プロフィール画像

コマース企画部 コマース企画G グループマネージャー
原山 裕喜さん

2020年新卒でLINEに入社。出前館に出向して飲食店向けサイトの立ち上げの企画を担当。21年に出前館に転籍し、出前館注文サイト・アプリの改善企画を担当。主な担当案件はレコメンド機能、決済手段追加、他社サービス連携、カート・注文手続き・注文完了画面のリプレイスなど

プロフィール画像

プロダクト開発部 コマース開発グループ所属
奥村 雄太さん

SIer、ITコンサルを経て2019年4月にLINEへ入社。入社後は、『SHOPPING GO』、『LINE デリマ』のフロントエンド/サーバサイドの開発に関わる。21年から出前館のフロントエンド開発を担当。現在は主に出前館のフロントエンドのリプレイスを進めている

コロナ禍で拡大した新たなニーズに応えるレコメンド機能

――コロナ禍をきっかけに、フードデリバリーサービスの競争が激化しています。出前館ではどんな取り組みを?

原山:この1年でいくつか新機能をリリースしていますが、その中で効果を発揮している機能の一つが「レコメンド機能」です。

背景の一つは加盟店の増加です。飲食店のデリバリー参入が急増したことで、出前館の加盟店は2020年7月の約3万店舗から、2021年10月には9万5000店舗と約3倍になりました。

お店や料理の選択肢が増えるのは多くのユーザーにとって喜ばしい一方で、「多過ぎて選べない」「注文に時間が掛かってしまう」人も出てきます。

そこで、たくさんの店舗の中から料理を選ぶ楽しさは維持しつつも、早く注文する品を選びたいユーザーの期待にも応えるべく、トップページに「あなたへのオススメ」の項目を追加。

ユーザーの居場所や属性にあわせて店舗がレコメンドされるため、サッと料理を選びたい人に役立ちます。

出前館

あなたへのオススメ

――フードデリバリーサービスというと「食べたいものをじっくり選ぶ」ユーザーが多いように思っていましたが、「速く選ぶ」需要もあるのですね。

原山:コロナ禍でフードデリバリーが身近になったことで、ニーズの多様性も広がったように感じていますね。

新しいお店や、よりおいしそうな食事をじっくり探したい人もいれば、平日の昼休みにオフィスで食べるランチを探す人も増えました。後者の場合、お昼休みの時間が限られていますから、パッと選べて、早く届くことが重要です。

私たち出前館は「デリバリーの日常化」を目指していて、あらゆるシーンで使いやすいサービスであることを追求しています。じっくり選びたいとき、速さを優先したいとき、どちらにも対応できるサービスになるために、今回はパーソナライズ表示によるレコメンド機能を実装することにしました。

ユーザーが求めるものを最短距離で目指す「MVP開発」

――具体的には、どのようにしてレコメンド機能を実現しているのでしょうか?

奥村:LINEのデータ専門研究開発組織「LINE Data Labs」と共同で作成しています。LINE Data Labsでは、出前館の注文履歴を基に「この地域のこういう属性のお客さまには、このショップの商品がよく注文されている」といった利用動向をまとめているので、出前館にそのデータを取り込んでパーソナライズに活用しています。

実装にあたり最も苦労したのは負荷対策ですね。パーソナライズ表示はユーザーごとに画面が変わるため、APIから取得したキャッシュを流用できず、サーバーの通信負荷が大きくなるんです。

また、どの地域で表示されているかを識別するブロックコードとショップのデータを掛け合わせるので、加盟店舗数の増加に伴い扱うデータ量も膨大に。そのため、データ量の正しい見積もりと、それに適したデータベースの容量を用意する必要がありました。

出前館

原山:現在、トップページの「あなたへのオススメ」では、店名と写真の他に、評価、最低注文金額、待ち時間のみを表示させていますが、これも負荷を考えてのことです。

やろうと思えば店舗ごとの人気メニューを表示したり、ユーザーにあわせて表示する料理の写真を変えたりといった工夫もできるかもしれませんが、扱う情報量が多くなるとそれだけ負荷も増し、表示などに時間が掛かってしまう。

そこでまずは現状のスペックに合わせて表示内容を最低限に絞り、ミニマムな機能でリリースしたのです。

奥村:出前館では今回に限らず、いつもMVP(ミニマム・バイアブル・プロダクト)開発を心掛けています。

MVPとは、ユーザーに利益をもたらす最小限の機能要件やシステムスペックに絞って、速くリリースしようというもの。実際にリリースしてユーザーからフィードバックを受けながら、自分たちの仮説が正しかったのかを検証し、改善していくサイクルです。

パーソナライズ表示はCVRにつながることが今回のリリースで分かったため、今後は機能を拡大していく予定です。

――まずは必要最低限。リリース後の反応を見ながら、伸ばすか辞めるか判断をするわけですね。

奥村:ちなみに先ほどの負荷対策の話に付随して、現在、画面表示や遷移スピードを上げるため全画面のリプレイスも進めています。出前館は歴史が長いサービスなので、システムのアーキテクチャが最新ではなく、ユーザー体験の速さにも影響が出てしまっていたためです。

今回のような新機能を追加する上でも、ユーザーに快適にサービスを使ってもらう上でも、リプレイスのプロジェクトは重要な役割を担っているんですよ。

根拠を基に仮説を立て、二つの視点で見極める

――やはり出前館のサービスを成長させていく上で、ユーザー体験における「速さ」を向上させることは重要ですか?

原山:そもそもフードデリバリーサービスは、「何か食べたい」と思った時に使う方が多いので、本質的に速さは重要だと考えています。だからこそ、これまでも料理を温かいうちに届けるべく、配達員のアサインや経路選択などのシステムで配達効率を後押しし、「届ける」速さの向上に努めてきました。

今回の「速く注文できる」施策についても、CVRが高く出ていることから、サービスを伸ばす上で必要な取り組みだと考えています。

奥村:僕の関わる「表示速度」に関しても、Amazonが2007年に「サイトの表示速度が0.1秒遅くなると売り上げが1%低下する、1秒高速化すると売り上げが10%向上する」という調査結果を出している通り、事業利益に直結する部分だと考えています。

(参考)Online Experiments:Lessons Learned

――では、「速さ」をサービスに取り入れる際のポイントは?

原山:まずはユーザーが求めているものを正しく見極めることではないでしょうか。

データにしっかりと目を通し、ユーザーの動きを理解した上で「こういうことに困っていそうだ」と仮説を立てる。すると、どういった機能が必要なのかが見えてくるはず。徹底したデータ分析によって、その仮説を裏付けられるだけの根拠を集めることが大切です。

レコメンド機能についても、「流行っているから」実装したわけではなく、Google アナリティクスやSQLで導き出されたデータなどを基に、ユーザーが求めている機能を考えた結果導き出されたものです。やはり、根拠に基づいた仮説が成功への最短ルートだと思いますね。

出前館

原山:また、その上で「MVP開発」で小さく始めることが大切なのかなと。

最初から多額のシステム投資して最大限の機能を盛り込んでも、いざリリースしてみたらユーザーが求めていたものとズレていた、ということは往々にして起こり得ます。

それならまずは最小限の機能でリリースして、ユーザーの声を聞きながら改善を加えていく方が、リスクも少ないし、最終的にはユーザーが本当に求めているものを最短で完成させられるのではないでしょうか。

奥村:僕は、速さの改善には「企画的な観点」と「システム的な観点」の二つがあることを意識することが大事だと思います。

機能をリリースした際にうまく「速さ」が伸びていなかったとして、企画側に改善の余地があるのか、それとも開発部分で見直しが必要なのかによって次に取るべきアクションが変わってきますよね。

システムのパフォーマンスに関しては、ベストプラクティスと呼ばれるものが数多く存在しますが、サービスによって何かベストかはまったく違います。

地道に思えるかもしれませんが、継続的に効果を測定できる環境をつくっておき、MVPでリリースして計測し、調整していくという方法が、結局は失敗しにくいのではないかと思いますね。

取材・文/古屋江美子 撮影/吉永和久 編集/河西ことみ(編集部)

Xをフォローしよう

この記事をシェア

RELATED関連記事

RANKING人気記事ランキング

JOB BOARD編集部オススメ求人特集





サイトマップ