こんにちは。株式会社ペライチ のフロントエンドエンジニア藤田です。
デザイナーやサーバーサイドのエンジニアと連携を取り、アプリケーション内におけるユーザーと関わる部分の機能開発や改善が普段の主な業務内容です。
今回はその中でも年々課題感が増している CSS 設計周りのこと、その課題解消の一手として Tailwind CSS を導入してみたことについてまとめてみました。なにかの参考にして頂けたら幸いです。
CSSにおける課題
皆さんご存知の通り、現状 CSS はグローバルスコープな言語です。
グローバルスコープということはつまりスコープが無いということなので、何も考えないと、意図しない要素にスタイルが適用されてしまったり、他のセレクタと競合してしまったりします。
そのためファイルの追加や変更をする際は、影響範囲について慎重に考慮する必要が生じます。大規模なプロジェクトでの CSS 保守性を担保するためには多くの課題があります。
アーキテクチャ
再利用性や保守性を担保しつつ効率よく CSS を運用していくにはどうすればいいか。
そんな課題を解決する手法として、命名規則やディレクトリ構成が定められた CSS アーキテクチャと呼ばれるものが数多く考案されていきます。先人たちの知恵の結晶ですね。
有名なものでは BEM、OCSS、SMACSS、FLOCSS、RSCSS などがあり、それぞれに特徴や得意・不得意があったりします。
ペライチのCSSの現状
（自分がジョインする遥か昔から）ペライチも前述した CSS の設計に苦しんできた会社の１つであり、今日まで思考錯誤を繰り返しています。
ペライチの CSS は FLOCSS の思想をベースに、基本的に次のようなレイヤーで構成されています。
- Foundation - reset/mixin/normalize/base/vendor...
- Layout - header/main/sidebar/footer...
- Object
- Component - grid/button/form/media...
- Projects
- peraichi - mypage/login...
- checkout
- ec
- editor
- Utility - clearfix/display/margin...
命名規則は、BEM システムのシンタックスである、Block、Element、Modifier に分類して構成される規則を採用しています。
（JavaScript で操作されるような「状態」を表すような Modifier については、SMACSS の State パターンの命名を拝借しています）
しかし、組織のスケールに伴い上記のままではスピード感を持った実装が難しくなってきているのが現状です。
全体の UI/UX を監修するデザイナーがジョインし、プロジェクトを跨いだデザインの統一やユーザー要望による UI 改修が年々増えてきて、自前のコンポーネントを拡張してくのでは対応しきれない箇所がちらほら出てきました。
専任を配置する余裕がなかなか無く、スケール感も読めない中での設計は難易度・不透明度が高く、命名規則やディレクトリ構成だけではクリアできない問題に直面しています。
Tailwind CSSの導入
そんな中、大規模なリデザイン案件が発生したので、前述の課題を解決する１つの手段として、CSS フレームワークの検討をはじめるようになりました。
デザイン要望の再現性と、それでいてスピードを落とさずに開発をする必要があったので、ユーティリティファーストである Tailwind CSS を試験的に導入してみようという運びとなりました。
導入方法や詳細に関しては数多の記事が存在しているので、ここでは省略させていただきます。
（ちなみに弊社での導入環境は Nuxt.js です）
入れてみて感じたメリット・デメリット
メリットとして大きく感じるのは、やはり命名や設計にコストを割かなくて良くなった点や、デザインの再現性などです。
アサインされているエンジニアも少なく、ガシガシ画面を作っていく必要があったので、その点はかなり助かりました。ユーティリティファーストなので、細かいデザインパターンのニュアンスに対応でき、且つ複数回使われる際はコンポーネントとして閉じ込められるので、保守性や再利用性も高いように感じています。
一方、デメリットも感じました。
ほうぼうで言われているように、ユーティリティファーストという性質上付与するクラスが大量になるので view ファイルが複雑化しがちです。レスポンシブ対応やマウスアクションによるスタイルの切り替えの際にはかなり増えてしまいます...。
（以下はメールアドレスの入力フォームのサンプルです）
<input type="mail" placeholder="メールの件名を入力してください" class="w-full rounded border border-gray-300 py-2 px-4 leading-none transition outline-0 tracking-widest focus:border-transparent focus:shadow-input-focus" required>
既存のユーティリティクラスを独自のカスタム CSS として定義できる@applyが用意されていたりしますが、クラス名を考える必要があるので、今回感じた利点と少しズレてしまうため現状の使用は見送っています。
あとは用意されている大量のクラスをふんわり覚えないとけないので、安定して運用されるまでの導入コストもある程度かかる気がします。
まとめ
Tailwind CSS を効率よく運用していくにはまだまだ試行錯誤が必要そうですが、開発スピードやデザインの再現性が保証されていけば、他プロジェクトでも使用していきたいと考えています。
移りゆく流行りや顧客要望が次々アップデートされる中で、デザインやそれに付随した CSS 周りの問題はどのプロダクトでも起こりうることかと思われます。
CSS において銀の弾丸は（今はまだ）存在しないので、ペライチも絶えず模索していく必要がありそうです。
採用情報
現在エンジニア募集しています！
▼ 選考をご希望の方はこちら（募集職種一覧）。
▼ まずはカジュアル面談をご希望の方はこちら
募集中の職種についてご興味がある方は、お気軽にお申し込みください（CTO がお会いします）
Discussion