機能は存在するのでしょうか? AI が SaaS に製品自体の再考をどのように強いているか

中堅企業の SaaS 企業の CEO は最近、少し前までは異例に思えたであろう状況が、ますます現実的であると感じ始めていると述べました。

最大手の顧客の 1 つが、自社のワークフローを支援する特定の新機能を求めていました。この種類の要求は、顧客にとって明らかに価値がありますが、必ずしもロードマップの先頭に躍り出るほど重要ではありませんでした。

エンタープライズ ソフトウェアではよくあることですが、タイムラインにコミットする前に、リクエストはビジネスと製品のディスカッション、設計作業、エンジニアリングの優先順位付け、テスト サイクル、セキュリティ レビューを経る必要がありました。

お客様はそれを理解してくれました。しかし、しばらく待った後、別の可能性が浮上しました。ベンダーが機能を出荷するのを待ち続けるのではなく、社内で AI コーディング ツールを使用して、問題を十分に解決できるものを独自に構築することを検討していました。

このたった 1 つのコメントは、株価が打撃を受ける中、SaaS 企業がまさにこの感情を理由に、本格的に吸収し始めたばかりの広範な変化を反映しています。

何年もの間、機能リクエストはベンダーへのリクエストでした。それはバックログに入り、他の優先事項と競合し、顧客が十分に重要であるか、ユースケースが十分に広範であれば、最終的には製品に組み込まれることになります。

その論理は今、弱まり始めています。顧客がますます、狭いワークフロー、軽量の内部ツール、またはカスタマイズされたインターフェイスを自分で生成できるようになると、従来の機能の役割が変わり始めます。そして、それが実現したら、より深い質問をする価値があります。ソフトウェア業界が歴史的に理解してきた方法でその機能は存在するのでしょうか?

機能はかつて製品でした

数十年にわたり、SaaS 企業は事前定義された機能を通じて価値を構築してきました。ロードマップは基本的に、どの機能を構築するか、顧客のどの問題点を優先するか、製品チームがどれだけ早く需要をソフトウェアに変換できるかについての一連の決定でした。

多くのカテゴリーにおいて、機能の深さと機能の速度が競合他社との差別化の核となりました。より迅速に出荷し、より多くのユースケースをカバーし、顧客の要求により効果的に対応できる企業が有利になることがよくありました。

このモデルは、ソフトウェアの作成に費用がかかり、時間がかかり、エンジニアリング能力による制約が大きかった世界では理にかなっていました。多大な投資を意味するため、機能には重みがありました。それには、計画、開発、品質保証、リリース管理、サポートが必要でした。実際に代替手段がなかったため、顧客はそのプロセスを理解しました。どうしても何かが必要な場合は、それを要求することも、カスタマイズにお金を払うことも、待つこともできます。

AI 支援開発はその方程式を変え始めます。社内チームがワークフローを記述し、その使用可能なバージョンを数四半期ではなく数日で生成できるようになると、機能の意味が薄れ始めます。機能が重要でなくなったからではなく、同じパッケージ化された形式で提供する必要がなくなったからです。

場合によっては、顧客がベンダーに機能のすべての層を構築してもらう必要がない場合もあります。必要なのは、その一部を自分たちで形成するのに十分なアクセス、柔軟性、コンテキストだけかもしれません。

機能は動的なものになる可能性があります

本当の問題は、AI が SaaS 企業の機能構築の迅速化に役立つかどうかではないかもしれませんが、実際に役立つことは明らかです。より重要な問題は、製品開発の固定単位としての機能という概念が薄れ始めるかどうかです。

長年にわたり、チームはリクエストを収集し、それらを製品要件に変換し、ロードマップにスケジュールし、広範なユーザー ベース向けの標準化された機能としてリリースしてきました。ソフトウェアがより動的に生成できる世界では、そのプロセスはますます非効率的に見えるかもしれません。

AI ネイティブ環境では、顧客は従来の意味での機能をまったく要求しない可能性があります。必要なワークフロー、必要な出力、必要な承認、関係するデータ ソース、プロセスを管理するルールを単に説明するだけかもしれません。そうすれば、プラットフォームは正式なリリース サイクルを待つのではなく、製品環境内でその機能を生成できるようになります。そのシナリオでは、機能はより流動的になります。

それは、エンタープライズ ソフトウェアの定義方法における重要な変化を意味するでしょう。この機能は、もはや製品の最小の戦略的構成要素ではなくなります。代わりに、プラットフォームは、機能をより柔軟に作成、変更、管理できる環境を提供します。

これは、価値の所在が変わるため重要です。ワークフローをオンデマンドで生成できる場合、防御可能性は分離された機能自体にありません。むしろ、安全で信頼性が高く、スケーラブルな方法でその生成を可能にするシステムにあります。

プラットフォームが本当の堀となる

これは、AI が本格的な SaaS プラットフォームを単純に無意味にする可能性が低い理由でもあります。たとえワークフローが迅速に生成できたとしても、それは依然としてはるかに大きな企業現実の中で動作する必要があります。構造化データに接続し、アクセス制御を尊重し、既存のシステムと対話し、監査可能な出力を生成し、セキュリティ ポリシーに準拠し、内部実験だけではめったに一致しないレベルの信頼性で機能する必要があります。これらは些細なことではありません。多くのエンタープライズ環境では、これらが実際の製品です。

イタイ・サギ 戦略、成長、M&A を専門とするテクノロジー企業や投資家の戦略アドバイザーであり、Crunchbase News へのゲスト寄稿者であり、経験豊かな講師でもあります。彼の顧問サービス、講義、コースの詳細については、以下をご覧ください。 SagieCapital.com。 LinkedIn で彼とつながる さらなる洞察と議論のために。

関連書籍:

図： ドム・グスマン