※注：個人の経験と主観を多分に含みます

まえがき

フロントエンドエンジニアと一口に言ってもその出自は様々で、バックエンドから入ってきた人たちは何となく CSS を目の敵にする傾向が強いような気がします。
確かにプログラム視点からみると貧弱過ぎてすぐに壊れる仕様に不満を感じる気持ちは分かりますが…
自分はというと HTMLコーダーから入ってきたクチなので CSS やその設計には全然抵抗ないです。（むしろ大好物）

面倒な CSS の管理を極力遺棄したい気持ちが高まった結果、CSS フレームワークの採用にたどり着くのはもはや必然なのかもしれません。
ただし本当にその選択は正しいんでしょうか…？

CSS フレームワーク導入による明るい未来の幻想

CSS フレームワーク導入推進派の意見を聞くと開発コストの削減や学習コストの低さ、品質を担保できるなどの利点が挙げられますが、実際に導入をした結果、負の面が噴出するケースに幾度となく遭遇してきました。

フレームワークの利点が実際の成果に反映されなかったケースを幾つか挙げてみます。

制作コストを削減できる

確かにイニシャルコストは削減できます。
ただしカスタムが前提の場合、フレームワークの制約がカスタムの足枷になることが多いです。
また事前にカスタムに対するレギュレーションを決めておかないと、直ぐに作業者ごとの「オレオレ CSS」が増えてカオス化、後の運用コストに跳ね返ってきます。
そして大抵の案件はカスタムせずに済むケースである方が少ないです。

作りきりの逃げ切り案件だったらまだしも、運用保守まで見据えると、ちゃんとカスタム部分のレギュレーションを決めておいた方が良いですし、コスト削減はトータルで見る必要があります。

学習コストが低い

メジャーな CSS フレームワーク（例えば Twitter Bootstrap とか）は制作経験者が多いという1点において学習コストは低いのですが、星の数ほどある様々なフレームワーク、少しでも王道から逸れると大多数の人にとっては初見のケースがほとんどだったりします。
公式の手厚いドキュメントも学習コストを低くできる一因ですが、案件には必要のない多機能なコンポーネントも内包されていたりして、必要最低限にコンポーネント設計したフルスクラッチの CSS に比べて見るべき部分が多かったりします。

引き継ぎは公式ドキュメントを案内すれば良い

カスタムしてない状態のフレームワークだったらその通りですが、カスタムしているのであれば追加・修正部分の補足情報はやっぱり必要になるため、公式ドキュメントのみ、という訳には行かなかったりします。
公式＋カスタム差分のドキュメントの合わせ技でフォローする必要はあります。

クオリティを担保できる

制作に関わる人が CSS フレームワークの仕様と制限、作法を正しく理解していることが前提です。
CSS の工数を減らしたい、手間をかけたくない、というモチベーションが先行してフレームワークの理解が少ないままにコンポーネントを量産すると、本来フレームワークで書くべきレイアウトやコンポーネントをオレオレ CSS で書いてしまい、亜種や派生が生まれてそこから管理が破綻していく、というケースを何度も見てきました。
クオリティを担保するにはフレームワークへの学習とレギュレーションの遵守が必要になります。

CSS フレームワーク導入検討するときに気をつける点

CSS フレームワークを導入してメリットを享受するには、以下の点をちゃんと事前に検討・対処した方が良いでしょう。

フレームワークの制約・仕様がプロジェクトの要件に則しているか

よく使われているから、くらいの安易な理由でフレームワークを導入すると痛い目を見ます。

採用されている CSS プリプロセッサ
コンポーネント粒度
カスタムのし易さ
コンポーネントの種類やボリューム

プロジェクトの規模や求められる機能・構成・要件によって使い分けられるように CSS フレームワークも複数の選択肢を持っておけると良いでしょう。

プロジェクト上のレギュレーションを明確にする

カスタムが前提の場合、CSS フレームワークの本来のレギュレーションだけでは不十分です。カスタム可能な範囲や追加の方針、命名規則、管理方法などを決めておかないと運用で担当ごとに重複や亜種が生まれて確実に死んでしまいます。
コンポーネントの修正や追加を行う場合は是非を含めてチームでのレビューが必須になります。

CSS フレームワーク導入をディレクター、デザイナーが認識している

フレームワークの仕様・制限の前提をある程度理解しないと、ディレクターやデザイナーからそれらを無視したワイヤーフレームやデザインが成果物としてが上がってきて、その内容の差し戻しなどの手間が発生してしまいます。
UI 設計が始まる前のキックオフミーティンなどで、事前にフレームワークの導入とメリット・制限を説明しておく必要があります。

まとめ

CSS フレームワーク向きの案件とは

とにかく工数圧縮、工期短縮が第一命題のプロジェクト
デザイナーがアサインできないプロジェクト
マークアップエンジニアがいないプロジェクト（CSS とか極力触らずに済ませたい人向け）

CSS フレームワークは UI 設計や HTML/CSS を他力にすることでショートカットするための仕組みなので、フルスクラッチなデザインが必須だったり、大幅に HTML/CSS を弄る必要がある案件は逆に制作の足枷になるケースが多いです。
逆にカラーパターンの調整など、最低限の変更で済ませてフレームワークの仕様に要件を寄せられる案件の場合は圧倒的コストパフォーマンスを発揮します。

CSS フレームワーク導入時に気をつけること

CSS フレームワークを導入するのであれば以下の点を考慮すると比較的案件が平和になります。

CSSフレームワークで規定されている以上のことはしない
ディレクター、デザイナーにフレームワーク仕様と画面設計の制限を認識・共有する
仕様に合わせてカスタムするのではなく、極力 CSS フレームワークの制約に沿って UI 設計・デザインを行う（そういった意味ではフロントエンド側である程度イニチアシブを取れないと色々とつらい）
カスタムする場合はカスタム部分におけるレギュレーションを明確にして品質を維持する

カスタム部分はフレームワークとは別系管理して切り離しておくことをオススメします。
俯瞰したときにどこまでがフレームワークで、どこからがカスタムなのかが、ファイル単位やレギュレーションレベルで明確にしておくと、理解しやすくなり管理効率も上がります。
別系管理にすることでフレームワークのカスタム汚染を予防してオリジナルの状態を保持でき、不具合発生時の影響範囲の切り分けもやり易くなります。