クラシルのWebチームでデザインシステムを少しずつ構築していっている話

2019年7月26日 17:59

delyのWebチームでプロダクトデザイナーをやってるkassyです。

現在、Webチームではデザインシステムを少しずつ導入しています。今日はその取り組みについてご紹介したいと思います。

今回の作業を行ったチームのメンバー構成
デザイナー × 1
フロントエンドエンジニア × 2
フロント兼サーバーサイドエンジニア × 1

デザインシステムとはなにか

とはいえデザインシステムと言われてもなんのこっちゃな方もいると思うので、カンタンに説明します。

ざっくりいうとデザイナーに属人化しがちなデザイン上の規則やルールなどを明確にし、開発チーム全体の共通言語とする取り組みです。それは何を良しとするのかという思想的な部分から、どの色をつかうのか、どのコンポーネントを使うのかという具体的なものまで（必要に応じて）明確にしていきます。アウトプットはドキュメント管理ツールだったり、Webサイトだったり、Invision DSMだったりいろいろですね。うちの場合はStorybookで管理しています。

参考例：Shopifyのデザインシステム

導入のきっかけ

現在、UI部分の全面的なリニューアル作業を進めていて、裏側のコードも大きく見直すことになったからです。大事なことなので強調しますが、巷でデザインシステムが流行ってるからうちのチームでもやってみるか〜〜というのではなく、時期的に取り入れるメリットがありそうだからやってみようという極めて合理的な動機からでした。なのでリニューアル作業が走っていなければ、やっていなかったと思います。

以前の失敗

どのようにやったのかの話の前に、ちょっと過去の話を。

前職でもデザインシステムを導入する機会があり、導入に向けて動いたのですが、その時はうまくいきませんでした。。思い返すと失敗の原因は３つあったと思います。

エンジニアの巻き込み不足
デザイナーだけで作業を進めてしまったため、それをやる必要性についてエンジニアの理解を十分に得ることができなかった。

時間をかけすぎてしまった
UIインベントリを数スプリントをかけて行う ⇒ デザインを精査する ⇒ コンポーネントをFigma上で整理する、、、というように工程ごとに時間をかけて作業をしてしまったために、冗長化してしまった。そしてそれはアジャイル的な価値のあるものをすばやく作るという動きとも相性が悪かった。

運用フローをきちんと決めなかった
作った後にどのように運用やメンテナンスしていくかなどのところを詰めきれていなかったので、きれいなコンポーネントがFigma上に構築されただけの絵に描いた餅になってしまった。

というような失敗があったので、個人的にはそれを踏まえての再チャレンジでした。

やる前に決めたこと

今回は話し合って以下のルールでやってみることにしました。

・小さく始めてみる
・とりあえずボタン要素から着手してみる
・Storybookはとりあえずローカル上で確認できるまでとする
・コンポーネントの粒度は、Atomic DesignのAtomレベルに限定
・Figmaとコードのコンポーネントの命名規則は揃える

重要な部分だけ解説します。

小さく始めてみる
海外の事例を見ればShopifyやAtlassianなどの大規模なデザインシステムの事例が見つかりますが、いきなりあそこを目指すのは無茶です。それにぼくたちがやりたいのは体系だったデザインシステムを完成させることではなく、あくまでも開発の効率化のため。とりあえずやれるところからやってみようというライトなモチベーションで着手しました。

ひとまずボタン要素から着手してみる
小さな成功体験を得るために着手する範囲を限定させ、まずは見た目的にもわかりやすい「ボタン」から着手してみました。

ゴールを明確化させた
どこまでやれば完了なのかというゴール地点も明確化。今回はローカル上のStorybookで整理されたコンポーネントが見れるまでとしました。

初回の作業でやったこと一覧

まず、二手に分かれてデザイナーは既存のボタン類の洗い出しを行い、フロント側はStorybookの環境構築に着手。洗い出しが終わったらMTGを開催し、全員でボタンについてのディスカッションを行いました。

MTGでは「ボタン」の曖昧な部分をひたすら明確化させていった
・ボタンとリンクの違いの明確化
　└ テキストリンクと文字だけのボタンの違いは？

・ボタンで必要となるサイズの明確化
　└ 大、中、小の３パターンで大丈夫？

・ボタンで必要となる状態変化の明確化
　└ hoverとdisableとそれ以外に必要なのは？

・ボタンの細かい仕様についての明確化
　└ 文字数が多い場合はどうする？
　└ アイコンなどがあった場合は？
　└ アイコンの配置はどのようなパターンが考えられる？
　└ ボタンのMAX幅はいくつにする？

その後、Figma上でコンポーネントを整理し、それを元にコード化してStorybook上に整理。そして実際のコードに反映させていきました。

これがぼくたちの最初の小さなデザインシステムの誕生でした。

実際のデザインシステム

現在の進め方

頻繁に利用するコンポーネントがあり、デザインシステム化させたほうが良さそうだったら、その都度MTGを開催。初回と同じような洗い出し作業から着手して、実際のコードを置き換えるところまでを１サイクルとして行っています。

導入して良かったこと

共通言語ができた
例えば、いままで#635F5Aだったカラーをgray-darken-40と定義して、Figma上でもコード上でもその命名規則を使うというルールにしたことで、作業が劇的にラクになりました。エンジニアがFigma上のコンポーネントを触るとgray-darken-40だとわかり、ソースコード上でもgray-darken-40と指定できる。また、変更したいときも「そこはgray-darken-40じゃなくてgray-darken-20で」と言えば済むので、コミュニケーションコストが下がりました。

開発効率が上がった
いままでは同じようなコンポーネントでも、ページごとに毎回コードを書いて実装していたので、手間もかかるし、ブレが生じやすい状態となっていました。それが共通化され、コンポーネントへのプロパティの追加／削除で多様なバリエーションを表現できるようになったので、開発効率がかなり上がりました。

変化にも強くなった
施策や方向性の見直しなどによってコンポーネントが頻繁にアップデートされていく環境なのですが、一度共通化させたところに関しては柔軟な変更がしやすくなったので、そのような変化にも強くなりました。

今後の課題

あくまでWebチームとして局所的に導入しただけだったり、根源的な「何を良いとするか？」という原則的な部分は一旦棚上げしていたりで、まだまだ未完成のものです。これをさらに継続的に良くしていければと思います！

よかったら参考までにどうぞ。

参考文献

作業するにあたり参考にさせていただいたドキュメント一覧。特にエウレカさんのブログには刺激をもらいました・・！

お知らせ

クラシルではデザイナーを絶賛募集中ですー！！
興味のある方がいたらぜひ〜〜。