😺

脱Bootstrap!mybestの管理画面のUIを統一して複雑化していたCSSをシンプルにした話

2022/09/21に公開約3,800字

はじめに

こんにちは、株式会社マイベストでフロントエンドエンジニアをしてますyamadaと申します。
弊社ではmybestというサービスを運営しており、日々様々な記事が公開されています。
記事を作成・編集・公開するにあたり管理画面も自社で開発してるのですが、少し前までこの管理画面のフロントエンドが少々問題を抱えてました。
今回はその問題を解決した話を簡単に共有したいと思います。

管理画面が抱えてた問題

mybestの管理画面は構築時にCSSフレームワークのBootstrapが採用されました。
その後、何かしらの理由でAdminLTE(管理画面に特化したBootstrapベースのCSSフレームワーク)が追加導入され、更に独自のCSSをを追加したという経緯があります。
そのため、mybestの管理画面はBootstrap、AdminLTE、独自CSSの3つのCSSを同時に使用しており下記の問題を抱えてました。

テイストの違うデザインが複数あり管理画面の利用者を混乱させていた

この場合の3つのCSSを同時に使用していたというのは3種類の異なったテイストのデザインが存在することを意味します。
これにより、ページによって全く違うテイストのデザインが入り乱れ利用者を混乱させていました。また、コンポーネントのルールや見た目が違うので、利用者が管理画面を把握するコストが大きいといった問題もありました。mybestというサービスが大きくなるに連れて管理画面の利用者も増えており、この問題は大きな課題となっていました。

Bootstrap AdminLTE 独自CSS

BootstrapとAdminLTEが負債になった

BootstrapとAdminLTEは簡単に見栄えの良いUIを作れて便利なのですが、凝ったオリジナルデザインのUIを作る場合にはほぼ不要になります。
多様化する管理画面のユースケースにBootstrapとAdminLTEが提供するUIだけでは対応出来なくなり、現在の開発では専属のデザイナーとフロントエンドエンジニアが参画してオリジナルデザインのUIを作るようになりました。
このため、BootstrapとAdminLTEで用意されたUIを新規で使うことは完全に無くなりました。

独自CSSが複雑になっていて管理し辛くなっていた

mybestはRuby on Railsで作られたWebアプリケーションなので当然SprocketsでCSS(Sass)を管理していましたが、モダンフロントエンドへの移行のためwebpackも並行して使うようになりました。そのためSprocketsとwebpackで管理する2つのCSS(Sass)ディレクトリが存在してました。
Sassについては独自メソッドや条件分岐、ループ、継承などの機能がたくさんあり便利なのですが、それらの使い方が統一されておらず煩雑になっていました。
(創業初期にデザイナーやCSSを書く人が頻繁に入れ替わっていた影響のため)

このディレクトリの問題とSassの便利機能の繁雑化が絡み合いとても管理し辛い状態となってました。

mybest独自のデザインシステムとCSS設計について

既存デザインの整理の一環としてデザイナー主導で独自のデザインシステムが生まれ、このデザインシステムを使い管理画面のUIを統一するプロジェクトが発足しました。
また、フロントエンドの技術課題としてCSSを整理するプロジェクトも発足していたのでUI統一と並行して対応する事となりました。
※独自のデザインシステムの詳細については割愛させて頂きます。

CSSの方針・設計について

Sassで便利機能を色々使ったけど結局 CSSはシンプルな方が使いやすいし分かりやすい という結論になり、mybestのCSSでは最低限の必要な機能のみを使うという方針とし、設計に関してはFLOCSS+ITCSSの独自のものを使用する事にしました。
※独自のCSS設計については別で紹介できればと思います

この当時、いずれ非推奨になるnode-sassを使っていてDart Sassへの置き換えも課題としてあったので同時に対応する事にしましたが、Dart Sassのグローバル変数の扱い難さと学習コストの高さが懸念となりSassを外そうという事になりました。

Sassの機能としてはimportとmixinくらいがあれば良かったのでプラグインを使い自由に便利機能を追加できるPostCSSを採用する事にしました。(別プロジェクトでReact化も走っていたのでCSS in JSへの置き換えも検討されたのですが、その場合、一旦ピュアなCSSに近づけてからの方がスムーズに対応できるという判断もありました)

結果、下記のような方針で進める事になりました。

方針

  • Sassの独自メソッド、条件分岐、ループ、継承は削除する
  • Sassの変数をピュアなCSS変数に置き換える
  • Sassを外してPostCSSを使う(import、mixin)
  • webpackのみでCSSを管理する

UIの統一とCSSシンプル化の進め方

UIの統一

デザイナーからFigmaでデザインを共有してもらった後に
おおまかですが下記の流れで進めました。

  1. webpackで管理しているCSSディレクトリにコンポーネントディレクトリを追加
  2. Figmaを元にコンポーネントを追加
  3. コンポーネントをページに当てはめる
  4. カテゴリごとにリリース
  5. BootstrapとAdminLTEの削除

slimに書かれたロジックはほぼ変更する必要がなかったのでHTMLを適切な構造を変え、そこに新たなCSSを適用し記事カテゴリごとにリリースしていきました。
上で書いた通り、React化のプロジェクトも走っていたので部分的にReactでの実装もありましたがUIの統一という文脈で困ることはなくスムーズに実装できました。
実装中に余白や色が違うなどの問題が多々発生しましたが、デザイナーとマメにコミニュケーションを取りながら作業を進めれてたので、最終的には実装したコンポーネントとFigmaのデータを同一にする事が出来ました。

CSSのシンプル化

おおまかですが下記の流れで進めました。

  1. Sassの独自メソッド、条件分岐、ループ、継承を削除する
  2. Sassの変数をピュアなCSS変数に置き換える
  3. Sprocketsで管理していたCSSをwebpackで管理しているCSSに移行する
  4. Sassを削除しPostCSSを導入する
  5. import, mixinを使えるようにする

Sassで使っていた独自メソッド、条件分岐、ループ、継承は全て削除してベタ書きに直しました。
条件分岐やループのネストが深い、継承が複数行われ継承元が分からないなど若干のハマりポイントもありましたが大きなトラブルもなく対応できました。

タスクの管理は「Sassから条件分岐を削除する」みたいな大きな粒度でJiraのチケットを作っていたのですが、個人的にはこのくらいの粒度でもやりやすかったです。
大きな粒度で対応すると変更した画面の数も増え確認がとても大変なのですが、弊社のスーパーエンジニアがVisual Regression Testの仕組みを導入してくれてたので確認作業に大幅に時間を費やすみたいな事もありませんでした。(PRの確認は大変だったと思います😅)

UIが統一されCSSがシンプルになってどうなったか

管理画面全体で一貫性を保てユーザーを混乱させることがなくなりました。
CSSがシンプルになったことで以前より管理しやすくなり開発速度も高まりました。

  • ディレクトリ構造が分かりやすくなりました
  • 条件分岐やループがなくなって可読性が高まりました
  • BootstrapとAdminLTEを削除できてスッキリしました!

今後について

今後、mybestの管理画面はNext.js化されてReactコンポーネントをStorybookでテストするような仕組みも導入予定です。
引き続きの課題としてCSSやReactコンポーネントの整理を更に進めたいと思っていますし(正直まだまだ整理が必要です)、整理と併せてCSS in JSの導入なども検討されています。

ご興味を持った方はぜひ採用ページをご覧ください!

Discussion

ログインするとコメントできます