負債になりにくいCSSを デザイナとつくるには？ あるいはユーティリティファーストCSSへの入門 2025.01.07 pixiv Inc. f_subal

2 今のお仕事とか ● 2016年4月 ピクシブ株式会社に新卒入社 ● 2018年から pixivFACTORY の開発 ● フロントエンドエンジニア → テックリード → エンジニアリングマネージャ → PdM ● 2020年〜2022年デザインシステムの開発を兼任 ○ 2022年に charcoal として OSS 化 ○ デザインシステム初期メンバーで、OSS化プ ロジェクトを進行した人 ● 2024年に『Tailwind CSS実践入門』を出版 @f_subal ピクシブ株式会社

3

4

今日お伝えしたいこと ● コーディング規約だけでCSSの負債を防ぐのはかなり厳しいと思う ● デザイナの思想が弱いと土台が弱くなるので、その上にルールを構築してもあん ま堅牢にならないのでは、という話 ● なんかデザインシステムをやると良いと聞いたけど、どう技術選定すべきか ○ なぜ Tailwind CSS がその用途で便利なのか ● Tailwind CSS を使って負債になるのはどのようなケースか ○ 結論「デザインシステムを作ろうとしてないとこほど Tailwind が負債化す るのでは」という主張をします ● ※ 割と「長く続けるサービスにおけるCSS」前提の話になると思います 5

CSSにおける負債とはなにか 6

デザイナ = ドメインエキスパートである ● スタイリングの負債 ≒ デザイナの認知と書かれたコードが乖離すること ● 構造的にはドメインと実装の乖離みたいな話と同じ ○ DDDに例えると、デザイナはUIにおけるドメインエキスパートである ○ 個々のデザインはそのドメインにおけるデザインの言葉で書かれるべき ● 「ここのページのここのmarginを5pxに直してください」「それってHTMLでい うと div.index-page-card-wrapper のことですか？」「さぁ？（知らん）」 ○ これはUIの言葉がデザイナとエンジニア間で一致していない状態 ● 本当は「このページの 同士の間隔を space-s にしてください」ぐらい の会話がしたいはず ○ デザイナ側が5pxみたいな用語化されてない言葉で喋るのも問題がある 7

コーディング規約は乖離を防がない ● CSS設計論は命名のルールを敷いてくれる ○ 書く人が書きやすくなったり、他のクラスと衝突しにくくなったりする ● が、別に頑張って命名したところで「用語」とか「共通言語」になることはない ○ プログラマしか知らない変数名みたいなもの ○ そういう命名ルールにも意義はあるんだけど、デザイナの認識との乖離を防 ぐのには役に立たない ● 共通コンポーネントや、色の名前や文字の大きさの名前は「共通言語」になる素 質がある ○ なのでスタイリングの設計には、これらを協力して作り上げることがベース になってるほうが良いはず 8

デザインシステムをつくる 9

「デザインシステム = 契約」である ● デザインシステムは一般に色・スペーシングなどのルールを作ったり、コンポーネ ント集を作ったりすることぐらいに思われている ● なぜこれをやるのかというと「共通言語」を作るため ○ デザイナが Figma で Black 50 という色で文字を書いていたらそのまま .text-black-50 というクラスがかける方が良い ● 「たまに使う便利な定数やコンポーネント集」はデザインシステムではない ○ なぜなら強制力がないから ○ 「Figmaでもコードでも、ここに載ってないものが使われてたらおかしい」と いう含意があるべき ○ → 「デザインシステム = デザイナと開発者が守る契約」である 10

11 1.デザイナーが 　Figmaで色名を指定してるのを見る 2. 「VSCodeでsurface3って打ったら その通りのクラスあったわ！！」 超簡単！！！！！！！！

12

13 https://gihyo.jp/article/2024/01/tailwindcss-design-s ystems-01

なぜTailwind CSSを使うか 14

15 ● デザイナがFigmaで定義したトークン を一通りthemeに記述する ● そうすると色、スペーシング、角丸 などのクラスが全部できる ● Figma に出てくる色名を適当にタイ ピングすると補完でクラスが出る状 況になる！！！ ● DDDは思想だけあって実装はみんな 我流だが、デザインシステムには Tailwind というツールがある！ デザインシステムの フレームワーク

16 拙著『Tailwind CSS実践入門（技術評論社）』第９章より

17 https://speakerdeck.com/fsubal/tailwind-csswoben-qi-deka sutamaizusurufang-fa

Tailwind CSSを負債化させない ためにはどうすればよいのか 18

デフォルトテーマで自滅してる人多くない？ ● 聞いたことある苦情の例 ○ Q. Figma を見ながら Tailwind のサイトで近い値を探すのが不毛 ■ A. 状況がおかしい、テーマを自分たちでカスタマイズしないのが悪い ○ Q. ちょっと変わった値が出るとすぐ 〇〇-[〇〇px] みたいになる ■ A. テーマとして正常な値を決めてデザイナと握ってないのが悪い ● なんとなく「Tailwind を使う = デフォルトテーマを使う」と思い込んで自滅し ている人をよく見る気がする ○ が、それは外から適当なデザインシステムを借りてるのと同じなので、使い 方が Bootstrap から進歩してない ○ あなたに必要なのは Bootstrap か MUI かもしれませんよ 19

Tailwind のデフォルトテーマを忘れよう ● あなたの Tailwind CSS が負債化するのは、あなたのチームの誰もテーマの内容 に責任を持っていないから ○ エンジニア「なんか知らないけどデザイナはここに載ってるテーマに沿って 作ってくれるんでしょ」 ○ デザイナ「なんか知らないけどここに載ってない色を使うとエンジニアが嫌 がるらしい」 ○ → 破滅、終わり ● もしデザイナが spacing を 4、8、16、24、40… に絞りたいと思うのなら、そ れしかマークアップで使えないべき（すべてのトークンは union 型だ） ○ Figma 上のルールと tailwind.config.js が一致するようにカスタマイズする ○ もし理由があって他の値を使うのならデザイナは毎回説明すべき 20

あとはコンポーネント設計で頑張れ ● React や Vue.js などの素晴らしいポイントは、「コンポーネント設計論だけあ ればCSS設計論ってそこまで考えなくて良くない？」という空気を作ったところ にある（極論） ○ 厳密には CSS Modules や CSS in JS の功績だが ○ 拙著『Tailwind CSS実践入門』１章はそういう話をしている ● 影響範囲がわかるように十分コンポーネントを小さく切り、クラス名が衝突しな いような工夫さえできれば、それ以外はあんまいらない ○ そしてTailwind CSSを使ってる場合クラス名が衝突するかは考える必要が ない ● React を使ってなくとも、HTML を partial に切って同じ工夫をした方が良い 21

Tailwind はこの辺の戦略と無関係な理由 で褒められがち ● 「Tailwind CSS が AI と相性が良い」という話は正直かなり怪しい ○ よくよく根拠を聞いてみても「有名なCSSフレームワークはクラス名が学習 されてるから生成しやすい」以上の内容がない ■ つまり、「一般に自分の書いたCSSよりはCSSフレームワークのクラス の方が生成しやすい」と言っているだけ ■ その理屈だと Bootstrap も同じぐらい AI と相性が良いのであまり意 味のない主張 ● v0 で Tailwind を採用したのは正しい技術選定だと思うが ○ それはできたものをカスタマイズがしやすいからがメインの理由では？ 22

まとめ ● デザイナーはサイトのUIデザインにおけるドメインエキスパートである ○ 少なくともそのように振る舞うことを期待すべきである ● CSS設計はデザインのドメイン理解とコードの乖離を減らすものである方が良い ● デザインのドメイン理解とコードの乖離を減らす手法がデザインシステムである ○ トークンやコンポーネントの定義は、ドメイン用語の制定みたいな感じ ○ DDDやマイクロサービスが組織論であるのと同じぐらい、デザインシステ ムは組織論（役割分担の設計に妙味がある） ● Tailwind CSSの良さは、トークンをベースにマークアップができること＋共通認 識に寄与しない命名を避けられること ● この発想でTailwind CSSを使わないせいで負債化するのは多分しょうがない 23

負債になりにくいCSSを デザイナとつくるには？ あるいはユーティリティファーストCSSへの入門 2025.01.07 pixiv Inc. f_subal