【第１段・デザインシステム導入直前取材！】デザイナーとエンジニアが課題解決に向けた新たな試みをしているらしいので聞いてみた！

▽こんにちは、スペースエージェントのたかもりです。

スペースエージェントでは現在、新たに ``デザインシステム`` というものを導入しようとしています。
本導入自体はまだ先ですが、デザイナー2名が中心となり、開発チームを巻き込みながら準備を進めてくれています！

そんなデザインシステムについて、デザイナー2名からお話を聞いてきました！

デザインシステムって何ですか？

デザインシステム（Design Systems）というのは、『デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法』のことです。

簡単に言うと、デザインに関するあらゆるルールを定めたものと言った感じです。

重要なのは、『目的を達成する』という部分。
つまり、『目的に応じてあらゆる決定を下していく』ということを定義します。

今回で言うと、その大きな目的は、『反響アップや仮説検証の施策をより素早くリリースすること』
その他には、大きな規模でのブランド統一や視覚的な一貫性、チームワークと共同作業などの目的があります。

続く文言については、以下のように捉えています。

▼ デザインシステムの導入プロセスは、このような感じ。

説明すると、まず会社やプロダクトの目的や価値を改めて考え直し、デザイン原則を作っていきます。

そして、今あるプロダクトのデザインを『機能パターン（インターフェースの実体のある実行可能な部分）』と『認知パターン（個性を視覚的に表現するエモーショナルな外観）』に分けて、検証していきます。

要は、一つのデザイン要素だけを集めてそれらを比較し、何がどのような目的で使われているかをエンジニアと共通理解する。そして、改めて定義をし直していくようなイメージです。

それらを言語化することにより、要素の目的が具体的になるので、エンジニアとデザイナー間の要素に対する認識を共通化させることができるようになります。

最終的に、それらパターンと使用方法を、パターンライブラリに収集し、利用していくという流れです。

▼ 導入するにあたり、参考にしたオススメの書籍です。

Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド
（アラ・コルマトヴァ/著, 佐藤伸哉/監修, 株式会社Bスプラウト/翻訳）

Atomic Design ~堅牢で使いやすいUIを効率良く設計する
（五藤佑典/著）

どうしてデザインシステムを導入しようと思ったのですか？

実は今、エンジニアが開発したものをデザイナーがチェックする際、デザイン観点での修正が多く、かなり工数がかかってしまっています。
デザイナーとしては勿論デザインを担保しなければならないのですが、その工数のために開発スピードが減速してしまい、そこに課題感を持っているという状態です。

■ スペースエージェントの課題感

１．スタートアップなのに施策が遅い
２．都度デザインが常態化して統一感がない
３．エンジニアと共通認識がない

そこで開発サイドより、「これらの課題を解決し、反響アップや仮説検証の施策をより速くリリース出来るようなシステムづくりを行ってほしい。」という依頼をもらい、すべての課題を解決していくために新たなシステム導入を考え始めました。

最初は、「工数を削減すればいいのなら、アトミックデザインを入れるのはどうか。」と考えました。
アトミックデザインというのは、デザイン要素（UIパーツ）を最小単位まで分解することで再利用性を高め、それらを組み合わせてページを作成していく方法です。
アトミックデザインを用いると、全てとは言えなくとも、エンジニアがデザイナーに確認することなくコーディングできる部分が大幅に増えるため、開発のスピードアップが期待できます。

しかし、アトミックデザインは完全にHOWであり、エンジニアがそのページやデザイン要素の『目的や意図』を理解することが出来ないんですね。
そのため、エンジニアがデザイン要素を視覚的な部分だけで判断し、デザイナーの目的や意図と異なる使い方をしてしまうかもしれないと気が付きました。
そうなると、結局デザイナーの確認が必要になり、最終的にシステム自体が破綻してしまうかもしれないというリスクから、それならば ``もっと本質的なところから構築していったほうがいい`` と考えました。

そこで、デザインシステムの導入を決めたのです。

導入プロセスの詳しい方法や、意識していることなどをお聞きしたいです！

プロセスとしては、まず、エンジニアに向けてワークショップを開催しました。

正直、現状では、エンジニアがデザインを理解できておらず、一方でデザイナーもエンジニアを理解できていない部分があります。
もちろん互いに理解がなくとも、エンジニアがデザインを完全に再現できるのであれば問題ないかもしれませんが、みんながみんなそのようなスキルセットがあるかと言うと、そうではありません。
そうなると、やはり理解し合うことや、定義としてルール化することが必要になってきます。

そこで、そのような齟齬があることをエンジニア側にもしっかりと意識してもらう為、ワークショップ形式で時間をかける事を意識しました。

まず概要を説明し、そこからデザイン原則を定義していきます。
他企業の事例などを参考にしつつ、自分たちでしっかり考えました。

デザイン原則を定義する

手順 1. プロダクトの目的を定義する

これまで、『プロダクトの目的は何か』という部分の定義付けをしてこなかったので、このタイミングでプロダクトの目的を明確にしていきます。

その際に、会社として掲げているミッションやビジョン、バリューなどを再確認し、会社としての目的を思い出す作業を行います。
さらに、スペースエージェントではOKRを導入しており、今回のデザインシステムの導入も Key Result としてOKRツリーに紐付けていくのですが、OKR上で掲げているクオーター毎や1年後の目標を再確認し、改めて認識の共有を図ります。（OKRについてはこちらの記事で！）