MVP開発の例──何を確かめるために、どこまで作ったか期間と規模つきで7件を並べて読む

MVPの事例を読むとき、つい「どんな機能が入っていたか」を見てしまいます。ですが、同じ機能でも、確かめたいことが違えば作るべき範囲は変わります。参考になるのは機能の一覧ではなく、「何が分かっていなかったのか」と「そのためにどこまで作ったのか」の組み合わせのほうです。この記事では、実際に世に出た7件を、確かめたい一点・作った範囲・期間・規模という形でそろえて並べました。数日で出したものから数ヶ月かかったものまで幅があります。自分の場合はどこまで作ればいいのか、判断の材料にしてください。

事例は「機能」ではなく「確かめたい一点」で並べる

MVPの範囲は、業種や規模では決まりません。決めているのは、始める時点で何が分かっていなかったかです。需要そのものが分からないなら小さくなりますし、需要は確定していて運用に載るかどうかが不安なら、業務まるごとを一度動かす必要が出てきます。

そこで以下では、7件を次の順で並べます。数日から数週間で出したもの、1〜2ヶ月かけたもの、途中で作る対象そのものが変わったもの、そして途中から引き継いだものです。期間の長さは「丁寧さ」ではなく、確かめたいことの重さに比例します。

なお、それぞれの数字は各出典に書かれている範囲で載せています。丸めたり、後から良く見えるように言い換えたりはしていません。

数日〜3週間で出した例

BENLOG｜4時間弱、確かめる仮説は一点だけ

ハコブネが2026年8月23日に東京・目白台とオンラインで開いた1DAYのハッカソンで、運営が作った記録アプリです。参加者全員が4時間弱でプロダクトを完成させて発表し、その日に生まれたのは5本（参加者3本、運営2本）でした。開発が初めての人や、事業をまだ持っていない人も含まれています。

BENLOGで確かめる仮説は「うんちを育てるためなら、人は毎日トイレを記録するのか」の一点です。合格ラインとして、7日後の継続率40%、30日後20%、1日平均3.5件が置かれました。これは検証前に置いた目標値であって、実測された結果ではありません。4時間弱という時間でここまで絞り込めているのは、確かめる対象が一つしかないからです。なお、この回は少人数の開催で、アンケートに答えた3名の満足度は全員10点満点でした。

Prompt Lab｜構想からベータ版公開まで3週間

Walkersが自社で立ち上げたプロダクトです。構想からベータ版の公開までが3週間でした。

ここで参考になるのは、期間が先に置かれていることです。「作り終わったら出す」ではなく「3週間で出す」と決めると、入りきらない機能は自然に落ちます。自社プロダクトは締め切りがない分だけ膨らみやすいので、期間を先に固定するやり方は、個人開発でもそのまま使えます。

1〜2ヶ月で出した例

一番飯店｜ベータ版まで2週間、運用ごと確かめる

1952年創業、高田馬場にある中華料理店です。スタッフ4名で、紙の伝票とトランシーバーによる運用が長く続いていました。これをノーコードのオーダーシステムに置き換えています。ベータ版までは2週間、導入からは約2年が経っています。オーダーの労力は約50%削減されたとのことですが、これは依頼者の体感として語られている数字です。

この例では「欲しい人がいるか」はすでに分かっています。毎日その業務が発生しているからです。分かっていなかったのは「その運用をシステムに載せ替えられるか」でした。だからMVPの範囲は、機能の数ではなく、実際の営業時間のなかで一周回せるかどうかで決まっています。

ツナガル｜1ヶ月、すでにある導線の上に載せる

高福合同会社の会員システムです。LINE公式アカウントと連携する形で開発し、期間は1ヶ月でした。開始から約2ヶ月で会員12名、LINEの登録は約60名という規模です。

新しくアプリを作らず、すでに使われている入口の上に載せているのが要点です。人数としては小さい規模ですが、「登録した人がどう使うか」を見るには十分に観察できます。逆にこの人数では、割合の比較で何かを結論づけることはできません。規模が小さいうちは、割合ではなく使われ方を見る、という使い分けになります。

途中で、作るものの順番や対象が変わった例

ApoLink｜テストマーケの反応で、作る順番を組み替える

UPSTA Japanが手がける、日程調整と決済が一体になったビジネスマッチングのサービスです。テストマーケの段階でマッチング機能の反応が良かったため、開発の途中で作る順番を組み替え、それでも予定どおりリリースしています。開発は2ヶ月半、リリースから1ヶ月半で会員200人弱という規模です。

ここでのポイントは、順番を変えたのに期日が動いていないことです。作る順番を入れ替えられるのは、最初に「全部を同時に作らない」と決めているからです。全機能を並行で進めていると、途中で得た反応を反映する余地がなくなります。

サカチムプラス｜確かめる対象そのものが変わった

個人が運営するサッカーチーム向けサービス「サカチム」の有料版です。当初は検索サイトの強化を想定していましたが、対話を重ねるなかで「チーム専用ホームページの質」へ方向を変えました。結果として100種類の配色を実装しています。元のサカチムには164チームが登録されています。

作るものが変わった、というより、確かめたい問いのほうが置き換わった例です。こういう転換は、作り込んでから起きると痛手になります。小さく出して話を聞く段階で起きれば、方向を変えるだけで済みます。

途中から引き継いだ例

Calmspot｜見通しが立たなくなった状態から、範囲を引き直す

クリスタルロードのプロダクトで、自社開発で見通しが立たなくなった状態から引き継いで開発したものです。期間は3〜4ヶ月、当初の予算200〜300万円から開発コストは50%以上削減されたとされています。この削減幅は依頼者談として語られている数字です。

引き継ぎの場面では、MVPの考え方が「作る範囲を引き直す道具」として働きます。止まっている案件は、たいてい機能が多すぎて終わりが見えなくなっています。何を確かめるために作っていたのかに戻り、そこに必要な範囲へ絞り直すと、再び動き出すことがあります。

7件を並べて見えること

7件を通して見ると、期間は4時間弱から3〜4ヶ月まで大きく開いています。ただし、期間の差は「どれだけ丁寧に作ったか」ではなく、確かめたいことの位置の差です。

もうひとつ共通しているのは、どの例も「誰かに使ってもらえる状態」まで持っていっていることです。画面だけ、資料だけで止まっているものはここにありません。範囲は狭くてよいのですが、外に出ていないと何も返ってきません。

自分の場合にあてはめるときは、まず「いま分かっていないことは何か」を一行で書いてみてください。それが需要そのものなら数日から数週間、運用に載せられるかなら数週間から数ヶ月、という目安で見当がつきます。

よくある質問5選

質問1事例の期間をそのまま自分の計画に当てはめてよいですか。

目安としては使えますが、条件が違えば変わります。同じ「1ヶ月」でも、既存の導線に載せるのか、ゼロから入口を作るのかで中身はまったく違います。期間より、その例が何を確かめようとしていたかを見てください。

質問24時間で作ったものでも、MVPと言えるのですか。

確かめたい一点が決まっていて、実際に使ってもらえる状態になっていれば言えます。BENLOGの場合は仮説が一つに絞られていました。逆に、長い時間をかけても問いが決まっていなければMVPとは呼べません。

質問3事例に出てくる数字は、どこまで信用してよいですか。

出典に書かれている前提とセットで読んでください。この記事でも、BENLOGの継続率は検証前に置いた目標値、一番飯店の約50%は依頼者の体感、Calmspotの50%以上は依頼者談と明記しています。実測値とそれ以外は分けて扱うのが安全です。

質問4既存の業務をシステム化する場合も、MVPは必要ですか。

需要がすでに証明されているので、確かめる対象は「欲しい人がいるか」から「その業務を載せ替えられるか」に変わります。範囲を狭めるという意味でのMVPは有効で、一番飯店のように現場で一周回せるところまでを先に作る形になります。

質問5一人で作る場合も、同じ考え方で進められますか。

進められます。むしろ一人のほうが、作る量が直接スケジュールに跳ね返るので、範囲を絞る効果が大きく出ます。削り方や期限の決め方は、個人開発向けの記事のほうで詳しく扱っています。

この記事について

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

株式会社Walkers 取締役

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

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

最終更新：2026年9月16日