今日の朝の記事で、BEM/FLOCSSってそもそも何なのかを初心者向けに整理してみました。
ただ、実際に案件をやってると「何なのか」より先に「この案件にそもそも要るのか」で迷う場面の方が多かったりします。
ずっとこの設計をベースにやってきた身として、今日はその線引きをゆるっと言葉にしてみようと思います。
案件ごとに毎回一から考え直すのも大変なので、自分の中である程度パターン化して持っておくと判断が早くなる、という実務的な話でもあります。
🎥 この記事の内容は動画でも解説しています。
「正しい設計か」じゃなくて「守る人がいるか」
BEM/FLOCSSを導入するかどうか、自分の中の判断軸は「正しい設計かどうか」ではありません。
「このルールを守る人が自分以外にいるか」「自分自身、半年後にこの命名ルールを思い出せるか」の2つです。
どんなに綺麗な設計ルールでも、守る人がいない現場に持ち込むと、クラス名を考える時間だけ増えて、誰も回収しないコストになってしまいます。
規約って、守られて初めて意味があるものなんですよね。
向いている案件
- 複数人で触る案件(命名ルールが無いと、人によってクラス名の付け方がバラバラになる)
- 長期運用で改修が続いていく案件(半年後・1年後の自分が読み解ける状態を保ちたい)
- ページ数が多く、コンポーネントの再利用が効く案件(同じボタン・カードが何箇所にも登場する)
- 引き継ぎが前提の案件(自分以外の誰かが5年後に触る可能性がある)
- デザインシステムがある程度固まっている案件(componentに入れるべきものが最初から見えている)
💡 Tips: デザインシステムとは
ボタンや見出しの色・余白・角丸などのルールをあらかじめ整理して、サイト全体で統一して使い回せるようにした設計のまとまりのことです。FigmaのコンポーネントやCSS変数として管理されていることが多く、これが固まっているほどFLOCSSのcomponentが機能しやすくなります。
そこまで要らない案件
- 1〜3ページのLP(コンポーネントが再利用されないので
component/が空になりがち) - 納期が極端に短い案件(命名を考える時間そのものが惜しい)
- 既存テーマのカスタマイズが主で、追加CSSが数十行程度の案件
- クライアント側が後からノーコードで触る前提の案件(そもそもクラス設計の恩恵を受ける人がいない)
こうして並べてみると、判断軸は「ページ数」でも「予算規模」でもなく、このルールが後から誰かの役に立つ場面が来るかどうか、なんだと思います。
要らない案件に無理やり導入すると、component/フォルダの中身がほぼ空、みたいな状態になって、逆に「このフォルダ、何のためにあるんだっけ」というノイズになってしまいます。
実際にこのブログでも「置き場所」で迷った実例
このブログ自体もFLOCSS運用なんですが、実際に手を動かしてる最中に迷う場面はちゃんとあります。
トップページのヒーロー演出で文字が光るシマーエフェクトを実装したとき、最初から共通コンポーネントとしてcomponent/に切り出すか迷いました。
結論はproject/_page.scssにmixinとして置く、でした。理由は、その時点でトップページのヒーローにしか使う予定がなかったからです。
実際、その後トップページのCTAブロック(お問い合わせへの誘導ブロック)の見出しにも同じ演出を使うことになり、そこで初めて@include text-shimmer(...)という形でmixin化しました。
2箇所ともトップページの中だけの話なので、今でもproject/_page.scssに置いたままです。
もし3つ目の使い道が別のページで出てきたら、そのタイミングで初めてcomponent/への昇格を考えると思います。
CTAって何?
「Call To Action」の略で、「お問い合わせはこちら」みたいな、読者に次の行動を促すボタンやブロックのことだよ。
最初から完璧に分類しようとせず、2回目の再利用が実際に発生してから動かす。この順番を守るようにしてから、「使われるかもしれない」を先回りして作りすぎることが減りました。
これはFLOCSS/BEMを導入するかどうかの判断とも同じ話で、「将来使うかもしれないから」で規約を先回りして持ち込むより、実際に必要になったタイミングで導入する方が、結果的に無駄が少ないなと感じています。
BEM側も「守れる範囲」に留める
FLOCSSがフォルダの話なら、BEMはクラス名の話ですが、こちらも同じ考え方で調整しています。
Elementのネストは2〜3階層までに意識的に抑えていて、それ以上は途中で別のBlockとして切り出すようにしています。
理由は単純で、ネストが深くなるほど「このクラス、どのBlockの何番目の子だっけ」と自分でも追えなくなってくるからです。
Modifierも見た目や状態の違いだけに使うと決めていて、役割そのものが変わるようなパターンはModifierではなく別のBlockにする、というルールにしています。
これも「理論上どこまで表現できるか」ではなく「自分が半年後に迷わず読めるか」を基準にしている、という点で判断軸は一貫しています。
まとめ
FLOCSS/BEMは「導入すれば必ず正解」という魔法のルールじゃなくて、あくまで道具です。
今回の判断軸をひとことでまとめると、このルールを守る人が、自分を含めて本当にいるかどうか、に尽きます。
「そもそも何なのか」が気になる方は今日の朝の記事を、実際の運用ルールの細かい線引きが気になる方はこちらの記事も合わせてどうぞ。
この記事が参考になったら、応援クリックをお願いします
