見出し画像

プロダクト原価の考え方 〜SaaS経理・FP&A向け

Louis

「うちの原価、何が入ってるの？」
この質問に即答できないまま、毎月のPLを締めていませんか。

SaaS企業の経理・FP&Aがしんどくなる理由のひとつは、“原価”が曖昧なまま意思決定が進むことです。
そして曖昧な原価は、こういう事故を連れてきます。

  • 粗利が良いはずなのに、なぜかキャッシュが減る

  • 広告費を増やしているのに、利益が残らない

  • CSが疲弊しているのに「原価は低い」と言われる

  • 開発を増やしても「原価じゃなく販管費でしょ？」で終わる

  • 経営が見たい“単位経済”が作れず、会議が空回りする

結論から言うと、**プロダクト原価は“会計処理の話”ではなく“経営の設計図”**です。
ここを握ると、経理が「締める人」から「伸ばす人」に変わります。


1. そもそもプロダクト原価とは何か

プロダクト原価とは、ひと言で言えばこうです。

「その売上を生むために、プロダクトとして最低限必要なコスト」

ポイントは「最低限」と「プロダクトとして」です。
つまり、会社全体の運営費（人事・総務・経営企画・役員報酬など）まで無差別に入れると、原価は意味を失います。

SaaSの原価を考える目的は、粗利（Gross Margin）を正しく測り、改善点を特定すること。
粗利は投資家・CFO・事業責任者が最も見ている数字のひとつで、ここが曖昧だと「何を改善すべきか」が永久に決まりません。

2. SaaSの原価を分解する“王道フレーム”

SaaSの原価は、だいたいこの3つに分解できます。

2-1 提供コスト（Deliver Cost）

  • サーバー費（AWS/GCP等、プロダクト稼働に必要なもの）

  • 外部API利用料（メール送信、音声、OCR等）

  • 監視・セキュリティの必須コスト

  • 決済手数料（該当する場合）

2-2 サポート・運用コスト（Support / Ops Cost）

  • CSの人件費（オンボーディング、問い合わせ対応、運用支援）

  • サポートツール費（Zendesk等）

  • 導入支援の外注費（もしプロダクト提供に必須なら）

2-3 プロダクト提供のための“必須人件費”

ここが一番揉めます。結論はこう。

  • **「保守・運用・障害対応」**は原価寄り

  • **「新機能開発・将来投資」**は販管費寄り（または資産化対象）

つまり、既存顧客に価値を届け続けるために必要な工数は原価に寄せられます。
反対に、未来の売上を作るための投資は、原価に入れると意思決定が歪みます。

3. 「開発費は原価か？」問題の落とし穴

よくある地雷はこれです。

「エンジニアはプロダクトの人だから全部原価でしょ？」

これをやると、粗利が一気に悪化し、“プロダクトは儲からない”という誤解が生まれます。
その結果、経営はコストカットに走り、開発体制が弱り、プロダクトが負けます。

じゃあどうするか。
おすすめは、エンジニア工数を**“目的別にタグ付けして配賦”**です。

  • 障害対応、保守、運用 → 原価

  • 新機能開発、リファクタ、将来投資 → 販管費（または資産化）

  • 特定顧客向けカスタム → 原価 or 個別プロジェクト原価（別管理）

“正しさ”というより、意思決定のために分ける。ここが重要です。

4. プロダクト原価を作ると、経理の価値が爆上がりする理由

経理が「数字を出す人」で終わるのは、原価を“会計の箱”でしか捉えていないからです。
原価が作れると、あなたはこういう武器を持てます。

  • 粗利を“顧客セグメント別”に語れる

    • SMBはCS工数が重い

    • エンプラは導入支援が厚い

    • どちらを伸ばすべきかが決まる

  • LTV/CACの議論が現実になる

    • 粗利が適当だとLTVが幻になる

    • CACだけ精密でも意味がない

  • 「人を増やす」議論が納得感を持つ

    • CSを増やすべきか

    • どの顧客層に注力すべきか

    • “疲弊”を数字で救える

この状態になると、経理は“社内の攻めの参謀”になります。
転職市場でも評価されるのは、このタイプです。

5. 明日から使える：プロダクト原価の作り方（超実務）

5-1 まずは「原価候補」を棚卸し

  • インフラ費

  • CS人件費

  • サポートツール費

  • 保守運用のエンジニア工数

  • 導入支援費（必須分）

5-2 原価の基準を“文章”で定義

例：
「売上を維持するために必要な提供・サポート・運用コストを原価とする」
※この一文があるだけで、社内の揉め事が激減します

5-3 配賦キーを決める（完璧より継続）

  • インフラ：アクティブユーザー数、利用量、契約数

  • CS：問い合わせ件数、オンボーディング工数、顧客数

  • エンジニア保守：稼働時間割合（ざっくりでOK）

5-4 粗利を“見える化”して会議に出す

  • 粗利率の推移

  • 原価の内訳推移

  • 顧客セグメント別粗利（可能なら）

6. まとめ：人生が詰みそうな経理へ

経理って、責任感が強い人ほど苦しくなります。
「自分がやらないと回らない」
「締めないと会社が止まる」
その気持ちは正しい。でも、ずっと抱えたままだと燃えます。

プロダクト原価を整えるのは、あなたを楽にします。
なぜなら、“しんどさ”を構造に変換できるから。

  • CSがつらい → 原価が重い構造

  • インフラ費が増える → 利用構造の変化

  • エンジニアが疲弊 → 保守が増えている兆候

全部、数字で説明できる。
そして数字で説明できる人は、社内でも市場でも強い。

次に読む（おすすめ）

役に立ったら「スキ」で保存代わりにどうぞ🙏 次も同テーマで“型”を解説します。

📌 はじめての方へ： https://note.com/louis_/n/n7b27184d2788

いいなと思ったら応援しよう！