フロントエンドPMシリーズ
第4回 / 全5回
フロントエンドPMが決めるバックエンドとの責任分界ベストプラクティス
フロントエンド開発が荒れる原因は、
技術力不足でも、コミュニケーション不足でもない。
責任分界が曖昧なまま進んでいることだ。
特にフロントエンドPMは、次の問いから逃げられない。
これはフロントの責任か？
それともバックエンドか？
この記事では、
フロントエンドPMが判断すべき「線の引き方」を
実務ベースで整理する。
なぜ責任分界は必ず揉めるのか
理由はシンプル。
フロントエンド
「体験」を見る
バックエンド
「正しさ」を見る
この2つは、必ず衝突する。
どちらも正しい。
だからこそ、事前に線を引いていないと、必ず炎上する。
PMが理解すべき前提：フロントとバックの役割は対等ではない
まず誤解を壊す。
フロントが軽い
バックが重い
ではない。
役割が違うだけ。
バックエンドの役割
- 正を持つ
- 取り消せない判断をする
- 業務ルールを保証する
フロントエンドの役割
- 見せる
- 誘導する
- 一時的に補助する
この前提を外すと、
どんな設計も破綻する。
責任分界① 「正（マスター）」はどこにあるか
最初に決めるのはこれ。
このデータの「正」はどこか？
バックエンドが正であるもの
- 金額
- 在庫
- ステータス
- 権限
フロントが持っていいのは？
- 表示用の加工
- 並び替え
- 一時的な入力状態
例外なし。フロントが正を持った瞬間、事故る。
正ではないものだけ。
「これ、ズレたら誰が責任取る？」
答えが曖昧なら、
フロントに置いてはいけない。
責任分界② バリデーションはどこまでやるか
これも揉めやすい。
場所
種類
理由
フロント
未入力チェック
文字数制限
フォーマット（メール等）
文字数制限
フォーマット（メール等）
UX向上のため
バック
業務ルール
整合性チェック
権限チェック
整合性チェック
権限チェック
フロントは信用しない
「フロントのバリデーションは親切、バックのバリデーションは責任」
責任分界③ エラー時の責任はどこにあるか
エラー対応は、責任分界が一番露出する場面。
PMが決めるべき3点
1. エラーの種類（業務／技術）
2. 再試行できるか
3. 利用者に何を伝えるか
やってはいけない例
- フロントでエラーを握りつぶす
- 「想定外」で済ませる
- とりあえず汎用メッセージ
エラーは仕様の一部。PMが決めないと、必ず後回しになる。
責任分界④ APIは「実装の詳細」ではない
フロントエンドPMが一番意識を変えるべきポイント。
APIは、フロントとバックの契約書だ。
このAPIで何を保証しているか
失敗時、何が返るか
将来項目が増えたらどうするか
ここを決めずに「とりあえず叩く」は、
設計放棄。
PMが間に入るべきタイミング
PMが介入すべきサインは明確。
これが出たら介入
- フロントが業務判断を持ち始めた
- バックがUXを気にし始めた
- 「それはそっちで」が増えた
これは衝突ではなく、
線が引かれていないサイン。
PMの仕事は、どちらかの肩を持つことじゃない。
線を引くことだ。
判断に迷ったときの一文
最後に、PMが迷ったときの判断軸を1つ。
「それは、取り消せる判断か？」
取り消せる
↓
フロント
取り消せない
↓
バック
これで8割の議論は終わる。
まとめ：責任分界は「技術設計」ではなく「PM設計」
正
バックエンド
体験
フロントエンド
API
契約
エラー
仕様
これを誰が決めるか？
フロントエンドPMだ。
フロントエンドPMシリーズ
第4回 / 全5回