チーム開発で破綻しないCSS設計｜スケーラビリティを考えた命名規則の選択

2026年06月14日

クリオ

Web制作ディレクター / フロントエンジニア

こんにちは！

今日は「チーム開発で破綻しないCSS設計｜スケーラビリティを考えた命名規則の選択」について解説します。

複数人開発でなぜCSSが崩壊するのか

僕も最初は本当に気づかなかったんですけど、CSS が破綻するのって大体「複数人で開発し始めた時点」なんですよ。
1人で書いてる時は「自分のルール」で統一できるから問題がないんです。
でも、チーム開発になると、それぞれが違うやり方でクラス名を付けるから、めっちゃカオスになる。

現場でよく見るのは、こういうパターンです。

各自が「これで分かりやすいはず」と思ってるんですけど、後から別の人がコードを見ると、もう何がなんだか。
ほんま、修正するのに時間がかかります。

さらに怖いのが「同じ名前のクラスが複数の場所で定義されてる」という状態。
1つ修正したと思ったら、別の場所で同じ名前が使われてて、予期しない場所が壊れる。
これが本当に現場あるあるです。

命名規則を統一することって、実は「単なる美しさ」の問題じゃないんです。
それは「スケーラビリティ」の問題なんですよ。

プロジェクトが大きくなると、CSSファイルも増えます。
ページが増え、コンポーネントが増え、気づいたら style.css が5000行超えてたりします。
そういう状況で「あ、このクラス名どこで使ってるんだっけ？」って探すのは本当に大変なんです。

けれど命名規則がしっかりしてると、こういうメリットが生まれます。

つまり、命名規則ってのは「チーム開発のための言語」だと思ってください。
みんなが同じルールで話してれば、大規模プロジェクトでも破綻しないんです。

ここからは、実際にどう選ぶかです。
重要なのは「完璧な設計を求める」んじゃなくて「プロジェクトに合ったものを選ぶ」ってことです。

.block__element--modifier という形式ですね。
僕のチームでも、複数ページ、複数コンポーネントがあるプロジェクトではほぼBEM記法を採用してます。

例えば、カードコンポーネントなら。

こうすることで、「このカードの派生版」「このカードの子要素」が一目瞭然になります。
新しく入ったメンバーも、ルールを理解してれば迷いなくコード書けます。

ただし、BEMは最初はめっちゃ冗長に感じます。
クラス名が長くなるし「こんなに細かく分ける必要あるの？」って思っちゃう。
でも、半年後のメンテナンスフェーズで「あ、このルール本当に助かる」ってなりますよ。

スタートアップとか、とにかく最初はサッと作りたい。
そういう時は、無理してBEMにしなくていいんです。

例えば .header、.header-nav、.header-nav-active みたいに、ハイフン区切りで単純にしちゃう。
最初のうちはこれで十分です。

ポイントは「後から移行できる設計にする」ってことです。
最初から複雑にしすぎて、チーム全体が疲れちゃったら本末転倒ですから。

これはフレームワーク（ReactやVue）を使ってるプロジェクトの話ですね。
styles.module.css みたいに、各コンポーネントに紐付いたCSSファイルを作る。

こうすると、クラス名が自動的に一意になるから、命名規則について悩まなくていいんです。
ただ、従来のマルチページサイトだと難しいので、この方法は選べない場合が多いですけど。

僕が実際に使ってる判断基準はこれです。

そしてね、最後に大事なのは「チーム全体で合意する」ってことなんです。
いくら完璧な設計でも、メンバーが納得してなかったら、結局ルールが守られません。
導入前に「なぜこの命名規則にするのか」を説明して、質問を受け付ける。
そうすることで、みんなが自分たちのルールだと認識できるようになります。

CSS設計で最も大事なのは「完璧さ」ではなく「継続