この記事はBEMとはどんな設計手法なのか？デザインシステムに適しているのかどうか？
についてまとめた記事です。
Block-Element-Modifierを略してBEMです。
クラス名をBlock__Element—Modifierのようにつけます。（Block,Element,Modifierをどのように繋げてCSSのクラス名にするかは複数の手法がありますが、ここでは一旦割愛します。）
ものすごく雑に言うと、CSSのクラス名を「どこの-なに-どんな」という分類で命名しようという規則です。
例えば、「メニュー」というパーツの中にある、「非活性状態」の「ボタン」があったとします。
そのボタンに対して、BEMの規則に則ってクラス名前をつけると、「menu__button—disabled」となります。
あえてこのクラス名を日本語に合わせるなら「メニュー__ボタン—非活性状態」となります。
つまり、
Blockは「どこの」を意味し、今回の例だと「メニュー」が当てはまります。
Elementは「なに」を意味し、今回の例だと「ボタン」、
Modifierは「どんな」を意味し、今回の例だと「非活性状態」が当てはまります。
これだけだとなんのことかわからないと思うので少し解説します。
なお以下の記事ではコードも交えて詳しく説明しているので、気になった人は参考にしてください！
「どこの-なに-どんな」の「どこの」の部分にあたります。
パーツの大きなくくりとイメージしてもらえれば良いかと思います。
例えば先ほどの例であげた「メニュー」というパーツがあった場合、そのパーツの子要素になるものに関しては「menu__なんちゃらかんちゃら」というクラス名になります。
なおそのメニュー全体のくくりとなるクラスに対しては、「menu」というクラスを適用します。
「どこの-なに-どんな」の「なに」の部分にあたります。
パーツとしての大きなくくりであるBlockの中の要素を意味します。
あるパーツの中にボタンが入っていたとしたらそのクラス名は
「Element名__button」のようになります。
「メニュー」というパーツの中の「ボタン」につけるクラス名は「menu__button」のようになります。
「どこの-なに-どんな」の「どんな」の部分にあたります。
BlockやElementに対して、基本となる状態ではない状態や、形状・大きさを表す際に用います。
先ほどの例でいうところの「非活性状態」がこれにあたります。
有名だから良いというわけでは決してありませんが、こういった命名規則や設計手法を比較する際に、有名であるかどうかは採用の指標の一つになり得ます。
情報の取得しやすさ、理解している人の母数の多さはプロジェクトで採用する際には必ずメリットとなります。有名であれば、これら2つが担保されている確率が高いと言えます。
BEMはクラス名からそのクラスが何を担っているかが非常にわかりやすいです。そのため、改修や拡張に強くプロジェクト開発において、強みを発揮します。
HTMLとクラス名が長くなりがちで慣れない人からすると見た目が悪いため、初見の人でネガティブな印象を持つ人が多いと感じます。
例えば以下のコードです。
コードは読みやすさが大事なので、コードが長くなってしまうことに対する忌避感がある人は少なからずいるはず。
とっつきずらさ故に敬遠している人は多い印象です。
今回の記事では省いていますが、BEMにはルールがたくさんあります。そのため、少しだけ勉強してみたが、わかりにくいという印象を受ける人が少なからずいるはずです。
ここまで書いたBEMの内容をまとめると、「理解すると便利だけどとっつきにくい設計手法」という感じになるかなと思います。
なんで便利なのにとっつきにくいの？と疑問に思う方向けに説明すると、CSS自体が非常に簡単に崩壊しやすい言語仕様になっているからです。
そのCSSを便利に安全に扱うために様々なルール、設計手法があると僕は考えています。
CSSの設計について気になる方は以下の記事をご覧ください。
実際に弊社では、BEMを用いてデザインシステムを開発しています。僕もいくつかBEMでデザインシステム を実装してみて感じた感想を以下に述べます。
また、デザインシステムの設計にAtomic Designが用いられているため、Atomic Designについての用語が出てきます。以下の記事でAtomic Designについて軽く解説されているので、Atomic Designをあまり知らない人はこの記事に軽く目を通してから読んでもらえるとより理解が深まると思います。
atomには基本的に他コンポーネントを含まないものになっています。そのため、何も考えずにBEMの基本的な命名規則に沿ってhtml/cssを書いていくことができるため非常に相性が良いと感じました。普段であれば悩むような状態が違うものや形状が違うものの命名に関しても機械的に作業を行っていけるためとても効率がよかったです。
これは単純に自分の練度不足でもあるのですが、Molecule以上の、一つのコンポーネント内に複数のコンポーネントを含むものに関しては少し実装者の慣れが必要だと感じました。
どこまでを親コンポーネントの責務とし、どこまでを子コンポーネントの責務とするのかに少し悩み手が止まることが、ままありました。
子コンポーネント同士の位置関係（paddingやmargin,flexなどなど…）に関してはできる限り親コンポーネントに書くことと、またその際に、親コンポーネント側に子コンポーネントを入れるためのラッパー的なクラスを用意することを意識するようになってからはだいぶ悩まずにかけるようになりました。
CSS設計をせずにコーディングをしてしまうと、ぱっと見でCSSのなにがおかしいかなどはレビューが難しいところです。
しかし、BEMを用いることで、UIをどのようにコンポーネント化して認識しているのかがコードから読み取ることができるようになります。
そのため、レビューを行う際に実装者がどのようにコンポーネントを認識しているか、またそれをどのように変えればよりよくなるかなどが、クラス名やコードで表すことができる点はとても優れていると感じました。
BEMのCSS設計はかなり有名であると思います。その一方で、その特性から毛嫌いしている人や難しいと感じる人もいるかと思います。僕も実際に学んで実践してみるまではそのような印象でした。
今実際に使うようになってみると、とても便利です。記事内でも書いたように規則に沿って開発を進められるためクラス名やHTML構造に対する悩みに対して明確に解答を出せることが何よりのメリットだなと感じました。
そのため、CSSの設計手法として非常におすすめです。
導入する際の注意点としては、チーム内で規約の認識のすり合わせをレビューのタイミングでできるだけ行うことです。
Fixelではリモートワークでスムーズなコミュニケーションを行うために様々な仕組みやシステムを導入しています。
気になる方は以下の記事をご覧ください。
新卒でオンライン学習サービスのフロントエンドエンジニアを経験。新規マッチングサービスのフロントエンド、5年以上続くサービスのシステムのフルリプレイスを経験。その後受託開発ではサーバーサイドおよびインフラも経験し、2020年3月にFixelに入社。Fixelでは主にフロントエンド開発やコーディングを担当。
