近年、国内外の様々な企業のプロダクト開発に導入されている「デザインシステム」。「デザインシステム」を導入することで、デザイナーやエンジニアの開発生産性や効率性を高めたり、ユーザー体験の一貫性を提供できたりと、様々なメリットがある一方で、事業内容や成長フェーズ、組織構造などによってデザインシステムの目指すべきカタチは異なり、正解や完成がないことから、悩みを抱えている企業や開発者は少なくありません。

そこでラクスル株式会社（以下、RAKSUL）は、デザインシステムのコミュニティ「Design System Build」を立ち上げ、2022年8月23日に“デザインシステム構築の様々なアプローチ”をテーマに勉強会を開催しました。
この勉強会では、デザインシステムを構築していく過程で得たナレッジや成功・失敗事例などを共有します。

スピーカー：
深田 康太（freee株式会社 DesignEngineer / ProductDesigner）
池田 泰延（株式会社ICS フロントエンドエンジニア）
大木 尊紀（Ubie株式会社 デザインエンジニア）
中島 晃（ラクスル株式会社 デザインエンジニア）
糸数 昌史（ラクスル株式会社 デザインエンジニア）

詳細：https://raksul.connpass.com/event/255844/

デザインシステムを作っても使われなければ意味がない。｜ラクスル株式会社

まずトップバッターを務めるのは、勉強会を主催しているRAKSULです。
デザインエンジニアとして働く、中島さんと糸数さんが「印刷ECデザインシステムのこれまでとこれから」というテーマを掲げ、お話しました。

RAKSULでは印刷や物流、広告、コーポレートITなどの領域でプラットフォームを展開しており、今回は印刷・集客支援のプラットフォーム「ラクスル」事業におけるデザインシステムの話となります。

ラクスルはネット印刷を起点に、ノベルティやグッズ、名刺などの印刷から、DMやポスティングといった集客支援に至るまでさまざまなサービスを展開しています。

サービスが次々と生まれるのに連れ、開発体制も拡大していて、現在は日本とベトナムに開発チームを複数持っています。

糸数さんは「デザイン組織の拡大に伴い、正社員のほか副業デザイナーの方も20人を超える体制になってきていることから、プロダクトや職種、言語間において『共通言語の必要性』をより感じるようになった」のが、デザインシステムに取り組み始めた背景になっていると説明します。

そんななか、2021年にはデザイン・イノベーション・ファームTakramとともに、プロダクトのパーソナリティやデザイン原則の策定を行い、今年からはそれらをもとにFigmaでのコンポーネントデザインを始めています。

ただ、デザインシステムの構築を始めた当初は「せっかく作っても使われずに終わってしまう」という課題感を抱えていたと糸数さんは言います。

「デザインシステムの継続的なアップデートや、その存在自体を認知してもらい、現場で長く使ってもらうようにするにはどうすればいいか。そのようなことを考えたときに、デザインシステム に名前を付けている会社があることを知り、ラクスルでも親しみやすく一度聞いたら記憶に残るようなネーミングを作りたい。そう思うようになりました」

コンセプチャルなネーミングを考えるために、フロントエンジニアやデザイナーを交え、いくつも案を出して議論を重ねた結果、図のようなコンセプトをテーマにした「kamii（紙）」に決まったそうです。

ロゴに関しては「バリエーション展開しても一貫性が保て、かつ認知力を失わないようなデザインを意識した」と糸数さんは語ります。

「デザインシステムを作ると、必然的にリポジトリも増えていくだろうと思ったので、認知の面から考えたロゴのデザインに仕立てました。また、ロゴのカラーは自由に変えられるように設計することで、親しみやすさや汎用性も意識しました」
さらに今後コンテンツを随時追加していくために、ドキュメントサイトを立ち上げ、運用していくとのことです。

各事業の成長度合いに合わせ、フレキシブルに最適化していく

デザインシステムにおける実際の開発については、RAKSUL中島さんから説明が行われました。最初はリポジトリ構成についてです。

「kamiiではkamii-icon（アイコンの管理）、kamii-css（コンポーネントのCSSを管理）、kanji-vue（Vue コンポーネントライブラリ）の3つのリポジトリにて開発されています。背景として、RaksulではVueを利用しているプロジェクトが多いものの、Ruby on railsやPHPなどのバックエンドでHTMLを出力するレガシーな環境もまだ存在していて、Vueベースのコンポーネントライブラリだけでは一部のプロジェクトにしか適用できず、長く使ってもらうための設計にはならない。そう感じたのでさまざまな環境で利用できる、3つのリポジトリに分けた構成にしています」

このように責務を分けた構成にした結果、iconのみ、cssのみ、コンポーネントとそれぞれの環境によって柔軟に選択できるようになったそうです。

ここからは各リポジトリの説明に入りました。

まず、kamii-iconについては「今回のデザインシステムの構築のために、新たに作り直されたアイコンセットになっている」と中島さんは述べます。

「アイコンのみをウェブフォントで提供し、Font Awesomeと同じような記述で各種アイコンの利用は可能になっています。アイコンの利用にはnpm等でインストールするほか、Wordpressでのブログシステムでもアイコンを利用するケースも出てくることを想定し、CDNでも配信を予定しています。それによって、レガシーな環境でもHTMLにタグを埋め込むだけでアイコンを活用することができるようになるわけです」

次いでkamii-cssについては、tailwindcssのブラグインとして開発し、コンポーネントの見た目を定義したCSSのみを提供するようになっているとのこと。

「このような構成にすることで、Vueを利用しないプロジェクトであっても、コンポーネントの見た目だけを揃えたい、あるいは見た目だけを利用したいというケースに対応することができます。また、Vue以外のコンポーネントライブラリを制作する場合でも、容易に見た目を揃えることが可能になります」

kamii-vueに関しては「今まで作っていたVueベースのコンポーネントライブラリをデザインシステム用にアップデートしたものになる」と中島さんは続けます。

「基本的にはkamii-cssをインポートして利用するようになっており、インタラクションに集中して開発ができるようになっています」

このようにレポジトリを分けてデザインシステムを開発しているわけですが、今後のアクションとして、中島さんは次のように目標を定めています。

「作っても使われずに終わることのないように、開発しながら管理・維持していけるような仕組み化を目指しています。例えば、Figmaのapiを利用してデザインのアップデートを自動化できるようにしたり、Vue以外のReactなど他のフレームワークでも利用できるようにコンポーネントライブラリの拡充を図ったりすることを進めていく予定です。RAKSULの各事業の成長に合わせ、フレキシブルに最適化していき、デザインシステムを広く使われるようなものにしていければと思っています」

3年ほどデザインシステムを運用して見えてきた成果と課題｜freee株式会社

2社目はfreeeのデザインシステムについての発表となります。

デザインエンジニア/プロダクトデザイナーの深田さんが「デザインシステムと画面パターン」というテーマで説明を行いました。

深田さんは新卒でfreeeへ入社し、Webアプリケーションの開発を経験したのち、デザインチームに異動。現在はfreee会計のプロダクトデザインやデザインシステムの運用に携わっています。

freeeは「スモールビジネスを、世界の主役に。」というミッションのもと、「アイデアやパッションやスキルがあればだれでも、ビジネスを強くスマートに育てられるプラットフォーム」の実現を目指しており、ビジョンについては図のように3つの要素から成る統合型経営プラットフォームを掲げています。

そのなかでも、デザインシステムに大きく関わるのが統合型クラウドERPだと深田さんは言います。

「スモールビジネスに関わるさまざまな領域でプロダクトを開発していますが、それぞれの一貫性や統合型の価値、体験を提供したいという思いがあります。もちろん、まだ世に出していない新規プロダクトもスピード感持って開発していきたいですし、プロダクト単体でもユーザーに価値提供できるようにしていきたい。

そのためには、デザインシステムが『画面レベルでの一貫した体験・プロダクトの開発生産性』の下支えとなり、新規プロダクトの立ち上げや既存プロダクトの改善の双方ともスピード感を持って開発できる土台の役割を果たすことが重要だと捉えています」

freeeにおける現状のデザインシステムは、立ち上げから3年程度経っていて、すでに各プロダクトで利用されているような状況とのことです。

3年ほど運用してきた成果として、深田さんはこのように説明します。

「1からコンポーネントを実装する必要がなく、何か修正がある際は使っているコンポーネントを用いている箇所全体に反映できるなど、開発生産性が向上しました。また、コンポーネントの見た目と挙動が揃うため、『見た目から挙動がなんとなく想像すること』ができ、ユーザーも学習しやすくなっていて、さらにはアクセシビリティの観点でも誰にでも使いやすいプロダクト品質の担保につながっています。

そして、各コンポーネント単位で文字や色などのデザインエレメントを反映できるため、ブランドの体現にも寄与している。このようにコンポーネントレベルでは、一定の効果を出せていると感じいます」

こうした一定の成果がある一方、現状ではコンポーネントレベルでの一貫性にとどまり、似たパターンの画面でもレイアウトが異なったり、開発生産性についても似た組み合わせの実装を繰り返している箇所もあり、まだまだ改善の余地があるとのことです。

ギャップが生じている背景として、深田さんは「デザインシステムの立ち上げに、レイアウトの改善も見込んでいたこと、そして画面設計の指針として定めたUI/UXガイドラインに、具体的なレイアウトまで規定していなかった」と振り返ります。

「どうしてもコンポーネントの利用とともに、新しいレイアウトを都度考えていく形になってしまっていたと思っています。また、storybookにも実装サンプルを載せていますが、レイアウトの面では網羅的でなかったり、新規プロダクトでは新しくレイアウトを試す機会があるものの、既存のプロダクトやデザインシステムが追従できてなかったりしていました」

パターンの定義からプロダクトレベルの一貫性や開発生産性を実現したい

そこで、深田さんはプロダクトレベルの一貫性や開発生産性を実現のために画面パターンの定義に取り組みたいと述べます。画面パターンの定義には「パターン自体の定義と、パターンごとの画面レイアウト、画面の挙動や振る舞い、提供したい体験に基づくデザインの根拠」等が含まれるといいます。

「画面パターンを定義することで、プロダクトを通した一貫的な体験を提供しやすくなりますし、画面の7~8割くらいがパターン化される見込みでデザイナーがパターン化されない部分にフォーカスできるようになりデザインの生産性の向上がなされると考えています。また、デザインが揃うことで、フロントの実装としても揃えやすくなるなど開発生産性の向上にも期待しています。」

それではどのようにして画面パターンを規定していくのでしょうか。

深田さんは「まずは扱うオブジェクトの性質と分類を行うことが先決になってくる」と話します。

「一覧表示で名前、日付と数字等の組み合わせなどがどう識別されるのか。詳細表示で内包するデータの表示や関連するデータの示し方などのパターンを洗い出すことが大事になってくると考えています。加えてパターンにする粒度の判断をしていくことも肝になってくるでしょう。こうして規定した画面パターンに合わせた理想系の画面を再定義していき、レイアウトやビジュアル、プロダクトの挙動や振る舞いなども含めてデザイナーの総意となるように協力しながら進めていく予定です」

想定されるアウトプットとしては、以下で示す写真のような内容になるとのことです。
プレゼンテーションの結びとして、深田さんが将来の展望について抱負を語りました。

「まだまだ未定ですが、画面パターンが定まるからこそ、手を伸ばせる領域も出てくると考えます。画面テンプレートの自動生成などを行うなど、より高い開発生産性を目指すこともあり得ますし、パターンの見極めができれば作るべきUIの予測が立てられるようになるため、デザイナー職以外の人もUIを考えやすくなるのではと思います。、あくまで可能性レベルの話にはなりますが、将来的に実現できるように取り組んでいければと考えています」

海外の先進企業に見るモーションへの言及｜株式会社ICS

3社目はICSのパートとして、フロントエンジニアの池田さんが「デザインシステムにおけるアニメーション定義」をテーマにプレゼンテーションを行いました。

最初はウェブコンテンツにおけるアニメーションの必要性について、池田さんは「GoogleやAppleが出しているデザインシステムのうち、モーションについて言及しているところがあり、そこから読み解いていきたい」と述べました。

「Googleが提唱するMaterial Designでは、UIを表現したり使いやすくするためにモーションが役立つことを示しています。一方、AppleのHuman Interface Guidelinesでは、モーションによって視覚的な体験を豊かにし、さらにはモーションがフィードバックと理解を深めるための素晴らしい方法であることに言及しています。

MicrosoftのFluent UIでは「ユーザーとデジタル体験の間に感情的なつながり」をもたらし、モーションが階層構造を確立するのに役立ち、またその動きによってパフォーマンスが向上している印象を生成するのにも寄与すると触れられています」

基本的に各社のデザインシステムでは、モーションの必要性や効果に対して言及がなされていますが、「もう少し深く掘り下げてみると、各社とも『イージング（加減速）の性質』を持ち合わせているのが特徴になっている」と池田さんは続けます。

また、アニメーションを用いた過剰な演出についての言及も各社共通で行われているそうです。

つまり、アプリケーションの性質によっても、アニメーションを入れる量について考えなくてはならないことを示しているわけです。

一定の品質を担保するためのデザインシステムの必要性

次に池田さんは現場寄りの話として、一定の品質を満たすためのデザインシステムの必要性について説きました。

ICSの場合、サイト制作のフェーズでは「設計から実装の間でアニメーションを検討することが多い」とのことです。

「アニメーションを考える際、『そもそも利用者にとってアニメーションが必要か否か』を検討します。toCの場合、ゲームのUIを作る場合はアニメーションを盛り込んだ方が没入感を高める体験の創出につながりますが、コーポレートサイトや製品サイトの場合はリッチに上品に魅せるためのアニメーションの活用を考えたりします。また、toBにおけるウェブシステムやイントラサイトでは、アニメーションがない方がいいケースもあるので、適材適所での判断を意識するようにしています」

また、実装前の準備としてはベンチマークサイトの共有や、要件上必要なアニメーションの仕様化、実装メンバーの認識共有を目的にデザイナーの要望をドキュメント化することを行っているそうです。

ですが、どんなに準備を念入りに進めても「どうしてもデザイナーとエンジニアの溝が生まれてしまう」と池田さんは話します。

「『モーションが入ると思っていたのに実装されていなかった』と思うデザイナーと『デザインカンプにないから仕様だと認識していなかった』と思うエンジニアの間ではどうしても考えのズレが生じやすいと思っています。また、アニメーションの実装を担当するエンジニアによって、バラツキが起こりやすく、人によって演出が控えめだったりその逆で過剰すぎたりと、この点はどうしても避けられないと言えます」

仮にアニメーションの依頼をドキュメント化しても、未定義部分を解消するのは難しく、デザイナーとエンジニアとの“空白部分”が発生しやすいわけです。

こうした課題解決の一環として、ICSでは「文章の出現やスクロールの演出、モーダルダイアログ、ハンバーガーメニューなど、頻出するUIのお手本集の作成に取り組んでいる」と池田さんは説明します。

「お手本集は『最大公約数としての社内共通デザインシステム』という形で位置付けしています。ICSは受託案件が多いゆえ、いろんなデザインの方向性を考えなくてはならないので、案件ごとに表現を考え、最低限の品質の明確化を目的にお手本集を開発していければと考えています。そのほか、アニメーション実装のテクニックはオウンドメディアで積極的に発信し、社内外に向けてナレッジを蓄積していく取り組みを行っています」

他方、アニメーションの実装のデメリットとして「実装難易度がはるかに増大する」と池田さんは述べます。

「例えばマイクロインタラクションは表示面積が小さいだけで、複雑なものは制作時間がかかります。また、画面転換のトランザクションはURL遷移（ルーティング）を含めて仕組みを考える必要があり、開発時間がかかってしまう。このようにアニメーションは簡単そうにみえて、実は複雑な制御が必要になってきます。

それだけでなく、アニメーションの実装でミスをしやすいこともたくさんありまして、割り込み処理の際にボタンが連打できてしまわないか、パフォーマンスの実行時に負荷の高まりによって動作が重くなり、カクついてしまわないかといったことも起こりうるでしょう。こうした課題の対策として、NG例やOK例を示した社内チェックリストを用意しています」

また、アニメーションを組み込んだとしても、スクリーンリーダーで読み上げられるか、Tabキーなどでキーボード操作は可能かといったアクセシビリティの観点も重要視するように心がけているそうです。

池田さんは「より良いコンテンツ作りには、適材適所のアニメーション実装が求められる」とし、発表の内容をまとめ上げました。

「アニメーション実装は担当者によってバラツキが生じやすいため、明文化することが効果的です。そして、アニメーションの課題をクリアし、高品質な成果物を出すことを目指して
いくのがいいのではないでしょうか」

デザイン基盤を整え、プロダクト全体の生産性向上を図っていく｜Ubie株式会社

4社目はUbieでデザインエンジニアを務める大木さんが登壇。「デザインシステム運用とOKRの良い関係」をテーマにしたプレゼンテーションを実施しました。

「テクノロジーで人々を適切な医療に案内する」をミッションに掲げる医療AIスタートアップのUbieですが、「ホラクラシー」という組織体制を敷いています。
また、ホラクラシーのサークルごとにOKRを策定し、クオーターごと（3ヶ月）で振り返りと再策定を行う運用を実施しているそうです。

数あるサークルの中に「デザインによる価値最大化サークル」というものがあり、主に以下のような取り組みを行っているとのことです。

「デザインの力によって柔軟かつスピーディーにプロダクト品質の改善と新たな価値創出を行うこと。そして、開発におけるデザイン基盤を整え、プロダクト全体の生産性向上を推進する目的で立ち上げた」と大木さんは言います。

そんななか、Ubieのデザインシステム「Ubie Vitals」では「ユビーらしいプロダクトデザインを支える集合知を蓄積し、アイデアを具現化する手助けとなる役割を担っている」と大木さんは説明します。

デザインシステムをOKRと絡めて運用するメリット

また、デザインによる価値最大化サークルでは、全社で定めるOKRとは別に独自のOKRを策定しており、次のように取り組んでいるとのこと。

「まずは前Qの振り返りを経て、今Qでやりたいことや、やるべきことを集めて発散します。その後、それらを分類してObjectiveを考え、ObjectiveごとにKey Resultsを定め、KR Promoter（KRを追う責任者）とGatekeeper（進捗管理者）を決めて全体像を明確化します。最後にKR PromoterがKRで達成するべき詳細を詰めていく流れになっています」

ポイントとして気をつけているのは「InvestとReturnをなるべく数値化すること」だと大木さんは話します。

「本来であればKRに数字が入っていればいいのですが、デザインシステムの構築においてはそれがなかなか難しいので、代わりにInvestやReturnに数字を入れることを意識しています。それに加え、OKRは具合的に書くことが肝になってきます」

デザインシステムをOKRと絡めて運用するメリットについては以下のように説明します。

「進捗を数値で可視化できるため、全体の状況把握がしやすくなるのがメリットになっていて、さらに『何ができて何ができなかったか』が記録に残るぶん、振り返りもしやすくなります。また、デザインシステムのどの部分に注力するかもチーム内外で共有できることから、デザインシステムに直接的に関係のないメンバーにも情報共有しやすいのも利点と言えます」

他方でデメリットについても大木さんはこう示しました。

「数値化しにくい目標を管理するのが苦手で、コミットするメンバーもプロダクト開発との兼業になるので、どの程度の工数が割けるかが不明瞭になりがち。さらに、どのくらいの進捗が出せるのか読みづらい側面もあります。また、OKRの特性としてストレッチした目標を立てるため、3ヶ月より長いスパンのロードマップをしっかりと決めて一緒に運用していくのは相性が悪いと感じています」

そして、組織的なイシューも見ておかなければなりません。

兼業で関わるゆえ、進捗が悪く見えてしまったり、事業開発の優先度の兼ね合いから、デザインシステムの構築に労力を割けなかったりと、スタートアップならではの課題も出てくるでしょう。

「ユビーではメンバーの入れ替わりが激しく、3ヶ月ごとにチーム体制が大きく変化するので、サークルメンバーも流動的になりがちになっています。この辺りは課題感を持っていて、固定メンバーを設けるなども視野に入れつつ、改善できればと思っています」

最後に大木さんは、今後やりたいことの抱負を述べ、登壇者プレゼンテーションを終えました。

「デザインシステムのサポート体制構築や社内への浸透もOKRで進捗管理できればと考えています。そして、優先度の決定やメンバーの固定化などの方法を模索しつつ、採用・企業ブランディングの観点からもデザインシステムを外部公開できるように準備を進めていきたいです。」

予想を超える反響をいただいたため『#DesignSystemBuild -デザインシステム構築の様々なアプローチ-』の動画を期間限定で公開中！

『RAKSUL DESIGN MAGAZINE』では、RAKSULに所属するデザイナーをはじめとしたスタッフが書いた記事を、定期的に更新しています。是非フォローいただけると嬉しいです。

✔︎RAKSUL のデザインエンジニアとカジュアル面談
✔︎ RAKSUL DESIGN MAGAZINE（note）
✔︎ Twitter
✔︎ RAKSUL DESIGNの紹介
✔︎ RAKSUL デザイナー採用情報