フロントエンドPMシリーズ
第1回 / 全5回
フロントエンドPMのためのベストプラクティス
迷ったときに「間違えにくい判断基準」
フロントエンドPMの仕事は、正解を当てることではない。
外しにくい判断を積み重ねることだ。
フロントエンド開発では、常に複数の「正しそうな選択肢」が並ぶ。
- フロントで持つか、バックで持つか
- 今作るか、後で作るか
- 厳密にやるか、割り切るか
この記事では、フロントエンドPMが迷ったときに使える「判断のベスプラ」を整理する。
技術の正解集ではない。
PMとして事故りにくい選び方の話だ。
ベスプラ① フロントエンドで「判断していいこと／ダメなこと」
まず一番多い迷い。
これはフロントで判断していいのか?
判断していいこと
- 表示制御（見せる／見せない）
- 操作可能・不可の切り替え
- 一時的な入力チェック
理由は単純で、誤っても取り消せるから。
判断してはいけないこと
- ビジネスルールの確定
- 取り消せない状態遷移
- 金額・在庫・権限の最終判断
これをフロントに寄せると、仕様変更＝即破綻になる。
「取り消せない判断は、フロントに置かない」
ベスプラ② 状態（State）を増やしていい条件・ダメな条件
状態管理は、フロントエンドPMが最も事故りやすい領域。
状態を増やしていい条件
- 表示のためだけに必要
- 他の画面・機能に影響しない
- 再読み込みで消えても問題ない
例:
- ローディング中かどうか
- 入力途中かどうか
状態を増やしてはいけない条件
- 複数画面で共有される
- API結果と二重管理になる
- 「どれが正か」説明できない
ここで状態を増やすと、後から必ずバグる。
「その状態、APIとズレたらどうなる？」
即答できなければ増やさない
即答できなければ増やさない
ベスプラ③ API仕様が固まっていないときの進め方
現場でよくある状況。
APIまだだけど、画面は先に作りたい
これは条件付きでOK。
進めていい条件
- APIの責務が明確
- エラーケースが想像できる
- 画面が「仮」だと全員理解している
止めるべきサイン
- APIの返却項目が増え続けている
- 画面側でデータ加工が始まる
- 「とりあえず」で判断が置かれ始める
「画面が先行していいのは、
APIの責任範囲が固まっているときだけ」
APIの責任範囲が固まっているときだけ」
ベスプラ④ フロントエンドPMが介入すべきレビュー観点
フロントエンドPMはコードレビューをする必要はない。
だが、見ないといけないレビュー軸がある。
見るべきポイント
- この判断、どこで確定しているか
- 状態が増えた理由を説明できるか
- 後から仕様変更したら、どこが壊れるか
ここを聞いて説明が曖昧なら、設計がまだ未完成。
「将来の変更点を説明できない設計は止める」
ベスプラ⑤ PMが「今はやらない」と言うべきタイミング
PMの仕事は進めることだけじゃない。
止めるべきタイミング
- 判断材料が揃っていない
- 技術で誤魔化し始めた
- 「あとで直す」が増えた
ここで止めないと、後で必ず炎上する。
「迷っている時点で、設計は未完成」
まとめ：ベスプラは「逃げ道を減らすため」にある
フロントエンドPMのベスプラは、正解を当てるためではない。
間違えにくい選択肢を残すためにある。
- 取り消せない判断はフロントに置かない
- 状態は増やす理由を説明できるときだけ
- APIが曖昧なら、画面も仮にする
- 将来の変更点を説明できない設計は止める
これだけ守るだけで、炎上率は目に見えて下がる。
フロントエンドPMシリーズ
第1回 / 全5回