CSSフレームワークをデザインシステムに置き換えている

みんなのウェディング、松久(@kamonegi1977)です。
独自で作っていたCSSフレームワーク「Esthe(エステ)」を置き換えているお話です。

CSS フレームワークを置き換える理由

2015年から利用していたCSSフレームワーク「Esthe(エステ)」の置き換えを進めている理由は、主に3つあります。

☠️ 1.Railsの組み合わせで、不具合を発生させやすい

input要素で radioボタンを作りチェックしたかどうかは、li要素の class に checked と指定する必要があります。
Rails では form helper によりradioボタンでは、checked 属性を処理してくれます。 しかし、Esthe 独自の class については、フォームのレイアウトに合わせて helper を開発したりすることがありました。

<ul class="radio">
  <li class="checked">
    <input type="radio" value="1">
    <label>項目</label>
  </li>
</ul>

初見では正常系の処理をブラウザーで確認していると「あれ?」と気づくのですが、正常系を軽くテストしていると漏れてしまうことがありました。
また、独自の helper を都度で開発するのは開発時間がかかります。

☠️️️ 2.社内の独自ルールが増えて育成コストが高い

Esthe には、margin や padding などを指定する「ユーティリティクラス」と呼ばれる実装があります。
例えば下記のような実装です。

.mg10t {
  margin-top: 10px !important;
}

.taC {
  text-align: center !important;
}

このようなユーティリティクラスは、キャンペーンページなど1ページぐらいをCSSを書かずに作りたい、という要望を実現しやすくします。

その反面、社内だけの独自ルールになります。
社内だけの独自ルールは、学習コストを発生させます。特に新卒研修では「意味のある Class 名をつけましょう!」と言ったあとに「.mg10t は…」という説明が必要になります。研修コストも増えますし、教わる方も「なぜ、.mg10t はいいの?」という気持ちを生みます。

☠️️️ 3.基準となる UI がハッキリしなくなった

.mg10t などのユーティリティクラスとの組み合わせで、様々なUIが作れます。

様々なUIが作れるため、基準のUIがわからない状態になっていきました。そうすると、デザインレビューでも、マークアップでも、UIが増殖し、サイトの利用体験としてちぐはぐな印象を与えることになってしまいました。
実装面でも、再利用性が低いので HTML/CSS を書く時間が増えていきます。

🔦 置き換えで目指す方向性

Esthe で出てきた問題を解決するために、上記の問題を解決するために下記のルールで作り変えることにしました。

  • Rails と組み合わせて上手く動くこと
  • 社内の独自のルールから使われているルールに沿うこと
  • ユーティリティクラスを無くすこと
  • 基準となる UI をハッキリさせること

🐼 Rails と組み合わせて上手く動くこと

form でのエラー表示を aria-invalid 属性を利用することにしました。

config/application.rb に下記のような設定をしました。

config.action_view.field_error_proc = proc {|html_tag, _instance|
  html_field = Nokogiri::HTML::DocumentFragment.parse(html_tag).children.attribute("aria-invalid", true)
  html_field.to_s.html_safe
end

Rails 側で処理をし、CSS の クラス名を書くわけではなく、aria-invalid 属性を利用して状態を HTML 側に持ってもらうようにしました。

WAI-ARIA について

新しい デザインシステム では、aria-* 属性を積極的に利用するようにしています。知っている人が少なかったので、デザイナーシェア会で WAI-ARIA についての発表をしました。

🐼 社内の独自のルールから使われているルールに沿うこと

知られているルールを使っている、と明示しました。新卒研修でも伝えるのはルールの採用理由になりますし、世間で使われているルールであれば、実績があることが確認できるからです。

例えば、Class 名の命名ルールは、 BEM + RSCSS(のVariaonts のみ)というルールにしました。実際には、下記のような方法で書いています。

.block {
  .block__element {
    &.-modifier {
    }
  }
}

BEM のコーディングルールも整理しました。
細かすぎるけど伝わってほしい私的BEMプラクティス30(ぐらい)」を参考にして用意しました( 余談ですが、CSSを学んだサイトの1つに「ねこめしにっき」があり感慨深いです )

ルールを伝える時

ルールを作り広めるために、よくない書き方の理由と一緒に説明することを徹底しました。
新卒研修で説明したり、エンジニアを集めて説明をしたりしました。

🐼 ユーティリティクラスを無くすこと

ユーティリティクラスの乱用で UI の基準が不明確になっていたのでユーティリティクラスを作らない、というルールで始めました。また、ユーティリティクラスを多用しているとE2Eテストで辛い、という理由もあります。

各コンポーネントには、ある程度の modifier を用意しました。使い方の想定をして用意する必要がありますが、便利すぎるのではなく、便利じゃない時があったら、なぜそうなっているのか?考えて判断してほしい、という思いもあります。
実施には下記のようなイメージです。

.component {
  &.-margin-top-20px {
    margin-top: 20px;
  }
}

上記の例では「.-margin-top-20px」という modifier を用意しています。
modifier は状態を示したいのですが、レイアウトの調整用も 0 にはできなかったので、何をしているのかクラス名に書くことにしました。

🐼 基準となる UI をハッキリさせること

「ユーティリティクラスを無くすこと」に関係しますが、ユーティリティクラスでの実装をやめて、コンポーネントの使い方を明確にしていきました。

特に「❗禁止事項」を書いています。また、コンポーネントの目的についても書くようにしました。
これは、コンポーネントの使い方の説明や、意図が不明確だっため意図しない使い方が発生していたためです。この意図しない使われ方を防ぐためにも、ユーティリティクラスを作らないようにしています。

どうやって作り始めたか?

最初は、スタイルガイドの置き換えで始めました。
既存のスタイルガイドを技術的な視点で置き換えたい点は明確になっていきましたが「UI の基準を作る」ためには、「UIの理由」「サービスの世界観」と言ったものも明確にしていくことが必要でした。

作り続けるために下記の3つから始めました

  • UIインベントリをする
  • 色の整理をする
  • 定期的に話し合い続ける

🛠 UIインベントリをする

やらなくてもいいのでは?と思いましたが、やってみました。
やってみると、どれぐらいバラバラなのか?想像と違ったところも明確になります。地道ですが本当に「UI インベントリ重要」です。

やり方は「GitHub で issueに 一人でひたすらキャプチャーと感想を書く」です。
デザイナーの園田がキャプチャーをとり、感想を書くを繰り返してくれました。
時々、エンジニアから「こんなパターンもあるよ」と書いてもらったりもしました。

🛠 色の整理をする

元々、整理されてはいたのですが、使われていない色もあったので改めて整理しました。
最近では、デザイナーの髙橋が Figma で色パレットを用意してデザイナーでシェアしたりもしています。

まだ、色の目的が不明確でキーカラーの使い分けがしにくい状況になっています。これを整理して用途をハッキリさせていくのが必要だと認識しています。

🛠 定期的に話し合い続ける

定例のミーティングを 10分でもいいのでやることにしました。
成果がなくても、やることにしました。定期的にやっていないとない時は、0からスケジュールの調整を構築しないといけなくなるのが大変だからです。
定例ミーティングを無駄にはしたくないので、少しでも進めておく行動ができる定例ミーティング駆動開発になっています(とにかく進めるきっかけになっていたらよし、としました)

どうやって作り続けたか?

  • 大雑把なスケジュールを作る(数回)
  • エンジニアとの共有
  • 投入しやすいところから案件投入

📆 大雑把なスケジュールを作る(数回)

下調べをして、これぐらいはかかりそう、という予想をたてます。あくまでも予想ですし、やってみたら大変だった、サービス開発を優先させたから進まなかった、というのも予想されます。
守れなかったことを悔やむと、やりたくなくなります。継続して改善していくことを優先しています。

エンジニアとの共有

みんなのウェディングでは、HTML/CSS をエンジニアもデザイナーも書きます。そのため、エンジニアとの共有は大切です。
ただし、マークアップは好きじゃない人もいるので、新しいデザインシステムに期待を持たせないようにしました。「CSS を書くのが簡単になります!」という期待は持たせず「書く方法」と理由をきちんと説明することを徹底しました。

「CSS を書くのが簡単になります!」という期待を持たせない部内広報をしつつも、フォームなど一部のページではコンポーネントの組み合わせを明文化しました。 Atomic Design でいうと 「Organisms(有機体)」「Templates(テンプレート)」あたりを作りました。
エンジニアの期待のハードルを下げつつ、開発が楽になるような仕組みを用意して期待を上回るような体験をしてもらいました。

新卒研修での説明

新卒研修でも説明をしました。
最初のうちに、世の中にあるルール( BEM + RSCSS )の話をし、当社の歴史的経緯を話をしていくことで、違いを明確にし学んでいけるようにしました。

実際の研修の様子は「2019卒デザイナーがマークアップ研修で学んだこと」でデザイナーの小板からお話しさせていただいています。

投入しやすいところから案件投入

少しづつ置き換えをしているのですが、置き換えしやすい .os1-link-see-more という「もっと見る」リンクを置き換えていきました

少しづつでも置き換えを継続していくことを注意しました。

これからのデザインシステム

正直、最初から上手くできたわけではありません。試行錯誤して進めていました。
何点か特に注意した点があります。

スケジュールと作業量について注意しました。
専任のチームがあって進めているわけではないので、通常業務とスケジュールとのバランスをとるのか?に注意しました。無理してもよくないし、継続して進めないと、進捗がないのでスケジューリングは目安ぐらいにして進めました。

UI の目的を明文化した。
既存のCSSフレームワークには、目的や利用シーンが書かれていなかったので、デザインシステムに持ってくるときに「この形になったのはなぜ?」をデザイナーに聞くところから始まりました。
そこで、今回はUIを作るときに、目的やどんなときに使えるのか?使えないのか話し合いをして、要点をシステムに書くようにしました。
デザインシステム自体も名前を決めて「どうしてなのか?」について説明を書くことにしました。デザインシステムの名前は「Oshidori(オシドリ)」となり、チームで育てていく意識作りもできました( 期せずして「デザイニング・インターフェース 第2版」の愛称?である「オシドリ」になったのは偶然です )。

デザインシステムは、デザイナーとエンジニア間の共通言語となるものだと思っています。また、利用者がサービスに触れる接点になります。
完成はなく、少しづつでも作りづける体制を根付かせていきたいと考えています。