作る前にアプリのアイデアを検証する方法

アプリのアイデアを試す最も高くつく方法は、アプリを丸ごと作ってしまうことです。ところが、初めて起業する多くの人がまさにそれをやってしまいます。半年と貯金を費やし、静寂の中でローンチし、そこで初めて誰も欲しがっていなかったと気づくのです。

もっと良い方法があります。ここでは、MCDevLabs が本番コードを1行書く前に使っている検証プレイブックをご紹介します。

アプリではなく、問題から始める

アプリは解決策です。それに恋してしまう前に、問題そのものと、お金を払うほどそれに困っている人が誰かを具体的にしましょう。1つの文を書いてみてください。「[具体的な人物]は[何かをすること]に苦労していて、今は[良くない代替手段]でしのいでいる」。これをすっきりと埋められないなら、まだ作る段階ではありません。人に話を聞く段階です。

見込みユーザー10〜15人に話を聞きましょう。売り込むのではなく、痛みと既存の代替手段に耳を傾けるのです。既存の代替手段（スプレッドシート、メモアプリ、誰かにお金を払う）こそ、本物の問題が存在する最も強いシグナルです。

ランディングページで需要をテストする

アプリを作る前に、ランディングページを作りましょう。アプリがすでに存在するかのように説明し、明確な行動喚起（「早期アクセスを取得」）を加え、そこへ少量のトラフィックを流します — 数百ドルの広告か、あなたのユーザーがすでに集まっているコミュニティでのオーガニックな投稿です。

あなたが求めるシグナルはコンバージョンです。訪問者のうち何パーセントがメールアドレスを教えてくれるか。何もコンバージョンしないページは、開発に1セントも使う前に、極めて重要なことを教えてくれます。（これは、私たちのすべてのアプリが本物のマーケティングサイトとともにリリースされる理由でもあります — TagTrek や OwlRoutine をご覧ください。）

ASO という「茶柱」を読む

App Store と Google Play は、巨大な需要のデータベースです。作る前に、次のことをリサーチしましょう。

• 検索ボリューム — あなたのアプリが狙うキーワードを、そもそも誰かが探しているか。
• 競合 — 数千件のレビューがある平凡なアプリが3つあるか（好機：需要は証明済み、勝つ余地あり）、洗練されたものが30ある（難しい：混雑）、それともゼロか（リスキー：需要がないかもしれない）。
• 競合へのレビューの不満 — 星2つのレビューは、無料の機能ロードマップです。

健全なニッチには通常、証明された需要と、品質やフォーカスにおける明確な隙間の両方があります。その隙間こそ、あなたの切り込み口（ウェッジ）です。

テスト可能な最小のバージョンを作る

需要が本物らしく見えてきたら、コアの価値を届ける最小のバージョンを作りましょう — プロトタイプではなく、ユーザーの前に置ける本物の（小さな）アプリです。ここで私たちのアイデアから App Store までのプロセスが始動します。1つのコアループを、丁寧に作り込み、小さなグループにリリースするのです。

2つの数字を見守りましょう。アクティベーション（人々はコアの価値を体験したか）とリテンション（また戻ってきたか）です。リテンションはアプリのアイデアの真実の血清です。誰も再び開かない美しいアプリは、どんなにレビューが良くても、失敗した仮説です。

ピボットするか、やり抜くかを見極める

検証は合否を分ける関門ではありません。それぞれが何か月ではなく数日で済む、安価な実験の連続です。ランディングページがコンバージョンしないなら、コードに触れる前にポジショニングを直しましょう。MVP がリテンションしないなら、機能を追加する前にコアループを直しましょう。小さく速い賭けは、毎回、1つの巨大な賭けに勝ります。

その規律こそ、優れたスタジオがもたらすものです。あなたのアイデアをプレッシャーテストしたい — そしてそれが持ちこたえたなら無駄のないバージョンを作りたい — なら、お話ししましょう。間違ったものを美しく作るより、安価に検証するお手伝いをしたいのです。