フレームワーク活用ガイド
押さえておきたい用語
- モジュラーデザイン: 独立した再利用可能なコンポーネントの組み合わせでUIを構築するアプローチ
- アトミックデザイン: Atoms（原子）→Molecules（分子）→Organisms（有機体）→Templates→Pagesの5階層でUIを構造化する手法
- コンポーネント: 特定の機能と見た目を持つUIの構成単位。ボタン、カード、フォームフィールドなど
- デザイントークン: 色・フォントサイズ・スペーシングなどの基本的なデザイン値を変数として管理する仕組み
1
UIの分解
既存画面を最小単位のコンポーネントに分解 → コンポーネントの分類
こんな悩みに効く#
- 「同じようなUIを毎回ゼロから作っていて非効率」
- 「画面ごとにデザインが微妙に異なり一貫性がない」
- 「デザインシステムを作りたいが何から始めるか分からない」
使い方#
既存UIを最小単位に分解する
現在のプロダクトの全画面をスクリーンショットで収集し、共通するUI要素を洗い出す。ボタン、フォームフィールド、カード、モーダルなど、繰り返し使われている要素をリストアップする。
コンポーネントを階層化する
洗い出した要素をAtoms（最小単位）→Molecules（Atomsの組み合わせ）→Organisms（Moleculesの組み合わせ）に分類する。各コンポーネントにprops（変更可能な属性）を定義し、1つのコンポーネントで複数のバリエーションに対応する。
デザイントークンを定義する
色、フォントサイズ、行間、スペーシング、角丸などの値を変数（トークン）として定義する。コンポーネント内で直接色コードを指定するのではなく、
--color-primaryのようなトークンを参照する設計にする。ライブラリとガバナンスを整備する
FigmaやStorybookにコンポーネントライブラリを構築し、使い方のドキュメントを添付する。新コンポーネントの追加には「既存で代替できないか」のレビューを必須にし、ライブラリの肥大化を防ぐ。
具体例#
SaaS — デザインシステムによる開発効率化
状況: 5つのプロダクトを持つSaaS企業で、各チームが独自にUIを設計。ボタンだけで12バリエーション、カードは8種類が存在し、実装の重複とUI不整合が常態化していた。
適用プロセス:
- 全プロダクトのUIをスクリーンショットで収集し、共通コンポーネントを86個特定
- 統合後のコンポーネントを32個に集約。ボタンは3バリエーション（Primary/Secondary/Ghost）に統一
- Figmaライブラリ＋Storybook＋npmパッケージで共通コンポーネントを配布
成果: 新画面の設計時間が平均40%短縮。UI実装のコードレビュー指摘が60%減少し、5プロダクト間のUI統一が実現した。
ECプラットフォーム — マルチブランド対応
状況: 同一プラットフォームで10ブランドのECサイトを運営。ブランドごとにデザインが異なるが、構造とコンポーネントは共通化したいという要件。
適用プロセス:
- 全ブランドで共通する構造（ヘッダー・商品カード・カート・決済フロー）をOrganismsとして定義
- ブランドごとの差異（色・フォント・角丸）はデザイントークンで切り替え可能に設計
- 1つのコンポーネントライブラリ＋10セットのデザイントークンで全ブランドに対応
成果: 新ブランド追加時のUI構築期間が3か月→2週間に短縮。コンポーネントのバグ修正が全ブランドに自動反映されるようになった。
社内システム — レガシーUIの段階的モダン化
状況: 10年間機能追加を重ねた社内業務システムで、画面ごとにUIスタイルが異なる。全面リニューアルの予算は確保できず、段階的な改善が求められていた。
適用プロセス:
- 利用頻度の高い画面20ページのUIを分解し、共通コンポーネントを28個特定
- 新デザインのコンポーネントライブラリを構築し、まず最も利用頻度の高い3画面から適用
- 四半期ごとに5画面ずつ新コンポーネントに置き換えるロードマップを策定
成果: 1年で主要20画面のUI統一が完了。ユーザーから「画面ごとに操作方法が違う」という苦情がゼロになり、操作研修の時間が半減した。
うまくいかないパターン#
| パターン | 問題点 | 対処法 |
|---|---|---|
| 最初から完璧を目指す | コンポーネント数が膨大になり着手できない | 利用頻度の高い10〜20個から始める |
| 粒度が細かすぎる | Atomsレベルまで分解すると管理コストが増大 | 実際に再利用されるレベルで分割する |
| ガバナンス不在 | チームが独自にコンポーネントを追加し肥大化する | 追加ルールと承認プロセスを設ける |
| デザインだけで完結 | Figmaにはあるがコードに反映されない | エンジニアと共同でStorybook等の実装を並行する |
まとめ#
モジュラーデザインは 「UIを部品の組み合わせで構築する」 考え方であり、デザインシステムの基盤になる。小さな部品（Atoms）から段階的に組み上げることで、一貫性・再利用性・保守性が確保される。デザイントークンでブランドごとの差異を吸収し、ガバナンスで品質を維持すれば、プロダクトの成長に伴うUI複雑化を防げる。