デザインシステム

英語名 Design System
読み方 デザイン システム
難易度
所要時間 数週間〜数ヶ月(構築)
提唱者 Google Material Design、Salesforce Lightningなど各社の実践から発展
目次

ひとことで言うと
#

色・フォント・コンポーネント・インタラクション・文言のルールを一箇所にまとめた「UIの共通言語」。デザイナーとエンジニアが同じルールブックを見ることで、一貫性のあるプロダクトを素早く作れるようになる。

押さえておきたい用語
#

押さえておきたい用語
デザイントークン(Design Token)
色・フォント・余白などのデザイン値を変数名で管理する仕組みcolor-primaryのように名前で指定し、後から一括変更が可能。
コンポーネント
ボタン、入力フィールド、モーダルなど再利用可能なUIの部品。バリエーション(Primary/Secondary/Disabled等)を持つ。
Storybook(ストーリーブック)
コンポーネントをブラウザ上でカタログ形式に表示し、動作確認できる開発ツール。
コントリビューションガイド
デザインシステムに新しいコンポーネントを追加するためのルールとプロセスを定めた文書。
ガバナンス
デザインシステムの更新管理・品質維持・意思決定の仕組み。専任チームまたは担当者が必要。

デザインシステムの全体像
#

トークン→コンポーネント→ドキュメント+ガバナンスの3層構造
デザイントークンカラー・タイポグラフィ・スペーシング・角丸・影意味のある名前で管理し、デザインとコードの共通言語にするコンポーネントライブラリボタン・入力・カード・モーダル・ナビゲーションFigma + コードライブラリ(React/Vue等)を同期ドキュメント+ガバナンス使用例・Do/Don't・コード例・バージョニングコントリビューションガイドと専任チーム小さく始めて育てる
デザインシステム構築の進め方フロー
1
現状棚卸し
既存UIの色・フォント・部品を洗い出す
2
トークン定義
色・フォント・余白を変数化
3
コンポーネント構築
10〜15個の最頻出部品から開始
4
ドキュメント+運用
ガイド公開と継続的な更新

こんな悩みに効く
#

  • 画面ごとにデザインがバラバラで、同じアプリに見えない
  • デザイナーが増えるたびにUIの不一致が増える
  • 同じようなコンポーネントを何度もゼロから作っている

基本の使い方
#

デザイントークンを定義する

デザインシステムの最小単位=デザイントークンを決める。

  • カラー: プライマリ、セカンダリ、背景、テキスト、エラー、成功などの色パレット
  • タイポグラフィ: フォントファミリー、サイズスケール(H1〜body〜caption)、行間
  • スペーシング: 余白のスケール(4px, 8px, 16px, 24px, 32px, 48px……)
  • 角丸・影・ボーダー: UIの質感を決める基本値

トークンに意味のある名前をつける(color-primary spacing-md など)。#3B82F616px ではなくトークン名で指定することで、後から一括変更が可能になる。

コンポーネントライブラリを構築する

デザイントークンを使って再利用可能なUIコンポーネントを作る。

  • 基本コンポーネント: ボタン、入力フィールド、チェックボックス、ドロップダウン
  • パターンコンポーネント: カード、モーダル、テーブル、ナビゲーション
  • 各コンポーネントにバリエーションを定義(例: ボタン → Primary / Secondary / Ghost / Disabled)
  • 使用ガイドライン: いつ、どの場面で、どのバリエーションを使うか

デザインファイル(Figma)とコードライブラリ(React、Vue等)を同期させるのが理想。

ドキュメントとガバナンスを整備する

デザインシステムは使われなければ意味がない

  • ドキュメントサイト: 各コンポーネントの使用例、Do/Don’t、コード例を掲載
  • コントリビューションガイド: 新コンポーネントの追加ルール
  • バージョニング: 変更履歴を管理し、破壊的変更は事前に通知
  • オーナーシップ: デザインシステムの専任チーム(最低1名)を置く

小さく始めて育てるのが鉄則。最初から完璧なシステムを目指さない。

具体例
#

例1:SaaSプロダクトが4週間でデザインシステムを立ち上げ開発速度を40%改善する

Phase 1(2週間): 現状の棚卸し

  • 全画面のスクリーンショットを並べて、使われている色・フォント・コンポーネントを洗い出す
  • 発見: ボタンが7種類、グレーが12色、フォントサイズが15パターン。統一感ゼロ

Phase 2(2週間): トークン+基本コンポーネント定義

  • カラー: プライマリ(Blue-600)、セカンダリ(Gray-700)、エラー(Red-500)+ 各色の100〜900スケール
  • フォント: 見出しInter Bold / 本文Inter Regular / サイズ5段階
  • スペーシング: 4px刻みの8段階
  • 基本コンポーネント: ボタン3種、入力4種、カード、モーダルをFigma+React

Phase 3(1ヶ月): 展開+ドキュメント

  • Storybookでコンポーネントカタログを公開
  • 新規画面からデザインシステムを適用。既存画面は段階的に移行
  • 週1回の「デザインシステムオフィスアワー」で質問対応

効果: 新画面のデザイン〜実装が40%短縮。 「このボタンどっちを使う?」の議論がゼロに。エンジニアのコメント「コンポーネントを組み合わせるだけで画面が作れる」。

例2:複数プロダクトを持つ企業がデザインシステムでブランド統一を達成する

状況: 3つのSaaSプロダクトを持つ企業。各プロダクトが独自のUIルールで開発されており、同じ会社の製品に見えない。顧客から「操作体系がバラバラで使いにくい」との声。

取り組み:

  • 3プロダクト共通のデザイントークンを定義(カラー5色、フォント2種、スペーシング8段階)
  • 共通コンポーネント25個を作成。各プロダクト固有のコンポーネントは別レイヤーで管理
  • 全プロダクトのデザイナー8名+エンジニア15名がStorybookを共有

結果:

  • プロダクト間のUI差異: 87箇所→12箇所(86%削減
  • 新機能開発速度: 平均2.3倍に向上(共通コンポーネント再利用のため)
  • 顧客満足度調査で「製品間の一貫性」スコアが3.1→4.4に改善(5点満点)
  • デザイナーの異動時のキャッチアップ期間が2週間→3日に短縮
例3:スタートアップがデザインシステムを最小構成で始め6ヶ月で成長させる

状況: デザイナー1名、エンジニア4名のスタートアップ。デザインシステムの必要性は感じているが、専任リソースは割けない。

最小構成でのスタート(Week 1-2):

  • デザイントークン: カラー4色、フォントサイズ4段階、スペーシング4段階
  • コンポーネント: ボタン2種、入力フィールド2種、カード1種(計5個)
  • ドキュメント: NotionにDo/Don’tを記載(1コンポーネント1ページ)

成長過程(6ヶ月):

  • Month 1: +3コンポーネント(モーダル、ドロップダウン、テーブル)
  • Month 3: Storybookを導入しコード側も整備。コンポーネント計15個
  • Month 6: デザイントークンをFigma Variables化。コンポーネント計28個

結果: 6ヶ月後にはデザイン〜実装のサイクルが2.5倍速に。 エンジニアの声「最初の5個だけでも、あるとないでは全然違った」。小さく始めたからこそ、プロダクトの成長に合わせて自然にシステムが育った。

やりがちな失敗パターン
#

  1. 最初から完璧を目指す — 100コンポーネントを定義してからローンチしようとして、いつまでも完成しない。まず10〜15個の最頻出コンポーネントから始める
  2. デザインだけ or コードだけ — Figmaにだけ定義してコードと乖離する(逆も然り)。デザインとコードの同期が命
  3. ルールを作って押し付ける — 開発者やデザイナーが「使いたい」と思えるDX(Developer Experience)が大事。強制ではなく「使うほうが楽」な状態を作る
  4. 専任担当者を置かない — 全員の「片手間」で運用すると、更新が止まり陳腐化する。最低1名のオーナーを明確にし、更新とサポートの責任を持たせる

まとめ
#

デザインシステムは「UIの共通言語」。トークン→コンポーネント→ドキュメントの3層構造で、一貫性と効率を両立する。小さく始めて育てていくことが成功の鍵。プロダクトが成長してメンバーが増えるほど、デザインシステムの投資対効果は大きくなる。