デザインシステムの管理
デザインシステムの管理はなぜ重要か？
簡単に言うと、デザインシステムは「料理の共有レシピ集」のようなものです。家族みんなが同じ料理を作るとき、それぞれが勝手に作り方を考えていたら、味もボリュームもバラバラになります。しかし、共有レシピ集があれば、誰が作っても同じ味・同じ仕上がりになります。さらに、「このレシピを使って、あとは好みでアレンジしてよい」というルールがあれば、一貫性を保ちながら柔軟に応用できます。デジタルプロダクトのデザインも同じで、ボタン、フォーム、ナビゲーション、カードといった再利用可能なUIコンポーネントを標準化し、カタログ化することで、デザイナーとエンジニアは毎回ゼロから作る必要がなくなり、スピードと品質を両立できます。
もう少し正確に言うと、デザインシステムは再利用可能なUIコンポーネント、デザイン原則、ガイドライン、コーディング規約を体系的にまとめた組織の共有資産です。UIデザイナーとフロントエンドエンジニアの連携の良さは、高速なアプリケーション開発にとって重要な要素です。また、フロントエンドエンジニアとバックエンドエンジニアの連携のしやすさも課題になります。デザインシステムを整備することで、デザインの反映を自動化し、一貫性のあるユーザー体験を提供しながら、開発サイクルを高速化できます。優れたデザインシステムには、動作するUIライブラリだけでなく、いつ・なぜそのコンポーネントを使うべきかを説明したドキュメント、アクセシビリティガイドライン、UXライティングのルールなども含まれます。これにより、異なるチームや新しいメンバーでも、統一されたデザイン品質を維持できます。
具体的には、Googleの「Material Design」、Appleの「Human Interface Guidelines」、Microsoftの「Fluent Design System」は、世界的に有名なデザインシステムです。これらは単なるUIコンポーネント集ではなく、デザイン哲学、原則、実装ガイドまで包括的に定義されています。国内では、SmartHRが「SmartHR UI」という独自のデザインシステムを公開しており、社内の複数プロダクト間で一貫したUI/UXを実現しています。freeeも独自のデザインシステムを構築し、会計、人事、申告といった異なるプロダクトラインで統一されたデザインを提供しています。これらの企業は、デザインシステムを一度作って終わりにするのではなく、継続的にメンテナンスし、プロダクトの進化に合わせて更新し続けることで、長期的な開発効率と品質を保っています。
デザインとコードの連携による効率化
デザインシステムの真価は、デザイナーとエンジニアの協働を円滑にすることにあります。従来、デザイナーがデザインツールで作成したモックアップをエンジニアが目視で確認しながらコードを書くというプロセスには、多くの解釈のズレと手戻りが発生していました。デザインシステムはこの課題を解決します。
デザイントークンとして色やフォントサイズを管理することが効果的です。たとえば、プライマリカラーを「#1976D2」というハードコードされた値ではなく、「color-primary」という変数として定義します。この変数をデザインツール（Figma）とコード（CSS、React）の両方で共有することで、デザインの変更がコードに自動的に反映されます。色だけでなく、フォントサイズ、行間、余白、角丸、影などのスタイル属性もすべてトークン化します。これにより、「デザインでは角丸が8pxなのに、実装では10pxになっている」といった細かな不一致を防ぎます。
また、オンラインコラボレーションに対応しているUIデザインツールをプロダクト組織で共通して利用することが重要です。Figmaなどのツールを使えば、デザイナーが作成したコンポーネントとエンジニアが実装するコンポーネントが一致しているかを視覚的に確認できます。Figmaの開発者モード（Dev Mode）を使えば、エンジニアはデザインからCSSやReactコードを取得でき、実装が効率化されます。デザインシステムのコンポーネントをFigmaのライブラリとして共有することで、デザイナーは常に最新のコンポーネントを使ってデザインでき、デザインと実装の乖離を最小化できます。
スタイルポリシーと組織全体のサポート
デザインシステムを単なるコンポーネント集に終わらせず、組織全体の共通言語とするには、包括的なドキュメントと全社的なサポート体制が不可欠です。
デザインシステムのコンポーネント、スタイル、パターンについての詳細なドキュメントを共通の情報設計思想に基づいて作成します。各コンポーネントの目的、使用場面、使用上の注意、コード例、プロパティ一覧、アクセシビリティ配慮事項、UXライティングガイドラインを明記します。Storybookを使えば、動作するコンポーネントを見ながら、プロパティを変更して挙動を確認できます。また、プラットフォーム固有のガイドラインも必要で、Web、iOS、Androidそれぞれの技術的制約や推奨パターンを文書化します。ドキュメントと実装が乖離してしまうことが最大のリスクなので、コードとドキュメントを同じリポジトリで管理し、プルリクエストのレビュープロセスで両方が更新されていることを確認します。
組織全体のサポートも重要です。デザイナーや開発者のみならず、プロダクトマネージャー、マーケティング担当者など、すべてのステークホルダーがデザインシステムの価値を理解し、活用できるよう支援します。新しいメンバーがチームに参加した際、オンボーディングプログラムの中でデザインシステムの研修を必ず組み込みます。また、定期的にデザインシステムのレビュー会議を開催し、各コンポーネントの利用頻度、課題、改善要望を集め、継続的に棚卸して陳腐化することなく改善できているかを確認します。デザインシステムの改善は、専任チームが責任を持つか、各プロダクトチームから持ち回りでメンテナンス担当を割り当てることで、継続性を保ちます。
カテゴリ内クライテリアの解説
DESIGN-4-1: デザインシステムの整備されたUIライブラリを用いて、機能の仮説検証が半数以上できている
目的: 再利用可能なUIコンポーネントにより、開発スピードと品質の両立が目的です。新機能を開発する際、既存のコンポーネントを組み合わせるだけで素早くプロトタイプを作成し、仮説検証できる状態を目指します。
実装のポイント: UIライブラリには、ボタン、フォーム、テーブル、モーダル、ナビゲーション、カード、アラートなど、プロダクトで頻繁に使用されるコンポーネントを網羅的に含めます。React、Vue、Angularなどのフレームワークに対応したコンポーネントライブラリを構築し、npm パッケージとして配布することで、各チームが簡単に利用できるようにします。新機能開発の際、まず既存コンポーネントで実現できないかを検討し、既存コンポーネントの組み合わせで対応できる場合はそれを優先します。半数以上の機能がデザインシステムのコンポーネントで実現できている状態を目標とし、その割合を定期的に測定します。これにより、デザインシステムの実用性と網羅性を評価できます。
注意点: デザインシステムのコンポーネントだけに固執すると、革新的なUIの実験が阻害されるリスクがあります。新しいユーザー体験を試す際には、デザインシステムの枠を超えた挑戦も必要です。ただし、その実験が成功した場合は、デザインシステムに新しいコンポーネントとして追加し、他のチームでも活用できるようにします。また、コンポーネントの粒度が細かすぎると、組み合わせが複雑になり、かえって使いにくくなることがあります。適切な抽象度を保つことが重要です。
DESIGN-4-2: 利用頻度の高いコンポーネント等をまとめたデザインシステムを構築し、継続的に棚卸するなど陳腐化することなく改善できているか
目的: デザインシステムは一度作って終わりではなく、継続的にメンテナンスすることが目的です。プロダクトの進化、デザイントレンドの変化、技術スタックの更新に合わせて、デザインシステムも進化させる必要があります。
実装のポイント: 四半期ごと、または半年ごとにデザインシステムのレビュー会議を開催し、各コンポーネントの利用頻度、課題、改善要望を集めます。利用頻度の低いコンポーネントは削除または統合を検討し、逆に頻繁に独自実装されているパターンは新しいコンポーネントとして追加します。また、アクセシビリティ基準（WCAG 2.2など）の変更、ブラウザの新機能、パフォーマンス最適化の機会なども定期的に評価し、デザインシステムに反映します。バージョン管理を適切に行い、破壊的変更を導入する際は、移行ガイドと十分な移行期間を提供します。デザインシステムの改善は、専任チームが責任を持つか、各プロダクトチームから持ち回りでメンテナンス担当を割り当てることで、継続性を保ちます。
注意点: デザインシステムのメンテナンスは、新機能開発に比べて優先度が下がりがちです。しかし、メンテナンスを怠ると、デザインシステムが実際のプロダクトと乖離し、誰も使わなくなってしまいます。経営層やプロダクトリーダーが、デザインシステムのメンテナンスを重要な投資として認識し、リソースを確保することが不可欠です。また、あまりに頻繁に破壊的変更を加えると、利用側のチームが追従できなくなるため、変更の頻度とインパクトのバランスを取る必要があります。
DESIGN-4-3: デザインシステムの目的と具体的な設計情報を含めたドキュメントと、動作するUIライブラリの両方が整備されているか
目的: ドキュメントと実装の両方を整備することで、デザイナーとエンジニアの協働が円滑になります。ドキュメントだけでは実装時に解釈のズレが生じ、実装だけでは使い方や意図が伝わりません。
実装のポイント: デザインシステムのドキュメントサイトを構築し、各コンポーネントの目的、使用場面、使用上の注意、コード例、プロパティ一覧、アクセシビリティ配慮事項、UXライティングガイドラインを明記します。Storybookは、Reactなどのコンポーネントライブラリのドキュメント作成に最適なツールで、動作するコンポーネントを見ながら、プロパティを変更して挙動を確認できます。また、Figmaなどのデザインツールとコードが連携していることも重要で、デザイナーがFigmaで配置したコンポーネントと、エンジニアが実装するコンポーネントが一致していることで、デザインと実装のギャップを最小化できます。ドキュメントには、デザインシステムの哲学や原則も含め、「なぜこのように設計されているか」を理解できるようにします。
注意点: ドキュメントと実装が乖離してしまうことが最大のリスクです。コードが更新されたのにドキュメントが古いままだと、利用者が混乱します。理想的には、コードとドキュメントを同じリポジトリで管理し、プルリクエストのレビュープロセスで両方が更新されていることを確認します。また、ドキュメントが詳細すぎると、メンテナンスコストが高くなり、更新が追いつかなくなります。必要最小限の情報に絞り、サンプルコードや図を活用して、直感的に理解できるドキュメントを心がけます。
DESIGN-4-4: オンラインコラボレーションに対応しているUIデザインツールを、プロダクト組織で共通して利用しているか
目的: Figmaなどのコラボレーションツールにより、リモート環境でも効率的なデザインワークが可能になります。デザイナー同士、デザイナーとエンジニア、デザイナーとプロダクトマネージャーが、リアルタイムで同じデザインを見ながら議論できることが目的です。
実装のポイント: Figmaは、現在最も広く使われているオンラインコラボレーション対応のUIデザインツールです。複数人が同時に同じファイルを編集でき、コメント機能でフィードバックを直接デザインに書き込めます。デザインシステムのコンポーネントをFigmaのライブラリとして共有することで、デザイナーは常に最新のコンポーネントを使ってデザインできます。また、開発者モード（Dev Mode）を使えば、エンジニアはデザインからCSSやReactコードを取得でき、実装が効率化されます。組織全体でFigmaを標準ツールとして採用し、すべてのデザイン資産をFigmaで管理することで、情報の一元化と検索性の向上が実現できます。Adobe XD、Sketchなども選択肢ですが、組織全体で統一することが重要です。
注意点: ツールを導入しただけでは、コラボレーションは生まれません。デザインレビュー会議をオンラインで実施し、Figmaを画面共有しながら議論する習慣を作る必要があります。また、Figmaのファイル構成が無秩序だと、必要なデザインを見つけられなくなります。ファイルの命名規則、フォルダ構成、アクセス権限の管理ルールを明確にし、定期的に整理することが重要です。さらに、デザインツールの学習コストも考慮し、新しいメンバーに対するトレーニングを提供することで、組織全体のデザインリテラシーを高めます。
DESIGN-4-5: プロダクト特有のUIコンセプトが一貫した情報設計に基づいており、ドキュメント化されているか
目的: 一貫したデザイン原則により、統一感のあるユーザー体験を提供することが目的です。個々のコンポーネントだけでなく、プロダクト全体を貫く思想やコンセプトを明文化します。
実装のポイント: デザイン原則（Design Principles）を3〜5個程度定義し、ドキュメント化します。たとえば、「シンプルであること」「ユーザーに選択肢を与えること」「フィードバックを即座に提供すること」といった抽象的な原則を、具体的な実装例とともに説明します。また、情報アーキテクチャ（IA）として、ナビゲーション構造、情報の階層、ラベリングの一貫性を設計します。たとえば、「削除」という操作を表すラベルは、プロダクト全体で「削除」で統一し、「消去」「除去」「取り消し」といった類義語を混在させないようにします。カラーパレット、タイポグラフィ、スペーシング、アイコンスタイルなどの視覚的なガイドラインも、デザインコンセプトの一部として明文化します。
注意点: デザイン原則が抽象的すぎると、実際の意思決定の場で活用されません。各原則には、「この原則に従った良い例」と「この原則に反する悪い例」を具体的に示すことで、理解と実践を促進します。また、デザイン原則とビジネス目標が矛盾する場合もあります。たとえば、「シンプルであること」と「多機能であること」はトレードオフの関係にあります。こうした矛盾をどうバランスさせるかも、原則の中で言及しておくと良いでしょう。
DESIGN-4-6: デザインシステムにUXライティングについてのガイドラインが存在しない（アンチパターン）
目的: このアンチパターンは、UXライティングのガイドラインがないと、文言の統一性が失われ、ユーザー体験が損なわれることを指摘しています。視覚的なデザインだけでなく、言葉のデザインも重要です。
実装のポイント: UXライティングガイドラインには、トーン＆マナー（フォーマルかカジュアルか、敬語か常体か）、専門用語の使用ルール、エラーメッセージの書き方、ボタンのラベリング規則、文字数制限などを含めます。たとえば、「ボタンのラベルは動詞から始め、具体的な行動を示す（例：保存する、送信する）」「エラーメッセージは問題を指摘するだけでなく、解決策を提示する（例：パスワードは8文字以上で入力してください）」といったルールを定めます。また、多言語対応の場合、翻訳のガイドラインも重要です。単純な直訳ではなく、文化的な配慮を含めた翻訳方針を明文化します。Notionやconfluence、またはデザインシステムのドキュメントサイトにUXライティングセクションを設け、誰でも参照できるようにします。
注意点: UXライティングガイドラインを作成しても、実際のプロダクト開発で遵守されなければ意味がありません。デザインレビューやコードレビューのプロセスで、文言がガイドラインに準拠しているかをチェックする仕組みを組み込みます。また、ガイドラインが厳格すぎると、創造性が阻害される可能性もあります。基本ルールは守りつつ、特殊なケースでは柔軟に対応できる余地も残しておくことが重要です。
DESIGN-4-7: デザインシステムが存在するのにもかかわらず、関係者のアドホックな意思決定によってデザインの一貫性が損なわれている（アンチパターン）
目的: このアンチパターンは、デザインシステムのガバナンスが不十分だと、せっかくのシステムが形骸化することを指摘しています。ルールがあっても守られなければ意味がありません。
実装のポイント: デザインシステムのガバナンス体制を明確にします。デザインシステムの変更提案プロセス、承認フロー、例外対応のルールを定めます。たとえば、「デザインシステムに含まれないコンポーネントを使用する場合は、デザインレビュー会議で承認を得る」「新しいコンポーネントの追加提案は、GitHubのIssueで起票し、デザインシステムチームが評価する」といったプロセスを確立します。また、自動化ツールを活用し、デザインシステムからの逸脱を検知します。たとえば、Storybookのビジュアルリグレッションテスト（Chromatic、Percy）を使えば、意図しないデザイン変更を自動検出できます。ESLintやStylelintのカスタムルールで、デザインシステム外のスタイルを使用した際に警告を出すことも効果的です。
注意点: ガバナンスが厳格すぎると、開発スピードが低下し、現場の反発を招きます。ガバナンスの目的は「一貫性の維持」であり、「統制」ではありません。現場の創意工夫を尊重しつつ、その成果をデザインシステムに還元する文化を作ることが重要です。また、経営層やプロダクトリーダーがデザインシステムの重要性を理解し、率先して遵守する姿勢を示すことで、組織全体の意識が高まります。
DESIGN-4-8: デザインシステムにマイクロインタラクション（ユーザーの行動に応じた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素）が組み込まれていない（アンチパターン）
目的: このアンチパターンは、マイクロインタラクションがユーザーエンゲージメントと満足度を高める重要な要素であることを指摘しています。静的なUIだけでは、洗練された体験は提供できません。
実装のポイント: マイクロインタラクションには、ボタンのホバーエフェクト、クリック時のリップルアニメーション、ローディング中のスピナー、フォーム送信成功時のチェックマークアニメーション、ページ遷移時のトランジションなどが含まれます。これらをデザインシステムのコンポーネントに組み込み、一貫した動きを提供します。アニメーションの速度（デュレーション）、イージング関数（加速・減速カーブ）も標準化し、すべてのアニメーションが同じリズムで動くようにします。たとえば、「すべてのトランジションは200msのease-out」といったルールを定めます。また、アクセシビリティの観点から、ユーザーがアニメーションを無効化できるオプション（prefers-reduced-motion）にも対応します。Framer MotionやReact Springなどのアニメーションライブラリを活用することで、実装が容易になります。
注意点: マイクロインタラクションは、適度に使えば体験を豊かにしますが、過剰になるとパフォーマンスを低下させ、ユーザーをイライラさせます。アニメーションの必要性を吟味し、ユーザーの目的達成を助けるものだけを採用します。また、モバイルデバイスやローエンドのPCでもスムーズに動作するか、パフォーマンステストを実施することが重要です。さらに、動きの激しいアニメーションが苦手なユーザー（乗り物酔いしやすい方や光過敏の方など）への配慮として、過度な動きを避け、必要に応じて無効化できるようにします。
参考資料・ツール
参考書籍・記事
『Design Systems』（Alla Kholmatova著）は、デザインシステムの構築と運用の包括的なガイドです。なぜデザインシステムが必要か、どのように構築し、維持するかが詳述されています。
『Atomic Design』（Brad Frost著）は、UIを原子（Atoms）、分子（Molecules）、有機体（Organisms）、テンプレート、ページという階層で設計する手法を提唱した名著です。デザインシステムのコンポーネント設計の基本的な考え方を学べます。
SmartHR Design System: SmartHRが公開しているデザインシステムです。コンポーネント、デザインパターン、アクセシビリティガイドラインなどが体系的にまとめられています。(https://smarthr.design/)
GitHub: kufu/smarthr-ui: SmartHR UIのReactコンポーネントライブラリのソースコードがOSSとして公開されています。(https://github.com/kufu/smarthr-ui)
関連するフレームワーク
Atomic Designは、UIコンポーネントを階層的に設計するフレームワークです。最小単位の原子（ボタン、入力フィールド）から、分子（検索フォーム）、有機体（ヘッダー）、テンプレート、ページへと組み立てていく考え方です。
Design Tokensは、色、タイポグラフィ、スペーシング、シャドウなどの視覚的な属性を変数として定義し、プラットフォーム間で共有する手法です。JSONやYAMLで定義したトークンから、CSS、iOS、Android向けのスタイルを自動生成できます。
Component-Driven Developmentは、UIを独立したコンポーネント単位で開発する手法です。Storybookを使ってコンポーネントを分離環境で開発・テストすることで、品質と再利用性を高めます。
推奨ツール
Storybookは、UIコンポーネントのドキュメント作成と開発環境を提供するツールです。React、Vue、Angular、Svelteなど主要なフレームワークに対応し、コンポーネントを分離環境でテスト・ドキュメント化できます。
Figmaは、オンラインコラボレーション対応のUIデザインツールで、デザインシステムのコンポーネントライブラリを管理し、チーム全体で共有できます。開発者モードを使えば、エンジニアがデザインから実装情報を取得できます。
Chromatic、Percyは、ビジュアルリグレッションテストツールで、デザインシステムのコンポーネントに意図しない視覚的な変更が加えられた際に自動検知します。CI/CDパイプラインに組み込むことで、デザイン品質を自動的に保証できます。
Style Dictionaryは、Design Tokensを管理するツールで、一つのトークン定義ファイルから、CSS、SCSS、iOS、Android、React Native向けのスタイルファイルを自動生成できます。