１．CSSの部品分け

SassとPostCssを使うこと前提の部品分け。
できるだけ不要なスタイルはコードとしてビルドしない。

（１）スタイル集合

• 関連しあう配置、装飾の集合。
• セレクタの名前を原則使わない。（場所と部品に依存しない）
• mixinで管理。(mixinにすることで、必要なときだけ定義を利用）
• ベンダープリフィックスなどはPostCssのプラグインに任せて、シンプルに記述。

（２）共通部品のスタイル

• elementやboxのセレクタにスタイルを定義。
• mixinでセレクタごと管理。(mixinにすることで、必要なときだけ定義を利用）

（３）画面ごとに１つのCSSファイルを読み込み

• セレクタの定義をする際に、上記の「スタイル集合」や「共通部品」をincludeする。
• indexで各パーツを読み込み、一つのcssファイルにする。
• 共通部分などを分割して読み込むと、画面が増えるごとに衝突の可能性が高まり、定義が煩雑になる。

２．コードの重複やビルドサイズ

• いろいろな画面で、いろいろな定義を使い回すと衝突することがあり、importantなどの定義をつかった無駄な定義をする可能性がある。1画面1cssファイルにすることで、画面間の衝突を回避する。
• mixinでパーツを管理することで、必要なときに必要な定義を使う。
• 分割してCSSを読み込むと、何が使われているのかわからず、デバッグに時間をとる可能性が高いので、分割読み込みはできるだけしない。

３．肥大化回避の為、原則フレームワークは利用しない

• FlexやGrid、Sass、PostCssなど技術的な進展、IEの利用減少とブラウザの進歩により、技術的な差違を埋める必要が減ってきた。
• フレームワークを利用すると、汎用性があるが故に、不要な定義を利用する可能性がありビルドサイズが肥大化する。
• フレームワークは、プロトタイプなどすぐに作りたいなど時間短縮には有効であるが、会社のサービスであれば、必要な定義をmixinで管理して利用する方が細かい調整が効く。
• フレームワークを利用するにしても、mixin経由で定義を必要なときだけ利用する。

４．共通の定義を複数ファイルに分けて複数の画面で読み込む弊害

• 再利用性を考えて、共通の定義ファイルを独立して複数の画面で読み込むと、イレギュラーな画面があった場合に、定義の衝突が起きてしまう。
• 利用しない定義を読み込み、その分は、サイズの無駄になる。
• BEM記法など名前の衝突をしないための冗長なセレクタにせざるを得なくなる。