MVPか完成版か：最初のアプリ開発のスコープの決め方

アプリ開発プロジェクトは、その重さがあまり意識されない一つの判断から始まります。「最初のバージョンをどれくらいの規模にするか」です。小さすぎれば役に立たないアプリになり、大きすぎれば最初のユーザーが現れる前に予算が尽きてしまいます。MVPか完成版かという議論は、本当はどちらが優れているかという話ではありません。自社のビジネスにとって正しい最初のスコープをどう決めるか、という話です。

本記事では、私たちがクライアントのスコープ削減をどのように支援しているか、予算はどこから漏れやすいのか、そしてMVPがかえって誤った判断になるのはどんな場面かをお伝えします。

MVPとは何か、そして何がMVPではないのか

MVP、つまり Minimum Viable Product はよく誤解されます。特に多い誤解は次の二つです。

• 「MVP＝安物のバージョン」。 これは誤りです。MVPは小さくてもかまいませんが、きちんと動き、使いやすく、ユーザーを苛立たせないものでなければなりません。頻繁にエラーが出るアプリはMVPではなく、ただの壊れた製品です。
• 「MVP＝すべての機能を簡略化したもの」。 これも誤りです。むしろ予算が漏れる最も確実なレシピです。どれも中途半端な15個の機能ができあがるだけです。

私たちが使っている定義はこうです。MVPとは、実際のユーザーが使えて、そこから学びが得られる最小のバージョンです。 キーワードは「学び」です。MVPを公開した後には、「人は本当に使いたいと思うのか」「どの部分が最も使われるのか」「どの機能は実は重要ではなかったのか」が分かっているべきです。

当社の自社プロダクトであるKosPro（インドネシアの下宿・賃貸物件オーナー向け管理アプリ）も、最初のバージョンでは物件・部屋・入居者・請求の記録しかできませんでした。財務レポートも、マルチユーザーも、決済連携もありませんでした。初期ユーザーから学んだのは、私たちが重要だと思い込んでいた機能よりも、支払い遅延のリマインダーのほうがはるかに求められていたということです。

スコープの削り方：中核となる一つのフローから始める

私たちの経験上、最も効果的な方法は機能リストを作ることではありません。中核となるユーザーフローを一つ、最初から最後まで書き出すことです。

たとえば、ケータリング事業者向けの注文アプリなら次のようになります。

顧客がアプリを開く → 本日のメニューを見る → プランと日付を選ぶ → 支払う → ケータリング側が注文を受け付けて「配送済み」にする → 顧客に通知が届く。

これだけです。このフローに含まれるものはすべて 必須（must-have） です。フローの外にあるものは、すべて順番待ちのリストに入れます。

中核フローが明確になったら、あらゆる機能アイデアを三つの箱に分類します。

MVPに入れるのは Must の箱だけです。加えるとしても、本当に自社プロダクトの差別化になる Should を一つか二つまでにします。残りは捨てるのではなく、ロードマップに書き留めておきます。

スコープが決まった後の開発工程を理解したい方は、経営者のためのSDLC解説をご覧ください。

予算はどこから漏れやすいのか

私たちが見てきた限り、予算の漏れは意図的に決めた大きな機能からはあまり生じません。「ついでに」追加される小さなことから生じます。

1. いつの間にか紛れ込む「あったらいいな」機能

「ついでにExcel出力もできますか」「ついでにダークモードも」。一つひとつは1〜2時間の作業に聞こえますが、積み重なると2週間になります。シンプルなルールは、プロジェクト途中で追加する新機能は、スコープ内の別の機能と入れ替えるか、スケジュールの延長を明示的に合意するかのどちらかにすることです。

2. 過小評価される外部連携

決済代行サービス、配送業者、会計ソフト、既存システムとの連携は、ほぼ必ず想定より時間がかかります。外部サービスのドキュメントが不完全だったり、サンドボックス環境に問題があったり、旧システムのデータに一貫性がなかったりするためです。MVPでは、最も重要な連携を 一つ だけ選びましょう。

3. 途中での再デザイン

画面を作り終えた後にデザインを変えると、作業が二重になります。最初に時間をかけて中核画面のデザインを合意し、MVPのリリースまでは規律を持ってそれを守りましょう。

4. すべてのプラットフォームに同時対応する

Web、Android、iOS、管理画面を最初のバージョンで一度に作るのは、四つの製品を作るのと同じです。まずはユーザーが最も多くいるプラットフォームから始めましょう。Flutterのような技術を使えばAndroidとiOSを一つのコードで作れますが、それでもテストとリリースの作業はそれぞれに必要です。

5. 初日から「数百万ユーザー対応」を目指す

大規模なスケールに耐えるアーキテクチャには、相応のコストがかかります。MVPで重要なのは、後からスケール できる 土台であって、今すでにスケール している 土台ではありません。その他の費用の内訳は、2026年インドネシアのアプリ開発費用で解説しています。

MVPがかえって誤った判断になるのはどんなときか

正直なところ： 私たちは常にMVPを勧めるわけではありません。最初のバージョンが「最小限」であることが、かえって損失や危険につながるビジネスもあります。そうした状況でMVPを無理に押し通すのは、大きく作りすぎるのと同じくらい悪い判断です。

最初のバージョンのスコープを、より充実させるべき状況は次のとおりです。

• 規制のある業界。 医療、金融、学校教育など。監査ログ、多段階の承認、データ保護といった機能は「Could」ではなく、事業を運営するための前提条件です。
• 決済と顧客のお金。 アプリで残高やウォレットを管理したり、返金を処理したりする場合、その部分は初日から正しく動かなければなりません。「後で直す」は通用しません。
• すでに使われているシステムの置き換え。 チームが20の機能を持つ旧システムを使っているなら、5機能しかない新バージョンは受け入れられません。この場合のアプローチはゼロからのMVPではなく、段階的な移行です。
• B2B顧客との約束。 顧客との契約で特定の機能が明記されているなら、その機能は自動的に「Must」になります。

こうしたケースでもスコープは削りますが、最低ラインは高くなり、スケジュールも意図的に長く取ります。

最初からv1からv2への道筋を計画する

良いMVPは行き止まりではありません。成長できるMVPと作り直しが必要なMVPを分けるのは、削らない 三つのことです。

1. データ構造。 レポート機能がまだなくても、注文データは最初から漏れなく正確に記録しておきます。そうすれば、後からその上にレポートを作るだけで済みます。
2. コード品質とテスト。 機能が少ないことは、コードが雑でいい理由にはなりません。むしろ小さいからこそ、きれいに保つのは容易です。
3. アカウントと所有権。 リポジトリ、サーバー、ドメイン、外部サービスのアカウントは、初日から自社名義にしておきます。将来ベンダーを変更する場合に重要になります。詳しくはソフトウェア開発会社選びのチェックリストで解説しています。

この三つが守られていれば、v2は やり直し ではなく 追加 の作業になります。v2の計画はv1のリリース前に書いておくべきですが、決定はv1の利用データを4〜8週間見た 後 に行いましょう。実際のユーザーが使い始めると、優先順位が大きく入れ替わることはよくあります。

AI機能はMVPにどう組み込むべきか

この質問はますます増えています。私たちの答えは一つの点にかかっています。AIはプロダクトの価値の中核なのか、それとも補助なのか。

• AIが中核の場合。 たとえば当社のプロダクトCuplikinは、長い動画の中から見どころを見つけるAIそのものが本質です。AIがなければプロダクトが成り立ちません。こうした場合はAIをMVPに含め、むしろ他の機能（エディター、字幕、書き出し）を最初のバージョンでは絞り込みます。
• AIが補助の場合。 「AIによるメニューのおすすめ」機能を持つ注文アプリを考えてみてください。おすすめ機能は便利ですが、それがなくてもアプリは役に立ちます。AIが活用できる実際の注文データが溜まってから、v2で追加しましょう。データがなければ、AI機能はただの飾りです。

私たちがよく勧める中間の選択肢もあります。AIそのものはまだ作らず、v1のデータ構造をAIに 対応できる ように設計しておく方法です。すでに稼働しているシステムにAIを追加する方法は、既存アプリのAI移行で解説しています。

AI機能に関する実践的なルール

AI機能をスコープに入れる前に、「この機能が10回に1回間違えても、ユーザーはこのプロダクトを使い続けたいと思うか」と問いかけてください。答えがノーなら、その機能はまだMVPの中核にする準備ができていません。どんなAIモデルでも、ときには間違えるからです。答えがイエス（たとえば、おすすめや、ユーザーが手直しする下書きなど）であれば、AIは「決める」機能ではなく「助ける」機能として安心して組み込めます。

現実的なMVPのスケジュール

中核フローが一つ、連携が一つの場合の大まかな目安は次のとおりです。

誰の見積もりであれ、「MVP」の期間が3〜4か月を超えるなら、そのスコープはおそらくもうMVPではないか、まだ考慮されていない大きな連携があるかのどちらかです。いずれにしても、そのまま受け入れるのではなく話し合うべきです。

次のステップ

長い機能リストがあって、最初のバージョンに何を入れるべきか迷っているなら、そのリストをそのまま私たちに送ってください。無料の初回相談では、通常、中核フローの整理と、Must・Should・Couldの切り分けをお手伝いしています。まずは当社のソフトウェア開発サービスをご覧いただき、お問い合わせフォーム、WhatsApp、またはメール（hello@rancanginaja.com）でお気軽にご連絡ください。