ツール

次世代デザインツールはどこへ向かうのか　後編

Yasuhisa Hasegawa

• 4 min read

デザインをスケールさせていく

デザインツールの現在と未来を考えたとき、デザインシステムの存在は無視できません。今のデザインツールはデザインシステムの作成・運用に最適化するための機能実装がされています。

  • 一貫性のあるデザインの作りやすさ
  • コンポーネント（部品）として捉えた UI の管理
  • 複数人のデザイナーによるプロダクトデザインの運用
  • コードへの書き出しなどエンジニアとの連携

ひとりのデザイナーに頼るのではなく、組織でデザインを運用していくためにデザインシステムのニーズが高まってきています。欧米ではここ数年でデザイナーとエンジニアの比率が小さくなってきている状況をみても、デザインが個人プレーからチームプレーになってきているのが分かります。

表現力だけでなく、周りとの連携・共有ができるツールが求められているのも、デザイン担当者がひとりで黙々と作るものではなくなってきているからでしょう。より早く改善・模索を繰り返すことが要求されているので、チームとして前進できるツールが求められています。

デザインシステムの先にあるもの

デザインシステムはデザインをスケールさせていくための通過点です。一貫性を保つためのガイドラインとしてだけでなく、非デザイナーでもデザインの実装をしやすくするためのデザインシステム。しかし、カタログ化されているだけで運用が追いついていない場合もあれば、実装への壁が高いこともあります。

前回、html-sketchapp のように HTML ファイルを Sketch ファイルに自動生成するツールを紹介しました。しかし、この方法だとコードが書ける方が主導の運用になるのでデザイナーが参加するのが難しくなります。今年に入って、デザインファイルからのコードの自動書き出しする手段が増えてきています。

  • Sketch2React : Sketch ファイルから React へ書き出し
  • Figma to React : Figma ファイルから React へ書き出し
  • Relay : Figma ファイルからアセットの書き出しを自動化
  • Framer X : React アプリが作りやすくなるデザインツールを開発中
  • UXPin : 自社で提供しているデザインシステム機能からコードへ書き出し

より早く、より効率的に動くには繰り返し作業の自動化が欠かせません。上記で紹介している手段はその第一歩と呼べるでしょう。こうした課題はデザイン特有のものではなく、開発では 10 年以上模索が続けられています。アプリケーションの構築、サービスの連携、テスト、リリースはもちろん、インフラの管理なども自動化しなければいくら人がいても足りません。

例えば以下のようなツールを用いて開発の効率化・自動化をしています。

  • Git : コードのバージョン管理の効率化
  • Chef: サーバ設定や更新を自動化
  • New Relic : パフォーマンス監視を通して課題発見
  • Docker : 仮想的に複数のOSを動作できるテスト環境の構築
  • Jenkins : ビルドやテストを頻繁に繰り返すためのツール

従業員の能力、開発環境、組織文化、要件に応じて複数のツールを組み合わせてワークフローにある『溝』を埋める試みがされています。プロダクトの開発と運用をシームレイスなサイクルにするための試みを DevOps と呼んでいますが、このデザイン版である DesignOps が昨年から注目さています。デザインツールが React をはじめとした開発フレームワークと相性が良くなってきているのも Ops（運用）しやすくするための試みと言えるでしょう。

デザイン環境をデザインする

DesignOps は デザイナーを数十人以上抱えている組織で必要とされている考え方なので、積極的に取り入れることはありません。しかし、デザインの構築と運用の課題はデザイナーが 2, 3 名しかいない組織でもあります。デザインツールを選ぶ際も、構築と運用両方をみて決めるのが理想です。デザイナーにとってすごく扱いやすいツールでも、データの受け渡しや意思疎通を難しくするのであれば、全体工程を遅くしてしまうからです。

デザイナーが使うツールとはいえ、デザイナー視点だけではなく以下の課題をどう向き合うかで決めるべきだと考えています（幸い、選択肢はたくさんあるので吟味できるようになってきています）。

  • 人 : デザインプロセスに関わるのは誰か？その人たちはどこにいてどういうポジションなのか？
  • ワークフロー : 設計から実装までのワークローは？デザイナー以外が既に使っているツールはなにか？
  • ガバナンス : 働き方・作り方でボトルネックになっているところは？ツールの運用・教育をどうしていく？

DesignOps というバズワードを使うかどうかはさておき、よりデザインの実装がしやすくするような環境作りはチームで動くためには欠かせません。Web サイト、アプリ構築というスケールの大きいところからスタートするのではなく、小さなところから挑戦して自社に合うやり方を見つけるのも手段です。

以前からデザインシステムという大きなものを作る前に色から始めることを勧めていますが、ツール、ドキュメンテーション、オペレーションの連携で苦労することがあります。Webだけなら楽かもしれませんが、iOS、Android も含めるとどうやって管理すれば良いのか迷います。そんなとき Theo のようなツールをつかって、yaml ファイルから各プラットフォームでつかえるカラーパレットを自動生成すればデザインと実装の効率化が可能です。

小さなところからデザインの効率化の恩恵を体験して徐々にやれる範囲を広げるのも手段ですし、こうしたことが実現できるデザインツールが今後の選ぶポイントになるでしょう。

おわりに

今のデザインツールは良くも悪くも「チームスポーツとしてのデザイン」「再現性の高いデザイン」を支援するものへと発展してきています。個々のデザイナーのもつ表現力をサポートするのであれば、Photoshop や Illustrator で解決しているので、あえて同じ部類のツールを作る必要はないのかもしれません。

ただ、組織化してデザインをスケールさせていくというニーズのない現場との相性が悪いのも事実。次々と新しいデザインツールを出している欧米のデザイン事情と日本とでは異なることから、今のデザインツールの発展に違和感がある人もいると思います。日本ではデザインシステムという『新しいプロダクト』を作れる体制があるところが少ないなか、欧米では次のステージへ走り出している状況を比較しても違いがあります。

欧米は進んでいて日本は遅れているという安易な結論付けは良くありません。日本でデザインの仕事をするという現実の中で、地に足をつけた施策が必要だと思っています。デザインツールの現在と未来を振り返ったのも、全体の潮流を見た上で、次のステップを踏んでいただきたいからです。流行っているツールや手法を片目で追いつつ、何をすべきかを考える上で今回のシリーズが役に立てば幸いです。

Yasuhisa Hasegawa

Yasuhisa Hasegawa

Web やアプリのデザインを専門しているデザイナー。現在は組織でより良いデザインができるようプロセスや仕組の改善に力を入れています。ブログやポッドキャストなどのコンテンツ配信や講師業もしています。