フロントエンドPMシリーズ 🎉
第5回（最終回） / 全5回
フロントエンドPMのための判断チェックリスト
炎上回避・保存版
フロントエンドPMの仕事は、正解を当てることじゃない。
炎上する判断を、事前に外すことだ。
このチェックリストを使うタイミング
- 設計レビュー前
- 実装着手前
- 本番リリース前
全部できていなくてもいい。
「説明できない項目」があるかどうかだけを見る。
「説明できない項目」があるかどうかだけを見る。
チェック①
役割と責任は言語化されているか
- フロントエンドPMの責任範囲を説明できる
- バックエンドPM／エンジニアの責任範囲を説明できる
- 「どっちでもいい」が残っていない
曖昧な責任は、必ず後で衝突する。
チェック②
フロントとバックの「正」は分かれているか
- 金額・在庫・権限の正はバックエンド
- フロントは表示と一時状態のみ
- フロントに「最終判断」が置かれていない
正を2つ持った瞬間、事故は確定。
チェック③
状態（State）を増やした理由を説明できるか
- その状態は何のために存在するか
- 消えたら何が困るか
- APIとズレたらどうなるか
即答できないなら、その状態は作ってはいけない。
チェック④
グローバル状態は最小限か
- 複数画面で本当に必要か
- 更新タイミングが明確か
- 影響範囲を説明できるか
「便利そうだから」は却下。
チェック⑤
APIは契約として扱われているか
- APIの成功・失敗時の挙動が決まっている
- エラーコードや理由を前提にUIを設計している
- 将来項目が増えたときの影響を想定している
APIを「とりあえず叩く」と、設計は必ず後回しになる。
チェック⑥
バリデーションの責任は分かれているか
- フロント：入力しやすさ・UX
- バック：業務ルール・整合性
フロントは親切、バックは責任。
チェック⑦
エラー時の振る舞いは決まっているか
- どのエラーを利用者に見せるか
- 再試行できるか
- オペレーションに逃がすか
エラー未定義＝仕様未完成。
チェック⑧
「あとで直す」が残っていないか
- 仮実装
- 一時対応
- 暫定対応
これが増えてきたら、設計が破綻し始めているサイン。
チェック⑨
判断を取り消せる設計になっているか
- フロントで行う判断は取り消せる
- 取り消せない判断はバックにある
- 誰が巻き戻せるか決まっている
取り消せない判断をフロントに置いたら終わり。
チェック⑩
PMとして「止める判断」をしているか
- 判断材料が揃っていないのに進めていないか
- 技術で誤魔化していないか
- 「進めること」だけが目的になっていないか
止めるのもPMの仕事。
10個も覚えなくていい
このチェックリストで一番大事なのはこれ。
説明できない判断が、
1つでもあるか？
1つでもあるか？
あるなら、
それが次に燃える場所だ。
それが次に燃える場所だ。
まとめ：フロントエンドPMは「判断を減らす人」
正はバックエンド
状態は最小
APIは契約
エラーは仕様
そして何より、
判断を増やさない。
増やすなら、責任を決める。
それができれば、
フロントエンドPMとして
現場はかなり静かになる。
フロントエンドPMとして
現場はかなり静かになる。
シリーズ完結
この記事で扱ったのは、
ではなく
技術の知識
むしろ
判断の位置
フロントエンドPMとして
「なぜか燃えにくい人」になるための
最低限の装備は、ここに全部ある。
あとは、現場で使うだけ。
フロントエンドPMシリーズ 🎉
第5回（最終回） / 全5回