最初より速い2回目、累積資産の活用法

2回目のMVPの本当の強みは、シーズン1の作業の「残りかす」だ。

14日 → 9日、その差はどこで生まれるか

パク・ソヨンさんは最初のMVPをLovableで14日で出しました。マーケコラム自動分類SaaS、100人登録、30人アクティブ、5人有料。半年後、2回目のMVPを始めました。同じドメイン、マーケSNSコンテンツのパフォーマンス分析ツール。

1回目に必要だった作業を振り返ります。

• ログイン画面? 1回目でSupabase認証を統合済み、スニペット1つでOK
• API構築? 1回目でClaude API連携経験あり、同じパターン
• DBスキーマ? 1回目の振り返り資料を開いて「今回はこの部分は不要、抜こう」
• デザインシステム? 1回目のFigmaコンポーネントをそのまま持ち込み、2時間でプロトタイプ

結果は9日。14日からほぼ半分に。

大事なのは、速くタイピングしたわけではないこと。賢く決定したのです。何を飛ばし、何を再利用するかを、すでに知っていたから。

2回目のMVPは速いのではなく、賢いのです。その賢さの源は最初に残った資産たち。

最初のMVPで残った4つの資産

1. コード:動いたパターンの集まり

最初のMVPのコードはレガシーで合っています。半年後には自分のコードも読めないほど。それでもコードが資産な理由は、「何かが動いたパターン」が残っているから。

パクさんが再利用したのは正確にはコードではなく、「Supabase認証はこういう作り」というパターン、「Claude API呼び出しはこんな構造」というパターンでした。CursorやClaude Codeはこのパターンを認識して次のMVPに自動で適用してくれます。

1回目のプロジェクトのコードは、2回目のプロンプトの文脈になります。「この機能を作るとき、まずこの構造を確認して」というヒントになる。

2. 関係:信頼できる人のリスト

最初のMVPリリース後、パクさんをDMで探した人は100人。アクティブ30人。本当に大切だったのは5人。毎週フィードバックをくれて、機能を一緒に考え、自分のネットワークにパクさんを紹介してくれました。

2年後、パクさんが5本目のMVPを企画するときいちばん最初にしたことは何か? この5人へメッセージ。3人がすぐ反応、2人がテストを名乗り出る、1人が友達紹介。すでにあなたを信じている人がいるのです。

冷たく集めた顧客100人の月3回以上アクティブ率は37%。コミュニティで温かく紹介された顧客40人のアクティブ率は68%。

3. ノウハウ:罠の地図と迂回路

パクさんは最初のMVPでデータベーススキーマを過剰設計してしまいました。カラムを3回修正、マイグレーションに2日浪費。振り返りメモ:「次回はMVP段階では『必要不可欠なもの』だけ入れて、ユーザーフィードバック後に追加しよう。」

2回目のMVPで同じ過程を繰り返しません。最初から「フィードバック後に追加」と「今絶対必要」を分けた。初期スキーマは50%シンプル、マイグレーションコストは最低限。

「2回目は1回目のノウハウをそのままなぞれば良い」と思うと失敗します。大事なのはパターン認識。罠の1つが別の状況で繰り返されたとき、それをルールに変えるべき。

4. ツール:設定済みのワークフロー

パクさんが最初のMVPで使ったツール:Cursor、Figma、Supabase、Vercel、Linear、Notion。2回目も同じツール。でも今回は設定がすでにできていた。Cursorは前のプロジェクトの拡張機能とカスタム設定を自動認識。Figmaライブラリは整列済み。Supabase分析ダッシュボード5分でセット。

パクさんは1回目で「このツールは自分のワークフローに合わない」ことも学びました。最初に計画していた管理ツールをやめ、2回目は最初からLinearだけ。選択肢が減って集中力が上がりました。

意識して積み上げる、作業中メモの力

4つの資産は自動では積み上がりません。意識的な記録が必須です。

パクさんは最初のMVP開発中、毎晩10分で3つを記録しました。

1. 今日何をしたか:「ログイン統合完了」「DBマイグレーション2回目」
2. 何が遅かったか:「スキーマ再設計で2時間ロス」「Figmaフィードバック1時間」
3. 次は何を違うやり方にするか:「スキーマはユーザーフィードバック後に追加」「デザインはプロトタイプ前に協力者チェック」

3文だけのNotionページでしたが、14日終了時点で振り返りの型が完成。パクさんはこのメモを「2回目MVPチェックリスト」に変換しました。

2回目のMVPを速く作るチェックリスト:
- スキーマ:フィードバック前に必須項目のみ(以前4個→2個に)
- デザイン:コンポーネントライブラリを先にコピー
- 関係:初期ユーザー5人に先に聞く
- ツール:検証済みの組み合わせのみ(新規ツールはNG)

このチェックリストが9日を作ったのです。

14日 vs 9日、時間別の分析

いちばん大きな節約:

1. 企画:スキーマ簡素化で8時間節約
2. UI:コンポーネントライブラリで4時間節約
3. デザイン:手に馴染んだデザインシステムで8時間節約

資産再利用ワークフロー

Step 1. MVP終了直後(1〜2日以内)

やらないこと:すぐマーケに全振り / 新機能追加(フィードバックなし)

やること:

• コードを一度読む(30分):「どのパターンが動いたか」
• ツール設定のスクショ(30分)
• 初期ユーザー5人リストの整理(30分):名前、連絡先、解いた問題
• 開発日誌から「2回目でやらないこと」を抽出(1時間)

Step 2. 運用中(1か月以上)

• フィードバックで出なかった機能:「誰も使わなかった」→ 次は外す
• もっとも修正した部分:「ここを3回変えた」→ 次はまずユーザーに聞く
• 時間がかかった部分:「収益性なしで時間がかかった」→ 優先度を下げる

Step 3. 次のMVPを始める直前(1日前)

1. コード:最初のプロジェクトのレポを開いて「パターンだけ持ち出す」とCursorプロンプトに
2. 関係:初期ユーザー5人に「次のアイデアを見てくれる?」とメッセージ
3. ノウハウ:チェックリストを読みながら「この過程はスキップ」を決める
4. ツール:検証済みのツールセットを先にセットアップ

9日コースのタイムライン

まとめ

2回目のMVPが速い理由は、単に時間管理ではありません。あなたがすでに賢くなっているからです。最初の14日が作った資産が、次の9日を作ります。

でも気をつけることがあります。速くなったのは良いけれど、同じミスをまた犯したら? もっと速く同じ罠に落ちます。次の記事では「二度見た失敗はパターンだ」という原則で、自分の失敗を事前に防ぐ方法を扱います。

前の記事:Persevereの罠
次の記事:同じミスをしない方法、パターン認識の技術

パク・ソヨンについて
パク・ソヨンはフェイルスクールが作った架空のペルソナです。ただしGitHub Copilotの生産性レポート、Pieter Levelsのシリーズビルダー事例などはすべて実在のものです。

キム・ミンチュル、Freeive CEO、フェイルスクール