個人開発を11ヶ月続けてみて残った、6つの「名前のある」フレームワーク
プロダクトエンジニアをしているすずきゆーだい（@szkyudi）です。仕事の傍ら、「みらいぼ」という家計アプリを個人開発しています。
リリースしてから11ヶ月、いろいろなフレームワークや手法を試してきたのですが、振り返ってみると「これは本当に使ってよかった」と言えるものは6つに絞られました。今日はその地図を共有します。
先にお断りしておくと、この記事にオリジナルの手法はひとつも出てきません。全部、業界で名前が付いているもの——つまり、読んだその日から調べて使えるものだけです。そのかわり、実例の数字はすべて自分のアプリの実測です。
全体像はこんな感じです。プロダクト運営は6つの局面がぐるぐる循環していて、それぞれに主役のフレームワークがいる、という整理です。
立ち上げ … リーンキャンバス
需要検証 … MVP／コンシェルジュMVP
観測 … AARRR＋ノーススター指標
効果検証 … コホート分析＋事前登録
収益判定 … ユニットエコノミクス
転換 … Pivot or Persevere（→ 1に戻る）
順番に説明していきます。
1. リーンキャンバス（立ち上げ）
役割をひとことで言うと、仮説の台帳です。課題・提供価値・顧客・収益を1枚に書き出して、各ブロックに確度のラベル（未検証／状況証拠あり／実証済み）を付けて運用しています。
大事なのは「書いて終わり」にしないことでした。リーンキャンバスは、何が当たったかではなく何を賭けたかを先に書き残しておく場所です。なので、成功条件を後から直した記録も、確度を格下げした記録も、恥ごとキャンバスに残すようにしています。
実例をひとつ。立ち上げのとき「1週間継続率50%」という成功条件を書いていたのですが、運用してみると、このアプリは毎日開く道具ではなく「月1回、残高を更新して未来を確かめる道具」だと分かってきました。そこで成功条件そのものを修正して、直した事実と理由もキャンバスに残しました。間違った賭けの記録が残っているおかげで、同じ間違い方をしなくなった気がします。
2. MVP／コンシェルジュMVP・スモークテスト（需要検証）
リーンスタートアップ系の技法群で、役割はコードを書く前に需要を確かめることです。手作業で価値を届けて反応を見るのがコンシェルジュMVP、LPと価格表だけで支払い意思を測るのがスモークテストです。
いまはFP（ファイナンシャルプランナー）向けのtoB展開をこの流儀で検証しています。ヒアリング5人中2人が課題を自発的に語ったら次へ進む、LPで有料の意思表示が3件集まったら開発GO、という二段ゲートです。変換ツールも「作りたい気持ち」はあるのですが、依頼が実際に2件発生するまでは手作業でしのぐ、と先に決めました。
ちなみにこの思想、開発の順序にも応用できます。「検証に依存しないものから作る」——ヒアリングの結果で設計が変わりそうな機能は聞いた後に、何を聞いても変わらない機能（デモで見せる主役）は先に、という順番です。
3. AARRR＋ノーススター指標（観測）
AARRRは獲得→活性化→継続→収益→紹介の5段で事業を見る横断の地図、ノーススター指標は事業の本質を1つに絞った縦の照準です。地図だけだと全段を均等に磨きたくなってしまうし、照準だけだとボトルネックを見落とすので、2つセットで持つのがよさそうです。
そして照準は、業界の定番から借りずに自分のプロダクトの性質から導くべきでした。僕は定番のD1継続率（毎日開くアプリ用の指標）を追いかけて、毎朝赤点の成績表を見ているような気分になっていた時期があります。思い切って「2ヶ月連続で月次の残高更新に帰ってきた率」に差し替えたら、配下の施策の正解が全部入れ替わりました。「毎日開かせる工夫」を捨てて、「月1回を確実に迎えに行く通知」に投資が向かうようになりました。
地図のほうの効能もひとつ。先日「なんか調子悪いな」と感じたとき、AARRRの段で切り分けたら「獲得段の問題（給料日前スパイクの反動）で、アプリ側は無罪」と数時間で判定できました。感覚を段に分解できるのは、思っていた以上に安心感があります。
4. コホート分析＋事前登録（効果検証)
「その施策、効いたの？」を裁く層です。ユーザーを世代（コホート）で割って比較すること、そして判定日・合格ライン・撤退ラインを施策を打つ前に固定して、途中経過で打ち切らないこと（統計で「覗き見」と呼ばれるやつの禁止）。
コホートの効能は劇的でした。オンボーディング刷新の効果は世代比較で完了率63%→92%と出ましたし、平均継続率を層に割ったら「初期設定を完走できなかった人は復帰0%／答えまで到達した人は48%復帰」という二極が現れて、戦略が反転しました。平均は二極を隠すというのを、身をもって学びました。
事前登録のほうは、地味ですが個人開発にこそ効くと思っています。個人開発は判定する人と実装する人が同一人物なので、後から決める基準は必ず自分に甘くなります。課金画面を刷新したときは「表示があるのに購入ゼロが4〜6週続いたら差し戻す」を実装前に書いておきました。これがほとんど唯一の品質保証です。
5. ユニットエコノミクス（収益判定）
お金まわりの意思決定の最終審級です。払っていい獲得単価＝課金転換率×手取りLTV÷3。この「÷3」はLTV:CAC≧3という古典ルールそのままです。
うちの実例だと、この式で許容獲得単価を出したら、実際の広告の獲得単価はその10倍以上でした。正直、改善でどうにかなる差ではなかった。なので事前に決めていた判定日に、広告を獲得目的から降ろして、キーワード調査専用に縮小しました。
もうひとつ、データが薄いうちはLTVを期待値で語らずに、確定している下限だけを当てにするようにしています。うちなら年額課金の前払い分だけ。数字の一番の使い道は「伸ばす」ではなく「やめる」判断で、やめる判断を迫ってくる数字ほど、式と判定日を先に固定しておかないと直視できないなと感じます。
6. Pivot or Persevere（転換）
リーンキャンバスと対になる、出口側のフレームワークです。続けるのか、方向転換するのか、撤退するのかを、事前に定義した基準で判定します。
toB挑戦のゲートはこうです。ヒアリング合格かつ有料意思3件ならGO。課題は実在するけど解がズレていたら対抗案へPIVOT。課題自体が語られなかったらtoBは棚上げして、本体の高単価化に資源を戻す（NO-GO）。3つの出口を全部、検証を始める前に書いてあります。
「継続すれば成功する」という励ましをよく見かけますが、単一モデルの継続って線形にしか積み上がりません。実を結ぶのはモデルの変更を試し続ける継続で、その試行を規律にしてくれるのがこの基準だと思っています。
まとめ：6つは順に起動すればいい
一行でまとめると——リーンキャンバスが賭けを宣言して、AARRRとノーススターが現在地を教えてくれて、コホートと事前登録が真偽を判定して、ユニットエコノミクスがお金の可否を裁いて、ピボット基準が次の賭けを決める。この循環が、いまのところのプロダクト運営のOSです。
最後に、これから立ち上げる人へ。6つを最初から全部やる必要はないと思います。立ち上げ期に動くのは1と2だけで、ユーザーが付いたら3、施策を打ち始めたら4、お金が動いたら5、行き詰まったら6が順に起動してくる——というのが、この11ヶ月の実際の順序でした。統計の道具（信頼区間とか検出力分析とか）は4と5を支える部品なので、必要になってから覚えても間に合います。
次回は、この6つを実際に回している「手足」の話をします。運用のほとんどをAIに任せるために整備した配管——APIキーや分析基盤——の話です。
後編はこちら：
