エンジニアの僕が強みを活かして施策推進したら、異次元の角度で数字が伸びちゃった話

こんにちは。エンジニアの敷地(@shikichee)です。
現在AI受診相談ユビーのプロダクトオーナーをやっています。

自分が入ってから、リピーター数が2ヶ月半で5倍に

今回はエンジニアとして培ったスキルを活かしながら、施策の立案から実行まで行い、2ヶ月半でリピーター数が5倍になった事例を紹介できればと思います。タイトルは若干ふざけすぎですが。笑

※この記事は Ubie Advent Calendar 2020 の 21 日目の記事です。

0. 突然のチーム移動&課題だらけの環境

Ubieに入って3年間、病院向けのプロダクトAI問診ユビーをソフトウェアエンジニアとしてずっと開発してたのですが、今年の10月にAI受診相談ユビーという一般ユーザー向けのサービス開発チームに異動することになりました。

AI受診相談ユビーとは

質問に答えいてくと、参考病名や適切な医療機関が出てくるシンプルなサービスです。ぜひ具合が悪くなったときに使ってみてください。https://ubie.app/

2022年にUS版（https://ubiehealth.com/）もリリースされています。
※2023年3月追記

開発メンバーは、エンジニアが3人、デザイナー1人の小さなチームでした。
リリースして半年経ち20万弱のMAUがあったものの、サービスとしては伸び悩んでいました。

課題だらけの環境で、プロダクトオーナーに
チームに入った瞬間に、カオスな環境だ・・・。と感じたのが正直なところです。

移動した当初、様々な問題がありました。

1. 目標設定：目標が抽象的で、様々な課題に対応しすぎている
2. 施策立案：成果に繋がる施策が出ない
3. 実行：何のためにやるのか分からないまま開発

最初はエンジニアとして通常通り施策の開発をする予定でしたが、このままではまずいと思い、自分からプロダクトオーナーになることを宣言し、施策を推進していくことにしました。

1. 一番成長に寄与する課題を特定し、結果を可視化できる環境作り

目標が抽象的で、様々な課題に対応しすぎている問題
当時のチームの目標数値は、NPS(顧客満足度) を高くするというものでした。サービスは半年しか経っておらず、様々な問題を抱えていました。

質問が分かりにくい、もっと具体的な症状を入れたい、病名が参考にならないなど。ユーザーの声を挙げ出したら、きりがありません。チームに4人しかメンバーがいないため、全てに対応していく暇はありません。
短期間で成果を出すには、一番どこがプロダクトの成長にレバレッジが効くポイントなのかを見極めフォーカスする必要があります。

誰にどういった行動をして欲しいのか。
シンプルですがまずはここを決めるところから始めました。

ターゲットユーザーの明確化
過去のインタビュー内容を見返し、試しに自分がどんなサービスか使ってみようというライトユーザーも多いことが分かってきました。
ライトユーザー向けに機能を作っていると効果がすぐに出ないため、時間が足りません。

AI受診相談ユビーを通じて、病院に行こうかどうか迷ってる人を後押しし、病院に早めに行ってよかったと思ってもらうことこそがサービスの価値だと考えました。

要医療の人が、最適な医療機関に行くのをサポートする。という直近のプロダクトのコンセプトを決め、ターゲットと見るべき指標を定義しました。

Before:
ターゲット：全ユーザー
指標：NPS(顧客満足度)

After:
ターゲット：年齢が高い人かつ、症状の重症度が高い人
指標：医療機関の表示率、医療機関の詳細表示率

Redashダッシュボードの作成

ターゲットセグメントを元に重要指標を定義し、常にダッシュボードで最新化し見えるようにしました。

エンジニアとして、どのDBに何のデータがあるか分かり、SQLが書けたので、分析も他の職種の人より簡単にできます。足りていないログも、自分で仕込むこともできます。今回は、目標設定からダッシュボード作るまで比較的容易に行うことができました。

2. エンジニア目線でコスパの良い施策を考える

成果に繋がる施策が出ない問題
一通り明らかな改善点を直していき数値が改善していったのですが、ある時それ以上伸びなくなっていました。

結果画面で病名を見て、画面から離脱する人が多かったのです。

ユーザーが表示された病名に対して判断がつかず、離脱しているのではないかという仮説を立てました。
ただ、どういった病気なのか説明文を入れるにも数千と病気はあるため、短期間で全ての文章を医師に依頼して作成してもらうことはできません。

既存のアセットを活かしたコスパ施策
ユビーは問診技術を強みとして持っており、医師監修の元症状と病気の紐づいたデータを数年間鍛え続けています。
この紐付きデータを使って、病気に対してよくある症状を自動生成できるのではないかと考えました。データサイエンスチームと協力しSQLで検証すると、ほぼ全ての病気で紐づく症状を作成することができました。

数日で実装され、リリース後、医療機関の表示率やリピート率が急激に伸びはじめました。

エンジニアとして、プロダクト内部や既存のアセットを理解しているため、開発コストがかからない施策をエンジニアは考えやすいです。今回は、データのアセットを詳細に理解できていたため考えることができました。

3. 毎日、検証と学習ができる開発チームに

何のためにやるか分からないままの開発
チームは様々な問題を抱えていました。スクラム開発を導入しているものの、機能をリリースすることが目的化していたり、施策の優先順位も伝わっておらず個々人の力量で開発が行われたりしている状況でした。

その結果、なかなか重要な施策がリリースされないことや、リリースされたとしても結果が検証されないことが多発していました。ABテストをやってもその結果が放置されてしまうといったことも起きていました。

施策ごとの結果を積極的にデータで可視化する文化作り
何のために開発するのか、何の数値を検証するのか毎回設定しました。そして、リリース後の検証結果の可視化が漏れていた時も、自分が積極的にSQLを書き、チーム内で共有していきました。

その結果、自然と数字を共有するカルチャーが出来上がり、データドリブンで意思決定できるようになってきました。

さらに、ABテストの結果を共有するチャンネルや、普段slack上で思いついたアイディアをスタンプで押すと、施策が集まるチャンネルなどを作っていきました。

最終的には、データを元に新しい根拠のある施策がメンバーから生まれるようになっていきました。

エンジニアとしてチームに入り込んで、全員でデータを元に施策を考えるカルチャー作りができたかなと思っています。

4. 結果

2ヶ月半でリピーター数が伸びた
リピーター数が5倍になりました。

他チームからの声
ユビーでは、社内でよかった行動を称え合うカルチャーがあるのですが、今回のプロジェクトに関わるものをまとめてみました。
リリースの速度や結果についての反響がよかったようです。

エンジニア主導で施策推進していく場合のデメリット
エンジニア出身だと、どうしても実現可能性を考えてしまうのでアイディアが小さくなってしまうのを感じました。
戦略から逆算して、大胆な施策を考えることを意識的にやっていく必要があります。

5. まとめ

エンジニアとしての強みを活かして、以下の3つについて紹介しました。

取り組み
1. 成長に寄与する課題を特定し、目標数値のダッシュボード化
2. 既存のアセットを理解しているからこそできる、コスパの良い施策立案
3. データを元に施策を考えるカルチャー作り

結果
リピーター数が5倍に

引き続き、サービスの成長に全力でコミットしていきたいと思っています。今後も、サービスの成長過程で工夫したことや学びなどがあれば書いていきます。

さて、ユビーではエンジニア含め、あらゆる職種で積極的に採用行っています。今回の記事で、少しでも興味を持った方は、ぜひ採用サイトからUbieDayというオンライン会社説明会やカジュアル面談にお越し下さい。

#アドベントカレンダー