生成AIを使ったtoCプロダクトを立ち上げた(立ち上げている)感想
今年の春先から生成AIを利用したC向けのプロダクトの立ち上げをしています(一応役割としてはPdMですが、新規立ち上げなので目安程度)。
現時点ではα版として開発を進めていて、PMFに向けたプロダクトの価値検証や生成AIの技術検証を進めている段階です。手応えはぼちぼちいい感じで、もう少ししたら正式版としてリリースできる予定です。
まだα版開発段階ですが、生成AIを使ったC向けプロダクトの立ち上げをしてみてどんな学びがあったかをまとめています。Tipsやノウハウというより、生成AIプロダクト開発における自分たちのスタンス・考え方についてになります。
※正式版リリース・PMFに向けてチームメンバーも募集中です！記事末尾に募集要項を記載しているので、興味がある方はTwitterのDMや募集ページからお気軽にご連絡ください。
やろうとしてること
まず、どんなプロダクトを開発しているかについてです。
事業ドメインは求人領域
ざっくりいうと、チャットで求人を探せるサービス
生成AIがサービスのコア体験を支えるようなプロダクト
カスタマージャーニーの一部を生成AIで改善するアプローチではなく、バリュープロポジションを生成AIで構築するアプローチ
まだα版のため詳細は書けないのですが、チャットで会話しながら求人を探せるサービスを作っています。
4点目に書いた通り、サービスの一部の機能に生成AIを導入してみてUXを改善するものではありません(職務経歴書を自動生成する、求人の内容を要約する、カスタマーサポートとのチャットのやり取りを自動化する等ではない)。
どちらかというと、プロダクトのコア体験であるチャット部分を生成AIで構築するアプローチなので、生成AIの使い方がプロダクトの価値を大きく左右する、そんなプロダクトです。
立ち上げてみて感じたこと
生成AIを使ったプロダクト検証と技術検証は楽しい
UXもUIも技術も未知な部分があるからこそ楽しめる
でもプロダクト化するのはそこそこ大変
生成AIの使い方がプロダクトの提供価値に直結するからこそ、諸々の難易度は高いですが、大きな価値提供の可能性を検証できるので楽しみは大きいと感じています。
プロダクトの提供価値をはじめ、UXも技術もUIも基本的にわからないことだらけです。なので、地道に1つ1つIssueを検証していくしかないのですが、発見があった時の楽しさはプロダクトの立ち上げの醍醐味だなと思います。
どんなUXが最適かもわからないし、UIのスタンダードもないし、どんな技術を使えば課題解決につながるかもわからないので、全てが手探りです。
モバイルアプリないしWebサービスのデファクトスタンダードがある程度出来上がっていて、それこそ生成AIに聞けばそれっぽいUIが出てきたり、コードを書いてくれる時代だからこそ、スタンダードがあまりない領域で自分たちで最適解を探しに行くことは面白みがあるなあと。
特に今回のプロダクトについては、ターゲットユーザーの特定のジョブにおいて存在する大きな課題を生成AIを使って解決しにいく挑戦をしているので、一朝一夕でクリアできる課題ではなく、ある程度の期間で検証と改善を繰り返していくので、テーマとしても楽しいかなと思っています。
検証〜立ち上げの流れ
基本的にすべてのIssueで、2つの点を並列で検証を進めていく必要があります。
どんな価値を提供すればユーザーの課題を解決できるか(What・プロダクト面)
その価値を生成AIでどう実現するか(How・技術面)
生成AIを使わないWebサービスで、利用する技術スタックにノウハウがあるプロダクトの場合、検証したいIssueが決まれば、それを解決する機能を実装して検証をすればいいのですが、生成AIの場合まだあまりチームに知見が溜まっていないので、その機能をどう作ればやりたいことができるか自体も検証しなければいけません。
例えば、「このシーンではXXのようにユーザーに振る舞うと、ユーザーの課題を解決できるのでは」というIssueがあった場合に、生成AIでどう実装すれば理想的な振る舞いをしてくれるかが都度調査・検証が必要です。
なので、検証したいIssueに対しての技術面での調査コストがそこそこあるので、プロダクトの立ち上げ初期では、以下のようにプロダクト側のIssue検証を行いました。
検証したい項目の洗い出し
プロダクトを作らないでユーザーインタビューで検証
ざっくり粗めにプロダクトを作ってユーザーインタビューで検証
徐々にプロダクトの品質を上げてユーザーを集客して検証
プロダクト立ち上げ初期の価値検証フェーズにおいては、量的調査よりも質的調査をしたかったので、実際にプロダクトはつくらずに検証したい内容を人力オペレーションでカバーしながら検証を進めました。
その間に技術的な調査は平行して行い、プロダクト側の検証が徐々にできてきた段階で、プロダクト化しています。
また、生成AIでの実装で100%の品質を目指すとかなり時間がかかるケースがあるので、ある程度ボーダーラインを超えていればプロダクトに組み込んでリリースして様子見るというスタンスを大切にしています。
プロンプトを例に上げると、一部を変えると今回追加する要件Aは満たすようになったけど、元々のBの精度が若干落ちた、ということがあったりします。
これをAとB両方100%の精度にするためのプロンプトを調査検証することももちろんやりたいのですが、わりと時間を要するので、全体のバランスを見て着地点を判断しています。
生成AIに任せる/任せない部分
サービスのコア体験を生成AIで構築するアプローチで進めていますが、どこまで生成AIに任せるのかは悩んでいます。
すべての体験・対話の流れを生成AI中心にしていいのかはまだ検証中
このプロダクトにおける最適なUXを知っているのは我々かそれとも生成AIか
我々の方が最適解を持っている可能性が高いので、コアとなる体験は生成AI主導でありつつも、我々が補助線を引く必要があるのでは
これまではチャット形式のプロダクトを作る場合、対話の流れを自分たちで設計する必要がありましたが、生成AIを使うことで生成AIがコンテキストを読み取り、対応をしてくれるので細かい流れを設計しなくてもよくなります。
もしかすると生成AIに任せきったほうが自分たちが手を加えるより良い結果を生むのでは？いや、ある程度ハンドリングがいるのでは？みたいな行ったり来たりしてるのが本音です。
我々が細かい指示をせずとも生成AIがこれまで学習したデータから最適なタイミングで最適な対応をしてくれる期待もあります。
とはいえ、やはりプロダクト化する以上、自分たちがユーザーの声を聞く等をしてリサーチして得た学びをプロダクトに組み込んだほうがよい体験が提供できると思っています。
なので生成AIにほぼお任せでよしなにやってもらうのではなく、要所を抑えることが大切で、そのために理想の体験を設計するのが重要なのかなと考えています。
手段と目的
生成AIを使うことは手段で、ユーザーの課題を解決することが目的であることは常に意識しています。上述の通り、もしかするとユーザー体験を良くするのは生成AIメインではなく、生成AIが補助役程度の可能性もあります。
なので、課題解決/価値提供ができるのであれば、生成AIが補助になってもいいという考えを持ちつつ、それでも生成AIの持つ可能性とそれによるプロダクトへのインパクトを探索したいと思っています。
チーム体制
今のチーム体制は4人で、PO、PdM、フロントエンジニア、サーバーサイドエンジニア各1名です。
わかりやすさのため便宜上役割を書いてますが、プロダクトの立ち上げフェーズなので、割と縦横無尽に動き回っています。どこかに主軸を起きつつもフルスタックでやるのが好きな人は結構楽しめるんじゃないかなと思います。
これまでに書いた通り、技術面での調査・検証もプロダクトの成長に大きく関わるので、あまり細かい役割にとらわれず、色々コード書いたりして試していくこともとても大切かなと思っています。
色々と模索段階ですが、プロダクトは形になってきていて、これからPMFに向けてさらに改善をしていくフェーズなので、もし興味がある方はご連絡ください。
今回は抽象的な内容が多かったですが、次回はより具体的な内容も書いていければと思っています。プロダクトも近々公開できると思うので、公開できた時はぜひ触ってみてください！
この記事が気に入ったらサポートをしてみませんか？