個人開発でMVPを絞る方法：作らないことを決める実践ガイド

機能を減らしすぎると、何のためのサービスなのか伝わらない画面だけが残ります。MVPを決めるときは、機能単位ではなく、ユーザーが目的を達成する一連の行動で考えます。

たとえば『相談内容を整理するサービス』なら、入力欄だけでは価値を感じにくく、論点の整理と次のアクションの提案までが最小体験になるかもしれません。

各機能を追加する前に、次の質問へ答えます。3つとも必要ならMVP候補、そうでなければPhase2候補です。

• この機能がないと、中心価値を体験できないか
• 最初の利用で、ユーザーが自分の課題を解決できたと感じるか
• モックデータや手作業で代替しても、まず仮説を検証できるか

ログイン、保存、外部API、通知は便利ですが、実装と運用の負担を増やします。まずはモックデータや限定的な手入力で中心体験を確かめ、継続利用したい理由が見えてから追加するほうが判断しやすくなります。

ただし、たとえば共同編集サービスのようにログインが価値そのものに直結する場合は例外です。重要なのは一般論ではなく、そのアイデアの中心価値に必要かどうかです。

後回しにする機能は、単に一覧へ逃がすのではなく、どんな結果が出たら追加するかを決めます。『週に何度も使われるなら履歴保存を追加する』『情報更新を追えないという声が多ければ通知を検討する』のように条件を置くと、次の投資判断がしやすくなります。