データを見て直す（PDCAループ）

このレッスンで終わる頃には

• 「勘で直す」と「データで直す」の違いが分かる
• ファネル分析で穴を1つ見つけて、仮説→改善まで1サイクル回せる
• ABテストの本質と、ソロ開発で現実的にできる範囲が分かる

勘で改善するのは、レントゲンなしの手術

公開して、MCPで数字が見えるようになりました。

ここで多くの人が、こう思います。

なんとなく、ここを直したらいい気がする。

これがいちばん危ない。

Shin氏の比喩がすごく的確だったので引用します（医療職の方には特に刺さるはずです）。

例えるならば、人間が病気にかかって、その病気を直しましょうと。 ですけど病気の原因分からないから、とりあえず片っ端しから、ここかなみたいなちょっと感覚で なんか手術始めたりとか、お薬処方したりとか、そういったことをやってたわけです。

ですけど、そういった病気を直すにはまずはその人に問診をして、 例えばレントゲン取ったりとか、体温測ってみたり、血圧測ってみたり、 それで、ここなんじゃないかなっていう当たりをつける。

ソロプレナー入門の動画 より。

これ、アプリ改善でも同じです。データを取らずに直すのは、暗闇で手探りの手術と同じ。

ファネル分析の基本

ファネル（Funnel）= ロート。アプリ内で、ユーザーが下に進むほど数が減っていく構造のことです。

例：

ランディングページ訪問     1000人 ████████████████████
   ↓ （80% 離脱）
新規登録                    200人 ████
   ↓ （50% 離脱）
初回利用                    100人 ██
   ↓ （90% 離脱）
有料プラン                   10人 ▌

このとき、いちばん大きな穴 がどこかが見えれば、改善のインパクトが最大化されます。

「LP→新規登録の80%離脱」を 80%→60%に減らせれば、登録ユーザーは2倍になる。「初回利用→課金の90%離脱」を 90%→80%にしても、課金ユーザーが2倍になる。

全部直す必要はない。いちばん大きな穴を1個ずつ。

仮説の立て方

穴が見つかったら、次は 「なぜ離脱してるか」の仮説。

仮説の立て方は3パターン。

パターン1：ユーザーの気持ちに想像力を働かせる

「LP→新規登録で80%離脱」を見て、自分がそのユーザーだとしたら、

• 「メールアドレス入力が面倒」
• 「何ができるのか分からない」
• 「料金が不明」
• 「個人情報を取られそうで怖い」

このうち1つが原因と仮定して、そこを直してみる。

パターン2：他のサービスと比較する

同じ機能を提供してる他社サイトを5つ見て、自分のサイトと比べてみる。

• 認証は何ステップか？
• LP に何が書いてあるか？
• ボタンの色・文字は？

「自社だけ違う」部分が、たいてい穴の原因です。

パターン3：Claude Code に分析させる

これがいちばん早い。MCPで取ったデータを Claude Code に渡して：

このファネルデータと、自分のサイトのページHTMLを見て、 どこに離脱の原因がありそうか仮説を3つ出してください。

これで、自分が思いつかない角度の仮説が出てきます。

改善の例

仮説ができたら、最小限の変更で試します。

例1：LP→新規登録の離脱が多い

例2：初回利用→継続の離脱が多い

例3：課金転換率が低い

Shin氏は「マイクロコピー（小さな文言）の修正だけで売上が1.3倍になることもある」と言ってます。コードに大変更を加えなくても、直せる場所はたくさん あります。

ABテストの本質と、ソロ開発の現実

「ABテスト」をご存知の方も多いかもしれません。

理想は、1箇所だけ変えて、他を全部固定して、数週間置いて、結果を比較する こと。

ただ、ソロ開発では現実的に難しいです。

理由：

• 1箇所だけ変えるのに数週間かけると、その間アプリが進化しない
• そもそもユーザー数が少ないので統計的有意差が出にくい
• 他の機能も並行で改善したくなる

なので 「厳密なABテスト」ではなく「テストマーケティング」 くらいの精度で進めるのが、ソロ開発の現実です。

仮説を立てる → 直す → 数日見る → 良くなった気がしたら採用、ダメなら戻す

これでも、勘で直すよりは100倍ましです。

PDCAループの作り方

   ┌─────────────────────────┐
   │                              ↓
 [Plan]                       [Check]
 仮説を立てる            数字で結果を見る
   ↓                              ↑
 [Do]                         [Act]
 最小限の変更             採用 or 戻す
   │                              ↑
   └─────────────────────────┘

これを 毎週のルーティン にします。

これを 3〜6ヶ月続ける と、初期からは別物のアプリになります。

逆に「公開して数字を見ない」と、3ヶ月で諦めることになります。改善ループ＝ソロ開発の生命線です。

モチベーションの話

ここまで読んで、「データ分析って地味だな」と思った方。

正解です。実際、地味です。

ただ、Shin氏も動画で言ってましたが、仮説が当たったときの嬉しさが、ゲームみたい でハマります。

「あの仮説のおかげで離脱が3%下がった」 → 月の売上が3万円から3.5万円に → 自分の判断が数字に効いた

これが、給与で1万円上がるのを待つよりずっと早く、自分でコントロールできる。

ソロ開発の隠れた楽しみは、ここにあります。

今日の宿題

Lesson 06でMCPを繋いだあなたへ。

データが1週間以上溜まってきたら、

1. ファネル分析で いちばん大きな穴 を1つ特定
2. その穴の原因仮説を3つ立てる（自分で / Claude Codeに頼んで）
3. 仮説1つを最小限のコード変更で試す
4. 1週間後、数字が動いたか確認

公開直後でデータがまだ少なければ、Lesson 09の「広げる」が先かもしれません。柔軟に。

次のレッスン予告

最後の Lesson 09 は 同僚・家族・地域に広げる。

公開して改善ループが回り始めたら、次は人を呼ぶ段階です。SEO・SNS・口コミ、ソロ開発でできるマーケティングを軽く扱います。

完成したらお知らせします。