デザインシステムに関する質問に答えました

2024年08月28日に発売された「デザインシステムの育て方（原題 Design That Scales）」をキッカケに、デザインシステムの質問をいただきました。

何故IBM, Google, Salesforce, Shopifyなどはデザインシステムを公開できているのでしょうか？

デザインシステムに関わる人数の違いが、公開できている最大の要因だと考えています。もちろん「オープンソースコミュニティへの還元」といった思想やマインドセットも欠かせませんが、長期的に維持・運用できる人材がいることが大きいです。

デザインシステムに関わる正確な人数は把握できませんが、ある程度予測は可能です。例えば IBM の Carbon Design System のレポジトリには482人がコントリビュートしています。もちろん、全員が常時関わっているわけではなく、全ての関係者がGitHubにコミットしているわけでもありませんが、100人以上が何かしら関わっていることは想像できます。

さらに、公開には他のメリットもあります。全世界に拠点を持つ大企業では、時差だけでなく、スキルや職域の違う多くの人が関わります（サードパーティやパートナーを含めるとさらに人数は増えます）。そのため、Web上に公開することで、誰でもいつでも参照できるという利便性が生まれます。

パイロットプロジェクトから抽出したモノは抽象化する際、歪曲して伝搬する危険性はないですか？

ありますが、未然に防ぐことも可能です。

まず、パイロットプロジェクトを行う理由や要件を明確にすることが重要です。なぜ現時点でパイロットプロジェクトが適切な手段だと判断したのか、どのような成果（アウトカム）を目指しているのかを、簡潔で良いので文書化します。ライブラリにあるコンポーネントに更新するのか。新しいコンポーネントを作るのか。プロジェクトの目的によって、アウトカムも変わるでしょう。

パイロットプロジェクトで新しいコンポーネントが生まれた場合、そのコンポーネントがどのような意図や文脈で作られたのかを記録することも大切です。これは担当デザイナーが記録するか、デザインシステムチームが支援するかは状況によりますが、デザインシステムチームが間接的にでもパイロットプロジェクトに関与することが必須です。

書く習慣がないチームであれば、まず少しだけでも書き始めるところからスタートかもしれません。

職種を超えたコミュニケーションデザインを考える

デザインの解説を書き残すことは非常に手間がかかりますが、デザインの意図が説明しやしくなるだけでなく、途中で人が入ってきたとしても文脈が伝わりやすくなります。

Yasuhisa HasegawaYasuhisa Hasegawa

また、現場の観察を通して、新しいコンポーネントを作る際に生じる問題やFigmaライブラリの構成、エンジニアとのやりとりに関する課題も見えてくるはずです。これらのポイントもメモしておくと良いでしょう。

デザインシステムを作る前にデザインのシステムを理解しよう

解決しなければならない課題に目を向けなければいけません。一貫性がない状態が生まれた要因は何でしょうか。

Yasuhisa HasegawaYasuhisa Hasegawa

事業としてデザインシステムを破壊、もしくは改変する選択をした際デザインシステムチームは何をすべきか

何が「破壊」や「改変」という判断に至ったのか、まずはその点について周囲と合意を取ることが最初のステップです。「整理がつかなくなったので改変します」「古くなったので仕切り直します」「担当者がいなくなったのでやり直したい」といった理由では、表層的な問題にしか聞こえず、それに反応しているだけだと感じられるため、誰も賛同しません。おそらく数年後同じ問題の再発になります。

しっかり症状と向き合うことが大事です。なぜ整理がつかない状況が生まれたのか？という問いに正直に答えること。特定の人のせいではなく、組織のインセンティブかもしれないですし、開発プロセスといった環境によるものが要因のことが多いです。

それ、課題じゃないですよ

人によっては症状を課題と呼んでいることがあり、こうした言葉の解釈のズレを置き去りにすると、進め方に対する意見の食い違いが発生します。

Yasuhisa HasegawaYasuhisa Hasegawa

ホットポテトは外注先の開発会社とシステム改善で実現できると思いますか？

ホットポテトはスピードだけでなく、周囲の雰囲気を読んで自発的な提案をしてチームメンバーを支え合う関係性が欠かせません。そうした密な動きがとれるような関係は社内にいるメンバーとのほうが実現しやすいですが、外部会社と実施するのであれば、ホットポテトができるように契約もしくは発注内容を変えるとお互い進めやすくなると思います。

様々な制約のなかで考えていることだと思いますが、外注先の方と一緒にするということは、ノウハウの一部が自社に残らない懸念もあります。そのため、プロジェクト後の振り返りやドキュメント制作を依頼することを忘れずに。

改めてデザイナーはHTML/CSSのスキルを習得すべきですか？

こういった「すべきですか？」という質問は、たいてい「Yes」という答えになりがちです。知識があるだけでも、Figmaのレイヤー構造や命名方法が変わるので、メリットはあると思います。ただし、「すべきこと」を際限なく習得するのもキリがありません。

Figmaなどのデザインツールを使って作業する方には、最低限「半年後の自分でも理解できるように作る」という視点を持っていてほしいです。今はファイルの細部まで覚えていても、半年後にはほとんど忘れているものです。場合によっては、「なぜ自分はこんな作り方をしたのか？」と自分自身にツッコミを入れたくなることもあるでしょう。

こうした問題を少しでも減らしたいと思う方なら、次第に「Group 1234」のような無意味なレイヤー名を減らし、フレームの外にメモ書きなどを入れるなど工夫を始めるはずです。そのようなちょっとした配慮でも、他のデザインチームメンバーだけでなく、エンジニアも助かるでしょう。

質問ありがとうございました。
また、デザインシステムの育て方の相談がある方はぜひお問い合わせください✉️

ポッドキャストでも質問を募集しています。

Automagic Podcast 質問フォーム

番組で取り上げる質問を募集しています！ 「デザインの決め方進め方」「PdMとのコミュニケーション」「オススメツール」など、デジタル系のデザイン周辺であれば答えられます！ 今まで取り上げた質問 フロントエンドエンジニアのデザインシステム関わり方は？ 次に生まれる新しいデザイナーってどんなものだと思いますか？ 効果的なUXリサーチ結果の伝え方 ポッドキャストを長く続けるためにやらないようにしてる事は？ デジタル庁のサイトについてどう思う？

Google Docs