デザインシステム

デザインシステムとは、一貫したUIを効率よく構築するためのコンポーネント・デザイントークン・ガイドライン・ツールの集合体である。プロダクトが成長し複数のチームが開発に関わると、デザインの不統一や重複した実装が生まれやすくなる。デザインシステムはこの問題を構造的に解決し、デザイナーとエンジニアが共通の言語でコミュニケーションできる基盤を提供する。

Atomic Designはデザインシステムのコンポーネント設計方法論の一つで、UI要素を「Atoms（ボタン・入力欄等の最小単位）」「Molecules（複数のAtomの組み合わせ）」「Organisms（Moleculeを組み合わせたセクション）」「Templates」「Pages」の5段階に分類する。この階層構造により、コンポーネントの再利用範囲と依存関係が明確になり、変更の影響範囲を制御しやすくなる。

Storybookはコンポーネントを独立した環境でインタラクティブに開発・文書化できるツールであり、デザインシステムの中核となる。各コンポーネントのStory（状態・バリエーション）を定義することで、実際のアプリケーションに組み込まずに視覚的な確認が可能になる。また、Storybookはデザイナーへのレビュー依頼や、アクセシビリティチェック・ビジュアルリグレッションテストの基盤としても活用される。

コードレビューで着目するポイント

デザイントークン（色・スペーシング・タイポグラフィ）がコードで一元管理され、ハードコードされた値が散在していないか
Storybookのデフォルト状態・エラー状態・ローディング状態など、コンポーネントの各バリエーションがStoryとして定義されているか
コンポーネントの粒度が適切か（一つのコンポーネントが過度に多くの責務を持っていないか）
デザインシステムのバージョニングが管理されており、破壊的変更（APIの変更等）がセマンティックバージョニングで明示されているか
FigmaのデザインとコードのコンポーネントのProps APIが対応しているか（デザインと実装の乖離がないか）
デザインシステムのコンポーネントが実際のプロダクトで使われており、デザインシステムとプロダクトが乖離していないか

典型的なアンチパターン

デザイントークンの重複定義: #1a73e8 という青色が primary-blue という変数と button-color という変数の2箇所で定義されていると、将来の変更時に片方だけ更新して不整合が生まれる。色・スペーシングの実値は一箇所のみで定義し、他は参照する形にすべきである。

デザインシステムの「ゴースト化」: 一度構築したデザインシステムを更新せず放置し、プロダクト側が独自のコンポーネントを増やし続けることで、デザインシステムが実態を反映しなくなる状態。デザインシステムの更新プロセスと所有者を明確にしないと起きやすい問題である。

全コンポーネントのAtomic化強制: Atomic Designの概念を厳格に適用し、本来プロダクト固有のページコンテキストで成立する要素まで再利用前提のAtomに分解しようとすると、過度に汎用化されたAPIを持つ使いにくいコンポーネントが生まれる。実用上のトレードオフを判断して設計する必要がある。

参考リソース

ツール: Storybook - コンポーネント開発・文書化・ビジュアルテストのデファクトツール
書籍: 「Atomic Design」（Brad Frost） - デザインシステムのコンポーネント設計方法論の原典（無料でオンライン公開）
事例: Radix UI - アクセシビリティに優れたヘッドレスUIコンポーネントライブラリ
事例: shadcn/ui - Radix UIをベースにしたカスタマイズ性の高いデザインシステムの実装例
ツール: Style Dictionary - デザイントークンを複数プラットフォーム向けに変換・配布するツール