天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

【ニジボックス主催】失敗から学ぶデザインシステム:成功への道をエンジニアと共に

nijibox.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

デジタル庁がデータを公開したことでも話題になったデザインシステム。言葉は聞いたことがあっても、深くそのことについて理解している方は意外と多くないのではないでしょうか。

当イベントでは、ケーススタディからデザインシステムの実態に迫っていきます。デザインシステムは、製品やサービスの一貫性を確保し、そのスケーラビリティを拡大するための強力なツールです。ただ、デザインシステムの導入によってより一貫性のあるデザインと効率的な業務フローを確立する企業がある一方で、導入したもののうまくワークせず、途中で断念してしまった企業もあるのが事実です。

今回はそんなうまくいかなかったケースから、原因を深掘りし、我々が学ぶべきこととその対策を議論していきます。 なぜうまくいかなかったのか。失敗しないためにはどうすればよかったのか。エンジニアの視点から模索します。

デザインシステムのポテンシャルを最大限に引き出し、失敗しないための方法を共に探求しましょう。

会の様子

デザインシステムとは?

最初にデザインシステムの紹介がありました。

一貫したWebサイトを提供するためのものであり、開発効率の向上や学習コストの低下、エンジニアとデザイナーの共通認識の構築が利点として挙げられるということです。

【失敗例1】デザインシステムを導入したけど使われない

プロダクトの進化に伴いコンポーネント呼び出しが変化してしまった場合など、デザインシステムが定着しない状況に対してどのように対処していくのか?という話がありました。

必要性を感じられるようにデザインシステムの作成者が啓蒙することや、「これがデザインシステムだ」という風に形から入ってしまうのを避ける(=問題からスタートせずカタログからスタートしてしまうのを避ける)のも重要だということでした。

また、デザインシステムには必要な部分だけインクリメントに定義を増やしていこうとするのも大切だということです。

【失敗例2】デザインシステムを導入した結果開発工数が逆に増えた

続いて、デザインシステムを導入した結果、定義した結果あるべき状態との差分が明確になってしまい、既存の状態を改修することになって開発工数が増えてしまったという事例に関して話がありました。

デザインシステムを導入した後は、デザインシステムのルールを改修する期間を一定設けた方がよいということで、ルールにいきなり従う状態を作るのは悪手だということです。

また、フェーズによっては作り切ることが大切なフェーズというのもあるので、そのような状態でデザインシステムを導入するのは、開発効率がかえって落ちることもあるという話もありました。

デザインシステムの理想的な始め方

デザインシステムを今から始めることを検討しているような人は、まずは「ちいさくはじめるデザインシステム」を読むと良いという話がありました。

具体的には、それぞれの課題に対してどのようなアプローチを取るとよいのか?という話が事細かに書いてあるのが特によいのと、プロダクトだけではなくブランド全体に適用できるようなデザインシステム(=ロゴやブランドのフィロソフィーなど)を作る過程が説明されているのが良いということです。

また、原則が生まれるたびに言語化するという話や、志のある少人数メンバーで進めるという話など、実際にデザインシステムを運営する上で共感できる話が多数出ていることや、デザインシステムを導入している会社のインタビューが複数紹介されている(=デザインシステムの導入や運営が会社によってぜんぜん違うことを実感できる)のも好印象だったということです。

会全体を通した感想

実際に運用をされている上での失敗事例をベースに話されるという切り口はあまりない形だったので面白かったです。

「デザインシステム」を他の新しい仕組みに置き換えても言えそうな話が多かったので、デザインシステムならではという観点でも少し話が聞けると、よりよいなあと思いながら聴いていました。