1. MVP開発で本当に固定されるのは「機能」ではない
MVPでよく削られるのは次のような要素です。
・画面数
・設定機能
・権限管理
・デザイン
しかし、これらはすべて後から足せます。一方で、後からほぼ直せないものがあります。
それが次の3つです。
・状態の寿命
・データ構造の粒度
・UIとロジックの距離
MVPでも、ここだけは必ず決まります。
2. 固定① 状態の寿命をどこに置くか
最初のアプリで必ず決まるのが、状態の寿命です。
・画面を閉じたら消えるのか
・アプリが生きている間は残るのか
・サーバーに永続化されるのか
多くのMVPでは、実装を急ぐあまり、
・画面コンポーネントが状態を持つ
・画面遷移で暗黙的に状態が引き継がれる
という構造になります。
これを後から、
・グローバル状態に移す
・セッション管理を入れる
のは、ほぼ全面改修です。状態の寿命は、最初の1行で決まります。
3. 固定② データの正規化レベル
MVPでは「とりあえず動けばいい」として、次の判断がよく行われます。
・APIレスポンスをそのまま保存
・JSON構造を画面単位で設計
・重複データを許容
この時点で、データの正規化レベルが確定します。
後から、
・検索を高速化したい
・集計を取りたい
・別画面で再利用したい
と思っても、データがUIに最適化されすぎていて使えないという状態になります。
MVPでのデータ設計は、少なすぎても、雑すぎてもダメです。
4. 固定③ 画面とロジックの結合度
初期実装では、ほぼ確実にこうなります。
・ボタン押下で直接処理を書く
・画面内で分岐ロジックを持つ
・API呼び出しがUIに埋まる
これはMVPとしては正解です。問題は、そのまま次に進んだ場合です。
この構造を引きずると、
・テストが書けない
・ロジックの再利用ができない
・画面修正が仕様修正になる
UIとロジックの距離は、後から離そうとすると必ず破壊が起きます。
5. なぜこの3点は後から直せないのか
理由は単純です。
この3つは依存関係で直列につながっています。一番上を変えると、下がすべて壊れます。
MVPで一度でもユーザーに使われた時点で、
・状態の期待値
・データの意味
・画面の挙動
が暗黙的に固定されます。
7. MVPとして成立する最小構造の実態
現実的なMVPの最小構造は、次のレベルです。
これ以上増やすと検証がぼやけ、これ以下だと実運用に耐えません。
「小さく作る」とは、この単位を増やさないことを意味します。
8. 技術者視点でのMVP判断チェックリスト
実装前に、最低限これだけは言語化すべきです。
・この状態はいつ消えるか
・このデータはどの画面で再利用されるか
・このロジックは画面外に出る可能性があるか
これに答えられないまま書いたコードは、MVP後に必ず足を引っ張ります。
スタートアップのアプリプログラミングにおけるMVP開発は、機能を削る作業ではありません。状態の寿命、データ構造の粒度、画面とロジックの結合度という三つの技術前提を、どこまで許容するかを決める作業です。最初のアプリで失敗するかどうかは、何を作ったかではなく、何が固定されたかで決まります。
