フロントエンドPMシリーズ
第2回 / 全5回
フロントエンドPMが知っておくべきReact開発の考え方
【実装しない人向け】
フロントエンドPMは、Reactのコードを書く必要はない。
ただし、Reactで何が起きているかを理解していないと、設計判断ができない。
この記事では、
- コンポーネントの書き方
- hooksの使い方
は一切扱わない。
代わりに、React前提でPMが判断すべきポイントだけを整理する。
なぜReactを知らないPMは詰まるのか
React開発でPMが詰まる瞬間は、だいたい決まっている。
- 「それ、React的にどうなんですか？」と言われる
- 状態をどう持つかで議論が止まる
- 修正の影響範囲が読めない
原因はシンプル。
Reactの"設計単位"を知らないまま、画面や機能の話をしているから。
React開発の基本単位は「画面」ではない
PMが最初に理解すべきこと。
Reactの基本単位は画面でもページでもない。
コンポーネントだ。
コンポーネントとは何か（PM向け定義）
- 見た目
- 振る舞い
- 必要なデータ
をひとまとまりにした責任単位。
つまりReactでは、
「どこまでを一つの責任として扱うか」
を決めることが、そのまま設計になる。
PMが判断すべきコンポーネント分割の観点
ここがSEO的にも刺さる部分。
分けていいサイン
- 表示条件が違う
- 使い回される
- 仕様変更が入りそう
分けないと、修正コストが指数関数的に増える。
分けない方がいいサイン
- 見た目以外の差がない
- 状態を共有しすぎる
- 分けた理由を説明できない
分けすぎると、構造が理解できなくなる。
PMは「きれいに分ける」ではなく
「将来壊れにくい単位」を選ぶ。
Reactにおける「状態」は設計そのもの
React開発での最大の設計論点は、状態（State）だ。
ここでPMが判断を間違えると、あとから取り返しがつかない。
PMが最低限理解すべき状態の種類
PM判断: 自由に持っていい
① 表示のための状態
- ローディング中
- 開閉状態
- 入力途中
PM判断: 二重管理しない
② API由来の状態
- 取得したデータ
- 更新結果
フロントで正を作らない
PM判断: フロントに持たせない
③ ビジネス状態
- 進行ステータス
- 権限
- 確定フラグ
バックエンド責務
React PMがやってはいけない判断
現場で多い地雷。
- 「とりあえずフロントで持ちましょう」
- 「UI側で吸収しましょう」
- 「後で整理すれば大丈夫です」
Reactは、後で整理しにくい構造を持つ。
一度持たせた状態は、必ず他のコンポーネントに伝播する。
PMが止めるべきサイン。
PMがレビューで見るべきReact設計の質問
コードは見なくていい。
この3つを聞くだけでいい。
- この状態は、どこで生まれた？
- それが変わったら、どこに影響する？
- 将来この仕様が変わったら、どこを直す？
ここで即答できない設計は危ない。
React前提でのPMの立ち位置まとめ
フロントエンドPMは、
Reactを書く人 ではない。
Reactで壊れにくい判断をする人だ。
- コンポーネントは責任単位
- 状態は設計そのもの
- 取り消せない判断はフロントに置かない
これを理解しているだけで、
React案件の炎上率は激減する。
フロントエンドPMシリーズ
第2回 / 全5回