デザインシステム構築に必要なのは結局コミュニケーション
はじめに
2025年現在、「デザインシステム」という言葉は既に広く知られており、規模の大小はあれど、多くのプロジェクトで作成・運用されるようになったように感じます。
そんな時勢の中、初めて業務でデザインシステムの構築に携わることになり、個人的に反省点が多々ある結果となってしまったので、自戒の意を込めてここに反省と得られた教訓を記しておきます。
本記事について
本記事では「デザインシステム構築業務に対する考え方」を中心に書きました。「トークンの命名規則」など具体的な話はそこまでしません。
プロジェクトの前提
この記事における事例となるプロジェクトについて簡単にまとめておきます。
私が参画した当時、デザイナーの方がFigmaで途中まで作成したデザインガイドラインがありました。
ただ他業務の都合でデザインシステム関連の業務が一旦保留とされており、この時点では実際のプロダクトのデザインやプロダクトコードには反映されていません。
ちょうど私が参画したタイミングで、折りよくこのガイドラインを作り切ることになりました。
諸々の都合により工数が1ヶ月しか取れず、エンジニア側は関連業務に着手する予定はありませんでしたが、個人的にデザインシステム関連の話に興味があり、この機に実践経験を積みたいと思っていたので、打診してエンジニア領域の業務を担当させてもらうことになりました。
今思えばこの1ヶ月という工数でできることなどたかが知れているのですが、当時の私は「まぁ普段から知識は漁ってるし、ある程度は形にできるやろ」と楽観的に考えており、結果ちゃんと痛い目を見ました。
本来のゴール
反省に移る前に、本来デザインシステムを構築する時に何がゴールになるかを考えます。
デザインシステムの目的と目指す状態
デザインシステムの目的は、大きく分けると「ブランディング」と「開発生産性向上」に分けられます。私はブランディングについては深く語れないので本記事では割愛します。
ここで気をつけなければいけないのは、「開発生産性向上」とはチーム全体としてより多くの課題を解決できるようになっていなければいけないという点です。
エンジニアの視点でデザインシステムと聞いて真っ先に思いつくのは、デザイナーとの共通言語（＝デザイントークン）を策定することによるコミュニケーションコスト削減や、コンポーネントライブラリを実装してプロダクトで再利用することによる実装工数削減など、実装と直接紐づくような話かと思います。身近な話なので当然と言えば当然ですね。
この時エンジニア観点のみでデザインシステム構築を進めてしまうと、デザイナーが使いづらい（最悪使うこともできない）本末転倒なデザインシステムが出来上がります。
例えばデザインシステム構築にあたりよく使われる「Tokens Studio for Figma」というFigmaプラグインは、GitHub連携などエンジニアにとっても嬉しい機能が盛り込まれているため、可能であれば採用したいと考える人も多いのではないでしょうか。
ただデザインシステム構築を前提としていない限り、既存プロダクトのデザイン業務で採用されていることはまずないでしょう。
新しいプラグインを採用するということは、既存の業務プロセスを新しいプラグインを使ったものに変えていく必要があるということです。これには当然学習コストが必要になるだけでなく、変化に対する心理的なハードルもあります。
デザイン業務のプロセスの変更にデザイナーの同意が得られていなければ、そこで作られたものはただ形骸化するだけで、目的の開発生産性向上には繋がりません。
更に加えると、デザイナー・エンジニア間で納得いくものが出来上がったとしても、チーム全体に浸透していないと運用に乗せることはできません。プロダクトオーナーなど方針を決定するメンバーと意思疎通が取れていないと、運用するために必要な工数が見積もられず、これもまた形骸化することになります。
多くの人に言われていることですが、デザインシステムは構築して完了ではなく、そこから継続して運用しなければ意味がありません。運用するためには、それまでデザイントークンがなかったチームに浸透させるための学習コストや、作成したデザインシステムを継続して運用し続ける工数がかかります。
これら全ての工数を天秤にかけた上で、「開発生産性」＝プロジェクトが持つ課題を解決する速度が向上したと言える状態が、デザインシステムの作成により目指すべき状態です。
「デザインシステム」が指す成果物
ここまで「デザインシステム」という言葉を使い続けていますが、そもそもデザインシステムとは具体的にどのような成果物を指すのでしょうか？
「デザインシステム」に近い用語はいくつかあり、これらはその性質や作用する職能によって区分できると考えています。
- デザイン原則 ... デザインのベースになる思想、コンセプト。
- デザインガイドライン ... デザイン原則に則り作成された具体的なルール。
- デザインシステム ... 原則及びガイドラインをプロダクトに反映させるための仕組み全般。
これらと具体的に作られるものを簡単に図にしてみました。
「デザインシステム」と言っても、その内実は多種多様です。
大量の人的リソースを割いて上記全ての領域を完全に網羅するパターンもあれば、一旦既存のプロダクトのUIを整理する目的で、デザイン上共通するUIをまとめたコンポーネントライブラリだけ作るパターンもあります。
ここで重要なのは、何をゴールとするかチーム全員の認識が揃っている必要があるということです。
成果物とその目的の認識がメンバー間でずれていると、細かい意思決定をする時の指針がないので、統一されるはずのデザインシステムの中でデザインの意図がぶれぶれになってしまいます。
デザインシステムは、継続して運用されるという点で、プロジェクトではなく一種のプロダクトです。
プロダクトの目的が定まっていないと、ユーザーはどのように使えば良いかわからず離れていってしまいます。
使われないプロダクトに価値はありません。必ず目的を定め、それに適した形のデザインシステムを作り、ユーザーに価値をもたらすことが重要です。
今回の反省→学びポイント
1. チーム全体を巻き込み、全体でゴールの認識を合わせる
今回の最も大きい反省点として、先に述べた「チーム内で目指すゴールを統一する」ことができていませんでした。
これは完全に自分の進め方のミスで、デザイナー・エンジニア以外の役職（プロダクトオーナー、スクラムマスターなど）のメンバーとの共有が不十分だったり、デザイナー・エンジニアそれぞれと個別にコミュニケーションを取ることが多く、一度に全体で認識を揃える機会を設けていませんでした。
結果として、ある程度仕組みができて共有したタイミングで認識のずれが発覚し、そのまま運用できる状態まで作り切ることができませんでした。
今思えば、デザインシステム構築というプロジェクトに対し、全体像など叩きを作った段階で、全員（最低でも全役職１人）集めて相談するべきだったと思います。
またこの時、前にも述べたように「何を作り（成果物）」「どう使うか（運用）」を定めて合意を取っておけば、全員がそのゴールに向かって動けたでしょう。
2. 「デザインシステムを小さく作る」は思ったより小さくない
今回デザインシステム構築に着手することになった段階では、ここまで本記事で書いたようなことは考えられておらず、まさにエンジニア視点の考え方に寄っていました。
そのため自分は、エンジニア側で先に仕組みを作り、それを元に他メンバーと話しながらいろいろ決めていければよいかと、かなりふわっとした進め方を考えていました。
しかし蓋を開けてみれば、そもそも仕組みを作る段階でデザイン業務視点や運用視点で考慮しなければならないことが多く、かなりの時間を他メンバーとの相談・意思決定に割くことになりました。
今回このコストの見積もりが甘く、着手した当初想定していたところまで完成させることができませんでした。
デザインシステム構築にかかるコストのほとんどはコミュニケーションコストです。
目指すゴールをコンポーネントライブラリのような小さい範囲に留めたとしても、どこまでライブラリとしてまとめるか、どのようなルールのもとにまとめるか、運用はどのように行うかなど、チーム全体の方針として決めなければいけないことは山ほどあります。
通常のタスクでも設計・開発のような実作業だけでなくコミュニケーションにかかるリードタイムを考慮して見積もりをする必要がありますが、デザインシステムにおいては思っている数倍かかると認識しておいたほうがよいです。
またデザインシステムに専任させる人的リソースを持つケースはそこまで多くありません。基本的には通常業務と並行して行うことになると思います。
障害対応など緊急性の高い（ように見える）タスクによって、思うようにデザインシステムの工数が取れないこともあるでしょう。
この時デザインシステムを小さいタスクと捉えていると、「あとでやればいいや」と先送り先送りにされ、最終的には「いつかやろう」とデザインシステム構築自体が頓挫してしまうことになります。
予想しているよりも大きいプロジェクトになることを始めから自覚し、その前提で成果物や工数を考えることが重要です。
できたポイントを少しだけ
反省点も多い取り組みでしたが、気分を上げるために少しばかりできたことも書いていきます。
デザイナーとエンジニアの双方が使いやすいものを考える
今回デザイナーさんとのコミュニケーションの多くがこれに当たる内容でした。
デザイントークンやコンポーネントの叩きはデザイナーに作成していただきましたが、これらは再利用性や統一されたルールを考慮して定義する必要があります。
これはWeb制作的なデザイン業務と比べるとかなりシステマチックで、初めて取り組むデザイナーはかなり戸惑うポイントかなと思っています。
そのためエンジニア側で使う時にどのような形になっていると嬉しいか、密に連携を取りながら進めました。
ただ前述した通り、エンジニア側の思考に寄りすぎてデザイナーが使いづらいものになってしまうと、みんなが使いやすいデザインシステムにはなりません。
当初作成いただいたトークンがどのような意図で作成されたかなど、デザイナー側の思考を聞き出したりしながら、なるべく双方が使いやすい定義を目指しました。
結果としてお互い納得感を持って作業を進められたように感じます。
Figmaからデザイントークンを書き出してTailwindCSSのテーマに設定する
実装目線のタスクに目が向きすぎたという反省はありつつ、その部分に関してはある程度形にできたかと思っています。
今回は以下の流れを採りました。
- Figma Variablesでデザイントークンを定義する
- Figma PluginのDesign Tokens を使ってtokens.jsonを書き出す
- 2で書き出したjsonをStyle DictionaryでTailwindCSS v4のthemeに変換する
プロジェクトによっては別のツールを採用することも多いですが、大まかな流れはどのプロジェクトでもそこまで変わらないと思います。
TailwindCSS v4からTheme variablesという機能が追加され、これまでjsで記述していたテーマをCSS変数で書けるようになりました。
当時まだv4が公開されて日が浅く、この形式にStyle Dictionaryで変換する事例が見当たらなかったので、自前で変換するためのStyle Dictionaryのjsを書きました。
元々TailwindCSSはちょっと触ったことがあるくらいでしたが、この作業を通してベースの考え方が少し理解できたような気がします。
おわりに
昨今AIが急速に発展してきて、デザインシステムの重要性はより一層高まっています。
AIはプロンプトの要件を満たすUIを一瞬で作成してくれますが、生成結果に再現性がないため複数のサービス・プロダクトで一貫したデザインを担保するのは不得手です。
これがデザインシステムという拠り所を得ることで、プロダクトで重視すべき原理原則に則ったデザイン・UIを確実に提供できるようになります。
本記事で述べたように、デザインシステムの構築にはコミュニケーションによる課題発見と意思決定が最も重要かつ時間がかかります。
AIによるサポートはいくらか望めるものの、各々のプロダクト・プロジェクトの課題はそれに関わる人にしかわかりません。
この前提やチームが目指す状態とそれをどう継続させるかをチーム全体で共有しながら進めることで、形骸化しないプロダクトとしてのデザインシステムを運用することができます。
これから増えるであろうデザインシステム関連の業務に携わる人に、少しでも糧になる部分があれば幸いです。
おすすめ書籍の紹介
記事の執筆中、以前から認知していたもののタイトルだけ見て積読していた『デザインシステムの育て方 継続的な進化と改善のためのアプローチ』を読み始めました。
まだ冒頭十数ページですが、デザインシステムの捉え方や構築・運用に必要な心構えなど、新規に作成するケースに対しても有効な内容で、どうしてプロジェクトを担当する当初に読んでいなかったか後悔しています。
ぜひ一読されることをお勧めします。
Discussion