ガバナンスのトラップにはまらないためのデザイントークン活用

手段が変わっても問題は変わらない

ここ数年で、Design Tokens を用いてデザインと開発の同期を図る組織が増えています。生成AIと組み合わせることで、意味付けされたセマンティックトークンによる効率化が期待されるケースも少なくありません。Token の仕組み作りはボトムアップでできるのでハードルが高くありませんが、プロダクト開発と連携したガバナンスは一筋縄にはいきません。

プロダクト開発の要望や優先順位を踏まえて、デザインシステムとどう同期させるかは Design Tokens に特有の課題ではありません。 デザインファイルの UI ライブラリのような単純なものから、Storybook を使った開発連携まで対象が変わっても、「誰が決めて、どう反映するか」という問題は変わりません。

Design Tokens によるメリットはあるものの、それだけで従来からあったガバナンスの課題は解消されません。

プロダクトチームはプロダクトの KPI や OKRで評価されます。クロスプロダクトの一貫性で評価されることはありませんし、効果が期待できるなら、ガイドラインにないパターンが使いたくなる場合もあります。デザインシステムの採用にも追加や調整の手間がかかるため、機能のリリースを優先して対応することはありません。

何かを始めるなら、まずはボトムアップで着手する方が早く進みます。 自分たちの担当範囲であるUIライブラリや実装フレームワークに手を入れると、作業を速く進められます。 デザインシステムの初期段階であれば、採用コンポーネント数のような指標が有効です。しかし、それをデザインチーム唯一のKPIとして続けていると、プロダクト側とのインセンティブや優先順位にズレが生じます。その結果、コンポーネントの採用が進まなくなったり、運用が複雑化したりします。

運用モデルが有効と言われているのは「Federated Model」と呼ばれる、 プロダクトを担当するデザイナーと開発者が、デザインシステムチームに派遣されて連携しながら運用していくというものです。プロダクトチームの状況が見えやすくなることで、どのコンポーネントを追加・改善すればよいかの判断もしやすくなります。

ただ、Federated Modelは回避策に過ぎず、根本的な解決にはなりません。デザインシステムチームがプロダクトチームの文脈を理解する機会にはなりますが、その先の対応が不明確です。もしデザインシステムチームが引き続き「一貫したUIを維持する仕組み」を最重要視するなら、プロダクトチームが求める「ユーザーの成果をどう支援するか」とは乖離します。

AI を使った Design Tokens 活用でも、「何を使うか」は指示だけでは十分ではありません。「なぜこの選択がこの文脈に合うか」まで調整が必要ですし、その明文化のためにはガバナンスが不可欠になります。AI には大きな可能性を秘めているとはいえ、解決すべき課題は今までと大きく変わりません。

デザインシステムのガバナンスの目的が、「トークンの使い方をドキュメント化（もしくはAIが理解できるように）して一貫性を保ちやすくすれば、チームはより速くリリースできる」 という仮定に基づていることがあります。開発効率化や一貫性は重要とはいえ、ボトルネックがこれらが不明確なら、どれだけトークンガバナンスを整えても解決しません。ドキュメントの整った、しかし依然として速くリリースできないコンポーネントができるだけです。

長年デザインシステムのガバナンスが答えようとしている「デザインシステムとプロダクトニーズが対立するとき、誰が判断するのか」という問いは、ほとんどの組織で答えをもっていません。「良い感じに、議論しながら決める」といったルールでは、判断の一貫性が失われ、次第にプロダクトとデザインシステムの差が広がっていきます。

例外があるとしたら「デザインシステムがプロダクトそのもの」である場合。Shopify、Airtable、Softr、Kintone のようなプラットフォーム企業は、デザインシステムがプロダクト開発だけでなくユーザーも扱う大事な道具になるので、プロダクト戦略とデザインシステム戦略がアラインしやすいです。言い方を変えるなら、デザインシステムそのものが売り上げに直結しています。

#372 AIもデザインシステムも銀の弾丸ではない（sakitoさん）

http://yhassy.heteml.net/mp3/automagic372.mp3

Yasuhisa HasegawaYasuhisa Hasegawa

多くの組織でデザインシステムがプロダクトそのものではない場合、問いは「プロダクト開発のボトルネックが本当に実装レイヤーにあるのか？」に移ります。 現場の効率化が進んでも、開発工程全体の観点で見たときに、 「コンポーネント採用数」で成果を示す。デザインシステム評価として、これは分かりやすい指標です。ただ、デザインステムが成長期に差し掛かっているにもかかわらず、自分たの効率化だけを物差しにし続けると、問いはいつも「もっとってもらうには？」に戻ってきます。使ってもらうための座組や、複雑な判断ツリーを作るといった活動を何年も続いているのではないでしょうか。

デザインシステムに過度な期待をしないほうがいいと言われて久しいです。ただ、Design Tokens や AI への注目が高まったことで、期待は形を変えて再び膨らみ始めているように見えます。技術や手段は新しくなっても、「仕組み化すればうまくいく」という前提は変わっていません。これは以前から繰り返されてきたトラップと同じ構造です。手段ではなく、前提そのもの疑うところから始める必要があるのではないでしょうか。

組織の文脈を置き去りにしたデザインシステムの罠

デザインシステムの成功は手段の選択に大きく左右されるわけではなく、実際には計画の不備が失敗の原因となることが多いです。

Yasuhisa HasegawaYasuhisa Hasegawa

探索ツールから始めてみる

先述したように、Design Tokens によるメリットはありますし、様々な可能性を示しています。最終ゴールは、プロダクションインフラとして位置づけですが、そこへいきなり突き進もうとするとプロダクトチームとの連携で悩み始め、使えるモノができる前に仕組み化の議論が増えてしまうことがあります。

最近、試し始めているのが Design Tokens をつかったプロトタイプ制作です。今でもバイブコーディングでプロトタイプを作っている方はいますが、 Design Tokens を活用することで、早期に「自社プロダクトっぽい見た目」のプロトタイプでアイデア発散ができます。詳細なところまで Design Tokens を定義していなくても、Semantic Tokens がある程度揃ってさえすれば『らしい』デザインを出力することができます。きちんと Design Tokens が作られることを待つことなく、現場で検証できるのも魅力です。

ここで重要なのは、ただ Design Tokens を使うだけでなく、判断の記録を残すことです。コンポーネントをはじめ、色の使い方、スペース、配置など、どのように出力したかログを残しています。どういう文脈（企画案）で、どんなコンポーネントが必要になるのか。間違えやすいデザインの判断ポイントはどこかも見えてきます。記録情報が プロダクションインフラとして Design Tokens を活用する際の貴重な資産になります。

Design Tokens の可能性は、制作効率化だけにとどまらない思います。トークンという共通の基盤があることで、制作・実装だけでなくプロダクトチーム全体が貢献しやすくなります。

また、仕組みの作り方にも見直す余地が生まれます。インタビューや会議で「こうしてほしい」と言れたことをもとに設計するのではなく、実際にどう使われてるかという行動から積み上げていく。言葉ではなく行動を起にすることで、長年の課題だったアライメントに少しずつ近けるのではないかと思います。