---
title: 知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ
tags: 
author: [Hidetaka Okamoto](https://www.docswell.com/user/hidetaka-stripe)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/2EVDNYP9EQ.jpg?width=480
description: 知らないと損する。 SaaSのマネタイズ手法と 請求管理のイロハ by Hidetaka Okamoto
published: February 01, 25
canonical: https://www.docswell.com/s/hidetaka-stripe/ZMXYXW-2025-02-01-165501
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/2EVDNYP9EQ.jpg)

Burikaigi
知らないと損する。
SaaSのマネタイズ手法と
請求管理のイロハ
岡本 秀高 ( @hidetaka_dev )


# Page. 2

![Page Image](https://bcdn.docswell.com/page/57GYK9P47L.jpg)

開発 / リソースの
優先順位


# Page. 3

![Page Image](https://bcdn.docswell.com/page/4EQMNW2RJP.jpg)

その開発 / リリースは
売上・収益に
どんな影響を
あたえるか？


# Page. 4

![Page Image](https://bcdn.docswell.com/page/KJ4VGKLQE1.jpg)

自分のブログに
Stripeを導入
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/LE13DXLLJG.jpg)

頼まれて作った
Payment Links
の方が売上ある
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/GEWPYNVQJ2.jpg)

システム・サービス開発あるある
開発量と
売上・収益は比例しない


# Page. 7

![Page Image](https://bcdn.docswell.com/page/47ZKX34373.jpg)

短期間での収益化と
そのための開発リソースの確保が求められている
開発リソースの確保は経営課題
経営幹部の
61%
が、
優秀な開発者の確保は成功にとっ
て重要な課題だと回答
短期的な収益性の改善がより重要
73%
●
●
短期的な売り上げの向上
コスト削減と効率化


# Page. 8

![Page Image](https://bcdn.docswell.com/page/YJ6Q4X3ZJV.jpg)

プロダクトの
開発・運用リソースは
収益性に影響を受ける


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GJ5RQXL974.jpg)

SaaSのマネタイズで
絶対にやるべきこととは？


# Page. 10

![Page Image](https://bcdn.docswell.com/page/9E2DPXL5ER.jpg)

A: 顧客に料金を請求する


# Page. 11

![Page Image](https://bcdn.docswell.com/page/D7Y258Q67M.jpg)

立ち上げ期では、マネタイズが後回しされやすい
● 開発リソースがコア機能の実装分しかない
● 顧客が使ってくれる・課金するかわからない不安
→ 請求を行わない「ベータ提供」としてローンチ
マネタイズ実装を、「リリース後」に検討開始
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/VEN8NQ21J8.jpg)

マネタイズ検討を後回しすると起きる弊害
● DB構造と料金モデルの不整合による DBテーブル追加
● 従量課金に必須の「請求根拠の利用データ」がない
● ベータ版の無料アクセスと
トライアルや無料オファーユーザーの判別
● そもそも検討した料金モデルが PMFしていない
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/Y79KRD1Y73.jpg)

作らずに
請求を始める
UnsplashのSenが撮影した写真


# Page. 14

![Page Image](https://bcdn.docswell.com/page/G78RW34KED.jpg)

α版 / β版ではフォーム + メールで申し込みを処理


# Page. 15

![Page Image](https://bcdn.docswell.com/page/L7LKNV6PER.jpg)

申し込み後の業務フローや連携だけまず実装する
メール通知で
支払い状況などを社内共有
Webフォーム
ダッシュボードで
サブスクを手動作成
メールで
支払い等の案内を顧客へ
Webhookで
申し込み情報処理の
カスタムワークフロー
15


# Page. 16

![Page Image](https://bcdn.docswell.com/page/4EM2XG52EW.jpg)

ローコード型の決済フォームで、申し込みを自動化
個別の商談
ダッシュボードで
手動の申し込み処理
サブスクリプション作
成
メール通知で
支払い状況などを社内共有
メールで
支払い等の案内を顧客へ
Webhookで
申し込み情報処理の
カスタムワークフロー
16


# Page. 17

![Page Image](https://bcdn.docswell.com/page/PERMNZ3579.jpg)

独自のデザインやフローを実現するための API組み込み
個別の商談
ダッシュボードで
手動の申し込み処理
サブスクリプション作
成
独自の
決済フォーム
メール通知で
支払い状況などを社内共有
メールで
支払い等の案内を顧客へ
Webhookで
申し込み情報処理の
カスタムワークフロー
17


# Page. 18

![Page Image](https://bcdn.docswell.com/page/P7XVN94XJX.jpg)

状態変化 ( =イベント )をトリガーにしたシステム設計
E vent
D riven
A rchitecture
https://aws.amazon.com/jp/what-is/eda/


# Page. 19

![Page Image](https://bcdn.docswell.com/page/37KQNPZ97D.jpg)

イベント駆動アーキテクチャにすると、
さまざまなフローからの申し込みに対応できる
ダッシュボード
ローコード
フォーム
API
メール通知で
支払い状況などを社内共有
サブスクリプション
作成イベント
メールで
支払い等の案内を顧客へ
Webhookで
申し込み情報処理の
カスタムワークフロー
19


# Page. 20

![Page Image](https://bcdn.docswell.com/page/LJ3PVXD975.jpg)

変化に対応するため、決済・請求系は疎結合に作る
● システムは決済の「後」から設計する
○ DB更新・社内通知・CRM連携etc…
○ Q: 申し込み後、やるべきタスクはどれだけある？
● 決済・申し込みUIは、作り替え前提にする
○ 最優先は市場に出して、ちゃんと売ること
○ EDAによって、UIの変更をより簡単に
20


# Page. 21

![Page Image](https://bcdn.docswell.com/page/8JDL82P87G.jpg)

もう1つの
見落としポイント


# Page. 22

![Page Image](https://bcdn.docswell.com/page/VEP281NWE8.jpg)

獲得した売上は
全て会社の口座に入ったか？


# Page. 23

![Page Image](https://bcdn.docswell.com/page/27VDNYK97Q.jpg)

売れても現金がないと、事業は続かない
● 経営が黒字でも倒産することはある（黒字倒産）
○ 倒産企業の 45%近くが黒字倒産
● 売り上げを増やすだけでなく、
「お金を確実に回収すること」も事業貢献
● 入金が遅い / 未払いや回収不能の売上はいくらある？
* https://mfkessai.co.jp/startup-article/prevent-black-ink-bankruptcy
23


# Page. 24

![Page Image](https://bcdn.docswell.com/page/5JGYK9Q4JL.jpg)

実際にあった請求まわりのアレコレ - 1
● 年間支払いのプランをリリース
● チャージバック・不審請求が発生する
● 調べると、現在進行形で使っているユーザー
● チャージバックの対応手数料やサポートの手間が ...
→ 顧客が契約を忘れないための通知や案内は十分？
24


# Page. 25

![Page Image](https://bcdn.docswell.com/page/47QMNWKREP.jpg)

カード明細の表記は
ブランドと一致していま
すか？
長期サイクル支払いは
事前にリマインドを
いれていますか？


# Page. 26

![Page Image](https://bcdn.docswell.com/page/KE4VGKPQ71.jpg)

実際にあった請求まわりのアレコレ - 2
● サービスをリリースした
● 契約数・ MAUに対して実売上が少ない
● 決済エラーで未払いになっているユーザーが
最長半年以上そのままになっていた
→ 請求期日や決済成否の監視と通知は十分か？
26


# Page. 27

![Page Image](https://bcdn.docswell.com/page/L713DX9LEG.jpg)

通知機能や
Webhook連携で
決済でも Observability


# Page. 28

![Page Image](https://bcdn.docswell.com/page/G7WPYNQQE2.jpg)

請求管理や回収フローも、実は EDA
未払い
期日超過
チャージバック
社内通知
イベント
顧客への連絡やリマインド
カスタムワークフロー
28


# Page. 29

![Page Image](https://bcdn.docswell.com/page/4JZKX3W3J3.jpg)

請求管理や回収フローも、実は EDA
未払い
イベントがあるなら
監視ができる
期日超過
イベント
チャージバック
社内通知
顧客への連絡やリマインド
カスタムワークフロー
29


# Page. 30

![Page Image](https://bcdn.docswell.com/page/YE6Q4XGZEV.jpg)

プロダクトの収益性も、重要な監視対象


# Page. 31

![Page Image](https://bcdn.docswell.com/page/GE5RQXV9J4.jpg)

可視化・監視・ Ops化
● ダッシュボードや SQLによる現状の可視化
○ 売上・収益モデルの現状を把握する
● APIやWebhookで連携と検知が容易に
○ 決済や請求管理、売上情報などの変化を監視する
● 「見える化」したものは、 Opsにできる
○ 収益にまつわる Ops = Revenue Operation ( RevOps )
31


# Page. 32

![Page Image](https://bcdn.docswell.com/page/972DPX357R.jpg)

短期での収益化や成長を目指すために
● プロダクトの MVPをリリースする
● まずは手動で顧客と売上を 10件獲得する
● 申し込みフローを自動化し、成長を目指す
● 売上回収やアップセル・クロスセルへの挑戦
● RevOpsによる取り組みのアジャイル化
32


# Page. 33

![Page Image](https://bcdn.docswell.com/page/DJY25816JM.jpg)

システム開発から商品開発へ
● 「売上は全てを癒す 」 by ダイエー 中内氏
● 今の売上や収益性を把握していますか？
● システムは売るための施策に耐えれますか？
● 現在位置とゴールを観測可能（Observable）にして
BizとTech両サイドからサービスを成功に導こう！
33


