変更の影響範囲が整理され、必要なコンポーネントの再利用が考慮されているか？¶
Type: Structure
Category: UI・通知
Audience: 設計初心者 / 設計中のチーム / レビュワー
背景・概要¶
UI変更はロジック・スタイル・状態管理に波及するため、影響範囲を事前に整理し、再利用可能な構造で設計することが重要
再利用可能な設計であれば、他画面への展開・保守性・QA負荷の低減にもつながる
例¶
- 入力フォームをEditableFormとして共通化し、新規作成・編集画面で再利用
- 金額表示コンポーネントを切り出し、各所でCurrencyとして共通利用
- Feature Flag を用いた段階的なUI差し替え
よくある失敗例¶
- 同じコンポーネントの実装が複数箇所に散在し、バグ修正が1箇所で完結しない
- UI変更による副作用の影響が未評価で、リリース後に予期せぬ不具合が発生
- 状態管理ライブラリ（Redux, Vuexなど）の構造が破綻し、ロジックが分散
FAQ¶
Q. 影響範囲の洗い出しはどう行う？
A. DOM構造・状態管理・依存先のAPIをベースに、Storybookの利用やテスト観点レビューで網羅的に確認するとよい
Q. 全てのUIを共通化すべき？
A. 共通化にもコストがかかるため、2画面以上で重複利用が見込まれるものを優先的に共通化するとよい