【考察】SaaSビジネスとLTVの関係性、実行する組織構造についての所感
SaaSを中心に、事業を短期的な売上の視点で考えるのではなく、顧客との長期的な関係構築により中長期視点でLTVを伸ばしていく考え方はもはや一般的なものとなっていると思う。
LTVとはLife Time Valueの略でいわゆる顧客生涯価値といい、一人の顧客から取引を開始してから終了するまでの期間に生み出される利益の総和を表す指標である。LTVについてはすでに多くの企業で重要なKPIとみなされており、各所で語られている為、あまり詳細に説明する必要はなさそうだ。
LTV最大化に向けては粘着性が高く業務に入り込むサービスを主としている観点でSaaSビジネスが相性が良いということは事実である一方、顧客へのペネトレイトを重視する為に低単価のプライシングを行うことで打ち手が逆に狭まってしまったり、THE MODELなど事業の推進体制としてこの仕組みが用いられることも多い中で、逆に思ったような成果に繋がらない事象も一方で発生しているように感じている。
低単価、THE MODELが一概に良くないということを言いたいのではなく、改めてSaaSビジネスを展開する上で自社の特性を鑑みてどの観点を考慮しておくべきなのかを整理する目的でこのnoteを書いていきたい。
遅くなったが、僕自身のプロフィールは下記だ。
セールス、マーケを中心に獲得戦略を思考する機会が多く、現場のオペレーションに噛みつつ一歩俯瞰した視点で状況を客観視する立場が多い為、その経験から似たような立場にある方を中心に参考になる情報がお伝えできたら嬉しい。（まとまりなく6,000字程度の分量になってしまったので、面倒な方は適宜読み飛ばして頂ければ幸いだ）
新卒で富士通株式会社入社、ITシステムのエンプラセールスに従事。
その後、Webマーケティング支援会社にて大手企業向けのデジタルマーケ支援業務(特にCRM、バイラルマーケ、Ad)に従事した後、HRベンチャーにて事業開発リーダーや事業部長として担当事業の中長期戦略、P/L、セールス/CS/オペレーション組織のマネジメント、プロダクト企画、組織開発(採用、評価、目標設計)、を担当。
現在はITメガベンチャーにて業務支援SaaSのプロダクトマーケティングマネージャーを務め、事業P/Lに紐づくSMBおよびエンプラ顧客のGTMにおけるtoBマーケ、セールス、IS、CSなどを統合した戦略策定、PJM、開発要件整理などの業務に従事。
LTVの重要性と基本戦略（前提）
LTVの定義は記述した通りの考え方であるが、LTVと同時によく言われるのがCAC(Customer Acquisition Cost)、つまり一人あたりの顧客獲得コストだ。CACには、広告出稿・イベント出展などのマーケ費用だけでなく、セールス人件費など、顧客獲得のために費やしたすべての費用が含まれる。
CACを算出する場合は活動すべてを含んだCACを算出する必要がある為、総称するとBlended CACがいわゆるCACを表す言葉になるが、顧客獲得はpush施策だけで獲得するものだけではない為、分解して指標を見ていく必要があり、それぞれOrganic CAC、Paid CACに分けられる。どの活動がどちらに属すのかは企業内の定義によるものもあると思う。
LTVとCACを見比べ、事業のユニットエコノミクスを算出することで事業が健全な状態であるかを把握することが可能であるが、CACと一緒にその資金が何ヶ月で回収できるのか（Pay Payback Period）を見ておくことも大切である。
LTVがCACを上回っていたとしても、自社基準の中で回収期間があまりにも長いとそれも事業として健全ではないとも捉えられ投資判断にも影響する為、適切な状況であるかはウオッチしておくべきだ。
今お伝えした観点を見ていくにあたり、まず最も重要なのがLTVがどの程度の規模感になるかという観点だ。上記の通り、打ち手の幅はLTVで決まってしまうからだ。
低LTVのビジネスモデルによって起きること
プロダクトがターゲットとする企業規模はSMBからエンタープライズへと大きくなるにつれLTVも大きくなる為、許容CACも大きくなる。
許容CACが大きくなると、取りうるマーケティングオプションの幅も広がるが、逆を返すとLTVが低いプロダクトは、許容CACの上限が決まってしまうので、取りうるマーケティングオプションの幅も狭くなってしまう。
獲得数を重視し短期的に許容CACを超えて施策を突っ込み、後からLTVを合わせにいく戦略を取るケースもあるにはあるが、LTVを合わせにいく道筋が見えていないケースも多く、獲得したは良いものの、短期的にプロダクトやオンボーディングが受け止められる余力がなく結局チャーンにつながってしまうパターンも多い。
（アカウント接触が過去あるのでハウスリストとして他プロダクトの促進を行いクロスセルを生み出そうという発想も出がちだが、顧客の置かれている環境も課題も全く異なるので、スムーズにクロスセルを生み出すことはやはり後付けだと極めて難易度が高い気がしている。）
才流さんのスライドや下記記事がとてもわかりやすく詳細を記載されている為、イメージがより膨らむと思う。
LTVの高さが、BtoBマーケティングの自由度を決める
https://markezine.jp/article/detail/31888
従って、繰り返しだが高LTVの創出はすべての活動の根幹になる為、LTVが高くなるプロダクトをいかに設計できるかが重要な観点となる。
LTV向上の打ち手についての詳細は割愛するが、基本的には平均単価の向上、チャーンレートの低減、購入回数の増加に対するアプローチをプロダクト、サービスの両観点から検討していく流れとなる。
組織特性とSaaSビジネス
では、LTV向上の為に組織体制としてはどのような観点を考慮していく必要があるのかについて、企業特性の観点から考えていきたい。
ひとまとめには括れないという前提は予めお伝えしつつ、大企業の事業運営を例に僕が見てきたケースから考察すると、まず組織が成長すると説明のコストが増え機動力が落ちていく。
事業戦略に伴う予算取得やリソース配分は、企業にもよるが半期に一度程度で見直しの機会があり、そのタイミングの数ヶ月前から準備がスタートする。
つまり、当期の戦略を動かしつつ次の予算取得のためにどう説明を作っていくかを考えなければならない為、成果に時間を要するチャレンジをしている場合、大きな戦略変更を挙げにくい構造にある。（当然兆しが出ていないと説明ができない為、大方針に落とすのには1年ぐらいの時間を見ておく必要がある感覚だ）
また、トップの意思決定や関連事業との兼ね合いにより、担当するプロダクトの方針転換に影響を及ぼすケースが少なくない。
従って、事業主体での急な方針転換や戦略の転換は難しく、長い時間をかけて根回しを行い下準備をしていく必要があるのだ。また、他事業との兼ね合いの中で変更を余儀なくされることもあったり、社内のトレンドの中で知らない間に自組織に影響を及ぼす体制変更や検証が進んでいることもあり、そことの整合性を考える必要が出てきたりする。
また、関連部署のミッションやKPIも一度決めたものを柔軟に変更していくことは難しい。
予算取得のタイミングで決定した方針に従いその中でミッションを遂行していく為、上手く事業運営できている状態でガッチリ方針と戦術が噛み合っていれば良いが、基本的に縦割りで事業運営がなされていく為、それぞれをしっかりマネジメントできる役割がいないと、気がついたらバラバラな動きを各所が取ってしまう事態がよく発生する。
また、そもそも大企業は「効率的に多くを獲得する」思考が特に強いため（小さい規模をとっても事業インパクトがない）、組織構築や人員配置はどうしてもロジカルに頭数で判断されるケースが多くなる。
配置される人員による実際のパフォーマンスにおいても、数を回しKPIだけ合わせにいく思考が強くなってしまうのだ。
もちろん、上手く事業運営できている企業や組織があることも理解はしているものの、組織人数が多い為にどうしても全体最適の考えが働き組織がサイロ化してしまうことで、一気通貫で顧客体験を提供する為の推進論理が働きにくい構造にある、ということは認識しておくと良いだろう。
ただ、ベンチャー規模が上記と全く逆かと言えばそうでもなく、企業によって様々ではあるので結局はマネジメント次第だ。ただ、折角なのでその機動力は顧客体験の実現の為に活用する組織体制であって欲しいとは感じる。
ちなみに僕は「ベンチャー最高！大企業は微妙…」と考えている訳ではなく、それぞれの良さがあると思っている。
どの規模感でビジネスを展開するかにより組織のあり方は異なるし、ベンチャーも組織が大きくなれば機動力が無くなり上記の状態へ構造的に近づいていってしまう上、自分自身いつどこでどんなキャリアを歩むかは分からないので、構造を踏まえ自社はどうすべきかをフラットに考えられる頭にしておいた方が良いと考えている。
TheModelの本質とは
推進にあたりTheModelを組織にインストールすると、必ず「KPIの持ち方と連携の仕方」が論点に挙がる。マーケはリード数ではなく有効リード数、ISは商談数ではなくターゲット商談数を目指そう、のように、隣の組織に干渉できるようなKPIを持たせて活動させていると思う。
ただ、ある程度推進すると「これ結局意味あるんだっけ？成果に繋がってる？結局それぞれの部署は隣のKPIまでしか見てなくない？分業によって逆にコミュニケーションコスト上がってない？」のような疑問が浮かんできてしまう。
上記によって、TheModelを廃止し1人のセールスが全ての対応を行う形へ移行していくケースも少なくない。
これに対しては、下記記事の考え方がとても参考になるのだが、TheModelは組織体系の型ではなく「課題解決のプロセス」である、という点を一度考え直してみてはどうかと思う。
組織が大きくなると当然一人で全ての顧客対応を抱えることは難しくなる為、分業制をとる必要性が出てくる。分業制を敷くと各セクションにおけるミッションやKPIに左右され、組織が大きければ大きいほどサイロ化し横の連携が取りづらくなってしまうが、問題はこの分業制にあるのではなく「すべては顧客の課題解決のためにあること」を組織全体で考えられていない点にある。
まず顧客の課題解決が前提にあり、その上で自社組織の効率化を考える順序であり、効率化が先ではないのだ。
「いや、そんなの当たり前じゃん」と感じる方もいるかと思うが、実際にこれを組織として一気通貫で実現するのは大変なことだし、つい忘れてしまう。フレームワークは恐ろしいもので、そのフレームワークを使っていると裏に隠れている本質を見失ってしまう。前提の細かいスタンスを合わせることは組織を動かす上で極めて大事なことだ。
顧客の課題解決を前提としたTheModelの活用という形で先ほどの課題を改めて捉え直してみると、あるべき姿が見えてくる。
【ありたい姿】
顧客の課題解決を組織全体で実現する
【組織課題】
一人で全ての顧客対応を行うことが難しい
【対応方針】
・組織を分業しセールス、IS、CSをそれぞれ管理する
・それぞれの組織がお互いのKPIに干渉し合しあい一気通貫の顧客体験を実現する
・横断でデータを用いたマネジメント組織を置き客観的な視点で顧客体験の実現のために分析と示唆を提供する
・組織に属する人の専門性構築を強く意識しプロフェッショナルとして育てる
逆に言えば、組織課題として対応工数の逼迫が無かったり、スーパーセールスマンがいる状況であれば、あえて分業する必要はなさそうだ。
当然、一人の優秀な人材が初回架電から商談、オンボーディングまで一気通貫でサポートしてくれれば、企業にとってもどれほど安心だろう。（商談の人は素晴らしかったのに、CSがイマイチで上手く活用し切れずそのサービスを解約したケースは自分もあるので気持ちがわかる）
上記のような連携をこの規模で高いレベルで実践しているのがSalesforceであり、改めて参考にする部分も多いと思う。
やはり、TheModelという仕組みを実装だけしても上手く回らず、組織全体として運営の仕組みや人材育成を考える必要があるのだと再認識させられる。
組織という生き物
「組織マネジメントは車を運転することに似ている。上の立場や役職になればなるほどより大きな車を運転することになる為、その特性を理解しておく必要がある。」これは上司からの受け売りの言葉だ。
例えば、大きなトラックがハンドルを切った時、前輪、後輪が順番に徐々にその方向へ舵を切り進んでいくが、組織も同じで大きな組織になればなるほど、このトラック自体がとてつもなく大きな車体となり、トップが方針を変えたとしてもすぐに現場には行き渡らない。
しかも、組織はその前輪も後輪も意思を持っているので、説明や理解の時間軸も考慮するとより柔軟性を持って動くことは難しくなる。
一方で、車体自体が大きくパワーがあるため、一度その方向に向くとすさまじい力を発揮する。(ベンチャーはその小回りの良さが働く側として気持ちの良いところであると同時に、小さくまとまりすぎてもそれ相応の成果しか得られない為、常に大きな変化を狙う姿勢は崩してはいけないとも思う)
リーダーがすべきことは、車両自体のエンジンの見直しや積み荷を調整して動きを調整すること（組織構造をいじる）、しっかり意図通りに車輪を動かすための潤滑油を刺し続けること（MVVやKPI、主要テーマなどの定期的な説明と共有）が大事になってくる。
また、そもそもこの時間軸を考慮に入れたうえで起きうる状況やリスクに思いを馳せ、気がついた時に身動きが取れないということにならないよう、先手先手で打ち手を考えておくことが大切だ。
これは非常にバランス感覚が求められる役割であり、誰しもができることではなく、且つ経験が必要な役割であることもまた事実だ。
だが、どんな立場だったとしても、周囲を巻き込み協力者を増やしていくことで徐々にあるべき姿へと近づいていければ良いのだと思う。メンバーの方も上司を動かそう。些細な問いから事業の変化は生み出していける。僕も引き続き、気を引き締めてトライしていきたい。
最後に
かなりの長文になってしまいましたが、お付き合い頂きありがとうございました！各論を深く記載する目的ではない為、具体的なhowにあまり言及しておらず恐縮ですが、どこかのタイミングでまた書いていけたらな、と思っています。
Xもやってます。プロダクトマーケやマネジメントに関して呟くことが多いです。お気軽にフォローいただけたら幸いです！
https://twitter.com/ytshiba22
この記事が気に入ったらサポートをしてみませんか？