TL:DR;

• CACはある期間に1ユーザーを獲得するのにかかった必要、LTVは当該期間に獲得したユーザーが解約までに支払う費用
• LTVとCACの比率目安は3:1と言われており、LTV/CACは3が目安
• もしLTV/CACが1だとビジネスが危うい、これが5だともっと広告を使うべき、という指標になる

では、まずは用語の定義から。

CAC

CAC:Customer Acquisition Costの略。シーエーシー、だったりカックと言う。あるSaaS企業のCACは、ある期間の内1ユーザー(取引先)を獲得するのにかかったセールス・マーケティング費用の総額を表す。CACは費用なので、低ければ低いほど良い。CACを下げる方法には大きく以下の3つがある。

• マーケティングチーム/インサイドセールスが質の高いオーガニックリード/商談を獲得する(要は、ザ・モデルで言う入り口の効率が良い)

• フィールドセールスによる健全なパイプジェン(要は、ザ・モデルで言うリードに対するコンバージョン効率が高い)

• カスタマーサクセスによるクロスセル/アップセル(既存顧客による横展開なので、基本的にセールス・マーケティング費用が新規でかかることがない)

なお、CACは以下の式で算出できる。

ある期間にかけたセールス・マーケティング費用 / 獲得したユーザー(取引先数)

セールス・マーケティング費用には大まかに以下を入れておけば良い。

• (a)　広告出稿額
• (b)　従業員の給与
• (c) 　その他マーケティング費用(ツール費用など)

LTV

LTV:Life Time Valueの略。エルティーヴィー、と読む(CACと対照的に、読み方のばらつきは無い)。1ユーザー(取引先)あたりが解約までに払い続ける金額なので、

• ユーザー(取引先)あたり平均利用料
• ユーザー(取引先)あたり平均利用期間

の積で求められる。

LTVとCACの比率目安はどの程度が適正水準なのか？

一般的に、LTV:CACの比率は3:1、つまりLTVをCACで割ると3が目安だとSaaSの世界では言われている。この比率は高ければ高いほど良い。一般的に事業が成長するとCACは広告出稿効率の低下やシェア争いが生じて増える傾向にある。このため、LTV:CACを高い水準に保つには、

• いかにして値上げをしてLTVの構成要素である平均利用料を引き上げるかと、
• カスタマーサクセスに力を入れて平均利用期間を増やしていくか

と言うことが重要になる。

LTV/CACは3が目安なので、これよりも高い場合は、もっと顧客獲得を増やすために広告を出向することを考えるべきだし、逆にこの水準が1に近い状態だと、広告を使ってユーザーを獲得するが、ユーザーはすぐに解約するもしくは極めて不健全な状態、と言うことができる。

このCAC、LTV議論はどちらかと言うと細かいオペレーションというか、経営にやや偏った話にはなる。一方でオペレーショナルな導入としてはやっぱりザモデルが一番優れていると思うので、まだ読んだことがなくてSaaSに興味のある方は是非読んでみてください。

“原典に当たれ”

前職の先輩から受けた指導を思い出す。めっちゃ怖かった。ネットの情報よりも、現場でクライアントにヒアリングした情報を、など。

さて、SaaS発祥の地でもある米国の決算情報を知りたいと思ったことはないだろうか。さすがに直接米国SaaS企業の社員に聞くわけにもいかないし一次情報では全くないが、およそ第三者の手に入れうるまとまった質の高い二次情報として決算書は最高に使える。実は以下の通りになっているので何か参考になれば幸いである。

エグゼクティブ・サマリー

結論から言うと、

• form 10-K、form 10-Q
• annual report

を見れば、企業の概要をつかむ上では間違いない。以下、それぞれの役割を紹介しよう。

Form 10-K、form 10-Q

日本でいう、いわゆる通期の有価証券報告取引書。米国の会計基準はGAAP基準に則っており、form 10-Kは通期、Form 10-Qは四半期の企業成績が載っている。

Annual report

日本でいう、いわゆる決算説明会資料のこと。米国の会計基準はGAAP基準に則っており、form 10-K、form10-Qはこの会計基準に則った報告内容の一方で、annual reportには各社独自のKPIがでてきたり、form10-Kやform10-Qの数値をビジュアライズしたものが多く、よりわかりやすい内容になっている。

ということで

Google翻訳の精度も劇的に改善してるご時世なわけだし、このサイトを読んでる方はそれなりに受験英語も得意だった人なはずだ。以上、とりあえずAnnual reportを読んで自社のSaaSと比べると色々学びがあると思いますよ！という話でした。

番外編

上場時の数値は、Form s-1に載っている(googleで「企業名 form s-1」で検索すれば一番上にでてくる)。高い数値目標を掲げながら邁進しているときに、「あの巨大企業もこんな時代があったんだな」と眺めて勇気をもらうのにオススメです。

SaaSで重要な3文字と言えば、M(A)RRであることに異論はないと思うんだけど、時価総額を決めるためで超重要な3文字がある。それがTAM(タム、と読む。Total Addressable Marketの略称)だ。

TAMはあるSaaSがサービスとして最大でリーチできる売上規模のことを言う。つまり、例えばERPの市場規模がx兆円あるとして、あなたがERPのSaaSを「仮に」理論上全ての企業に提供できるんだとしたら、あなたのSaaSのTAMはx兆円だと言うことだ。TAMの広さ(ベン図で言う全体集合みたいなの)をユニバースと呼ばれることが多い。なので、「タムのユニバースは～～」みたいな使い方をしたりする。ただソフトウェアを打ってるだけなのに、「ユニバース(宇宙)」と言う言葉が出てくると元理系少年としては胸アツになるこの言葉。

TAMは「Addressable」と言うところが肝で、「あなたの企業がそこにサービスを提供し売るか」と言うところが妥当に示せないと意味がない。つまり、先ほど例であげたERPSaaSをあなたが作り上げることに成功したとして、おそらくそのSaaSは「この業態に強い / この企業規模に強い」みたいな特徴を持っていたりするだろう。だとしたら、あなたの想定すべきTAMは全企業ではなくて、むしろ

• あなたのSaaSが強い企業に導入できる理論売上 = 全企業の数 x 業態の割 x 企業規模の割合 x SaaS単価

だったりする。

※ここの売上がMRRかARRなのかと言う細かい話はあるが、12を割り算するのか掛け算するのかと言うだけの話なので、瑣末な話だろう

もちろん、実際はこんなに簡単じゃなくて、「そもそもそのTAMで捉えている企業のお財布的にお金を出せるのか」は重要な論点だったりする。

正直SaaS企業経営に携わっていると、外向けの値として多少大きめにTAMを捉えて、「夢を語る」フェーズと、実際に予実を合わせに行く文脈で、「堅くTAMを捉える」両方が求められる。このように、正解が全くなく、全てのSaaSで推定・算出根拠が全く異なるであろうTAMもSaaS経営の面白いところだったりする。みんな各種統計をこねくり回したりとか、涙ぐましい努力をしてTAMを算出してたりする。TAMの捉え方をしくじると、経営的にはまあまあ渋いことになるので要注意だ。日々自分を戒めている。

「SaaS、といえばMRR(Monthly Recurring Revenue)」といっても過言でないだろう。MRRは、毎月繰り返し発生する売上を表し、ARR(Annual Recurring Revenue)も概念としてはMRRと同様だが、「年」単位で売上が発生することが異なる。

つまり、解約率がゼロだと仮定すると、

• MRR100万円だと来月も100万円
• ARR100万円だと来年も100万円

が入ってくる。ではMRRとARR、どっちの指標が適切なんだろうか？

MRRとARRは「ARR = MRR x 12」という単純な式で関連づけることができる。ただ、MRRの場合は、伸び続けるSaaSスタートアップの場合、会計年度の1ヶ月目と12ヶ月目では当然金額が異なってくるはずなので、どの月を起点にして12倍にするかでARRが異なる。もちろん、これは強気に売上の予測をするのか、保守的に売上の予測をするのかにより異なるし、せっかく成長していっててもそれを上回るスピードで解約が起きていたら1ヶ月よりも12ヶ月目の方がMRRが下がる、という笑えないことが起きるだろう。

SaaSOPTICSによれば、

・ARRをMRRより使うべきなのは、契約の最小単位が1年の場合でBtoB向け

・逆に、toC向けのサービスでARRを使うことは稀

・ARRの方がMRR(日割りのケースが多く、月の中でも月初月末で金額が変わる)に比べて、より正確な売上が予測できる

SaaSOPTICS

とのことだ。

個人的には、契約の最小単位が1年かどうか、という点については、あまり本質的ではないと思っていて、ARRだろうがMRRだろうが、SaaSの凄さを比較するための指標なんだから、何を算出の根拠においているのかをはっきりした上で議論できたらどっちでもいいかなと思っている。

ちなみにSaaS関連の考え方全般については、元SalesforceでMarketoの福田さんが書いた「ザ・モデル」が詳しい。(画像クリックでamazonの新しいタブが開きます。)

はじめに、PSRとPERは以下の略称を指す。

PSR(Price to Sales Ratio): 株価売上高倍率。時価総額を年間売上高で割ったもの。(*1)

PER(Price Earnings Ratio): 現在の株価が1株あたりの純利益の何倍かを指す。(*2)

(*1) 野村證券

(*2) ZAiONLINE

ある企業の時価総額は株価 x 発行済み株式数で求めることができる。PSRとPERはともに企業の時価総額/株価に関係した指標であり、企業に対する評価指標である。特にSaaSは、チャーン(顧客の解約)さえ起きなければ売上は上がり続けるモデルではあるので、「いかにして適切に企業価値を評価するか？」という問いが市場の要請として発生する。

一般的に、上場していて財務情報がしっかりと公開されており、DCF法による企業価値をしっかりと評価できる場合は特に問題がないんだけど、SaaSスタートアップはそもそも上場しておらず、株価も公開されていないが故にその価値価値を評価することがとても難しかった。

そこで現れたのがPSRだ。PERやDCF法は、企業情報を正確に把握しておかないとできないのに対して、単純な売上に対する倍率で企業価値を算出することができる。とは言っても、類似のSaaS企業に対して、売上に対する株価を調べ、その割合(これをマルチプル、と言ったりする。例えば、採用の面接で、「うちのマルチプルは10倍程度」と言われたら、「売上x10倍が時価総額ってことは、時価総額100億なのね」みたいに理解できる)を算出して出すので、あまり個別事情を勘案していない(例えば、プロフェッショナルサービスと月額課金の割合が異なれば、当然収益性は異なるため)正確ではないが、まあ、一つの目安になる。

本当にみんな次から次へといろんなことを考えだすよね。

Salesforce(セールスフォース、と読む)の決算が絶好調だ。2019年3月4日発表のIRによれば、2019年(会計年度)の決算にて

売上は132.8億ドル(=1ドル100円換算で約1.3兆円)、作対伸び率は26%

Salesforce IR

とのことだ。

セグメントの売上は

サブスクリプションとサポート費(*1)が124.1億ドル(=1ドル100円換算で約1.2兆円)

プロフェッショナルサービス(*2)が8.6億ドル(=1ドル100円換算で約860億円)

(*1) 収益が安定する月額課金SaaSパート

(*2) 収益が不安定な単発課金パート

Salesforce IR

とのこと。

実にサブスクリプションが売上の92％を占める化け物企業だ。しかも、月額課金が前提のSaaSモデルだから、翌年の売上も堅い。SaaSのスタートアップにいるので、当然のごとく日々の業務でSalesforceを使う。それは、もう好むと好まざるを得ず。

実は、Salesforceという商品自体は、SaaS企業向けにデザインされていなくて、どちらかというと単発で売上が発生する、ショット向け商品を売る企業のためにデザインされているな、と現場では感じる。それがゆえに各社涙ぐましい努力をして、Salesforceを独自にカスタマイズし、自社の受注情報を握られ、他の絶妙な代替手段がないため乗り換えることができず、「仕方なく」使っているのが実情だと思う。

それがゆえに、例えばSaaSスタートアップの現場メンバー同士で情報交換をすると、「Salesforceでこれってどうやっている？うちはこう魔改造してるよ」的な話で盛り上がって、いい刺激を受けあっているらしい。

こういうところもふくめて、やっぱりSalesforceって偉大だし、SaaSスタートアップの経営に携わる身としては、自社をこういうように大きくしていきたいなあと思いながら、今日も会社を後にするのだった。

前職の広告会社は、営業の受注管理を「ヨミ表」という表で管理していた。

「ヨミ表」は、各営業が自身の受注目標にたいして、どの程度期待収益が見込まれるかを管理する表を指す。(「表」と言っても実際現場で使うのは、入力用の中央集権的自家製システムであり、そこからみんな大好きExcelにチームもしくは個人単位で値を出力し、A3用紙に出力して、、、ということを毎週やっていた。)この中央集権的な自家製システム(以下、仮に「ニュークリアス」としよう。広告会社はこういう厨二的ネーミングが大好きなのである)に毎日情報を営業現場でニュークリアスに入力し、中央にて企画室がその数値を積み上げ、最終的な期待収益を予測していた。これが、実績のJ、80%のA、60%のB、40%のC、みたいに段階に分かれており、今自分の提案はどうなっていて、その結果数字がどれだけ足りないのかを明らかにするのが営業メンバーの仕事であり、営業マネージャーは「ヨミを管理し、部長やさらに上の役職に報告を上げる」ことが仕事だった。

企画室から、毎日夕方にメールで配信されてくる全国に散らばる営業の成績を見て、営業からオフィスに戻った後、会社から貸与されているラップトップPCを開き、「あ、何々さんはもう目標を達成したのか」だったり、「Xチームは目標を達成するまであと残りこのくらいなんだな」みたいなところを見ていた。

それにしても当時からわからなかったことだったんだけど、「期待収益」という項目があって、ヨミとそのヨミにいる金額の総和を、ヨミの状態に応じて係数を掛け合わせて、算出してたんだけど、あの頃の自分には「なぜ、ヨミという営業の主観が入りまくった情報を元に期待収益を算出できるのか、掛け算はさておいて、その背後にあるロジックの妥当性」が正直言って全くわからなかった。だって、売れる確率だよ？分母は何を使うんだよ？という話である。

今SaaSのスタートアップの経営に関わって、わかってきたことがある。それは、ヨミ表のヨミ、は営業のアスピレーション(営業の意思)で作ってはダメで、営業のフェーズにおける行動と対応づけをしないと意味がない、ということ。つまり、受注確率80％の受注、というものがあるとしたら、申込書はもう送っていて、捺印返送を待っている状態を80%とし、逆に、商談を始めたばかりだと、顧客のニーズがわかったタイミングでようやく20％とするなど。

結局、営業のアスピレーションベースでヨミ管理をすると、営業によってのブレが激しすぎて、均一化できない。さらに、営業マネージャーの役割が、強気・もしくは弱気なヨミの読み直し、ということになってしまう。これって、組織として再現性を高めてビジネスをしていく上ではマイナスでしかない、と私は思う。

もちろん、数字に現れないニュアンスがある商談だってもちろんあると思うし、全てがデジタルな世界ではないということを認めつつ、だからこそヨミは行動管理と照らして行う方が経営もメンバーもハッピーになれるんじゃないか、そんなことをぼんやりと考えた。

ASPとSaaSは、ともに月額課金でソフトウェアを提供している。このため、実態は同じものであり、ただ単に最近流行ってるのでかっこいい風な名称で「SaaSと読んでるだけちゃうんか？」という疑問が湧く。

アメリカのサイトsaasaddictによれば、以下の違いがあるらしい。なお、以下は管理人SLの意訳である。

—-

(1)ASPはISVの作ったソフトウェアを売る。SaaSは自分たちで作ったソフトウェアを売る。

ISVはIndependent Software Vendorの略。何に対してIndependentかというと、ハードウェアメーカに対して、とのこと。

(2)ASPはシングルテナント。SaaSはマルチテナント。

つまり、ひとつの会社に対してひとつの環境を用意するか、複数の会社が相乗りできる形で環境があるかないかの違いのようだ。

(3)事業スケーラビリティはSaaSの方が高い。

プログラムの大部分を共通化できるマルチテナントであるがゆえに、顧客のフィードバックをプロダクト開発にすばやく反映することができるメリットがある。

—-

共通して、実装やシステムに近いところが特徴としてあげられていた。SaaSスタートアップの現場的には、改めて考えてみるとなるほど確かになと感じるし、もう少し組織に寄った観点で言うと、

• SaaSでは、カスタマーサクセスが組織として担保されているが、ASPは担保されていない(カスタマーサポートはいるが)

ということなのではないか、と思っている。

これは、上のシングルorマルチテナントかというところも大きく効いていると思うんだけど、結局ソフトウェアをアップデートできないのなら、顧客と伴走するカスタマーサクセスの職責を果たせなくなってしまうためだ。

SaaSスタートアップの現場からは、以上です。

三年前にこの業界に入ってくる前、私はある広告会社にいた。広告会社なのでビジネスモデルは、

• ショット(単発発生)で売上を作る

ものだった。

営業はあの手この手でクライアントの広告予算を取ってくる。クライアントの予算総額を知り、クライアントの予算を自社メディアに差配するのが良い営業のような雰囲気があった。この状態について、

• 利益率は高くて、

• 参入障壁もまあ低いので

ビジネスとして参入する気持ちはまあわかる。

だけど、経営的には、慎重に経営したい自分としては、そこまでおいしくないんじゃないか、って常に思ってた。「次の年、クライアントの気が変わったらどうするんだろう」だったり、「クライアントが『これって効果出てるの？』みたいなことをいいはじめたらどうする？」という点で。

SaaSは、ちゃんと字義通りSoftware as a Serviceとして取り組む以上、利益率はどんどん上がる。(あんまりソフトウェアに寄っちゃうと、ASPと変わらなくなって、解約したりするけど。)

SaaS会社の社長が毎年元旦に、昨年末のMRRを12倍して今年の売上を読むことができることも素敵である。ごちゃごちゃ季節要因とかを考えずに単純な掛け算で売上をそれなりの精度で予測できるのもSaaSの魅力のひとつなのである。