はじめに
今までのMPAの新規プロダクト開発では、デザイナーさんにデザインを作ってもらい、
それをコーダーさん（デザイナーを兼ねている場合あり）にHTML、CSSに落としてもらい、
エンジニアがWebアプリにHTML、CSSを当て込む という流れでプロダクトの開発を行っていました。
SPAの新規プロダクト開発でも同じような流れ、役割分担でプロダクト開発をおこなっていったのですが、
WebアプリにHTML、CSSを当て込む段階で上手くいかず、負債になってしまったので、反省も込めてアウトプットしたいと思います。
（デザイン、HTML&CSSに落としてもらうところまでは上手くいっていました。）
フォルダ構成や設計
CSSのフォルダ構成や設計は
- base(共通で利用するパーツのcss)
-_button.scss
-_modal.scss
- page(ページ単位)
- auth
- parts(ページ固有のデザイン)
- _body.scss
- style.scss（そのページで利用するパーツのcssを読み込むファイル。エントリポイント的なファイル）
のようになっていて、
Vue側では
- components
- pages
のような構成になっていました。
当て込み方
まず共通の部分を読み込むために
main.tsでbaseフォルダ以下のscssファイルをimportする形にして、
pages配下のコンポーネントではpartsフォルダ以下のscssをimportするようにしました。
componentsフォルダ配下のコンポーネントに関しては
コンポーネントに切り出したものの、切り出したHTMLがページ単位のCSSに依存していました。
Vueでは（おそらくReactでも）コンポーネント単位で閉じているので、親コンポーネントでimportしたCSSが子コンポーネントに適用されることは基本ありません。
（Scoped CSS は、子コンポーネントの一番上の要素には効いてしまうという話はあるにはあるのですが、、、）
ですので、components配下のコンポーネントでもpages配下のコンポーネントで読み込まれているCSSを再度importしなければいけませんでした。
結果的に当て込むことはできたのですが、かなり無理矢理な形になってしまいました。
負債になってしまった感覚がありました。
原因
モダンなフロントエンドフレームワークを使った開発でのコンポーネント指向の理解が浅かったです。
もっというと従来のWebアプリはHTMLファイル、JavaScriptファイル、CSSファイルとして分けるというような考え方（ファイルの種類別で分けるような）で、CSSにも設計があって、、、
というような考え方とコンポーネント指向の相性が良くなく、今回のようなことが起こってしまったのだと思っています。
HTNL&CSSの段階の設計（非コンポーネント指向）と、Vueの設計（コンポーネント指向）のギャップが当て込み時のオーバーヘッド、負債を作り出してしまったのではないかと思っています。
どうやったら良かったのか
前提、デザインとHTML&CSSの部分は上手くいっていたのですが、アプリ側（自分側）の当て込みが上手くいかなかったので、そこに対する対応策を上げていきます。
先程あげたギャップをなくすための方法を考えてみました。
デザインだけをやってもらい、コーディングからエンジニアが巻き取る
エンジニア側の負担が大きくなってしまうのと、エンジニア側のCSSの理解度に依存してしまうのがデメリットかなと思います。
（何もWebエンジニア全員がCSSが得意なわけではないので。。。）
（WebエンジニアがCSSを書くことにより、より負債になってしまう可能性もあるので。。。）
エンジニアのリソースとの兼ね合いもあるのかなと思っています。
HTML&CSSをコンポーネントごとに閉じて設計をしてもらう
Webアプリの都合をコーダーさんに強いることになってしまうので、少し難しく感じる部分はあります。
ただしエンジニア側でコーディングまで巻き取れない、コーダーさんにコーディングしてもらわない物理的に無理！ という場合は、コンポーネント指向をコーダーさんに説明をし、それにそった設計をしてもらうようにしたほうが良いと思います。
Utility FirstなCSSフレームワークを使う
WebアプリにHTML、CSSを当て込む時のコストを一番減らせるかつ、CSSの設計がアプリに影響しないのでメリットは多いと思います。
それとローンチ後にWebエンジニアがHTML、CSSを書かないといけない場合、CSSの設計などに縛られずに進めていけることもメリットだと思います。
デメリットとしてはコーダーの方でUtility FirstなCSSフレームワークを使いこなせる人が少なさそう、
コーディングするリソースがありかつUtility FirstなCSSフレームワークを使いこなせるWebエンジニアが少なさそう（もしコーディングまでWebエンジニア側で巻き取るとしたら）
というところだと思います。
（他にもTailwind CSSなどフレームワーク単位でのデメリットはあると思うのですが、、、）
ここ最近Tailwind CSSやChakra UI流行ってるな〜と感じてはいたのですが、その理由がわかった気がします。
モダンなフロントエンドフレームワークはコンポーネント指向が前提になっており、そうなった場合にUtility FirstなCSSフレームワークは相性が良いのだろうなと思っています。
最後に
新規プロダクトを開発するときにはデザイナーさんやコーダーさんと役割分担をすると思うのですが、
そのときにコンポーネント指向を考慮できていないとデザインをWebアプリに当て込む段階で苦労してしまう、負債になってしまうということを書いてきました。
そしてWebアプリに当て込む段階で苦労しないためにも、負債を残さないためにも、どうやったら良かったのかを振り返り３つの方法を考えてみました。
もっと良い方法もあるかと思いますが、もし何か参考になれば幸いです。
（もっとこうしたら良かったんじゃない？ということがあったらコメントで教えていただけると嬉しいです！）
ここまで記事を読んでいただきありがとうございました。