MVPの開発期間はどれくらいか：プロダクトの種類別の実際の期間

MVPの期間を最もよく予測するのは複雑さです。見積もりでは三つの段階を使っています。

予算も同じ段階で決まります。SaaS MVPの開発費用の記事で、段階ごとの価格帯を紹介しています。

プロダクトの種類は、かなり予測しやすい形でこれらの段階に当てはまります。この表は、よくあるMVPがどの段階に入るかを示しています。細部によっては、一段階上下することもあります。

Telegramミニアプリは、たいていシンプルか中程度の段階に入ります。Telegramの中で開くためアプリストアへの申請が不要で、ユーザーのアカウントもTelegramのものを使えます。

どのMVPも同じ段階を経ますが、単純な一覧から想像するよりも段階同士が重なり合います。

• 見積もり。ブリーフが、範囲、期間、価格を記した提案書になります。Sakuraでは、ほとんどの提案書をブリーフがそろってから2〜3営業日以内にお送りしています。
• デザイン。まずユーザーフロー、次に再利用できるコンポーネントで作った画面、最後に操作できるプロトタイプです。
• 開発。フロントエンド、バックエンド、連携を進め、毎週操作できるビルドをお渡しします。
• テスト。合意したブラウザと端末ですべてのフローを確認し、パフォーマンスと基本的なアクセシビリティも確かめます。
• 公開。デプロイ、アクセス解析、モバイルアプリがあればストアへの申請、そして実際のユーザーが来てからの最初の修正です。

デザインと開発は意図的に重ねて進めます。最初のフローが承認されたら、残りのフローを設計している間に、その開発を始めます。

デザインは通常、開発より先に始まり、先に終わります。ただし、両者を完全に順番に進めるべきではありません。デザインが完成したファイルを渡して手を離すと、実装に費用のかかる画面が開発中に見つかり、手戻りで数週間が失われがちです。

解決策は、開発者が組み立てるのと同じコンポーネントでデザインすることです。そうすれば承認済みの画面はほぼ完成した状態になり、疑問点も安く済むうちに解決できます。

たとえば、ドイツの中古車市場向けB2BツールAutoIntelは、プロダクトデザインと、サンプルの掲載情報で操作できるプロトタイプから始まりました。クライアントはチームとともにプロトタイプを確認し、データ収集を見積もる前に必要な項目と絞り込み条件を決めました。この順番により、開発の最も費用のかかる部分を、画面に本当に必要なものへ集中させられます。

公開日を計画している場合は、短いブリーフをお送りください。プロダクトがどの段階に入り、現実的な期間がどれくらいかをお伝えします。

ブリーフでは小さく見えても、開発で数週間を足す機能があります。注意すべきなのは次のものです。

• 連携。決済、ログインサービス、CRM、外部APIは、それぞれ設定、エラー処理、テストが必要です。
• 権限と役割。役割が一つ増えるたびに、各画面が扱う状態が掛け算で増えます。
• ネイティブアプリ。フロントエンドがもう一つ増え、アプリストアの審査も加わります。AppleのApp Reviewは、提出の少なくとも50%を24時間以内、90%を48時間以内に審査しますが、却下されると時計は振り出しに戻ります。
• 複数の言語。すべての文言、エラーメッセージ、ヘルプが各言語で必要になり、レイアウトは最も長い言語に合わせる必要があります。
• 素材の遅れ。最後の週に届く文章、価格、法的文書、実データは、テストを止めてしまいます。
• 遅い判断。回答を1週間待つ質問は、その上に作られるすべてを遅らせます。

MVPの期間は、質を下げるのではなく、作る量を減らすことで短くなります。最も時間を節約できるのは次の判断です。

• 磨き込みではなく、フローを丸ごと削る。すべてのフローを半分ずつ作るのではなく、二次的なフローを後のリリースに回します。
• まずWebで公開する。レスポンシブなWebアプリならスマートフォンとパソコンの両方に届き、ストアの審査も不要です。
• 実績のあるサービスを使う。ホストされた決済ページ、既存のログインやメールのサービスは、自前で作るより速く安全です。
• 早く決める。デザインを承認し、質問にその日のうちに答えられる担当者を一人決めます。
• 少人数のユーザーで早めに試す。Jakob Nielsenの研究では、5人のユーザーでのテストで使いやすさの問題の大半が見つかるとされています。大規模な一回より、小規模な数回のほうが効果的です。

車の販売広告向けのAIフォトスタジオCarPixlyは、iOS版の準備が続く間に、Android版をAPKとして自社のダウンロードページで公開しました。出せるところから公開し、プラットフォームを後から増やすのは、実際のユーザーに届く最短の道であることが多いです。

着手前にいくつかのものがそろっていると、最初の数週間が速く進みます。どれも技術的な知識は必要ありません。

• 主要フローの短いリスト。公開時にユーザーができなければならない一つから三つの作業を、わかりやすい言葉で書いたものです。
• 判断する担当者一人。デザインを承認し、質問にその日のうちに答えられる人です。
• 既存アカウントへのアクセス。ドメイン、ホスティング、アクセス解析、決済サービス、すでに使っているAPIです。
• 実際の素材、またはその提出日。プロダクトに表示する文章、価格、法的ページ、サンプルデータです。
• 公開に関する制約。その日付を重要にしているイベント、投資家との面談、繁忙期などです。

これらがそろっていれば、見積もりは数週間ではなく数日で済み、デザインも仮の文章ではなく実際の素材から始められます。

期間が延びるのは、開発者の入力が遅いからではほとんどありません。開発の周りで下された、あるいは下されなかった判断が原因です。

• 書面の変更手続きがないまま、途中で範囲が膨らむ。
• フィードバックに1日ではなく1週間かかる。
• 「完成」の定義を誰も書いておらず、最後の数週間が議論になる。
• 連携が、実際の例外ケースではなく、範囲の一行として計画されている。

変更手続きのある固定範囲なら、これらの大半を管理できます。その方法は請負と準委任の比較で解説しています。

公開は一つ目の時計の終わりではなく、二つ目の時計の始まりです。公開直後の数週間は、たいていプロジェクト全体で最も忙しい時期です。

実際のユーザーは、テストで見逃した不具合を見つけ、小さな変更を求め、誰も想定していなかった使い方をします。新機能に取りかかる前に、公開直後に短い修正と素早い改善の期間を設けましょう。

その後は、実際の利用状況に基づく月ごとの改善計画という安定したリズムに移ります。Sakuraのすべてのプロジェクトには不具合修正のための保証期間があり、その後の作業は月額プランで続けることも、社内チームに引き継ぐこともできます。

最も重要な仮説を検証できる範囲で、できるだけ短くすることです。Lean Startupの言葉を借りれば、MVPの目的は「できるだけ早く学び始めること」です。

計画が複雑な段階を大きく超えているなら、何を学びたいのか、より小さなプロダクトで同じことを学べないかを考えましょう。早く公開した一つのフローが、最も大切な問いに答えてくれることはよくあります。

計画を立てる準備ができたら、プロダクトについてお聞かせください。範囲、期間、固定価格を記した提案書をお届けし、毎週のビルドでプロダクトが形になっていく様子を確認していただけます。