「デザインシステムを作ってほしい」。プロダクトマネージャーからその言葉を聞いたとき、正直なところ身が引き締まる思いだった。当時、私が所属していたスタートアップはシリーズBの調達を終えたばかりで、エンジニアチームは半年で3倍に膨れ上がっていた。デザイナーは私を含めて3人。プロダクトのUIは、良く言えば「多様」、悪く言えば「カオス」だった。
同じ「確認ダイアログ」なのに画面によってボタンの色が違う。フォントサイズのバリエーションは数え切れない。新しいメンバーが入るたびに「このボタン、どのスタイルが正解ですか？」という質問がSlackに流れる。デザインシステムの必要性は、もはや明らかだった。
なぜデザインシステムが必要だったのか
最大の理由はチームのスケーリングだった。3人のデザイナーが暗黙知で共有していたルールは、チームが拡大するにつれて機能しなくなっていた。口頭で「あのページのあのボタンを参考にして」と伝えるやり方では、もう限界だった。
さらに、エンジニアとのコミュニケーションコストも膨大になっていた。デザインレビューのたびに「ここのpaddingは何px？」「この色のカラーコードは？」といった質問が飛び交い、本質的な議論に時間を割けなくなっていた。デザインシステムは、こうした摩擦をなくすための共通言語になるはずだった。
Phase 1 — 監査と棚卸し
最初にやったことは、既存UIの全スクリーンショットを撮り、使われているコンポーネントを徹底的に洗い出すことだった。ボタン、入力フィールド、カード、モーダル、ナビゲーション — すべてをFigma上に並べた。
結果は衝撃的だった。ボタンだけで23種類のバリエーションが存在していた。色、サイズ、角丸、フォントウェイト — 微妙に異なるボタンが画面ごとに散在していた。この「一貫性のなさの可視化」こそが、チーム全体にデザインシステムの必要性を理解してもらう最も効果的な方法だった。
- ボタン: 23バリエーション → 目標: 5パターンに統合
- カラーパレット: 47色 → 目標: 12色のセマンティックカラー
- フォントサイズ: 18種類 → 目標: 8段階のタイプスケール
- スペーシング: 不統一 → 目標: 4pxグリッドベース
Phase 2 — トークンから始める
コンポーネントをいきなり作り始めたい衝動を抑え、まずDesign Tokensから着手した。色、タイポグラフィ、スペーシング、シャドウ、ボーダー — これらの最小単位を定義することが、システム全体の土台になる。
色については、プリミティブカラー（Gray-100, Blue-500など）とセマンティックカラー（text-primary, bg-danger など）の二層構造を採用した。こうすることで、将来的にダークモード対応やブランドカラーの変更にも柔軟に対応できる。
タイポグラフィは、Major Third（1.25倍）のスケール比を基準に8段階のサイズを定義した。行間、字間もすべてトークン化し、「見出しっぽいサイズ」ではなく「Heading-L」という明確な名前で呼べるようにした。
「完璧なシステムを目指すな。使われるシステムを目指せ。」
これは当時のテックリードが言った言葉で、私のデザインシステム構築の哲学になった。完璧な命名規則や網羅的なドキュメントを追い求めるより、まず開発チームが日常的に使えるものを作ることが最優先だった。
Phase 3 — コンポーネント化
トークンが固まった後、いよいよコンポーネントの設計に入った。基本的な考え方はAtomic Designに沿ったが、厳格にAtoms/Molecules/Organismsの分類に縛られることはしなかった。
理由はシンプルで、「このコンポーネントはAtomかMoleculeか」という議論に時間を費やすより、実際にプロダクトで使われるパターンを素早く整備する方が価値があったからだ。最終的には「基本コンポーネント」「複合コンポーネント」「パターン」という3層構造に落ち着いた。
各コンポーネントには必ず以下を定義した:
- バリアント（サイズ、カラー、状態）
- インタラクション仕様（ホバー、フォーカス、ディセーブル）
- アクセシビリティ要件（コントラスト比、キーボード操作）
- 使用ガイドライン（Do / Don't）
運用のリアル
デザインシステムは「作って終わり」ではない。むしろ、運用フェーズこそが本番だ。私たちが特に注力したのは以下の3点だった。
ドキュメントは、Storybookを活用してコンポーネントの実装とドキュメントを一体化させた。Figmaのコンポーネントとコードの同期を維持するために、週1回のデザイン×エンジニアリングの同期ミーティングも設けた。
オンボーディングでは、新メンバーが入社した初日にデザインシステムのウォークスルーセッションを実施した。30分のセッションだが、これだけで「どこを見ればいいか」が明確になり、立ち上がりが格段に速くなった。
更新サイクルは、2週間のスプリント内に「デザインシステムの改善」枠を必ず確保した。プロダクト開発の中で見つかった不足や改善点を、定期的にシステムにフィードバックする仕組みだ。
振り返りと学び
1年間の運用を経て、最も大きな学びは「最初から完璧を目指さない」ということだった。デザインシステムは生き物だ。プロダクトが進化すれば、システムも進化しなければならない。
もうひとつ重要なのは、使う人と一緒に育てるということ。デザイナーだけでなく、エンジニア、PM、時にはQAチームからのフィードバックがシステムを強くする。「これ使いにくい」「このパターンが欲しい」という声こそが、デザインシステムの最良の養分だ。
デザインシステムの構築は、華やかなビジュアルデザインとは異なる地味な作業の連続だ。しかし、チーム全体のデザイン品質を底上げし、コミュニケーションコストを劇的に削減するその効果は、計り知れない。もしあなたがデザインシステムの構築を任されたら — まず完璧を手放すことから始めてほしい。