MVP開発はどこまで作る？最初の予算で確かめたいこと

最初の公開で、何が分かれば次へ進めるか

説明用の例として、企業が会議室を借りられる予約サービスを考えます。日程検索、決済、会員ランク、レビューをそろえる前に知りたいのは、「電話で調整している担当者がWebから申し込むか」かもしれません。その問いなら、割引機能を増やすより、条件を読んで予約を申し込める体験を先に作る意味があります。

一方、知りたいのが「有料でも使うか」なら、無料の試作品への感想だけでは答えが出ません。実際の料金を提示して購入を検討してもらう必要があります。GOV.UKの初期検証の手引きも、不確かな前提を早く試す考え方を示しています。これは民間サービスの期間や成果を保証するものではなく、開発の順序を考える参考になります。

問いを選ぶときは、今の代わりの方法も聞いてみてください。電話が面倒でも、担当者との相談に価値を感じているなら、入力をWebへ移すだけでは選ばれないかもしれません。予約の例なら「いつ空いているかすぐ分かること」と「特殊な条件を相談できること」のどちらが大事かで、先に作るものが変わります。今使っている手段と比べて、何が良くなれば切り替えるかまで考えると、企画の中心が定まります。

参考：GOV.UK Service Manual：How the alpha phase works

画面の試作品で十分なこと、本番でないと分からないこと

利用者がメニューを理解できるかなら、画面をクリックして試せる試作品が役立ちます。しかし「毎月使いたい」という感想と、忙しい業務の中で実際に使うことには距離があります。継続利用を知りたければ、対象者が仕事を終えられる提供方法が必要です。先に検証方法を選ぶと、最初から全機能を実装する以外の道が見えてきます。

法人向けでは、操作する人と購入を認める人も別です。利用担当者が便利だと感じても、管理者が利用状況を確認できなければ導入が止まる場合があります。誰から何を確かめたかを分けて聞き、未確認の条件を残しておきましょう。試作品の評価を、そのまま購入の意思と読み替えないことが大切です。

参加者を集める準備も、開発と並行して進めます。誰が案内し、いつ実際の業務が発生し、試した後に話を聞けるかを確認します。予約の必要がない時期に触ってもらっても、利用がない理由を需要不足と判断することはできません。親しい人だけが参加する場合は、その人たちが特に支援を受けやすい条件だったことも残します。反応の良さだけで対象を広げず、次に試す相手を選ぶ材料にできます。

表が収まらない場合は横にスクロールできます。

予約の例では、自動化を減らしても「予約できた」は残す

先ほどの説明用の例では、空き枠の確認を運営者が行い、Webでは希望日時を受け付ける方法があります。この場合、申込み直後は「受付済み」、確認後は「予約確定」と分けて伝えます。自動調整を後回しにしても、利用者が予約できたか分からない状態にはしません。キャンセルや希望枠が取れない場合の連絡も、一つの予約体験に含まれます。

これに対して、予約の安全な保存や、他社の申込内容を見せない制御は、件数が少なくても必要です。小さくするなら公開する設備や利用企業を絞るほうが、体験を壊さず調整できます。図の三段階がつながっていれば、裏側の一部が手作業でも、Web申込みに価値があるかを観察できます。

手作業を残すなら、その時間も予算に入れる

管理画面を簡単にすれば開発量は減りますが、担当者が毎回表を整理するなら、費用は運営へ移ります。申込み一件を処理する時間だけでなく、連絡待ち、変更依頼、担当者が休む日の引き継ぎも考えます。手作業を選ぶ判断は有効ですが、誰が何件まで扱うかが曖昧だと、利用者が増えた瞬間に受付が詰まります。

最初の運用では、手助けした操作も記録してください。毎回電話で説明すれば利用者は完了できても、画面だけで使えるかは分かりません。どこで迷い、どの説明を補ったかを残すと、次の開発で直す場所が具体的になります。手作業の記録は、自動化する価値が大きい仕事を見つける材料にもなります。

予算が足りないときは、対象と試し方を変える

見積もりが予算を超えたら、機能一覧に削除線を引く前に、今回の問いへ戻ります。全業種に売る前に一つの業務に絞る、自由な申込みを定型にするなど、対象を狭めると設計と確認の量も減らせます。反対に、権限確認やデータ保護を省いて帳尻を合わせると、検証に参加する人へ安心して提供できません。

開発会社には、同じ予算で「何を確かめられ、何は分からないか」を説明してもらうと比較しやすくなります。ダンドリのWebサービス開発は80万円〜を公表していますが、任意のMVPをその額で作れるという意味ではありません。機能、データ、連携を確認して個別に見積もります。初回の公開費だけでなく、その後の検証と変更に使う予算も残しておきましょう。

追加したい機能が出たときは、今回の問いに必要な理由を短く書きます。予約の例で「おすすめ順に並べたい」という要望が出ても、設備の違いが分からないなら、先に説明を直す方法があります。同じ予算の中で足すなら、延期する仕事も一緒に決めます。何でもできる将来像と、今試す範囲を一枚の図で分けておくと、社内で企画を共有するときにも、初回からすべて必要だという誤解を減らせます。

公開後は、登録数より「用事を終えたか」を見る

予約サービスなら、閲覧、申込み、確定、再利用を分けて見ます。申込みが少なくても、必要な設備を扱っていなかったのか、入力が難しかったのかで次の対応は変わります。GOV.UKの計測ガイドが示すように、目的に沿った数字と利用者の声を組み合わせると、単に機能を足す以外の判断ができます。

公開前に振り返りの日を置き、利用できた人、途中でやめた人、運営にかかった手間をそろえます。少人数なら率だけでなく件数も確認し、社内のテスト利用は区別します。需要が見えたら自動化する、操作で止まったら直す、別の課題が強ければ企画を変える。こうして次の投資を選べる状態が、初回開発の成果です。

運営が成立するかも振り返ります。申し込んだ人が満足していても、担当者が何度も連絡し、手間をかけて成立させているなら、そのまま広げるのは難しいかもしれません。受付から確定までの時間、差し戻しの理由、支援が必要だった箇所を並べます。需要があり、手間の原因も分かったなら、自動化への投資を考えられます。利用者の反応と提供する側の負担を合わせて見ることで、次に作る機能を選べます。

参考：GOV.UK Service Manual：How to set performance metrics for your service

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □最初に確かめたい問いを一文で言える。確認状況・メモ：
• □試してもらう利用者と、その人が困る場面が決まっている。確認状況・メモ：
• □受付から目的の完了までを通して説明できる。確認状況・メモ：
• □手作業の担当者と、対応できないときの案内を決めた。確認状況・メモ：
• □権限・保存・取消など、省けない処理を確認した。確認状況・メモ：
• □公開後の観察方法と、次の判断日を用意した。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• How the alpha phase worksGOV.UK Service Manual
• How to set performance metrics for your serviceGOV.UK Service Manual