フロントエンドPMが押さえるべき
フロントエンド開発の進め方と失敗しやすいポイント
フロントエンド開発は、技術だけでなく要件整理・設計・チーム連携が成果を大きく左右する。
特にPMがフロントエンド領域を理解していないと、次のような問題が起きやすい。
- 実装が進むほど仕様が揺れる
- UIはできているのに使いづらい
- バックエンドとの責任分界が曖昧
- リリース直前で大きな手戻りが発生する
この記事では、フロントエンドPMとして最低限押さえるべきポイントを実務ベースで整理する。
フロントエンドPMの役割とは？
フロントエンドPMの役割は、単に「画面側の進捗を見ること」ではない。
主な役割は次の3つだ。
📊 フロントエンドPMの3つの役割
① 要件をUI/UXに翻訳する
- 業務要件を操作単位に分解
- どの状態で何ができるかを明確化
- 利用者目線での設計
② 技術制約を前提に設計を組み立てる
- 状態管理の理解
- APIの粒度・形式
- パフォーマンス制約
③ バックエンドとの境界を決める
- 判断範囲の決定
- バリデーション位置
- エラー責任の明確化
フロントエンド開発でよくある失敗
⚠️ よくある失敗パターン
仕様が画面単位で決まっている
- 状態遷移が考慮されない
- 操作の不整合が生まれる
- 後から破綻する
UIはできているがUXが悪い
- 操作順序が思考と合わない
- 途中状態が考慮されていない
- エラー時の戻り方が不明
責任分界が曖昧
- 不具合の原因が特定できない
- 修正スピードが落ちる
- チーム間の責任が不明確
失敗パターン1: 仕様が「画面単位」で決まっている
❌ 悪い例:
- 画面A
- 画面B
結果:
- ある画面ではできる操作が別の画面ではできない
- 状態遷移が考慮されていない👉 操作単位・状態単位で要件を整理する必要がある。
失敗パターン2: UIはできているがUXが悪い
- ボタンはある
- 入力項目も揃っている
それでも使いづらい原因は:
- 操作の順序が利用者の思考と合っていない
- 途中状態が考慮されていない
- エラー時の戻り方が分かりづらい
PMがUXを設計していないケースが多い。
失敗パターン3: バックエンドとの責任分界が曖昧
フロントエンドで起きた不具合が:
- APIの問題なのか
- UIの問題なのか
- データの問題なのか
分からなくなる。
この状態では、修正スピードが極端に落ちる。
フロントエンドPMが最初にやるべきこと
🎯 PMが最初にやるべき3つのステップ
状態遷移を言語化する
初期状態 → 入力中 → 確認中 → 完了 → エラー
画面一覧ではなく、状態の一覧を作る
API前提で画面を設計する
- 非同期処理中の表示をどうするか
- エラー時に何を見せるか
- APIが返さない情報は表示できない
フロントエンドの判断範囲を決める
- 入力チェックはどこまで行うか
- 表示制御はどこで行うか
- 一時的な状態をどこに持つか
① 状態遷移を言語化する
画面一覧ではなく、状態の一覧を作る:
- 初期状態
- 入力中
- 確認中
- 完了
- エラー
状態遷移の例
各状態からどの状態に遷移できるかを明確にする
② API前提で画面を設計する
- APIが返さない情報は表示できない
- 非同期処理中の表示をどうするか
- エラー時に何を見せるか
この前提がないと、実装時に揉める。
// 良い例: API前提の設計
{
"user": {
"id": "123",
"name": "田中太郎",
"status": "active",
"lastLogin": "2026-02-10T10:00:00Z"
},
"loading": false,
"error": null
}
// 各状態に対応した表示を事前に決める
- loading: true → スケルトン表示
- error: "Timeout" → 再試行ボタン表示
- user: null → 未ログイン画面③ フロントエンドの「判断範囲」を決める
- 入力チェックはどこまで行うか
- 表示制御はどこで行うか
- 一時的な状態をどこに持つか
ここを決めるのが、フロントエンドPMの仕事だ。
フロントエンド vs バックエンドの責任分界
フロントエンド
- ✓ 必須入力チェック
- ✓ 形式チェック（メール、電話番号）
- ✓ 文字数制限
- ✓ 一時的なUI状態管理
- ✓ ユーザビリティの最適化
バックエンド
- ✓ ビジネスロジックのバリデーション
- ✓ 一意性チェック（重複確認）
- ✓ 権限チェック
- ✓ データ整合性チェック
- ✓ セキュリティ検証
どちらで何を判断するかを明確に分けることで、不具合の切り分けが早くなる
責任分界の例:
【フロントエンド】
✓ 必須入力チェック
✓ 形式チェック（メールアドレス、電話番号）
✓ 文字数制限
✓ 一時的なUI状態管理
【バックエンド】
✓ ビジネスロジックのバリデーション
✓ 一意性チェック（重複確認）
✓ 権限チェック
✓ データ整合性チェックフロントエンドPMに必要な最低限の技術理解
コードを書く必要はない。だが、次は理解しておくべきだ。
これを知らないと、実装の妥当性を判断できないPMになる。
まとめ：フロントエンドPMは「翻訳者」ではなく「設計者」
フロントエンドPMは、要件を伝える人ではない。
要件を、実装可能な構造に設計する人だ。
- UI
- UX
- 技術制約
- チーム分業
これらを同時に扱うのが、フロントエンドPMの役割である。
🎯 フロントエンドPMの4つの領域
要件定義
- 業務要件の分解
- 操作単位への変換
- 状態遷移の明確化
設計
- UI設計
- UX設計
- API設計との整合
技術理解
- コンポーネント設計
- 状態管理
- 非同期処理
- パフォーマンス
チーム連携
- バックエンドとの境界
- デザイナーとの協働
- エンジニアとの対話
よくある質問（SEO用）
Q. フロントエンドPMとUIデザイナーの違いは？
A. UIデザイナーは見た目を設計し、フロントエンドPMは動きと構造を設計する。
UIデザイナーは視覚的なデザイン（色、レイアウト、タイポグラフィ）に責任を持ち、フロントエンドPMは「どの状態で何ができるか」「エラー時にどう振る舞うか」といった動的な仕様を決める。
Q. フロントエンドPMにコーディング力は必要？
A. 必須ではないが、理解がないと判断できない場面が多い。
コードを書く必要はないが、「この実装は妥当か」「この変更は影響範囲が大きいか」を判断するには、技術的な理解が不可欠。少なくとも、状態管理、非同期処理、コンポーネント設計の基本概念は理解しておくべき。
Q. フロントエンドPMはバックエンドも見るべき？
A. 見るべき。責任分界を決めるために必要。
「どこまでをフロントエンドで判断するか」を決めるには、バックエンドの実装内容や制約を理解する必要がある。APIの設計、レスポンス形式、エラーハンドリングの方針などは、フロントエンドPMとバックエンドPMが協議して決めるべき事項。
Q. 状態遷移図を作るのに時間がかかります。本当に必要ですか？
A. 必要。後の手戻りを防ぐ投資と考えるべき。
状態遷移図を作らずに実装を始めると、「この状態からこの状態には遷移できるのか？」「エラー時にどの状態に戻るのか？」といった疑問が実装中に頻発し、結果的に手戻りが発生する。事前に整理することで、実装がスムーズになり、不具合も減る。
Q. フロントエンドPMとして最初に読むべき本は？
A. 技術書よりも、UXデザインとシステム設計の基本書を推奨。
推薦図書:
- 「誰のためのデザイン？」（ドナルド・ノーマン）- UI/UXの基本原則
- 「リーン・スタートアップ」（エリック・リース）- 段階的な設計思考
- 「Clean Architecture」（ロバート・C・マーチン）- 責任分離の考え方
その上で、React/Vue.jsなどの公式ドキュメントで技術の基礎を理解すると良い。