MVP開発の期間は何で決まる？範囲・判断・確認から考える
MVP開発の期間は、機能の数だけで決まるものではありません。この記事では、期間を左右する「作る範囲」「判断の速さ」「確認の回数」の3つを順に整理します。あわせて、見積もりを依頼する前に何を決めておくと期間の見通しが立てやすくなるのかを説明します。
MVP開発の期間に「標準の日数」を置きにくい理由
MVPとは「Minimum Viable Product」の略で、事業の仮説を確かめるために必要な最小限の機能だけを備えた製品のことです。完成品の縮小版ではなく、「確かめたいことを確かめるための道具」と考えると分かりやすくなります。プロトタイプやモックアップとの違いは、プロトタイプとモックアップ・MVPの違いで整理しています。
「MVP開発 期間」で調べると、さまざまな目安が出てきます。ただ、私たちはこの種の一律の日数をそのまま信頼するのは難しいと考えています。同じ「MVP」という名前でも、中身が大きく異なるためです。会員登録と一覧表示だけのものと、決済や外部サービスとの連携、権限管理まで含むものでは、作る量がまるで違います。
期間を分解すると、次の式で考えられます。
期間 ＝ 作る作業の時間 ＋ 判断や確認を待つ時間
前半の「作る作業の時間」は、作る範囲の大きさで決まります。後半の「待つ時間」は、判断の速さと確認の回数で決まります。実際の案件では、後半が思った以上に長くなることがあります。開発そのものは進められるのに、仕様の回答待ちや社内の承認待ちで手が止まる、という場面です。システム開発の遅延の一般的な原因は、システム開発が遅延する原因と、発注時にできる防ぎ方でも扱っています。
つまりMVP開発の期間は、開発会社の作業速度だけでなく、発注する側の進め方にも左右されます。以降は、3つの要素を順に見ていきます。
要素1：作る範囲は「確かめたい仮説」から決める
期間にもっとも直接効くのは、作る範囲です。範囲が広がるほど、設計、実装、テストのすべてが増えます。
範囲を大きくしやすい要素
MVPの範囲を膨らませやすいものには、次のようなものがあります。
- 利用者の種類（ロール）の数：一般利用者だけか、運営者や提携先も使うか。種類が増えるほど画面と権限の設計が増える
- 決済や本人確認：お金や個人情報を扱う部分は、確認事項が多い。外部サービスを使うか自作するかでも作業量が変わる
- 外部システムとの連携：連携先の仕様確認や、先方との調整が発生する
- 管理画面：運営側の機能をどこまで最初に作るか
- データの移行や取り込み：既存の情報を使う場合、整える作業が発生する
- 通知やメール、検索、集計といった周辺機能：1つひとつは小さくても、積み重なると大きくなる
決済の扱いは新規事業の決済システム開発｜外部サービスと自作の分け方、管理画面は新規事業の管理画面開発｜最初に作る範囲の見極め方で、判断の軸を整理しています。
「最小」を決める基準は、仮説にある
では、どこまでを最初に作ればよいのでしょうか。私たちは、基準を「確かめたい仮説」に置くことをおすすめします。
たとえば「この市場の利用者は、このサービスにお金を払うか」を確かめたいなら、決済までの流れは範囲に入ります。一方で「利用者が毎週使い続けるか」を確かめたいなら、課金の仕組みよりも、使い続けたくなる中心の機能に時間を使うほうが理にかなっています。仮説が違えば、「最小」の中身も変わります。
機能を絞る具体的な手順はMVP開発の機能の絞り方｜最初に作るものと後回しの基準にまとめています。ここでは、期間の観点から次の点だけ押さえておきます。
- 範囲は「あれば便利」ではなく「なければ仮説が確かめられない」かで決める
- 後回しにした機能は、捨てたのではなく順番を変えただけ、と整理しておく
- 範囲が曖昧なまま着手すると、開発の途中で「これも必要では」という追加が出て、期間が読めなくなる
範囲は、期間を短くする手段としても、見通しを立てる土台としても、最初に固めたい要素です。
要素2：判断の速さが、待ち時間を決める
2つめは、判断の速さです。ここは見落とされやすい一方で、期間への影響が大きい要素です。
開発が止まるのは、判断を待つとき
開発の途中では、細かな判断が何度も発生します。たとえば次のような場面です。
- 画面の項目をどうするか、仕様の解釈をどちらにするか
- 想定していない例外の場合、どう動かすか
- 追加したい要望を今回に含めるか、次に回すか
- 見せ方や文言を、誰が最終的に決めるか
こうした問いに答える人が決まっていないと、確認が社内を回り、返答に時間がかかります。開発側は、回答が来るまで該当部分を進められません。
仮の計算で見る、待ち時間の大きさ
イメージしやすいように、あくまで仮の計算をしてみます。開発の途中で確認が10回発生し、そのたびに返答まで3営業日かかるとします。すると待ち時間だけで30営業日、週に5営業日として約6週間になります。回答の速度が当日から翌日に変われば、同じ10回でも大幅に縮まります。
もちろん、待っている間に別の部分を進めることもできるため、単純に足し算にはなりません。それでも、判断の速さが全体の期間に大きく響くことは分かります。
判断の速さを上げる3つの工夫
判断を速くするために、私たちは次の3点を事前に整えておくことが有効だと考えています。
- 最終判断者を決める：仕様の確認に答える窓口と、決める権限を持つ人を明確にする。窓口が決められない内容を、毎回上に持ち帰る形だと遅くなる
- 判断の優先順位を共有する：「仮説を確かめることが最優先で、見た目の細部は後回し」のように、迷ったときの基準を先に合わせておく
- 経営陣と現場の見ている目的をそろえる：新規事業では、経営陣（決裁者）と現場（立案者）が同じ目的を見ているのに、判断の材料と進める速度が違うために話が噛み合わなくなることがある。ズレているのは目的ではなく進め方であることが多い
発注側で判断を担う役割については発注側のプロダクトオーナーとは｜役割と判断のしかた、経営陣と現場のすれ違いについては新規事業で経営陣と現場がすれ違う原因は進め方のズレが参考になります。
なお、仕様の変更や追加が途中で出ること自体は、新規事業ではごく自然です。大切なのは、変更が出たときの扱いを先に決めておくことです。システム開発の仕様変更への対応｜追加要望の扱い方で、その考え方を扱っています。
要素3：確認の回数と、確認のタイミング
3つめは、確認の回数です。ここでは「回数が少ないほど早い」とは限らない点が重要です。
最後にまとめて確認すると、手戻りが大きくなる
確認の回数を減らすために、「要件を最初に文書で固めて、完成してから確認する」進め方を選ぶことがあります。一見、効率的に見えます。ただ、言葉だけで要件を決めると、同じ文書を読んでも人によって思い描く画面が違い、完成してから「思っていたものと違う」と分かることがあります。
そのとき直す範囲は、すでに作り込まれた部分です。1回の手戻りが大きくなり、期間も延びます。要件定義の抜け漏れや食い違いが、使ってみて初めて分かるのは、新規事業ではよくあることです。要件定義の進め方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で扱っています。
実物を見ながら確認すると、直す範囲が小さい
一方、作りかけの段階で実際に動くものを触りながら確認すると、「ここはこう」という指摘をその場で出せます。ズレが小さいうちに直せるため、1回あたりの手戻りが小さくなります。確認の回数は増えますが、全体では期間が短く収まる可能性があります。
この考え方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも詳しく書いています。
確認は「回数」より「何を見るか」
確認を増やすだけでは、かえって待ち時間が増えます。確認の質を上げる工夫として、次の点が挙げられます。
- 毎回、見る目的を決める：「今回は申込みの流れだけ確認する」のように、範囲を絞る
- 見る人を決める：確認の場に判断できる人がいないと、持ち帰りが増える
- 確認で出た指摘を、すぐに仕分ける：今回直す、次に回す、やらない、の3つに分けて記録する
- 本物に近いデータで見る：ダミーデータが現実とかけ離れていると、使い心地の判断がずれる。プロトタイプのダミーデータの用意のしかたが参考になる
進捗確認の場の持ち方はシステム開発の進捗確認のしかた｜定例会とデモの見どころにまとめています。
AIを使った開発で、期間の何が変わるのか
近年は、AIを活用した開発が広がり、プロトタイプやMVPを作る期間への関心が高まっています。AIが設計や実装、テストの一部を担うことで、「作る作業の時間」は短くなりやすくなっています。仕組みはAIでプロトタイプを短期間で作れる理由｜工程ごとの仕組みで、工程ごとに解説しています。
ただし、ここまで見てきた式で考えると、変わるのは前半だけです。
期間 ＝ 作る作業の時間（AIで短くなりやすい）＋ 判断や確認を待つ時間（AIでは短くならない）
何を作るかを決めること、仮説に照らして「これでよいか」を判断すること、品質の最終判断をすること。これらは、人が担う部分です。作る作業が速くなるほど、全体の期間に占める「判断と確認」の割合は大きくなります。言い換えると、AIの活用が進むほど、発注する側の判断の速さが期間を左右しやすくなります。
人月（作業者の人数×月数）で費用や期間を測る従来の考え方がどう変わるかは、AI開発で人月の考え方はどう変わる？工数で測れない部分で整理しています。また、AIと人の役割分担の全体像はAI駆動開発とは｜AIと人の役割分担と発注側の要点をご覧ください。
AIを使うから期間が自動的に短くなる、と考えるのではなく、「短くなった作業時間を、判断と確認の質に振り向ける」と考えるほうが、現実に合っていると私たちは考えています。
期間の見通しを立てる前に、整理しておきたい5つの問い
ここまでの内容を、見積もりを相談する前の整理項目にまとめます。新規事業に取り組む会社が、開発会社と話す前に確かめておくと、期間の見通しが立てやすくなります。
- 確かめたい仮説は何か 「誰が、何のために、どんな条件で使い続けるか」まで言葉にしておく。仮説が1文で書けると、範囲が決めやすい
- 最初に見せたい相手は誰か 社内の決裁者なのか、見込み顧客なのか、提携先なのか。相手によって、必要な完成度が変わる
- 仕様を決める人と、回答にかかる日数はどのくらいか 質問への返答が当日なのか、数日かかるのか。決められない事項が出たときに、誰が決めるのか
- 外部サービスや既存システムとの連携はあるか 連携先の仕様や審査が必要な場合、開発とは別の待ち時間が生まれる
- 確認の場を、いつ、誰と、何回持てるか 確認の日程を最初に押さえておくと、待ち時間が読みやすくなる
仕様がまだ固まっていない段階でも、この5つに答えを出す過程で、固めるべき範囲が見えてきます。仕様が決まっていない状態からの相談については、仕様が決まってないシステム開発の相談は可能かで扱っています。
また、見積もりを受け取ったときは、金額や期間の数字だけでなく、前提や範囲を読み解くことが大切です。何を含み、何を含まない見積もりなのかによって、期間の意味も変わります。システム開発の見積もりの違い｜金額より先に見る前提と範囲も合わせて確認してください。
MVPを作った後の進め方、たとえば検証の指標をどう置くかについては、MVP検証の指標を先に決める方法｜判断基準の作り方が役立ちます。期間を決める段階で「何をもって検証完了とするか」まで考えておくと、MVP開発の終わりが明確になります。
まとめ
MVP開発の期間は、次の3つの要素で決まります。
- 作る範囲：確かめたい仮説から逆算して、最小の範囲を決める。範囲が曖昧だと、途中の追加で期間が読めなくなる
- 判断の速さ：開発は、判断や回答を待つ間に止まる。最終判断者、迷ったときの優先順位、経営陣と現場の目的合わせを先に整えておく
- 確認の回数：最後にまとめて確認するより、作りかけの実物を見ながら小さく何度も確認するほうが、手戻りが小さく済む。回数だけでなく、毎回「何を見るか」を決める
AIを活用した開発では、作る作業の時間は短くなりやすい一方、判断と確認の時間は人が担うため短くなりません。だからこそ、「期間は開発会社だけが決めるもの」ではなく、発注する側と開発側が一緒に管理するものだと私たちは考えています。
JustFitは、構想をもとに約1ヶ月で、実際に動くプロトタイプを先に開発する受託開発サービスです。進め方としては、まず何に困っているかを伺い、1ヶ月で作るものを一緒に決める「認識合わせ」を行います。そのうえで、実物を見てから契約するかを判断していただけます。仕様が固まっていない段階でも相談できますので、期間の見通しを立てたい新規事業のご担当者は、JustFitのサービス紹介もあわせてご覧ください。