初めに
初めまして。SKIYAKI開発部クリエイターチームでマネージャーをしているカミヤです。
コーダーとして入社し在籍5年目。マネージャーになってからは3年目です。
ときどきPM的な動きをしつつ、デザインのリニューアルや新規開発などに携わっています。
最近はデザインシステムを導入するにあたり奔走しているので、そういった内容を何回かに分けて書いていこうと思っています。
テーマ：デザインシステムとは
デザインシステムとは。
検索結果をざっくりとまとめてみると「デザインの一貫性を保ち、効率的な開発をするための、ガイドライン・コンポーネント・ツールなどの体系的な集合体です。」といったような趣旨になります。
具体的には、デザインの原則や構築するためのスタイルガイド、UIコンポーネントライブラリなどで構成されたもので、プロジェクトで共有される「全ての設計図」のようなものをさします。
導入することでユーザーには一貫した体験を提供できますし、開発側には開発効率を高めることができる恩恵があります。
ブランドイメージを向上させるといった側面もあります。
判断基準などが体系的にまとまったものがあれば、デザイン改修するシーンでも、AI駆動開発をするシーンでも意思決定・開発がスムーズに行えます。
この記事群が、デザインシステムがどんなものか理解していきながら、導入完了するまでの体験記的な読み物になればいいなと思っています。
これでいいんだっけ？ これってどうなんだっけ？
開発中にはたくさん判断に迷うシーンに遭遇します。
コーディング規約のような技術的なルールから、デザインをする際に守るべきルール、なにも開発側だけに留まりません。
コンテンツ側も指標がなければ、ついつい統一感のないライティングになってしまっていることもあります。
こうした進行の手を止めてしまいがちな「これってどうしたらいいんだろう」をルールメイクした集合体があれば、それに則っていけばいいので効率的です。
迷うことを減らし、可能な限り再現可能なもので作り上げていける状態に持っていければ、純粋に作ることにフォーカスできる（のを目指したいな）。
道のり1：構成を考える
デザインシステムを作り上げるぞと意気込んだものの、どういう構成にするべきかを考える必要がありました。
ありがたいことに色々な企業がデザインシステムを公開しているので、それらを参考にしつつ、
開発環境にマッチするフォーマットを検討した結果、以下の形で進めることにしました。
- Notion（ドキュメント） + Figma + Storybookの構成
- 社外への公開はしない
UIカタログである"Storybook"は社内のdemo環境までにし、
Figma MCPを使うケースを想定してFigmaとStorybookを併用してデザイン・コード資産としていくことにしました。
順番が前後してしまいましたが、次にデザインシステムの構成要素に触れていきながら道のりを棚卸ししてみます。
デザイントークン (Design Tokens)
根幹となる要素です。
色、フォントサイズ、スペーシング...こういったデザインの属性を人間が読める名前（例：color-primaryなど）で定義してコードで再利用できるようにする仕組みをさします。
デザイナーがFigmaでトークンを更新すれば、ビルドプロセスを通じてCSS変数に自動反映させて一気にデザイン実装へ適用できる、といったことも可能になります。
ここが整備されることによって、デザインと開発の連携強化、具体的にはデザイナーとエンジニアが同じ言語で会話でき、コミュニケーションコストが削減されるようになります。
コンポーネントの構造化
似通ったコードが乱立していては保守コストは嵩みます。
再利用性と保守性を高めるためにも、設計ルールに則って適切な粒度でコンポーネント化していくことが理想です。
Atomic Designに則ることが一般的。
ここが整備されることによって開発速度の向上、具体的には新規機能開発時にUIコンポーネントをゼロから書く必要がなくなり、ビジネスロジックの実装に集中できる...といった部分が期待できます。
ドキュメンテーションとプレビュー
ドキュメントと並び、コンポーネントを開発・テストできる環境として、Storybookなどのツールを導入します。
便利な点としては、実際に組み込む前にあらゆるStateやPropsを試せますし、開発効率にも品質保証の向上にも直結します。
カタログとしても有益で、車輪の再発明も避けられます。
（よくみたら他のページで似たようなパーツあった...といった悲劇にさようなら）
ここまで説明しましたが、
改めてデザインシステムは単なるツールの導入にとどまらず、開発工程自体の技術的な投資として有益だといえます。
未来のメンテナンスコストを削減し、高速で安定した開発が可能になれば作ることにもっとフォーカスしていけるはず…！
道のり2：現状の棚卸し
こういった要素のドキュメントを整備するにあたり、実際のコード資産・デザイン資産がどうなっているのか、そのギャップを見てみる必要がありました。
デザイン資産
デザインは、Figmaで「デザインガイド」や「マスターコンポーネント集」として用意までされていました。
カラートークンやテキストサイズ、borderのルール、buttonのルール、icon…最小限必要な要素は整備されています。
カラーなど、一部が変数化されてはいるもののバリアブル化はされておらず。
現在の弊社はページごとにブレの少ないデザインを作ることはできますが、デザイン作業効率はまだまだ向上できそうでした。
言い換えると、開発工程に組み込める形式にはまだなっていないとも言えます。
カラー、タイポグラフィ、余白などはルールメイクされていますが、
角丸、シャドウ、メディアクエリ、行送り、幅などは体系だったドキュメントにはなっていませんでした。
コード資産
UIカタログ
Storybookは開発環境のバージョン齟齬などで過去に頓挫していました。
ただ、当初の活用法とは違う形で（ディレクトリを切り分けるなど）方法を考えていけば、導入自体はできるだろうと見通しを立てました。
（余談）ここに関してはiinoさんが奮闘してくださったので以下のエントリーを読んでみてもらえると良いでしょう。
コンポーネント化
近年開発に着手したものはコンポーネント化されているものの、まだまだ昔のコードは手直しが必要であったり、コンポーネント化が必要なものがたくさんあります。
button、icon、accordion、tooltipなど基本的なものは新しいコンポーネントがありますがまだまだいっぱい作業は必要です。
道のり3：短期目標
関係各者に概要を伝えるキックオフを行い、作業チーム（デザイナー、エンジニア、コーダー）でのMTGを作成して着手を開始しました。
地図を広げたものの道のりは遠くです。
小さくゴールを設計するためにも、小さなパーツのデザイン実装をゴールにしました。
「アイコンとテキストで構成されている、dashboardに実装しているナビゲーションをFigmaMCPを活用してAI実装できるようにする」
こちらをゴールに、コンポーネントのドキュメンテーションと、それらに必要なデザイントークンの原則系を整備していく必要があります。
ここから着手を始めました。
終わりに
今回はデザインシステム導入にあたって簡単な経緯を綴ってみました。
具体的な話などは二回目以降で書いていけたらと思いますので今後ともよろしくお願いします。
株式会社SKIYAKIのテックブログです。ファンクラブプラットフォームBitfanの開発・運用にまつわる知見や調べたことなどを発信します。主な技術スタックは Ruby on Rails / React / AWS / Swift / Kotlin などです。 recruit.skiyaki.com/
Discussion