始めに
この記事は、Frontend Talk「デザインシステム構築のリアルな裏側」（hey・note・ANDPAD）のイベント内容について、レポート形式でまとめたものです。
発表者、運営者など関係者の皆さまにデザインシステム構築の知見を共有いただけたこと、レポートの公開許可をいただけたことを感謝します。
- 各社の発表内容を項目ごとにまとめた構成としています。
- レポート内容には自分の感想や解釈も含まれています。
- 掲載許可のもとで公開しています。
重要ポイントの抜粋：各社で共通していると感じたこと
時間はかかるが、一貫性の維持と効率化のために
- デザインの一貫性維持や開発効率化のためにつくっている。
- いきなり完璧なものを目指さない。まずは70点を目指す。
- 頑張っているが未完成で時間がかかる。走りながらつくっている。
共有しやすい仕組みづくり
- デザイントークン（最も小さな構成要素）をつくる。
- Tailwind CSSを使っている。まずはCSSを共通化する。
- ドキュメントに曖昧な内容を残すと、トラブルのもとになりやすい。ブレやすい。全体最適のためにロジカルに細かく言語化する必要がある。
デザイナーとエンジニアの連携と共有
- 全体像をチームで共有する。認識を共有する。
- デザイナーとエンジニアの連携を密に。
- デザイナーとエンジニアの橋渡し的な役割が必要。
思ったこと
ちょうどデザインシステムを構築中ということもあり、とても参考になりました。以下の点に特に共感しました。
- いきなり完璧なものを目指さず、まずは70点を目指して走りながらつくっていく。まずはデザイントークン（最小の構成要素）を定義する。
- Tailwind CSSを用いて、まずはHTMLとCSSを共通コンポーネント化する。VueやReactなどのフレームワークごとの対応はその次とする。
- 全体像をチームで共有し、デザイナーとエンジニアが相互にフィードバックしてつくりあげていく。
Tailwind CSSを用いることでフロントエンドエンジニア間でルールを共通化しやすくなるメリットの他にも、デザイナーがソースコードを編集しやすくなるメリットもありそうです。デザインを細かく微調整できることによる品質向上と開発効率化のメリットがあると思います。
デザインシステムをつくる目的・必要性
デザインや実装方法に一貫性が無く、ユーザーの利便性が損なわれているので改善したい
- デザインに一貫性が無く、サービスや機能によってデザインが不統一で品質に差がある。適切なコンポーネント化（共通部品化）がされていない。
- それによりデザイン再現度の低い、インタラクションが統一されていない、開発効率が低い、メンテナンス性が低いなどの課題がある。
- 1人のユーザーが複数のプロダクトを併用するのにデザインが不統一で、ユーザーにとって使いにくく不親切な状態になっている。
ユーザーに一貫性のある体験を提供したい
- タイポグラフィや配色、余白（スペーシング）やボタンのデザインなど、ユーザーインターフェイスのデザインや振る舞いを統一化したい。
- デザイナーもしくはフロントエンドエンジニアごとの制作方法や開発方法、技術力、経験の差、得意分野の違いなどによるユーザーインターフェイス品質の不統一を解消したい。
- 企業成長や所属デザイナーの増加に伴って、個々のデザイナーでサービスや企業のブランドに対する解釈が異なってきた。なので認識を合わせたい。
開発効率・メンテナンス効率の向上
- より開発効率を高めるため。
- メンテナンス性を高めるため。
- ルールを細かく意識しなくても使っていけるようにしたい。
デザインシステム構築の課題
対象範囲が広く、やることが多すぎる
- 共通デザインをいきなりつくるのは難しい。
- 全ての問題を一気に解決しようとしすぎている。
- コンポーネント以外のデザインルールは、まだデザイナーの脳内にしかない。明文化が必要。
コンポーネント管理を効率化する仕組みが必要（デザインとコードの整合性を維持）
- デザインとコードの両面から整合性を維持したルールが必要。
- 細部の仕様や設定を省略した結果、デザインやコードの整合性が維持できない。
- 変更差分の同期をどうやって取っていくのか？ より効率的な管理方法は？
- サービスごとに異なるフレームワークが使用されている。例えばサービスによってVueが使われているものとReactが使われているものがある。
時間がかかる
- 指針づくりに半年くらいかけた。
- 1年半経っても、ほぼ反映されていない。
- デザインシステム構築とプロダクト開発の2足のわらじになって、どちらかが止まってしまうジレンマがある。根本的な解決方法は見つかっていない。
デザインシステムの価値や必要性が組織に伝わりにくい
- 組織内にデザインシステムの価値を見えるようにしていくのが難しい。まずはトップダウンで進めている。
- 組織内の課題として、何らかのサービス開発や機能開発と比較されるとデザインシステム構築の優先度が低く見られてしまう。
- デザインシステムを改善していくチームの目標や評価は？
課題解決への取り組み
大まかな目標を決める・全体像を共有する
- デザインシステムのベースになる大目標（ステートメント）を決める。
- まずは70点を目指す。
- デザインシステムのゴールイメージや構成要素を視覚化して、チームで認識を共有する。
フェーズごとに範囲を絞る
- まずはCSSの共通化のみをおこなっている。
- まずはデザイナーとフロントエンドエンジニアの動ける範囲に絞る。バックエンドについては後で対応。
デザイナーとエンジニアの密な連携を
- Tailwind CSSを使用して、新規でユーザーインターフェイスを制作した。
- デザイナーとエンジニアで昼会を毎日実施して、デザインの変更差分を愚直に同期。
- コンポーネントごとにステージング環境で確認している。
デザイントークンの定義
- デザイントークン（最も小さな構成要素）を定義。
- やりたいことは全体の一部。課題は山積み。
- 少しずつやっていく。
デザインとコードの整合性を維持したい
- デザインとコードが同期されている状態が理想。
- チームのみんながプロダクトに集中できるようにしたい。
- Atomic Designはやめた。
根本的にAtomic Designは使用していないのかもしれないとも思いました。デザイントークンとして最小単位を定義してコンポーネント化（共通部品化）すれば、あえてAtomic Designのルールに沿う必要性は薄いのかなと思います。
デザインとコードをつなぐ役割を受け持つ
- デザインとフロントエンドの両チームに所属。
- ルールを配る役割を担う。
- デザインのルール決めやマークアップを対応。
トーンオブボイス
- サービスの人格を定義する。例えば言葉遣い。
- トーンを決めて共有する。
サービスの人格を定義するという考え方が面白いと思いました。このサービスでは「こんな言い方はしない」、「ユーザーに対するこの案内方法は不親切なのでNG」、「ユーザーのプライバシーをもっと配慮する必要がある」といった気付きにつながりやすくなるメリットがありそうです。
イラストシステム
- 社内にイラストレーターが在籍。
- イラストのシステム化も進めている。
- 社内向けにイラストのカタログを用意している。
デザインシステムの浸透を促すための取り組み
- 新規ページの制作時にデザインシステムに沿った開発を進める。
求めている人材
- UIデザイナー
- デザインエンジニア（デザインとエンジニアリングの橋渡し）
- フロントエンドエンジニア
組織によって呼び方や役職の定義に違いはあると思いますが、総合するとUI（ユーザーインターフェイス）デザイナー、フロントエンドエンジニア、もしくはその両方を担当する人材が各社で求められている印象です。「めちゃくちゃ募集している」とのことで、各社で切望されているようです。
求められる領域が広がるにつれて得意分野も広がっているようです。フロントエンドエンジニアは大きく2種類のタイプに分かれている印象があります。
- VueやReact、AngularなどのフレームワークやJavaScriptが得意で、よりシステム的に複雑で高機能なユーザーインターフェイス設計、コンポーネント設計、バックエンド連携に長けたフロントエンドエンジニア。
- CSSやアニメーション実装への理解が特に深く、デザインの再現性やきめ細やかさ、インタラクションの心地良さを高い品質で実現することに長けたフロントエンドエンジニア。デザイナー寄りな側面もあり。
両方を兼ねている場合や中間的なグラデーションもあると思いますが、どちらのタイプも需要が高く複数の組織で求められていると感じました。
質疑応答
人的リソース状況や最初の進め方は？
- フロントエンドエンジニアが12人在籍。
- デザインシステム構築はボトムアップよりも、トップダウンの動きに近い。
- 特に最初はトップダウンから始めている。
- デザインシステムに専属で1.2〜1.5人が担当。
- デザインシステムの中で細かく担当を分けて、プロジェクトごとにオーナーを割り当てている。
組織によって担当する役職や工数配分は異なっているようでした。デザイナーとフロントエンドエンジニアの連携が特に重要で、両方の役割を理解して兼任する橋渡し的な存在が求められていると感じました。
デザインシステムの構築・運用・アップデートで気を付けるポイントは？
- 全体像をイメージできるものを共有する。認識の共有。
- 他社のデザインシステムを参考にする。自社に合いそうなものを取り入れる。段階的に適用できるものが良さそう。
- Adobe（Spectrum）、SmartHR（SmartHR Design System）のデザインシステムが特に参考になる。
- とりあえずTailwind CSSを使ってやってみよう。
- デザイナーとエンジニアの認識共有のため、週1回で定例共有を実施。
- 完璧なものを目指さずに、走りながら進める。
複数プロダクトがある場合の進め方は？
- プロダクトを横断して合意を取りながら進めるのが良いか試験中。
- プロダクトごとにどこまで自由度を持たせるかを考えている。
- デザインシステムの設計者が一緒にプロダクトに入って、デザインシステムをアップデートしていく必要がある。
- かなりロジカルにつくる必要がある。
- 全体最適のために、なぜこうなっているか細かく言語化する必要あり。プロダクトごとの独自ルールを優先させないため。
デザインシステムやルールを運用していただくためには、細かくドキュメントとして明文化していくこと。デザインシステムの設計者がプロダクトに関わり、相互に意見交換やアドバイスしていく仕組みや時間確保が必要なのかなと思いました。
デザインと実装の技術的なアップデートをどうやっているか？ バッティングへの対応は？
- SSR（サーバーサイドレンダリング）は最低限にする。
- Svelteを使う。
Svelteについては名前を少し見たことがある程度でほぼ知らなかったので、新しい発見でした。
最後に
各社のデザインシステム構築における取り組みを学ぶ機会をいただけて、イベントの関係者の皆さまに感謝します。ちょうどデザインシステムを構築中なので共感することが多く、とても参考になりました。ありがとうございます。
例えば今進めているデザインシステムのプロジェクトでは、デザイントークン（最小の構成要素）の定義を優先して進めたり、効率化のためにTailwind CSSの導入を推奨していたりします。この判断が適切かどうかの材料としても、組織ごとの取り組みや意思決定について知る機会は貴重でした。
各社で共通する課題や悩み、解決方法や試行錯誤の過程にデザインシステム構築をより良く進めていくヒントが詰まっていると感じました。それらを今後に活かしたいと思います。
アーカイブ動画・イベント資料
