見出し画像

AIプロダクトは、なぜ「ユーザー会」までが製品になるのか。FDEの本当の価値とは。

Taka

SaaSのプロダクトを比較するとき、昔は「星取表」がかなり機能していた。

自社に必要な機能を縦に並べて、候補となるプロダクトを横に並べる。SSOに対応しているか。API連携できるか。必要な管理機能があるか。セキュリティ要件を満たしているか。価格はいくらか。

10社に提案してもらっても、比較表を作れば、10社から5社、5社から3社、最後に1社と絞っていくことができた。

もちろん、SaaSでも実際に使わなければ分からないことはある。

それでも、「この機能が存在する」ということと、「その機能を使えばこの仕事ができる」ということの距離は比較的近かった。

ところが、AIプロダクトでは少し事情が違う。

「比較してから試す」から、「試さないと比較できない」へ

例えば10社のAIプロダクトが、全社同じように「契約書をレビューできます」と書いていたとする。

従来型のソフトウェアなら、必要な機能が実装されているかを確認すれば、ある程度は比較できる。

しかしAIの場合、「できます」の中身がかなり違う。

自社の契約書を読み込ませたとき、どこまで正確にリスクを抽出できるのか。自社独自のルールをどこまで理解できるのか。期待するフォーマットで回答してくれるのか。どの程度Hallucinationが起きるのか。

自社のデータを入れて、自社の業務で動かして、実際のアウトプットを見てみないと分からない。

モデルだけの問題でもない。

データ、プロンプト、業務設計、周辺システム、そしてHuman-in-the-loopをどこに置くかによっても結果は変わる。

つまり、従来のソフトウェアが、

比較する → 絞り込む → 試す

だったとすれば、AIプロダクトは、

試す → 初めて比較できる

に近づいている。

だからPoCの重要性が高くなる。

しかし、ここで一つ問題が起きる。

買い手も、売り手も、無限にPoCできない

10社を比較するために10社すべてPoCすればいい。

理屈ではそうなる。

しかし、現実には難しい。

ユーザー企業側は、PoCのためにデータを用意しなければならない。セキュリティレビューも必要になる。実際の業務を知っている現場の人にも参加してもらう。評価基準を決めて、アウトプットを確認する。

本業を持ちながら10社と同時にこれをやるのは、ほぼ不可能だと思う。

だから、実際にはPoCに入る時点である程度候補を絞ることになる。

そして、リソース制約があるのはAI企業側も同じである。

AIのPoCは、営業担当者がデモを見せて終わりとは限らない。

顧客固有のデータや業務を理解し、環境を整え、場合によってはSolution Engineerやエンジニアが入り、アウトプットを検証する。

すべての企業から「PoCしたい」と言われても、すべてに同じ密度で対応することはできない。

買い手も、売り手も、無限にPoCできない。

だからこそ、どの会社とPoCするのか、どの顧客のPoCにどこまでリソースを投入するのかという判断そのものが、SaaS以上に重要になっていく。

そして、仮にPoCが成功して契約できたとしても、話はそこで終わらない。

むしろAIプロダクトの場合、そこからが長い。

AIプロダクトは、導入後も試行錯誤が続く

あるユースケースでPoCをする。

うまくいく。

契約する。

導入する。

従来の感覚なら、ここから「運用フェーズ」に入る。

しかしAIプロダクトの場合、その後にも大量の問いが残る。

別の部署でも使えるのか。

違うデータを入れたらどうなるのか。

どこまでAIに任せるのか。

どこにHuman-in-the-loopを残すのか。

現場にどう定着させるのか。

ROIをどう測るのか。

新しいモデルが出たら、以前できなかったことができるのではないか。

新機能を既存の業務にどう組み込むのか。

一つのPoCに成功したからといって、その会社におけるAI活用の正解が見つかったわけではない。

むしろ、

PoC → 導入 → 試行錯誤 → 改善 → 展開 → また試行錯誤

というサイクルが続いていく。

しかも、その間にAIのパワーアップによって、AIのプロダクト自体も変わる。

昨日までできなかったことが、モデルのアップデートによって突然できるようになるかもしれない。

逆に、新しい機能が増えすぎて、数カ月前に設計した運用が最適ではなくなることもある。

AIプロダクトでは、導入した瞬間に不確実性がなくなるわけではない。

導入後も、不確実性と付き合い続けなければならない。

ここが、AIプロダクトを考える上でかなり重要なのではないかと思っている。

「何を買うか」だけでなく、「買ったあと」が重要になる

そう考えると、AIプロダクトを選ぶときに評価すべきものも少し変わる。

モデルの性能はどうか。

機能はどうか。

UIは使いやすいか。

価格はいくらか。

セキュリティは大丈夫か。

もちろん全部重要である。

でも、それだけでは足りない。

「この会社は、契約したあとも一緒に試行錯誤してくれるのか」

という問いがSaaSより、どのサービスより重要になる。

Customer Successは強いのか。

技術的な相談ができる人がいるのか。

新しいユースケースを継続的に教えてくれるのか。

新機能が出たとき、それをどう使えばいいのか学べるのか。

うまくいかなかったとき、一緒に原因を考えてくれるのか。

そして、他のユーザーが何を試し、どこで失敗し、何に成功しているのかを知ることができるのか。

AIでは、Beforeだけでなく、Afterまで含めてプロダクトを評価する必要があるのだと思う。

そして、その企業がAfterにどれくらい本気で投資しているのか。

それを象徴的に表すものの一つが、「ユーザー会」なのではないかと思っている。

AI時代のユーザー会は、単なるファンコミュニティではない

ユーザー会というと、「ユーザー同士の交流」「エンゲージメント」「ロイヤルティ」「ファン化」といった話になりやすい。

もちろん、それらも重要だと思う。

でもAIプロダクトにおけるユーザー会には、もっと実務的な意味がある。

導入後の試行錯誤を高速化するための、学習インフラである。

例えば、ある企業がAIを全社展開しようとして失敗したとする。

なぜ失敗したのか。

研修が足りなかったのか。

ユースケースを絞らなかったのか。

現場にとって使う理由がなかったのか。

Human-in-the-loopを外しすぎたのか。

逆に、別の企業では特定部署だけから始めたらうまくいったかもしれない。

別の企業ではプロンプト研修より、業務そのものを再設計した方が効果があったかもしれない。

こうした情報を、一社一社がゼロから試して学ぶ必要はない。

誰かがすでに失敗したことなら、その失敗から学べばいい。

誰かが新しい使い方を発見したなら、それを試してみればいい。

ユーザー会が機能していれば、一社の試行錯誤を他社が利用できる。

そしてAIの場合、この情報の「鮮度」がかなり重要になる。

1年前の成功事例より、先月の失敗談

従来型SaaSなら、2年前に書かれたBest Practiceの記事が今でも十分役に立つことがある。

AIでは、同じとは限らない。

モデルが変わる。

機能が増える。

プロンプトの常識が変わる。

以前は難しかったユースケースが、突然現実的になる。

ユーザー側の使い方もどんどん洗練されていく。

だからAIプロダクトでは、完成されたCustomer Storyだけでは情報が足りなくなる。

企業のWebサイトには、

「導入によって生産性が30%向上しました」

「年間○時間削減しました」

といった綺麗な成功事例が並ぶ。

もちろん、それも参考になる。

でも実際にAIを運用している人が知りたいのは、

「何をやったら失敗したのか」

「どこまでAIに任せたら危なかったのか」

「どの部署では定着しなかったのか」

「PoCではうまくいったのに、本番で何につまずいたのか」

「最近のアップデートで、何が変わったのか」

といった話だったりする。

こういう情報は、企業公式のCustomer Storyにはなかなか載らない。

しかしユーザー同士なら話せる。

場合によっては、1年前に綺麗に編集された成功事例より、先月ほかの会社が経験した失敗談の方が価値がある。

AI時代のユーザー会は、成功者をステージに上げて称えるだけの場所ではない。

現在進行形の成功と失敗を持ち寄り、参加者全体の試行錯誤を少しだけショートカットする場所になっていくのだと思う。

AI企業も、ユーザー会に投資しなければ生き残れない

これはユーザー企業にとってユーザー会が便利、というだけの話ではない。

AI企業側にとっても、Afterへの投資はかなり重要になると思う。

どれだけ性能の高いAIを作っても、顧客が使いこなせなければ価値は生まれない。

価値が生まれなければ、利用量は増えない。

新しいユースケースにも広がらない。

Expansionも起きない。

そして、いずれ更新されなくなる。

AI企業にとって、「売る」と「使ってもらう」の距離は、むしろ従来型SaaSより遠くなる可能性がある。

だから、良いAIを作って営業力で売れば終わり、では生き残れない。

顧客が導入後に試行錯誤するところまで含めて支援する必要がある。

ただし、ここでもリソース制約が出てくる。

100社の顧客がいれば、100社すべてに大量の人員を張り付けることはできない。

だからこそ、ユーザー会が効いてくる。

一社で見つかったBest Practiceを、その一社だけに閉じない。

一社の失敗を、ほかの99社にも共有する。

さらに企業がすべて教えるのではなく、ユーザー同士でも知識を交換してもらう。

つまりユーザー会には、アフターフォローを一対一から一対多へレバレッジする機能がある。

営業イベントには大量の予算を使っている。

広告も出している。

展示会にも出ている。

PoCまでは手厚く支援してくれる。

でも、契約したあとのユーザーが継続的に学べる場所がほとんどない。

そういうAI企業があれば、私は少し不安になる。

逆に、ユーザーが定期的に集まり、企業側も人とお金を出し、新しいユースケースや失敗を共有し、ユーザー同士の学習を支援している。

それは、

「私たちは売った後にも投資します」

という姿勢を、営業資料ではなく実際の投資行動で示している。

だからユーザー会の活発さは、そのAI企業がAfterにどれだけ投資しているのかを見る、一つのProxyになると思う。

そして、FDEはその循環の中心にいるのかもしれない

ここで、昨今よく聞くようになったForward Deployed Engineer、FDEについても考えたい。

最近はさまざまな企業が「FDE」という言葉を使い始めている。

ただ、私はFDEを少し狭く捉えている。

自社プロダクトを持つ企業のエンジニアが顧客の現場に入り、顧客固有の課題を解きながら、そこで得た知見を自社プロダクトの改善へ戻す。

これがFDEなのではないかと思う。

だから、私の定義では、単にエンジニアが顧客の現場に入ることとFDEは同じではない。

自社プロダクトを持たないコンサルティング会社やSIer、SES企業が、自社のエンジニアを顧客先に配置して「FDE」と呼ぶケースも出てきている。

もちろん、その仕事自体に価値がないという話ではない。

ただ、私はそれをFDEとは少し違うものとして考えている。

違いは、「顧客先で働いているか」ではない。

顧客先で得た知見が、自社プロダクトへ還流するループを持っているか。

ここが重要なのではないかと思う。

FDEは複数の顧客の現場に入る。
それも、導入後だけでなく、導入前のPoCのお客様の現場にも入る。

そこで、

「このユースケースでは、みんなここで詰まる」

「この機能が足りない」

「この業務では、こう使うとうまくいく」

「プロダクト側が想定していなかった使われ方をしている」

という知見を得る。

そして、それを自社のエンジニアリング、Product Management、Product Marketingなどへ戻す。

「顧客からこの要望が来ました」で終わるのではなく、複数顧客の現場で得たインサイトを抽象化し、どこまでプロダクトとして解くべきなのかを考え、ロードマップに反映していく。

これができれば、一社のために行ったアフターフォローが、自社プロダクトそのものの改善につながる。

一社のために行ったPoCの結果から得られるインサイトをプロダクトの改善につなげることができる。

ちょっと話が逸れるが、AI時代の副産物として、プロダクト改善がいままでより短いスパンでよりアジャイルになる。

いままではマーケットインのプロダクト改善をするときは、導入後のお客様から得たインサイトをプロダクトに反映させることが多かった。つまり、プロダクトの改善ループは導入後に始まる。

しかし、導入前のPoCが増え、FDEが活躍すればするほど、導入前に得られるインサイトが多く、導入前のお客様から学んだことをプロダクトの改善に活かせるのである。つまり、プロダクトの改善ループの距離が以前よりどんどん近づいているのである。

これはFDEだけでなく、プロダクトマーケティングやエンジニアのチームにも大きく影響する話であり、また別記事で深堀りたいと思う。

話をもどす。

そして私は、FDEにはもう一つ重要な役割があると思う。

ユーザー会を盛り上げることである。

FDEが、顧客とプロダクトとユーザー会をつなぐ

FDEほど、ユーザー会で話すのに適した人はいないかもしれない。

複数のお客様の現場を見ているからである。それも、導入前のPoCの情報が多い。

もちろん、個別顧客の機密情報を話すことはできない。

それでも、複数社を支援する中で見えてきたパターンなら共有できる。

「最近、このユースケースでPoCを検討する企業が増えています」

「こういったPoCでは、この部分でつまずくケースが多かったです。これはきっと導入されているみなさまのXXの活動でも活かせるインサイトです」

「こういう設計にすると比較的うまくいっています」

「この課題を複数のお客様から聞いているので、現在ProductやEngineeringと改善を検討しています」

「こうした背景から、今後ロードマップとしてこの方向を考えています」

こういう話をFDEがユーザー会でする。

するとユーザー側は、単に新機能の説明を聞くだけではなく、

自分たちの試行錯誤が、他社の試行錯誤やプロダクトの未来とどうつながっているのか

を知ることができる。

さらに、PoCでまだ検証段階の他社の最新の試行錯誤の情報を得ることができる。

そして、そこからまた別のユーザーが、

「うちでは少し違って、こういう問題があります」

とフィードバックする。

その情報をFDEが持ち帰る。

すると、

顧客(PoC) → FDE → Product → ユーザー会 → 別の顧客 → FDE

という循環ができる。

この循環が高速で回る会社は強いと思う。

FDEとユーザー会は、それぞれ別の流行ではない。

どちらも、顧客の試行錯誤を一社の中に閉じず、自社プロダクトと他の顧客へ還流させる仕組みとして捉えることができる。

AIプロダクトの不確実性が高いからこそ、この循環そのものが競争優位になるのかもしれない。

ユーザー会を見ると、そのAI企業の思想が少し分かる

だから私は、これからAIプロダクトを選ぶとき、製品ページだけを見るのでは足りないと思っている。

その会社のユーザー会も見てみたい。

どれくらいの頻度で開催しているのか。

会社側から誰が参加しているのか。

マーケティング担当者だけなのか。それともFDEやProduct、Engineeringの人たちまで出てくるのか。

綺麗な成功事例だけが発表されているのか。

それとも、現在進行形の試行錯誤まで共有されているのか。

ユーザーから得たフィードバックが、どのようにプロダクトへ戻っているのか。

そこを見ると、その会社が顧客を、

「契約を取るまでの相手」

と考えているのか、

「一緒にプロダクトを進化させる相手」

と考えているのかが、少し見える気がする。

AIプロダクトは、買って終わりではない。

プロダクト自体も変わる。

正しい使い方も変わる。

ユーザー側も試行錯誤し続ける。

だから、AIプロダクトの選定では、「今、どの製品が一番優れているか」だけでは足りなくなっていく。

この会社は、売ったあとも一緒に試行錯誤してくれるのか。

このユーザーコミュニティにいれば、他の人の成功と失敗から学び続けられるのか。

そして、自分たちの試行錯誤もまた、プロダクトや他のユーザーへ還元されていくのか。

「何を買うか」と同じくらい、「誰と試行錯誤を続けるか」。

AIプロダクトでは、そんな選び方が以前より重要になっていくのだと思う。

だから「ユーザー会」は、もはや製品の外側にあるおまけではない。

AI時代には、ユーザー会まで含めて一つのプロダクトなのかもしれない。

いいなと思ったら応援しよう！