CSSの命名規則、どこへ向かう？BEMからTailwind、そしてshadcn/uiへ
目次
1. はじめに：2020年、Web制作会社でのはじまり
私がWeb制作の世界に足を踏み入れたのは2020年4月。最初に入社した制作会社では、コーディング規約というものがあることを教わりました。
「BEMやSMACSSなど、いろいろな命名規則がある」と言われ、正直なところ最初は「え、これら全部のルール覚えないといけないの…？」と戸惑ったのを覚えています。実際にはその中でもBEMを採用していたように記憶していますが、はじめはその命名規則を覚えることで精一杯だったような記憶もあります。
2. BEM・SMACSS全盛期、命名との格闘の日々
当時よく使われていたのが「BEM（Block, Element, Modifier）」という命名ルールです。
たとえば以下のようなクラス名になります。
.card__title–highlighted
このように、コンポーネントの構造に沿って命名することで、スタイルの責任範囲を明確にしようという考え方でした。
ただ、構造が複雑になるほど、クラス名もどんどん長くなり、最終的には何を表しているのかわからないような“クラス名の爆発”が起こることも…。
さらに、社内で定めた命名ルールには bl- や ly- といった接頭辞がつけられており、
「bl は block、ly は layout の略」などと説明されたものの、それが厳密に使い分けられていたかというと、なかなかそこまでうまくできなかったことも覚えています。
また、社内ルールに従った命名がパートナー先にきちんと伝わらず、独自の命名で納品されてしまったことも覚えています。
「命名の統一」は確かに大切ですが、実際の開発スケジュールやリソースとの折り合いは、そう簡単にはつかないものでした。
3. Bootstrapによる「命名吸収」の考え方
そんな中、業界ではBootstrapが広く使われるようになっており、これが命名ルールに対して新しい風をもたらしました。
<button class=”btn btn-primary”>送信</button>
<div class=”row”>
<div class=”col-6″>カラム1</div>
<div class=”col-6″>カラム2</div>
</div>
Bootstrapが提供する .btn や .row などのクラス名に従えば、見た目も整うし、命名に頭を悩ませる必要もなくなります。この「命名を吸収する」スタイルは、独自命名に比べて圧倒的に楽でした。
そしてなにより、「なるほど、ボタンのスタイルは btn-primary という命名にすれば良いのか」という形で、命名の参考にもなりました。独自ルールよりも、既成のルールに従うほうが、メンバー間の認識統一がしやすかったのです。
4. CSS in JSの登場と、新たなアプローチ
Reactを学び始めた頃、styled-components や emotion といった CSS in JS ライブラリに出会いました。
const Button = styled.button`
background-color: blue;
color: white;
`;
このように、クラス名ではなく、Reactコンポーネントとスタイルを1つのファイルにまとめることで、命名を気にせずに済むというメリットがありました。
ただ一方で、「CSSをJavaScriptに書くこと」への違和感や、SSR（サーバーサイドレンダリング）に関する課題（「styled-components SSR」で検索するとCSSがページ読み込み初期に当たらないといったような記事が散見される）などもあり、必ずしも万能ではありませんでした。
5. Tailwind CSSの登場と衝撃
そんな中、Tailwind CSS が登場し、CSSの書き方・考え方に大きな変化をもたらしました。
<button class=”bg-blue-500 text-white px-4 py-2 rounded”>送信</button>
最初は「クラス多すぎじゃない？」と思ったのが正直なところですが、使っていくうちに「クラス名を考える必要がない」快適さに気づいていきました。
Tailwindは、原則として「同じ見た目なら同じクラスを使う」という思想に基づいており、命名規則に悩まされることがほとんどありません。むしろ、Tailwindのクラスを通じて、適切なスタイルの構造を学ぶような感覚になります。
コーディング規約に縛られるというよりも、「設計思想に従う」ことが求められる。これは、以前とはまったく異なるアプローチでした。
6. shadcn/uiの登場と、コンポーネント設計の現在地
さらに最近では、shadcn/uiのようなTailwindベースのUIコンポーネントライブラリが登場し、スタイリングと命名に対する感覚はさらに変化しています。
shadcn/uiでは、Tailwindのクラスを用いながらも、構造化されたUIコンポーネントを提供してくれるため、初学者でも「こう書けばそれっぽくなる」という指針を得ることができます。
しかも、className によって簡単にカスタマイズも可能です。命名に悩むよりも、再利用しやすい設計をどう作るかにフォーカスする時代になったように感じます。
7. おわりに：命名ではなく、設計思想へ
このようにCSSの歴史を振り返ってみると、命名規則というのは常に開発者を悩ませてきました。
BEMやSMACSSのような厳格な命名ルールに始まり、Bootstrapが提供する統一命名、CSS in JSのクラス不要スタイル、Tailwindのユーティリティ設計、そしてshadcn/uiのような再利用設計のようなものたちです。
今や「命名で悩まなくていい」ことは、現代CSSにおけるひとつの理想となっています。
しかし一方で、設計が雑になれば、コードの読みづらさや保守性の低下につながってしまうのも事実です。
だからこそ、今後のCSSにおいて大切なのは、「命名ルールの遵守」ではなく、「設計思想の共有」なのではないかと感じています。
補足：Sassの存在について
なお、かつて主流だったSassも、この変遷の中で一時代を築きました。
ネストや変数など多くの便利機能がありましたが、CSSの進化やTailwindの台頭により、現在ではあまり使われなくなってきています。技術が進化する一方で、Sassの方向性が少し現実から離れてしまったという印象です。
