SaaS立ち上げに関わる全ての人へ捧ぐ - 「All for SaaS」を読んでみた！

SaaSの開発に関わる機会があり、積読していた「All for SaaS」を読んでみることにした！

作者:宮田善孝
翔泳社

前職はアドテク系のSaaS開発に関わっていてこの本は購入していたのだが、積読になったまま埃をかぶっていた。

今回は開発前に実施する、事前調査やプロトタイプを作る方法を知りたかったため、Part1「SaaSを取り巻く環境」〜 Part3「事前/深掘り調査とプロトタイプ」をメインに読み進めた。（という前提のもと本記事を読んでください）

本書を読んで、事業として破綻しないSaaS事業を作るために参考となる指標 や、事業を企画するための事前調査 について学ぶことができた。SaaSを立ち上げる際に読む本ではあるが、プロダクト開発共通で言えそうなことも書いてあったため、私のように業務の中で新規事業の企画をしたことがないエンジニアにも大変役立つ内容だった。もちろん、SaaSに特化した話も含まれているため、普段企画をしているがSaaSの企画をしたことがない人にとっても役立つ内容だと思う。

SaaSを評価する指標

ユニットエコノミクス

SaaSを評価する指標として ユニットエコノミクス というものが一般的に用いられ、ベンチャーキャピタルの中でも度々参考にされているらしい。ユニットエコノミクスは以下の計算式で求められる。

ユニットエコノミクス = LTV(1ユーザが契約から解約までに支払う金額の合計) /  CAC(1ユーザを獲得するまでにかかった金額)

LTV(ライフタイムバリュー)

LTVは「1ユーザが契約から解約まで支払う金額の合計」を表す。

LTV = Average MRR per Customer(1ヶ月の利用額平均) × Average LifeTime of a Cutomer(平均継続月数)

「1ヶ月」としている部分は、事業によって異なるため自分の事業に合わせて読み替える。

CAC(ユーザー獲得コスト)

CACは 「1ユーザを獲得するまでにかかった金額」 を表す。

CAC = Sales and Marketing Costs(セールス・マーケコスト) / Number of Acquired Customers(ユーザ獲得数)

セールス・マーケコストをどこまでをコストとして含めるか、これも事業や求めたい指標によって異なる。

LTV > CAC が成り立たなければ事業として破綻している

この計算式が成り立っていない場合、ユーザを集めると集めるほど赤字になっていく状況である。つまり事業として破綻している状態である。

LTV(1ユーザが契約から解約までに支払う金額の合計) > CAC(1ユーザを獲得するまでにかかった金額)

ベンチャーキャピタルの中では、この数値が3倍以上であることが投資をする上で一つの指標となっているらしい。

新規事業を企画する際には、この数値が3倍以上になることを確認することで、継続的な事業になるかを判断する材料になりそうだ。

調査とプロトタイプ

プロダクトの立ち上げに向けて、本書では以下3つの調査とプロトタイプの手順が紹介されている。

事前調査
深堀調査
プロトタイピング

事前調査

まずは事前調査として、自分のデスク上でできる調査（デスクリサーチ）を行う。

5つの方法が紹介されているのだが、中にも印象に残っているのは、インターネット調査や競合調査における「英語での調査を行う」という部分だ。SaaSビジネスは欧米を始めとする海外の方が進んでいるため、参考になることが多いらしい。エンジニアリングの中で英語の文献も参考にするべきとは聞く話だが、SaaSビジネスの調査においても重要であることがわかった。

深堀調査

事前調査を行うことでプロダクトが方向性が見えてくるとは思うが、これではまだ不十分だという。プロトタイピングを行うには、ユーザに対するインタビューを通して業務の進め方を把握する必要がある。

いくつかの方法が紹介されているのだが、中にも印象に残っているのは 「競合プロダクトの調査」 である。HPや資料等からターゲットユーザ等を把握することで、自社のサービスの参考にすることができる。トライアル等で利用できるのであれば、実際に利用してスクリーンショットを撮っておくとよい。このような先行事例を参考にすることが 自社のプロダクトを作っていく上でショートカット となる。

プロトタイピング

開発には多くの時間がかかるため、プロトタイピングという一段階を挟むことで手戻りを減らすことができる。

印象に残っているのは「プロダクトビジョンの作成」である。本書においては以下のように説明されている。

企業全体のミッションに即した形で、プロダクトを通して対象となる業務や市場に対し、どのような価値を提供し、何を実現するのかを簡潔にまとめたものである

多くのプロジェクトで、このタイミングでデザイナーやエンジニアが入ってくるだろう。関係者が増えたタイミングでバチっとハマったプロダクトビジョンがあると、各メンバー間で無駄なコミュニケーションを取らずとも目指す方向性を一致させるられるため非常に良さそうだと思った。

また、プロダクトビジョンを作る上でのポイントとして、以下のポイントが紹介されていた。

正解に近づけるものではなく、正解だと思い込んで伝え続け、そして1人で多く共感してもらい、協働してもらうこと

新規事業は世に出してみるまで正解かわからないので、正解にしてやるくらいの熱狂が必要だと理解した。現在の上司が、「新規事業にはパッションが必要だ」と言っていたことを思い出した。

さいごに

SaaSに限らずプロダクト開発に役立てそうなことを学ぶことができた。エンジニアのメイン業務は開発ではあるものの、いわゆる経営者の視点も持つことも非常に重要だと思っていて、引き続き事業のことも理解できるように学んでいく。

なんて美しい夕陽だ🌇

プログラミング、日常、忘れないように書いていきます