デザインシステムは「作る」より「運用する」ほうが10倍難しい
立派なガイドラインが「誰も見ないPDF」になる日
「開発のスピードを上げたい」「プロダクト間のUIのばらつきをなくしたい」。そんな目的でデザインシステム構築のプロジェクトが立ち上がる。数ヶ月かけてFigmaで美しいコンポーネント集を作り、詳細なルールをドキュメント化する。しかし半年後、そのデザインシステムは誰にも参照されず、現場ではまた独自のボタンやフォームが量産されている。なぜこんなことが起きるのか。
デザインシステムは「プロダクト」である
最大の原因は、デザインシステムを「一度作ったら終わりのガイドライン」だと勘違いしていることだ。デザインシステム自体が、社内のデザイナーやエンジニアをユーザーとする「ひとつのプロダクト」なのだ。プロダクトである以上、ユーザーのフィードバックを受けて継続的に改善し、アップデートし続けなければ、すぐに実態と乖離して使われなくなる。
形骸化を防ぐための3つの運用ルール
1. 「例外」を許容するプロセスを作る
どんなに完璧なコンポーネントを用意しても、実際のプロダクト開発では「どうしてもこの画面だけは特別なUIにしたい」という例外が必ず発生する。この時、「ルールだからダメ」と突っぱねると、現場はデザインシステムを無視して隠れて実装し始める。例外が発生した時の相談フローと、それをシステムに逆輸入してアップデートする仕組みを最初から設計しておくことが重要だ。
2. 専任の管理チーム（または担当者）を置く
「みんなで少しずつメンテナンスしよう」という性善説は、忙しい現場では絶対に機能しない。誰の責任でもない仕事は、誰の仕事でもなくなるからだ。規模にもよるが、デザインシステムの保守・運用に責任を持つ専任の担当者、あるいは稼働の20%を割り当てられたコアメンバーを明確にアサインする必要がある。
3. コードとデザインを同期させる
Figma上のデザインと、実際のフロントエンドのコード（ReactやVueのコンポーネント）がズレ始めると、デザインシステムの崩壊が始まる。Storybookなどを活用し、「デザインデータと実装されたコードが常に一致している状態（Single Source of Truth）」を技術的に担保する仕組みが欠かせない。
小さく始めて、育てていく
最初からGoogleやAppleのような壮大なデザインシステムを作ろうとする必要はない。まずはカラーパレットとタイポグラフィ、そしてよく使うボタンやフォームのコンポーネントだけを定義する。それを実際のプロジェクトで使いながら、足りないものを少しずつ足していく。その泥臭い反復作業の先にしか、本当に機能するデザインシステムは存在しない。