はじめに

こんにちは。

私はディップ株式会社で 10月にリリースしたスポットバイトルのユーザー向けサイトの開発に携わっています。本記事では、この開発で Tailwind CSS を導入した経緯や、使ってみて感じたこと、Tailwind CSSに感じていることなどを私個人の視点でざっくばらんにご紹介したいと思います。

導入した経緯

まず今回の開発でスタイリング手法を決定するときに、

クラス名の命名の手間をなくせること
デザインシステムからの逸脱を防げること

の 2点に大きな利点を感じて Tailwind CSS を採用しました。

命名の手間を省けること

まず1点目、クラス名の命名の手間をなくせることについてです。

これまで私の開発チームでは SCSS を使って、要素+連番という形でクラスを命名していました。

<div class="bg01">
    <div class="pt01">
        <ul class="ul01"></ul>
    </div>
    <div class="pt02">
        <h1 class="pt01"></h1>
        <span class="span01"></span>
    </div>
</div>

bg01, span01のような 要素+連番 というような命名は、セマンティックさに欠けますが、機械的に命名できるので、命名で悩まされることは少ないです。一方で使い回しが難しく、連番で命名しているが故に CSS がなくなったら、空き番号を作るのか、詰めるのか、など扱いづらさがありました。

その点 Tailwind CSS は、事前に定義されたユーティリティクラスを使うため、個別にクラス名を考える必要がなくなります。これまでの命名規則を鑑みると、命名の手間を省き、再利用可能な CSS として扱える Tailwind CSS のメリットは大きいと感じました。

デザインシステムの逸脱を防げること

次に2点目、デザインシステムからの逸脱を防止できることについてです。

開発がスタートする際にデザイナーの方に、どのようにデザインしていくかのお話を聞く機会を頂きました。そこですでに色、フォント、スペーシングなどプロジェクト全体で使用されるスタイルが整っていました。色やサイズの命名も詳細に定義されていたため、このデザインシステムの内容を tailwind.config.js に反映すれば「Figma に書いてあることを見て、同じ名前の色、サイズを選択する」ということが実現できると感じました。
今回の開発において、デザインシステムの逸脱を防止できる Tailwind CSS のメリットは大きいを感じました。

使用していく中で感じたこと

導入する前にメリットと感じていた 2点は開発を進めていく中で強力なメリットだと感じています。
一方で、使用して感じたこともあったので紹介します。

文章構造とスタイルをコロケーションできることによって認知負荷を下げられる

1つ目は、文章構造 (HTML) とスタイルをコロケーションできることによって認知負荷を下げられることです。

Tailwind CSS は HTML の構造とスタイルが同じ場所にあるため、どの要素がどのスタイルを持っているのか一目でわかります。またデザインの変更が必要になったとき、CSS を探し回る必要がなく、HTML のなかで直ちに変更できます。

また今回 GraphQL を採用しており、GraphQL のクエリやフラグメントもコンポーネント内にコロケーションしています。そのため、Tailwind CSS と GraphQL フラグメントのコロケーションにより、コンポーネントがどんなデータを取得し、それをどのように表示し、どのようなスタイルが適用されるかが一目で分かりました。

スタイル変更時の CSS の肥大化を防止できる

2つ目は、スタイル変更時の CSS の肥大化を防止できることです。

通常の CSS だと、とある変更が他の要素にどのように影響するのかが分かりづらいです。そして結果的に影響範囲が分かりにくく、不要な CSS が残ったりデグレを発生させてしまったりすることがあります。

一方、Tailwind CSS はユーティリティクラスが直接要素に適用されるため、影響範囲が明確になります。また Tailwind CSS には、ビルド時に未使用の CSS クラスを削除する仕組みがあるので、不要な CSS が増え、CSS が肥大化することを防止できます。

今回はスクラムで新規開発を行っており、デザインや仕様が変わることは多々ありました。その中で変更に強い Tailwind CSS は強力なメリットだと感じました。

可読性の悪さはあまり感じない

Tailwind CSS はよく「クラスが長くなって可読性が低下する」ことがデメリットとして挙げられますが、個人的にはそこまで気にならなかったです。

むしろ、スタイル (Tailwind CSS) と文章構造 (HTML) がコロケーションされていることで、スタイルの適用範囲が分かりやすくなりますし、クラスを冗長に書き連ねることが変更容易性を生んでいる点だと感じています。
クラスが長くなって可読性が悪いと感じる場合はコンポーネントの粒度が適切かどうかを疑う必要があると思いました。

また、ESLint のプラグインである eslint-plugin-tailwindcss や VSCode 拡張機能の Tailwind Fold を使ってクラスの整列、並び替え、折りたたみをすることができます。

また Class Variance Authority (CVA) や Tailwind Variants のようなライブラリを活用して、スタイルの管理を楽にすることもできます。

これらを取り入れることで、Tailwind CSS の変更容易性の良さを活かしながら、可読性の低下を改善することはできると感じています。

Tailwind CSS が負債になったときの不安

技術選定をするときには、その技術が今後もメンテナンスされ続けるかどうかを考える必要があります。Tailwind CSS に関しても、1〜2年でメンテナンスが止まるとは思っていませんが、それでも「もし開発が止まったとき」のリスクは頭の片隅にあります。

特に Tailwind CSS は独自性が高い分、他の技術へのリプレイスが簡単ではないです。また公式の VSCode 拡張機能の Tailwind CSS IntelliSense のメンテナンスが止まった場合も開発体験は大きく損なわれるので、そうなるとTailwind CSS自体が負債になると思います。

これは Tailwind CSS に限った話ではなく、どの技術にも言えることですが、その技術が「負債になるリスク」そして「リプレイスのコスト」を考慮しつつ、技術を採用することで得られる生産性の高さやメリットを天秤にかける必要があると感じました。

これから

Tailwind CSS を導入したことで、開発のスピードを向上させることができ、機敏に修正に対応することもできました。一方で Tailwind CSS の思想を理解して、使う必要性を強く感じました。明確なルールを定めて無法地帯にならないよう努めていきたいです。

また、現在 Tailwind CSS v4 のベータ版がリリースされています。v4 にアップデートできるよう準備を進めておきたいと思います。