「コンポーネントを作ったはいいけど、数が増えすぎて管理が大変…」
「新しいメンバーが入ってきた時に、どのコンポーネントを使えばいいか説明するのが難しい…」
「似たようなコンポーネントが重複して、どんどん肥大化している…」
現場のデザイナーなら、誰もが直面したことのある悩みではないでしょうか。
コンポーネントは作れば作るほど便利になるはずが、かえって使いづらくなってしまう。
その原因の多くは、コンポーネントの階層構造の設計にあります。
この記事では、実際の現場で活用できる階層構造の設計方法を、具体例を交えながら解説していきます。
アトミックデザインの考え方を基本としながらも、現実のプロジェクトに合わせた実践的なアプローチをお伝えします。
明日からのデザイン作業で即実践できる、コンポーネント設計の具体的なテクニックをご紹介していきましょう。
1. 階層構造の基本的な考え方
コンポーネントを作成していくと、必ず直面するのが階層構造の設計です。適切な階層構造がないと、以下のような問題が発生します：
- コンポーネントの重複が増える
- 必要なコンポーネントが見つけにくい
- 更新や修正が煩雑になる
ではなぜ、階層構造が重要なのでしょうか？
1-1. 理想的な階層構造とは
良い階層構造には、以下の3つの特徴があります：
検索性：探したいコンポーネントがすぐに見つかる
- 論理的な分類
- 一貫性のある命名
- 適切な粒度分け
再利用性：必要な場所で効率的に使える
- 汎用的な設計
- 明確な役割分担
- 適切な依存関係
保守性：更新や修正が容易
- シンプルな構造
- 一貫性のあるルール
- 適切なドキュメント化
1-2. 現場での実践的なアプローチ
実際のプロジェクトでは、以下のような階層構造がお勧めです：
Components/
├── Base/（基本要素）
│ ├── Button
│ ├── Input
│ └── Icon
├── Common/（共通パターン）
│ ├── Header
│ ├── Navigation
│ └── Footer
└── Feature/（機能別）
├── ProductCard
├── SearchResults
└── UserProfileこのような構造にすることで：
- チーム内での共通理解が容易に
- コンポーネントの役割が明確に
- メンテナンスがしやすく
なにより、新しくチームに参加したメンバーでも、直感的にコンポーネントを探せるようになります。
2. アトミックデザインの効果的な活用
Figmaでコンポーネントの階層構造を考える際、多くのプロジェクトでアトミックデザインの考え方を採用しています。しかし、その基本概念を理解しているだけでは、実践的な活用は難しいでしょう。
このセクションでは、アトミックデザインをFigmaでどのように活用すべきか、実務的な視点から解説します。
2-1. アトミックデザインの基本概念
アトミックデザインは、化学の周期表からヒントを得た考え方です。UIの要素を以下のように分類します：
Atoms（原子）
├── 最小単位のUI要素
│ ├── ボタン
│ ├── アイコン
│ └── テキスト入力
└── 特徴：それ以上分解できない
Molecules（分子）
├── 複数のAtomsで構成
│ ├── 検索フォーム
│ ├── ナビゲーションリンク
│ └── 入力フィールド
└── 特徴：特定の機能を持つ
Organisms（有機体）
├── より大きな機能単位
│ ├── ヘッダー
│ ├── カード
│ └── フォームセクション
└── 特徴：完結した機能を持つ2-2. Figmaでの実践的な適用
理論を理解したら、次は実践です。Figmaでは以下のような構造にすることをお勧めします：
🧱 Base Components/（Atoms）
├── Button
├── Input
└── Icon
🧩 Common Components/（Molecules）
├── SearchBar
├── MenuItem
└── FormField
📱 Feature Components/（Organisms）
├── ProductCard
├── NewsArticle
└── UserProfile重要なのは、この構造を厳密に守ることではなく、プロジェクトの規模や性質に応じて柔軟にカスタマイズすることです。
2-3. カスタマイズのポイント
実務では、以下のようなポイントを意識してカスタマイズすることをお勧めします：
命名規則の工夫
Base/Button/Primary
└── 階層/要素/バリエーション
Common/Card/Blog
└── 階層/要素/用途
Feature/Dashboard/StatCard
└── 階層/機能/要素検索性の向上
- 絵文字によるビジュアルヒント
- プレフィックスの活用
- 一貫性のある命名
メンテナンス性の考慮
- 依存関係の明確化
- バージョン管理の仕組み
- ドキュメントとの連携
3. 実践的な階層設計の手順
理論を理解したところで、実際にどのように階層設計を進めていけばよいのでしょうか。
このセクションでは、現場での具体的な手順とポイントを解説します。
3-1. コンポーネントの分類方法
まずは既存のデザインを棚卸しし、コンポーネントを分類していきます。以下の3つの観点が分類の基準として有効です：
使用頻度による分類
High（高頻度）
├── ボタン
├── 入力フィールド
└── アイコン
※プロジェクト全体で繰り返し使用
Medium（中頻度）
├── カード
├── リスト
└── モーダル
※特定の機能内で複数回使用
Low（低頻度）
├── 特殊なフォーム
├── カスタムグラフ
└── ユニークな機能
※限定的な場面でのみ使用機能による分類
Navigation/
├── グローバルナビ
├── サイドメニュー
└── パンくず
Forms/
├── 入力フィールド
├── セレクトボックス
└── チェックボックス
Content/
├── 記事カード
├── 商品一覧
└── プロフィール再利用性による分類
Shared/（複数プロジェクトで使用）
├── ボタン
├── フォーム要素
└── アイコン
Project/（プロジェクト固有）
├── 特殊な機能
├── カスタムコンポーネント
└── ページ固有の要素
3-2. 効率的なフォルダ構造の作り方
分類が決まったら、次はフォルダ構造を整理します。以下のような構造がお勧めです：
Design System/
├── 00_Guidelines/
│ ├── Colors
│ ├── Typography
│ └── Spacing
├── 01_Base/
│ ├── Button
│ ├── Input
│ └── Icon
└── 02_Components/
├── Navigation
├── Form
└── Content重要なポイント：
- 番号プレフィックスで順序を制御
- 関連する要素をグループ化
- 検索しやすい命名を採用
3-3. 具体的な手順
1.現状分析
- 既存デザインの棚卸し
- 使用頻度の確認
- 重複要素のチェック
2.基準の設定
- 分類方法の決定
- 命名規則の策定
- フォルダ構造の設計
3.整理と実装
- コンポーネントの作成
- プロパティの設定
- バリアントの整理
4. 保守性を高める設計テクニック
コンポーネントの階層構造を作ることはできても、それを長期的に保守することは別の課題です。時間とともにコンポーネントは増え、変更や改善が必要になります。
このセクションでは、将来の変更にも耐えられる設計テクニックを解説します。
4-1. コンポーネントの粒度設計
コンポーネントの粒度は、保守性に大きく影響します。以下のようなアプローチで適切な粒度を見極めましょう。
分割の判断基準
分割すべき場合：
- 複数箇所で再利用される
- 独立して機能する
- 単独でテスト可能
分割を避けるべき場合：
- 常にセットで使用される
- 文脈依存が強い
- 分割による複雑化が予想される
実践的な粒度の例
Button/
├── Base（共通スタイル）
│ └── プロパティで制御可能な範囲
└── Variants
├── Size（sm, md, lg）
└── Style（primary, secondary）
Card/
├── Base（カードの基本構造）
└── Content Slots
├── Header（任意）
├── Body（必須）
└── Footer（任意）4-2. 依存関係の管理
複雑な依存関係は保守性を低下させる大きな要因です。以下の原則で依存関係を管理しましょう。
依存の方向性
推奨：
Base → Common → Feature
（基本的な要素から特殊な要素へ）
避けるべき：
Feature → Base
（特殊な要素から基本的な要素への直接参照）依存関係の可視化
Component/
├── Dependencies.md（依存関係の文書化）
└── Button/
├── uses: Icon, Text
└── used-by: Card, Form4-3. 更新しやすい構造作り
バージョン管理の仕組み
Component/Button/
├── v1（安定版）
├── v2（開発版）
└── Changelog.md変更の影響範囲の制御
プロパティによる制御
├── 色やサイズ → プロパティで変更
├── レイアウト → Auto Layoutで対応
└── 表示/非表示 → ブール値で制御ドキュメントとの連携
各コンポーネントに必要な情報：
- 使用目的
- プロパティの説明
- 制約事項
- 更新履歴
まとめ：明日から実践できる階層設計のポイント
ここまで、Figmaにおけるコンポーネントの階層構造について詳しく見てきました。
最後に、実践的なポイントをチェックリスト形式でまとめます。
設計前の確認事項
✓ プロジェクトの規模は？
- 小規模：シンプルな2層構造
- 中規模：Base/Common/Feature の3層構造
- 大規模：アトミックデザインベースの多層構造
✓ チーム状況は？
- チームの規模
- デザイナーの人数
- 開発チームとの連携方法
実践のためのチェックリスト
基本設計
- コンポーネントの分類基準を決める
- 命名規則を統一する
- フォルダ構造を整理する
構造化
- 再利用性の高い要素を特定する
- 適切な粒度で分割する
- 依存関係を整理する
保守性
- 更新手順を決める
- プロパティの使用範囲を定める
- ドキュメントの形式を統一する
最後に
完璧な階層構造を最初から作ることは難しいですが、この記事で紹介した考え方をベースに、プロジェクトの状況に応じて柔軟にカスタマイズしていくことをお勧めします。
大切なのは、「チームで運用できる」「将来の変更に耐えられる」構造を目指すことです。
明日のデザイン作業から、ぜひこれらのポイントを意識してみてください。
