CSS設計で「後から困る」を防ぐ｜スケーラブルな命名規則の実装パターン
こんにちは！
今日は「CSS設計で『後から困る』を防ぐ｜スケーラブルな命名規則の実装パターン」というテーマで、現場で本当に活躍する命名規則の使い方についてお話しします。
なぜ命名規則で「後から困る」のか
僕も駆け出しの頃は、命名規則なんて気にしてませんでした。
単に.header、.button、.cardみたいに思いついた名前をつけていたんです。
最初のプロジェクトは小さかったから問題なかったんですけど、ほんまにやばくなったのは、そのサイトが大きくなり始めた時。
「あれ、.buttonってどのボタンのCSSなん？」ってなるわけです。
プロジェクトに複数のボタンスタイルが出てきて、.button--largeと.button-largeが混在してたり、.button-primaryと.primary-buttonが両方あったり…。
チームメイトが書いたコードを見ると、命名ルールがめっちゃ一貫してないんですよね。
これが何年も保守してるサイトだと、レガシーコードと新しいコードが混在して、「どっちに合わせるんだ…」という状況が生まれてしまいます。
結果として、バグが生まれたり、無駄なCSSが増えたり、最悪の場合リファクタリング地獄に陥ることもあります。
だからこそ、プロジェクト開始の段階で「ここの命名規則はこれで統一します」と決めておくことが、本当に大事なんです。
BEMとFLOCSSの使い分けの実例
現場でよく使われている命名規則の代表がBEMとFLOCSSです。
ここで大事なのは「どっちが正義か」じゃなくて、「プロジェクトのどこでどっちを使うか」という判断なんです。
BEMの実装例：単一のコンポーネントに集中したい時
BEMは「Block」「Element」「Modifier」という3層で管理します。
例えば、商品カードのコンポーネントがあったとしましょう。
.product-card { /* Block */ }
.product-card__image { /* Element */ }
.product-card__title { /* Element */ }
.product-card__price { /* Element */ }
.product-card--featured { /* Modifier */ }
.product-card__price--sale { /* Element + Modifier */ }
BEMの良さは、各クラスの関係性が一目瞭然だということです。.product-card__imageを見たら、「これは product-card の内側の image なんだな」とすぐにわかります。
新しいメンバーが参加した時も、ルールさえ説明すれば、すぐに同じ書き方ができるようになるんですよね。
ただ、BEMでよくある落とし穴があります。
それは「3層を超えて深くしてしまう」ことです。
.product-card__content__inner__text ← これはやめておくといいですよ
こういう深さになると、HTMLの構造が変わった時に地獄を見ます。
BEMは「Block と Element は1段階まで」くらいのルールを決めておくと、ほんまに無駄な複雑性を避けられます。
FLOCSSの実装例：大規模プロジェクトで整理したい時
FLOCSSは「Foundation」「Layout」「Object」という層で整理します。
Object はさらに「Component」「Project」「Utility」に分かれます。
.fz-16 { font-size: 16px; } /* Utility */
.c-button { /* Component */ }
.c-button--primary { /* Component Modifier */ }
.p-hero { /* Project - ページ固有 */ }
.l-container { /* Layout */ }
FLOCSSの強みは、CSSを「再利用の可能性」で分類するところです。
Utility は本当に小さな単位で、何度も使える。
Component は複数ページで使うパーツ。
Project はそのページでだけ使うやつ。
このように層を分けることで、「このスタイル、どこに書いたらいいんだろう…」という迷いが減ります。
大規模なチーム開発では、この判断の明確さが本当に大事です。
実際の使い分けの判断基準
僕が現場で使い分けている判断基準はこんな感じです：
- プロジェクトが小～中規模、または単一ページアプリの場合 → BEMを採用
- 大規模Webサイトで複数ページ、複数人チーム → FLOCSSを採用
- Tailwind CSS を使ってる場合 → 命名規則そのものがいらない（ユーティリティファースト）
ただし、これは「絶対」ではありません。
チームの習熟度やプロジェクトの性質に応じて、柔軟に選択するといいですよ。
プロジェクト規模に応じた命名の選択肢
僕が見てきた失敗パターンの1つに「命名規則をオーバーエンジニアリングする」というのがあります。
例えば、小さなLPサイトなのに、FLOCSSの全層を完璧に実装しようとしたり、BEMで深い階層を作ったり。
結果として「規則を守ることが目的」になっちゃって、実装が遅くなるんです。
これ、ほんまにやっちゃいました。
小規模プロジェクト（1～3ページ）
正直な話、ここまで来たら命名規則は「シンプル」が最強です。
例えば、シンプルな「プレフィックス + 機能名」くらいで十分。
.hero-title { }
.hero-subtitle { }
.feature-card { }
.feature-card-image { }
.btn-primary { }
.btn-secondary { }
後から保守する人が見ても「あ、hero に関するやつね」とわかります。
複雑な規則より、「シンプルで誰が見てもわかる」方が絶対に重要です。
中規模プロジェクト（5～20ページ）
ここからは BEM か