MVPの期間は、どこで伸びるのか

期間を聞く前に決めておく一つ

MVP開発の相談で期間が最初に気になるのは当たり前だ。ところが同じ機能一覧を数社に送っても、返ってくる想定期間はばらばらになる。機能の数だけでは期間が決まらない。MVPは本番サービスを小さく縮めた版ではなく、仮説を確かめる道具だ。「このサービスにお金を払う人がいるか」を調べる最小限と、「正式公開に出しても恥ずかしくない初版」とでは、作業量がまるで違う。

決めることは一つ。今回の版で何を確かめたいのか。確かめる対象がはっきりすれば、受託側も「その目的ならこの画面とこの機能で足りる」と範囲を絞れる。仮説が空のままだと機能一覧は伸び続け、期間はその一覧についていく。

初版から外すものを先に選ぶ

一覧を見直すと、今作らなくていい項目がかなり出てくる。管理画面がその代表だ。初期は注文も申し込みもスプレッドシートで受けて、人が手で処理しても回る。ソーシャルログインを三種つなぐ代わりにメールログイン一つで始めてもいいし、多言語対応や通知、精算の自動化は、利用者が増えるまで人が代わりにやれる。

外すのと雑に作るのは別だ。利用者が実際に触る画面と流れが粗いと、仮説の検証そのものが成立しない。削るのは運用側の都合の機能と、念のための機能だ。人手で回せる仕事は自動化を後回しにして、浮いた時間を利用者が出会う表側に使う。

走り出すと、返事の速さが日程を作る

作業が動き出してから日程を押すのは、たいていコードではない。デザイン案を送って確認を待つ数日、文言の確定を待つ数日が積み上がると、遅れは週単位になる。受託側は決定が来ないと次の画面へ進めない。その待ち時間はそのまま開発期間に乗る。

確認の周期を先に決めて、決める人を一人に絞ると、この遅れは大きく減る。毎週同じ曜日にその週の成果を見て、その場で決める。決裁者が複数いると、違う方向の指摘をすり合わせる時間が別に要る。この段階では、完璧な決定より速い決定のほうが日程に効く。

ストア審査と決済代行は、他人の予定表

開発が終わっても公開できないことがある。アプリはストア審査を通す必要があり、リジェクトされれば直してもう一度並ぶ。決済を受けるなら決済代行との契約と審査が別にあり、事業者側の書類もそろえる。

この日程は受託側が縮められない。開発期間の中に入っていると計算すると、実際の公開日がずれる。

だから、この手続きは開発の初週に一緒に走らせておく。決済代行への申し込み、ストアアカウントの開設、必要書類の準備を、画面の作業と並行させる。外部サービスの連携も同じだ。つなぐ先が決まっているなら、見積もりの段階でサービス名まで書いて送ればいい。連携ドキュメントが薄いサービスや、別の承認手続きを挟むサービスは、それ自体が日程の変数になる。

公開日がもう決まっているなら

開けたい日が先に決まっているなら、その日付から教えてください。確かめたい仮説がまだ一文になっていなくても大丈夫です。Weple のMVP開発は、今回の版で確かめることをそろえたうえで期間を先に固定し、その中に入る範囲を組む順番で進みます。作りたい機能の一覧がすでにあるなら、初版から外す項目を一緒に選びます。費用がどんな基準で決まるかは料金案内に書いてあります。ストア審査や決済代行のように外で回る日程まで入れて、最初の日程表を一緒に引きます。