創業して 11 年が経過しました。失敗の経験も兼ねて、今回は、起業前に知っておきたかった SaaS 開発の重要チェック項目をまとめました。起業へのロードマップにも。時間の切り売りから脱却して、プロダクト成功のスピードを早めることができるのではないかと思います。
絶対覚える用語
進む前に、SaaS 用語を整理しておく。個人開発だとしても絶対に知っておいたほうがいい。
→ 横にスクロールできます
| 用語 | 補足説明 |
|---|---|
| LTV（顧客生涯価値） | 顧客がサービスに支払う総額の見積もり。これが高いとサブスクビジネスは強い |
| CAC（顧客獲得コスト） | 1 人のユーザーを獲得するのにかかる費用。広告費・営業工数・人件費など含む |
| OKR | 目標と主要な成果。定量的に進捗を測れるため、SaaS 開発の方針として取り入れると強い |
| リカーリング収益 | 継続的に発生する収益（サブスク型）。積み上げ式のため、事業の安定性が増す |
| ユーザーストーリー | ユーザーストーリーマッピング。ユーザーの行動ベースで要件を整理する手法。SaaS の UI/UX 設計や機能優先度に使える |
| 非機能要件 | パフォーマンス、セキュリティ、拡張性、可用性など。初期に考慮しておくと後の手戻りが減る |
それでは、SaaS 開発のチェック項目をまとめていく。「ちゃんとやれば失敗するほうが難しいんじゃないのか」というくらい、重要な項目。
CRUD とログインがある SaaS を作れ
最初から複雑なプロダクトを目指すと、進まない。まずはログインして、データを作成・取得・更新・削除できるものを作ること。それだけで SaaS の 8 割の基礎が身につく。Supabase や Firebase を使えばすぐに形になる。
認証
DB
リカーリング収益（毎月・年次の継続課金）積み上げろ
単発課金ではなく、継続課金モデルを選ぼう。毎月・年次などリカーリングで収益が積み上がるモデルは、LTV が高く事業が安定する。カード情報を預かるのはリスクなので、Stripe や Paddle で導入する。
Stripe Billing で定期・継続課金を簡単管理
B2B から始めろ。解約されにくい
個人向けではなく、法人向けを最初のターゲットにすることで、契約が長続きする。稟議を通してもらうことで、簡単には解約されない構造が作れる。
スロークエリ・認証・セッション・RLS は早めに触れ
後から修正が面倒になる部分。特に RLS（Row Level Security）を知らずにリリースすると情報漏洩につながる。Supabase などは RLS で堅牢性を保てる。
Supabase RLS
セキュリティチェックリスト
SaaS はスケールして仕組みを資産化しろ
自分が動かなくても売上が立つように、プロダクト・マーケ・サポートまで仕組み化すること。ソロ SaaS でも売上が積み上がる構造を目指す。
企業が「払わざるを得ないもの」を作れ
Nice to have ではなく Must have を作る。事業に組み込まれた SaaS は、簡単には切り離せない。業務に直結するほど強い。
業務理解 → 課題を言語化 → 解決策の仮説 → プロトタイピング
プロダクトは思いつきで作るのではなく、業務理解から入ること。顧客が本当に困っていることを言語化して、仮説を立てて、小さく検証する。
毎月 5 万円払う企業か？稟議が通るか？ROI を語れるか？
価格は市場ではなく、相手が得られる利益（ROI）で決める。B2B なら 5 万円以上の月額も普通。その分、課題解決力と提案力が求められる。
価格設定はコストでなく「相手の利益」
開発コストや人件費ではなく、導入した企業が得られる価値で価格を決めるべき。価値ベースのプライシングが基本。
経費で落としやすい設計にしろ
法人カードで落とせるように、請求書の発行や、事業用メールへの通知、法人管理画面などを整備すること。
課金設計・表示義務は初期から考えろ
特商法・資金決済法など、日本の法律は意外と厳しい。課金導線・キャンセルポリシー・返金ポリシーの明記など、初期から整えておく。
開発前にプロダクトに関係するリーガルを読め
サービス内容によって適用される法律は違う。本人確認が必要か、ポイント発行があるか、個人情報を扱うかなどで注意点が変わる。
個人開発 SaaS で気をつけるべき日本の法律
利用規約・ポリシーに同意した証跡は保存しろ
法的トラブルを防ぐため、いつ・誰が・何に同意したかは DB に保存する仕組みを作っておくこと。電子契約レベルではなくても最低限は必要。
要件を先に決めすぎない
完璧な仕様書を書こうとしても無理。最初から全部決めるのではなく、走りながら考えることが重要。
まずプロトタイプ → フィードバック → 必要な仕様だけを要件化
リーンな進め方がベスト。早く形にして見せ、実際の反応から必要な仕様を決めていくことで、無駄な工数を削減できる。
プライシング → 事業計画 → 販売戦略 → リリース
開発だけで終わらない。「売れる設計」から逆算してプロダクトを作る。価格設定・販売チャネル・営業フローまで見据えること。
フィードバックを受け取る仕組み（Discussions など）を用意
GitHub Discussions や Slack、Intercom など、ユーザーからの声を受け取れるチャネルを持っておくと改善が加速する。
GitHub Discussions 作成方法
