以前から積んでいて注目していた書籍だったのですが、ようやく読むことができました。感想を書いておきます。SaaS企業に勤めるソフトウェアエンジニアにとくにおすすめです。
我々（ソフトウェアエンジニア）は事業をわかっているべきなのか
まず前提として、いわゆるWebサービスやSaaSを開発する事業会社に勤めるソフトウェアエンジニアに関する話を少しします。[*1]筆者もそうした会社に勤めるソフトウェアエンジニアです。我々にとって元々無縁だったわけではないのですが、コーディングエージェントによって我々の仕事における一番の参入障壁ないしは専門性の源泉であったコーディングやアーキテクチャデザインといった知見が、必ずしも参入障壁にならない可能性が出てきています。
どこまでうまくいっているのか実態はわかりませんが、Rampという経費精算SaaSでは、Slackでエージェントに話しかけると画面に機能が追加され、本番リリースできる状態にあるようです。これによりプロダクトマネージャーが顧客の反応を探りながら、自分で自然言語で画面を改良してリリースするといった開発フローを取れるようになってきているようです。実際のところは画面でもエラー時の挙動などさまざまな非機能要件はあるはずで、その辺りを最後どのようにハンドルしているかはわかっていませんが、ソフトウェアエンジニアの手からそうした画面のちょっとした修正のような「雑務（チョア; chore）」[*2]は離れつつあるかもしれません。チョアからの解放は私たちにとっても悪い話ではなく、事業にとっても改善サイクルが速くなるのでウィンウィンな話だとは思います。
ただもちろん開発の仕事がすべてが溶けてなくなったわけではありません。私たちは引き続き非機能要件の匙加減を調整する審美眼は求められるでしょうし、たとえばPostgresに保存しておくのかRedisに保存しておくのかといったミドルウェアの使い分けをはじめとする一定程度の開発経験がないと判断が難しいタスクを適切に判断していくのでしょう。書籍『Googleのソフトウェアエンジニアリング』で語られていた対比構造を借りると、「プログラミング」の仕事は確かに消えるかもしれませんが、「ソフトウェアエンジニアリング」のタスクは残り続けるのです。[*3]そうしたタスクに集中できるかもしれません。一方で、SaaSの開発現場では毎日そのようなソフトウェアエンジニアリング的な、他職種からすると難易度の高いタスクが山積して面倒を見続けているかというとそうでもありません。日々のタスクの大半を占めていたであろうプログラミングのタスクはAIにより、高速に仕上がるようになりました。浮いた時間をどうするか。ここが難しいところです。
近年、事業会社のソフトウェアエンジニアはプロダクトマネージャーに近い動きをするよう働きかけられつつある話をよく聞きます。実際私の会社でも一部そうした施策が実施され始めています。その際重要になってくるのが、作る機能がきちんと事業成長につながっているかという目線です。もちろん会社によって事業の構造は異なるため一般化は難しいですが、SaaS企業の場合はある程度見るべき指標や数字は決まっており、事業成長そのものをいくつかの因子に分解して説明できます。非常に単純化するなら、これから作ろうとする機能が、事業上のどの数字や因子に貢献するかという嗅覚が今後求められるでしょう。これが「事業会社のソフトウェアエンジニアもビジネスをわかるようになるべき」という昔から言われている標語の一例でもあります。
もちろん数字だけを追いかけると、今度は使われない機能が大量に増えるなど「プロダクト」が骨抜きにされてしまいます。なので加えて、プロダクトの持つ思想と照らし合わせ、方向性が間違ってなければ選択するというのは当たり前ですが含まれます。事業とプロダクトの両方を理解しデザインするのは、事業会社のソフトウェアエンジニアには以前からも求められていましたが、技術という参入障壁が崩れ去りつつある今、より一層その傾向と重要性が強まりつつあります。
本書の特徴
サブスクリプション型のモデルを見ない日はありません。今はやりのChatGPTやClaudeなども全部サブスクリプション型です。また、すでに死んだと言われてしまったSaaSもサブスクリプション型のビジネスモデルの代表格です。時代の寵児とも言えるサブスクリプション型のビジネスモデルの会計からの目線を学べる一冊です。
MRR、ARR、CAC、LTV、ユニットエコノミクス…など、サブスクをビジネスモデルとする事業ではよく見る数字や言葉について体系的かつ簡潔に説明してくれる点が良い点でした。この手の体系的な説明は入社時にオリエンテーションがある会社もあるかもしれませんが、私はとくには受けていなかったので独学状態でした。一冊読んでおけばひとまず事業の構造がわかったり、日々の業務でレバレッジポイントがどこかを考える起点になったりすると思いました。
会計の知識がどれくらいいるかというと、収益、費用、キャッシュフローといった用語くらいは押さえている状態が望ましいと思います。あるいは財務会計と管理会計の違いは前提知識とされていそうな雰囲気です。本書のタイトルである「サブスク会計」は管理会計側の話です。この辺りのキャッチアップが怪しい方は別の入門書も同時に紐解いた方がよいかもしれません。最も、少しネット上の解説を読んで雰囲気を理解しておけば大丈夫だと思いますが。
印象に残ったところメモ
どこで元を取るかはやり方次第
サブスクの課金には大きく分けて、初期費用、定額課金、従量課金、違約金の4つがあります。課金の裏側では費用が常に発生しており、この費用をどう回収するかの設計によって、どのような課金形態になるかが変わります。
たとえば初期費用を設定しておいてきちんと初期導入時の稼働コストを取る手がある一方で、初期費用は設定せずに定額課金に上乗せする手もあります。ただし途中で解約されると初期費用を取りっぱぐれてしまうことから、一定期間内の解約が発生した場合に違約金の形で初期費用等々を回収できるスキームにしておく方法もあります。
あるいは定額課金と従量課金の比率も課金設計の一つです。後述するように定額課金の設定いかんでは、サービスをあまり使わないユーザーが損する可能性もあります。逆に定額課金が高すぎると、今度はサービス導入後に顧客が支払わなければならない固定費が大きくなることを意味します。ここを嫌う顧客も多くいるため費用と相談しながらうまいバランスを保つ必要があるというわけです。
サブスクリプションモデルは財務会計では実情を追いづらい
これは本書で最も印象に残った点で、サブスクは費用回収時期がずれます。どういうことかというと、費用が発生するタイミングと収益の発生するタイミングがどうも一致しません。これは、サブスクは解約されるまで定常的な収益を発生させ続けることに起因します。
3年間という期間があったとして、1年目に販促費用を大量に突っ込み、3年目でその費用を全部回収できるとします。財務会計だと1年目は販促費分費用が計上され、2年目と3年目は販促分の費用は計上されません。しかし、実際に収益と費用をきちんと対応させる形にするのであれば、各年度にちゃんと費用を分配しておくべき（1年目の費用はならされているべき）ということになります。
解約されるまで定常的な収益を発生させ続けるということは、1年目の契約状況がそのまま2年目にほぼ確実に適用されるということを意味します。厳密には解約もあるので完全に予測通りにはなりませんが、将来の収益の予測を非常に立てやすいビジネスだといえます。これを利用すると、費用を調整して出す利益をコントロールしやすくなります。
SaaS企業の決算書を読む時にはこの点に注意が必要で、しばらく発生している赤字額だけに着目してしまうとその会社の業績を見誤ってしまうことになります。続いていた赤字はどこかで費用の抑制によって減少し、結果的に黒字に転換するタイミングが来るかもしれないからです。しかもそのコントロールを比較的しやすいというのがSaaS企業の会計の特徴でもあります。SaaS企業の決算を時系列で追っているとJカーブと呼ばれる曲線を描いていることがあります。なのでSaaS企業の決算書を読み解く際には、キャッシュフローの確認も必要だったりするわけです。
ユニットエコノミクス
ユニットエコノミクスはサブスクのROIです。算出式は、「LTV / CAC」です。たとえばLTVが2000万のときCACが500万だった場合、ユニットエコノミクスは4となります。つまり顧客獲得単価あたり4倍のLTVが得られる計算になります。
SaaS企業等の業績を見るとチャーンレート（解約率）を逐次追っている図が示されていることが多いですが、単にチャーンが多いとある一定期間で見た時に値上げでもしない限り課金額が純減するという理由のほかに、LTVが下がってしまうからという理由もあります。LTVは顧客平均単価 / 解約率（あるいは顧客平均単価 * 平均継続期間）で算出されます。LTVが下がるとそのままユニットエコノミクスが下がるので、結果ROIが低いという状態になるという理屈ですかね。
手切れは良くなく、カスタマーサクセスが重要
サブスクリプションモデルは定額課金が発生することから、金融などでよく見かけるチャリンチャリンビジネスかと思われがちです。が、実のところまったくそんなことはありません。課金形態にもよりますが基本的には定額課金を一定期間以上行ってもらわないと、初期費用の回収に失敗するなどの「取りっぱぐれ」が起こります。そこで大事になってくるのがカスタマーサクセスのような、顧客と寄り添ってビジネスを成功させていく人たちです。サブスクビジネスは意外にもかなり泥臭いと中にいて思うことが多いです。
先行者優位でもない
SaaSに限らずどのビジネスもそうといえばそうですが、そもそもそのマーケットが先行者優位なのか後発者優位なのかはよくわかりません。私が普段仕事で見ている請求書受領や発行に関するマーケットにもさまざまなプレイヤーがおり、外から見るとレッドオーシャンに見えるかもしれません。競合がひしめいているのはむしろチャンスで、そこにマーケットがあることを意味します。なのでマーケットを開拓する労力を割かなくても良いということです。
定額課金は公平とは言い切れず、従量課金の方が公平なケースもある
いわゆるコーディングエージェントのサブスクがわかりやすいかもしれません。月額2万円で利用し放題なコーディングエージェントがあったとします。ある人は2万円を超える3万円のトークンを毎月使い、ある人は1万円分のトークンしか毎月使わなかったとしましょう。前者の人はたくさん使っているので実質1万円得をしており、後者の人は逆に実質1万円損をしています。定額課金だと、そのサービスを使わないユーザーは損をする構図になっているのです。事業者側からすると、たくさん使うユーザーでは費用がより多くかかるものの、使わないユーザーにはそれほど費用がかかりません。ここで帳尻を合わせているケースもあります。前者を「哀れな子羊」、後者を「ハゲタカ」と本書では呼んでいます。
こうしたケースでは、ひとつは従量課金の方が公平になると言えるかもしれません。つまり子羊側は1万円しか要求しないようにし、ハゲタカ側に3万円きっちり要求すれば、公平であるとは言えるでしょう。サブスクの維持費用は顧客が負担していることを考えると、使った分だけ料金が請求されるのは至極妥当なことなのです。使わなかった側からすると、たくさん使っているユーザーの肩代わりをしているという不公平感は減ります。
ただこの辺りは課金設計と考え方次第ともいえます。哀れな子羊を、多少料金を多めに払っても満足した状態に保つ「幸せな子羊」に変えるように努力してもよいかもしれません。また、そもそもハゲタカを発生させないように、サービスの提供にかかる費用を極めて小さくしていく手もあります。子羊の増加は解約率の上昇につながり、ネガティブな口コミが広がれば顧客獲得単価が上がります。またハゲタカが多くなれば赤字幅が広がりビジネスが立ち行かなくなることもありえます。
まとめ
個別具体の事業上の数字を把握したからといって、開発するプロダクトの機能がどの数字にどう紐づいているかは残念ながら少々わかりにくいです。これは機能開発によるアウトカムの寄与度を測るのが難しいなどさまざまな計測上の難しさを孕んでいるとは思います。ソフトウェアエンジニアの仕事はなかなか事業の特定の「結果」の数字にピンポイントに響くケースは少なく、「先行指標」に関係することが多いからだとは思います。
もちろんそこで諦めてしまうのではなく、今事業が「チャーンレート（あるいはどの種類のチャーン）を気にしているのか」「定額課金の課金額を高める施策をしたいのか」「新規顧客を増やしたいのか（CACを上げてがんばろうとしてるか）」のように、ぼんやりとでもいいのでどこに向かっているかを把握しておくのは重要です。ここがわかってくると、自身の取り組む先行指標としてのタスクが結果どこに関係しているかを説明できるようになります。そうすると日々のリファクタリングやCI/CDの改善といったタスクが、どういった事業上の結果につながっていくかを説明可能になるはずです。これは『エンジニアリングチームのリード術』という書籍の2章にもあったような「アウトカムを意識した開発」の第一歩になるでしょう。事業の文脈の中にリファクタリングのような行為がそのタイミングで合致した流れであるかどうかをアウトカムベースに判断できるかもしれません。
ところで最近全然ブログで技術の話をしていない。実は書き溜めている技術寄りの話はあるので、どこかで放流したいです。
そのほかの書籍
理解を深めるためにという視点から以前読んだ本を何冊かついでに載せておきます。
会計の入門は正直ほかにも良書がありますが、近年発売されていてかつビジネスパーソンをターゲットとして書かれている一冊です。「原価よりも安い値段で商品を売ったらどうなるか。赤字となるのは明白だ」「売るだけ赤字が膨らむ負け戦だ」という一見するともっともそうに見える話題が（管理）会計の目線から見ると実はそうでもないこともあるんですが、これがなぜ起こるかなどを詳し目に説明していて良いです。[*4]。本書を少し目を通して見て、会計の知識が怪しいなと思ったらぜひ読んでみると良いかもしれません。
9章でSaaS企業の例が紹介されており、あわせて読むと「なぜあのSaaS企業は赤字を掘り続けているのに大丈夫なんだ？どう評価すればいいんだ？」に関する理解が深まるかもしれません。この本でも紹介されているようにサブスクリプション型ビジネスは最初は赤を掘り、その後赤をコントロールできるJカーブという曲線を描くことがあります。そうしたSaaS企業を評価する際に重要になってくるのが、結局どれくらいキャッシュを持っているかです。ここが赤を掘れるキャップ、つまりは投資してリターンを得られる可能性の限界点でもあるからです。キャッシュフローを見ましょう。[*5]
*1:さらにいうと、ある程度の事業規模をすでに持っているとか国内であるとか、そういう前置きは必要かもしれません。たとえばプロダクトをゼロから立ち上げた直後くらいだと、そもそもこんな話を気にしている暇はなく、とりあえず顧客要望のありそうなものをひたすら作って目の前の受注に繋げる必要があるという考え方もできるからです。要するに一般化は難しく、私が今直面している現状についてこれから少し話をします、くらいの意味です。
*2:雑務というとちょっとマイナスな印象があるため。実際は雑務も重要なので、意図的にここからカタカナ語を使います。
*3:「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」。
*4:ちなみにこの間違いをしたのは日本経済新聞です。日経は経済新聞ですが、経済の込み入った話題については記者の認識が誤っていることもあり注意深く読まなければなりません。ちなみにですが、固定費の回収が肝です。
*5:XではたまにSaaSビジネスをするスタートアップの決算公告の大きな赤字に関してコメントがついていることがあります。だいたい「もう終わりだ」みたいな感じのコメントがついてますが。スタートアップなのでそんなもんだとは言えますし、SaaSなら赤字をコントロールしやすいところに良さがあり、一概にその時の赤字が悪いとも言い切れません。そういうときは赤字の額の推移を見た方がよいですね。今Jカーブのどこかを一度プロットして確認すると良いです。一方でその赤字の掘り方でまずいかどうかはスタートアップの決算公告ではキャッシュフローが公開されていないことが多いためわかりにくく、キャッシュフローが公開されていない以上資金調達の情報から推察するしかないんですよね。
