『デザインシステムのプロセスを確立することで、デザイナーや開発者、関わるすべての関係者が最高のパフォーマンスを出せるようしたい』

Saas事業を担うプロダクトカンパニーでは、2018年からデザインシステムの検討・テスト導入が始まり、2022年から「Allied Desigin System（アライドデザインシステム ）」と題して、複数のプロダクトを横断したUI・UXの統一を目指しています。

今回は、デザインシステム導入を主導したフロントエンドエンジニアの吉原ゆりさんと、プロダクトカンパニーCDOの相原幸司さんに導入背景や目指す姿についてお話を伺いました。

吉原ゆり（よしはら ゆり）
2016年に新卒でアライドアーキテクツに入社。バックエンドエンジニアとしてモニプラやbrandtouchの開発に携わり、2019年頃にフロントエンドエンジニアに転身。現在はフロントエンドチームのリーダーとして、echoesやLetroの開発に携わりつつ、デザインシステムプロジェクト推進に奮闘中。

相原幸司（あいはら こうじ）
大学在学中アルバイト先の出版社でWebや印刷デザインを始める。2001年よりフリーランスのWebデザイナー。大手書店チェーンなどのWebやブランディングデザインを手がける。2013年アライドアーキテクツ入社。2019年より現職。プロダクトカンパニーCDOとして、プロダクトとビジネスコミュニケーションの両デザイン領域を管轄。

ーーまず、プロダクトカンパニーでデザインシステムを導入した背景について教えてください。

吉原：はじめはフロントエンド開発の改善のために、フロントエンドエンジニアとデザイナーでAtomic Designについて話をするようになり、2018年の秋くらいから「まずは1つのプロダクトからやってみよう！」と、当時展開していたbrandtouch（ブランドタッチ）というプロダクトで初めてデザインシステムを導入しました。

相原：最初brandtouchでスタートしたときは、「開発フローがスムーズになるように」とか、「自分たちの負債をいかに減らすか」っていう開発視点からのスタートだったね。

吉原：そうですね。背景としては、当時社内にフロントエンドエンジニアがいなくて、主に業務委託の方がデザインやコーディングしたものを、バックエンドエンジニアがVue.jsを使って実際のプロダクトに埋め込んで実装していました。

ただ、HTMLをVueに移植するという二度手間が発生して、デザインの反映ミスが起きやすい状況になっていたり、バックエンドエンジニアのほとんどはベトナムの方だったこともあって、デザインの追加や修正するのにもかなりのコミュニケーションコストがかかっていました。

そこで、フロントエンドエンジニアがVueも含めたフロントエンド領域を担当するようにしたのですが、今までバックエンドエンジニアがルールもなく実装していたこともあり開発しづらい状態だったので、フロントエンドのルールをつくろうという方向性で話が進んでいきました。

併せて、デザインもデザイナーと連携してデザインシステムベースで認識合わせた上で実装していこう、となったのが始まりですよね。

相原：そうだね、ただ実際フロントエンドエンジニアとデザイナーで認識合わせて動こうってなったのは2021年あたりからで、本格的に導入を始めたのはechoes（エコーズ）というプロダクトからです。

それまではルールとしてデザインシステムをベースにしてるだけで、フロントはフロントエンドエンジニアで、デザインはデザイナーで、という感じで、、

実際にしっかり連携を取れていたわけではなかったですね。

ーー初めてデザインシステムを導入したbrandtouch（ブランドタッチ）ではどのようなことをしたのですか？

吉原：まずは、世界的に浸透しているUI設計手法であるAtomic Designをコンポーネント設計に採用しようと決めました。ただ、Atomic DesignはUI設計手法なので開発にそのまま使うのは難しく、いざ導入しようとしたとき、「実際のフロントエンドの開発に取り入れるにはどうしたら良いか」、となりました。

なので、Atomic Designをベースにどのように分類するのが良いか、どう名前をつけるか、、など一つ一つのルールをデザイナーと相談しながら決め、チームに合ったルールを作ることからスタートしましたね。

相原：Webデザインではこれまでページ単位で作ってきた歴史があります。なので昔、Photoshopとかを使ってWebデザインをしていた頃は、いわゆる「シンボル」とか「コンポーネント」などの概念がほぼなかったんですね。

一方でフロントエンドではページ毎にある共通のパーツがコンポーネントごとに分かれて作られてます。プロダクトのデザインでは2017年前後にSketchというツールを導入したのですが、これがシンボルやコンポーネントをものすごく容易に開発できるきっかけになりました。

Sketchのブームがきたタイミングと、先ほど言ったフロントエンド開発の課題が大体シンクロしていたときに『じゃあbrandtouch（ブランドタッチ）でSketchを使ってデザインシステムを作ってみよう。』『共通言語がAtomic Designなら色んな文献や先例もあるから導入しやすそうだね』という話になりました。

なので、例えばAtomic Designアトミックデザインには、Atoms、Molecules、Templatesなどの概念があるのですが、コンポーネントの単位を分けていくときに、どこに属するのかや名前にどう命名規則を作るかなどを固定化してからコンポーネントを増やしていくような作業を最初はしてましたね。

プロダクトを横断したUXの統一を目指して

ーーアライドにはLetro（レトロ）、echoes（エコーズ）など複数プロダクトがありますが、個々のプロダクトで導入していき、組織横断の「Allied Design System（アライドデザインシステム）」を掲げて走り出したのはいつ頃からですか？

相原：2022年頭からです。2021年の冬くらいにechoesのデザインシステムが他プロダクトと機能が共通するコンポーネントまで出来上がってきて、これならプロダクト間の横軸通せそうとなったのでAllied Design Systemと掲げました。

また、現在行っているLetroの開発でも改めてLetroのAtomic Designやコンポーネントを整理しています。

実はLetroは過去に1度大幅なリニューアルをしているのですが、実施したのが2019年の春ごろだったのでもう3年経つんですよね。やっぱり油断してるとちょっとずつデザインシステムが崩壊していたりするんですよ（笑）

吉原：そうですね（笑）brandtouchもそうだしLetroもそうですけど、最初の方にやったデザインシステムは結構探り探りだった部分があって、名前の付け方が微妙だったり、コンポーネントの単位が適切じゃないものもあったりして。

そういったものは、echoesで整理して作ったデザインシステムを参考に見直してAllied Design Sytemとして統一を進めています。

ーーAllied Desigin System（アライドデザインシステム）について詳しく教えてください。

相原：「アライドアーキテクツが提供するプロダクトは、統一してこういうことものを大事にしています」というものをアウトプットし、見えるものにして見せておきたいということを意図してAllied Desigin System（アライドデザインシステム） と仮に名前をつけています。

例えば、brandtouch、echoes、Letroと仮にこの3つのプロダクトだけでみると、どのプロダクトもUGCを収集して〇〇（まるまる）するんですね。この「〇〇する」という部分がプロダクトによって違うのですが、”UGCを集める”という部分は共通です。

この”UGCを集める”というUXを、AとBとCのプロダクトでバラバラにしてしまうとアライドアーキテクツとしてどのようにUGCを扱っているかの意味合いを変えてしまいます。なので、プロダクトは変われど”UGCを集める”という機能で、共通のUXを実現するのがAllied Desigin Systemの究極的な目標ですね。

それを実現するとなると、それぞれのプロダクトのUIがある程度共通化されている必要が出てきます。そのために必要になるのがデザインシステムの概念で、プロダクトA、B、Cで最終的な効果の出し方は変わるけど、その間のプロセスを共通化していくことで、お客様の体験を良くすることができます。

その他にも、開発スピードの向上や、スムーズに議論を進められることが見込めるというのもあります。これがプロダクトカンパニーにAllied Desigin Systemというデザインシステムを導入した理由です。

導入を進めていく中で感じている効果と課題

ーーデザインシステムを導入してどのような効果がありましたか？

相原：全体的にいい効果が出てると思います。

例えば要件定義要件定義などの上流の話をするときに画面（ワイヤーフレーム）を見ながら議論を進めたいという要望が出てくると思うんですね。

その際に例えば、ワイヤーフレームをフリーハンドで書いてみたり、ホワイトボードを使って上流を決めた後にデザインに入るというフローだと、実際に上がってきた実物に近いデザインを見たときに「あれ、イメージ違くない？」という話になることがありました。

一方でデザインシステムがあると、ボタンの色やマージンなどの要素が先に決まってるので、ワイヤーフレームを実デザインデータを組み合わせて短時間で作ることができるというメリットがあります。リモートワークが中心になり、直接ホワイトボードや画面見ながらのMTG頻度が減っている中、実際にリリースされる画面に近いモノを見ながら議論ができるので、以前より議論の精度が上がっている実感がありますね。

また議論の精度が上がるのに比例して、開発スピードも上がってきています。
デザインシステムを導入したことによって、手戻りや大きな認識齟齬が無くなってきつつあるので、上流工程を中心に様々な点で、このような良さを実感しています。

ーーフロントエンド側ではどんな効果を感じていますか？

吉原：やはり、デザインや挙動がデザイナーと認識合わせて作られたパーツが使い回せるので開発が楽になりましたね。

特に、現状フロントエンドエンジニアの人数が足りていない部分もあって、バックエンドエンジニアにフロントの実装を協力してもらう事もあるのですが、そのときに認識齟齬によるデザインの乖離がなくなってきました。

フロントエンドエンジニアだとデザインの細かい調整も効くのですが、ベトナムのバックエンドエンジニア開発するとなると、これまではどうしても言語や伝え方の面で全体的な認識に誤差が起きやすく、修正するにも言語の壁があったりして、共通認識が取れるまでに時間がかかってしまうことが多くありました。

ただ、デザインシステムを導入してからは、フロントエンドのソースコードとAtomic Designが基本的な共通言語としてあるので、比較的ノンバーバルコミュニケーションに近い形で、言語や伝え方等によるアウトプットクオリティやスピード感の課題がかなり少なくなっているというメリットがありますね。

ーー逆に、導入を進めていく中で課題に感じている部分はありますか？

吉原：フロントエンド開発の領域では、「既存のシステムへの反映が難しい」というのはあります。
実際にデザインシステムを導入していくとなると、リファクタリングと同じような形になっていくので、それをどこまでどの範囲でやっていくかを考えるのが難しいところですね。

例えば、既にライブラリを導入してるとそこも含めてリファクタリングしないといけないので、既存のシステムありきでどういう風に変えていくかを考えるのに一番頭を使っていますね。

相原：デザイン側の難しさは、ロジックをどう組み立てるかの部分ですね。さらに言えば、アライドみたいに複数のプロダクトを持っている会社が会社としてのデザインシステムを構築するにはどうすればいいのかを考えるのはやっぱり難しいです。

Allied Desigin Systemって聞こえは良いですけど、実際は『LetroではこのUIが適切だけど、echoesでは適切ではない』みたいな部分ももちろんあるんです。
そこにどう横串を通すかを考えるのが最大に難しいポイントであり解決しないといけないポイントでもあると思っています。

優れたUXの実現を目指して

ーーAllied Desigin System（アライドデザインシステム）の今後の展望を教えてください！

相原：Allied Desigin Systemは何を参考にしたかというと、クリエイティブを作るためのプラットフォームとして絶対的な存在のAdobeです。この”クリエイティブを作る”という1つのUXを実現するためのUIコンポーネントがAdobeのソフトウェア間で相当統一されているんですよ。

例えば、AdobeのIllustratorやPhotoshopを使ったことがあれば、静止画デザインしか作ったことがなくても動画など他メディアのクリエイティブも作れるようなUI状態を実現してます。そうすると結果的にこの世に出ていくデザインの量も質も上がり、それを見た人たちの感性のレベルも上がっていくという世界観があるんですね。

要はAdobeを使えば社会全体のデザイン全体のレベルが上がっていくのがAdobeの世界観だと思います。

もちろん僕たちがAdobe社と同じことを実現できるとはおこがましくて言えませんけど、最終的に目指すのは自分達のプロダクトが社会やビジネスの課題を解決するのはもちろん、社会全体のデザインレベルの向上に貢献している状態です。

僕たちはマーケティング業界の中で、僕らのプロダクトを使ってくれているお客様や、見てくれる消費者のみなさんが「デザインが良くなった」という実感が湧くよう、それに繋がる第一歩としてAllied Design Systemの構築をしたいと思います。

吉原：フロントエンドとしては、そういった私たちの考えるAllied Design Systemを全アライドアーキテクツのプロダクトを通じて、早く確実に届けられる環境をつくりたいと思っています。

今はまだ、各プロダクトや開発における問題を解決するために、デザイナーと一緒にDesign Systemを定義し、各プロダクトへ適用し始めたところですが、デザインシステムのプロセスを確立することで、デザイナーや開発者、関わるすべての関係者が最高のパフォーマンスを出せるようしたいと思っています。その中で、ユーザーにより良い体験を届けられるように追求し続けることで、より優れたUXを実現していきたいと考えています。

また、アライドアーキテクツのプロダクトとしてUXを一貫して提供できるように、全プロダクトにデザインシステムを展開していく予定です。最終的に、Allied Design Systemの世界観や思いを感じ取ってもらい、お客様と共に成長していくプロダクトを目指したいと思っています。