見出し画像

TailwindCSSをデザイナーが実務で使ってどうだった？

ウエダ カズキ


この記事は「株式会社エイチームフィナジーAdvent Calendar 2020」21日目の記事になります。
本日はWebデザイナーの@kazkiuedaが担当いたします！

せっかくアドベントカレンダーに参加するのであれば今年の振り返りも兼ねて、今年前半に新規事業（ナビナビ保険）で導入したTailwindCSSの手応えを感じてる部分と今後の課題や展望について皆さんにシェアできたらなと思っています。

ちなみに実際に制作/運用しているサービスはこちらになります。

ちなみに、拙文ですが以前TailwindCSSについて書いた記事はこちらです。
「TailwindCSSって何だ？」と思われた方は公式サイトと一緒にこちらを参考にされると、私が導入前に抱いていたメリットなどを掴みやすいかもしれません。

なんでTailwindCSSを導入したかったのか

コーディング規約に課題を感じていた

弊社ではBEMを使った独自のコーディング規約を作り、大部分の事業では現在もそのルールを元に運用されていますが、基本的にルールを増やしていくことで不具合を最小限にするというアプローチだったので運用していくうちにルール自体が物凄く増え、コーディングしてもらう方への教育コストが大変になっていくという新たな課題を抱えてしまっていました。

既存の規約の問題点を解消する為には、「スピード⇄不具合」のトレードオフの関係を断ち切る必要があるなと感じていました。規約を作ることで達成したいのは「不具合が起こらない・負債を出さない環境を作る」ことにあるのは事実ですが、ただ単にスピードが落ちるだけでは事業の中で理解が得られにくいのも事実です。

ですが、そんな簡単に解決できる話ではありません。既存手法の改善では厳しそうだなと思った私は、考え方を根本から変えないと解決できないのでは？と考えました。

具体的に、以下のことが実現できないか考えました。

・CSSファイルを管理しない
・ルールを作らない

既存のCSS設計の問題点

CSSを管理する上で大変なのは、大体の場合、CSSの変更はHTML構造の編集とセットで、特に他のページから共通のUIを持ってくる際にいろいろなことを考えなければいけないことです。例えば、

・既存ページの他の要素へ与える影響はないか？
・過不足なく該当箇所のソースコードを移植することができているか？
・修正は必要ないか？（marginなど）

などで、とにかく気を使います。
規約ではなるべくこういったことに悩まなくていいようにBEM記法やマルチクラス禁止などルールを定めていましたが、メンバー間で厳密に運用することが難しく、マルチクラスを禁止することで却って同じようなBlockクラスを大量に作ってしまい、保守に苦労するケースが多発していました。

また、意外とBEMで保守性の高いCSS設計をするのは難易度が高いものです。保守でソースコードを拡張していく中で、例えば経験の浅いメンバーが触ると途端に壊れてしまうということも結構起きました。

ルールはメンバー全員が運用できて初めて意味を為すというのを実感した瞬間でした。

自サービスに適した設計とは？

以上のような経緯から、新規事業でのCSS設計について考えた結果次のような条件を満たしたものにしたいなと考えました。

・「再利用性」より「捨てやすさ」
・規約ベースである
・ルールレスである

再利用性は高いに越したことはないのですが、再利用性の高い汎用的なUIパーツを実装/運用することは結構難易度が高いです。自分だけが触るのであればまだしもいつ担当が変わるかもわかりません。そこで、あえて再利用しない前提でスタートしようと決めていました。

次に、規約ベースであること。何らかの形で幅の単位やカラー、フォントサイズなどを管理して個人の実装の癖が出にくくしたいなと思っていました。
当初はルールがあるならここで制約を設けて、難しいルールを守らなくても勝手に秩序が保たれる仕組みを作ろうと思っていました。

最後に、規約自体を撤廃しルールレスにすることです。今まで起こした不具合を対策しているルールなのになくすのはおかしいと思われる方も多いかもしれませんが、自分の中で「追加されたルールのほとんどが再利用性を下げて影響範囲をそのページ内に限定すれば起きない」と確信していたので、撤廃することにしました。
またパートナーに作業依頼をする際に、作業をしていただくハードルが高すぎて依頼できないというケースも多かったので、それを解消したいという思惑もありました。

以上の要件を満たす方法をいくつか考えましたが、これらを満たし、プラスReactでもRailsでも同じルールで運用できそうなのはTailwindCSSだけだったので、この時点で、ほぼTailwindCSS導入でいこうと決めていました。

実際に導入してみて

うまくいった点

CSSファイルを（一部例外を除き）全廃しました。TailwindCSSの特徴として予め準備されたユーティリティクラスをView側で指定することでスタイルを当てることができるというのがあります。今回そちらを使うことでViewファイルのCSSを全廃し、一部base.scssの記述もTailwindCSSの形式にしたことで、記述行数が大幅に減りました。

以下は一例ですが、DOM構造にスタイルがセットで紐づいていることでこのまま他ページに移植できますし、ユーティリティクラスでの記述によってセレクタ の優先度による副作用も起こしません。

// view側はこんな形で記述しています
<div class="text-gray-700 text-xs hidden md:block">
  <%= link_to '執筆者・監修者紹介', cms_authors_path, class: 'px-4 py-2 rounded-full text-gray-700 transition-colors duration-200 hover:bg-gray-200' %>
  <%= link_to '運営会社', cms_company_path, class: 'px-4 py-2 rounded-full text-gray-700 transition-colors duration-200 hover:bg-gray-200' %>
  <%= link_to 'お問い合わせ', new_cms_contact_path, class: 'px-4 py-2 rounded-full -mr-4 text-gray-700 transition-colors duration-200 hover:bg-gray-200' %>
</div>
// base.scssには以下のように書いてます
html {
 @apply leading-normal text-black bg-white tracking-wide antialiased break-words;
 font-family: system-ui, -apple-system, BlinkMacSystemFont, 'Hiragino Sans',
   'Helvetica Neue', 'Verdana', 'BIZ UDPGothic', 'Meiryo', 'Apple Color Emoji';
}

変更が実質Viewファイル内に閉じているので、他のページへの変更を気にしなくていいのはすごく楽です。これだけでやりたかったことの80%は達成されたと思います。

また、ユーティリティクラスを管理することで制約ベースのコーディングを実現しました。基本的にユーティリティクラスのみでのコーディングとなるので、表記揺れや癖がでにくく、コーディングルールがほぼなくなりました。不安視していたTailwindCSS独特の記法も、チートシートと一緒に5分ほどレクチャーするだけで問題なく使ってもらえてるようで今のところ問題なさそうです。

余談：なぜCSSファイルを排除したかったのか？

結論から言うと、CSSファイルが生まれると以下2つの課題が生まれるからです。

・クラス名単位でプロパティを指定することで、スタイルの優先度の問題が発生する
・「一部品に対して一種類のスタイル」の原則が維持できない

CSSファイルにスタイルをまとめる場合、記述方法的に行数を圧縮できるというメリットはありますが、展開されたCSSファイルは今までの形と変わりません。当然ですが同じプロパティが異なるクラスに存在し、同じタグ内で同時に指定されている場合、一方が他方を打ち消す関係になります。なので、「必ずスタイルが当たる」という前提が崩れてしまうわけです。
なお、これはTailwindCSSでカスタムクラスを作る場合も同様です。

// 例えばこういうclassがscssファイルにあったとする
.btn {
  @apply text-sm font-bold p-4 rounded-full;
}
.btn-cta {
  @apply text-lg p-2 rounded-lg;
}
....
//classの読み込み順によって適用されないプロパティが生まれる
<div class="btn btn-cta">送信</div>

この原則が遵守されているかどうかで、コーディングや検証の際に精神的負担がかなり違ってきます。遵守されている場合、確認すべき箇所が少なくて済むからです。これにより、検証に欠ける工数を限りなくゼロにすることができ、制作に掛ける本質的な時間を増やすことができます。これは私が日々保守運用する中で実感していることで、「影響範囲が100%把握できている」と確信を持てるだけで気持ち的にすごく楽ですし、何より手間も省けます。

うまくいかなかった点

最初から想定してた点として、TailwindCSSでは擬似クラスを扱えないので複雑なCSSアニメーションなどを作ろうとすると結構大変な場合があります。ただ触っていて感じるのは、CSSであまり複雑な記述をすると保守の問題だったり経験が浅いメンバーが困ったりすることもあるので、そういった記述を防ぐ役割は果たしているかもしれません。
現在やむなくこういった実装をする場合はcomponent.scssに記述していますが、可能なものからカスタムクラスにすることでできるだけcomponent.scssが肥大化しないように気をつけています。

また、独自にクラス名を付けないということで、一括で検索をしづらいというデメリットも生まれました。正直全体を一括で変えるというケースがほとんどないので現状のままでも運用できますが、今後対策が必要そうです。

加えて、これも想定していたし厳密にはTailwindCSSのデメリットではないですが、CSSファイルへの記述を限りなく薄くしている為、同一パーツの繰り返しに対して同じスタイルを複数回当てなければいけないケースが発生しています。
以下はfooterコンポーネントの一部です。同じ記述が繰り返されています。

<%= link_to 'FP監修カードローン情報サイト なるほど！カードローン', 'https://naruhodo-cardloan.com/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>
<%= link_to 'キャッシング比較・情報サイト ナビナビキャッシング', 'https://a-cashing.com/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>
<%= link_to '住宅ローン比較・情報サイト ナビナビ住宅ローン', 'https://navinavi-mortgage.com/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>
<%= link_to 'おすすめクレジットカードの比較ならナビナビクレジットカード', 'https://navinavi-creditcard.com/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>
<%= link_to 'おすすめ法人カードの比較ならナビナビ法人カード', 'https://www.navinavi-corporatecard.com/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>
<%= link_to '通信費・家計見直しサイト ソルディ', 'https://www.soldi.jp/', class: 'text-xs text-black inline-block p-3 sm:p-1 underline', target: '_blank', rel: 'noopener' %>

もうお気づきの方もおられるかと思うのですが、繰り返し記述に関してはUIパーツのコンポーネント化で解決できそうです。が、Railsで作っている部分では速度低下の懸念からPartialファイルの多用を避けていました。

Railでは今後ActionView::Componentというコンポーネントを使えるようになっていくようなので、本格運用されるようになればこちらに各部品を移していく形になりそうです。

意外だった/今後の課題だなと思った点

作業場所がViewファイルに限定されたことで作業がシンプルになり、例えば「このページのこのパーツを移植したい」といった依頼があった時にデザイナー以外でもやろうと思えばできるようになりました。もちろんデザイナーの業務の一部でもあるのですが、こういった業務を誰でもできるものにしていくことでデザイナーがやることで真価を発揮できるタスクに集中できるというのは、意外な気づきでした。

また、いままで何となく使っていた技術（PostCSSやCSSプロパティの細かい挙動の違い）への理解が深まったのも嬉しい誤算でした。

今後の課題は、CSSを書かざるを得ないケースにどう対応するかということと、設定ファイルを作り込めば作り込むほどどんなユーティリティクラスがあるかわかりにくくなるので、自前でチートシートを作る必要があるかなということですね。最終的にはコンポーネント単位で管理して自前のTailwindUIみたいなライブラリにしていければいいなと考えています。

さいごに

今回実務で導入前にプライベートでTailwindCSSを使った上で、ある程度手応えを掴んだ上で事業に導入したので、得たい結果はしっかり得られる形になりました。ですが、事業に入れてみて感じたのは、個人で触るプロジェクトと違いあるジレンマが起きた時に潔く諦めて無理に作らないみたいなことができないケースも多々あって、その都度どうしようか考えることも多いです。上で偉そうに書いてきましたが、正直日々触る中で出てくる課題に対してチャレンジし続けている形になります。

同じように奮闘されている方がおられたら是非ディスカッションして色々聞いてみたいなーと思うので、よければコメントいただけると嬉しいです。

あと導入に際し感じたのが、CSS周りの改善はデザイナーだとルールで改善しようとしがちだし、エンジニアだとCSSを触らないので現場レベルでユースケースを考えづらいということで、意外と誰も手をつけていない部分なのかもしれないなということでした。
CSS設計に興味があって同じような課題を社内に持っている、特にインハウスのデザイナーの方がいれば、案外活躍できるチャンスかもしれないです。

今後の展望として、今Figmaで管理しているデザインデータとTailwindCSSのルール、そして実際のソースコードとの高いレベルでの統合と、アクセシビリティを損なわない仕組み作り（アクセシビリティチェックの自動化）などにも挑戦していきたいと思います。

ここまでご覧いただきありがとうございました。

この記事が気に入ったらサポートをしてみませんか？