IT・SaaSで詰まる「拡張×進化」 — 機能を増やしても解約が止まらない理由｜FUKUMO LABO 連載 #5

SaaSは「機能が多ければ勝つ」のではない。機能追加は、解約を止めるほどには効かない。

この記事を読み終えると、IT・SaaSの詰まり構造を「機能の差別化不足」ではなく「レバレッジを生む構造の欠如」として捉え直せる。そして自社プロダクトのレバレッジ・ポイントを設計し直す視座が手に入る。

私はIT・SaaS事業の経営者と話す機会が増えてきた。BtoB SaaS、BtoCアプリ、業務システム、開発ツール—プロダクトは様々だが、成長後期の症状は共通する。

「機能を増やしているのに、解約が止まらない」
「顧客成功(CS)を強化しても、1顧客あたりの工数が増える一方」
「PMF後、ARR成長率が鈍化した」
「競合と機能を比べると勝っているのに、顧客が大手に流れる」

話を聞いていて感じるのは、彼らが努力を怠っているわけではまったくない、ということだ。開発も営業もCSも、それぞれの持ち場で全力を尽くしている。ロードマップは要望で埋まり、リリースノートは毎月更新されている。それでも詰まる。

こうした症状への診断として現場でよく聞くのは「機能の差別化が足りない」だ。だが私の見立ては違う。SaaSという事業の構造上、機能差別化に頼れる範囲には上限がある。上限のある軸でいくら努力を積んでも、詰まりは解消しない。欠けているのは別の原則だ。SDMP理論で読み解く。

1.SaaSの誤解—「機能が多ければ勝つ」はなぜ罠か

SaaS業界の一般通念は、「機能の幅と深さで競争する」だ。競合分析シートを作り、機能比較表を顧客に提示し、「うちはここができます」と売る。

これはPMF前の探索フェーズでは有効だ。顧客の困りごとを機能で解決する、というシンプルな価値が効く。

だがPMF後、スケール期に入ると、機能では勝負がつかない構造に変わる。なぜなら、SaaSの機能はコピーされやすいからだ。競合の良い機能は6ヶ月-1年で模倣される。大手SaaSは既存資産(顧客基盤・ブランド・統合プラットフォーム)をテコにして、追いついてくる。

そして顧客は、機能の細かい違いより、「乗り換えコスト」で残るか離れるかを決める。機能で勝っても、乗り換えコストが低いと解約は止まらない。

この構造は、私が自衛隊で学んだ軍事理論の転換と重なって見える。これまでの軍事理論の多くは、一つの正面にリソースを最大限つぎ込んで勝つ、いわば個別最適を前提としていた。決定的な一点に戦力を集中し、その局面で勝ち切る。私が指揮幕僚課程(CGS)の教官として指揮官候補生に戦術を教えていた頃も、集中は教育の柱の一つだった。だがVUCAと呼ばれる時代の様相は違う。複数の正面に同時にリソースを配らなければならず、どの正面にも十分な戦力を割けない状況が当たり前に起きる。そこで問われるのは個々の戦いの巧拙ではない。目的は何か。何を達成すべきか。各局面でどこまでやるか。全体を俯瞰した、全体最適の判断である。

SaaSの開発現場は、まさにこの複数正面の戦いだ。新機能開発、既存機能の改善、保守・バグ対応、サポート、営業からの個別要望。限られた開発リソースは、常にこの5つの正面に取り合いされている。どの正面にも「やるべき理由」があり、どの正面にも十分な人員を割けない。このとき機能比較表を眺めて「競合より機能が足りない」と焦るのは、一つの正面の戦況だけを見て増援を叫ぶ指揮官に似ている。問うべきは、プロダクト全体として何を達成すべきか、そして各正面でどこまでやれば十分か、だ。

機能を増やしても解約が止まらない背景には、典型的な悪循環がある。解約の兆候が出ると、営業やCSが顧客の不満を持ち帰る。「あの機能がない」「ここが使いにくい」。開発はそれに応えて機能を足す。だが、こうした要望の多くは解約を検討している顧客——つまり主軸から外れつつある顧客から出てくる。その声に応えるほど、プロダクトは主軸顧客にとって複雑になっていく。画面が増え、設定項目が増え、オンボーディングが重くなる。CSの工数は顧客ごとに膨らみ、対応は遅れる。そして解約面談で顧客が口にするのは、決まって「使いこなせなかった」という言葉だ。機能を足した努力そのものが、使いこなしの障壁を高くする方向に働く。機能追加が解約に効かないどころか、逆方向に作用することすらあるのは、このメカニズムによる。

SaaSが詰まる本質は、「機能の差別化不足」ではなく、「乗り換えコストを高めるレバレッジ構造」を持っていないことにある。そしてレバレッジ構造の設計には、複数正面を俯瞰する全体最適の視点が要る。

2.原則—速度・レバレッジ・差別化の3つの正体

リソース配分の判断には、身体感覚がある。戦闘ヘリの操縦士だった10年間、飛行中の判断の中心には常に燃料管理があった。燃料は有限で、空中で足すことはできない。残りの燃料で何を優先し、何を諦めるか。任務の達成と帰投の余裕を天秤にかけ、刻一刻と減っていく数字を見ながら決め続ける。SaaSの開発リソースも同じだ。「足せない」前提に立ち、何に使い、何に使わないかを決める。その配分基準を与えるのが、これから述べる原則の組合せである。

SDMPの7原則のうち、SaaSが組み合わせるべき3つを確認する。

2.1③速度(Speed)

SaaSにおける速度は、(1)機能リリース速度、(2)顧客フィードバックを製品に反映する速度、(3)顧客成功(CS)対応速度、の3つに分かれる。

PMF前は(1)リリース速度が主役だ。PMF後は(2)フィードバック反映と(3)CS対応が重要になる。だが、これら3つの速度を上げても、それだけでは解約は止まらない。速度は必要だが、単独では効きにくい。

理由は第1章の悪循環を思い出せばわかる。方向の定まらない速度は、複数正面への応答を一律に速くするだけで、プロダクトの複雑化を加速させる。まずい方向に速く進めば、まずい場所に早く着く。速度は、後述する差別化とレバレッジに方向を与えられて、初めて武器になる。

2.2⑥レバレッジ(Leverage)

レバレッジとは、少ない資源で大きな効果を生む構造の活用だ。SaaSにおけるレバレッジは、4つに整理できる。

• データ蓄積のレバレッジ:顧客が使うほど蓄積されるデータ。解約すると失われる。

• - ワークフロー統合のレバレッジ:業務プロセスに組み込まれた状態。解約すると業務が止まる。

• - ネットワーク効果のレバレッジ:他社・他チームとの連携で価値が生まれる構造。解約すると連携が切れる。

• - 学習コストのレバレッジ:顧客のチームが使い方を習得した状態。解約すると再教育が必要。

これらはどれも「顧客の乗り換えコストを高める」構造である。機能の差別化より、レバレッジ構造の方が解約率に効く。

注意したいのは、これらが「顧客を縛る仕掛け」とは違うという点だ。データ蓄積もワークフロー統合も、顧客が使い込むほど顧客自身の得る価値が増える構造であり、乗り換えコストはその副産物として高まる。顧客価値と切り離した囲い込みは、不満を溜めながら残る顧客を生み、いずれ一斉解約という形で崩れる。レバレッジ構造は、顧客価値の上に建てるものだ。

2.3②差別化(Differentiation)

SaaSの差別化が生まれる場所は、機能の差より一段深いところにある。「価値軸の差」だ。第2巻(スタートアップ)と同じ命題だが、SaaSではより明確に現れる。

例えば、同じ「会計SaaS」でも、「経理担当者の業務効率化」と「経営者の意思決定支援」では価値軸が違う。機能セットは重なるが、訴求する顧客像、UI、通知、レポート設計が全て異なる。価値軸で差別化されると、競合はそもそも追ってこない。

価値軸の設定は、第1章で述べた「目的は何か」の問いそのものでもある。経理担当者の効率化が目的なら、達成すべきは入力時間の短縮であり、各機能はそこまでやれば十分となる。経営者の意思決定支援が目的なら、達成すべきはレポートの即時性と一覧性であり、入力機能は合格点でよい。目的が定まると、各正面の十分ラインが定まる。

3.フレームワーク—SaaSの「3層レバレッジ」で解約を止める

3原則をどう組み合わせるか。SaaSに特化した構造に落とす。

3.1第1層:価値軸の差別化(誰のためのSaaSか)

主軸顧客像を明確化する。ここを集中の中心に置き、価値軸を1〜2軸で決める。

例:
- BtoB SaaS A:「中堅製造業の経理部長」が主軸/価値軸=「現場と経営のデータブリッジ」
- BtoCアプリB:「30代の副業ワーカー」が主軸/価値軸=「副業収入の確定申告の自動化」

主軸顧客が明確だと、機能追加の判断基準が持てる。「主軸顧客の価値軸を補強する機能か?」がフィルターになる。主軸外の顧客の声に応答すると、機能が拡散して集中が失われる。

これは軍事でいう「目的の明確化」と同じ働きをする。複数の正面に引き裂かれる開発リソースに対し、達成すべきものの順序を与えるのが第1層だ。順序がなければ、5つの正面はすべて「等しく重要」になり、声の大きい正面が勝つ。それを戦略とは呼べない。成り行きである。

3.2第2層:レバレッジ構造の設計

主軸顧客に4つのレバレッジ構造を組み込む。これが⑥レバレッジの主戦場である。

• データ蓄積:顧客が使うほど、顧客自身のデータが自社プラットフォームに蓄積される構造

• - ワークフロー統合:顧客の業務プロセスに自社SaaSが「呼吸の一部」として組み込まれる構造

• - ネットワーク効果:顧客と顧客の顧客・取引先が自社SaaS上で連携する構造

• - 学習コストの高さ:顧客のチームが自社SaaS固有の使い方を習得していく構造

このうち1つでも強く効くと、解約率が下がる。4つすべてに効かせるのが理想だが、1つに集中するだけでも効果は出る。

どれに集中するかは、主軸顧客の業務の性質から決まる。日次で使う業務ツールならワークフロー統合が効きやすく、データが資産になる領域ならデータ蓄積が効く。複数の企業や部門をまたぐ業務ならネットワーク効果、専門性の高い操作を伴うなら学習コストだ。第1層で主軸顧客が決まっていれば、この選択は迷わない。逆に第1層が曖昧なまま第2層を設計しようとすると、4つすべてに中途半端に手を出して、どれも効かない。

3.3第3層:速度の機動的応答

レバレッジ構造を維持・強化するために、速度を活用する。機能リリース、フィードバック反映、CS対応の3つを速くする。

ただし、速度の方向は第1層(差別化)と第2層(レバレッジ)を補強する方向に限定する。主軸外の顧客の要望に応答する速度は、抑制する。これが集中ありの速度である。

全体最適の判断とは、結局のところ「各正面でどこまでやれば十分か」を決めることだ。保守は事故が起きないラインまで。営業要望は主軸顧客の価値軸と重なる範囲まで。新機能はレバレッジ構造を強める順に。満点を狙う正面を絞り、他は合格点で止める。この「十分ライン」の設定が、結果として速度を生む。すべての正面で満点を狙う組織は、すべての正面で遅くなるからだ。燃料計を見ずに全タスクを引き受ける操縦士はいない。開発ロードマップにも、同じ規律が要る。

4.具体例—3つの仮想SaaS

具体例で構造を確認する。いずれも特定の実在企業を指さない。業界の典型構造を、私の観察範囲で抽象化した3社である。

4.1 BtoB会計A社—データ蓄積レバレッジで解約を起きにくくする

A社は中堅企業向け会計SaaS。価値軸は「現場と経営のデータブリッジ」と定義。機能では大手会計ベンダーに負ける部分もあるが、顧客が使うほど顧客自身の経営データがA社プラットフォームに蓄積される構造を持つ。

3年使った顧客が別ベンダーに乗り換えると、(1)過去3年の経営データの再構築コスト、(2)チームの再教育コスト、(3)経営会議資料の様式変更、が発生する。これがレバレッジ・コストである。

重要なのは、このコストが顧客への嫌がらせとして働いていない点だ。3年分のデータ蓄積は、顧客自身の経営判断の精度を上げている。顧客価値と乗り換えコストが、同じ構造から生まれている。

結果としてA社は、機能数では大手に劣るが、一度導入した顧客が使い込むほど離れにくくなり、解約の話そのものが出にくい。機能の数で競り合わずに、データ蓄積レバレッジで勝っている例である。

4.2業務SaaS B社—ワークフロー統合で業務に呼吸させる

B社は中堅小売向け在庫管理SaaS。価値軸は「店長の朝の30分を守る」と定義。朝の在庫確認・発注作業を、ボタン1つで完了させるUIに集中投資。

このSaaSを解約すると、店長の朝は以前の手作業の段取りに逆戻りする。つまり、店長個人の業務リズムに「呼吸の一部」として組み込まれている。これがワークフロー統合のレバレッジである。店長は毎朝このSaaSを開くことをもはや意識すらしない。そして意識されない道具は、比較検討の土俵にも載らない。競合の機能比較表が、そもそも店長の手元に届かないのだ。

機能はシンプルだが、業務に深く組み込まれているため、解約判断が難しい。結果としてB社は、営業リソースの軸足をCS強化へ移し、既存顧客との関係を深めて売上を伸ばす構造に転換できた。

4.3 BtoCアプリC社—学習コストレバレッジでリテンションを高める

C社は副業者向け確定申告アプリ。価値軸は「副業の確定申告を30分で完了させる」。

特徴的なのは、1年目より2年目、2年目より3年目の方が操作が速くなるUI設計だ。過去年度のデータを引き継ぎ、「今年も同じ」ボタンが大半の項目を自動入力する。つまり顧客は、使うほど自社アプリ固有の使い方に慣れる。これが学習コストレバレッジである。

別の確定申告アプリに乗り換えると、(1)過去データの移行コスト、(2)UI操作の再学習、が発生する。機能は似ていても、顧客は残る。操作が年々速くなる体験は、顧客にとっては単なる快適さにすぎない。だが事業の側から見れば、時間とともに太くなるリテンションの構造である。レバレッジ構造の良い設計では、こうして顧客の体験と事業の防御が同じ場所に重なる。

3社に共通するのは、全正面で勝とうとしていない点だ。A社は機能数で大手に劣り、B社の機能はシンプルで、C社のアプリにも競合と似た部分は多い。彼らは満点を狙う正面を一つに絞り、残りの正面は合格点で止めている。捨てた正面があるからこそ、レバレッジ構造に注ぐリソースが残る。これがSaaSにおけるSDMP戦略の実装である。

5.閉じる—次回への引き

IT・SaaSの詰まりの中心には、「レバレッジを生む構造の欠如」があった。③速度+⑥レバレッジ+②差別化の3つを組み合わせて、価値軸を集中し、レバレッジ構造を設計し、速度を補強に向けることで、解約率は下がる。そしてその土台には、複数正面に取り合いされる開発リソースを俯瞰し、各正面の「十分ライン」を決める全体最適の判断がある。個々の機能開発の巧拙を磨く前に、この判断の枠組みを持てているか。それが、成長後期のSaaSを分ける。

閉じる前に、今日持ち帰れる小さな点検を置いておく。紙とペンがあれば10分で済む。

• 問1: 直近3ヶ月で追加した機能のうち、主軸顧客の価値軸を補強したものはいくつあるか。営業要望への応答や解約引き止めのための追加と分けて、数えてみてほしい。

• - 問2: あなたのプロダクトを3年使った顧客が明日解約するとき、その顧客が失うものを具体的に3つ書けるか。書けなければ、レバレッジ構造はまだ設計されていない。

• - 問3: 開発リソースが取り合いされている5つの正面(新機能・既存改善・保守・サポート・営業要望)のそれぞれについて、「どこまでやれば十分か」のラインを言語化できているか。

3問とも即答できたなら、この記事は確認作業だったはずだ。どこかで手が止まったなら、そこがあなたのプロダクトのレバレッジ・ポイントを設計し直す入口になる。連載を読み進めながら、折に触れて自社プロダクトを点検してほしい。

次回第6巻は、教育・研修の「定着×個別最適」を深掘りする。山本篤の本業ドメインでもあるため、自衛隊CGS教官時代と退官後のFUKUMO LABOの観察を踏まえて、⑦継続性+②差別化+⑥レバレッジの組合せが、なぜ教育・研修の勝ち筋になるかを解説する。

ここまでお読みいただきありがとうございました。

連載「不確実下の意思決定—SDMP理論を発信する」全10巻はhttps://note.com/fukumo_laboでまとめてお読みいただけます。

—山本篤(FUKUMO LABO)