AIの急速な技術進化により、「SaaS is Dead」とまで言われる議論が起きるなか、実際のプロダクト開発の現場では何が変わり、何が変わらないのでしょうか。
プロダクトマネジメントの観点からAIとSaaSの違いを理解することは、今後のソフトウェアビジネスにおいて不可欠な視点となっています。特に生成AIは、従来のSaaSプロダクト開発の手法や考え方に大きな転換を迫っており、プロダクトマネージャー(PdM)の役割や求められるスキルにも変化をもたらしています。
そこで今回は、AIを活用したプロダクト開発の最前線で活躍する方々を招き、SaaSとAIのプロダクトマネジメントにおける違いや共通点、今後のあり方について伺いました。
お招きしたのは、システムの利活用を促進するサービスやAIプロダクトを手がけるテックタッチで取締役CFO兼CPOを務める中出昌哉さん。LayerXのプロダクトストラテジーであり、日本CPO協会ファウンダーでもあるケン・ワカマツさん。そして、聞き手にはALL STAR SAAS FUNDのメンターであり、Zen and Company代表取締役として数々のスタートアップへプロダクトに関するアドバイザリーを提供する宮田善孝さんにお願いしました。
既存SaaSにAIを取り入れる視点と、AIネイティブな新規プロダクト開発の両面から、「現場の生の声」を引き出します。
SaaS企業もAIプロダクトを続々とリリースする時代に
宮田:今日は、SaaSとAIのプロダクトマネジメントにおける違いというテーマでお話を伺わせてください。まずはお二方の自己紹介と、担当しているプロダクトからお聞きできれば嬉しいです。では、中出さんから。
中出:テックタッチでCPOをしている中出昌哉です。私は金融業界出身で、野村證券でM&Aを担当した後、MBAを取得し、外資系プライベートエクイティファンドのカーライルを経て、テックタッチに入社しました。
テックタッチでは過去、事業立ち上げに携わり、新規GTM戦略や新セグメント開拓などを手がけ、振り返ると事業責任者とプロダクトマネージャーの両面を担っていたと思います。その後はプロダクトマネジメントの領域に注力し、CPOに就任。現在は今年4月にリリースした「AI Central Voice」というプロダクトの事業責任者を務めています。
宮田:テックタッチとしては、どういったAIプロダクトに取り組んでいますか?
中出:現状で大きく2つあります。一つは既存のテックタッチの祖業でもある「DAP(※Digital Adoption Platformの略。ウェブシステムやアプリケーションの使用を促進し、最適化するための技術)」のためのツールに組み込まれている「AI Hub」機能です。
これはシステム上にナビゲーションを表示するもので、フロントエンドのどこにでも要素を配置できるのが特徴です。たとえば、経費精算のワークフローにボタンを設置し、領収書をアップロードした際にそのボタンを押すとOCR読み取りが行われ、情報が自動転記されるといった使い方ができます。ほかにも、既存システムのワークフローにRAGとLLM(大規模言語モデル)を連携させ、フロントエンドから取得できるHTMLや文字情報をLLMへ受け渡すといったことも可能です。
もう一つが、新しいプロダクト「AI Central Voice」で、主に「定性情報の構造化」を行います。ユーザーの声や社内文書など、大量の文章情報を整形したうえで構造化します。ここで言う「構造化」とは、文章に複数のタグを付けていくような作業です。
たとえば、ある文章が「顧客の要望」に関するものだとして、それらに「特定の顧客セグメントから出ている」といった意味ごとにチャンク分けを行います。こうして構造化されたデータはカウント可能になり、全体のデータを投入したときにセグメント別やクロス分析による傾向値を確認できます。
さらに、RAG(Retrieval Augmented Generation、検索拡張生成)で活用する際も、大量の文章をそのまま処理するのではなく、人間が図で見るように傾向を把握し、それをベースにAIと対話できるようにしています。これにより、膨大な情報とAIがディスカッションできるような体験を目指しています。
宮田:なるほど、AIを前提にした新規プロダクトと、従来のSaaSにAIを組み込むといった観点の比較も興味深いです。今日はよろしくお願いします。それではケンさんもお聞かせください。
ケン:LayerXでプロダクトストラテジーを担当しているケン・ワカマツです。私は元々エンジニアからプロダクトマネジメントに移り、Adobe、Cisco、Salesforceといった企業でプロダクト開発を経験してきました。Salesforceでは機械学習AIプラットフォーム「Salesforce Einstein」のプロジェクトに携わり、AI技術の組み込みを担当していました。現在はLayerXでは「Ai Workforce」というLLMと生成AIを活用したプロダクト開発に取り組んでいます。
宮田:LayerXの「Ai Workforce」はどういったツールですか?
ケン:「Ai Workforce」は企業と成長を共にする生成AIプラットフォームです。ただ、従来のSaaSとAIを組み合わせたものとは一線を画していると自負していて。簡単に言うと、一つのプラットフォーム上でさまざまな業務に対応するワークフローを構築し、それをアプリケーションのように使いこなすことができるシステムです。
宮田:具体的にはどのような用途で活用されているのでしょうか?
ケン:「Ai Workforce」は人と同じように書類を読み、書き、整理し、複雑な業務をAIに任せる「AIオンボーディング」と呼んでいるプロセスを実現しています。たとえば、社内で契約書のレビューをする際には、特定情報の抽出やエクセルへの転記、稟議書作成といった一連の作業があります。こうした複数の書類をまたがる作業の自動化は難しかったのですが、AIが契約書を理解し、必要な情報を抽出して適切に転記するといったことが可能になっています。現状では、基本的にはエンタープライズ顧客向けに、特定業務プロセスの自動化に注力しています。
「SaaS is Dead」を言い換えると?AI時代のソフトウェアビジネスの変化
宮田:まずは「SaaS is Dead」の議論から伺いたいと思います。AIエージェントの登場によってSaaSの価値が低下するのではないか、という見方もあります。お二人はSaaSとAIの関係をどのように捉えていますか?
中出:この「SaaS is Dead」というフレーズは強すぎる表現ではありますが、実態としては的を射ている部分もあると感じています。特に米国市場では「AI機能を持たないソフトウェアは投資対象外」という風潮が強く、CFOとして海外投資家と会話すると、「AIの時代にどう対応していくのか」という点に会話が集中することがほとんどです。
市場は今まさに期待フェーズにありますが、ソフトウェアが価値を提供するうえで“AI Powered”であることは必須事項になっています。ここでAIへの対応を怠れば、SaaS企業はそのポジションを失いかねないでしょう。
具体例を挙げると、「AI Central Voice」のような新規プロダクトを作る過程で気づいたのですが、<yellow-highlight-half-bold>「AI時代に新規開発されたプロダクト」と「既存SaaSにAI機能を後付けしたもの」は大きく異なります<yellow-highlight-half-bold>。データの持ち方、UI、UX、必要なモジュールのすべてが違うんです。
データをAIに渡すことを前提に設計されたプロダクトは、AIのUX体験とデータの持ち方が圧倒的に優れています。既存SaaSに「ちょこっと」AI機能を足すアプローチでは、なかなか太刀打ちできない。そのため、テックタッチでも既存SaaS製品にAIを組み込みながら、「AIネイティブな競合が現れたとき、どう戦うべきか」を真剣に検討しています。これは、AIネイティブなソフトウェアを作っているからこそ想像がつくことでもあります。
共通して言えるのは、<yellow-highlight-half-bold>AIによって従来の体験が根本から変わる以上、データ設計とUX設計をゼロベースで見直すべき<yellow-highlight-half-bold>ということ。場合によっては、一から作り直したほうが早いケースもあります。
宮田:データの持ち方とUXの設計を、ゼロから考え直す必要があると。ケンさんはどう考えてます?
ケン:従来のSaaSでは、特定のペルソナに最適化された生産性の高いワークフロー、いわゆる「ハッピー・パス」を考えて、それをベースにプロダクトを設計してきました。できるだけ広い層に使ってもらい、ビジネスを拡大し、そこからバーティカルに市場に届けていくというアプローチです。
しかし、LLMや生成AIの時代では、この考え方が大きく変わりつつあります。最も大きいのは「最善のUX」を厳密に定義する必要がなくなってきていること。これにより、従来のSaaSプロダクト開発手法とは異なるアプローチが求められています。
私が最近、特に変化を感じているのはプライシングです。SaaSと新しいAIプロダクトでは収益モデルの考え方に大きな違いがあり、いろいろと悩まされるところだと感じます。
ディスカバリーからデリバリーまで…PdMの業務フローにおける変化のポイント
宮田:PdMの業務フローという観点で考えると、ミッションやビジョン策定から効果検証までの一連の流れのうち、具体的にはどのポイントで変化が起きているのでしょうか?データの持ち方などに違いはありますか。
中出:ディスカバリーのプロセスはまったく変わっていないと考えています。今でも顧客のもとへ赴き、業務内容やワークフローを理解し、A→B→C→D→E→Fというステップがあるのならば、「AからFへどう効率的に無駄なく進めるか」という価値提供の本質は変わりません。
変わったのはデリバリー側です。従来のSaaSではA→B→C→D→E→Fを順序立ててワークフローに落とし込んでいましたが、LLMの力により一足飛びに実現できるようになり、これが一気に民主化された印象です。
それこそUXも大きく変わりました。たとえば、データを蓄積した後の活用方法。以前はBIに連携してグラフで可視化する形だとしたら、今は「データが溜まっているから答えを教えて」というチャットベースのアプローチになりました。そうなれば、UXもチャットを基軸にしていく。ただし、LLMはSQL生成や数値計算が苦手なため、すぐには一足飛びには解決できない課題もあります。
顧客がフラストレーションなく正確なデータを取得できるよう、どのような組み合わせ・データの持ち方が最適かを考える必要があります。とはいえ、「今のSaaS」と「AI以前のSaaS」ではUXもデータ構造も取得方法もまったく異なります。この領域は日進月歩で、「Text-to-SQL」など、技術が急速に発展しているんですよね。PdMとしては、常に最新技術トレンドを追いかけ、ときには既存の設計を大きく変更することも必要でしょう。しかし、<yellow-highlight-half-bold>最も重要なのはディスカバリーのプロセスであり、この本質的な部分は変わっていない<yellow-highlight-half-bold>と感じています。
宮田:つまり、ディスカバリーでユーザーニーズを理解し、それを言語化して価値に落とし込むというデザイン力は今も昔も変わらないということですね。
中出:そうです。今はまさに黎明期で、常に試行錯誤しながら進むしかない。だからこそ大きなチャンスでもあり、ソフトウェア企業として腕の見せどころだと思います。
宮田:ケンさんはどう考えますか。PdMのワークフローの変化を感じますか?
ケン:PdMのワークフローとして、大きく2つの変化を感じています。まず、チーム構成が変わりました。従来はアプリケーションチーム、プラットフォームチーム、AIモデル開発チームが明確に分かれていましたが、今は「LLMエンジニア」という職種が登場し、PdMと密接に連携して開発を進めるようになっています。
「どの部分を、どのチームが担当すべきか」「どの方向性でプロダクトを進めるべきか」という境界線が曖昧になり、従来の「AIモデルを受け取ってアプリケーションに組み込む」というワークフローから、「LLMエンジニアと共同で開発する」という形に変化している。これは新しい挑戦であり、面白い変化でもあります。
宮田:昔の機械学習はパターン認識が中心で、認識されたパターンをシステム化するだけでした。ところがLLMは、チャットベースのインタラクティブな対話で自由度が高く、アプリケーションエンジニアとの共同チューニングで付加価値を生み出しやすくなったということですね。
ケン:その通りです。非常に大きな変化だと思います。
データの持ち方についても、中出さんが指摘された点に加えて、従来のSaaSは構造化データを基盤にして機械学習を行い、予測やサジェスチョンを提供していました。しかし、LLMの世界では構造化データがなくてもできることが格段に増えています。
もう一つの変化として、SnowflakeやDatabricksなどのデータウェアハウスの普及が挙げられます。これまでアクセスが難しかったデータを活用し、LLMや生成AIに連携できるようになりました。以前は自社でインテグレーションを構築する必要がありましたが、今はそのまま使えるようになってきているのも、技術の進化を表しているポイントでしょう。
AIがもたらすプライシングの変化は「バリュー=トークン」ベースへ
宮田:ユーザーへの提供価値の創出が広がるなかで、それをビジネス化するプロセスにも変化があるのではないでしょうか。特にプライシングについてはどうでしょう?現場ではどのような議論がされていますか?
中出:AIの世界では、トークン=バリューだと考えています。だからトークンベースのプライシングで勝負すべきだと思います。お客さまにとっても理解しやすく、「よくわからないのに月額料金だけ増えている」という状況より、「1回のクリックでこれだけの生産性向上」という形で価値が可視化できるほうが納得感がありますから。
たとえば、Salesforceのカウンターポジションとなる"SalesforceX"を立ち上げるなら、Salesforceがシートベースのプライシングである以上、自社はバリューベースで勝負したほうが差別化できます。Salesforceのような大企業がプライシングモデルを突然に変更することは難しく、ユーザーに混乱を招くだけです。そのため、新規事業の立ち上げ時には競合に対しても説明しやすく、お客さまにも理解されやすい、そして原価構造にも合致したプライシングが採用されるでしょう。
一方で課題もあります。使用量によって月々の請求額が大きく変動すると、従来のMRRといった指標が通じずに経営予測が立てにくくなります。ただ、この点は工夫の余地があり、「初めにトークンをまとめて購入してもらい、コミットメントを確保する」アプローチなど、さまざまな手法が考えられます。<yellow-highlight-half-bold>基本的には、トークンベースのプライシングに向かう<yellow-highlight-half-bold>と思いますし、お客さまも「効果に応じた支払い」という点で納得される傾向にあります。
宮田:ユーザー側の納得感も変わってきているのですね。従来、特に日本では稟議の通りやすさがネックとなり、固定的なコストベースのほうが説明しやすいという面がありましたが、AIの登場によってその構図も変わりつつあるということでしょうか。
中出:そう感じています。比較的、そういった会社も多いと思いますね。
宮田:ケンさんはプライシングの変化も感じているとおっしゃっていましたが、LayerXではこの観点、いかがでしょうか。
ケン:論理的にはトークンベースが理想的だと思います。実際、開発側でもAPI利用の課金はそのようになっているわけです。ただ、難しい点もあります。これは「SaaS is Dead」の延長線上の話でもありますが、AIにより直感的で使いやすいアプリケーションが増えると、必要なユーザー数自体が減少する可能性があります。
従来は10人で行なっていた業務が三人で済むようになり、極端な場合は1ライセンスで十分という状況も考えられる。その観点からも、トークンベースのプライシングが自然な流れでしょう。
ただし、特に大企業では稟議の問題があります。年間予算が固定されているなかで、「トークンを使い切ったらどうなるのか」「追加予算はどうするのか」という懸念が生じます。ユーザー数が無制限になる可能性もあり、さまざまな工夫が必要だと感じています。
プロダクト開発側の責任として、<yellow-highlight-half-bold>トークンを効率よく使えるアプリケーション設計も重要<yellow-highlight-half-bold>です。顧客が得られる生産性と消費するトークン量のバランスを最適化することが、我々の役割だと考えています。
宮田:まさにバリューベースを取るうえでの諸刃の剣といいますか……「価値を出すのであればコストもミニマイズしてください」というプレッシャーでもありますね。もっとも、この流れはすぐにでも来そうです。
PRDは未だ必要か?AIプロダクト開発における現場の工夫
宮田:ミクロな視点に移りますが、プロダクト開発プロセスでもPoC期間やPRD(Product Requirements Document、製品要件文書)の書き方など、変化が見られると思います。従来はステップ・バイ・ステップで進めていた部分を、AIでドラスティックにジャンプできる可能性もあります。現場ではどのような工夫をされていますか?
ケン:大きく2つのアプローチがあると感じています。既存の延長線上にあるユースケースであれば、PRDを作らずにすぐPoCに進むことが容易になりました。特にプロンプト・エンジニアリングはアプリケーションコードを書かなくても調整や改良ができるため、開発スピードが格段に上がっています。
一方で、AIプロダクトとして大きな変革を目指す場合は、しっかりとPRDを作成し、仕様を明確に定義する必要があると考えています。たとえば、AIエージェントのような機能を実装する場合には、従来型のプロダクトマネジメントが依然として重要です。
宮田:モデルやプロンプトのチューニングはアドホックに改善できる一方で、プラットフォームの根幹部分など静的なシステムとして提供する部分は、しっかりとPRDを作成して開発を進める。そういう棲み分けが必要なのですね。
ケン:そうですね。アプリケーションの体験部分とプロンプトで実現できる部分に重なりがあり、その境界線をどう引くかがチームごとに変わってくるのだと思います。もっともAIエンジニアの特性やレベル、経験によって最適な提供方法は変わるでしょう。
それこそ、従来のSaaSのPdMが考えてきたような、「カスタム化するべき部分」と「プラットフォームで提供すべき部分」の区分けは引き続き重要な課題です。ただ、以前は主に社外やお客さまとの直接対話から得られた情報をもとに判断していましたが、今はLLMエンジニアを通して情報を得ることも増えています。
宮田:この論点は永遠のテーマになりそうですね。立ち上げ期は「プロンプトの領域を広く取り、プラットフォームをライトに提供します」といった形でも、PMFが見えてきた段階ではシステム化へ舵を切る流れになるはず。そこから、ターゲットをエンタープライズに変えたときには、再びカスタマイズ領域を増やさなければならないので、LLM側にポーションを持たせる。そういったストーリーが描けそうです。
ここで中出さんに、既存プロダクトへのAI導入と、AI前提で新規開発する場合における違いを踏まえると、いかがでしょうか。
中出:実は今週、自分で2本のPRDを書いているところなんです(笑)。
既存プロダクトへのAI導入に関しては、それほど大きな変化はないと感じています。プロダクトが大規模で、バグを出せない環境であるほど、慎重にチューニングしていく必要がありますから。
そのうえで、LLMは「A」というリクエストに対して何が返ってくるか予測できないのが特徴でもありますよね。従来のSaaSからすると特異なシステムで、同じリクエストでもまったく異なるレスポンスが返ってくる可能性がある。そのため、大規模システムに組み込む際には慎重さが求められ、PRDをしっかり書いて計画的に進める必要があります。ただし、ケンさんが言うように、LLMエンジニアリングやAI主体の発想は常に重要です。
プロダクト開発体験で最も変わったことと言えば、エンジニアでない人でもプロダクトを作れるようになったこと。「AIエージェントを作る」という場合、プログラミングコードを書かなくても、20ステップに分けたプロンプトでフロー設計ができます。本来ならPythonで記述するところが、専門知識なしでも実現できるようになったんです。ノンエンジニアが少しコードを書いたりすることもできるようになっています。また、PoCや顧客へのカスタマイズも高速に進められるようになり、プロダクト開発のMVP段階での開発待機期間が大幅に短縮されました。プロダクト作りの体験そのものが変わっていますね。
それでも私がPRDを書き続ける理由は、「Why」「What」「How」という構成がいまだに重要だからです。特に「Why」と「What」は必須。LLMネイティブな新しいプロダクトでは「How」の部分が「コーディングなしでLLMにより可能」というものになりがちですが、実際にはもっと中間的な領域もあります。やはり中長期的視点での「How」の検討は依然として必要です。ただ、結局は、PRDの「Why」と「What」の重要性は変わっていないと思います。
プロダクトマネジメントの本質と、AI時代の新たな課題
宮田:PdMとしての変わらない本質と、変わりつつある部分について、もう少し掘り下げてみましょう。
ケン:従来と違って、PdM主体でアウトプットを出しながらバリューを発揮できているように思います。それこそアイデアがあれば、プロトタイプを作って実験してみて、それを社内で使ってもらうようなこともできますからね。実際にLayerXでは「Sales Portal」という社内向けアプリケーションを営業用に作り、活用されています。
これはLayerXのバリューの一つでもあるのですが、社内で得た体験をお客さまにも同じように提供していただきたいんですね。実際に自分たちで使ってみてプロダクト化していく。その点については変わりませんし、PdMとしてのマインドセットや行動も変わらないかな、というふうに思いますね。
中出:私もプロダクトマネージャーの根本的な役割は変わっていないと感じます。ソフトウェアとは本来、人間が行うべき煩雑なプロセスを効率化するものです。AIによってその効率化がさらに進んだだけで、本質的には同じことをしています。
お客さまを理解し、ユーザージャーニーを把握し、プロセスをどう効率化するかを考えるという基本は変わりません。ただし、MVPやPoCを高速に作れるようになり、プロダクトデプロイのスピードも上がっているなかで、意思決定のスピードやトレンド理解の重要性は増しています。業界動向を素早く把握して、迅速に対応できる人材が今後ますます求められるでしょう。「超」高速な意思決定で、PDCAサイクルを「鬼のような速さ」で回せることが必要になる一方、その空いた時間で「何をするか?」という問いも生まれています。
私自身もPRDを書きながら営業活動も行うなど、マルチタスクが可能になってきました。そういう変化のなかで、組織の在り方や、そのなかでの自分の関わり方も変わってくるのではないか、と予感しています。
ケン:組織として変わる部分では、LayerXでは「Bet AI」というバリューを掲げて、「AIを10年に一度のパラダイムシフトと捉えこの未来にBetする。」ことを追求しています。これはPdMだけでなく社内全体の考え方として浸透しています。
PdMとしては単に自分の働き方を改善するだけでなく、お客さまの働き方をどう変えていくかを考えることが重要でしょう。技術を踏まえたうえで、最終的にはユーザーに価値を届けることが使命であり、これは今後も変わらない本質だと思います。
組織のAI活用は「知識共有」と「ベストプラクティスの展開」
宮田:AI技術の急速な発展に対応するために、組織としてどのような取り組みをされていますか?個人の力量だけでは追いつくのが難しく、組織的なサポートが必要だと思うのですが。
ケン:LayerXでは、社員全員がOKRを設定する際に「LayerXの羅針盤」を参照し、そのなかから「Bet AI」や「息を吸うように他社のプロダクトや施策を調べる」といった指針を取り入れています。
たとえば、社内で新たなAIツールを調査し、全社で活用できる仕組みを構築することで「KR」を達成できる仕組みです。また、そうした取り組みを社内で表彰するプロセスもあります。つまり、社員が自ら「ファーストペンギン」となって、AI活用を組織的に推進しているのです。
中出:テックタッチも同様のアプローチです。会社全体でAIツールを使いこなすことを重視していますが、実際にはAIへの適応力に個人差があるのも事実です。同じBizDev担当者でも、数百行に及ぶ精緻なプロンプトを作成する人もいれば、簡易的な使い方にとどまる人もいます。
これは時代に適応するセンスや興味関心の差もあり、全員に均一に浸透させるのは難しいと感じています。そこで私たちの戦略としては、中央集権的にベストプラクティスを作成し、それを展開する方法を取っています。業務プロセスを理解したうえで、最適なAIツールとプロンプトを用意し、「このボタンを押すだけで使える」形で提供するアプローチです。
言わば、PdMとしての「お膳立て作戦」が一番早いだろうと。PdMが各部門の業務を理解して、それぞれにあったAIソリューションを、ベストなUXで提供する形が効果的だと考えています。セールス担当者の場合、AI自体には詳しくなくても業務プロセスは理解しているので、AIに興味がある人をピックアップし、業務を理解したうえで最適なプロンプトを共同で作成し、ほかのメンバーでも使いやすい形に整備するというやり方ですね。
日本発イノベーションを!AI「ゴールドラッシュ」の可能性
宮田:最後に、AI時代のPdMやCPOの皆様へ、ぜひ背中を押すメッセージをお願いします。
中出:ソフトウェア産業は、率直に言って、アメリカに完全敗北してきた歴史があります。AIも現在のLLM基盤を見ると同じ状況に入りつつあります。このままアプリケーションでも同様の展開になってしまうと、またも日本発のイノベーションが生まれにくい状況が続いてしまうでしょう。
しかし、今はまさに久々の本格的なチャンスだと考えています。まだ誰もベストプラクティスを完全に確立していない領域で、技術理解とユーザー体験をうまく結びつけることができれば、大きな価値を生み出せる可能性があります。
CPOやエンジニア、ビジネスサイドも含め、みんなで知見を共有し、会社の枠を超えて協力していくべきときだと思います。日本発の大きなイノベーションを起こすために、ぜひ情報交換を活発に行なって、みんなで頑張りましょう!
ケン:アメリカではこの時期を「ゴールドラッシュ」と呼んでいます。AI時代は、誰にでもチャンスがある技術革新の時代です。従来はインフラやデータの蓄積がなければ参入が難しかった領域でも、LLMの登場によって、ビジネス価値を新たに提供できれば数年でユニコーン企業になれる可能性があります。
私も中出さんと同様、さまざまなアイデアの共有や議論を通じて、この変革期を共に乗り切っていきたいと思います。ぜひ多くの方々と知見を交換できることを楽しみにしています!