「Web版MVPってなに？」「MVPって聞くけど、結局ただの試作品でしょ？」と思っているなら、少し危ないです。
なぜなら、Web版MVPを知らないままアプリ開発を始めると、誰も使わない機能に時間とお金を溶かす可能性が高いからです。恐ろしい話ですが、世の中には「完璧なアプリを作れば売れる」と信じて、半年かけて、数十万円から数百万円を使って、最後に誰も使わないサービスを完成させる人が普通にいます。
結論から言うと、Web版MVPとは「いきなり本格アプリを作る前に、ブラウザで使える最小限の機能だけを作り、需要があるかを検証するためのWebサービス」です。
つまり、完成品ではありません。豪華なアプリでもありません。むしろ逆です。最低限だけ作って、実際に人に使わせて、必要かどうかを見極めるためのものです。
私は個人でWebアプリを作るなら、最初からスマホアプリ化を狙うより、まずWeb版MVPで試すほうが圧倒的に現実的だと考えています。理由は単純です。早い、安い、直しやすい。この3つが強すぎます。
参考：MVPの考え方は、Lean Startup公式でも「最小限の労力で顧客について最大限の学びを得るもの」と説明されています。
Lean Startup公式：What Is an MVP?
Lean Startup公式：Methodology
Web版MVPとは？なにを指すのか
MVPは「最小限で売れる完成品」ではない
MVPは「Minimum Viable Product」の略です。日本語では「実用最小限の製品」と訳されることがあります。
ここで勘違いしやすいのが、「最小限」という言葉です。
MVPは「手抜きの未完成品」ではありません。かといって「最小限で完成された商品」でもありません。正しくは、仮説を検証するために必要な最小限の形です。
たとえば、授業の予定管理アプリを作りたいとします。
最初から以下のような機能を全部入れる必要はありません。
- Googleカレンダー連携
- iPhoneカレンダー連携
- 売上集計
- 入金管理
- 生徒ごとの料金設定
- 通知機能
- 請求書発行
- サブスク決済
- 管理画面
- スマホアプリ化
これを最初から全部作るのは、かなり危険です。もはや開発というより、自分で自分に課す罰ゲームです。
最初に検証すべきなのは、「講師が授業予定と収入をまとめて管理したいと思うか」「実際に入力し続けるか」「今のカレンダーや表計算より便利だと感じるか」です。
この検証に必要なら、最初はWeb上で予定登録、月間表示、収入合計だけでも十分です。それがWeb版MVPです。
Web版MVPはブラウザで使える最小アプリ
Web版MVPとは、スマホアプリやPCソフトではなく、ブラウザでアクセスして使える形のMVPです。
たとえば、次のような形です。
- URLを開けば使える
- ログインすれば自分のデータを見られる
- スマホでもPCでも使える
- 最低限の登録、編集、削除ができる
- 必要ならホーム画面に追加してアプリっぽく使える
WebアプリをPWA化すれば、スマホのホーム画面に追加して、アプリのように起動することもできます。MDNではPWAを「Web技術で作られ、プラットフォーム固有アプリのような体験を提供するアプリ」と説明しています。
MDN：What is a progressive web app?
また、W3CのWeb Application Manifest仕様では、Webアプリ名、アイコン、起動URLなどのメタデータを定義できます。
W3C：Web Application Manifest
iPhoneでもSafariからWebサイトをホーム画面に追加し、「Webアプリとして開く」ことができます。
Apple公式：Turn a website into an app in Safari on iPhone
つまり、Web版MVPは「App Storeに出していないからアプリではない」という話ではありません。最初の検証段階では、むしろWebで十分なことが多いです。
Web版MVPを作るメリット
開発コストを抑えやすい
Web版MVPの最大のメリットは、開発コストを抑えやすいことです。
スマホアプリを本格的に作る場合、iOS、Android、審査、ストア公開、端末ごとの挙動確認など、考えることが一気に増えます。もちろん本気で展開するなら必要です。ただ、最初の段階でそこまでやる必要があるかは別問題です。
Web版なら、まず1つのWebアプリとして公開できます。ユーザーはURLからアクセスできます。更新もサーバー側で反映できます。アプリ審査を待たずに改善できるのは大きいです。
最初から完璧なスマホアプリを作ろうとすると、検証前に体力を削られます。まだ需要があるかもわからないのに、外装だけ高級車にするようなものです。人間、なぜか中身より先に革シートを選びたがります。
修正が早い
MVPでは、作った後の修正が本番です。
むしろ、最初に出したものが一発で正解になることのほうが珍しいです。使ってもらうと、だいたい想定外のことが起きます。
「このボタンが分かりにくい」
「入力が面倒」
「スマホだと見づらい」
「この集計はいらない」
「逆にこの項目がほしい」
こういう反応を集めて直すのがMVPです。
Web版なら、修正してすぐ反映できます。スマホアプリのように更新版を配信して、ユーザーにアップデートしてもらう手間が少ないです。小さく作って、小さく直す。この速度がかなり重要です。
テスターに渡しやすい
Web版MVPは、テスターに渡しやすいです。
「このURLから使ってみてください」で済みます。必要ならログインIDを発行するだけです。
App StoreやGoogle Playで公開する前に、知り合い、既存顧客、関係者、少人数のテスターに使ってもらえます。特に個人開発や小規模サービスなら、この段階がかなり大事です。
いきなり世の中に公開する必要はありません。最初は5人でも10人でも構いません。むしろ、最初の段階では少人数のほうが改善しやすいです。
大量のユーザーを集める前に、少人数が本当に使うかを見るべきです。使われないものを広告で広めても、ただの拡散された失敗になります。
Web版MVPで検証すべきこと
本当に困っている問題なのか
Web版MVPで最初に見るべきなのは、「その機能が便利か」ではありません。
もっと根本です。
本当にその問題で困っている人がいるのか。
ここを間違えると終わりです。どれだけUIがきれいでも、どれだけ機能が多くても、困っている人がいなければ使われません。
たとえば、授業管理アプリなら「講師は予定管理に困っているのか」「収入見込みを把握したいのか」「交通費や入金管理までまとめたいのか」を確認する必要があります。
自分が困っているだけなのか、他の人も困っているのか。ここを切り分けるべきです。
お金を払うほど必要なのか
次に大事なのは、お金を払うほど必要かどうかです。
「便利ですね」と言う人はいます。人間は社交辞令を覚えた生き物なので、そこはあまり信用しすぎないほうがいいです。
本当に見るべきなのは、次の行動です。
- 継続して使うか
- 登録してくれるか
- 面倒でも入力してくれるか
- 料金を払う意思があるか
- 他人に紹介したいと思うか
MVPでは、褒め言葉より行動を見たほうがいいです。
「いいですね」と言われたけど誰も使わない。これは珍しくありません。むしろ、よくあります。やさしい世界に見えて、プロダクトには残酷です。
どの機能が本当に必要なのか
MVPの目的は、機能を増やすことではありません。
必要な機能と不要な機能を見分けることです。
最初は「この機能もあったほうがいい」と思いがちです。しかし、実際に使われる機能はかなり限られます。
予定管理アプリなら、最初に必要なのは以下のような機能かもしれません。
- 予定を登録する
- 日付ごとに見る
- 月ごとの収入を確認する
- 実施済みかどうかを記録する
逆に、最初から高度な分析機能や複雑な通知機能は不要かもしれません。
Web版MVPでは、実際の利用状況を見ながら、必要な機能だけを残していくべきです。
Web版MVPとプロトタイプの違い
プロトタイプは見た目確認、MVPは実利用確認
Web版MVPとプロトタイプは似ていますが、目的が違います。
プロトタイプは、主に見た目や操作感を確認するためのものです。Figmaなどで画面だけ作る場合もあります。これはこれで重要です。
一方、MVPは実際に使えるものです。最低限でも、ユーザーが触って、登録して、何らかの価値を感じられる必要があります。
つまり、プロトタイプは「こういう感じでどうですか？」を見るもの。MVPは「これを実際に使いますか？」を見るものです。
この差は大きいです。
画面を見て「良さそう」と言うのと、毎日ログインして使うのはまったく違います。人間のやる気は、画面を眺めているときだけ妙に元気です。実際に入力する段階になると急に消えます。
MVPは雑でもいいが、価値は必要
MVPは完成品ではないので、多少見た目が粗くても問題ありません。
ただし、価値がないのはダメです。
ここを間違えてはいけません。MVPは「雑でいい」ではありません。「検証に必要な価値だけは入れる」という考え方です。
たとえば、予定管理アプリなら、デザインが少し地味でも構いません。しかし、予定登録が分かりにくい、保存できない、スマホでまともに使えないなら、それはMVPではなく単なる未完成品です。
最小限でも、ユーザーが目的を達成できる必要があります。
Web版MVPを作るときの注意点
最初から機能を盛りすぎない
Web版MVPで一番やりがちな失敗は、機能を盛りすぎることです。
「ついでにこれも」
「将来的に必要だから」
「競合にはあるから」
「どうせ作るなら」
この言葉が出てきたら危険です。
MVPの段階で重要なのは、将来の理想形ではありません。今、検証すべき仮説です。
ユーザーが本当に求めているか分からない機能を先に作ると、開発時間が増えます。画面も複雑になります。テストも面倒になります。そして、結局使われない可能性があります。
最初は削る勇気が必要です。
きれいなデザインより使いやすさを優先する
もちろん、見た目は大事です。
ただ、MVP段階で最優先するべきなのは、派手なデザインではありません。使いやすさです。
文字が読める。ボタンが押せる。スマホで崩れない。入力が面倒すぎない。どこを見ればいいか分かる。
まずはここです。
高級感のあるアニメーションより、保存ボタンが分かりやすいほうが重要です。妙におしゃれな画面でユーザーが迷うなら、それは美しい迷路です。迷路を作るためにアプリを作っているわけではありません。
数字を見られる状態にする
Web版MVPでは、感想だけでなく数字も見たほうがいいです。
最低限、以下は確認したいところです。
- 登録者数
- 実際に使った人数
- 継続利用率
- よく使われる機能
- 離脱しやすい画面
- 有料化した場合の反応
これらが分かると、次に何を直すべきか見えてきます。
「なんとなく好評」では判断できません。なんとなく好評なものほど、いざ課金すると誰も残らないことがあります。現実はだいたい冷たいです。
Web版MVPはどんな人に向いているか
個人開発者や小規模事業者に向いている
Web版MVPは、個人開発者や小規模事業者にかなり向いています。
理由は、限られた時間と予算で検証できるからです。
特に、次のような人には相性がいいです。
- 自作アプリを作りたい人
- 業務改善ツールを作りたい人
- 講師、店舗、個人事業主向けサービスを作りたい人
- まず知り合いや既存顧客に試してもらいたい人
- App Store公開前に需要を見たい人
- サブスク化や決済導入を考えている人
最初から大規模サービスを目指す必要はありません。まずは狭い範囲で使われるものを作るべきです。
小さく刺さるものは、後から広げられます。誰にも刺さらない大作は、ただ重いだけです。
既存業務の置き換えにも向いている
Web版MVPは、新規サービスだけでなく、既存業務の置き換えにも向いています。
たとえば、今までExcel、Numbers、紙、LINE、Googleカレンダーでバラバラに管理していたものを、1つのWebアプリにまとめるケースです。
この場合も、最初から全部置き換える必要はありません。
まずは一番面倒な作業だけを置き換える。たとえば、予定と収入の集計だけWeb化する。そこで便利さが確認できたら、入金管理や通知を追加する。
この順番のほうが安全です。
Web版MVPから本格アプリに進む判断基準
継続利用されているか
Web版MVPから本格アプリに進むべきかどうかは、継続利用で判断するべきです。
一度使われただけでは弱いです。
何度も使われているか。毎週使われているか。使わないと困る状態になっているか。
ここが大事です。
継続利用されているなら、本格開発に進む価値があります。逆に、最初だけ触られて終わるなら、機能追加より原因分析が先です。
有料化の余地があるか
本格アプリ化するなら、有料化の余地も見たほうがいいです。
無料なら使うけど、有料なら使わない。これはよくあります。
もちろん最初は無料でも構いません。ただし、将来的に収益化したいなら、どこでお金を払ってもらうのかを早めに考えるべきです。
- 月額課金
- 買い切り
- 一部機能だけ有料
- 事業者向けプラン
- 初期設定サポート
- 広告なしプラン
Web版MVPの段階で、簡単な料金表示や事前登録、寄付、先行利用プランなどを試すのもありです。
「いつか収益化する」は、だいたい永遠に来ません。人類の「いつか」は信用してはいけません。
まとめ
Web版MVPとは、いきなり本格アプリを作る前に、ブラウザで使える最小限の機能だけを作り、実際の需要を検証するためのWebアプリです。
MVPは手抜きではありません。最小限の労力で、最大限の学びを得るための検証手段です。
特に個人開発や小規模サービスでは、最初からスマホアプリ化するより、Web版MVPで試すほうが現実的です。URLで共有でき、修正も早く、テスターにも渡しやすいからです。
Web版MVPで見るべきなのは、見た目の豪華さではありません。
本当に困っている人がいるか。
継続して使われるか。
お金を払うほど必要とされるか。
どの機能が本当に必要か。
この4つです。
最初から完璧なものを作る必要はありません。むしろ、完璧を目指すほど失敗しやすくなります。
まずは小さく作る。実際に使わせる。数字と反応を見る。必要な部分だけ直す。
Web版MVPは、アプリ開発で無駄な遠回りをしないための現実的な第一歩です。夢を壊すためではなく、ちゃんと形にするために必要な工程です。
コメント