BEMが業務で役立つ場面 ─ 大規模サイトとチーム開発

当記事はWebの間コーポレート記事の転載です。元記事はこちら。

数ページ規模のサイトであれば、CSSの管理はそこまで大変ではありません。
スタイルを追加しても影響範囲は限られ、チームメンバーも数人程度。
「とりあえずのクラス名」でも意外と回ってしまいます。

しかし、これが数百〜数千ページ規模のECサイトやメディアサイトとなると話は別です。
複数人が同時にCSSを書き、コンポーネントを使い回すなかで、クラスの衝突や上書き合戦が頻発します。

BEMが役立つ具体的なシーン

こうした大規模開発では「誰がどこで書いたCSSか分からない」ことがトラブルの原因になります。
BEMは次のような場面で効果を発揮します。

1.チーム開発でのクラス衝突回避

例：btnというクラスが複数人によって定義され、色やサイズが食い違う
BEMなら「header__btn / footer__btn」のように分けることで衝突を防げる

2. コンポーネント単位での再利用

BEMのBlockは「独立した部品」として設計するため、他ページに移植しても崩れにくい
特にECの「商品カード」や「レビュー一覧」などで効果的

3. 状態やバリエーションの明示化

例：カートに商品が入っているときだけ色を変える場合、「cart-active」のように状態が分かりやすい
チーム全体で「どういうときに使うクラスか」が即理解できる

実際の業界での採用例

• 大規模ECサイト：商品カードやランキング表示など共通UIが多いため、コンポーネント管理の恩恵が大きい
• ニュースメディアやポータルサイト：大量のコンテンツをテンプレート化するため、BEMでの明示的な管理が適している
• 受託制作の現場：複数の制作会社・外部パートナーが関わる場合、命名規則の統一で「誰でも理解できるCSS」を目指せる

注意点 ─ すべての案件で必要とは限らない

ただし「BEMが業務で役立つ場面＝すべての案件」とは限りません。

• 小規模コーポレートサイト
• LPやキャンペーンページ

こうした案件では、BEMよりも軽量な命名ルールやTailwind CSSのようなユーティリティファーストの方が効率的です。

BEMの有効性の裏にある課題へ

BEMは確かに大規模開発では役立ちます。
しかし同時に、クラスが長くなる・HTMLが読みにくくなるといったデメリットも存在します。

次回は「BEMのデメリットと現場での評価」について、より掘り下げて解説していきます。