Freeive

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か月間の記録を広げて、次の質問を投げます。

  1. この作業がなかったらリリース不可能だったか?
  2. この作業をしなかったらユーザーが気づいたか?
  3. この作業を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.5h2件 × 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段階

  1. 最初のMVPで「これは本当に必要だったか?」と感じた瞬間を5つ書く
  2. 各瞬間について「次はどうするか」のルールを決める
  3. ルールを1文ずつカードに書く
  4. 開発開始の前日にカードをもう一度読む
  5. 決定の瞬間に「ルールに従うか、新しく判断するか」の基準を立てる

まとめ

「5日で短く作る方法」の核心は速度ではなく選択です。速くやろうとする人は多いけれど、そもそもやらないと決められる人は少ない。そしてその差が14日と9日を作ります。

でも一度MVPを作るのが速くなったからといって終わりではありません。問題はこのペースで作り続けられるかです。次の記事では1人で複数のMVPを運営するシリーズビルダーの運営法を扱います。


前の記事:同じミスをしない方法
次の記事:シリーズビルダーの運営法、1人で複数のMVP


登場人物(パク・ソヨン、イ・ジュノ)について
登場人物はフェイルスクールが作った架空のペルソナです。


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

#フェイルスクール#シーズン2#圧縮#時間管理#意思決定自動化#完璧主義#ルールカード

Comments

コメント 0

サインイン状態を確認中…

コメントを読み込み中…

Recent

他の日記も。