個人開発のMVPの作り方。何を確かめるか決めてから、機能を削る

個人開発でMVP（最小限の製品）を作るとき、つまずく場所はだいたい二つです。機能を削れずに出せないことと、出したあとに何も測っていないことです。どちらも、作る前に「何を確かめるのか」を決めていないことから起きます。この記事では、作る前に決める3つ、機能の削り方、出したあとに見る数字の順に手順を整理します。ハコブネを運営する株式会社Walkers（累計開発実績300件）の実例を交えて書きました。

MVPは「作る量」ではなく「確かめる問い」で決まる

MVPは「小さく作ったサービス」ではありません。確かめたい仮説をひとつ決めて、その答えが出るところまでを作ったものです。だから、何を作るかの前に、何を確かめるかが決まっていないと大きさが決められません。

個人開発では、使える資源がほぼ時間だけです。人を雇って並行して進められない以上、確かめる順番を間違えると、その分だけ丸ごと遅れます。だから問いは一度に一つに絞ります。

作る前に決める3つ

1誰の、どの行動を確かめるのかを一文にする

「使われるか」では曖昧すぎて答えが出ません。人が実際にとる行動まで落とします。ハコブネのハッカソンで運営が作った記録アプリ「BENLOG」は、確かめる仮説を「うんちを育てるためなら、人は毎日トイレを記録するのか」の一点に絞っていました。主語（誰が）、行動（毎日記録する）、条件（育てられるなら）が一文に入っています。

2合格ラインを数値で置く

先に数字を置いておくと、出したあとに「まあまあ良かった気がする」で終わらずに済みます。BENLOGでは、公開前の時点で7日後の継続率40%、30日後20%、1日あたり平均3.5件という線を置いていました（いずれも検証前に置いた目標値で、実測はこれからです）。数字の正しさより、判断が先に決まっていることに意味があります。

3やめる基準を先に決める

合格ラインと同時に、下回ったら何をするかも決めます。作り直すのか、相手を変えるのか、やめるのか。ここを決めずに出すと、数字が悪かったときに「宣伝が足りないだけかもしれない」と考え続けて、時間だけが溶けます。

機能の削り方：仮説に効かないものを落とす

機能を削るときは、画面の一覧ではなく利用者が一周する道を書き出します。「知る→登録する→一度使う→また来る」のように並べたうえで、決めた仮説の答えに関係しない枝を落とします。ログイン、通知、管理画面、決済は、たいてい後から足せます。

順番を入れ替える判断も同じです。UPSTA Japanの「ApoLink」（日程調整と決済が一体になったビジネスマッチング）は、開発の途中でテストマーケティングを行い、マッチング機能への反応が明らかに良かったため、その機能を前倒しする形に作る順番を組み替えて予定どおりリリースしました。開発期間は2ヶ月半、リリースから1ヶ月半で会員は200人弱まで増えています。

ここで大事なのは「多機能にしなかった」ことではなく、反応という事実で順番を決めたことです。削る基準を自分の好みに置くと、削れません。

どのくらいの期間で出すか

期間は先に決めてしまうほうが、結果として機能が削れます。Walkersが自社で作ったプロンプト活用サービス「Prompt Lab」は、構想からベータ版の公開まで3週間でした。

もっと短くもできます。2026年8月に開いたAI新規事業立ち上げハッカソンでは、開発が初めての方や、まだ事業を持っていない方を含む参加者全員が、4時間弱で自分のプロダクトを形にして発表しました。この日生まれたのは5本。アンケートに答えた3名は満足度が全員10点満点でした（少人数の回であることは差し引いてお読みください）。

1日でできることと、事業として続けられることは別です。ただ、「作る」の前に止まっている期間のほうが、たいてい長いというのが実際のところです。

出したあとに見る3つの数字

個人開発は母数が小さいので、率だけを見てもぶれます。10人・20人の段階では、誰が使い続けていて、その人がなぜ戻ってきたのかを直接聞くほうが判断材料になります。

よくある詰まりどころ

作り込みすぎる。「これが無いと使えない」と感じる機能の多くは、作り手の不安から来ています。利用者は、確かめたい行動さえできれば先に進みます。

誰にも見せないまま完成させる。公開前でも、画面の絵だけで反応は聞けます。聞ける相手が一人もいない段階なら、作る相手を探すほうが先です。

感想だけを集めてしまう。「良いと思う」は応援であって、検証ではありません。使ったか、戻ってきたか、お金を払ったか——行動を見ます。

よくある質問4選

質問1MVPはどこまで作れば「出していい」のですか？

決めた仮説をひとつ確かめられるところまでです。登録・課金・管理画面のように、その仮説の答えに関係しない機能は、出したあとで足せます。

質問2デザインは作り込む必要がありますか？

確かめたいことによります。使い勝手そのものが仮説なら必要ですが、「そもそも欲しい人がいるか」を確かめる段階では、読めて押せれば足ります。

質問3ノーコードとコード、どちらで作るべきですか？

検証にかかる時間が短いほうです。道具は仮説の中身ではないので、慣れているほうで構いません。作り直す前提なら、捨てやすさも判断材料になります。

質問4公開しても人が来ないときはどうすればいいですか？

まず計測が動いているかを確かめてください。そのうえで本当に人が来ていないなら、確かめる対象は「作ったもの」ではなく「どこに、その困りごとを持つ人がいるか」に移ります。声をかけられる相手が10人いない仮説は、作る前に相手を探すほうが早いです。

この記事について

執筆：ハコブネ編集部　／　監修：池田 龍一

株式会社Walkers 取締役

池田は、ITとノーコードの事業開発・教育事業の立ち上げを経て2021年にWalkersを共同創業。100件以上のシステム開発に携わり、要件がまだ固まっていない案件や、他社から引き継いだ開発の立て直しを担当しています。

株式会社Walkersは、AI駆動開発・ノーコード開発のシステム開発会社です。累計開発実績300件、200社以上の支援、自社メディアの累計100万PV。受託開発と並行して、自社でも複数の新規事業を立ち上げています。

最終更新：2026年9月16日