BEMとFLOCSS、現場では何を先に揃えるか

案件のキックオフで、「CSSはBEMでお願いします」という声と、「FLOCSSで揃えてください」という声が同時に上がることがあります。どちらもクラスの命名に関する話に聞こえるため、その場では「どちらかに決めれば済む」と受け取られがちです。しかし、この2つが扱っている範囲は同じではありません。BEMは、ひとつの部品をブロック・要素・修飾子に分けて名前を付けるための方法です。一方のFLOCSSは、そうした部品を、どの層のファイルに置くかを決めるための設計手法です。

そのため、どちらか一方を採用すればCSSの運用が整う、と一概には言えません。先に揃えるべきなのは、クラス名の書き方なのか、それとも層ごとのフォルダ構成なのかを見極めることが、最初の判断になります。

結論からお伝えすると、小規模な案件で部品の名前だけを揃えたい場合は、BEM（またはMindBEMding）の書き方を決めるだけで十分なことがあります。ページ共通の枠組み、案件固有のまとまり、余白調整用のクラスまで置き場所を決めたい場合は、FLOCSSの層を先に決めるほうが運用しやすくなります。なお、FLOCSSのObject層のクラス名は、公式のREADMEでMindBEMdingを基本にすると定められています。つまり、2つは対立する選択肢ではなく、FLOCSSの層の上にBEMの命名が乗る関係だと考えると分かりやすくなります。

この記事では、フリーランスのWebディレクター兼エンジニアとしての実務をもとに、BEMとFLOCSSの違い、案件に合わせた決め方、2つを混在させたときに崩れやすいポイントを整理します。BEMの一次情報は bem.info、FLOCSSの一次情報は hiloki/flocss です。

想定している読者は、これから案件のCSS設計を決めるコーダーやエンジニアの方、そして制作チームの進め方を決めるディレクターの方です。すでに運用中のサイトで、クラス名の付け方がばらばらになって困っている場合にも、どこから整理を始めればよいかを判断する材料として読んでいただけます。手法の優劣を決めるのではなく、案件ごとに何を先に揃えるかを考えるための記事です。

BEMとFLOCSSは何が違うのか

まずは、2つの手法がそれぞれ何を決めるためのものなのかを、表で比べてみます。

BEMは、部品の内側の構造を名前で表すための方法です。.card__title という名前を見れば、それが .card というブロックの中にあるタイトルだと分かります。.card--featured であれば、通常のカードとは見た目が異なる種類だと読み取れます。部品の中の関係が名前から分かるため、HTMLとCSSを行き来するときに迷いにくくなります。

FLOCSSは、そうした部品をプロジェクト全体のどこに置くかを決めるための方法です。リセットや基本の文字設定を担う Foundation、ヘッダーやフッターのような大きな枠組みを担う Layout、繰り返し使う部品を担う Object という3つの層に分け、Object の中をさらに Component、Project、Utility に分類します。.c- .p- .u- といった接頭辞を見れば、そのクラスがどの層に属するのかが分かります。

この違いを意識しないまま片方だけを決めると、運用の途中で困ることがあります。BEMの命名だけを決めて、フォルダ構成が平坦なままだと、目的のスタイルを探すときにクラス名の検索に頼るしかなくなります。反対に、FLOCSSのフォルダだけを用意して、中のクラス名が .btn のような名前のままだと、層を分けた意味が薄れてしまいます。会議で手法の名前を挙げ合うよりも、リポジトリの構成とクラス名の例を1画面分、具体的に決めておくほうが、チーム内の認識を揃えやすくなります。

たとえば、「お知らせ一覧のカードは .c-card として Component に置き、トップページだけの並び方は .p-top-news として Project に置く」というように、実際の部品を使って1つ例を示すだけでも、メンバーの理解は大きく揃います。

流行で決める場合と、現状から決める場合

運用が崩れやすい決め方

「今はFLOCSSが主流だから」「BEMはもう古いから」といった理由で手法を選ぶと、運用が長続きしないことがあります。どちらの手法も公開されている設計の考え方であり、時期によって使えなくなるものではありません。大切なのは、チームのメンバーがそのルールを理解し、守り続けられるかどうかです。

メンバーが読み解けないルールは、守られにくくなります。ルールが守られなくなると、既存のクラスを上書きするスタイルが少しずつ増え、詳細度が高くなっていきます。話題になっている手法だからという理由だけで選ぶと、既存のCSSとの食い違いだけが残り、かえって修正に時間がかかる状態になりかねません。

運用が続きやすい決め方

運用が続きやすいのは、今あるCSSの状態から出発する決め方です。次の3つの手順で進めると、現場の負担を抑えながらルールを決めやすくなります。

1. 既存のCSSで使われている接頭辞やクラス名の傾向を、1時間ほどかけて洗い出す
2. 新しく作るファイルだけに新しいルールを適用するのか、既存のファイルも移行するのか、範囲を決める
3. レビューで確認する項目を1つに絞る（接頭辞が正しいか、層の置き場所が正しいか、のどちらか）

既存のCSSで .c- のような接頭辞がすでに使われているなら、FLOCSSに近い状態なので、層の分け方を文書にまとめるだけで移行しやすくなります。反対に、.card のような接頭辞のないクラス名が中心であれば、まずBEMの書き方を文書にまとめるほうが、移行にかかる時間を短くできることがあります。どちらが早いかは、ページ数や、同じクラスがどれくらい使い回されているかによって変わります。

レビューで確認する項目を1つに絞るのは、最初から多くのルールを求めると、確認する側もされる側も負担が大きくなるためです。まずは接頭辞だけ、あるいは置き場所だけを確認するところから始め、チームに定着してから項目を増やしていくと、ルールが形だけになるのを防ぎやすくなります。

既存のCSSを洗い出す際は、完璧な一覧を作る必要はありません。よく使われているクラス名を10〜20個ほど拾い、接頭辞の有無や、__ と -- の使われ方を確認するだけでも、どちらの手法に近い状態なのかは見えてきます。洗い出した結果は、そのままルールを決めるための議論の材料として使えます。

案件の規模や体制に合わせた3つの選び方

1. ページ数が少なく、部品の数も少ない案件

ランディングページや数ページ程度のサイトであれば、ブロック名と、要素を表す __、修飾子を表す -- の書き方を決めるだけで十分なことがあります。この規模で最初からFLOCSSのフォルダをすべて用意すると、中身のない空のファイルが増えるだけになることもあります。余白調整用のUtilityクラスも、必要になったものから追加すれば足ります。

2. 複数人で、半年以上にわたって運用する案件

複数のメンバーが長期間にわたって触る案件では、FLOCSSの層を先に決めておくと、担当者が入れ替わっても構成を把握しやすくなります。Foundation にはデザイントークンとリセットを、Layout には共通の枠組みを、Object には部品と案件固有のまとまりを置きます。そのうえで、Object の中だけをMindBEMdingの書き方で命名します。レビューでは「この変更は .c- と .p- のどちらに当たるか」をまず確認します。

3. デザインシステムと、期間限定のキャンペーンが混在する案件

サイト全体で使う共通のボタンは Component、期間限定のファーストビューは Project、余白の例外的な調整は Utility に置く、という振り分けを、口頭ではなく表にして1枚残しておきます。

<!-- サイト全体で使う共通の部品 -->
<a class="c-button c-button--primary" href="/contact/">相談する</a>

<!-- そのページだけで使うまとまり -->
<section class="p-pricing">
  <h2 class="p-pricing__title">料金</h2>
</section>

見た目が同じボタンを、キャンペーンのたびに .p-fv__btn として複製すると、色を変更するときに修正箇所が散らばってしまいます。反対に、期間限定の並び方まで .c- に入れてしまうと、共通部品であるはずの Component に、特定の案件の事情が入り込みます。公式のFLOCSSでも、Component は最低限の機能を持つ部品、Project は案件固有のまとまりとして分けて考えられています。

この振り分けの表は、AIにCSSを書いてもらう際にも役立ちます。「BEMでCSSを書いて」とだけ伝えるより、「.c- は共通部品、.p- はページ固有、余白の調整は .u- を使う」という表をプロンプトに含めたほうが、出力の方向性が揃いやすくなります。ただし、表を含めても意図と違うクラス名が出てくることはあるため、生成された内容は表と照らし合わせて人が確認します。

2つを混在させたときに起きやすいこと

BEMとFLOCSSの考え方が整理されないまま混在すると、次のような問題が起きやすくなります。

• BEMの Modifier と、FLOCSSの Utility が同じ余白を担当する: カードの余白を詰めるために .c-card--tight を使うのか、.u-mbs を使うのかがはっきりせず、レビューのたびに確認が必要になります。
• Layout に装飾のスタイルを書いてしまう: ヘッダーの枠組みと、グローバルナビゲーションの見た目が同じファイルにまとめられ、後からナビゲーションだけを差し替えることが難しくなります。
• is- から始まる状態クラスに単独で色を持たせる: FLOCSSの公式では、.is-active のような状態クラス単体にはスタイルを持たせないとしています。単体でスタイルを持たせると、ほかの部品の状態にまで影響することがあります。

こうした問題の多くは、「どちらの手法で対応するか」がケースごとに決まっていないことから起きます。たとえば余白の調整であれば、「部品の種類として余白が違う場合は Modifier、配置の都合で一時的に調整する場合は Utility」というように、判断の基準を一文で決めておくと、迷う場面を減らせます。

また、既存のSCSSでユーティリティクラスを運用している場合は、BEMの命名とは別に、余白の例外を調整するためのものとして役割を切り分けておくと整理しやすくなります。ユーティリティクラスを際限なく増やしてしまうと、HTMLを読むだけでは見た目が判断しにくくなり、後から参加した人が全体を把握するまでに時間がかかります。混在させること自体が問題なのではなく、それぞれの役割を決めずに使い分けてしまうことが、運用を難しくする原因になります。

混在による問題に気付くきっかけとして分かりやすいのは、レビューで同じ質問が繰り返されることです。「この余白はどちらのクラスで調整しますか」「このスタイルはどのファイルに書けばよいですか」といった質問が何度も出てくる場合は、判断の基準がまだ文書になっていない可能性があります。質問が出た時点で、その回答をREADMEに追記していくと、同じ迷いが繰り返されにくくなり、ルールも少しずつ実態に合ったものになっていきます。質問を「ルールを見直すための材料」として前向きに扱うことが大切です。

現場でつまずきやすいポイント

命名ルールを導入したはずなのに定着しない場合、次のような原因が隠れていることがあります。

• 命名ルールの資料だけを共有して、リポジトリの中身が変わらない: ルールを説明した資料があっても、実際のコードに例がないと、メンバーは既存のコードを真似して書き続けます。まずは代表的な部品を1つ、新しいルールで書き直して、見本として示すと伝わりやすくなります。
• 英語のBEMの解説と、日本語のFLOCSSの解説を同時に渡す: 参照する資料が複数あると、接頭辞の付け方が二重になったり、層の解釈がずれたりすることがあります。チームで基準にする資料を決めておきます。
• SuitCSSなど、さらに別の手法を追加する: 手法を増やすほど接頭辞の種類も増え、どのルールに従えばよいのかが分かりにくくなります。追加が必要な場合でも、採用する一次情報を1つに絞ります。

資料を読む順番にも気を付けたいところです。まずは案件のREADMEなど、チームで決めたルールを確認し、次に公式の資料を読みます。要約された解説記事を先に読むと、Project から Component へのスタイルの変更を例外として認めている点など、細かな取り決めが抜け落ちていることがあります。

また、ルールを決めた担当者が案件を離れると、決めた理由が分からなくなり、ルールが守られなくなることもあります。「なぜこの層に置くのか」という理由を、READMEに短く残しておくだけでも、後から参加した人がルールを理解しやすくなります。ルールの数を増やすことよりも、決めたルールの理由を共有することが、長く運用を続けるための土台になります。

もう一つ見落としやすいのが、CSSフレームワークやプラグインが出力するクラス名との関係です。WordPressのテーマやブロックエディタ、UIライブラリなどは、独自の命名でクラスを出力します。それらのクラスに対して、自分たちの命名ルールに沿ってスタイルを上書きしようとすると、詳細度の争いが起きやすくなります。外部から出力されるクラスは「触らない層」として扱い、どうしても調整が必要な場合は、上書き用のファイルを分けて管理しておくと、自分たちのルールとの境界がはっきりします。上書き用のファイルには、どの外部クラスを、どのような理由で調整したのかを短いコメントで残しておくと、外部のテーマやライブラリを更新したときの確認もしやすくなります。

まとめ：二択ではなく、どの順番で重ねるか

BEMとFLOCSSを「どちらを選ぶか」という二択で考えると、フォルダの構成とクラス名の付け方がずれてしまうことがあります。BEMは部品の名前の付け方、FLOCSSは部品の置き場所の決め方であり、2つは重ねて使うことができます。FLOCSSの層を土台にして、その上にBEMの命名を乗せる、という関係で考えると、両者の役割が整理しやすくなります。

案件の規模によって、どこまで決めるかも変わります。数ページ程度の小さな案件であれば、BEMの書き方を揃えるだけで十分なことがあります。複数人で長く運用する案件であれば、FLOCSSの層まで決めておくと、担当者が入れ替わっても構成を把握しやすくなります。どちらの場合も、今あるCSSの状態から出発し、レビューで確認する項目を絞って始めることが、ルールを定着させる近道です。

決めたルールの効果は、守られた分だけ表れます。ルールの名前だけを決めて中身が伴わなければ、導入した意味は薄れてしまいます。見本となるコードと、ルールの理由をセットで残し、チームで同じ基準を持つことを意識してみてください。

最後に、この記事の要点を整理します。

• BEMは部品の名前の付け方、FLOCSSは部品の置き場所の決め方であり、扱う範囲が異なる
• 手法は流行ではなく、既存のCSSの状態とチームの体制から選ぶ
• 余白の調整など、どちらの手法で対応するか迷う場面は、判断の基準を一文で決めておく
• 見本のコードと、ルールを決めた理由をREADMEに残しておく

CSSの設計は、一度決めたら終わりではなく、運用しながら少しずつ整えていくものです。最初から完璧なルールを目指すよりも、チームが守れる範囲から始めて、レビューで出た疑問を反映しながら育てていくほうが、結果として長く使えるルールになります。

まずは、今関わっている案件のCSSから、よく使われているクラス名を10個ほど拾い出してみてください。接頭辞の有無や、__ と -- の使われ方を見るだけでも、BEMとFLOCSSのどちらに近い状態なのか、そして次に何を揃えるべきなのかが見えてくるはずです。

CSSの命名やディレクトリ構成の決め方、既存のクラスから新しいルールへの移行範囲についてのご相談は、相談・お問い合わせからお気軽にどうぞ。