みんなのウェディングエンジニアリングブログみんなのウェディングエンジニアリングブログ記事の一覧CSSフレームワークをデザインシステムに置き換えているみんなのウェディング、松久(@kamonegi1977)です。独自で作っていたCSSフレームワーク「Esthe(エステ)」を置き換えているお話です。フレームワークを置き換える理由2015年から利用していたCSSフレームワーク「Esthe(エステ)」の置き換えを進めている理由は、主に3つあります。指定する必要があります。属性を処理してくれます。開発したりすることがありました。</li></ul>初見では正常系の処理をブラウザーで確認していると「あれ?」と気づくのですが、正常系を軽くテストしていると漏れてしまうことがありました。都度で開発するのは開発時間がかかります。指定する「ユーティリティクラス」と呼ばれる実装があります。下記のような実装です。!important;}このようなユーティリティクラスは、キャンペーンページなど1ページぐらいをCSSを書かずに作りたい、という要望を実現しやすくします。その反面、社内だけの独自ルールになります。社内だけの独自ルールは、学習コストを発生させます。は...」という説明が必要になります。いいの?」という気持ちを生みます。ユーティリティクラスとの組み合わせで、様々なUIが作れます。様々なUIが作れるため、基準のUIがわからない状態になっていきました。すると、デザインレビューでも、マークアップでも、UIが増殖し、サイトの利用体験としてちぐはぐな印象を与えることになってしまいました。書く時間が増えていきます。出てきた問題を解決するために、上記の問題を解決するために下記のルールで作り変えることにしました。属性を利用することにしました。下記のような設定をしました。側に持ってもらうようにしました。属性を積極的に利用するようにしています。ついての発表をしました。社内の独自のルールから使われているルールに沿うこと知られているルールを使っている、と明示しました。新卒研修でも伝えるのはルールの採用理由になりますし、世間で使われているルールであれば、実績があることが確認できるからです。)というルールにしました。実際には、下記のような方法で書いています。コーディングルールも整理しました。)ルールを伝える時ルールを作り広めるために、よくない書き方の理由と一緒に説明することを徹底しました。新卒研修で説明したり、エンジニアを集めて説明をしたりしました。基準が不明確になっていたのでユーティリティクラスを作らない、というルールで始めました。ユーティリティクラスを多用しているとE2Eテストで辛い、という理由もあります。使い方の想定をして用意する必要がありますが、便利すぎるのではなく、便利じゃない時があったら、なぜそうなっているのか?考えて判断してほしい、という思いもあります。実施には下記のようなイメージです。できなかったので、何をしているのかクラス名に書くことにしました。させること「ユーティリティクラスを無くすこと」に関係しますが、ユーティリティクラスでの実装をやめて、コンポーネントの使い方を明確にしていきました。「❗禁止事項」を書いています。コンポーネントの目的についても書くようにしました。これは、コンポーネントの使い方の説明や、意図が不明確だっため意図しない使い方が発生していたためです。この意図しない使われ方を防ぐためにも、ユーティリティクラスを作らないようにしています。やって作り始めたか?最初は、スタイルガイドの置き換えで始めました。基準を作る」ためには、「UIの理由」「サービスの世界観」と言ったものも明確にしていくことが必要でした。UIインベントリをするやらなくてもいいのでは?と思いましたが、やってみました。やってみると、どれぐらいバラバラなのか?想像と違ったところも明確になります。インベントリ重要」です。一人でひたすらキャプチャーと感想を書く」です。デザイナーの園田がキャプチャーをとり、感想を書くを繰り返してくれました。時々、エンジニアから「こんなパターンもあるよ」と書いてもらったりもしました。色の整理をする元々、整理されてはいたのですが、使われていない色もあったので改めて整理しました。色パレットを用意してデザイナーでシェアしたりもしています。色の目的が不明確でキーカラーの使い分けがしにくい状況になっています。これを整理して用途をハッキリさせていくのが必要だと認識しています。10分でもいいのでやることにしました。成果がなくても、やることにしました。定期的にやっていないとない時は、0からスケジュールの調整を構築しないといけなくなるのが大変だからです。大雑把なスケジュールを作る(数回)下調べをして、これぐらいはかかりそう、という予想をたてます。予想ですし、やってみたら大変だった、サービス開発を優先させたから進まなかった、というのも予想されます。守れなかったことを悔やむと、やりたくなくなります。継続して改善していくことを優先しています。エンジニアもデザイナーも書きます。そのため、エンジニアとの共有は大切です。マークアップは好きじゃない人もいるので、新しいデザインシステムに期待を持たせないようにしました。書くのが簡単になります!」という期待は持たせず「書く方法」と理由をきちんと説明することを徹底しました。書くのが簡単になります!」という期待を持たせない部内広報をしつつも、フォームなど一部のページではコンポーネントの組み合わせを明文化しました。「Organisms(有機体)」「Templates(テンプレート)」あたりを作りました。エンジニアの期待のハードルを下げつつ、開発が楽になるような仕組みを用意して期待を上回るような体験をしてもらいました。新卒研修でも説明をしました。)の話をし、当社の歴史的経緯を話をしていくことで、違いを明確にし学んでいけるようにしました。実際の研修の様子は「2019卒デザイナーがマークアップ研修で学んだこと」でデザイナーの小板からお話しさせていただいています。いう「もっと見る」リンクを置き換えていきました少しづつでも置き換えを継続していくことを注意しました。これからのデザインシステム正直、最初から上手くできたわけではありません。試行錯誤して進めていました。何点か特に注意した点があります。スケジュールと作業量について注意しました。専任のチームがあって進めているわけではないので、通常業務とスケジュールとのバランスをとるのか?に注意しました。無理してもよくないし、継続して進めないと、進捗がないのでスケジューリングは目安ぐらいにして進めました。既存のCSSフレームワークには、目的や利用シーンが書かれていなかったので、デザインシステムに持ってくるときに「この形になったのはなぜ?」をデザイナーに聞くところから始まりました。そこで、今回はUIを作るときに、目的やどんなときに使えるのか?使えないのか話し合いをして、要点をシステムに書くようにしました。デザインシステム自体も名前を決めて「どうしてなのか?」について説明を書くことにしました。デザインシステムは、デザイナーとエンジニア間の共通言語となるものだと思っています。利用者がサービスに触れる接点になります。完成はなく、少しづつでも作りづける体制を根付かせていきたいと考えています。(2019年10月24日)twitterfacebookhatenabookmark最新の記事みんなのウェディングはEKSで動いていますタイポグラフィとCSSのスタイル宣言2019年新卒エンジニア研修もそろそろ終盤です。