ReproのProduct Planning Teamでプロダクト企画を担当している河西です。
在庫を持たず、長く使ってもらうほど利益が積み上がる──。
私がSaaS企業に入社したのも、この美しいビジネスモデルに惹かれたからです。
しかし、現実はそこまで簡単な話ではありませんでした。
顧客が増えれば、当然インフラコストも増えます。特にReproのように大量のデータを扱うプロダクトでは、ある一定のラインを超えると「使われれば使われるほど、サーバー費が利益を食いつぶす」という悪夢が頭をよぎります。
LTVやCACといった、SaaSで重視される指標の裏で、「で、結局このお客さん1人あたり、いくらかかってるの？」という問いに即答できない。 1顧客あたりのインフラコストが見えない状態こそが、営業のアクセルを緩め、開発の不安を煽る元凶でした。
なぜ顧客あたりのインフラコストに即答できないのでしょうか？SaaSの原価計算が難しい理由は、使われ始めてから初めてシステム負荷が顕在化する点にあります。
今回は、この見えないコストといかに戦い、どうやって攻めのための原価管理を実現したか、そのプロセスを公開します。
※なお、本記事で扱っている原価や按分の考え方は、あくまでプロダクト改善と事業判断のための内部的な視点であり、個別の顧客条件や価格を示すものではありません。
SaaSのコスト構造と、見落とされがちな中身
一般的にSaaSのコストは、売上原価と販管費に大別されます。
この記事では、このうちプロダクト提供に直接関わる売上原価にフォーカスします。
売上原価には、例えば以下のような要素が含まれます。
- サーバーやネットワークなどのインフラコスト
- システム運用・監視のためのツール費用
- カスタマーサクセスの人件費
- 開発に関わる人件費
（※会計上の扱いは企業によって異なりますが、この記事では「プロダクト提供に直接影響するコスト」という意味で整理しています）
売上原価の内訳がブラックボックス化していると、事業のアクセルをどこまで踏んでよいのかを判断することが難しくなります。
なぜ判断が難しいのでしょうか。それは例えるなら製造業との構造の違いにあります。 パン屋のような製造業の原価計算は、何個作っても小麦粉のグラム数は変わりません。そのため、作った瞬間にコストが製品1個に紐づきます。
一方、SaaSは食べ放題のレストランに似ています。店舗運営の基本コストは一定ですが、顧客の利用方法によっては後から食材にかかるコストが膨らみます。「参加するだけでかかるコスト」と「使われるほど効いてくるコスト」が混在し、SaaSの原価構造はブラックボックス化しやすいのです。
Reproの原価計算を難しくする大量データ
Reproは、マーケティングオートメーションを担うプロダクトです。
顧客のアプリやWebサイトにSDKとして導入していただき、 ユーザー行動などの大量のイベントデータを常時受け取ります。
受け取ったデータをもとにReproのシステムが計算を行い、プッシュ通知やメール、ポップアップなどをリアルタイムに配信します。
大量のデータを意図通り遅滞なく取り扱えることこそが、Reproの価値そのものです。 ですが一方で、この強みはプロダクトへの負荷が高いことも意味します。 導入サービスの規模やユーザーの利用頻度によって、システムにかかる負荷は大きく異なってしまうのです。
なぜ、1顧客あたりのコストをみたかったのか
私は不安でした、どこかのお客さんがとんでもない原価になっているんじゃないかと。営業やCSの皆さんが死ぬ気で取ってきた売上がどこかに流れ落ちていっているのではないか。新しいお客さんは大丈夫なのか...。
背景にあったのは、市場変化と事業成長にともなって生じる構造的な問題を解決し、意思決定スピードをあげるためでした。
① プロダクトと管理体制のギャップ解消 Reproツールは提供価値の拡大に伴い、システム構造も原価構造も複雑化しています。 ユーザーの利用頻度によってシステム負荷は大きく異なるため、もはや全顧客平均での原価率では、実態に即した収益性の判断が不可能になっていました。
② 競争環境下での意思決定の高速化 MA市場の成熟に伴い競争は激化し、スピード感を持った提案が求められます。 しかし、原価がブラックボックスの状態では、「この提案価格で本当に適切なのか？」という判断に時間がかかります。 結果として、経験豊富な一部のメンバーに判断が集中し、営業・開発双方のリソースを圧迫していました。
原価判断を属人化させず、事前に判断基準を持つことで、誰もが同じ前提で意思決定できる状態を作る。 それによって、意思決定スピードを上げることが目的でした。
原価を知ることは、単なるコスト削減ではありません。事業の足腰を強くし、顧客にながく価値を届け続けるための筋肉質なPLを作る第一歩なのです。
では、どうやって見えないコストを配分するか
そこで私は、インフラチームと協力し、以下のステップで「1顧客あたりの原価」を算出する仕組みを設計しました。
- コストの分類: 全体のコストを、利用量に応じて増減する変動費と、利用状況に関わらず発生する固定費に分類
- 変動費のタグ付け: AWSのコスト配分タグを使い、セグメンテーション機能・配信機能などに選り分け
- コストドライバーの特定（ここが最難関）: イベントデータ量がインフラコストに最も影響するという仮説を立て、顧客ごとのイベント数に比例して按分
変動費に固定費を加算することで、「1顧客あたりのインフラコスト」が判明しました！
原価が見えると、攻めの戦略が描ける
顧客あたりの原価を可視化する取り組みは「原価が高いから下げよう」という話ではありません。 重要なのはこれまで感覚値だった事象にファクトとして向き合えるようになったことです。
新規契約時の迷わないプライシングの実現 Reproではご利用規模に応じたプランを提供しています。 一方で、利用が始まっていない段階では、どの程度のリソース負荷がかかるかを予測するのは簡単ではありません。
原価構造がクリアになることで、カテゴリやユーザー数といった情報から、過去の傾向をもとに 営業担当者でもおおよそのインフラコストを把握できるようになりました。
これにより、健全な収益が見込めるケースと、価格や条件面で戦略的に踏み込むケースの判断基準を事前に設けることができるようになりました。
結果、営業チームは迷いなくアクセルを踏めるようになり、経験則に頼ることで生じていた負荷や摩擦の改善につながると考えています。
プロダクト戦略へのフィードバック 全体平均だけでなく「どの機能が、どういったユースケースになるとインフラコストを押し上げるのか」が可視化されました。
これにより、将来さらにデータ量が増えた際にも利益率を維持できるアーキテクチャへの投資など、戦略的な議論が可能になります。
おわりに
SaaSのユニットコストに向き合う仕事は、一見すると地味かもしれません。 流行りのAIも、派手な新機能開発もありません。
しかし、この地味な数字の積み重ねこそが、プロダクトの未来を守る確かなファクトになります。
ReproのProduct Planning Teamでは、こうした取り組みを通じて、プロダクトと事業をボトムアップで改善していく文化を大切にしています。 少しでも興味を持っていただけた方は、ぜひカジュアルにお話ししましょう！
