同じミスをしない方法、パターン認識の技術

初めて見たミスは罠、二度目に見たミスはパターンだ。

2回目もまた迷う

パク・ソヨンさんは最初のMVPのあと、5人が有料会員になるのを見ました。1年経って新しいアイデアで2回目のMVPを作り始めました。

2回目のプロジェクトは最初より明確に見えました。最初の失敗を繰り返さないと決意していたから。でも同じミスはしませんでした。違うミスをしたのです。1週目まではうまく行きましたが、3週目にまた方向を見失いました。

パクさんは気づきます。「私は同じミスを繰り返しているのではなく、似たパターンを繰り返しているみたい。」

1回目と2回目のミスは違うけれど、根っこは同じ。それに気づくことがパターン認識です。初めて見たミスはただの罠。二度目に見たミスは自分自身のパターン。

メイカーがよく繰り返すミスのパターン7つ

1. 機能の過剰(Feature Creep)

もっともよくあるパターン。最初はコア機能3つで始めるつもりが、開発中に「この機能もあったらいいな」と考えてしまう。そうやって増えていき、リリース予定がずれます。イ・ジュノさんのAIプロンプト管理ツールも最初は保存 + 検索だけだったのに、タグ・バージョン管理・コラボまで欲を出した。幸い10日でブレーキ。

2. 顧客検証の不足(Validation Skipped)

開発中にユーザーインタビューができない。あるいはやっても「いいね」という1〜2文のフィードバックだけ。リリース後に「あれ? 誰もこの機能を使わない?」と発見。100人中5人だけ有料化してから「自分の仮定が間違っていた」と気づきます。

3. 時間見積もりの過剰

「Lovableで3日あれば」と計画。実際は統合・テスト・想定外のバグで5日。2回目でも自信はある。「1回目はやったことがなかっただけ、今回はできる」と思うけれどまた延びます。

4. 価格設定のミス(Pricing)

最初のユーザー5人から月$9.9を取れたから、次のMVPも同じ価格構造で仮定。市場も顧客も違うのに。あるいは高すぎて初日加入0。価格設定は小さな改善に見えるけれど、2回目のビジネスの収益を大きく左右します。

5. データ追跡の漏れ(No Metrics)

最初のMVPで何が動いて何が動かなかったかの記録がない。ユーザーがどこで離れたか、どの機能を使っているかを測らないと、2回目も推測のみになります。

6. 協業の不在(Solo Feedback Loop)

自分の考えだけで判断。友達・オンラインコミュニティ・購入意向のある顧客との対話なし。「これは良いアイデアだ」という確信だけで検証がない。

7. 完璧主義の罠(Perfectionism)

MVPなのに「正式版のような完成度であるべき」と考える。デザイン、コピー、エラー処理まで完璧にしようとして期間が延びます。2回目のMVPでもシーズン1で学んだ「最小」の意味を忘れる。

パターンが見え始める瞬間

韓国のノーコードスタートアップをいくつか追いかけると、最初と2回目の事業が同じ場所で失敗します。時間が違うだけ。最初は4週後に機能の過剰で詰まり、2回目は3週後に同じ理由で。一度見た罠なのに、同じサイズの罠にまた落ちる。

違いはこんなに小さい。自分のミスを意識的に分類したかどうか。「あ、これが自分のパターンだ」と命名すれば、2回目はずっと早く見えます。

パターン認識の始まりは反省(reflection)ではありません。カテゴリ化(categorization)です。

多くのメイカーは「機能を作りすぎた」とぼんやり整理します。これだけではパターンではありません。パターンになるためにはルールに変換される必要があります。

たとえば「機能の過剰」パターンなら、2回目のMVPキックオフで:

• 「このMVPのコア機能は正確に3つ。それ以上はすべて将来バージョンへ。」
• 「毎週木曜の午前に、機能リクエストが何件来たかをログ。10件以上ならシグナル。」

こうルールに変換すれば、3回目のMVPで気づくのではなく、2回目で防げます。

最初のMVPの振り返りから自分のパターンを抽出

シーズン1で学んだ振り返りの方式(KPT、5 Whys)をもう一度出します。今回は違うふうに読む必要があります。

たとえば最初のMVPのKPT振り返り:

• Keep:「早い意思決定」
• Problem:「機能が増え続けた」「ユーザーフィードバックを遅く受けた」「デプロイが何度も延びた」
• Try:「次はもっと顧客に会おう」

この3つを見ると、パターンは「スピード vs 検証」の不均衡です。早く決めたが検証なしで開発した。

これをルールに:

• ルール1:「最初の週にターゲット顧客5人のインタビューを終え、全員同じニーズを確認したときだけ開発開始」
• ルール2:「機能追加リクエストが出たら『この機能がないとMVPは失敗するか』の1問だけで判断。Yes/Noのみ」

最初のMVPが6週間なら、ルールを立てれば2回目は5週間に減らせます。

パターンが見え始めるとき、メイカーの跳躍

パターンを認識したメイカーの2回目のMVPは速い。でも「速い」は錯覚。正確には無駄が減るです。

韓国のあるインディ開発者は、最初のプロジェクトで機能の過剰で8週間かかりました。「次はもっと速く」と決意して2回目も7週間。「AI時代だから複雑になっただけ」と考えました。3回目の前に振り返りを整理してみたら、パターンが見えました。「私は毎週水曜に機能を1〜2個ずつ追加する。それが私の習慣だ。」

これに気づいたあとの3回目は、水曜はレビューミーティングだけして開発はしないとルールを決めました。その結果5週間に短縮。違いは「もっと頑張った」のではなく、繰り返される行動のパターンを意識的に遮断したこと。

最初のメイカーはミスで学び、2回目のメイカーはパターンで学びます。3回目からは予防します。

自分のパターンカードを作る

1段階. 最初のMVPのミス3つを書く

例:「機能を3つ追加した」「ユーザーフィードバックが遅すぎた」「デプロイ予定が何度も延びた」

2段階. それぞれのミスの共通パターンを1つ抽出

例:上の3つはすべて「速度の好み vs 検証不足」でまとまる。

3段階. パターンを止めるルール2つ

ルールは測定可能であるべき。「もっと気をつける」のではなく、「毎週月曜午前9時に機能追加リクエストの数をログする」のような具体的な行動。

4段階. 2回目のMVPキックオフでチームに共有

一人で作るなら、親しいメイカーの友達やオンラインコミュニティにこのルールを公開宣言。外的な約束は、内的な決意よりずっと強い。

まとめ

パターンを知れば、2回目のMVPは単に速くなりません。正確になります。正確なメイカーが速いメイカーに勝ちます。

次の記事ではこの正確さを時間にどう変換するかを学びます。同じことを30%速くやるのではなく、別のことをそもそもやらない。それが5日圧縮の秘訣です。

前の記事:最初より速い2回目
次の記事:5日で短く作る方法、圧縮の技術

登場人物(パク・ソヨン、イ・ジュノ)について
登場人物はフェイルスクールが作った架空のペルソナです。ただしトス、イ・スンゴン代表などの失敗事例、HBRスタートアップ失敗統計はすべて実在のものです。

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