【イベントレポート】Retty Beer Bash#1〜Rettyグロースの成功・失敗事例 大公開〜
こんにちは、Retty人事の大森です。
021/06/29に開催したオンラインイベント「Retty Beer Bash#1」。ご参加いただけなかった皆さんにもイベントの様子をレポートでお見せします！
イベントの目的
もともとRettyでは「イイゴハンの会」という、“飲んで食べてゆるくお話ししましょう”というイベントをオフィスで定期開催しておりました。このイベントをきっかけに様々な方と交流させていただき、採用や仕事など多方面に繋がっていました。それが新型コロナウィルスの流行に伴い、飲食を伴うリアルイベントは開催が難しくなりここ1年以上社外の方との交流機会が少なくなってしまいました。
そこでオンラインでも、イイゴハンの会のようなゆるさを残しながら皆さまと交流したい、お時間をいただくのであれば役立つ情報発信もできればということで、登壇者も参加者も飲みながら参加するテーマトークイベントRetty Beer Bashを企画しました。テーマを変えて1ヶ月〜2ヶ月に1度のペースで開催できればと思っております。
先日開催した第一回目のテーマは、Rettyグロースの成功・失敗事例 大公開ということで、RettyのVPoP、VPoE、PdM、リードデザイナーが登壇し、25名ほどのPdM、デザイナー、エンジニアの皆様にご参加いただきました。
19:30 乾杯/Rettyについて
19:35 イントロダクション
19:45 パネルディスカッション Rettyグロースの成功・失敗事例 大公開
21:00 終了
イントロダクション：Rettyについて
「あなたにBESTなお店が見つかる」というコンセプトで2011年にサービスローンチして以来、右肩上がりで成長してきたRettyの成功事例・失敗事例をパネルディスカッションでお話ししました。
パネルディスカッション：成功事例
こちらの5つのテーマから参加者の皆様のアンケートで3つお話する事例を決めました！
１：オフライン×オンラインコミュニティが加速する仕掛け
こちらの事例についてはリードデザイナーの山本、VPoPの野口からお話しました。
山本：Rettyはユーザーさんがクチコミを投稿してくださって成立するサービスですが、リリース初期から投稿が加速する仕組みを作ったという成功事例です。
大森：なるほど！
山本：投稿数のランキングがあり、投稿したジャンルやエリアであなたは何位ですというのが表示されます。自分がランクインすると、ランキングにいるユーザーさんのことを認知するようになり、ユーザーさん同士でのコミュニケーションが発生するようになりました。
そしてRettyではオフ会を定期的に開催しているため、オンライン上の繋がりがオフラインでも繋がるようになります。
オフラインで繋がった後はオンライン上でのコメントのやり取りがさらに活発化し、それによってまた一緒に食事に行こうというユーザーさん発信でのオフ会が開催されて・・という循環が起きています。
野口：オフ会には「いつもクチコミを参考にしているこのユーザーさんと会いたい」というモチベーションで参加してくださるユーザーさんもいらっしゃって、その方々が実際にオフラインで出会っている場に同席して熱量に感動しました。
オンラインとオフラインの循環は全部狙っていたかというとそうでもなくて、「オフ会やったら盛り上がるかな」とか思ってやった点の施策をユーザーさんが線にしてくださったみたいな感じですね。
田中：「会いたいユーザーさんを教えてくれたら社員が繋げます」という企画を開催していたこともありました。すごく人気企画でした。
山本：200名近いユーザーさんをお招きした大型のイベントをオフィスで開催したりもしています。ユーザーさんの熱量を肌で感じられるので社員も刺激をいただく場です。
2：事前検証を始めて、開発工数を節約！施策成功確度もアップ！
こちらの事例についてはPdM田中からお話ししました。
田中：初期は何もなかったのでスピード重視でやった方が良さそうなことをどんどんやっていくというフェーズから、必要な機能はそろってきてRettyならではの価値を明確にし、社内のリソース配分も戦略的に考えるフェーズに変わって、事前検証をちゃんとやるようになったというお話です。
田中：実装前にユーザーさんと壁打ちをします。プロトタイプを用意してヒアリングしたり、ユーザーアンケートなどの調査を実施しました。そもそも仮説が間違っていて課題と思っていたものは課題ではなかったとか、方向性は合っているけど機能的にはずれている、といった発見を事前にできるようになり、実装工数をかけずに議論ができるようになりました。
運営者の直感で成長できる範囲には限界があるなと感じました。事前検証をすることでユーザーさんへの価値提供にフォーカスした開発プロセスができるようになって良かったです。
大森：ユーザーヒアリングやユーザーアンケートはどのくらいの分量を実施すると「検証した」と言えるのでしょうか？
田中：検証したい仮説によります。例えば「お店の情報の信頼性を実感できるラインはどこか？」を検証するには結構な数聞かないと見えてこないですが、「ある画面のUIを見てもらってこれで伝わるかどうか？」だったら100人に見てもらわなくてもわかるし、ケースによります。
1年半ほどまえに「グルメサービスに何を求めているか」の検証で、2000人のアンケート、30人のインタビューを実施しました。定量定性組み合わせて実施することも多いです。
大森：ヒアリングやインタビューに応じてくださる方はどう探しているの？
田中：社員に紹介をお願いするのと、リクルーティングサービスを活用しています。
参加者：ユーザーアンケートとってその時は欲しいと言われても、いざ実装してリリースすると全然使われないケースってざらにありますが、そういう場合ってどういう感じで対処していますか？またそうならないためにはどうしていますか？
田中：まずそうならないようにするために、何かが欲しいと仰った際にその背景やコンテキストを理解するようにしています。最近だと動画投稿できるようにしてほしいと言われたのですが、その先に何を表現したいのか？と深掘りしていくと動画じゃなくて良いなとなったりします。
ただそれでも失敗して使われない機能になってしまうことはもちろんありまして、そういう場合はなぜそうなったかを議論した上で機能を消します。
参加者：初期の段階から事前検証しておけば良かったと思いますか？
野口：プロダクトのローンチ前の事前検証はした方が良いと思います。ローンチ後、グロースフェーズではスピード重視でどんどん出していくフェーズもある程度必要だと思います。
小迫：どう考えても必要でしょっていう機能もあるので検証するよりも開発しちゃった方が勝率高いタイミングがある。
参加者：プロトタイプはどのように作られていますか？何かサービスを使われたりしていますか？
山本：体験の仮説検証のプロトタイプはデザイナーが画像を粗々で作って共有することが多いです。ツールは今はFigmaを使っています。
参加者：プロトタイプ確認、ユーザーインタビューを定常的に回す場合、準備や実施にもそれなりの時間を使うと思いますが何人ぐらいで運用しておりますか。
野口：Rettyは現在、インタビューはメイン担当1人とPdMが2人で実施し、議事録担当が1人書き起こしを実施。ユーザーさんとの日程調整をカスタマーサポートチームが担当しています。Rettyだとこのように分担していますが、週1〜2回インタビュー実施する場合1人調整、もう1人がインタビューの設計や実施を行うとして2人が良いかなと思います。
3：コロナ禍でテイクアウト表示・検索をいち早くリリース！が、見切りも即決断
こちらの事例はVPoEの小迫からお話しました。
小迫：昨年の4月にテイクアウト機能というのをリリースしました。
小迫：コロナが本格化し緊急事態宣言があるんじゃないかと言われたような時期、飲食店さんのためにも自社事業のためにも何ができるか考え、オンラインで飲食店さんやユーザーさんにインタビューさせていただたりユーザーさんの行動ログを分析したりして、2週間弱でオンラインでのテイクアウト検索サービスの需要が高いと特定し、1ヶ月弱で急遽リリースしました。
ただ実際にリリースしてみると、継続的なグローストレンドではなかったことが判明しました。テイクアウトは毎回探すのではなくいくつかお気に入りのお店を見つけたらそれ以上は検索しないことがわかったので取り下げました。やる判断もやめる判断も早急に行いました。
参加者：テイクアウトが流行らなかったのってUberとかの宅配サービスがでかいんですかね？
野口：それもあると思いますし、家で食べるなら料理するという文化的な背景もあります。あと一部の都会を除いて大体は車文化なので近くにテイクアウトができる飲食店がない方も多かったり、様々な要因がありました。
パネルディスカッション：失敗事例
1：スクラムを入れたらむしろギクシャクした 最近ようやく形になってきた
小迫：今はLeSS（大規模スクラム）の体制で開発していますが、過去に何度かスクラムを導入しようとして失敗したお話です。
もともと特に開発スタイルはなくそれで問題もなかったのですが、次第に人数が増えてきて開発フレームワーク入れてみよう、スクラムやってみようとなりました。すると次第にスクラム絶対正義派閥と、なんかやりにくい派閥が発生してギクシャクしてしまいました。
そもそもなんでスクラム入れたいの？何が課題なの？どういう開発組織を目指しているの？というのがなく、なんとなくスクラムを入れてしまったのが失敗要因だったと思います。
野口：当時はスクラムの理解度も低く、流行っているから良いものなんだろうと本質を捉えずスクラムっぽいものを導入してしまっていました。
小迫：現在の体制になる前には1年くらいかけて、こういう目的・理由でこういう方法を取るよ、今後もっと最適な体制があれば変更するよ、という説明を全員にしてから導入しました。誰になぜ？と聞かれても答えられるように言語化しました。
2：アプリで短期数値を上げるためにUIだけ変更も、数値に現れなかった
山本：Web版のRettyでうまくいった施策をそのままアプリ版に持ち込んだら全然結果出なかった失敗談です。
検索結果画面で表示されるお店さんのカセットをすごく大きいものにしていて、Webでこのカセットを小さくして検索結果に表示されるお店の数が増えるようにしたら数値的に伸びたので、アプリでも同じように変更しました。
しかし結果的にアプリでは数値的には変化が出ませんでした。
ユーザーインサイトを得ずに成功事例をそのまま転用してしまったのがダメでした。まずWebとアプリだとユーザー体験が違っていて、Webは検索エンジンで「渋谷 居酒屋」などのワードで検索して上位表示されたサービスがRettyという体験、アプリの場合はまずRettyを開いている、この差を考えずにWebで良かったことをそのままアプリでも、とやっても結果は出ないとわかりました。
また、点の施策でアプリ全体でのユーザー体験の設計をしていなかったのも原因です。ただ画面を変えても意味いがない。
現在は、アプリのユーザーシナリオを作ってどういう体験を提供するべきなのか、から施策を決定するようにしています。
3：やりっぱなし・居所的だったユーザーインタビュー継続的な仮説検証を
田中：まず前提としてUXリサーチの手段のうちの一つがユーザーインタビューという位置づけですが、Rettyでは創業当初からユーザーさんからのお声で成長してきた側面が強く、ユーザーインタビューを盲信していたという失敗談です。
忘年会シーズンにRettyをもっと活用していただくためのユーザーインタビューを実施。予算は1人3000円くらい、大人数で入れるか、個室があるかが知りたいというインサイトを得たのでたくさんの検索軸を用意したのですが、結果全然使われませんでした。
自分たちが知りたいことを明確にできていなかったので聞いたことをそのまま機能に反映させてしまいました。
さらに、インタビュー結果を社内全体に共有できていなかったので、それをもとに動いているチームと知らずに動いているチームもありました。
①目的に合わせてユーザーインタビューという手段が適切なのかを判断する
②インタビューを実施するのであれば目的に応じた質問内容と対象者を検討する
③実施した内容は知見として社内に共有し足並みをそろえる
これらの重要性を学び、現在では改善しています。
最後に
イベントレポートは以上です！ご参加いただいた方からもご質問いただき、初回から盛り上がったので安心しました。このイベントを通じて知り合えた参加者の方と後日情報交換の場を持たせていただくなど、とても良いご縁につながりました。
今回の#1からより改善し、次回、7月27日（火）Retty Beer Bash#2スクラム開発におけるあれこれを語る会を開催します🎉🎉
みなさまぜひご参加ください！