デザインシステム：失敗する理由と機能するものの作り方

あるサイズに達したチームは、いずれ同じことを言い出す。「デザインシステムが必要だ」と。そして大半のチームは誰も使わないものを6ヶ月かけて作り上げ、1年後には最初と同じ非一貫性に逆戻りしている。

問題はコンポーネントではない。デザインシステムをプロダクトではなくプロジェクトとして扱っていることが問題だ。プロジェクトには終わりがある。プロダクトは進化する。進化をやめたデザインシステムは、ローンチした日から死に始める。

デザインシステムとは何か

デザインシステムはコンポーネントライブラリではない。コンポーネントライブラリは再利用可能なUIパーツのフォルダだ。デザインシステムは、プロダクトをどのように設計・構築するかを規定する、標準・ドキュメント・ツールの完全なセットだ。

それには以下が含まれる。

• Design tokens。 その他すべてが参照するアトミックな値（色、スペーシング、タイポグラフィ、シャドウ）。
• コンポーネント。 トークンから構築された再利用可能なUI要素。
• パターン。 繰り返し発生するデザイン上の問題（フォーム、ナビゲーション、エラー状態）への文書化されたソリューション。
• ガイドライン。 各パーツをいつ、どのように使うかのルール。
• ガバナンス。 システムの所有者、変更の提案方法、意思決定の方法。

これらのどれかが欠けると不完全なシステムになる。不完全なシステムは不完全な採用を生む。不完全な採用は、解決しようとしていたのと同じ非一貫性を生む。

デザインシステムが失敗する理由

失敗1：孤立した構築。 小さなチームが3ヶ月間姿を消し、美しいシステムを作り上げ、何も関与しなかった組織に発表する。そのシステムは構築者の前提を反映しているが、ユーザーの現実ではない。最初は礼儀的に採用されるが、やがて静かに捨てられる。

失敗2：早すぎる硬直化。 あらゆるシナリオに厳格なルールを持ってシステムがローンチされる。システムが想定していなかったケースに遭遇したデザイナーやエンジニアには2つの選択肢がある。システムと戦うか、回避するかだ。ほとんどは回避を選ぶ。システムは誰も参照しないリファレンスになる。

失敗3：専任の所有者不在。 システムはスプリント中に構築された。メンテナンスを担当する人がいない。トークンはコードベースから乖離する。コンポーネントはプロダクトに後れをとる。ドキュメントは古くなる。6ヶ月後、システムは去年のプロダクトのスナップショットだ。

失敗4：コンポーネントファーストの思考。 チームは1つのトークンを定義することも、1つのガイドラインを書くこともなく、47個のコンポーネントを作る。コンポーネントはFigmaファイルでは機能するが、根底にある値が体系化されていないため本番環境では壊れる。

失敗5：完璧主義による麻痺。 チームは何もリリースする前にすべてのエッジケースを解決しようとする。システムは一向にリリースされない。その間、プロダクトはシステムなしで毎日リリースされ続ける。

生き残るシステムの共通点

実際に長続きするシステム（Shopify Polaris、Atlassian Design System、IBM Carbon、GitHub Primer）を研究すると、3つのパターンが浮かび上がる。

小さく始めて成長した。 200個のコンポーネントでローンチしたものはない。トークン、少数のコアコンポーネント、明確なドキュメントでローンチした。その後、理論的な完全性ではなく、実際のプロダクトニーズに基づいて拡張した。

専任チームがある。 1人ではなくチームだ。スケールするデザインシステムには、最低でもデザイナー、エンジニア、ドキュメントライター、プロダクトオーナーが必要だ。ShopifyにはPolaris専属で数十人が働いている。数十人は必要ないが、ゼロ以上は必要だ。

コントリビューションをフィーチャーとして扱う。 最高のシステムは、プロダクトチームが追加を提案し、問題を報告し、コンポーネントをコントリビュートしやすくする。システムは中心だけでなく、端からも成長する。1つのチームの決定だけで成長するシステムは、常にプロダクトに後れをとる。

Design Tokensが本当の基盤

トークンは、他のすべてが継承するプリミティブな値だ。トークンを変更すると、それを参照するすべてのコンポーネントが自動的に更新される。これこそが、コレクションではなくシステムたらしめるものだ。

トークンレベル：

グローバルトークンは生の値を定義する。セマンティックトークンは意味（primary、danger、surface）を割り当てる。コンポーネントトークンはそれらの意味を特定のUI要素に結びつける。この3層構造により、1つのコンポーネントにも触れることなく、セマンティックトークンを変更するだけでリブランディングができる。

最初に定義すべきトークンタイプ：

• 色（背景、テキスト、ボーダー、インタラクティブな状態）
• スペーシング（4pxグリッド：4、8、12、16、24、32、48、64）
• タイポグラフィ（ファミリー、サイズスケール、ウェイト、行の高さ）
• ボーダーラジウス（なし、小、中、大、フル）
• シャドウ（エレベーションレベル）
• モーション（デュレーション、イージングカーブ）

他に何も定義しないとしても、これらは定義すること。チームが毎日下す視覚的判断の90%をカバーする。

長持ちするコンポーネントの作り方

トークンに基づいて構築されたコンポーネントは、ハードコードされた値で構築されたコンポーネントよりも本質的に堅牢だ。しかし、トークンベースのコンポーネントも構築方法が間違っていれば失敗する。

生き残るコンポーネントのルール：

設定より合成。 14個のpropsを持つボタンは柔軟ではない。脆弱だ。propsを通じてすべてのバリアントを処理するメガコンポーネントを作る代わりに、パターンに組み合わさる小さなコンポーザブルなパーツを作ること。カードは1つのコンポーネントではない。カードコンテナ、カードヘッダー、カードボディ、カードフッターが組み合わさったものだ。

ステートはオプションではない。 すべてのインタラクティブコンポーネントには、default、hover、active、focus、disabled、loading、errorのステートが必要だ。7つのステートすべてなしでコンポーネントをリリースするということは、誰かがそれらのステートをアドホックに作り、一致しないことを意味する。

「何か」だけでなく「いつ」を文書化する。 ボタンのドキュメントはどのように見えるかを示すだけでは不十分だ。プライマリボタン、セカンダリボタン、ゴーストボタンをいつ使うかを示すべきだ。意思決定フレームワークはビジュアルリファレンスより重要だ。

パターンはコンポーネントが解決できないことを解決する

ドロップダウンコンポーネントは、ドロップダウンがどのように見えるかを教えてくれる。しかし、ドロップダウンとラジオグループとセグメントコントロールのどれを使うべきかは教えてくれない。その判断こそがパターンだ。

早期に文書化すべきパターン：

• フォームレイアウト。 ラベルの配置、エラー表示、必須フィールドの表示、マルチステップフロー。
• ナビゲーション。 タブ、サイドバー、パンくずリストの使い分け。モバイルナビゲーションの折りたたみ動作。
• 空の状態。 データがないときに何を表示するか。イラスト？CTA？教育的コンテンツ？
• ローディング状態。 スケルトンスクリーン、スピナー、プログレッシブローディングの使い分け。それぞれが適切な場合。
• エラーハンドリング。 インライン検証、トースト通知、フルページエラー状態の使い分け。

これらのパターンは、システムのないチームを悩ませる「同じフォームを5つの異なる方法で作った」という問題を防ぐ。

ガバナンスが採用の成否を左右する

ガバナンスのないデザインシステムは、単なる提案に過ぎない。ガバナンスは3つの問いに答える。

1. 誰が決めるか？ レビューボードがあるか？単一の所有者か？民主的な投票か？どれを選ぶにしても、明示的にすること。
2. 変更はどのように行われるか？ RFCプロセス？GitHub issue？Slackスレッド？「新しいコンポーネントが必要だと思う」からそれがシステムに入るまでの道筋を定義すること。
3. バージョニング戦略は何か？ トークンパッケージのセマンティックバージョニング？リリースごとの変更履歴？ブレイキングチェンジのポリシー？

ガバナンスを省略したチームは、フォークしたシステムを抱えることになる。デザインはバージョン2.3を使っている。エンジニアリングはバージョン1.8を使っている。マーケティングサイトはローカルオーバーライドありのバージョン2.0を使っている。その時点で、デザインシステムが3つあって、一貫性はゼロだ。

よくある質問

デザインシステムの構築にどのくらい時間がかかるか？

初期基盤（トークン、10〜15個のコアコンポーネント、基本的なドキュメント）は、専任チームで2〜4ヶ月かかる。しかし、デザインシステムが「完成」することはない。デザインエンジニアリングチームのキャパシティの15〜25%を継続的に投資する計画を立てること。

小さなチームにデザインシステムは必要か？

必要だ。ただし、規模に見合ったものを。3人のチームにPolarisは必要ない。トークン付きの共有Figmaライブラリ、8〜10個のコアコンポーネント、1ページの意思決定ガイドが必要だ。最も痛みを感じているもの（大抵は一貫性のないスペーシングと色使い）から始め、そこから成長させること。

デザインシステムとコンポーネントライブラリの違いは何か？

コンポーネントライブラリは再利用可能なUI要素のコレクションだ。デザインシステムはコンポーネントライブラリに加えて、design tokens、使用ガイドライン、パターン、ドキュメント、ガバナンスを含む。ライブラリはシステムの一層に過ぎない。

野心ではなく、痛みから始める

プロフェッショナルに聞こえるからという理由でデザインシステムを作るな。チームが同じ問題を繰り返し解決することに時間を無駄にしているから作るのだ。今最も非一貫性を引き起こしている3つのことから始めること。それらを体系化し、リリースすること。その後は、ケーススタディで印象的に見えるものではなく、チームが次に求めるものに基づいて拡張すること。