開発会社と契約して、スケジュールにも合意した。でも、その期間中に向こうで何が起きているのか、正直よくわからない。進んでいるのか、遅れているのか、どうやって判断すればいいのか。
この不安は、開発の流れを週単位で把握していないことから来ます。MVPプロジェクトが実際にどんな順序で動くのか、各フェーズで開発側は何をしていて、依頼側のスタートアップは何を準備すべきなのかを、この記事で整理します。
週次分解の全体像
リーンMVPはおおよそ四つのフェーズで構成されます。企画・設計 → コア開発 → 統合・テスト → リリースです。
スコープにもよりますが、この一巡が8〜12週間で完了するのが理想的なペースです。要件の複雑さ、外部サービスとの連携数、フィードバックのスピードによって前後します。
以下の分解は10〜12週間規模のリーンMVPを想定しています。
1〜2週目: 企画と設計
この2週間、コードは一行も書かれません。でも、ここで決めたことがプロジェクト全体を左右します。後から変えると、すでに作った部分を大幅に作り直すことになるからです。
コアユーザーフローの定義
機能リストを作るより先に、「ユーザーがアプリを開いてから最初に何をするか、そして何が完了すれば目的を達したか」を1〜3シナリオに絞り込みます。
同じくらい重要なのが「今回作らないもの」のリストです。後からスコープが広がるのを防ぐために、除外項目を明文化します。
画面フローとデータ構造
ワイヤーフレームレベルで画面の繋がりを決めます。見た目の完成度より「このボタンを押すとどの画面に遷移するか」を開発者と依頼者が同じ絵で見られることが大切です。
データ構造（ユーザー、予約、商品など主要なエンティティ）もこの時点で設計します。中盤で構造を変えると、すでに実装済みの機能を大幅に書き直すことになります。
依頼者がこの期間にやるべきこと: レスポンスを速くすることです。開発側が画面フロー案を共有したら、1〜2日以内に反応することがスケジュール遵守の鍵になります。
コア開発フェーズ
プロジェクト全体の半分以上を占める最長のフェーズです。
3〜4週目: インフラ構築と最初の機能実装
開発環境の整備、デプロイパイプラインの構築、認証システムの実装が最初に行われます。見た目には何も変わりませんが、以降のすべての開発の土台になります。
基盤ができたらコアフローの最初の画面から順に実装を開始します。この段階のコードはまだ荒削りです。UIの完成度より、ロジックが正しく動くかを優先します。
5〜7週目: コア機能の完成
リリースに必要な機能がこの期間中に動く状態になるべきです。管理画面、コアデータ処理、外部サービスとの連携（決済、通知、地図など）がここに含まれます。
週次や隔週で中間デモを行っている場合、このフェーズが最も変化が見える時期です。画面は完成品には見えなくても、データが保存されて画面間の遷移が機能することを確認できます。
依頼者がこの期間にやるべきこと: フィードバックを「リリースしないと届けられない機能」と「リリース後に追加できる機能」の二つに分けることです。この区別がスケジュールを守ります。
統合とテスト
各機能が単体で動いた後、それらが組み合わさったときに正しく動くかを検証するフェーズです。
8〜9週目: 機能統合とバグ修正
ユーザーの一連のフローを初めて通しでテストします。「予約完了後に通知が送られ、管理画面にリアルタイムで反映される」といった、複数の機能が絡んだシナリオを検証します。
この段階で多くのバグが出るのは正常です。重要なのはゼロにすることではなく、リリースを阻害するバグを全て潰すことです。クリティカルな問題（クラッシュ、データ破損、決済フローの不具合）は即時修正します。影響範囲が狭いUIの細かい問題はリリース後のパッチに回す判断も必要です。
パフォーマンスチューニングとセキュリティチェックもこの期間に実施します。
リリース週
10〜12週目: 最終確認とデプロイ
本番環境へのデプロイです。ステージング環境では問題がなかったものが、本番環境で異なる動作をすることがあります。デプロイ直後に全フローを改めて通しで確認します。
App StoreやGoogle Playへの審査提出が必要な場合もこの期間に行います。AppleのApp Store審査は平均1〜3日ですが、場合によってはそれ以上かかることもあります。このバッファを日程に組み込んでおく必要があります。
リリース直前の確認項目:
- 利用規約・プライバシーポリシーページの用意
- エラー発生時に即座に対応できるモニタリング設定
- 最初のユーザーをどう獲得するかのチャネル準備
リリースは終わりではありません。実際のユーザーが使い始めると想定外の問題が出てきます。その声が次のイテレーションを動かします。
実際のプロジェクトで見る: 業務効率化SaaS MVP（12週間）
技術メンバーのいないスタートアップが、中小企業向け業務効率化ツールのアイデアを持ちこんできた事例です。日本の中小企業に受け入れられるには品質と導入後のサポートが重要だという認識から、スピードより丁寧さを優先してプロジェクトを進めました。
実際の週の動き:
- 1〜2週目: ターゲットとなる中小企業のユーザーフローを3本に絞り込み。データ構造を確定。除外機能のリストを合意。
- 3〜6週目: コア機能の実装。日本語ドキュメントの整備とUI設計を並行。シンプルさと操作のわかりやすさを優先。
- 7〜9週目: 機能統合と通しテスト。想定ユーザー（事務担当者）でのユーザビリティ確認。バグ修正。
- 10〜12週目: 本番環境デプロイ、導入サポート資料の整備、パイロット企業でのトライアル。
結果: 6ヶ月以内に8社が継続利用、継続率95%、満足度4.7/5。D社代表取締役は「日本の中小企業のニーズを理解した製品でした。導入サポートが丁寧で、社員全員がすぐ使えるようになりました」と語っています。
12週間かかった理由は、日本市場向けの品質水準を担保しながら、使いやすさを作り込む時間をあえて確保したからです。機能の数を絞ったことで、一つひとつの完成度を高めることができました。
意図的に省くもの
リーンMVPでは、最初から意図的に除外する項目があります。これらがなくてもリリースは可能です。
通常リリース後に回す項目:
- ソーシャルログイン（Google、LINE など） — メールログインで先に出せる
- 細かい通知・リマインダー設定 — 基本通知だけで十分
- 詳細な分析ダッシュボード — 主要指標の表示だけ先に
- 多言語対応 — 日本語一言語で検証してから
- ロール別の細かい権限管理 — 管理者と一般ユーザーの区別だけで始める
- オフラインモード
- ネイティブアプリ — モバイルWebで先に出す
このリストを見て「でもこれは絶対に必要です」と思う項目があるかもしれません。そのときに問うべき質問は一つです。「これがないと、最初の10社は利用を断るか?」。おそらくそうではないなら、リリース後の計画に入れるのが正解です。
開発費用の詳細についてはアプリ開発コスト完全ガイドを、MVP外注の全体的な進め方についてはスタートアップMVP外注完全ガイドをご覧ください。
自分たちのMVPは何週かかるのか。スコープによって答えは変わるため、一律の数字でお答えするのが難しいテーマです。30分の無料相談で今のアイデアをお持ちいただければ、現実的なスケジュールを一緒に描くことができます。