#
創業初期に開発リソースを確保する方法は、通常3つあります。共同創業者としてCTOを迎える、開発会社に外注する、自分で作る、の3つです。それぞれスピード、費用、自由度が異なります。
| 方法 | 初期費用 | MVP完成までの期間 | 自由度 | 主なリスク |
|---|---|---|---|---|
| 共同創業CTO | 株式10-20% | 1-3か月 | 高い | 適任のCTO探しに数か月かかることがある。意見対立のリスク |
| 開発会社への外注 | ₩5M-₩30M | 2-4か月 | 低い | 要件の認識違い。保守費用が別途発生 |
| ノーコード / ローコード | ₩0-₩300K/月 | 2-6週間 | 中程度 | 複雑な機能には限界がある。アクセス急増時に費用が跳ね上がる |
ノーコードやローコードが、いつでも最善というわけではありません。仮説をまだ検証していない初期段階で、先に数千万ウォンを開発に投じるのは、単純に順序が違うということです。顧客が本当にお金を払う意思を持っているか確認する前にコードを書くのは、買い手が決まっていないのに倉庫に在庫を積み上げるのと変わりません。
Airbnbの初期チームは、静的なWebページに写真を載せるだけで需要を確認しました。Dropboxはプロダクトがまったくない状態で、1本の動画からベータ版の利用待ち登録を75,000件獲得しました。MVPの目的は完成品を作ることではありません。できるだけ少ないリソースで、最も重要な仮説を1つ、否定または実証することです。
#
最初にツールを選んでしまう失敗は避けましょう。適切なツールは、目的によってまったく異なります。何かを選ぶ前に、3つの問いに答えてください。
1つ目は、このMVPで何の仮説を検証するのか。「このサービスにお金を払う人がいる」なのか、「この特定の機能が実際に繰り返し使われる」なのかによって、必要な機能の範囲は変わります。仮説が曖昧なままでは、どんなツールを使ってもMVPは完成しません。
2つ目は、ユーザーの中心的な行動は何か。ランディングページでメールアドレスを登録するのか、実際に決済を完了するのか、それとも一方のユーザーがコンテンツを投稿し、もう一方がそれを利用する双方向の構造なのか。それぞれ必要なツールの種類が異なります。
3つ目は、6か月後にどのくらいのユーザー数と取引量を見込んでいるか。多くのノーコードツールは初期費用を抑えられますが、ある時点から従量課金の影響が出てきます。選んだツールに6か月後、月₩3Mを超える費用が必要になるなら、その時点で切り替えコストにも直面します。事前に計算しておく価値があります。
#
非エンジニア創業者が作るMVPは、主に4種類に分かれます。需要検証用のランディングページ、一方向型サービス（予約・申し込み・サブスクリプション）、両面型プラットフォーム（ユーザー同士をつなぐもの）、社内業務ツールです。種類ごとに、適したツールのカテゴリーと費用構造が異なります。
| MVPの種類 | 代表的なツールのカテゴリー | 開発難易度 | 月額費用の目安 | 拡張性の限界 |
|---|---|---|---|---|
| 需要検証用ランディングページ | ページビルダー＋フォームツール | 低い | ₩0-₩50K | 決済機能や会員機能がない |
| 一方向型サービス（予約・サブスクリプション） | ノーコードアプリビルダー | 中程度 | ₩50K-₩200K | 複雑な条件分岐を実装しにくい |
| 両面型プラットフォーム | データベース連携型ビルダー | 高い | ₩100K-₩400K | アクセス急増時に性能が低下する |
| 社内業務ツール | スプレッドシート＋自動化 | 低〜中程度 | ₩0-₩100K | 一般公開サービスへの転用が難しい |
最も早く作れるのは、需要検証用のランディングページです。仕組みは単純で、ユーザーがメールアドレスを登録したり、事前決済を完了したりすれば、需要の証拠とみなします。この段階でユーザーが反応するのは、デザインの完成度ではなく、メッセージの的確さです。「これはあなたが抱えている問題ですか」という問いに、顧客が言葉だけでなく行動で応えたら、次の段階へ進む準備ができています。
ノーコードで最も実装が難しいのは、両面型プラットフォームです。供給側と需要側がそれぞれログインし、やり取りを行い、そのすべてを決済につなげる必要があります。最初からこの構造をすべてノーコードで作ろうとして、6週間を費やしてしまう創業者は少なくありません。現実的なのは、まず中核機能を1つだけ作り、残りの流れは運営担当者が手作業で処理する方法です。初期のマッチングサービスが典型例です。アルゴリズムを使わず運営担当者が人をつなぎ、需要を確認してから自動化を加えていきます。
#
ツールを選んだだけでは、MVPは完成しません。順序を間違えると、何も検証できないまま4週間が過ぎてしまいます。以下のチェックリストは、実行する順序に沿って並べています。
- 検証する中核仮説を1文で書く。（例：「30代の会社員は、毎週届く自分向けの献立提案に月₩10,000を払う」）
- 仮説を確認するためにユーザーが取るべき、最小限の行動を1つ定義する。（例：決済を完了する / メールアドレスを登録する / コンテンツを利用する）
- MVPの種類を決める。ランディングページ、一方向型サービス、両面型プラットフォーム、社内ツールのいずれか。
- ツールを1つだけ選ぶ。最初から複数のツールを組み合わせず、中核機能が動いてから連携する。
- 中核機能だけを作る。当初の機能リストの70%はMVPには不要。「あると便利」に分類されるものは削る。
- まず実際のユーザー10人に見せる。家族や友人ではなく、実際のターゲット顧客であることが必要。
- その10人の反応を記録する。すべてのクリック、操作に詰まった箇所、離脱したタイミング、質問を記録する。
- 仮説検証の結果を判断する。コンバージョン率、反応、インタビュー内容をもとに、継続・修正・方向転換を決める。
- 次の開発範囲を定義する。仮説を検証できたら、この時点で外注や開発者の採用を検討する。
この9つの手順のうち、最も省略されやすいのが6と7です。ツール作りに没頭すると、実際のユーザーに見せることが後回しになります。しかし、見せる相手がいないままツールを完成させるのは、販路がないのに在庫を積み上げるのと同じです。1人で4週間磨き込むより、未完成のプロダクトを10人に見せたほうが、早く結論にたどり着けます。
#
ノーコードやローコードのツールが使いやすいからといって、失敗せずに作れるわけではありません。参入のハードルが低い分、同じところでつまずく人も増えています。
1つ目の失敗は、デザインに時間をかけすぎることです。配色、フォント、アニメーションに2週間を費やしてしまう。初期のMVPでユーザーが判断するのは、仕上がりではなく、伝えている内容です。まず「自分の問題を解決してくれるか」に答える必要があります。
2つ目の失敗は、機能を際限なく追加することです。「これもあるといい」が積み重なると、MVPは3か月のプロジェクトになります。1つの仮説を検証するのに必要な機能は、通常1つか2つで十分です。それ以外は検証後に回しても、何も失いません。
3つ目の失敗は、最初から多くのツールを組み合わせることです。ページビルダー、フォームツール、決済ツール、メール自動化、分析ツールを一度につなごうとして、連携作業で止まってしまいます。最初は1つのツールでできる範囲に絞りましょう。自動化できる工程でも、まず手作業で動かし、流れが成立するか確認する価値があります。
4つ目の失敗は、すべてをノーコードで解決しようとすることです。機能によっては、ノーコードで作るより、スプレッドシートとメールで処理したほうがはるかに早く済みます。マッチングサービスの初期のマッチング処理が典型例です。アルゴリズムなしで運営担当者が手作業で人をつなぎ、パターンが確認できてから自動化を追加します。
#
Q. ノーコードでMVPを作った場合、本格的な開発に移るときにすべて捨てることになりますか？
A. コードの大部分は、そうなります。ただし、そこが本質ではありません。MVPから得たユーザーデータ、インタビュー結果、コンバージョン率には、開発仕様書よりもはるかに大きな価値があります。「捨てる」というより、「次の段階へ卒業する」と考えてください。検証済みの証拠を持って開発に進むのと、アイデアだけで進むのとでは、結果が大きく変わります。
Q. ノーコードツールの習得には、どのくらいかかりますか？
A. ツールによって異なります。現実的な目安は、ランディングページビルダーなら1日、一方向型アプリビルダーなら1〜2週間、両面型プラットフォームビルダーなら3〜4週間です。公式チュートリアルとYouTubeの解説動画を併用すれば、短縮できます。ただし、最初から複雑すぎるツールを選ぶと、習得だけでMVPの開発期間全体を超えてしまうことがあるので注意してください。
Q. ノーコードのMVPで、韓国の政府系起業支援事業に応募できますか？
A. はい。審査員は、MVPの技術的な完成度よりも市場検証を重視します。ノーコードで作ったサービスでも、実際のユーザー数、決済履歴、インタビュー結果があれば、事業計画書の有力な裏付けになります。どれほど簡素でも、ノーコードMVPがあることは、アイデアしかない状態よりも有利です。
Q. ノーコードのMVPは、後で開発者を採用するときに足かせになりませんか？
A. なりません。むしろ、検証済みのユーザーデータと確定した機能リストを持つ創業者は、開発者やCTO候補から好意的に受け止められます。「アイデアがあるので一緒に作りましょう」よりも、「有料ユーザーが100人いて、次の段階に進むための開発が必要です」のほうが、はるかに説得力があります。