シード期のMVPはどこまで作るか

シード期のMVPで最も多い失敗は、「機能を絞ったつもりが、絞ったそれぞれを丁寧に作りすぎる」ことです。機能の数は減っていても、管理画面、権限、通知、設定といった周辺を一通り整えると、結局は完成品と変わらない工数になります。

MVPの考え方そのものはMVP開発とは — 最小限の機能で市場検証を始める方法で扱っています。本記事は、シード期という制約のもとで、周辺機能を機能ごとにどこまで省けるかに絞って整理します。

判断の基準は一つ

省けるかどうかの基準は、「省いたときに、検証の結果が読めなくなるか」の一点です。

検証で見たいのは、利用者が価値を感じて繰り返し使うかどうかです。ここで、省いたせいで動作が不安定になったり、途中で操作が詰まったりすると、「価値がなかったから使われなかった」のか「使えなかったから使われなかった」のかが分からなくなります。この判別ができなくなる省き方だけは避けます。

逆に言えば、それ以外は省けます。以下、機能ごとに見ていきます。

管理画面 — 多くは省ける

自社の担当者が使う管理画面は、シード期に省きやすい筆頭です。利用者が数十から数百の規模なら、データベースの管理ツールや、読み取り専用の一覧画面だけで運用できることがあります。

省き方の順序は次のとおりです。

1. まず、管理画面で何をするつもりかを列挙する
2. そのうち、週に一度も発生しない操作を外す
3. 残った操作のうち、開発者が直接対応できるものを当面手作業にする
4. それでも毎日発生する操作だけを画面にする

この手順を踏むと、当初は十画面ほどを想定していたものが、実際に必要な画面は一つか二つだった、という形に落ち着くことがあります。

ただし注意点があります。担当者が本番データを直接触る運用は、操作ミスと権限の問題を伴います。触れる人を限定し、何をしたかの記録が残る形にしてください。この扱いはスタートアップのセキュリティと個人情報保護の考え方に沿います。

決済 — 「課金の有無」と「決済の実装」を分ける

ここは混同されやすい論点です。有料であることを検証するのと、決済機能を作ることは別の話です。

支払い意思の確認だけなら、請求書での個別支払い、事前の申込、口座振込といった手段で足ります。件数が少ないうちは、この運用のほうが速く、顧客と会話する機会も増えます。

決済の実装で時間がかかるのは、決済そのものより周辺です。

• 決済が失敗したときの再試行と通知
• 返金と一部返金の扱い
• 解約と日割りの計算
• 請求書と領収書の発行
• 消費税やインボイスに関する表示

これらを一通り作ると、それだけで相応の工数になります。有料契約の件数が二桁の前半にとどまる間は、運用で吸収するほうが合理的なことが多いです。件数が増えて運用が破綻し始めたら、そのとき実装します。なお、課金の設計そのもの（何に対していくら取るか）は件数に関係なく早く決めるべき論点で、マネタイズモデルの比較で扱っています。

契約や税務の取り扱いについては、一般的な情報の範囲を超えるため、個別の事案は専門家にご確認ください。

権限管理 — 種類を減らす、仕組みは作らない

権限は、「柔軟な権限の仕組みを作る」のではなく「権限の種類を減らす」方向で省きます。

シード期に必要な権限は、多くの場合次の二つか三つです。

• 一般の利用者
• 組織の管理者（法人向けの場合）
• 自社の運営者

役割ごとに細かく設定できる仕組みは、顧客から要望が出てから作ります。要望が出る前に作ると、実際に使われる組み合わせが分からないまま構造だけが複雑になり、後から変更しづらくなります。

一方で、省いてはいけないのは「他人のデータが見えない」ことです。これは権限の柔軟さとは別の、基本的な要件です。ここが曖昧なまま公開すると、検証どころか信用の問題になります。

通知・設定 — 初期値を固定にする

通知の種類を増やす、通知するかどうかを利用者が選べるようにする、といった設定は後回しにできます。

シードの間は、必要な通知だけを固定で送り、設定画面を作りません。設定画面を作ると、設定の保存、初期値、変更時の挙動、設定に応じた分岐がすべて必要になり、想像以上の作業量になります。

例外は、通知が多すぎて利用者が離れる場合です。その兆候が出たら、選択肢を作るのではなく、まず通知そのものを減らします。

省けないもの

一方で、シード期でも省けないものがあります。

• 中心となる体験の完成度。検証したい行動の流れは、途中で詰まらずに一通り動く必要があります
• データが消えないこと。バックアップの仕組みは地味ですが、失われたデータは検証をやり直せません
• 他人のデータが見えないこと。前述のとおりです
• 何が起きたかを後から追えること。誰がいつ何をしたかの記録がないと、問い合わせに答えられず、不具合の再現もできません
• 利用者の行動が観察できること。検証が目的である以上、結果を読む手段がないMVPは意味を持ちません

最後の点は見落とされがちです。凝った分析基盤は不要ですが、「誰が、いつ、どの操作をしたか」が分かるだけで、検証の解像度は大きく変わります。

省くと押し切られる場面での立場

範囲を絞る話は、合意した直後から崩れ始めます。崩れ方は決まっていて、「これくらいなら入れてもいいのでは」という一件ずつの追加です。弊社が開発をご一緒する際、最も強くお伝えするのはこの局面の扱いです。

追加の要望が出たとき、次の二つの問いだけで判断します。

1. これを省くと、検証の結果が読めなくなるか。 ならないなら入れません
2. 入れることで、リリースが何日延びるか。 日数で答えられないなら、見積もってから判断します

この二問で判断すると、大半の追加は入りません。実際に多いのは、「投資家への説明で見栄えがする」「競合が持っている」「後から足すと大変そう」という理由の追加です。いずれも検証の結果を読む役には立たず、リリースを遅らせます。

「後から足すと大変そう」で押し切られた場合に何が起きるか、想定の例で追います。シードのMVPで管理画面を省く判断をしていた、としましょう。リリース前に「顧客に見せたときに管理機能がないと不安がられる」という意見が出て、簡易な管理画面を足すことになります。実装は二週間で収まりましたが、権限の扱い、操作の記録、誤操作時の復旧まで含めると、結果として一か月を要しました。この間に検証は止まりました。検証で確かめたかったのは「現場の担当者が使い続けるか」であり、管理画面はその答えに影響しませんでした。

弊社は、この局面で発注側の意向に沿わない意見を申し上げます。 範囲の追加は受注額を増やす方向なので、請け負う側としては通したほうが得です。それでも止めるのは、検証が遅れた分だけランウェイが減り、次の判断が遅れるからです。範囲を守るとは、追加を断る人を決めておくことでもあります。その役割を発注側の誰が持つのかを、着手前に決めておいてください。

後で作り直す部分を先に決める

省いた結果として、後で作り直す部分が出てきます。ここで効くのが、作り直す前提の部分と長く残す部分を先に分けておくことです。

分け方の目安は、「事業の仮説に依存するか」です。仮説が変われば作り直すもの（画面の流れ、料金の体系、マッチングの条件）と、仮説が変わっても残るもの（利用者の情報、認証、データの保存）を分けて置きます。混ぜて書かなければ、後から片方だけを差し替えられます。

この分離は、意図して抱える技術的負債として扱えます。無自覚に溜まった負債と違い、どこを返すかが最初から分かっているぶん、返済の見通しが立ちます。返す順番の考え方は調達後に返す技術的負債の順番で扱います。

範囲を決めたあとにやること

範囲を決めたら、省いた機能の代わりに誰が何を手でやるのかを、名前を書いて決めてください。「管理画面は作らない」とだけ決めて運用の担当を決めないと、リリース後に問い合わせが来た時点で開発が止まります。

省く判断は、運用を引き受ける判断とセットです。ここまで決められていれば、シードのMVPは想定よりかなり小さく収まります。費用の考え方はMVP開発の費用相場で扱っていますが、案件により大きく異なるため、範囲の相談とあわせてご確認ください。

MVPの範囲の切り分けについては、Webシステム開発やUXデザインのページとあわせてお問い合わせからご相談ください。