部品分類3つの視点

Capsule and Separation CSS

Webサイトの部品分類はCSS設計の要となり、とくに基底となる分類をどのようにおこなうかは、イニシャルの制作効率やローンチ後の保守効率にも影響します。
サイトの特性に適合しない分類にしてしまうと、どのような素晴らしい詳細ルールを定めても「期待する構造」や「予測した通り」ではないため、編集のたびに頭で変換する時間が必要となり、「わかりにくい」と感じやすくなります。

このためサイト種別や特性・規模により、人が理解しやすい構造を作成することが必要です。

理想の状態をつくるための条件

誰もが理解しやすい状態というのは、つまりは人の脳が理解しやすいということです。予測や期待通りに構造化されていれば「わかりやすい」となります。
以下のような内容が重要になるのではないかと思います。

格納ファイルの内容が予測しやすいディレクトリ名になっている
分類手法が整理されている。もしくは把握可能な指針が提供されている
ディレクトリの数が適量である
各ディレクトリに保存されているファイル数が適量である

適切なディレクトリ名は馴染みや習慣などによって異なり、堅牢性向上のための細かなルールもそれぞれが定めるものとなりますが、ディレクトリ分割およびそれにより収められるファイル数は、サイトの特性や規模によって最適なものが異なります。

ではどのように分類するかですが、既存の定番と呼ばれるCSS設計や、旧来から制作者が考案してきた方式を分解していくと、部品は以下の3つの視点で分類することが可能です。
これをそのままディレクトリ設計に使用します。

SRT分類法

1・粒度（Size）	言葉自体は粒の細かさや荒さを表します。部品の大きさ・小ささ、面積・規模・範囲などの大小の差による分類です。例）ボタン→粒度：小／ナビゲーション→粒度：中
2・役割（Role）	どのような役割があるのか。機能（Function）や用途・使い道（Use）によって与える役目による分類です。例）コンテンツ／ナビゲーション／サイトフレーム
3・対象（Target）	どのページや区域で使うのか。ページ内のどの場所に配置するのかなど、部品の配置先による分類です。例）HOME用の部品／下層ページ用の部品／ヘッダー用・フッター用

これらは設計のためのアプローチであり、そのものがルールではありません。上記のような視点をもとにサイト特性に応じて部品を分類し、組み合わせ、その意図を明示し、チーム間で共有することによって「理想の状態」に近づける事ができるのではないかと思います。

上記3つの視点によるディレクトリ設計例と、その他の例をガイドとして以下に記載します。

視点1・粒度による分類例

Objectを部品の「粒度」により分類した例です。
粒度分類のみを使用したサイト構築は、大多数のページで同じデザインを再利用することが多いサイト、例外パターンや独自パターンが少ないサイトに向いています。
たとえば「サービス系サイト」や「システム管理画面」、「アプリケーションサイト」などです。

object/

element/　…　ボタンやアイコンなどの最小部品を管理
module/　…　中粒度の部品を管理

「element/」は、「component/」や「atomic/」といった他の名前に変更する事で、基底とするCSS設計思想や使い慣れた手法に合わせる事ができます。この場合、「module/」も別の名称が適切となったり、別粒度の新たなディレクトリが必要になるかもしれません。

改変例 Atomic Designのデザインアプローチを踏襲

Atomic Designのデザインアプローチでは、部品を最小粒度まで分解したのち、その組み合わせの粒度に対して名前が与えられています。
そのプロジェクトのCSS設計として最適かどうかは別の問題となりますが、概念をそのままディレクトリとして以下のように引き継ぐことが可能です。

object/

atmic/　…　AtomicDesignの「原子」を管理（類似名称：element）
molecules/　…　AtomicDesignの「分子」を管理（類似名称：component）
organisms/　…　AtomicDesignの「有機体」を管理（類似名称：module）
templates/　…　AtomicDesignの「テンプレート」を管理

※「pages」は、部品の概念ではないため、標準分類の「pages」を使用する事になります。

視点2・役割による分類例

Objectを「役割」ごとに分類した例です。
役割は、機能や使い道によって与えられるものであり、その働きは明確です。直感的に理解しやすく、コーポレートサイトなどのデザイン先行型サイトにおいて、旧来のコーディング手法の延長線上で使用しやすいのではないかと思います。

object/

contents/　…　コンテンツ用の部品を管理
navigation/　…　ナビゲーション用の部品を管理
siteframe/　…　ヘッダーやフッターの部品を管理

上記の構造にした場合、ヘッダー、フッターなどのサイト定型部分と、下層ページのコンテンツの部品を明確に分離して管理可能です。
これにより、サイトのフレーム部分とページ量産を異なるスタッフで分業する時に、Gitなどのバージョン管理システムにおいてコンフリクトが起こりにくくなります。

視点3・対象による分類例

その部品をどこに配置するのか、ページや場所、位置などの「対象」によって分類します。

対象分類例1 コーポレートサイトにおける対象分類

コーポレートサイトにおいて、各ページでコンテンツ独自の表示パターンが多い場合、もしくはそのカテゴリの下層ページが多くあり、他の分類ではファイル管理が煩雑になる場合の分類例です。

object/

home/　…　HOMEで使用する部品を管理
service/　…　サービス紹介のカテゴリ全域で使用する部品を管理
product/　…　製品紹介のカテゴリ全域で使用する部品を管理
contact/　…　お問い合わせページで使用する部品を管理

対象分類例2 ページ内の配置場所による分類

ページ内の上部や下部など、部品の配置場所や領域による分類方法です。

object/

header/　…　サイトのヘッダー部分に配置する部品を管理
footer/　…　サイトのフッター部分に配置する部品を管理
main/　…　主にサイトのメイン部分（コンテンツ）で使用する部品を管理

対象分類例3 異なるデザインのページを統合するようなサイト

以下は、該当するサイトは少ないかもしれませんが、各ページのデザインがまったく異なるプロモーションページを、HOMEからの遷移のみで動線を繋ぐようなサイトで有用ではないかと思います。

object/

home/　…　HOMEで使用する部品を管理
product_nameA/　…　製品Aの紹介ページで使用する部品を管理
product_nameB/　…　製品Bの紹介ページで使用する部品を管理
product_nameC/　…　製品Cの紹介ページで使用する部品を管理

複合分類例

「粒度分類」「役割分類」「対象分類」を組み合わせた例です。
以下の分類方法以外にも、サイトの特性によってさまざまな組み合わせが考えられます。

複合例A 粒度分類＋役割分類

「粒度による分類」に、特定役割のCSSを管理するディレクトリ「helper」を追加した例です。
粒度分類した部品に対し、余白やfloatなどの情報をマルチクラスで付与していくことで構築するサイトに適しているのではないかと思います。

object/

element/　…　ボタンやアイコンなどの最小部品を管理
module/　…　中粒度の部品を管理
helper/　…　単一プロパティによる拡張Classを管理（類似名称：utility / property）

※FLOCSSのObject内部構造と類似しており、そのまま「component/ project/ utility/」に置き換えることができます。

複合例B 粒度分類 → 役割分類

「粒度による分類」の、「中粒度」のディレクトリ内部を更に役割で分類した例です。
最小部品の再利用と、独自パターンの中粒度部品が混在するようなサイトに適しているのではないかと思います。

object/

element/　…　ボタンやアイコンなどの最小部品を管理
module/　…　中粒度の部品を管理
- contents/　…　コンテンツ用の部品を管理
- navigation/　…　ナビゲーション用の部品を管理
- siteframe/　…　ヘッダーやフッターの部品を管理

複合例C 役割分類 → 粒度分類

「役割による分類」の後、粒度に分類した例です。
各役割の内部において、共通する最小部品の「配置パターン（中粒度部品）」がいくつかあり、その中粒度部品をCMSのテンプレートなどで出し分けする。といった場合に管理しやすいのではないかと思います。

具体例としては、ECサイトの「商品閲覧動線」「決済動線」「キャンペーンページ」「ランディングページ」など、異なる目的のページや領域における、ヘッダー、フッターの出し分けです。

object/

header/　…　サイトヘッダー用の部品を管理
- element/　…　ヘッダーで使用する最小部品を管理
- module/　…　最小部品の組み合わせパターンを管理
footer/　…　サイトフッター用の部品を管理
- element/　…　フッターで使用する最小部品を管理
- module/　…　最小部品の組み合わせパターンを管理
contents/　…　コンテンツ用の部品を管理

改変例D 大規模サイト用に細分類した例

階層数やページ数が多いコーポレートサイトなどで部品ファイルの数が多くなり、少ないディレクトリではファイル管理が煩雑になってしまう時の分割例です。

object/

element/　…　ボタンやアイコンなどの最小部品を管理
module/　…　中粒度の部品を管理
- contents/　…　コンテンツ用の部品を管理
  - common/　…　共通部品を管理
  - home/　…　HOME専用の部品を管理
  - [any_name1]/　…　そのページの専用部品を管理
  - [any_name2]/　…　そのページの専用部品を管理
- navigation/　…　ナビゲーション用の部品を管理
  - common/　…　パンくずリストやタブなどの共通ナビゲーション
  - gnav/　…　グローバル系のナビゲーション
  - lnav/　…　下層ページのローカルナビゲーション
- siteframe/　…　ヘッダーやフッターの部品を管理
  - header/　…　ヘッダー専用の部品を管理
  - footer/　…　フッター専用の部品を管理
option/　…　ヘルパーClassや外部製のCSSなどの管理
- property/　…　ヘルパー系の単機能Classを管理
- vender/　…　外部製のCSSを管理

ディレクトリを設置しない

分類によるディレクトリ設置をおこなわない例です。
シンプルなランディングページなど、部品数が少ない場合は、無理にサブディレクトリを設置するよりも「Object/」直下にすべてのファイルを置いたほうが見通しよくなる事が考えられます。
この場合、ファイルの命名などによってなんらかの分類をおこなうかもしれませんが、作業効率・見通しを優先した例となります。