本文へスキップ
スキルアップカレッジ

保守できる CSS へ——リファクタリングとチーム運用

レッスン8：保守できる CSS へ——リファクタリングとチーム運用

このレッスンで学ぶこと

  • 既存の CSS を整理する順序を理解する
  • 消してよい CSS の見分け方を身につける
  • コードレビューで見るべき観点を理解する
  • 新しく入った人が迷わない構造と、修了後の学習の方向を理解する

前回のレッスンでは、デザイントークンと部品カタログを組み合わせて、小さなデザインシステムを組み立てる方法を学びました。最終レッスンとなる今回は、すでに存在する CSS をどう整理し、チームで保守し続けるかという、現場でもっとも実践的な課題を扱います。

既存の CSS を整理する順序

すでに動いている CSS を整理しようとするとき、多くの人はいきなり細かい部分から手を付けたくなります。ですが、順序を誤ると、途中で全体像を見失い、整理そのものが途中で止まってしまいます。

本コースで学んできた内容を踏まえると、次の順序が無理のない進め方です。

flowchart TD
  A[1. 全体を眺めて重複を把握する] --> B[2. 値をデザイントークンに切り出す]
  B --> C[3. 名前を役割ベースに整理する]
  C --> D[4. 部品として境界を引き直す]
  D --> E[5. 使われなくなったCSSを削除する]

この図は、レッスン1 からレッスン7 までの内容が、実は 1 つの整理の手順としてつながっていることを表しています。詳細度やカスケードの把握（レッスン1）から始まり、値の一元管理（レッスン3）、命名の整理（レッスン2）、部品としての境界の引き直し（レッスン5）を経て、最後に不要なコードの削除へと進みます。

最初から部品の境界を引き直そうとすると、値の重複や詳細度の混乱が残ったままでは、どこからどこまでが 1 つの部品なのかを正しく判断できません。まず全体の重複や詳細度の高いセレクタを把握し、値を整理してから、名前と境界を整えるという順番のほうが、途中で迷いにくくなります。

💡 ポイント 整理は一度にすべて終わらせようとしなくてかまいません。ページ単位、機能単位で少しずつ整理を進め、整理し終えた部分から順に「壊れにくい状態」を広げていくやり方でも十分に効果があります。

消してよい CSS の見分け方

CSS の整理で多くの人が悩むのが、「このスタイルは、もう消してよいのか」という判断です。判断の目安を 3 つ紹介します。

1 つ目は、対応する HTML がどこにも存在しないクラスです。

/* HTML側のどこにも .old-banner が見当たらない */
.old-banner {
  background: #f39c12;
  padding: 20px;
}

プロジェクト内を検索して、該当するクラス名が HTML やテンプレートのどこにも見つからなければ、そのスタイルは安全に削除できる可能性が高いといえます。

2 つ目は、別のスタイルによって完全に上書きされていて、実際には一度も適用されていないスタイルです。

.card {
  padding: 16px;
}

/* あとに書かれた同じ詳細度のルールが常に勝つため、上の指定は無意味になっている */
.card {
  padding: 24px;
}

レッスン1 で学んだカスケードの知識があれば、こうした「書かれているのに一度も効いていない」指定を見つけられます。ブラウザの開発者ツールで、取り消し線が付いたまま常に表示されているスタイルは、削除の候補になります。

3 つ目は、同じ役割を持つ部品がすでに複数存在し、統合できる場合です。

.notice-box {
  padding: 16px;
  border-radius: 4px;
  background: #fff8e1;
}

.alert-panel {
  padding: 16px;
  border-radius: 4px;
  background: #fff8e1;
}

.notice-box と .alert-panel は、名前こそ違いますが、指定している内容がまったく同じです。過去に別々の担当者が、同じ役割の部品を違う名前で作ってしまった典型的な例です。これらを 1 つの名前に統合できれば、CSS の量を減らしながら、部品カタログの見通しもよくなります。

⚠️ 注意 削除する前には、必ず影響範囲を確認してください。検索で見つからなかったからといって、JavaScript が動的にクラスを付与している場合もあります。削除は、テスト環境で表示を確認しながら、慎重に進める必要があります。

コードレビューで見るべき点

チームで CSS を書くようになると、コードレビューが CSS の品質を保つ重要な機会になります。本コースで学んだ内容にもとづくと、次のような観点でレビューできます。

観点 確認すること
詳細度 ID セレクタや深いネストを使っていないか（レッスン1）
命名 見た目ではなく役割にもとづいた名前になっているか（レッスン2）
値の重複 同じ値を 2 回以上書いていないか、変数にできないか（レッスン3）
部品の独立性 置かれる場所に依存したスタイルになっていないか（レッスン5）
状態の表現 状態を表すクラスと見た目のバリエーションが混同されていないか（レッスン5） 
/* レビューで指摘されやすい例 */
#top-page .promo-section .card.featured-item {
  margin-top: 40px !important;
}

このコードは、ID セレクタ・深いネスト・!important という、レッスン1 で扱った「強さで勝とうとする」書き方の特徴をすべて含んでいます。レビューでは、「なぜこの強さが必要になったのか」を確認し、多くの場合は役割にもとづく名前と、部品の外側で余白を調整する設計に置き換えられないかを検討します。

/* レビューを経て置き換えた例 */
.card--featured {
  background: var(--color-brand);
}

.promo-section {
  margin-top: var(--spacing-lg);
}

置き換えたあとは、.card--featured という Modifier がカード自身の見た目を担当し、余白の調整は .promo-section という置き場所の側が担当するという、レッスン5 の役割分担に戻っています。

📝 補足 コードレビューは、書いた人を批判する場ではありません。「このスタイルは、この部品の中に置いておいて大丈夫か」「ほかの場所に影響しないか」を、書いた本人と読む人が一緒に確認する場だと捉えると、指摘のやり取りがしやすくなります。

新しく入った人が迷わない構造

チームに新しいメンバーが加わったとき、CSS の構造そのものが「迷わずに済むかどうか」を大きく左右します。ここまでのレッスンで学んだ要素を、迷わない構造としてまとめ直すと、次のようになります。

flowchart LR
  A[デザイントークン<br/>1箇所にまとまった値] --> B[部品カタログ<br/>既存の部品の一覧]
  B --> C[命名規則<br/>役割にもとづく名前]
  C --> D[新しいメンバー<br/>迷わず既存の部品を再利用できる]

この図は、新しいメンバーが迷わずに作業を始められるまでに必要な要素のつながりを表しています。値がまとまっていること、部品が一覧できること、命名のルールが一貫していることの 3 つが揃って、迷わずに済む状態が作られます。

逆に、この 3 つのどれかが欠けていると、新しいメンバーは既存の部品に気づかずに似たようなスタイルを作ってしまったり、命名のルールがわからず独自の書き方を持ち込んでしまったりします。こうした小さなずれが積み重なることが、レッスン1 で扱った「CSS が壊れていく経過」の出発点でもあります。

🔰 初学者の方へ チームに新しく加わった立場で CSS を読むときは、「このプロジェクトのデザイントークンはどこにまとまっているか」「部品の一覧はどこで確認できるか」の 2 点を最初に探してみてください。この 2 つの在りかがすぐにわかるプロジェクトは、多くの場合、保守しやすい構造を持っています。

フレームワークでの CSS の扱い

ここまでは、CSS を単体のファイルとして扱う前提で学んできました。実際の制作現場では、React や Vue といったフレームワークを使う場面も増えています。フレームワークを使う場合でも、本コースで学んだ考え方の多くはそのまま活かせます。

フレームワークの多くは、部品（コンポーネント）を独立したファイルとして分割する仕組みを持っています。この仕組みは、レッスン5 で学んだ「部品は置かれる場所を知らない」という考え方と、方向性が同じです。1 つの部品を 1 つのファイルにまとめることで、その部品がどこで使われても同じ見た目を保ちやすくなります。

components/
  Button/
    Button.css
    Button.js
  Card/
    Card.css
    Card.js

このように部品ごとにファイルを分ける構成は、フレームワークの機能を使わなくても、ファイルの置き場所を工夫するだけである程度実現できます。フレームワークが提供するのは、主に「その部品専用の CSS が、ほかの部品に影響しない」ことを保証する仕組みです。命名の工夫や詳細度の管理といった、本コースで学んだ考え方の多くは、フレームワークを使う場合でも土台として必要になります。

📖 もっと詳しく 具体的なフレームワークの導入方法や設定は、それぞれのフレームワークに関する専門の教材で学ぶのがよいでしょう。本コースで学んだ命名・変数・部品化・詳細度の考え方は、どのフレームワークを選んでも土台として通用する知識です。

フレームワークの中には、部品ごとの CSS の影響範囲を自動的に区切る仕組みを持つものもあります。この仕組みがあると、名前の衝突は起きにくくなりますが、「部品が何の役割を持つかを考える」という作業そのものは、どのような仕組みを使っても変わらず必要です。

チームで CSS を運用するときの心構え

最後に、CSS をチームで長く運用していくうえでの心構えを 1 つ添えておきます。それは、完璧な設計を最初から目指さないということです。

本コースで学んだ命名規則やデザイントークン、部品カタログといった仕組みは、いずれも一度作ったら終わりではなく、使いながら少しずつ育てていくものです。レッスン7 の現場メモで触れたように、最初から細かいルールを作り込みすぎると、かえって運用がうまくいかなくなることもあります。むしろ、「いまのチームの規模と状況に見合った、最低限のルールから始める」という姿勢のほうが、長く機能する設計につながります。

コース全体の振り返り

最後に、本コースの背骨になっている考え方を振り返ります。

CSS が壊れるのは、書き方が下手だからではありません。どこに何が効いているかを追えなくなったとき、CSS は壊れます。この追跡のしやすさを保つために、本コースでは 6 個の中核メッセージを積み重ねてきました。

  1. CSS が壊れるのは、どこに何が効いているかを追えなくなったときである（レッスン1）
  2. 強さで勝とうとすると、次はもっと強く書くことになる（レッスン1）
  3. 名前は「見た目」ではなく「役割」で付ける（レッスン2）
  4. 同じ値を何度も書いた時点で、それは変数にすべきものである（レッスン3）
  5. 部品は、置かれる場所を知らないほど再利用できる（レッスン5）
  6. 守られないルールは、ルールが厳しすぎるからである（レッスン7）

この 6 個は、それぞれ独立した知識ではなく、互いにつながっています。詳細度を低く保つ（メッセージ 1 ・2）ことは、役割にもとづく名前を付けやすくし（メッセージ 3）、名前が整理されると値の重複にも気づきやすくなり（メッセージ 4）、その先に部品としての独立性（メッセージ 5）と、無理のない運用のルール（メッセージ 6）が積み上がります。

💡 ポイント 6 個のメッセージのうち、どれか 1 つだけを実践しても、CSS はある程度は改善します。ですが、真価が出るのは、6 個が組み合わさったときです。迷ったときは、この 6 個のどれに立ち返れば整理できるかを考えてみてください。

修了後の学習方向

本コースでは、CSS の設計・命名・変数・Grid・部品化という範囲を扱いました。ここから先、さらに学びを広げたい場合の方向をいくつか紹介します。

具体的な設計手法をさらに深める：本コースで紹介した BEM 以外にも、命名やファイル構成に関する考え方はいくつも存在します。プロジェクトの規模やチームの人数に合った手法を調べてみるとよいでしょう。

CSS の新しい仕様を追いかける：CSS は現在も仕様の追加が続いている分野です。基礎となる考え方を身につけておけば、新しい仕組みが登場したときも「これは何の役割を担うものか」という視点で理解しやすくなります。

実際のプロジェクトで手を動かす：設計の考え方は、知っているだけでは身につきません。自分のプロジェクトで命名やトークンの整理を試し、半年後に見返すことで、判断基準の意味が実感として理解できるようになります。

🔰 初学者の方へ 焦ってすべての知識を一度に身につけようとする必要はありません。まずは、いま自分が触っている CSS に対して、本コースで学んだ「役割で名付ける」「同じ値を 2 回書いたら変数にする」という 2 つの基準だけを適用してみることから始めてみてください。

実習：既存の CSS を整理する

次の CSS には、本コースで扱った複数の問題が含まれています。整理の手順に沿って書き直してみましょう。

#homepage .promo .card.featured {
  padding: 24px !important;
  background: #2c6cd4;
}

.notice-box {
  padding: 16px;
  background: #fff8e1;
  margin-bottom: 20px;
}

.alert-panel {
  padding: 16px;
  background: #fff8e1;
  margin-bottom: 12px;
}

手順は次のとおりです。

  1. #homepage .promo .card.featured の詳細度と !important を見直し、役割にもとづく Modifier（例：.card--featured）に置き換える
  2. #2c6cd4 のような値を、カスタムプロパティとして切り出す
  3. .notice-box と .alert-panel が同じ役割を持っていないか確認し、統合できるか検討する
  4. 統合する場合は、余白の違い（margin-bottom の値）を、部品の外側で調整する形に整理する
  5. 書き直した結果を、本レッスンの「消してよい CSS の見分け方」に照らして、削除できる指定が残っていないか確認する

書き直しの骨格は、次のように役割にもとづく名前だけが残る形になります。

.card--featured { /* ここに見た目を書く */ }
.notice-card { /* .notice-box と .alert-panel を統合した名前 */ }

まとめ

このレッスンでは、以下のことを学びました。

  • 既存の CSS を整理するときは、重複の把握から値・命名・部品の境界の順に進めると迷いにくいこと
  • 消してよい CSS は、対応する HTML がない、実際には適用されていない、同じ役割の部品が重複しているといった目安で見分けられること
  • コードレビューでは、詳細度・命名・値の重複・部品の独立性・状態の表現という観点で確認できること
  • デザイントークン・部品カタログ・命名規則の 3 つが揃うと、新しいメンバーが迷わず作業を始められること
  • フレームワークを使う場合でも、命名や詳細度の管理といった本コースの考え方は土台として活かせること

本コースでは、詳細度とカスケードの整理から始まり、命名・変数・Grid・コンポーネント指向・ユーティリティファースト・デザインシステム・リファクタリングまでを 8 レッスンで学んできました。CSS が壊れるのは、書き方が下手だからではなく、名前と責任範囲を決めていないからです。この考え方を手元のプロジェクトで実践し、増えても壊れない CSS を育てていってください。お疲れさまでした。

確認クイズ

このレッスンの理解度をチェックしましょう。