市場が厳しさを増すとき、唯一生き残るSaaSの指標
サブスクリプション型ソフトウェア企業のライフサイクルには、必ずある瞬間が訪れる。メトリクスのダッシュボードが、ツールではなく症状のように見え始める瞬間だ。デイリーアクティブユーザー数、機能の開封率、セッション時間、モジュールの採用状況、四半期ごとのNPS。あらゆるものが計測される。あらゆるものが緑色で表示される。それでも、契約は更新されない。
活動量と価値のあいだにあるこのズレは今に始まったことではない。だが、市場の圧力が求めるスピードで修正されているわけでもない。企業の購買担当者がテクノロジー予算のすべての行に本格的な精査を加えるいま、多くのソフトウェアプロバイダーが自らに正直に問いかけることを避けている問いがある。それは、自社のプラットフォームによってクライアントが実際に収益を上げているのか、それとも、誰も解約する時間がなかっただけのツールを使い続けているにすぎないのか、という問いだ。
フォネクサのグローバルディレクターであるデイビッド・ピッカードは最近、Forbes Technology Councilに一つの論考を発表し、そのズレを自己評価のための問いとして端的にまとめた。「もし自分がクライアントだったら、自社のソフトウェアを使うだろうか？」という問いかけだ。この挑発が効果的なのは、それを支える診断が正確だからである。SaaS業界は活動指標の文化を構築してきた。その文化は社内のロードマップや投資家向けプレゼンテーションには機能するが、クライアントの経済的体験との相関はますます弱くなっている。
成功指標が内部向けになるとき
問題は測定することではない。何を、なぜ測定するかを選ぶことにある。
バニティメトリクス——デイリーアクティブユーザー数、ログイン数、採用された機能の数——は、プロダクトの初期段階においては正当な役割を持っている。ソフトウェアが使われているかどうか、オンボーディングが機能しているか、フィードバックのラウンドを正当化するに足るエンゲージメントがあるかを示す指標として機能する。誤りが生じるのは、それらの指標が経済的成果の指標への移行を経ないまま、経営幹部のダッシュボードの中心へと移行してしまうときだ。
あるクライアントは高い利用パターンを示しながら、同時にプラットフォームを導入する前よりも少ない収益しか生み出していないことがある。ソフトウェアは設定に時間を食い、チームが習熟していないインテグレーションを要求し、誰も正しく解釈できないレポートを生成する。キャンセルのプロセスは遅く、組織的な慣性は強力であるため、解約率は何ヶ月も健全に見える。しかし契約は更新されず、その理由を説明しなければならないとき、答えは社内のメトリクスダッシュボードの中にはない。
これには、あまり明らかでない結果がある。プロダクトチームが、測定されているものに向けて最適化を始めるのだ。成功指標が機能の採用率であれば、機能が追加される。セッション時間であれば、必要でなくてもユーザーをプラットフォーム内に留めるフローが設計される。NPSであれば、アンケートのタイミングに合わせて知覚が管理される。活動指標に向けた最適化は、より複雑なプロダクトと、実質的なリターンが低下したクライアントを生み出す。 悪意からではなく、インセンティブの構造がクライアントの必要とは異なる方向を指しているからだ。
ピッカードが「バニティ開発」と呼ぶもの——クライアントのニーズではなく、市場のトレンド、競争上のプレッシャー、または社内の技術的親和性によって推進される機能を構築すること——に関する彼の主張は、まさにそのメカニズムを描写している。結果として生まれるのは、複雑さの層を積み重ねながら、そのどれもクライアントの収益、効率性、コスト削減を実証可能な形で動かさないプラットフォームだ。
誰も監査しないインセンティブ構造
バニティメトリクスの増殖の背後にあるのは無邪気さではない。それらを体系的に生み出すインセンティブ構造があり、少なくとも三つの水準で同時に機能している。
第一の水準は、資金調達サイクルだ。SaaS企業の初期から中期にかけての資金調達ラウンドは、歴史的にユーザー成長指標、月次経常収益（MRR）成長率、市場拡大の見通しと結びついてきた。それらの指標は活動データで捉えられる。一方、クライアントの経済的リターンは測定に時間がかかり、クライアントが必ずしも共有しないデータへのアクセスを必要とし、シリーズBのピッチデックには明快に現れない。結論は予測可能だ。チームは次のラウンドの評価を動かす指標に向けて最適化し、必ずしも提供した価値を反映する指標に向けてではなくなる。
第二の水準は、カスタマーサクセスチームの構造だ。長年にわたり、この機能は技術的・関係的サポートとして設計されてきた。実装の問題を解決し、チケットに対応し、オンボーディングを管理する。そのモデルでは、チームのパフォーマンス指標はクライアントの満足度と維持率であり、クライアントの収益拡大ではなかった。その結果、摩擦を検知するのに適した立場にありながら、プラットフォームがクライアントのビジネスに与える財務的インパクトを定量化するためのツールも権限も持たないチームが生まれる。
第三の水準——そして変化に最も抵抗するもの——は、プロダクトチームと日常業務を行うクライアントとの距離だ。ロードマップの意思決定は、ユーザーインタビュー、プロダクト内の行動分析、競合ベンチマーキングによって形成される。クライアントの財務諸表、運用効率の指標、あるいはプラットフォームがトランザクションコストを削減したかコンバージョン率を向上させたかについての誠実な評価によって形成されることは稀だ。その距離が、経済的な問題ではなく知覚された問題を解決する機能を生み出す。
ピッカードは、彼が「バニラ化」と表現するものをその解決策として指摘している。クライアントが特定の機能を求めるとき、プロダクトチームはその要求を一般化して、他のセグメントへとスケールし、将来のユースケースに対して十分な柔軟性を持つようにすべきだというものだ。原則は正しい。しかし、この議論が直接解決しない前提条件がある。一般化された機能が価値を生み出すかどうかを知るためには、クライアントにとって価値が何を意味するかについての運用上の定義を持っている必要があるということだ。その定義がなければ、一般化は競合他社の模倣と同様に複雑さを生み出す可能性がある。
SaaSプロバイダーの財務的健全性の先行指標としてのクライアントリターン
クライアントのリターンが最終的にSaaSプロバイダーの財務的健全性の最良の先行指標となる構造的な理由がある。それを明示する価値がある。
サブスクリプションビジネスモデルは二つの変数に依存している。既存収益の維持と、既存クライアントベース内での拡大だ。純収益維持率（NRR）——業界で最も注視される指標の一つ——は、まさにそれを測定する。解約、ダウングレード、拡大を組み込んだ後、アクティブクライアントからの収益が成長しているか、維持されているか、縮小しているかを示す。100%を超えるNRRは、既存のクライアントベースが利用を拡大していることを示しており、これは通常、新規顧客獲得コストを回避できるため、最も効率的な成長の指標となる。
その数値は、クライアントへの実証可能な経済的リターンなしには維持できない。プラットフォームを通じて増分収益を生み出せていない、コストを節約できていない、または運用効率を得られていないクライアントには、契約を拡大する経済的理由がない。慣性によって一度か二度のサイクルは更新するかもしれないが、拡大のロジック——NRRを100%の閾値を超えて押し上げるもの——は、クライアントがソフトウェアを肯定的なビジネス成果に結びつけていることを必要とする。
因果連鎖はそれゆえ明確だ。クライアントリターン→契約維持→支出拡大→健全なNRR→プロバイダーの評価向上。その連鎖の中間リンク——維持と拡大——だけを測定し、最初のリンクを監査しなければ、市場が次の更新サイクルで修正する堅固さの幻想を生み出す。
ピッカードは、利用ベースの収益モデルにおいて、プラットフォームへのクライアントの支出増加は、そのクライアントがシステムを通じてより多くの収益を生み出していることの症状であるべきだと指摘することで、同じ方向を示している。クライアントがプラットフォームへの支出を倍増させるなら、その利益はより大きな倍数で成長すべきだ。それが起きないなら、モデルは価値を提供していない。成長していない収益から増大する割合を取り込んでいるにすぎない。
記事が言及するマネージドサービスは、うまく設計されていれば、そのサイクルの加速装置として機能する。実装から実証可能なリターンまでの時間を短縮し、それがクライアントの利用拡大の決断を加速させる。記事が明示的には主題化していないが現実のリスクは、マネージドサービスが、十分に直感的でないか、成果を生み出すために過剰な介入を必要とするプラットフォームへのパッチになってしまうことだ。その場合、サービス層はプロダクトが排除すべきだった複雑さを無期限に補助する。
見えている数字の前にあるもの
クライアントのリターンをすべての中心に置くという議論は、その診断において正しい。しかし、その実装は、SaaS企業のほとんどがまだ解決していない前提条件に直面している。そのリターンを体系的かつ逸話的でない方法でどう測定するか、という問題だ。
クライアントの成功事例はすべてのソフトウェア企業に存在する。それらは営業プレゼンテーションと推薦文ページの燃料だ。問題は、事後的に語られた成功事例は商業的価値を持つが、運用上の有用性はほとんどないということだ。何がリターンを生み出したか、どのような条件で再現可能か、類似したプロフィールを持つ他のクライアントではなくそのクライアントで可能にした変数が何かを示さない。
セグメント間で比較可能で、リアルタイムで更新され、プロダクトとカスタマーサクセスの意思決定に情報を与えるクライアントリターンの測定方法論を構築するには、クライアントがデフォルトでは共有しないデータへのアクセスが必要だ。プラットフォームが、システム内の行動だけでなく、クライアントのビジネス指標へのダウンストリームの影響を捉えるために計装されている必要がある。そして、プロダクトチームとカスタマーサクセスチームが、更新を評価する経営幹部の購買担当者と同じ経済的言語を話す必要がある。
バニティメトリクスに関する議論で誰も語っていない摩擦は、まさにこれだ。SaaS企業がクライアントリターンを測定したくないのではない。データインフラ、クライアントとの情報交換協定、そのデータをロードマップのシグナルに変換する分析能力が、中規模プロバイダーの大多数において構築されていないのだ。経営幹部のダッシュボードを変えることは簡単だ。そのダッシュボードに情報を与える情報アーキテクチャを変えることは、何年もかかる作業だ。
このことはピッカードの論点を無効にしない。むしろ強化する。しかし、真の問題をあるべき場所に置く。何を測定するかを選ぶことではなく、重要なことを体系的に測定する能力の問題として。その能力を最初に構築することに成功したSaaS企業——クライアントの成果への可視性を可能にするクライアントとの協定を含めて——は、指標の名称を四半期報告書で変えるだけでは複製できない優位性を持つことになる。
メトリクスのダッシュボードは、プラットフォームが実証可能なリターンを生み出していなければ変わらない。しかし、そのダッシュボードを生み出すアーキテクチャ——そしてそれを誠実に解釈できるチーム——こそが、予算の再交渉を生き延びるプロバイダーと、次の更新サイクルに届かないプロバイダーを分ける投資だ。
