関心の分離（Separation of Concerns）
この技術でできること
- 見た目とデータ取得を切り離し、UI変更を安全に行える
- 特定の機能を変更した際、 関係のない別の機能が壊れるバグ（デグレ）を防ぐ ことができる
- どんなデータをどう見せるか（プレゼンテーション層）の 画面デザインに集中 できる
例 ** : カートに商品を追加するボタンを見た時、「ボタンの色とホバーのアニメーション」という ** 関心事（見た目） ** と、「サーバーに在庫を問い合わせて減少させる」という ** 関心事（ビジネスロジック） を、コード上で独立したファイルに分けて書く。これにより、デザイナーが「色を赤に変えたい」と言った時、在庫システムを一切触らずに安全に色だけを変えられる。
なぜ難しいか
システムを作っていると、様々な処理が一つの場所に「混ざりやすい」からです。
最初は単にユーザー名を表示するだけのUIでも、やがて「未ログインなら非表示にする」「長い文字は省略する」「アイコン画像を非同期で読み込む」など、無数の「別の関心事」が同じコードの中に書き込まれていきます。この巨大で複雑な一枚岩（モノリス型のコード）ができると、わずかなUIの微修正すら「どこに影響が出るか分からないから触りたくない」とエンジニアに敬遠される負債となります。
デザイン時の判断ポイント（Before/After）
パターン: 役割を分けたコンポーネント設計
Before（現実の悪い例） : 「ユーザーカード」のUIに、データ取得からエラー処理、クリック処理、細かなマージン調整まで、すべての役割を持たせて1つのまとまりとしてFigmaで定義（または実装）する。 → デザインだけ別バージョンに変えたいのに、データ取得ロジックが中にハードコードされているため、流用できずに新しくカード全体を作り直す羽目になる。
After（現実的な整理） : 関心を「見た目」と「箱」に分ける。
- Container（箱） : データ取得とエラーハンドリングだけを関心事とする透明な箱にする。
- Presentational（見た目） : データを受け取って単に表示するだけの純粋なUIにする。
なぜ改善されるか（なぜ現実的か） : 役割が分かれることで、「同じ見た目のまま取得先が変わる場合」や「データは同じだがモバイルアプリ向けのUIに変える場合」に、片方のパーツだけを差し替えて再利用（スワップ）できるようになるからです。
代替手段 : 最初から完璧に分離するのは難しい場合、最初は混ざった状態で作り、2回使い回す必要が出たタイミングで初めて分離する（YAGNIと組み合わせる）。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「どうせ同じセットなんだから、API通信までデザインパーツに含めて」
デザイナーの視点 : NotificationItemというFigmaコンポーネントに、常に既読ステータスをサーバーに送るロジックまで含めた「完成品」を作ってくれれば、色々な画面に簡単に使い回せる。（品質＝配置するだけの完全な部品化）
エンジニアの視点 : UIコンポーネントの中にAPI通信（副作用）を入れると、テストが非常に難しくなり、通信エラー時の画面ごとの見せ方の制御などが効かなくなる。（品質＝純粋な関数としてのUI機能と、副作用の完全分離）
なぜ衝突するか（品質の定義差） : デザイナーは「オールインワンのモジュールの便利さ」を重視し、エンジニアは「システムとしての予測可能性やテストのしやすさ」を重視しているため。
どう合意するか :
- 「表示するパーツ（ボタン、カード等）」には一切の通信やビジネスロジックを持たせない方針で合意する。
- デザイナーは「純粋なUI」を渡し、エンジニアは画面ごとの「親側」で必要な処理を注入してつなぎ合わせる。
実践チェックリスト
最低ライン（Must）
[ ] 「データをどう見せるか（UI）」と「データがどう操作されるか（ロジック）」を混同して話していない [ ] 1つのコンポーネントが「あれもこれも」と複数の役割を持ちすぎていないか見直している
理想ライン（Better）
[ ] Figmaの設計レイヤーでも、「基盤となるレイアウト（枠）」と「中のコンテンツ」の関心が分かれている [ ] 常に「この変更は、システムのどの関心（見た目か、データか、操作か）に対する変更か」をエンジニアと共有できている
関連技術
前提となる技術
- KISS原則 — 複数の役割が混ざるとシンプルではなくなる
次に学ぶ技術
- コンポーネント設計 — フロントエンドにおける関心の分離の実践
まとめ
- この技術の本質 : 変更が他に波及しないよう、システムの境界線を引くこと
- UXへの影響 : システムが柔軟になり、新しいUIの投下が容易になり、体験の改善サイクルが速まる
- 実務での判断軸 : 「UIの色を変えるために、サーバーやデータベースのコードを読んで直す必要がないか？」
- 次に学ぶべき技術 : コンポーネント設計（関心をUIとしてどう切り出すかの定石）
目的別のおすすめ :
- アプリ全体の構造パターンを知るなら → アーキテクチャパターン
- オブジェクト指向の原則を知るなら → SOLID原則