実にサブスクリプションが売上の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%とするなど。結局、営業のアスピレーションベースでヨミ管理をすると、営業によってのブレが激しすぎて、均一化できない。営業マネージャーの役割が、強気・もしくは弱気なヨミの読み直し、ということになってしまう。これって、組織として再現性を高めてビジネスをしていく上ではマイナスでしかない、と私は思う。数字に現れないニュアンスがある商談だってもちろんあると思うし、全てがデジタルな世界ではないということを認めつつ、だからこそヨミは行動管理と照らして行う方が経営もメンバーもハッピーになれるんじゃないか、そんなことをぼんやりと考えた。saaslifeASPとSaaSの違いを3つに濃縮し、現場的な考察を加えてみた。ASPとSaaSは、ともに月額課金でソフトウェアを提供している。このため、実態は同じものであり、ただ単に最近流行ってるのでかっこいい風な名称で「SaaSと読んでるだけちゃうんか?」という疑問が湧く。アメリカのサイトsaasaddictによれば、以下の違いがあるらしい。以下は管理人SLの意訳である。—-(1)ASPはISVの作ったソフトウェアを売る。SaaSは自分たちで作ったソフトウェアを売る。何に対してIndependentかというと、ハードウェアメーカに対して、とのこと。(2)ASPはシングルテナント。SaaSはマルチテナント。ひとつの会社に対してひとつの環境を用意するか、複数の会社が相乗りできる形で環境があるかないかの違いのようだ。(3)事業スケーラビリティはSaaSの方が高い。プログラムの大部分を共通化できるマルチテナントであるがゆえに、顧客のフィードバックをプロダクト開発にすばやく反映することができるメリットがある。—-共通して、実装やシステムに近いところが特徴としてあげられていた。SaaSスタートアップの現場的には、改めて考えてみるとなるほど確かになと感じるし、もう少し組織に寄った観点で言うと、SaaSでは、カスタマーサクセスが組織として担保されているが、ASPは担保されていない(カスタマーサポートはいるが)ということなのではないか、と思っている。これは、上のシングルorマルチテナントかというところも大きく効いていると思うんだけど、結局ソフトウェアをアップデートできないのなら、顧客と伴走するカスタマーサクセスの職責を果たせなくなってしまうためだ。SaaSスタートアップの現場からは、以上です。三年前にこの業界に入ってくる前、私はある広告会社にいた。広告会社なのでビジネスモデルは、ショット(単発発生)で売上を作るものだった。営業はあの手この手でクライアントの広告予算を取ってくる。クライアントの予算総額を知り、クライアントの予算を自社メディアに差配するのが良い営業のような雰囲気があった。参入障壁もまあ低いのでビジネスとして参入する気持ちはまあわかる。経営的には、慎重に経営したい自分としては、そこまでおいしくないんじゃないか、って常に思ってた。「次の年、クライアントの気が変わったらどうするんだろう」だったり、「クライアントが『これって効果出てるの?』みたいなことをいいはじめたらどうする?」という点で。Serviceとして取り組む以上、利益率はどんどん上がる。(あんまりソフトウェアに寄っちゃうと、ASPと変わらなくなって、解約したりするけど。)SaaS会社の社長が毎年元旦に、昨年末のMRRを12倍して今年の売上を読むことができることも素敵である。季節要因とかを考えずに単純な掛け算で売上をそれなりの精度で予測できるのもSaaSの魅力のひとつなのである。