開発優先度で悩まないための「データの民主化」
今回、所属しているトレタのアドベントカレンダーに投稿することになったので、長らくROM専門となっていたnoteで書いてみることにしました。
2020年4月に入社し、一貫してトレタ予約番という新規サービスのプロダクトマネジメントに携わってきましたが、その中で特にこだわって進めてきた「データの民主化」について触れてみます。
トレタ予約番とは
まず、トレタ予約番のサービス概要をプロダクト目線で説明すると、飲食店にかかってくる電話に対し、音声認識と音声合成技術を使うことで、予約者と会話形式でやりとりを行いながら予約完了までを24時間365日自動対応する、というものです。
以前から飲食店にとって、電話という強制的な同期コミュニケーションは、店内オペレーションの生産性を著しく落とし、店舗体験の重要要素である接客に集中できなくさせるという課題があったところ、コロナにより飲食店が大打撃を受け一旦課題が収束してしまいました。しかしながら今回コロナ禍が一応の収束を見せ、外食需要が急激に戻りつつある一方で、一度飲食業を離れてしまったスタッフの多くが戻ってこず、その結果かつてない人手不足が生じているのが現状です。
もはや何かを省人化・機械化しなければ肝心な接客すらままならないという状況で、改めて電話課題を解決する動きが急速に進み、まさに電話対応を省人化させるトレタ予約番の出番がようやく来た、というところです。
新規サービス開発の方向性と優先度決定に必要なもの
さて、このようなサービスを新規に開発するにあたり、前例が無い中で着実に有用なサービスに仕上げていくには、まずはMVP(Minimum Viable Product)を出すこと、そしてその後のサービス開発の方向性ならびに優先度は、予約者の行動データに基づいて意思決定をすることが重要だと考えていました。開発初期段階では、とりわけ大胆な話、面白そうな話で盛り上がることも多くなりがちですが、予約者はあくまで「予約をするというジョブ」を完遂することがゴールであり、それに最短距離で貢献する施策であるという根拠がなくてはなりません。行動データがリアルタイムかつ十分に取れないことで、発言者の声が大きいからであったりネタ・話題として面白いからといった理由で開発を進めると、取り返しがつかないあるいは手戻りに大きなコストを払うことにもなりかねません。そもそもサービス立ち上げ自体がチャレンジングなので、その登り方は極めて着実にしておくべきだと考えていました。
サービスフローのどこでどのようなデータを取得すべきかが肝
トレタ予約番における電話対応フローは大まかに、
1. 新規予約かどうか
2. 日時人数の確認
3. 個室希望の確認
4. 名前の確認
5. 連絡先の確認
6. 予約確定
となります。現状フリーな会話の意味理解をしているわけではなく、ある程度決められたフォーマット内での発話を認識し、シナリオベースで会話を進行させているため、上記フェーズ毎の複数パターンの掛け算だけでなく、予約以外の問い合わせにも対応しているため、今となっては万オーダーの会話パターンが存在しています。
このサービスにおける成功条件は、予約したい人がきちんと予約確定までたどりつけたか（それ以外の架電理由もあるが簡単化のため割愛）であり、裏を返せば、各フェーズで離脱させない仕組みが必要になります。なので、サービス改善のためには「フェーズ別の歩留まり管理」、すなわち、どのフェーズでどのような理由で離脱したのかをデータ化し、分析できるようにしなければなりません。具体的には、予約条件や名前を音声認識できなかったなどのプロダクト起因によるものなのか、あるいは休業日や満席など店舗起因によるものなのかをできる限り細かく切り分けられるようにし、開発側でコントロールできる/できないだけでなく、どこに改善インパクトがあるかを数字で掴めるようにする、ということです。
「データの民主化」のために必要なのは「意見」のないデータ
そして何よりも重要なのは、そのデータをビジネス・開発のロールを問わず見れるようにするだけでなく、自らSQLを書いてそれぞれの見地から分析できるようにする、いわゆる「データの民主化」です。これは分析スピードを上げるだけでなく、誰かの意見が混じっていない状態のデータをさわれるようにしたかったことに狙いがあります。例えば、データ自体は加工していなかったとしても、誰かが月次で抽出した時点でそれは「月次で見ることに意味がある」という「意見」が入っています。
もちろん当然に、プロダクトのパフォーマンス/予約者の満足度/利用店舗の満足度を代表するKGIや、それにつながるKPIを決めた上で「意見」のあるモニタリングしていますが、一方でありのままのデータをフルオープンにしておくことで、より良い指標があれば誰でもいつでも議論できる環境にしてある、というところに意味があると思っています。
ちなみに分析基盤としては、データウェアハウスはGoogleのBigQuery、BIツールは無償で使えるMetabaseを採用しています。高額なBIの利便性も捨てがたいのですが、Viewer権限でもそれなりにするので、広くに分析環境を提供する観点からMetabaseを活用しています。また、「データの民主化」を標榜するにはビジネスメンバーもSQLを書けなければなりませんが、まだそれほど複雑な分析が必要なフェーズでもないため、得意なメンバーに講師役をつとめてもらい、私も含め複数回のレクチャーを経て大体やりたいことはできるようになりつつあります。
「データの民主化」で得られる開発への効果
こうして「データの民主化」が進んでくると、タイトルの通り開発優先度の決定コストが非常に低くなる効果が出てきます。つまり、予約者の行動データが自由に確認・分析できるようになることで、サービスに対する現状把握レベルがメンバー内で揃ってくると共に、抱える課題とその重要度・緊急度についても最小議論で整理ができるようになります。もちろんプロダクトマネジャーである私が意思決定をすることにはなりますが、それまでのプロセスで大いに意見が対立し白熱するであったり、客観性を持たせるためのスコアリング手法を使わなくてはならないといった場面はありませんでした。そして、この効果はメンバー外のステークホルダーにも及んでおり、良いことも悪いことも数値で詳らかになってしまう透明性の高さから、各種説明コストが非常に低くなっており、とても健康的なサービス開発ができている（と少なくとも私は思っています。）
フェーズが変わる、指標も変わる
トレタ予約番はローンチから1年ほどですが、ようやく0→1フェーズを抜けたぐらいのサービスで、ここから1→10へのギアに変えて進めていく必要があります。フェーズが変わり、また顧客も増えると見るべきデータも随時変化していくと考えており、引き続きこの「データの民主化」により、指標をマンネリ化させることなく適切なものに見直していくことも大事になってきます。ここまで書くと、データ偏重になっているように感じられるかもしれませんが、データドリブンの限界も一方でよく見えてくるので、飲食店や予約者の方々からの定性的な印象・感覚といったことを確認できる仕組みもあわせて走らせています。
今回は初回でしたので概念的であまり具体的なことに触れませんでしたが、分析環境からどのように課題発見し、施策化→実装→検証といったサイクルの回し方や課題管理の仕方など運用面も非常に大事なポイントですし、そもそもサービスのKGI/KPIを何に置くかというのも新規サービスではかなりの悩みどころでもあると思うので、その辺りもトレタ予約番での事例を元にnote化していけたらと考えています。では。