フロントエンドPMシリーズ
第3回 / 全5回
フロントエンドPMのための状態管理ベストプラクティス
グローバルにする判断基準と、事故るサイン
フロントエンド開発で、PMが一番やらかしやすい判断がある。
この状態、グローバルに持ちますか？
ここで曖昧なまま進むと、後から必ず壊れる。
この記事では、
Reduxが良いZustandが良いContextはダメ
みたいな話はしない。
代わりに、PMとして「いつグローバルにしていいか」「いつ止めるべきか」
その判断基準だけを整理する。
そもそも「状態管理」で壊れる理由
状態管理が難しい理由は単純だ。
状態は、増えた瞬間に"影響範囲"を持つ。
影響範囲の伝播
1画面の話だと思っていた
1機能だけのつもりだった
それがいつの間にか、
- 他画面
- 他機能
- 他チーム
に伝播する。
問題は技術ではない。
PMが「影響範囲」を見ないまま判断していることだ。
PM向けに定義する「状態」の種類
まず整理する。
PMは、この3種類を区別しないと判断できない。
PM判断: ローカルで持ってOK
① 表示のためだけの状態
（UI State）
例：
- ローディング中
- モーダルの開閉
- 入力途中
特徴
- 表示にしか使わない
- 消えても問題ない
- APIと関係ない
むしろグローバルにしない
PM判断: 二重管理しない
② データ由来の状態
（Server State）
例：
- APIから取得した一覧
- 詳細データ
- 更新結果
特徴
- 正はバックエンド
- 再取得できる
- 同期ズレが最大リスク
フロントで"正"を作らない
PM判断: フロントに持たせない
③ 業務を左右する状態
（Business State）
例：
- ステータス
- 権限
- 確定フラグ
特徴
- 取り消せない
- 業務判断に直結
- 間違うと事故る
表示するだけ
グローバルにしていい条件【PM判断軸】
ここが一番大事。
グローバルにしていい状態の条件
次の3つをすべて満たす場合のみ。
- 複数の画面・機能で使う
- 更新タイミングが明確
- 影響範囲を説明できる
「便利そうだから」は理由にならない。
グローバルにしてはいけないサイン
現場でよくある地雷。
- とりあえず共有したい
- Contextで渡すのが面倒
- あとで整理する予定
これが出た瞬間、PMは止めるべき。
「後で整理する状態は、必ず整理されない」
PMがレビューで必ず聞くべき質問
コードを読まなくていい。
この質問だけでいい。
- この状態は、どこで生まれる？
- それが変わったら、どこが再描画される？
- 仕様が変わったら、どこを直す？
ここで即答できない設計は、グローバルにしてはいけない。
よくある失敗パターン（PM視点）
失敗①
「画面間で共有したい」
からグローバル化
からグローバル化
後で「この画面では使わない」が始まり、if地獄になる。
失敗②
APIの状態を
フロントで加工して保持
フロントで加工して保持
正がどれか分からなくなる。再取得のたびに壊れる。
失敗③
業務判断を
フロントで吸収
フロントで吸収
バックエンドと責任分界が崩壊。炎上一直線。
状態管理でPMが守るべき一文
これだけ覚えておけばいい。
「その状態、
なくなったら何が壊れる？」
なくなったら何が壊れる？」
答えが
画面だけ
→ ローカル
業務
→ バックエンド
よく分からない
→ 作らない
まとめ：状態管理は「技術選定」じゃない
フロントエンドPMにとって、状態管理はツールの話ではない。
Reduxか
Zustandか
Contextか
ではなく、
「どこまでフロントが責任を持つか」
を決める設計の話だ。
- 表示はフロント
- 正はバックエンド
- 迷ったら増やさない
これだけ守るだけで、
React案件の事故率は劇的に下がる。
フロントエンドPMシリーズ
第3回 / 全5回