※このページは5原則すべてのコーディング解説ではなく、デザイナーが判断の背景を掴むための入口です。
この技術でできること
- 要件が変わり続ける環境でも、過去のコードを壊さずに新しい機能を追加できる
- UIのコンポーネントが巨大な「神コンポーネント」にならず、保守しやすい適切なサイズに分割される
- サードパーティ（決済システム等）が仕様変更されても、影響を最小限に抑える構造（抽象への依存）を作れる
例: O（オープン・クローズドの原則）を守って設計されたUIシステムでは、新しい種類の「お知らせバナー（アラートや警告用の新しいバリエーションなど）」を追加する際、既存のバナーコンポーネントのコードを一文字もいじることなく、外部から新しいスタイルを流し込むだけで安全に拡張できます。
なぜ難しいか
SOLID原則は、本来オブジェクト指向プログラミングの文脈で生まれた「5つの原則の頭文字」であり、概念が非常に抽象的で、適用を誤ると過剰設計（硬直化：少しの変更で全体が壊れやすくなる、怖くて触れない状態）を招くからです。
- S: Single Responsibility（単一責任）
- O: Open-Closed（オープン・クローズド）
- L: Liskov Substitution（リスコフの置換）
- I: Interface Segregation（インターフェース分離）
- D: Dependency Inversion（依存関係の逆転）
デザイナーがこれを文字通りコーディングレベルで理解する必要はありません。しかし、「なぜエンジニアが既存のボタンを再利用せず、わざわざ新しいボタンを作りたがるのか（O原則）」、「なぜユーザー情報を丸ごと渡さず、画像URLだけをわざわざ渡してくるのか（I原則）」という判断の裏側には、常にこの原則が働いています。
設計プロセスの判断ポイント（Before/After）
パターン: Propsの過剰な受け渡し（Interface Segregation）
Before（現実の悪い例）: 「ユーザーアイコンを表示する小さなUIパーツ」を作る時、デザイナーが「後で何を使うかわからないから、とりあえずユーザーの全情報（アカウント番号、名前、年齢、住所、クレジットカード情報などが入ったオブジェクト）を全部渡して連携して」と指示する。 → エンジニア視点では、単なるアイコン表示にクレジットカード情報まで繋がるのはセキュリティ的にも設計的にも極めて危険である。
After（現実的な整理）: インターフェース分離の原則に従い、そのコンポーネントが「本当に必要な情報（画像URLと代替えテキスト）」だけを提供（Propsとして宣言）する設計にする。
なぜ改善されるか（なぜ現実的か）: 「必要最小限の依存関係」に絞ることで、どこでどのデータが使われているかが明白になり、将来ユーザーデータの構造が変わってもアイコン部品が壊れないからです。
代替手段: データのまとまりを渡したい場合は、「ユーザー情報」ではなく、「Figmaで定義したAvatar情報」という見た目の塊として別のルールで定義し直す。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「とりあえず既存のコンポーネントにフラグ（If文）を足して対応して」
デザイナーの視点: 今回だけ例外的に、既存のArticleCardの右上に「NEW」バッジを出したい。「if (isNew) { バッジ表示 }」という条件を1つ足すだけで済むのだから、素早くやってほしい。（品質＝見た目の素早い再現と共通化）
エンジニアの視点: 既存の安定して動いているコードの中に、特定の画面でしか使わない条件分岐を書き足すのは「オープン・クローズドの原則（変更に対して閉じていなければならない）」に違反する。「神コンポーネント」化の第一歩。（品質＝既存コードを壊さない安全性）
なぜ衝突するか（品質の定義差）: デザイナーは「見た目の効率」で設計を考えますが、エンジニアは「変更による機能破壊（デグレ）のリスク回避」を中心に設計を考えます。
どう合意するか:
- 原則として、既存のコンポーネントの枠組みはそのままに、「外側から機能（バッジ）を注入できる余白（Slot、Children）」を持たせる設計にリファクタリングする。
- エンジニアがコードを安全に保つための「遠回り」の必要性を、デザイナーがデザインシステムの負債防止として理解する。
実践チェックリスト
最低ライン（Must）
[ ] コンポーネントに「あれもこれも（2つ以上の責任）」を持たせていないか確認している（単一責任） [ ] 既存のパーツを無理に改修せず、新しいバリエーションとして拡張できる構造を描けている（オープン・クローズド）
理想ライン（Better）
[ ] 必要な情報だけをパーツに切り出す（インターフェース分離）視点で、エンジニアとAPIの受け渡しを相談できる [ ] これら5つの原則が、システムの「硬直化」を防ぐための共通言語であることを理解したうえで話せる
関連技術
前提となる技術
- コンポーネント設計 —
SOLIDの原則を、フロントエンドのUI分割に適用した姿
次に学ぶ技術
- アーキテクチャパターン —
SOLIDの思想をさらに大規模なシステム全体の骨組みに適用する
まとめ
- この技術の本質: ソフトウェアが「柔らかさ（変更の容易さ）」を失わないための5つの防御壁
- UXへの影響: 技術的負債を防ぐことで、プロダクト全体の「素早い機能改善サイクル」が維持され、UXが向上し続ける
- 実務での判断軸: 「この機能追加は、既存のうまく動いているシステムを“変更”しているか、それとも安全に“拡張”しているか？」
- 次に学ぶべき技術: アーキテクチャパターン（個別のコンポーネントだけでなく、システム全体の大きな構造を学ぶ）
目的別のおすすめ:
