Fail School·公開 2026.05.22·閲覧 18
5日で短く作る方法、圧縮の技術
2回目のMVPは同じことを30%速くすることではなく、別のことをそもそもしないこと。パク・ソヨンの14日→9日圧縮事例、最初にやった作業の70%分類法、時間泥棒3つと意思決定の自動化。
2回目のMVPは同じことを30%速くやるのではなく、別のことをそもそもやらないこと。
14日が9日になった理由
パク・ソヨンさんは1年前、最初のMVPを作るのに14日かかりました。マーケコラム分類SaaSでしたが、いざ始めると顧客の深いインタビュー5件を先にやり、ダッシュボードUIを3回作り直し、性能最適化に3日かけました。そんなとき、イ・ジュノさんが聞きました。「2回目は何日で作る?」
パクさんは考えてみました。最初にやった作業のうち、本当に必要だったのは70%くらい。インタビュー中の半分はすでに知っている問題で、3回目のダッシュボードデザインは最初とほぼ同じ、性能最適化はリリース後2か月経っても誰も触れませんでした。
だから2回目のMVPは9日でした。速く開発したのではなく、やらなくていいことをやらなかっただけです。
速くやる vs やらない、見た目は似ているが違う戦略
2回目のMVPを速く作る方法は大きく2つ。
- 速度改善:同じことを速く(5件のインタビューをもっと効率的に、ダッシュボードを速くデザイン)。「最適化」
- 仕事の除去:最初からそれをやらない(インタビュー2件だけ、UI再検討1回だけ、性能最適化はリリース後に)。「選択」
表面的には似ています。14日→10日でも、14日→9日でも。でも内部はまったく違います。1人メイカーの時間は限られているけれど、速度改善は選択肢が多く、仕事の除去ははるかに大きな効果を生みます。
韓国のあるスタートアップ事例。初期の開発チームは完璧な製品を作ろうと6か月計画でしたが、スプリント方式に切り替えて不要な機能を思い切って外したら2か月で初版リリースが可能でした。速度を2倍にしたのではなく、もともとやるべきことの60%をやらなかった。
10個やるべきことを9個に減らすほうが、9個を8個にするより心理的な収穫が大きい。前者は「選択」の体験で、後者は「加速」の体験だからです。
最初にやった作業の70%分類法
どんな作業が除去対象? 最初のMVPのあとの1か月間の記録を広げて、次の質問を投げます。
- この作業がなかったらリリース不可能だったか?
- この作業をしなかったらユーザーが気づいたか?
- この作業を2週間後ろに延ばしても問題になったか?
この質問に「いいえ」が2つ以上ならその作業は70%(除去対象)に含まれます。
必須作業(30%)
- コア機能の実装
- 最低限のユーザーテスト
- デプロイとモニタリング
- 致命的バグの修正
選択作業(70%)
- 3回以上のデザイン再検討
- 完璧なドキュメント化
- すべてのエッジケース処理
- リリース前の完全な性能最適化
- すべてのユーザーフィードバックへの対応
- マーケティング資料の準備
イ・ジュノさんの場合、最初のAIプロンプト管理ツールを作るとき、完璧なオンボーディングチュートリアルに2日使いました。分析してみるとユーザーの80%がヘルプを読まずにすぐ始めた。2回目の製品ではチュートリアルの代わりにインラインヒント3行で代替、実装時間2時間。
「もう一度作ったから今回はもっと完璧に」という考えが浮かんだ瞬間に注意してください。それは完璧主義の始まりです。
時間泥棒3つ
1. 決定の先延ばし
パクさんが2回目のMVPを企画するとき、「今回は技術スタックを変えようかな?」 この決定1つが3日の会議とテストにつながりました。結局維持しましたが時間の無駄。毎日の小さな決定が積もると「決定疲労」になります。
2. 過度な会議と報告
1人メイカーにとって会議は自分との対話ですが、チームがあれば会議は時間の浪費ポイント。「現況報告」の誘惑もあります。「進捗は何%か?」を毎日チェックして整理する行為自体が時間の浪費になります。
3. 小さな完璧主義
「インタビュー5件は少なすぎる?」→ 7件に増やす → 分析が複雑 → 1日追加。いちばん危険な瞬間は「リリース1週間前」。小さなバグを「すぐ直せる」と思って手を出した瞬間、想定外の別の問題が爆発します。
意思決定の自動化、パターンからルールへ
「外すべき作業」を知ることと「実際に外すこと」は違います。その間を埋める方法は意思決定を自動化することです。
イ・ジュノさんのルール:
- ルール1:初版にはもっともよく使う機能3つだけ。残りはv1.1で
- ルール2:バグは深刻度で分類。中以下はリリース後に持ち越す
- ルール3:意思決定は24時間以上悩むの禁止。それ以上なら既定値で
これらのルールは作るときに少し勇気が要ります。「本当にこの機能なしで大丈夫?」という疑い。でもルールが決まる瞬間、毎回悩む必要がなくなります。
意思決定の自動化は見た目「硬直した選択」のように見えますが、実は繰り返される小さな悩みから自由になる体験です。
時間節約マトリクス:9日 vs 14日
| 作業 | 1回目(14日) | 2回目(9日) | 外した理由 |
| 顧客インタビュー | 5件 × 1.5h | 2件 × 1h | すでに知っていた内容70% |
| 技術スタック決定 | 2日 | 0.5日 | ルール:以前と同じ |
| ダッシュボードデザイン | 3回再検討 | 1回再検討 | 初案 + フィードバック1回のみ |
| ドキュメント作成 | 1日 | 2時間 | インラインコメントで代替 |
| 性能最適化 | 3日 | 0日 | リリース後に進行 |
| エッジケース | 1.5日 | 0.5日 | 主要シナリオ3つのみ |
| マーケ準備 | 1日 | 0日 | ベータ少数公開 |
| バグ修正 | 1.5日(継続) | 1日(分類) | ルール:重大度のみ修正 |
| 合計 | 14日 | 9日 | 35%短縮 |
意思決定ルールカードを作る5段階
- 最初のMVPで「これは本当に必要だったか?」と感じた瞬間を5つ書く
- 各瞬間について「次はどうするか」のルールを決める
- ルールを1文ずつカードに書く
- 開発開始の前日にカードをもう一度読む
- 決定の瞬間に「ルールに従うか、新しく判断するか」の基準を立てる
まとめ
「5日で短く作る方法」の核心は速度ではなく選択です。速くやろうとする人は多いけれど、そもそもやらないと決められる人は少ない。そしてその差が14日と9日を作ります。
でも一度MVPを作るのが速くなったからといって終わりではありません。問題はこのペースで作り続けられるかです。次の記事では1人で複数のMVPを運営するシリーズビルダーの運営法を扱います。
前の記事:同じミスをしない方法
次の記事:シリーズビルダーの運営法、1人で複数のMVP
登場人物(パク・ソヨン、イ・ジュノ)について
登場人物はフェイルスクールが作った架空のペルソナです。
キム・ミンチュル、Freeive CEO、フェイルスクール
Comments
コメント 0
サインイン状態を確認中…
コメントを読み込み中…