【CSS設計】FLOCSSを導入してみて気づいた８つのポイント

こんにちは。短期・単発専門アルバイトサイト「shotworks」など、複数の求人サービスを運営している会社、インディバルでwebデザイン業務を行っている居月です。
デザイナーブログ第二回目の今回は、弊社の新しいサービスにFLOCSSというCSS設計手法を導入したことについてお話ししようと思います。

FLOCSSとは

いくつかある有名なCSS設計手法の中のひとつで、その有名どころのOOCSSやSMACSS、BEM、SuitCSSのコンセプトを取り入れたのがFLOCSSです。オブジェクト志向で設計されています。

基本原則

詳しい説明は、公式（https://github.com/hiloki/flocss）などをご覧いただくとして、ここではサラッとご説明するにとどめます。

FLOCSSとは、CSSを以下のように「3つのレイヤー」と「その子レイヤー（3つ）」に分けて構築しましょう、という考え方です。
・Foundation
・Layout
・Object
┗ Component
┗ Project
┗ Utility

上記のレイヤーの各概要は以下の通りです。
・Foundation：
ブラウザのデフォルトスタイルの初期化や基本的なスタイル（全体の背景や基本となるタイポグラフィなど）を定義。
・Layout：
ヘッダー、フッター、サイドバー、メインコンテンツエリアなど、サイト全体のブロックを定義。
・Object：
サイト内で繰り返されるパターンを定義。

・Component：
再利用できる最も小さな単位のモジュールを定義します。ボタン、ナビゲーション、ページネーションなど。
・Project：
サイトの中で固有の見た目を有するものを定義します。弊社のような求人サービスだと求人リストのリスト表示などがこれにあたります。
・Utility：
細かく見た目の調整を行う時に必要なお役立ちスタイルを定義します。clearfixやmarginの調整、テキストの配置、横幅指定など。

FLOCSSを導入した目的

・なぜFlocksなのか？->上記にもあるように、ほかのCSS設計手法の「良いとこ取り」だから
・再利用しやすい（社内のほかの新しいサービスへも転用可能）
・保守しやすい

開発環境

今回のサービス開発環境は以下の通りです。

• CSSプリプロセッサー：SaSS
• テンプレートエンジン：Blade
• 統合開発環境：PHPStorm

フォルダー構成

├── foundation/
├── layout/
├── object/
│ ├── component/
│ ├── project/
│ └── utility/
├── pages/
└── common.scss

弊社独自ルール

「Page」をつくる
個別ページごとのcssを格納する「Page」というフォルダーを作成しました。
あるスタイルを「Projectに入れるべきかどうか？」と迷う場合が多く、そこに「Page」という区分がある事で「あ、これは◯◯◯画面でしか使わないから『pageの_◯◯◯.scssに入れよう』」と判断できるようになりました。

導入してみて思ったこと

（１）common.cssが重い

「common.scss」には「Foundation」「Layout」「Object」「Component」「Project」「Utility」のscssファイルが全部で30も含まれています。（弊社では最終的にその状態になりました）
この6つのレイヤーに含まれるファイルのいずれかを修正すると、「common.css」のコンパイルが自動で実行されます。（そのように環境設定しています）
見た目の修正作業のフェーズで、「作業中」のスピナーが回るのを19回も数えるほどコンパイルで待たされるのは、正直言って精神衛生上あまり良くないです。ただ、これに対する解決策は今のところ見つけられていません。

緊急回避的に、「修正中の画面のためだけのscssファイル」がある場合はそのファイルに「common.css」のコンパイル対象となる記述を書いてしまう（コンパイルを避ける）というテがありますが、これは「後で消すのを忘れる」リスクとバーターなので強くおすすめはできません。

（２）「Component」に必要なものをあらかじめ定義していなかった

「Component」は一番「育て甲斐」のあるレイヤーだと思います。効率良く整理された「Component」のファイルは、他のサービスにそのまま転用が可能だからです。（Bootstrapを触ったことがある方ならそのイメージは持ちやすいと思います）
できればgeneralな要素を事前に検討して用意しておくと設計当初の時間が短縮されるように思います。
なお、今回の案件ではグリッドの概念を持ち込まなかったのですが、FLOCSSの説明をしているサイトの大半ではサンプルとして「_grid.scss」という記述が「Component」の中にあり、検討してみる価値があるのではないかと感じました。

（３）「Project」の定義が難しい

ほかのレイヤーは、そこへ格納すべきモジュールの定義が明確でかなり判別しやすいのですが、「Project」は判断が難しかったです。とあるスタイルについて、それが「Projectなのか？Pageなのか？」は都度判断で行うしかありませんでした。
最終的に、弊社では「Project」レイヤーに格納すべきものを「サイト内で複数回使い回すもの」と定義しました。それ以外の、固有ページで一度しか使わないスタイルはPageレイヤーに格納することにしました。

（４）SaSSとFLOCSSは親和性が高い

マルチクラスのFLOCSSは、同じ名前のblock要素を何度も書く必要があります。これがSassだと「&」を使って楽に記述できるのがいいですね。
ただ、「Component」レイヤーでは入れ子が深くなる傾向にあるので、この部分でもっと視認性の高い記述の仕方を検討する必要はあるのかもしれないなと感じました。

（５）ソースを見ている時に迷いがない

BootstrapなどのCSSフレームワークなどもそうですが「自分がイチから構築したのではない」ソースに触れる時、何かひとつ修正したいのにどこにその記述があるかパッと見て分からないという状況を体験した事がある方は多いのではないでしょうか。
FLOCSSでは「接頭辞の付与」というルールがあるので、「Component」なら「c-」、「Project」なら「p-」、「Utility」なら「u-」といった風に、ソースを見ている時点でCSSの所在がおおまかに掴めるのがとても便利でした。
（接頭辞がついていないclassは「（ファイル）数が少ない」「普段ほとんど触らない要素」もしくは「今修正中の画面固有のcss」なので影響が少ないです）

（６）後から参加する人は「一度全部cssを読んで概要をつかむ」必要がある。

今回の案件は「CSS設計に関わっていない人間（私）が後からコーディングに参加する」という状況にありました。この場合、FLOCSSは全体の把握をするための時間が必要だと感じました。（その為の時間をスケジュールの中で取っていただけたのは本当に助かりました）
自分がコーディングを担当するのではない画面も含めて、各要素がどのレイヤーに格納されているのか？を確認します。そのうえで自分が担当する画面に着手できるようになります。

（７）途中で修正が必要

今回は「サイト全体の細部が未定」な状態でcss設計をしたので、後になって「これは他のページでも使い回す」といった事が分かり、「Page」から「Project」へ移す…といった事が多かったです。
ただ、CSSでよくある「勝手なルール」は発生しにくくなるなと感じました。FLOCSSという枠がハッキリ・カッチリしている分、そこから外れたものは「極端にルールから外れているので見つけやすく」なり修正も容易です。

（８）他のサービスにも転用可能

上記（２）とも一部重複しますが、特に「Component」レイヤーは転用可能度が高いです。
今回のサイトでは作らなかったモジュールでも、今後たくさん定義され、それが積み重なっていけば、その分だけ新しいサービスを作る時に便利になると感じました。

おわりに

自分は導入当初、「マルチクラス」に頭を切り替えられなくて苦しみ、その余波で「ProjectのElement」命名に苦しみました…。が、慣れると「これはいいものだ！」と思えるようになりました。
今回ご紹介した案件のPhase2のリリースが待っているので、引き続きFLOCSSとお付き合いしていこうと思います。
最後まで読んでくださってありがとうございました。