はじめに

「SCSSってなんだか難しそう…黒い画面でコマンドを打つんでしょ?」 食わず嫌いでずっとCSSを書いていた私ですが、実際に触ってみたらその認識は間違いでした。

結論から言うと、SCSSは「CSSの書き方がそのまま使える、便利機能付きのCSS」です。 今のCSSの知識が100%活かせて、さらにコードを書く量が半分以下になる。もっと早くやっておけばよかったと後悔しました。

この記事では、WordPress制作などを想定した「実務で使えるSCSS環境」を最短で作る方法をまとめます。

準備:VS Codeで自動コンパイル環境を作る

ブラウザはSCSSを理解できないので、CSSに変換(コンパイル)する必要があります。 難しそうに聞こえますが、VS Codeなら拡張機能一つで全自動化できます。

手順①:拡張機能を入れる

VS Codeの拡張機能検索で「Live Sass Compiler」と検索しインストールします。

手順②:書き出し先の設定(ここがキモ!)

デフォルトだとSCSSと同じ場所にCSSが出来て邪魔なので、フォルダを自動で分ける設定をします。

  1. VS Codeで F1 キー(または Ctrl+Shift+P / Cmd+Shift+P)を押す。
  2. Open User Settings (JSON) と入力して選択し、設定ファイルを開く。
  3. 以下のコードを、波括弧 { ... } の内側に追記(コピペ)してください。
// Live Sass Compilerの設定
"liveSassCompile.settings.formats": [
    {
        "format": "expanded",     // 見やすい形式(圧縮したい場合は "compressed")
        "extensionName": ".css",
        "savePath": "/css"        // ★ここが重要!「css」というフォルダに書き出す指定
    }
],
"liveSassCompile.settings.generateMap": true, 
"liveSassCompile.settings.excludeList": [
    "/**/node_modules/**",
    "/.vscode/**"
]

これで、scssフォルダで保存するたびに、勝手にcssフォルダが作られ、そこにcssが書き出されるようになります。

フォルダ構成とファイルの役割

実務では、1つのファイルに何千行も書くことはありません。
「パーツごとにファイルを分けて、最後に合体させる」のが基本です。

おすすめのフォルダ構成

プロジェクト/
  ├── style.scss  (司令塔)
  │
  ├── foundation/ (土台)
  │    ├── _variables.scss
  │    ├── _reset.scss
  │    └── _base.scss
  │
  ├── layout/ (共通パーツ)
  │    ├── _header.scss
  │    ├── _footer.scss
  │    └── _sidebar.scss
  │
  └── object/ (部品)
       ├── _card.scss
       ├── _button.scss
       └── _title.scss

_(アンダースコア)の意味

ファイル名の先頭に_をつけると「これは部品だから、これ単体ではCSSファイルを作らないでね」という合図になります(パーシャルと言います)。

style.scss(司令塔)

ここではコードを書かず、下記のように部品を読み込むだけです。

// style.scss
@use "foundation/variables" as *;
@use "foundation/mixin" as *;
@use "layout/header";
@use "layout/footer";

これだけ覚えればOK!3つの便利機能

ネスト(入れ子)

CSSを書くとき、.card .title.card .text.card .btn…のように、親要素のクラス名を何度も繰り返して書くのが面倒ではありませんか?
SCSSでは、HTMLの構造と同じように「入れ子(ネスト)」で書くことができます。

メリット

  • 「&(アンパサンド)」を使えば、ホバー時(:hover)などの指定もその場に書ける
  • 親クラス名を何度も書かなくていい(タイプミスが減る)
  • HTMLの構造と同じ見た目になるので、直感的に分かりやすい
.card {
  background: #fff;
  width: 100%;

  // .card .title と同じ意味になります
  .title {
    font-size: 20px;
    font-weight: bold;
  }

  // .card .btn と同じ意味
  .btn {
    background: blue;
    
    // ★重要:「&」は親要素(.btn)の身代わり!
    // コンパイル後は .card .btn:hover になります
    &:hover {
      opacity: 0.8;
    }
  }
}

変数(Variables)

サイトのテーマカラーや共通の余白サイズなどを「変数」として定義できます。
普通のCSSでも変数は使えますが、SCSSの変数は記述が短く、計算もできるのが特徴です。

メリット

  • 「青を少し濃くして」と言われても、変数の定義を1箇所書き換えるだけで全ページに反映される
  • カラーコード(#3498db)を覚える必要がなく、「$main-color」という名前で管理できる
// foundation/_variables.scss で定義

$main-color: #3498db; // サイトのメインカラー
$font-base: 16px;     // 基本フォントサイズ
// layout/_header.scss で定義

@use "../foundation/variables" as *;

.header {
  // ここで色を指定しておけば、後で一括変更可能
  background-color: $main-color; 
}

.title {
  // 計算もできる!(16px * 1.5 = 24px になる)
  font-size: $font-base * 1.5; 
}

Mixin

SCSSで最も感動するのがこの機能です。
通常、メディアクエリ(スマホ対応)はCSSファイルの末尾にまとめて書くことが多く、「PCのデザイン」と「スマホのデザイン」の記述場所が離れてしまいがちでした。

Mixinを使えば、「PC用のスタイルのすぐ内側」にスマホ用スタイルを書くことができます。

メリット

  • 「PC用」と「スマホ用」のコードがセットになるので、見やすい
  • 修正漏れがなくなる(PCを変えたらすぐ下のスマホ用も目に入るため)
  • @media (max-width: 767px) という長い記述を毎回書かなくて済む
// foundation/_mixin.scss

// スマホの分岐点(ブレイクポイント)を設定
$breakpoint: 767px;

// "sp" という名前の便利機能を作る
@mixin sp {
  // 画面幅が767px以下の時だけ...
  @media (max-width: $breakpoint) {
    // ★ここに、あとで書くスタイルが挿入されます
    @content;
  }
}
// 使い方

@use "../foundation/mixin" as *;

.container {
  width: 1000px; // PC用
  display: flex;

  // 魔法の呪文「@include sp」
  @include sp {
    width: 100%;    // スマホ用
    display: block; // スマホ用
  }
}

注意点:初心者がハマりやすい「変数の壁」

ファイルを分割した際、「style.scssで変数を読み込んでいるのに、各ファイルで変数が使えない!」という現象に遭遇しました。

これはSCSS(Dart Sass)の仕様で、ファイルはそれぞれ独立しているためです。
変数を使いたいファイルでは、必ずその都度 @use を書く必要があります。

// _header.scss の先頭に必ず書く!
@use "../foundation/variables" as *;

.header {
    color: $main-color;
}

「とりあえずファイルの先頭で変数とMixinは読み込んでおく(おまじない)」と覚えておけばOKです。

さいごに

「新しい言語を覚えるのは大変そう…」 以前の私もそう思っていましたが、今回紹介した通り、SCSSの導入に必要な時間はわずか10分程度です。

VS Codeと拡張機能さえあれば、難しいコマンド操作も必要ありません。
それでいて、一度環境を作ってしまえば、以下のようなメリットがずっと続きます。

  • 修正箇所が一瞬でわかる(ファイル分割のおかげ)
  • スマホ対応の書き忘れがなくなる(Mixinのおかげ)
  • コードを書く量が圧倒的に減る(ネストのおかげ)

修正や運用が長く続くプロジェクトにおいて、「読みやすく、修正しやすいコード」を残すことは、将来の自分(やチームメンバー)を助ける最大の投資になります。
まだSCSSに触れていない方は、ぜひ次の案件から小さく始めてみてください。