これまでさまざまな組織のデザインシステム構築や運用を支援してきたグッドパッチ。本連載ではデザインシステムにフォーカスし、その概要や歴史、導入から運用、構築にいたるまで網羅的にお届けします。第3回は「デザインシステムのはじめかた」についてです。

※本記事はウェブマガジン「CreatorZine」に2023年12月20日に掲載された記事を再掲載したものです。

---

こんにちは。グッドパッチのUIデザイナーの乗田です。前回の記事「組織にデザインシステムが必要な理由とは──その効果や価値を徹底解説」では、デザインシステムの必要性や効果、価値について解説しました。第3回ではデザインシステムを構築する前に理解しておきたいポイントや、デザインシステムの構築サイクルについて紹介します。

デザインシステム構築をはじめる前に

デザインシステムへ取り組むきっかけとして多いのは、プロダクト開発で課題を感じている個人の活動から構築がスタートするケースです。この記事を読んでいるみなさんの中にも、個人や有志による少人数のチームでデザインシステムに取り組んでいる方がいらっしゃると思います。

一方、デザインシステムの構築が組織の活動として昇華されている例はまだ少ないのが実状です。これまでの連載でお伝えしたように、デザインシステムには組織課題を大きく解決する力がありながらも、構築の取り組みが個人の域にとどまってしまうのはなぜでしょうか。

その原因には、デザインシステムの価値を引き出すことができていなかったり、価値があっても組織への共有や訴求が十分にできていなかったりすることが考えられます。個人や有志によって構築されたデザインシステムが形骸化してしまうケースでは、「価値を届ける」という観点が不十分なことでデザインシステムが組織へ浸透せず、少しずつその活動にリソースを割くこともできなくなり、プロジェクトが終了する、ということが珍しくありません。

デザインシステムは組織課題を解決するためのソリューションであることからもわかるように、個人の取り組みだけでは発揮できるバリューに限界があります。だからこそ本記事のタイトルにもなっているように、デザインシステムは組織のみんなで構築して育てる必要があるのです。

それでは、デザインシステムを構築して価値を届け、それを組織の活動に昇華させるためには何がポイントとなるのでしょうか。今回は、構築プロセスに沿って紹介します。

デザインシステム構築に必要なサイクルとは

デザインシステムを構築する取り組みは、構築と運用のフェーズが直線的に連なっているものでも、最後にゴールがあるのものでもありません。構築のためには次の工程を循環させながら徐々に深め、より良いものにしていく必要があります。

1. 調査
2. 計画
3. 構築
4. 適用
5. 拡張

デザインシステム構築のサイクル：1. 調査

デザインシステム構築に不可欠な「価値を届ける」という観点において、ソリューションを策定する前に、まずは組織の状態を見つめる必要があります。

組織やそのメンバーが抱えている課題を分析し、デザインシステムを構築する際の戦略や実際のソリューションを導くのです。またこの時点で、課題を持っているメンバーの属性を把握しておくことが望ましいです。

例えば「エンジニアの開発効率低下」という課題解決を目的にデザインシステム構築のサイクルを回す場合は、エンジニアにとって活用しやすいフォーマットや表現のガイドライン、プロダクトに適用しやすい実装要件で構築されたライブラリなどが必要になります。

デザインシステムを提供する対象のメンバーの属性を深く理解することで、ソリューションがより価値のあるものになります。「価値を届ける」ことを前提にする以上、「調査」は欠かすことができないフェーズです。

より厳密に価値に向き合う必要がある場合や、課題に対するソリューションを適切に導き出すことが困難なケースでは、「バリュープロポジションキャンバス」や「価値仮説マッピング」を活用することでソリューションの確度を高めることができます。

デザインシステム構築のサイクル：2. 計画

調査が終わり次第、計画を立てましょう。調査フェーズで発見した組織内の課題やそれに対するソリューションを列挙し、課題の緊急度やソリューションの構築にかかるコストをもとに取り組みの優先度をつけます。デザインシステム構築プロジェクトの「バックログ」で管理できるのが理想です。

スモールスタートで段階的に取り組もう

デザインシステムのリリースサイクルは短いほど良いでしょう。構築を重ねて一般公開されているような完成度の高いデザインシステムを作ることは非常に魅力的ですが、組織へ価値を届けるという観点からはかけ離れてしまいます。

デザインシステムで組織課題を解決することを目的にしたり、いち早くデザインシステム構築の取り組みを組織の活動に昇華させたりするためには、小さいサイクルで構築サイクルを回し、最速で組織に価値をもたらすデザインシステムに育てることが大切です。

SmartHR社の例を挙げると、デザインシステムの運営理念に「WIPの精神で、すばやい提供を最優先します」と掲げていたり、自社で刊行したデザインシステムに関する書籍のタイトルを「ちいさくはじめるデザインシステム」と名付けていたりするように、スモールスタートを体現しています。

SmartHR Design Systemやその運営体制は規模が大きく完成度も高いため、現在デザインシステムの構築を構想している組織や、実際に構築に取り組んでいる多くのチームが参考にしているのではないでしょうか。その際は具体的な成果物だけではなく、その構築を支えている「ちいさくはじめる」という理念も合わせて参考にすることで、より良いデザインシステムへ近づくでしょう。

中長期的なビジョンを示すロードマップを作ろう

また、バックログと合わせて「ロードマップ」を用意できるとさらに良いプロジェクトにすることができます。ロードマップがあることによって、デザインシステムの中長期的なビジョンを簡単にイメージすることが可能になります。

デザインシステムを構築するチームのメンバーは、デザインシステムに対する解像度が高いことや、たくさんの良いデザインシステムをインプットしているため、デザインシステムが将来的にどのように拡大していくのかを具体的にイメージすることができるでしょう。そのためロードマップは、このようなメンバーに直接価値をもたらすものではありません。

一方、デザインシステム構築を「個人」ではなく「組織」の取り組みへ昇華させるためには、組織の中長期的な方針を策定するプロジェクトマネージャー（PM）やマネジメント層との連携が必要になりますが、彼らはデザインシステムの網羅的な知識がない可能性もあります。そういったメンバーとデザインシステムチームの連携を強める際に、ロードマップは効果的に機能するのです。

詳細はデザインシステム構築サイクル「5.拡張」のフェーズ紹介で後述します。

デザインシステム構築のサイクル：3.構築

計画が完了したら実際にデザインシステムの構築に取り組みます。このフェーズでは構築サイクル「1.調査」で発見した課題や、その課題を抱えているメンバーの属性が役に立ちます。

PMまたはPdMがワイヤーフレームやプロトタイプを構築する速度を向上させるためにデザインツール上のコンポーネントライブラリを構築する場合、コンポーネントだけではなくインタフェースのテンプレートまで用意することが望ましいでしょう。

前述のように、エンジニアの開発速度を向上させるためにフロントエンド用のコンポーネントライブラリを構築する場合は、プロダクトに適用しやすい実装要件で構築されていたり、エンジニアにとって活用しやすいフォーマットや表現のガイドラインが用意されていたりする必要があります。

また、構築の際はデザインシステムの利用者だけではなく、それを構築・運用するメンバー自身も考慮しなければなりません。

有志による取り組みの場合は構築のための工数が少ないことから、メンバーの負荷を抑えながら素早くリリースするためにも、外部ライブラリやドキュメント管理サービスなどを活用しながら進めるのが理想です。具体的な構築の取り組みについては、次回の記事でお伝えします。

デザインシステム構築のサイクル：4. 適用

構築が完了次第、組織へ適用していきます。このフェーズでは実際にデザインシステムを組織へ導入したり、活用してもらったりすることで課題の解決を図ります。

デザインシステムの構築を終えたら、アップデートした内容を組織内に展開しましょう。デザインシステムやその構築への取り組みを認知してもらうためにも、組織内のチャットツールやステークホルダーが集まる定期ミーティングなど、さまざまな形で周知の機会を用意します。

同時に、デザインシステム構築サイクルでターゲットとなるメンバーへは、個別にアップデート内容を周知する機会を設けましょう。課題解決をアシストするためにも、メンバーがデザインシステムを活用できるようにオンボーディングや教育をすることも重要な取り組みのひとつです。サイクルを回し始めた初期段階は、実際にプロダクト開発における課題が解消されるところまでをサポートし、構築したデザインシステムに問題や不備がないかをチェックします。

またこの段階では、デザインシステムの「価値のトラッキング」を行うことが望ましいです。デザインシステムを提供する前後でメンバーのワークフローにどのような差が生まれたのかを観察したり、提供前後での業務効率の変化を定量的に計測したりすることで、デザインシステムの価値を可視化します。

ビジュアル化したデザインシステムは、構築サイクルの「5.拡張」フェーズでデザインシステムの活動そのものの価値を訴求する際に役立ちます。

デザインシステム構築のサイクル：5. 拡張

構築サイクルを回し、そのデザインシステムを活用して組織課題を解決できたら、有志の活動からチームの活動へと転換させ、さらには組織全体の活動へと昇華させるための提案を行いましょう。

デザインシステムの価値を提示し、拡張を訴求しよう

先述のとおり、デザインシステム構築の取り組みを拡張するためには、PMや経営層など、組織の中長期的な方針を策定したり、決裁権を持っているメンバーとの連携が不可欠です。このようなメンバーとデザインシステムチームが連携を取る際には、構築サイクルの中で用意した次の資料やデータが役に立ちます。

• バリュープロポジションキャンバス
• バックログ
• ロードマップ
• デザインシステムの成果物
• デザインシステムによって変化した業務効率の差分

これらの資料を提示し、デザインシステムの価値や取り組む意義、中長期的な計画、組織にとってのアウトカムを共有し、デザインシステムへの取り組みを行うための予算（リソース）を確保します。

デザインシステムを構築するメンバーや利用するメンバーの視点は、どうしてもデザインシステムで得られる効果に向いてしまいがちですが、決裁者に価値を訴求するためには「デザインシステムの優位性」や「組織課題を解決する手段としての親和性」など、決裁者にとっての価値を彼らと同じ視点で伝える必要があります。

組織のみんなで構築サイクルを回そう

拡張の承認を得て予算（リソース）を確保できたら、デザインシステム構築の活動を広げていきましょう。

ここでまず追加したいのは「作業時間」です。有志の活動の場合は、主に通常業務の空き時間で行うため、時間の制約が厳しく、結果として発揮できるバリューにも限界があります。構築サイクルをより多く回すためにも、作業時間の確保は欠かせません。

続いて取り組むべきは「メンバー」の追加です。デザインシステムによって生み出せる価値の大きさはメンバーの職能や視点の多様さに大きく依存します。デザインシステムの価値をさらに最大化させるためにも、構築の取り組みを多様なメンバーによる活動に昇華させましょう。

それ以外にも、課題の調査に協力してくれたり、活用におけるデザインシステムへの気付きをフィードバックしてくれたりするメンバーを増やすことも効果的です。さまざまな形で協力してくれる人員を集め、組織のみんなでデザインシステムを育てられる体制を整えましょう。

まとめ

今回はデザインシステムを構築する前に理解しておきたいポイントや、その構築サイクルについて紹介しました。

デザインシステムで組織課題を解決するためには「調査」から「拡張」までのサイクルを小さく回すことが重要です。また、この取り組みを組織の活動に昇華させるためには、中長期的なビジョンや、デザインシステムによって生まれた価値を可視化して訴求することが欠かせません。デザインシステムやその構築の取り組みを“みんなのもの”にするためには、この両方を実行し続けることが大切なのです。

次回はデザインシステムの具体的な構築方法についてお届けします。