見出し画像

AI × メンタルヘルスアプリ「アウェアファイ」のプロダクトディスカバリー

Airi Oda

ToCのメンタルヘルスアプリを提供する株式会社Awarefy（アウェアファイ）でプロダクトマネージャーをしています、小田愛莉（@anny_iiniku）です。

先日、プロダクト開発に携わるさまざまな職種の方々が集まるオフラインイベント「プロダクトスクランブル」を主催した際、以下のようなご質問をいただきました。

本noteでは、アウェアファイのプロダクト開発の一端を、できるだけ具体的に紹介します。

プロダクト開発のプロセスに「銀の弾丸」はないものの、より良い成果を目指してプロセスの改善を追求し続けるPMの方は多いのではないでしょうか。私自身PMとして未経験だった頃は、他社の事例を貪るように吸収し、それを自分のプロセス改善に役立ててきました。このアウェアファイの事例が、読んでくださった皆さんの参考になれば幸いです。


プロダクトディスカバリーとプロダクトデリバリー

プロダクト開発のプロセスは、大きく次の2つに分けられると整理されています。

  • プロダクトディスカバリー

  • プロダクトデリバリー

これらの概念については、プロダクトマネージャー向けの参考書として有名な『INSPIRED』シリーズの著者が言及しています。

製品開発における「発見」と「提供」という2つの重要なプロセスを論じています。
発見（Discovery）は、顧客のニーズを迅速に把握し、適切なソリューションを見つけるプロセスであり、提供（Delivery）は、そのソリューションを安定してスケーラブルな形で顧客に届けることを指します。
成功するためには、これら2つを同時に行い、迅速な学習と信頼性のあるリリースの両立が必要だと強調されています。
（ChatGPTによる翻訳・要約）

https://www.svpg.com/discovery-vs-delivery/

限られた時間とリソースの中で、高い成果が求められるプロダクト開発において、何を課題とし、どのような方法で解決していくかを決めて実行することに絶対的な「正解」はありません。各社のPMが共通して、正解がない中でベストな解を出し続けることに、永遠の課題を抱えているのではないかと思います。

アウェアファイも、成長をし続けるためのベストな解を出し続けようとしている最中です。そんなアウェアファイがどのようなディスカバリーを行っているのか、またディスカバリーとデリバリーを結びつける際に用いる「デザインドック」とチーム内のコラボレーションのすすめについて、2回に分けて紹介します。

Awarefy（アウェアファイ）について

アウェアファイは、毎日に寄りそい 気づきを増やす AIメンタルパートナーアプリです。
AIであるファイさんがユーザーの心の健康と成長をサポートします。認知行動療法やマインドフルネスなど心理学の知見に基づくさまざまな機能を搭載しているC向けのアプリです。

2020年5月にローンチし、これまでに60万ダウンロードを達成。2022年にはGoogle Playのベストアプリ部門大賞を受賞。ユーザーが加入するサブスクリプションモデルでマネタイズしており、毎年数百％の成長率で売上を伸ばしています。サブスクリプションに加入している会員数は数万人規模に成長しました。

アウェアファイのプロダクトチーム体制

  • プロダクトマネージャー 1名

  • プロダクトマーケティングマネージャー 2名

  • デザイナー 1名

  • エンジニア 6名

  • 心理士 2名

アウェアファイのディスカバリーフロー

プロダクトチーム12名（2024年9月時点）というスタートアップであるアウェアファイでは、職種を超えたコラボレーションでプロダクトディスカバリーに取り組んでいます。ディスカバリーのプロセスは、主に6つのフローで進めることが多いです。

1. 四半期のテーマを策定

ディスカバリーの根幹となるプロダクト戦略や目標は、四半期単位でOKRを用いて設定しています。
このプロセスでは、事業責任者兼CTOのいけぴさん（@iktakahiro）と、経営視点とアラインしているかを確認しつつディスカッションを行い、また、関心領域が接するPMM（プロダクトマーケティングマネージャー）の秦くん（@shouken920）とも、目指す方向性にズレがないかを確認します。

アウェアファイは成長途上にあり、解決すべき大きな課題（＝アウェアファイでは「大きな石」と呼んでいます）がまだ多く残っています。
その中で、「この四半期で取り除くべき大きな石は何か？」「四半期終了時に目指す状態はどのようなものか？」を、チーム全員が共通の認識を持てるよう、簡潔かつ明確に示すよう努めています。

最近のアウェアファイでは、「ダウンロード後の最初の7日間で、ユーザーがアプリを日常に定着させるかどうかが、ユーザーの心理リテラシーに依存している」という課題を、取り除くべき大きな石として設定しています。これは、アプリを使い始めたユーザーの「定着」＝初期の継続率に伸び代があるためです。

特にアプリでは、ダウンロード直後の初期段階に多くのユーザーが残っており、そこで良い体験を提供できればスムーズな定着につながります。
これまでのKPIが大きく動いたのも、オンボーディングや主要な機能への動線変更など、初期体験の抜本的な改善を行ったときでした。
ユーザーは、最初の段階で最も意欲と熱量が高いため、このタイミングで良い体験を提供することが非常に重要です。逆に、一度離脱したユーザーを再び呼び戻すのは非常に難易度が高くなります。

一般的なアプリでは、インストール後3日で約80%、30日後には約90%のユーザーが離脱しているそうです。
（Reproさんのデータを引用：https://repro.io/bpo/appimprove/）

アウェアファイに関しても、定量的に見ると、ベンチマークとしている有名ヘルスケア系アプリと比較して、初期の定着率には改善の余地があることが明らかです。継続率は、サブスクリプションの無料トライアル後の有料プランへの移行にも大きく関わるため、ビジネス価値に直結する重要な指標です。
さらに、定性的には、心理学のバックグラウンドやリテラシーがないユーザーから「使い方が難しい」「何をすればいいのか分からない」といったフィードバックが多く寄せられています。

そのため、「ダウンロード後の最初の7日間で、ユーザーがアプリを日常に定着させるかどうかがユーザーの心理リテラシーに依存している」という石を取り除こうとしています。

例えるなら、裏路地にあるレストランでどれだけ料理を磨き込んでも、場所がわからなければお客さんが辿り着かないのと同じです。まずはお店の場所がわかりやすくなるように改善することを、料理の研究よりも優先しているというイメージです。

2. 解決したいユーザー課題を特定

1で設定したテーマを達成するために、まずユーザー体験上で何が起きているか、何がブロッカーとなっているかを特定します。
このプロセスでは、ユーザーインタビューやアプリ内のフィードバックフォームから得たユーザーフィードバックに加え、ユーザーのログデータを分析し、仮説を立てています。

アウェアファイ内に設置しているフィードバックを収集するフォームは、あまり目立たない場所にあるにも関わらず、平均すると1日5件程度、コンスタントに投稿されています。
自動でslackに通知される仕組みになっているので、プロダクト開発メンバーを含め全社員がリアルタイムでユーザーの声に触れています。

しかし、ユーザーインタビューやフィードバック・ログデータをただ眺めていても、「大きな石」が取り除けない理由、すなわち、課題は特定できません。特定するためには、かなりの気力と集中力が必要だと思います。
そのため、最近のアウェアファイでは、会議がない土曜日に「合宿」と称し、ホワイトボードを駆使してチームメンバーと議論したり、普段はリソースを割けていないデータ分析に集中し、インサイトを抽出する時間を確保することがあります。

先日の合宿の結果、以前のアウェアファイでは、心理学的な視点から忠実に考えると、ユーザーの抱える心の悩みによって効果的な支援方法が異なるため、一律の体験をこちらで提供するのは難しいと考えていたことに気づきました。
そのため、ユーザーが自分の悩みや状況に合わせてリテラシーを上げ、自ら最適な体験や解決策を選び取れるような体験を設計しようとしていたのです。

しかし、様々な定量・定性データを振り返る中で、リテラシーの高いユーザーは自分で解決策を見つけやすかったり、すでに持っているケースが多い一方で、リテラシーの低いユーザーには無理難題を押し付けてしまい、結果的に離脱してしまっているのではないかという強い仮説が立ちました。

例えるなら、大学受験の予備校に通っている生徒に、カリキュラムや教材を自分で選定させているようなものです。本来、ユーザーにそのような負担をかけるべきではありません。ユーザーは解決策を求めてアプリを利用しており、解決策を見つけ出すスキルを身に付けたいわけではないからです。

このため、リテラシーが低いユーザーをしっかり導ける体験設計になっていないことを課題と捉え、「いかにユーザーがアプリに導かれる体験を作るか」が重要な問いになりました。どんな心のお悩みに対しても、一定の効果があるアウェアファイ独自のメソッドを開発・提供しようとする構想が生まれました。今はメソッド構想により、ユーザーが自然にアプリからサポートを受けられるような体験を目指しています。

3. 課題の解決策案を出して優先順位をつける

課題が特定できたら、アイディアはさまざま湧いてきます。
アウェアファイでは、強みであるAI技術を活用して課題を解決できないか、CTOやAIの体験設計・チューニングを担当する心理士と解決策案のディスカッションすることが多いです。
また、他のサービスで感動した体験を分析し、どのような課題がどのように解決されているかを推測して、自社の解決策を考える際の参考にすることもあります。

アイデアが数多く出てくる中で、アウェアファイでは「大通りの体験を優先せよ」という方針を重視しています。先に述べたように、大通りにあたらない部分の改善では、数字に大きな変化が起こらないことが多いためです。

具体例として、過去にユーザーの定着率を高めるために、「過去の記録を見返し、自分の成長や変化を感じる瞬間を報酬にすればよいのではないか」というアイデアが出て、アウェアファイに書き溜めた記録をランダムに見返す機会を提供する機能をリリースしました。
一部のヘビーユーザーからは好評で、ヘビーユーザーがさらにヘビーに利用してくれるようになったことはわかりましたが、施策の目的としていた全体の定着率には全く影響がありませんでした。そもそも、見返すことに価値を感じるほど記録が貯まるユーザーの母数が少なく、想定していたインパクトが出せなかったからです。
この機能は運用にも一定のコストがかかっていたため、最終的に取り下げる決断をしました。7日程度継続したユーザーのさらなる定着率が「大通り」になった際には、リベンジしたいと考えています。

上記のような失敗体験を踏まえて、無限に湧き上がる「もっとこんなことをやった方がいいのではないか！」というアイデアに対しても、まずは「大通りの体験かどうか」を判断基準とし、インパクトが大きいと思われるものから優先順位をつけて進めていきます。
元メルカリの樫田さんのnoteにも「大通りを大事にしろ」という記載があり、強く共感しました。

最近のアウェアファイでは、先に述べたように、ユーザーのリテラシーや心の悩みの種類に関わらず、AIであるファイさんがユーザーをサポートする方針を採用しています。
これまでは、ユーザーが心の問題で困った際、ユーザー自身が適切な機能やタスクを選ぶ必要がありました。しかし、現在はAIとのチャット体験を中心に据え、AIと話しているだけで包括的なサポートが得られるよう、体験をシンプルにするという解決策案をとっています。
チャット体験を中心に据える意思決定をした背景には、ユーザーがアプリを使い始めた初日に最も触れている機能がチャット機能であったこと、そしてAI技術を活用した包括的なサポートを実現できそうなビジョンが見えたことがあります。これらにより、チャット体験が「大通り」になり得ると判断しました。

しかし、チャット体験が中心になることで「過去に話した内容をAIが覚えておらず、何度も同じ説明をするのが手間」という新たな課題が浮上しました。人間同士のチャットでは、これまでの会話を適切に記憶し、それに基づいて応答することが自然であるため、AIにも同様の期待が生まれていたのです。ユーザーがアプリに定着するためには、「ファイさん」を信頼できるパートナーとして感じてもらうことが必須です。初期でがっかりする体験をさせないよう、チャット体験を強化する一歩として、長期記憶システムを搭載した「AIメモリー」という新機能を先日リリースしました。（一方で、AIは人間ではないため、ユーザーの期待値を調整するための解決策も合わせて検討しています。）

このように、解決策案を机上に並べ、優先順位が高い解決策案を採用したときに新たに出てくる課題を潰し、というのを繰り返しています。

4. 疎結合な体験でドッグフーディング

解決策が具体的になってきたら、できるだけ早く、体験フローが「疎結合」な状態でドッグフーディング（社内テスト）を行うようにしています。
多角的な視点を取り入れるため、事業責任者、デザイナー、PMM、心理士など、体験内容に応じてさまざまな職種のメンバーを巻き込んで実施することが多いです。

最近のアウェアファイでは、ユーザーがアプリを使用することで目指す「ありたい姿」を明確にするために、オンボーディングのフローを改善するアイデアが出ました。
このアイデアを素早く検証するため、「実際に問いを投げかけたらどんな回答が出てくるか」「アイデアが出ない状態に対して生成AIがどのように支援できるか」を、紙とペン、そしてChatGPTを使って30分程度試行しました。このようにして、素早く学習のサイクルを回し、アイデアを磨いていきます。

5. プロトタイプを作成

4のプロセスを経ると、どのような体験フローや画面デザインが適しているか、PMとデザイナーの頭の中に初期のアイデアが形成されます。これをデザイナーがプロトタイプに落とし込みます。

初期段階で検証したいことは、そもそもこれが筋のいい課題と解決策のセットなのか？というコンセプト部分や、体験の大通りに関わる部分が多いため、スピードを重視してプロトタイプを作成します。
アウェアファイのデザイナーのりゅーさん（@ryuki_kyoto）はFigmaの達人で、わずか数十分で動くプロトタイプを立ち上げてしまいます！

最近のアウェアファイでは、AIを活用した体験設計が増えており、そのプロトタイプにも生成AIの機能を組み込みたいことが多いです。この場合、Figmaの裏側で人が手動で生成AIを動かす「オズの魔法使い」的なプロトタイプを作成します。
AIを用いたプロトタイピングについては、スマートバンクさんが運営している「プロダクトディスカバリーチャンネル」でもお話しさせていただいていますので、よろしければご視聴ください。

6. ユーザーテスト

プロトタイプが完成したら、デザイナーと共にユーザーと対面での検証を行います。すべての施策でユーザーテストを実施するリソースや環境は限られているため、特に「本当に価値があるのか？」という不確実性が高いものや、開発に工数がかかるものを優先してテストします。

また、ユーザーテストといっても、状況に応じて以下のように対象者を選定しています。

アウェアファイをダウンロードしたことがあるユーザーに聞きたい場合
ターゲットユーザーが特定の層である場合は、ユーザー以外に条件が合致する人を見つけるのが難しいため、既存のユーザーにお願いする方法を採用します。ただし、ユーザーの抽出やリクルーティングなど、テスト実施までの準備に時間とリソースがかかってしまいます。
アウェアファイでは、ユーザーログから対象のユーザーを絞り込み、メールで依頼を送ると、すぐに十分な数のユーザーから反応があります。最短で翌日からテストを開始できる環境が整っています。

ダウンロードしたことがない人に聞きたい場合
オンボーディングやチュートリアルのテストを行う際には、アプリをダウンロードしていない人にお願いします。
この場合、お手軽かつクイックに対象者を集められる「torima.in」をよく活用しています。

身近な人に聞く場合
ターゲットが広い層や汎用的な場合、ユーザーではない身近な人、例えば社員やインターン生、友人にテストを依頼します。
この方法は、接触までのリードタイムが短縮され、迅速に仮説検証サイクルを回せるメリットがあります。

ユーザーテストでは、いくらテストをしても「確実なこと」は分かりません。
例えば「本当にこの機能を使うのか」「実際にお金を払うのか」といったことは、リリースしてみないとわからないという感覚があります。
私自身、検証の設計にはまだ改善の余地があると感じていますが、ユーザーテストを通じて「初期アイデアのままリリースしなくてよかった」という貴重な学びを得ることが多々あります。
不確実性を完全に排除することはできませんが、それを減らすためにユーザーテストは重要なプロセスだと考えています。このように、ユーザーテストを重ねることでプロトタイプが徐々にブラッシュアップされていきます（場合によっては、再び2の課題特定のプロセスに戻ることもあります）。

最近のアウェアファイでは、単にその場での操作だけでなく、ユーザーが日常生活に戻った際にも利用し続けられるかどうかを検証するため、公式LINEを利用したインタラクティブで継続的なテストを実施してみました。

以上が、現時点でのアウェアファイのディスカバリーフローです。

この後は、ディスカバリーからデリバリーへの移行です。
アウェアファイでは、6のユーザーテストが完了する段階から、ディスカバリーの成果物として「デザインドック」というドキュメントを作成します。
「デザインドック」とは、チームのコラボレーションのハブとなるものです。

この「デザインドック」の紹介とすすめについて、次回の「プロダクトディスカバリーとデリバリーを繋ぐデザインドッグのすすめ」で紹介しています。
ぜひ続けてお読みください。


アウェアファイで一緒にプロダクトマネジメントをしませんか？

アウェアファイでは、事業拡大に伴い2人目のプロダクトマネージャーを募集しています。
私自身も法人営業からプロダクトマネージャーへ転身したように、プロダクトマネジメント未経験でも問題ありません。スキルや経験がなくても、プロダクトに強い関心があり、プロダクトマネジメントに必要なスキルを積極的に学ぶ意欲のある方と出会えることを楽しみにしています。興味を持っていただけた方は、XのDMまたはWantedlyからお気軽にご連絡ください。お待ちしています！


右も左も分からない頃に参考にしていた書籍


この記事が気に入ったらサポートをしてみませんか？