この記事は 食べログアドベントカレンダー2023 の6日目の記事です。
こんにちは。
食べログAndroidアプリ開発を担当している 原田 です。
私は食べログのアプリ開発部プロダクトチームに所属しており、口コミ領域におけるユーザー体験の向上をテーマとしたユニットで、企画メンバーやデザイナーと一緒にアプリのUI/UX改善に取り組んでいます。
前回の記事では、インストール直後のユーザー体験を向上させるための取り組みとしてDeferred Deep Linkの導入事例をご紹介しました。
今回の記事では、私が2023年度上期に行った「投稿店舗一覧画面の検索フォーム1Box化」を一例として取り上げ、案件開発において日頃から考えていることを整理しつつ、意識していることを現場目線でご紹介します。
サービス開発に携わっているエンジニアの方はもちろんのこと、そうでない方にもお役に立てる情報になれば幸いです。
目次
はじめに
普段の開発プロセスや体制について、簡単にご紹介します。
食べログアプリの開発チームでは、企画メンバー・デザイナー・エンジニアでチームを組み、各チームが仮説をもって様々なアプローチからアプリの改善に取り組んでいます。
食べログの横断的なチーム編成に関してはこちらの記事で詳しくご紹介していますので、ご興味を持っていただけましたらぜひご一読ください。
食べログの大規模なエンジニア組織を段階的に改善していく取り組み
通常は企画メンバーとデザイナーがプロトタイプを作成し、その後エンジニアが要件定義に入って具体的な仕様を決定していきます。
最近では施策考案や方針策定の段階からエンジニアも参加し、技術的な視点から要件を一緒に考えていくことも増えています。
リリースはiOSアプリ、Androidアプリともに週1で行っています。
リリース後には効果計測と仮説検証を行い、考察を得て次の施策に反映させていていくPDCAサイクルを早く回すことをチーム全体で意識しながら取り組んでいます。
今回の記事はその事例の1つです。
施策内容
「投稿店舗一覧画面の検索フォーム1Box化」について具体的にどのような対応をを行ったのか、簡単にご紹介します。
食べログアプリには店舗の検索結果を表示する画面がいくつかありますが、今回の施策で関係する画面は以下の2つです。
- アプリ起動初回時に表示されるトップ画面の店舗一覧画面
- 口コミを投稿するための店舗を検索する「投稿するお店を選ぶ」画面（以降、投稿店舗一覧画面）
今回の施策内容は、投稿店舗一覧画面の2Boxタイプの検索フォームを、店舗一覧画面と同様の1Boxタイプに変更するというものでした。
2Boxタイプはエリア／ジャンル指定検索が可能であり、1Boxタイプはフリーキーワード検索が可能となります。
1Boxタイプにするとわざわざエリア／ジャンルを指定する必要がなくなるため、ユーザーの検索体験が大幅に向上します。
昨年度から今年度上期にかけて「口コミ投稿の導線がわかりにくい」という課題を解消するために、投稿トップ画面（マイページタブ右下にある投稿ボタンから遷移できる画面のこと）を新設しました。
これにより、投稿店舗一覧画面への導線が増えることでユーザーの目に触れる機会が増えるようになりました。
元々、投稿店舗一覧画面は導線が少なくあまり見られない画面だったこともあり、2Boxタイプの古い検索フォームのまましばらく取り残されていたのですが、今回露出が増えるタイミングで店舗一覧画面と同様の1Boxタイプの新しい検索フォームに揃えたいという経緯がありました。
業務での考え方
1. 本当に「〜と同じ」でよいか？
当初、企画メンバーからは「投稿店舗一覧の検索フォームをアプリトップの店舗一覧と同じ感じにしてほしい」とお話をいただきました。
前述の通り、食べログアプリの開発チームでは要件定義段階からエンジニアも参加して案件開発することが多いため、上記のようなざっくりとした粒度でお話をいただくことも少なくありません。
このような場合、見切り発車で調査に入り、全ての機能を満たすための工数は・・とエンジニアが手を動かしはじめてしまうと、本来達成したかった目的に対してピンポイントにアプローチできずに、結果として大幅に工数を取ってしまうことがあります。
そういった場合は基本に立ち返り、改めて案件の目的をエンジニアも理解することが大切だと思っています。
今回の場合は
- 投稿店舗一覧画面でユーザーが体験したいのは「口コミを投稿したいお店（＝以前行ったお店）」を素早く的確に検索できることであり、「これから行きたいお店」を検索することではない
点が改修のポイントととして見えてきたため、それにそぐわない店舗一覧側の仕様は切り分け、ファーストリリースから落とす判断ができました。
上記について、早い段階で企画メンバーとエンジニア間ですり合わせられたことで、手を動かす前に必要な機能を絞り込み、仕様を最小限にできました。
これにより、最小の工数で、かつ最速でユーザーに価値を届けることができたと思います。
表面上は「〜と同じ」という要件があっても、その本当の意味や背景を理解することが大切だと感じています。
一歩立ち止まり、要件が具体的に何を指しているのか、それがどういうことを意味するのかを自分の頭で考えることが必要です。
また、施策の背後には必ずストーリーが存在するので、理解をするためにはプロジェクトの指標や動きにアンテナをはり、日頃から企画メンバーやデザイナーと会話して共通認識を構築しておくことが重要です。
理解した上で施策の意図や目的にあうかどうかを考えてより仕様をシンプルに削ぎ落とし、負債にならないようにシステム観点でエンジニアが提案し交渉していけると、アプリの改善は質・スピードともに向上していくと思います。
2. 目的達成に必要な最小の仕様に調整できているか？
上記1. の話に続く内容となります。
改修の目的をすり合わせた上で、実際に店舗一覧がもつ機能のなかで投稿店舗一覧改修のファーストリリースで対応した機能と、反対に切り分けた機能、またどんな観点で切り分けたのかについて具体的にいくつかご紹介します。
例1. 検索サジェスト画面での検索履歴表示機能
検索フォームをタップすると、テキスト入力に応じて検索サジェスト一覧が表示される画面（以降、検索サジェスト画面）に遷移します。
トップの店舗一覧では対応されている検索履歴表示機能ですが、こちらについては次のように考えたため、ファーストリリースから落としています。
- 店舗一覧画面ではお店を検索したり、お店を複数検索して比較したりする（＝検索するお店が決まっていないことが多い）
- 投稿店舗一覧画面は口コミを投稿したいお店を検索したい（＝検索するお店が決まっていることが多い）
- したがって、前回検索した履歴を使って検索したいシーンは少ないはずである
例2. 優先エリア指定あり検索機能
店舗一覧では、例えば「渋谷 恵比寿」のように複数のエリアが検索フリーキーワードに含まれる場合、「どちらのエリアを検索しますか？」画面が表示され、エリアとして指定するキーワードを優先的に検索させる機能が存在します。 こちらについては次のように考えたため、ファーストリリースに含めています。
- 想定利用シーンが限定的である投稿店舗一覧画面で、どこまで検索パターンをカバーさせるかは悩ましい
- とはいえ、検索のヒット数に関わる部分であるため、頻度は少なくてもカバーする必要がある
▼各機能
もちろん、どの機能についてもあったほうがよいに越したことはありません。
しかし、最短でリリースして仮説検証し、効率よく改善を積み重ねていきたいので、案件の目的をおさえて仕様を整理し、小さくリリースすることをチームとして徹底するよう意識しています。
3. リリース後に困らないか？
案件を進めるにつれ、要件定義段階、実装段階などそれぞれの段階で確認したいことがでてくると思います。
ここでは効率よく、かつ認識齟齬なく進められるよう普段から工夫している点について、他のメンバーとのやりとりの側面からご紹介します。
ドキュメント活用
私は、普段の小規模な施策についてはMicrosoft Teamsのチャットベースで要件や仕様をすり合わせていくことが多いです。
一方、チャットではなくドキュメントベースで進行する場合もあります。
通常、iOSアプリとAndroidアプリで同時にリリースすることが多いものの、改修内容によっては片方のアプリで先行して実装しリリースする場合があります。
こういった場合の案件や大型案件ではドキュメントを用意して進めていくようにしています。
今回もAndroidアプリの先行対応であり、かつ中規模以上の改修案件であったため、要件定義段階から相談・検討用のドキュメントを用意し、仕様に関する全てのやりとりをドキュメント上で行うことにしました。
このような案件を進行する際、チャットだけで完結させると、後で対応する開発者が仕様やそこに至った経緯を理解するために、すべての関連チャットを探して読み返さなければなりません。
一見地味ですが、実際はかなりの時間を要する作業です。
また、チャットの性質上、認識合わせの痕跡は残るものの、最終的な結論が不透明になることがあります。
例えば、特定の機能が実装されたのかどうかや、それに関する計画があるのかないのかが不明瞭なケースがあります。
プロセスと理由こそ残す
また、チャットだけでは、決定事項は分かるものの、その決定に至るまでの試行錯誤や背景が不足していることがあります。これでは同じ失敗を繰り返す可能性が高まります。
一方で、ドキュメントを作成することで、決定事項とその理由をフォーマット化し、誰でも同じ粒度で必要な情報を得ることができます。
さらに、ドキュメント上で案件進行してしまえば、後でドキュメントを作る作業が減ります。
ただしドキュメント作成に膨大な時間がかかってしまうのは本末転倒なので、丁寧な書き方に拘る必要はありません。
案件の性質に応じてやりかたを変えながら、そのやり方自体についてもメンバーと認識を合わせながら進めるのがよいと思っています。
食べログではiOSアプリとAndroidアプリを提供しており、まず一方のアプリに実装し、効果を見てからもう一方のアプリにも実装するという戦略を採っています。こういった場合、先行実装した機能の仕様を明確にしておかないと、一方のアプリでは対応されているのにもう一方のアプリでは対応されていないという状態になりかねません。
このような事態を避けるために、決定事項とその理由・背景については明確に記録を残すように、特に注意しています。
まとめ
食べログアプリの案件進行および開発プロセスに関して、日頃意識していることを整理してみました。
こういったチームで行うプロセスにおいては最適解を出すのは難しい場面も多いですが、要件定義の段階でエンジニア視点から提案し、機能仕様をユーザビリティとシステム効率の両面から最適化できるよう、引き続き試行錯誤していくことが重要だと考えています。
今回の記事を通して、普段食べログアプリのプロダクト開発をどのように行っているのか少しでも知っていただき、また、ご紹介した内容が何かのお役に立てば幸いです。
明日は @chibaqn さんの「カスタマーフライデーで得た『ユーザーの声』が施策につながった事例の紹介」です。お楽しみに！
