はじめまして、フロントエンドエンジニア・ディレクターの黒田です。
2024年現在、HTML/CSSコーディングは「CSSルネサンス」と比喩されるほど、CSSの機能進化が激しく、制作の難易度は年々上昇しています。それに伴いコーディングの設計力も必要となり、その代名詞とも言える「CSS設計」の言葉は、制作者であれば誰もが一度は聞いたことがあるのではないでしょうか。
私自身、CSS設計については何年も考え続けてきましたが、ふと、もし誰かに「CSS設計ができるようになるまで教えて」と依頼された場合はどうするだろう？と、考えました。
そういえば、CSS設計が出来るようになるまでのロードマップって見かけたことがないなぁ、と思い、モノは試し、今回はその視点で書いてみようと思います。
CSS設計が「できる」ようになるまで
まずは、何をもって「できる」なのかを定めてみます。
CSS設計の範囲は多岐に渡るため、ここでの「できる」は、「CSS設計の根幹を理解して、HTML/CSSコーディングの設計力と応用力が身につくまで」としてみます。イメージは、実装前もしくは実装時に最善の方法を考案でき、方針を決定できるレベルです。
そして、対象もつぎのように定めておきます。
- 対象者 … CSS設計を学び始めた制作者
- 制作方法 … JavaScriptによるインタラクションやCSS in JS、その他のプログラムは含まない
- サイト種別 … 企業サイトやブランドサイトなどの一般的な情報発信のためのWebページ
早速ですが、私が考えたロードマップはつぎの通りです。
- CSS設計の本質を捉える
- CSS設計のよくある誤解を解く
- 設計と手法、標準化の違いを知る
- 学ぶべき対象と内容を知る（座学）
- 著名なCSS設計手法から概念を学ぶ
- 命名規則の重要性と構成要素をそれぞれ学ぶ
- 実際に手を動かして学ぶ（実践）
- ドキュメントとしてアプトプットする
- 実際に作ってみてバージョンアップを繰り返す
- 繰り返して練り上げる
以下、それぞれの要点を書いてみたいと思います。
1・CSS設計の本質を捉える
CSS設計のよくある誤解
CSS設計を学び始めた段階では、「CSS設計とはBEMやFLOCSSなどのこと」と理解している方も少なくないと思います。これは完全に間違いとは言いませんが、完全な正解とも言えません。
誤解を恐れずに言えば、CSS設計とは『CSSの仕様に振り回されないように、あれこれ考えて決めた方法やルール全て』のことです。
全てとは、CSSのセレクタとプロパティ記述方法であり、命名規則であり、CSSの役割を定義する概念でもあります。また、これらから波及してHTMLコードの構造や、CSS(SCSS)ファイルやその他メタファイルの管理方法にも影響します。
個人的には、もう、CSS設計じゃなくて「コーディング設計」と呼べばいいんじゃないの？とも思ったりします。
少し話が逸れましたが、先に挙げたBEMやFLOCSS（その他にもOOCSS、SMACSS、MCSSなど）の方法論に話を戻すと、これらは設計方法を定型化した「手法」です。これらは業界内で今も語り継がれていますが、基本的には「どこかの現場で考えられた工法の一種」と言えます。
正解のない世界
なぜこのような言い方をするかというと、CSS設計には絶対的な正しさが無いからです。
CSS設計を学びはじめた頃は、BEMやFLOCSSなどの方法論が絶対的な教則のように見えることがあります。これらを学ぶと魔法のように良いコードが書けるのではないか、と期待してしまうような状態です。しかし、そのように捉えて学び続けていると、どこかで「結局何が正解なのか分からない」となりかねません。
というのも、CSS設計の最適解は、複数の要素が絡み合い変化するためです。
たとえば、企業サイト、システム管理画面、キャンペーンLPなど、制作物の種別によって設計の最適解は異なります。また、たとえ同じ種別であっても、デザインやオブジェクトの共通性によっても変化し、さらには納期的な制約や社風、チーム編成などによっても変わります。
そもそも、作りたいものに対して最適な工法を選ぶべきなのに、工法の1種を万能として利用するとミスマッチが起こりかねないということです。（比喩すると、鉄筋コンクリートの工法で犬小屋をつくる、みたいな事です）
何か1つの方法論に対して期待が高まりすぎると、迷路に迷い込む感覚になるため注意が必要です。
全ての情報は単なる参考資料
設計力を高めるために重要なことは、CSS設計や手法を表面上のルールとして暗記するのではなく、本質が何かを捉えるように努めることです。
本質が何かを捉えるには、まずは先人たちの知恵を学ぶことから始めます。このとき、これから目にする全ての情報は「自分が設計できるようになるための道具にしかすぎない」との心構えを持ちます。
あえて強めの書き方をしたのは、先に述べたように、素晴らしい概念に触れれば触れるほど、それが全て正しいように錯覚してしまうことがあるためです。
すべてが参考資料であり、工法を用いて設計を制するのは自分自身と考えておきます。
2・学ぶべき対象と内容を知る（座学）
最初はとにかく数多くの工法を知ることが重要です。加えて、命名規則について学ぶことも外せません。
最短ルートで設計力を高めるには、以下の2つを意識するのがおすすめです。
- 著名なCSS設計手法から「概念」を学ぶように意識する
- 命名規則の重要性を意識し、分解してそれぞれを学ぶようにする
※ もちろん、新しいCSSプロパティや実装方法を学ぶことも重要ですが、これは通常の学習範囲として今回の記事からは除外します。
著名なCSS設計手法から何を学ぶのか
CSS設計手法の歴史は、ある種CSSのグローバルスコープとの戦いの歴史です。
おおよその手法では、意図しないCSSプロパティ汚染が発生しないような試みがなされていますし、また逆に、より素早く認識を合わせるための試みもあります。これらの試みや考え方を具体化したものがルールです。どんな手法を学んでも、「マイナスの除去」と「プラスの醸成」の目的があり、「これは一体何をしようとしているのか」を考えることで、定められているルールが腑落ちしやすくなります。
著名なCSS設計手法は、それぞれに考え抜かれた概念があり、その思想とも呼べるものを学ぶことが、本質的な学びになります。
具体的に何をどれだけ学ぶか
では、何をどれくらい学べば良いのか、についてですが、以下にざっと挙げてみました。
読書においては「目的読み」や「課題読み」と呼ばれる方法がありますが、これと似たようなことができるよう、学べる内容を端的に表現しています。
- OOCSS … スタイルの責任を分離してCSSを管理する概念を学ぶ
- SMACSS … CSSの役割を分類する概念を学ぶ
- MCSS … CSSを階層構造（マルチレイヤー）で捉える概念を学ぶ
- ECSS … 影響を分離することで成果物を永続化させる考え方を学ぶ
- BEM … 命名継承によるセレクタ重複回避方法と、修飾子による拡張の概念を学ぶ
- ITCSS … 細分化されたレイヤーの概念と詳細度の設計について学ぶ
- FLOCSS … 様々な方法論を組み合わせた工法として、実務にどう落とし込むかを学ぶ
こうして見ると、それぞれの工法から学べることには違いがあります。
それぞれを設計のパーツと考え、本質的な共通点を探し、定義の最大値を探ってみます。そうすることで、設計に関する重要な概念が浮き彫りになってきます。
コンポーネントとの出会い
学習を進めていくと「コンポーネント」のキーワードが出てきます。
簡単に説明すると、コンポーネントとは再利用可能な「部品」のことであり、独立して動作するボタンやナビゲーション、モーダルウィンドウなどのことです。
コンポーネントについて学んでいくと、どこかで「Atomic Design」の考え方に遭遇し、「デザインシステム」や「ユーティリティファースト」などの話も混ざってきます。また別軸では、CSSのスコープをJavaScriptで制御する方法とも出会います。そして、どのようなWebサイトであってもコンポーネント化して組み合わせることが正義のように思える瞬間があります。
しかし、これも工法の一種でしかありません。
コンポーネントは、フロントエンド開発として語るのか、Webページ制作として語るのかによって重要度が変わる、最も「沼りやすいテーマ」です。
最初に定義した条件に従い、デザインシステムやコンポーネント、ユーティリティファーストなどの話は、Webサービスや管理画面のUIの話であると一旦割り切っておきます。
命名規則は設計の根底を支える
さて、ここまでは手法の話でしたが、それよりももっと根幹的で大切なものがあります。
それが、HTML要素に対する「命名規則」です。
コーディングは基本的に文字列の羅列・塊であり、デザインのように形状や色などで認知を操作できません。単語ひとつ、語感の共通認識が異なるだけで予測しやすさも大きく変化してしまいます。ゆえに、何においても命名をおろそかにしない意識が大切です。
命名規則と一言で言っても、内容はいくつかの要素で構成されます。
ここでは、命名規則を分解して、何を学ぶべきなのかを明確にします。
命名規則を分解するとつぎのようになります。
- 単語そのものの選定方法
- 単語の連結方法
- 単語の拡張方法
- 接頭辞と名前空間
1 の単語の選定は、デザインで表現されている対象要素にどんな単語を割り当てるかを考案することです。命名に利用する文字列は、業界で慣例的に利用する英単語と、コンテンツによって選定する英単語、その他は固有名詞、業界専門用語などがあります。
2 の単語連結方法は、単語同士の連結方法をどうするかです。古くはケバブケース、スネークケース、キャメルケースなどの記法があり、近年では単語の連結方法に意味を持たせたBEM（MindBEMding）の記法を思い浮かべるとわかりやすいです。
3 の単語の拡張は、コーディングの側面も強くなります。単語そのものに別の単語を加えて拡張するのか、OOCSSやBEMのモディファイアのようにマルチクラスで拡張するのかなどのアプローチを深堀りします。
4 の接頭辞と名前空間は、単語の機能を素早く識別したり、命名の重複を避けるための考え方です。c- や l- 、is- など様々なルールがありますが、これらをどのような意味で使うかを学びます。名前空間はもとはプログラミングの考え方ですが、この概念も把握しておくと良いです。
命名規則とは、おおざっぱに言うとこれらの組み合わせであり、そのルールです。
専門書やブログ記事などを読むときには、「あぁ、これは 2 の話をしているな」などと意識すると理解がしやすいと思います。
3・実際に手を動かして学ぶ（実践）
座学のつぎは、実際にアウトプットして学びます。
おすすめの方法は、自分の制作ルールをドキュメント化（言語化）することです。以下2つを自分でまとめてみます。
- 単語帳の作成 … 制作で利用する単語とその意味を一覧化する
- 制作ルールの作成 … 既存のCSS設計手法のように制作ルールを定める
ツールは何でも良いですが、単語帳はExcelやGoogleスプレッドシート、制作ルールのドキュメントはMarkdownで書くのがおすすめです。
単語帳の作成をおこなうと、今まで曖昧に使っていた単語の意味を考えるようになります。突き詰めるとリストはかなり長くなりますが、「なぜここでこの単語を使わなければならないのか」まで掘り下げて考え、単語に対して役割や使い所などの説明を加えます。
制作ルールの作成については、状況によって2つに分かれます。
パターンA・すでにコーディング規約がある場合
もし、すでにチームに所属していて何らかのコーディングルールがあるなら、それを自分なりにドキュメントにまとめ直します。このとき、必ず自分なりの解釈を添えます。なぜこのルールなのか、座学で学んだことをフル活用して言語化します。
そして、逆に何が定められていないかにも着目します。なぜ定められていないのかを先輩に聞いたり、自分なりに予測してみると、意外な発見があったりします。
この学習工程で重要なのは、自分が学んだことが正しいと思い込むのではなく、目の前にあるこのルールの裏にどんな背景があるのか、どのような気付きあるだろうか。と考えることです。
これにより、新たな発見を積み重ね、設計に関する理解度を上げていきます。
パターンB・自分で規約を作る場合
自身の環境で規約が定まっていない場合や、フリーランスで活動している場合など、自分で最初から制作ルールを作る場合は、まず最初にスコープを定めます。
たとえば、「数ページから20ページ前後までのコーポレートサイト」「一定期間で破棄されるLP」などの設定です。この設定をおこなうと、作業中に「この条件だとこのケースは切り捨てられる」などの判断がつきやすくなります。
規約をドキュメント化するときには、概念だけでなく具体的なサンプルコードを含めるようにします。
4・繰り返して練り上げる
設計力を高めるには、ここまでの内容を可能な範囲で繰り返します。
実際にコードを書いてみると、今まで気づかなかったことに遭遇します。たとえば「規約で明示していないパターンがでてきた」とか、「思ったようにうまくいかない」「規約を守ることで新たな問題が発生した」などです。
その都度、座学で学んだ先人たちの知恵を思い出し、最適解を考えます。そして、それを踏まえた上でもう一度ドキュメントにアウトプットします。
このような思考と言語化、体感の繰り返しで、コーディングの設計力と応用力は高まります。
さいごに
ここまで「CSS設計が出来るようになるまで」のロードマップと内容を考えてみましたが、最終的には自分が身を置く環境において、観測できる範囲でしか設計力は伸びません。
たとえば、Webシステムのフロント画面をつくるのが仕事の制作者と、インハウスで多くのキャンペーンLPを短期間でつくるのが仕事の制作者では、設計の思想や考え方そものが異なります。
それでも、「この条件で縛った場合はなにが最適解だろうか？」と、頭の中でロールプレイングすることで設計の幅を広げることはできます。
このような、たゆまない学習と実践を繰り返した先に得られるのは「確信」です。
同じコードを書いたとしても、記述に迷う時間が圧倒的に減り、確信に裏打ちされたコードは後続の制作者（実装仕様を忘れた未来の自分自身も含め）にとって優しいものになるはずです。
つまり、設計力を高める行為は「思いやり力を高めること」と、さいごは綺麗めにまとめて終わりたいと思います。
黒田 真一朗
この記事を書いた人