起業するなら、エンジニアを探す前に自分でMVPを作ってみよう

起業でいちばん多い失敗は、仲間を巻き込んで数か月かけて作ったものが、誰にも使われなかった、というものです。自分で数日で試せるなら、この失敗は避けられます。何を削って何を残すのか、その判断基準をまとめました。

まず結論

結論として、エンジニアを探す前に、まず自分で試作品を作ってみるべきです。

理由はシンプルで、そのアイデアが本当に求められているかは、作ってみるまでわからないからです。

誰かを巻き込んで数か月かけて作ったものが、誰にも使われなかった。これは起業でいちばんよくある失敗です。自分で数日で作れるなら、その失敗を避けられます。

MVPとは何か

MVP（エムブイピー）という言葉があります。「Minimum Viable Product」の略で、日本語では「実用最小限の製品」と訳されます。

よくある誤解は、**「機能を減らした劣化版」**だと思ってしまうことです。そうではありません。

MVPとは、確かめたいことを1つ確かめるために必要な部分だけを作ったものです。

目的が「確かめること」なので、何を確かめたいのかが決まっていなければ、そもそもMVPは作れません。

まず、確かめたいことを1つに絞る

作り始める前に、次の文を埋めてください。

＿＿＿な人が、＿＿＿という状況で、＿＿＿にお金や時間を払うと思う。

たとえばこうです。

予約の電話対応が大変な個人の美容室オーナーが、営業中に電話が鳴って手が止まる状況で、Webで予約を受けられる仕組みに月3000円払うと思う。

この1文が決まると、作るものが決まります。この例なら、確かめるべきは**「Webで予約が取れること」**だけです。売上分析も、顧客管理も、メール配信も、今回は要りません。

この1文が書けないうちは、まだ作り始めないでください。 曖昧なまま作ると、機能を削る判断ができなくなります。迷ったら全部入れる、という方向に必ず流れます。

機能を削る判断基準

作りたい機能を全部書き出したら、それぞれにこう問いかけます。

これがなくても、確かめたいことは確かめられるか？

答えが「確かめられる」なら、それは今回作らなくていい機能です。

厳しく見えますが、実際にやってみると驚くほど削れます。

削りやすいもの

機能	代わりにどうするか
管理画面	最初は自分でデータを直接見れば足りる
パスワードの再設定	数人のうちは手作業で対応できる
決済の仕組み	「払いたい」と言ってもらえるかを確かめるだけなら、振込でも足りる
通知メール	自分で手動で送れば代わりになる
デザインの作り込み	使えるレベルなら確認は成立する

どれも「後で必要になる」ものです。でも確かめる前に必要かというと、そうではありません。

削ってはいけないもの

一方で、削ると確かめること自体が成立しなくなるものがあります。

中心となる体験 — 上の例なら「Webで予約が完了する」こと
他人のデータが見えない仕組み — 公開する以上、省略できません
データが消えないこと — 確かめた結果そのものが失われます

2つ目は特に重要です。 MVPだからと省略されがちですが、事故が起きたら検証どころではなくなります。ここだけは最小限でも必ず入れてください。

自分とAIでできることが多い

自分や友達だけで使うツール
学校や会社の中だけで使うツール
アイデアを試すための試作品
利用者が少ない小さなサービス

専門家の知識が重要になる

他人の個人情報を預かる
お金のやりとりをする
利用者が一気に増えたとき
動かなくなったときの復旧

「作れる」と「公開していい」は別の話です。ここの線引きがわかることが大事です。

進め方

1
確かめたいことを1文で書く
曖昧なら、まだ作り始めない。
2
中心となる体験を1つ決める
「これができれば確かめられる」という1本の流れ。
3
その流れだけを作る
周辺の機能は作らない。
4
5人に使ってもらう
数は少なくていい。観察が目的。
5
考えを更新する
当たっていたか、外れていたかを言葉にする。

1つずつ順番に進めます。飛ばすと後で戻ることになります。

5人で十分です。 多くの場合、3人目までに同じ問題が繰り返し出ます。人数を増やすより、1人ずつ丁寧に見るほうが得るものが多くなります。

実際にMVPを作るときの指示

判断基準はわかっても、手が動かないと意味がありません。そのまま使える形にしておきます。

削る判断をAIに手伝わせる

作りたい機能を全部書き出したら、次の指示で整理させてください。

新規事業の検証用に、試作品を作ります。

確かめたいこと:
・（1文で。例：予約の電話対応が大変な個人サロンのオーナーが、
  Webで予約を受けられる仕組みに月3000円払うか）

作りたいと思っている機能:
・（思いつくまま全部書く）

このうち、確かめたいことを検証するために「なくても成立する」機能を
指摘してください。理由もつけてください。
削ったほうがよい理由が弱いものは、無理に削らなくて構いません。

自分では削れないものも、外から見ると削れることがよくあります。

作る指示

検証用の試作品を作りたいです。本番で使うものではありません。
10人くらいに触ってもらって、需要があるかを確かめるためのものです。

中心となる流れ:
・（1本だけ書く。例：来店希望者が日時を選んで予約を完了できる）

条件:
・凝った作りは不要です。動くことを優先してください
・データの保存は Supabase、公開は Vercel で、無料の範囲でお願いします
・あとでエンジニアに引き継ぐ前提なので、複雑にしないでください

「本番で使うものではない」と最初に伝えてください。 これがないと本格的な構成を提案され、検証に入るまでが遅くなります。

削ってはいけない部分の指示

MVPでも、これだけは省略できません。

検証用ですが、次の2つだけは省略しないでください。

1. 予約した人が、他人の予約内容を見られないようにする
   Supabase の RLS で、保存側から制限してください
2. 入力されたデータが消えないようにする

それ以外は最小限で構いません。

1番を省略すると、検証どころではなくなります。 他人の個人情報が見えた時点で、事業の話が止まります。

よくある失敗

作り込みすぎる

「もう少し形になってから見せたい」と思っているうちに、確かめるのが遅れます。恥ずかしい状態で見せるのが正解です。

感想を聞いてしまう

「どう思う？」と聞くと、たいてい褒められます。相手は気を使うからです。

聞くべきは意見ではなく、実際にどう使ったかです。黙って使ってもらい、詰まった場所を見てください。

結果を認めない

想定と違う結果が出たとき、「作り方が悪かっただけだ」と思いたくなります。

ここで正直に考えを更新できるかどうかが、その後を大きく分けます。外れたとわかったこと自体が、大きな成果です。

自分で作れると、何が変わるか

エンジニアを探してから作る場合と比べて、こう変わります。

これまで

1アイデアを考える
2エンジニアを探す
3作りたいものを説明する
4数十万〜数百万円を払う
5数週間〜数か月待つ

いま

1アイデアを考える
2AIに「こんなものを作りたい」と相談する
3その日のうちに動くものができる

サービスを作るまでの流れは、AIの登場で大きく変わりました。

失敗の費用が下がる — 数十万円ではなく、数日で済む
説明のズレがなくなる — 自分の頭の中のものを、自分で形にできる
仲間を誘うときに強い — アイデアだけで誘うより、動くものがあるほうが伝わる

最後の点は、意外と大きいです。エンジニアを誘うときも、動くものがあるほうが話が早くなります。

よくある質問

Q. 作ったものをそのまま本番で使えますか？ A. 確認が必要です。AIでアプリができた！でも、そのまま公開して大丈夫？を必ず読んでください。

Q. 外注する場合と比べてどうですか？ A. 外注していたサービスは、AIならどこまで自分で作れる？で費用の内訳を分解しています。

まとめ

エンジニアを探す前に、自分でMVPを作ってみる
MVPは劣化版ではなく、確かめるための最小構成
「確かめたいこと」を1文で書けないうちは作り始めない
**「なくても確かめられるか」**で機能を削る
ただし他人のデータが見えない仕組みだけは削らない
5人に使ってもらい、感想ではなく行動を見る