BEMのデメリット｜保守とスピードの狭間で考える

BEMは「役割を明確化する」という思想に基づいており、大規模開発や多数人での協業には適しています。
しかし、このルールが逆に “縛り” になるケースも少なくありません。
特に小規模案件やスピード重視の開発において、ルール遵守のために余計な工数が発生しやすいのです。

BEMの“強み”が裏返るとき

デメリット①：クラス名の肥大化

BEMは「Block__Element–Modifier」という形式を守るため、header__nav__item–active のように クラス名が長文化 します。

• コードが読みにくい
• HTMLが冗長になる
• メンテナンス時にタイプ量が増える

これらは特に「軽量化」を重視する案件では無視できない課題です。

デメリット②：学習コストと浸透の難しさ

BEMはルール自体がシンプルとはいえ、新人や外部パートナーにとっては “名前の付け方に迷う” 壁があります。

• BlockとElementの境界をどこで引くか
• Modifierは必須か、別クラスに分けるべきか

ルールを理解していない人が混ざると、かえって 命名規則が崩れ、管理が難しくなることもあります。

デメリット③：小規模サイトでは過剰設計

10ページ程度のコーポレートサイトや、短納期のキャンペーンLPなどでは、BEMの厳格な命名を守るよりも 「シンプルなクラス付け」 の方が早く・軽く仕上がります。
BEMは「将来的な拡張性」に価値がある一方で、使わない機能にコストを払うリスクも忘れてはなりません。

デメリット④：パフォーマンスへの影響

HTMLが冗長になることで、理論上は レンダリング速度やSEOに影響します。 特にGoogleが強調する「軽量化」「不要な複雑性を排除」という観点では、BEMのような冗長な命名規則は、必ずしもプラスに働くとは限りません。

すべての現場に万能ではない

BEMは大規模開発や複数人での長期運用には確かに有効です。
しかし、小規模・短期・軽量化重視のプロジェクトでは 「重すぎるルール」 になることもあります。

つまり、BEMは「採用すべきか／すべきでないか」という二択ではなく、
案件ごとに最適なルールを選び分ける視点 が重要です。

次回はこの視点を踏まえ、「BEMとPageSpeed Insightsの関係」から、さらに最適解を探っていきます。