リリース前のバリデーション戦略: 兼業 micro SaaS の判断軸
兼業 micro SaaS の週 20 時間でコードを書く前に仮説をどう絞るか。3 層の仮説分解と、LP・既存ツール観察・直接ヒアリングの使い分け、開始しきい値。
兼業ではバリデーションの重みが変わる
フルタイム独立なら 100 時間使って外しても 1 ヶ月で済むが、業務外 20 時間/週で動く兼業では 100 時間 = 5 週間になる。誤った仮説で 100 時間動いた瞬間、四半期の半分が消える。だから兼業 micro SaaS では「コードを書き始める前に仮説をどこまで絞るか」の重みがフルタイム独立より明らかに大きい。
私は受託テックリード本業で、業務外で gpdf / gsql / renma を回している (運営構造の詳細は nadai ecosystem の記事)。20 時間しか取れない前提で、書き始める前に何をどこまで検証するかを 2-3 個のプロジェクトで試行した結果が、ここに書く運用だ。
ただし慎重すぎても 1 年何も出ない、という対側の失敗も見てきた。バリデーションは「やる/やらない」ではなく「どこまでやってから書くか」のしきい値設計の問題だと感じている。
仮説を 3 層に分ける
漠然と「市場を検証する」と捉えると、検証手段の選択を誤る。私は仮説を 3 層に分け、層ごとに違う手段を当てている。
- レイヤー 1: 課題は存在するか — 困っている人がいるか
- レイヤー 2: 自分の解決策の方向性は成立するか — 自分が出せるアプローチが解になるか
- レイヤー 3: 価格を払う意志があるか — 月額 $X を実際に払うか
層が下に行くほど検証コストが上がる。レイヤー 1 は数時間で済むが、レイヤー 3 は実際の課金イベントを取らないと証明にならない。「どの層までを開始前に確認するか」を意識して切ると、20 時間しかない週でも判断が早くなる。
レイヤー 1: 課題の存在 — 数時間で確認できる
レイヤー 1 は既存ツール調査と検索クエリ観察で大部分が片付く。
gpdf の場合、レイヤー 1 の確認は実質 2-3 時間で終わった。Go の PDF ライブラリ事情を調べると、gofpdf は 2021 年にアーカイブ、その fork である go-pdf/fpdf も 2025 年にアーカイブ済み、UniPDF は商用ライセンス、gopdf と Maroto は gofpdf 依存系 — Pure Go で active かつ permissive な選択肢が事実上空白だった。これだけで「課題は存在する」が言える。Stack Overflow と Reddit r/golang で関連質問が定期的に流れていることも傍証になった。
この層で時間を使いすぎないこと。私は過去に「課題があるかどうか」だけで 2 週間調べたことがある。結論は数時間で出ていた。残りの 1 週間半は「自分が決断する勇気を出すための補強材料探し」で、検証ではなかった。
レイヤー 2: 解決策の方向性 — 動くプロトタイプを早く出す
ここが兼業勢にとって一番難しい層だ。LP だけ作って様子を見る、というのが従来の定石だが、私の手元では LP 単独はほぼ機能しない。
過去に 1 度、SaaS の LP を出して 3 週間流したことがある。集まったメールアドレスは 5 件で、本気で問い合わせまで来たのは 0 件だった。LP の「興味あります」と「実際に試す」のあいだの溝は、私の経験では深い。
代わりに効いたのが 動くプロトタイプを早く GitHub で公開する ことだった。gpdf は v0.x の段階で公開している。README に「これができる/これはまだできない」を正直に書いた状態で出すと、issue や discussions に「これ使ってみたが X が欲しい」「Y のユースケースで困った」が来る。LP の「興味あります」よりも、プロトタイプへの issue のほうが解決策の方向性検証として圧倒的に解像度が高かった。
ただしこの方法は OSS 前提で、純 SaaS には応用が効きにくい。SaaS の方向性検証は次のレイヤー 3 とほぼ重なるので、私は「OSS で出せるなら OSS から始める」を兼業の戦略にしている。gpdf-api のような派生 SaaS も、まず gpdf 本体を OSS で公開してから派生を作る順序にした。
レイヤー 3: 価格意志 — 直接ヒアリングか課金ボタン
「月額 $X を払うか」の検証は、メールでも LP でも取れない。理由は、人は仮定の質問に対して善意で「払う」と答えるが、実際の請求書を見せると 8 割が降りるからだ。
ここで効くのは 2 つしかないと感じている。
- 1on1 のヒアリング — 30 分話を聞かせてもらい、終盤で「いま $X/月の予算を取れるか」を直接聞く
- 実課金イベント — 課金フォームを置いて、実際にカードを切る人を待つ。ベータでも有償にする
兼業 20 時間で動いている前提だと、1on1 を 10 件積むのは 1 ヶ月以上かかるので、現実には 5 件で打ち切って実課金フォームに進む、という運用にしている。5 件のうち 3 件が予算を取れる雰囲気を出したら GO、3 件未満なら戻る。雑なしきい値だが、サンプル 10 を待つコストが兼業では大きすぎる。
私は gpdf-api でこのレイヤー 3 にまだ到達していない。なので上の運用は「これからやる手順」であって「やってきた結果」ではない。半年後に検証してまた書く。
コードを書き始めるしきい値
3 層の整理から、私が兼業で使っているしきい値はこうなる。
- レイヤー 1 + 2 が確認できたら、コードを書き始めて良い
- レイヤー 3 はコードを書きながら並行検証する
- ただし「最初の課金イベントを 90 日以内に取れるスコープ」に最小機能を切る
90 日というのは私のしきい値で、根拠は薄い。だが 90 日を超えるスコープを切ると、レイヤー 3 検証より前にコードが膨らみすぎて「使われない機能を作る」リスクが復活する、という感触がある。20 時間/週 × 12 週 = 240 時間。これが兼業で「外したと分かるまでに費やしてよい上限」として、いまは固く守っている状態だ。
失敗例: 200 時間使ってリリース直前に降ろした 1 件
数年前、業務外で書きかけた小さな SaaS を 1 個畳んだ。週末を中心に 4 ヶ月、累計で 200 時間ほど。リリース直前のベータ配布段階で「これは誰も使わない」と分かって降ろした。
何が悪かったかは明確で、レイヤー 1 (課題はある) を確認したあと、レイヤー 2 と 3 を飛ばしてレイヤー 4 (実装) に進んだ。LP も出していないし、誰にも話を聞いていない。「動くものができれば反応が取れる」と思っていた。
実際にベータを 5 人に渡した結果、3 人は触りもせず、2 人は「便利だが今は要らない」だった。「今は要らない」は「価格意志ゼロ」の婉曲表現だと、その時に学んだ。レイヤー 1 と 2/3 のあいだに巨大な溝があることを、200 時間払って体得した。
正直に書くと、200 時間のうちどこからが無駄だったかは今でも明確に切れない。最初の 50 時間で出した試作は学びになった気もするし、結局そのコードは 1 行も再利用していない気もする。とりあえず「レイヤー 2/3 のいずれかを飛ばしたプロダクトは書かない」と決めて、それ以来ぶれていない。今のしきい値運用はこの失敗の輪郭を踏んでいる。
質問への応答
「フルタイム独立なら全部最初に検証すべきでは?」
たぶんそうだ。フルタイムなら 1on1 を 10 件積む時間が取れる。私のしきい値は「兼業 20 時間で取れる範囲」に最適化されているので、フルタイム前提で読まないでほしい。フルタイム独立の人は、レイヤー 3 を 10 件積んでから始めるほうが期待値は高いと思う。
「LP テストはもう古いのでは?」
私は LP 単独では機能しないと書いたが、無価値とは思っていない。レイヤー 1 確認の補助線としては有効だし、後続のヒアリングや課金ボタンへの誘導には使える。「LP 単独でレイヤー 3 を取れる」という前提が古い、という言い方が正確かもしれない。
「OSS で出せないアイデアはどう検証するか?」
私の運用が OSS 寄りなので、純 SaaS のみのアイデアにはそのまま使えない。その場合は「動く小さな機能だけ無料公開して、上位機能を有料」の形 (= プロトタイプの代替) に切るしかないと感じている。私自身は OSS から派生を作る経路を選んでいるので、純 SaaS バリデーションは経験していない。経験のある書き手の記述に頼るほうが良い領域だ。
次のステップ
これは 2026 年 5 月時点の運用で、レイヤー 3 の検証は手元に実績がない。半年動かして外したらまた書く。