なぜ使われない？デザインシステムを展開する上での課題と対策

デザインシステムには「作る」フェーズと、それを「展開して使ってもらう」フェーズがあります。どちらのフェーズでも多くの課題が生じますが、本コラムでは「展開」の方に焦点を当てて、よくある課題とその対策を紹介します。

はじめに

少人数のチームや自分たちだけで使うためにデザインシステムを構築するなら、展開はそれほど難しくありません。しかし、チームが異なったり、別のプロダクトに展開しようとしたりすると、さまざまな課題にぶつかることになります。

デザインシステムは単に作るだけでは意味はなく、実際にプロダクトに導入され、効率化や品質向上といった価値を生み出すことで価値を発揮します。そのため、展開の過程こそが非常に重要であり、かつ課題が発生しやすいフェーズだと言えるでしょう。

本記事では「デザインシステムチーム」と「プロダクトチーム」が分かれている状況を前提として、デザインシステムの実務への導入時に直面しがちな課題とその対策を紹介します。

課題：そもそも「使われない」

デザインシステムの実務への導入時に直面しがちな1つ目の課題は、現場で「使われない」というものです。
せっかくデザインシステムを構築したにも関わらず、プロダクトチームに使われないことは非常にもったいないです。使えるはずなのに使われないという状況に陥ってしまった場合の、よくある原因と対策をいくつか紹介します。

原因A：デザインシステムの利点が伝わっていない

使われない原因の1つとして考えられるのは「デザインシステムの利点や魅力がプロダクトチーム（利用者）に適切に伝わっていない」ことです。
存在は認識していたとしても、利用者自身がその利点を感じていない場合、利用するまでには至りません。それどころか、導入のメリットが伝わらなければ、利用者は単に「新しいルール」を押し付けられたと感じてしまうかもしれません。

利用者にとって、慣れ親しんだ従来の方法を変えることには、学習コストや心理的な抵抗が伴います。デザインシステムチームは、この状況をネガティブに捉えるのではなく、まずは彼らの立場に「共感」し、課題に寄り添いながら丁寧に説明していく姿勢が不可欠です。

対策①：相手の「知りたいこと」に寄り添い、メリットを伝える

では、どうすればデザインシステムの価値を理解し、受け入れてもらえるのでしょうか。
大切なのは、デザインシステムの崇高な思想や設計思想を語ることではありません。それよりも、利用者一人ひとりにとって「何がどう嬉しくなるのか」という、具体的なメリットを伝えることです。
さらに効果的なのは、相手の役職や関心事に合わせた「刺さる言葉」で伝え方を変えるアプローチです。

PMにとってのデザインシステムの価値とは？

PMの主な関心は、プロダクト全体の品質、収支、チームの生産性にあると言えます。
PMに具体的なメリットを伝えるには、導入によってどれだけ効率化・コスト削減できるかを数字や事例で示すことが有効です（例:「UI修正対応の工数が30%削減」）。
また、一気に全ての画面に導入すると混乱や負担が増えるリスクがあるため、特定画面のボタンやフォームなど、小さい範囲で効果を数字で確認した上で拡大導入することを提案するのも良いかもしれません。

デザイナーにとってのデザインシステムの価値とは？

デザイナーの主な関心ごととして、デザインファイルの整理方法、スタイルの一貫性、効率的な作業プロセスなどが挙げられます。
デザイナーには、コンポーネントやデザイントークンの利用方法を具体的に伝えるとメリットを理解してもらいやすいのではないでしょうか。コンポーネント修正を1箇所で行えば全てのデザインに反映される仕組みを数字で示すと、より負担軽減が伝わりやすくなります（例:「ボタンのカラー変更作業が1時間から1分に短縮」）。

エンジニアにとってのデザインシステムの価値とは？

デザイナーの主な関心ごとは、デザインシステムによって実際のコードや開発プロセスがどう変わるかです。
そのため、UIコンポーネントの管理ができるStorybook等のツールを用いて、UIライブラリの具体的な使い方を示すのは有効です。実装スピードが速くなる点を数字で示すと、説得力が増すでしょう（例:「UIライブラリを導入することで、コードの記述量を300行程度削減可能」）。
デザインシステムやUIライブラリの利用に対して知見の少ないエンジニアには「効率的に画面実装できるUI部品集」というような言葉で説明すると理解がスムーズに進むかもしれません。

対策②：「まず触ってもらう」体験の場をつくる

説明を聞くより、実際に体験してもらう方がより理解が進む可能性が高いです。実際に手を動かして触れてもらうことで、その利便性を肌で感じてもらえます。
デザイナーやエンジニア向けに、簡単なハンズオンや勉強会を開いてみましょう。実際にコンポーネントを使って画面を組み立てる体験は、どんなに言葉を尽くすよりも深い理解につながります。

また、こうした場は、デザインシステムが抱える課題を吸い上げる絶好の機会にもなります。「説明が分かりにくい」「導入する上でこんな技術的な課題がある」といった、リアルなフィードバックは、デザインシステムをより良くしていくための貴重な財産です。

対策③：疑問を放置しない「継続的なコミュニケーション」

導入時の説明会だけで終わりにしてはいけません。プロダクト開発に組み込む中で、新たな疑問は次々と生まれてきます。
これらの疑問を放置してしまうと、独自の解釈で使われ、デザインの一貫性が損なわれる利用者の不信感や不安が募り、次第に使われなくなるといったリスクにつながります。

週に一度30分程度の相談会を設けたり、導入初期は物理的に近くの席で作業したりと、利用者がいつでも気軽に質問できる環境を作ることが、デザインシステムをチームに根付かせるための鍵となります。

原因B：メンテナンスされておらず「信頼できない」

次に考えられる「使われない」原因はデザインシステムが正しくメンテナンスされていないことです。UIライブラリが長期間更新されていなかったり、プロダクトの要件変更に追従できていなかったり…。そのような適切にメンテナンスされていないデザインシステムは魅力的ではなく、利用されない可能性が高いです。

一度「このシステムは古くて使えない」という印象を持たれてしまうと、利用の定着は困難になります。継続的に利用してもらうためには、構築後の適切な運用体制が不可欠です。

対策①：継続的な改善を可能にする運用体制を構築する

デザインシステムの改善や更新が滞らないよう、まずはその土台となる体制を整えることが重要です。

担当者と工数を明確にする

はじめに、デザイン側と開発側でメイン担当者を任命し、責任の所在を明確にします。ただし、担当者が他の業務と兼務している場合、改善の優先度が下がりがちです。計画的に改善を進めるためには、活動のための工数をあらかじめ確保しておくことが重要になります。

改善プロセスを定義し、周知を徹底する

次に、「課題の起票 → 実施可否の検討 → 実装 → ドキュメント更新 → リリース」といった一連の改善プロセスを定義します。このプロセスには、コードの変更だけでなく、関連するドキュメントの更新も必ず含めるようにルール化します。これにより、「コードは最新なのに使い方が分からない」といった事態を防ぎます。

また、リリース時にはバージョン管理と変更履歴の記録に加えて、その内容を利用者へ積極的に周知することも大切です。プロダクトチームが利用するコミュニケーションツールへ更新通知を流すなど、相手が情報を確認しやすい方法で共有しましょう。

対策②：フィードバックを収集し、活用する仕組みを作る

デザインシステムを改善するためのヒントは、実際の利用場面にあります。利用者からフィードバックを収集し、迅速に対応していくことは、システムの品質向上と利用者からの信頼獲得に直接つながります。

フィードバックの心理的ハードルを下げる

特にチームが分かれている環境では、プロダクトチームからデザインシステムチームへ要望を伝えることに、心理的な抵抗を感じる場合があります。そのため、誰もが気軽に意見を投稿できる「窓口」を用意することが効果的です。「何かあれば連絡してください」というスタンスだけでなく、個人宛てではない「場」に対して意見を投稿できる仕組みを設けましょう。

また、その窓口は「改善要望」に限定せず、「仕様に関する質問」や「相談」なども受け付けるように設計すると、より多くの声が集まりやすくなります。

フィードバックへの応答を徹底する

さらに重要なポイントとしては、投稿されたフィードバックには必ず何らかの応答をすることです。「内容を確認しました」「次のアップデートで対応予定です」といったリアクションを返すことで、利用者は自分の声が届いていると実感できます。このような丁寧なコミュニケーションが信頼関係を構築し、継続的なフィードバックを促進します。

原因C：必要ではないものを用意している

デザインシステムを運用していくと、頻繁に利用されるコンポーネントと、そうでないものの二極化が見られることがあります。その原因の一つとして、そもそも利用実態に合わない、必要とされていない要素を作ってしまっている可能性が考えられます。

こうした状況は、他のデザインシステムを参考に網羅性を重視したり、「将来必要になるかもしれない」という予測に基づいて過剰に作り込んでしまったりすることで起こりがちです。

対策①：小さく始め、プロダクトの課題に集中する

デザインシステム構築の基本は、小さく始めることです。不要な要素は利用されないだけでなく、将来的なメンテナンスコストとなり、負債に変わる可能性があります。

まずはプロダクトが抱える最大の課題は何かを見極め、それに対する最適な解決策に集中しましょう。例えば、開発工数の削減が目的なら、まずは最小限のUIライブラリだけを用意して効果を検証し、ルールや詳細なガイドラインは必要に応じて後から整備していくのが堅実なアプローチです。

対策②：データに基づいてコンポーネント化を判断する

どのコンポーネントから作るべきかという優先順位は、勘や理想ではなく、実際のデータに基づいて判断することが重要です。

プロダクトのUIを棚卸しする

具体的な手法として、プロダクト内に存在するUI要素（ボタン、フォームなど）をすべて洗い出し、その出現頻度やデザインのバリエーションをリスト化する「UIの棚卸し」を行いましょう。この作業により、最も再利用性が高く、共通化による効果が大きい要素を客観的に特定できます。

コンポーネント化の基準を設ける

この棚卸しの結果を踏まえ、コンポーネント化するかどうかを判断する際には、シンプルな基準を設けると意思決定がしやすくなります。例えば、「プロダクト内で3回以上利用されているパターンか」という基準（3回ルール）が有効です。3回以上出現する要素は、今後も利用される可能性が高いパターンと見なせますが、それに満たない場合は、まだ共通化するには時期尚早かもしれません。

また、不要な要素の作成にリソースを割いてしまうと、結果的に本当に必要なコンポーネントの開発が後回しになり、利用者が「使いたい時に必要なものがない」という事態を招きます。これもまた、デザインシステムへの不信感につながる一因です。

課題: 使われてはいるが、期待した「効果」が出ない

デザインシステムがチームに浸透し、利用されるようになった後、次に直面するのがこの課題です。ここでの「効果」とは、特にデザイナー、エンジニアの作業の効率及びプロダクト側UIの品質の向上を指します。デザインシステムが使われているにも関わらず効果が実感できない場合、その使い方に問題があるのかもしれません。

原因D：ルールが曖昧で、デザインが属人化している

これは、デザインシステムの使い方が、利用者に委ねられすぎているケースです。
例えば、コンポーネントをどう組み合わせるか、余白をどう取るかといった判断基準やルールが曖昧になっていると、アウトプットが個々の担当者のスキルや解釈に依存してしまいます。その結果、良かれと思って行った実装がプロダクト全体で見るとデザインの一貫性を損なう「揺らぎ」となり、期待した品質向上につながりません。

対策①：判断の拠り所となるルールを整備する

属人的な判断を減らし、誰が担当しても一定の品質を保てるよう、判断の拠り所となるルールを明文化することが重要です。

デザイン原則を定義する

まずは、チームが意思決定に立ち返るための「デザイン原則」を定義しましょう。原則は、デザインに迷った際に「どちらがより我々のプロダクトらしいか」を判断するための共通のコンパスとして機能します。

Amebaデザインシステム Sprindleでは、デザイン原則を次のように説明しています。

デザイン原則は「Amebaらしさ」を届けるためにどのように設計、デザインをするかの「約束事」です。

スタイルガイドラインを具体化する

色の使い方やコンポーネント間の余白といった、より具体的なデザインルールを「スタイルガイドライン」として整備します。具体的な指針を示すことで、細部のデザイン品質を担保します。

例えば、デジタル庁デザインシステムでは、リンクテキストの色だけでも色覚多様性も考慮してどう設定すべきかという指針を具体的に示しています。

対策②：ルールを形骸化させないプロセスと文化を醸成する

ルールは、作って終わりではありません。それを遵守し、維持していくための仕組みが必要です。

変更・追加のプロセスを設ける

新しいコンポーネントの追加や既存コンポーネントの変更時には、設計やデザインのレビューを含む明確なプロセスを定義し、無秩序な変更を防ぎます。

デザインレビューの文化を根付かせる

プロセスを形骸化させないためには、デザイナー同士が気軽に相談し、レビューし合える文化を醸成することが不可欠です。定期的なデザインレビュー会などを設け、チーム全体で品質を担保する意識を高めていきましょう。

対策③：チームの理解度を底上げする教育を行う

特に、経験の浅いメンバーや新しくチームに加わったメンバーがいる場合、ルールを渡すだけでは不十分かもしれません。
新しいメンバー向けにデザインシステムの正しい使い方を学ぶオンボーディングプログラムを用意したり、定期的に勉強会を開催したりすることも、属人化を防ぎ、チーム全体の品質を底上げするために有効な手段です。

原因E：プロダクトの「実態」と乖離している

デザインシステムが現場で利用されはじめてから問題が発覚して、実装の効率が上がらないというケースもあります。これは、デザインシステムが導入先プロダクトの技術的な制約や歴史的経緯を十分に考慮せずに設計されてしまう、実装観点の課題であることが多いです。
特に構築チームとプロダクトチームが分かれている場合、コミュニケーション不足からこの問題が発生しやすくなります。

例えば、以下のようなプロダクト固有の制約に対応できていない場合が考えられます。

• 特定の古いブラウザへの対応要件を満たしていない
• プロダクト側で利用している特定のライブラリ（フォームなど）と競合する
• 既存のCSS設計との相性が悪く、導入コストが高い
• アクセシビリティやパフォーマンスに関する要件をクリアできない

このような課題があると、デザインシステムの導入が部分的なものに留まったり、利用者の印象が悪化して利用されなくなったりするリスクがあり、期待した開発効率の向上につながりません。

対策①（予防策）：パイロットチームで構築と導入を並行して進める

この問題を回避するために最も有効なのは、構築の初期段階からプロダクトチームの協力を得て、検証を進めることです。

一部の機能やチームを「パイロットチーム」として巻き込み、デザインシステムの構築と実際のプロダクトへの導入を並行して実施するアプローチを推奨します。机上の議論だけでは見えてこない課題は数多くあります。実際にプロダクトに組み込んでみることで、技術的な問題を早期に発見できるだけでなく、パイロットチームが両チームの「橋渡し役」となり、円滑な連携を促すという組織的なメリットも期待できます。

対策②（事後対応）：展開フェーズで見つかった課題に対処する

もし展開フェーズでこのような課題が見つかった場合、迅速な対応が求められます。すぐに改善できる問題であれば対応するのが最善ですが、設計レベルからの見直しが必要な場合は、影響範囲の大きい特定のコンポーネントを一時的に「利用禁止」とする判断も必要になるでしょう。

「せっかく作ったのに」という気持ちになるかもしれませんが、デザインシステムの目的はプロダクトを改善することである、という原点を見失わないことが重要です。

なお、デザインシステムとプロダクトの「現実」に乖離があった場合の解決策としてプロダクト側の要件や設計を変更することは、デザインシステム側の都合を押し付けることになるため、基本的には推奨されません。
ただし、双方にとってメリットがある場合は、デザインシステムの導入を機にプロダクト側の古い設計を見直す、といった前向きなリファクタリングも選択肢になり得ます。重要なのは、プロダクト全体の価値向上という共通の目的に立ち返り、協力して判断することです。

原因F：不具合が多く、品質が信頼できない

提供されるコンポーネントに不具合が多く、その改善も迅速に行われない場合、利用者はデザインシステムに対して強い不信感を抱きます。
これは利用者の開発体験を損なうだけでなく、プロダクト本体の品質に直接影響を及ぼす重大な問題です。結果として、デザインシステムの利用が敬遠され、効果が出ないどころか、負債となってしまう可能性さえあります。

対策①（予防）：不具合を作り込まない開発プロセスを導入する

品質を担保するためには、まず不具合の発生を未然に防ぐ「予防」の観点が重要です。

静的解析ツールの導入

静的解析ツールとは、ソフトウェアを実際に動かす前にコードをチェックし、潜在的な不具合やルール違反を早い段階で見つける仕組みです。
例えば「ESLint」や「Prettier」といったツールを導入すると、コードの書き方を自動でチェックし、チーム全体で統一感のある品質を保てます。これにより、人手でのレビュー負担を減らし、修正コストやトラブル対応の工数を削減できます。

また、UIライブラリをReactやWeb ComponentなどのJavaScriptベースの技術で開発する場合は、TypeScriptの利用をおすすめします。TypeScriptはJavaScriptに「安全性を高める仕組み」を加えたもので、コードを事前にチェックしやすくするため、不具合を未然に防止できます。その結果、開発スピードが向上し、品質トラブルによる後工程のコスト削減にもつながります。

コードレビューの徹底

開発プロセスにコードレビューを必須とし、実装担当者以外の目で潜在的なバグや設計の問題を早期に発見できる体制を整えます。

対策②（検知）：自動テストで品質を継続的に担保する

作り込まれた不具合をリリース前に発見するためには、網羅的なテスト戦略が不可欠です。特に、手動テストへの依存を減らし、自動化を進めることが持続可能な品質保証の鍵となります。

ビジュアルリグレッションテスト

ビジュアルリグレッションテスト（VRT：Visual Regression Testing）とは、画素の差分を検出することで意図しない見た目の変化（デグレード）を自動で検知するテストです。
例えば、UIを実装する際のテストの自動化、チーム内共有、コメント・レビュー機能などを備える「Chromatic」のようなツールを活用することで、軽微なCSSの変更が予期せぬ影響を及ぼしていないかを効率的に確認できます。

E2E（End-to-End）テスト

E2Eテストとはユーザーで視点アプリケーション全体の動作を確認するテスト手法です。デザインシステムで用意した複数のコンポーネントを組み合わせた実際の画面で、ユーザーが意図した通り操作できるかを検証します。
例えば、主要なブラウザをサポートし、クロスブラウザテストが容易に実行できる「Playwright」のようなツールを使うことで、複雑なインタラクションを含む画面の動作を保証できます。

これらのテストを開発プロセスに組み込むことで、品質チェックの工数を削減し、より重要な開発作業に集中できるようになります。

対策③（対応）：迅速な不具合修正プロセスを確立する

万が一不具合が発見された際には、原因Bで述べた改善プロセスに則って迅速に対応し、修正版をリリースできる体制を整えておくことが、利用者からの信頼を維持する上で不可欠です。

デザインシステムの本質的な価値とは

デザインシステムの本質的な価値は、プロダクトの「実装速度」や「品質」を向上させることにあります。そのために重要なのは、デザインシステムの構築や展開を「目的」ではなく、あくまで「手段」として捉えることです。

デザインシステムチームは、「スタイルガイドの整備」や「コンポーネント利用率の向上」といった内向きの目標を追い求めがちですが、それ自体がプロダクトの価値を高めるわけではありません。私たちは常にプロダクトチームが抱える本質的な課題に目を向け、その解決に貢献しなくてはなりません。チームの目標も、「コンポーネント利用率」から「プロダクト開発の工数削減」へと、視点を転換することが求められます。

AI時代のデザインシステム

デザインシステムの展開の話題からは少し外れますが、生成AIの台頭により、あらゆる物事がこれまで以上にスピーディーに進むようになりました。デザインシステムも例外ではありません。

FigmaがリリースしたCode ConnectとDev Mode MCPサーバー（執筆時点ではオープンベータ版）はデザインシステムの展開、特にフロントエンド実装において非常に効果的なツールです。

技術的な詳細は省きますが、簡単に言うと Code Connect は「Figma上のコンポーネントと実装側のコンポーネントを紐付け、Figma上に利用可能なコードを表示する仕組み」です。

一方、Dev Mode MCPサーバー は「Figma上のデザインデータをAIモデルに渡し、フロントエンド実装の精度を向上させる仕組み」です。Dev Mode MCPサーバーでは、Code Connectを通して設定されたコンポーネントのコードの情報も取得できます。

この2つを組み合わせることで、AIモデルによる画面デザインのコード生成を、実際に利用可能なコードを用いて行うことが可能になります。

これにより、従来よりも高い精度でAIを活用したフロントエンド実装が期待できます。

展開フェーズにおいても、こうしたツールを組み合わせ、生産的に進めていくことが今後ますます重要になるでしょう。

最後に

デザインシステムの展開は、一度の説明で完結するものではなく、継続的な対話を通じて育てていくプロセスです。
最初は小さな一歩からでも構いません。大切なのは、利用者であるデザイナーやエンジニアの声に耳を傾け、彼らが抱える課題に寄り添い、共に改善していく姿勢です。

本記事で紹介した課題や対策が、皆さんのデザインシステム展開を成功に導くための一助となれば幸いです。
NCDCでは、今回ご紹介した内容に限らず、デザインシステムの構築・展開に関するさまざまな課題に対応したご支援が可能です。どうぞお気軽にご相談ください。