こんにちは。グッドパッチのUIデザイナーの乗田です。前回の記事では、デザインシステムを構築する前に理解しておきたい「調査」「計画」「構築」「適用」「拡張」の5つのプロセスについて解説しました。第4回では、「デザインシステムを構築するために必要な準備」をテーマにお届けします。

はじめに

　グッドパッチがデザインシステムの構築を支援する際、準備フェーズで行う作業はおもに次の4つです。

　準備のステップが多いと感じる人もいるかもしれませんが、これらはこの先のデザインシステムを構築・運用するフェーズで、迷いが生じた際にいつでも立ち戻れる「土台」として機能するため、これらのステップは欠かせません。

　一方、準備フェーズのアウトプットは組織に直接的な価値をもたらすわけではありません。そのため、もしデザインシステムに割けるリソースが限られている場合は、次回紹介する「トークンの定義」や「コンポーネントの構築」から着手することをオススメします。

　デザインシステムは常に価値を創出しながら作ることが望ましいものです。構築に決まった順番はないため、あくまで組織にとって価値がある部分から少しずつ取り組んでいくことを意識しましょう。

プロジェクトビジョンの策定

　プロジェクトビジョンは、デザインシステムを組織で構築・運用する際の目的や目標を可視化したものです。プロジェクトの目的が不明瞭だと、チームがゴールに向かって進むことが難しくなります。そこで、チームが正しい方向へ向かってデザインシステムを構築するための羅針盤のような役割を果たすのが「プロジェクトビジョン」です。デザインシステムチームの共通指針であり、意思決定の基準として機能します。

　プロジェクトビジョンは「目的」「目標」「課題」「手段」の4要素で構成し、ツリー状に表現するのが良いでしょう。

　プロジェクトビジョン策定で大切なのは「デザインシステム本位にしない」ということです。これはつまりデザインシステムの構築をプロジェクトの目的にするのではなく、プロジェクトの目的を実現するための“手段”としてデザインシステム構築が存在するということです。手段と目的を履き違えると「せっかくデザインシステムを作ったのに、何の課題も解決できなかった」といった落とし穴にはまってしまいます。

　次のツリー図は、グッドパッチがデザインシステムの構築・運用を支援する際によく策定するプロジェクトビジョンを抽象化したものです。

　このツリーを構成する4つの要素について、策定に至った背景や策定時に注意したいポイントを紹介します。

1. 目的

　目的では、このプロジェクトで達成したいことを定義します。

　グッドパッチが手がけたこれまでのデザインシステム構築の支援を振り返ると、「時間の使いかたを変える」という目的を起点にプロジェクトを進めていたケースがよくありました。この背景には、グッドパッチがデザインシステムを「クリエイティブのジャンプ台」と位置づけていることが大きく影響しています。

　デザインシステムは遵守すべきルールではなくガイドラインであり、創造的なアウトプットの前段にある意思決定を簡略化してくれる土台であるからこそ、「時間の使いかたを変える」ことを目的に据えることが多いのです。

　そのほかの目的として多かったのは、「チームのナレッジを良いデフォルトとしてストック・活用できる環境の実現」です。これはデザインの過程で生まれたナレッジを誰もが広く活用できる組織をつくるということです。チーム内で生まれたナレッジが再利用可能な状態で潤沢に用意されていることの効果は非常に大きいため、この目的もよく設定されています。

　ここで大切なのは、デザインシステムの“効果”を目的に掲げない点です。組織課題の改善プロジェクトにおいてデザインシステム構築という“手段”が前提にあると「一貫性の向上」や「共通言語の構築」など、デザインシステムの効果そのものに着目してしまいがちです。しかし、「時間の使いかたを変える」などのより根源的かつインパクトの大きい目的を設定することでプロジェクトの価値を最大化させたり、手段に縛られずにプロジェクトを進行したりできるようになります。

2. 目標

　目標では目的を達成するために到達すべき状態を明らかにします。グッドパッチではさまざまなプロジェクトにおいて、次の目標を掲げるケースが多くあります。

• ユーザーが課題解決に要する時間の短縮（Quality）
• チームのベロシティの向上（Cost）
• ユーザーに価値を提供するまでの時間の短縮（Delivery）

　「Quality」「Cost」「Delivery」の各観点を目標としている背景には、プロジェクトへ多面的な価値をもたらす狙いがあります。また、同時に重要なのは、それぞれ計測可能な目標であることです。定量的な目標を設定することで目的の達成度合いが明らかになるほか、プロジェクト前後の変化も可視化できるようになります。

　これらはすべて「成果目標」です。さらに目標の達成へと近づくためには、後述する「手段」を明らかにした上で、行動目標を具体的にブレイクダウンすることが望ましいでしょう。

3. 課題

　ここでは、先ほど設定した「目標」とのギャップ、すなわち目標達成を妨げる要因を挙げていきます。課題は「発生型」と「設定型」に分類して定義できると効果的です。

　発生型の課題では、過去から現在にかけて組織の理想の状態を阻害している課題を定義します。たとえば、次のようなすでに発生している業務課題です。

• 保守やレビューに多くの時間を要している
• メンバーによってアウトプットの量や品質に差が生まれている
• タスクの前提をすり合わせるためのコミュニケーションに多くのコストがかかっている

　発生型の課題は、「素早く正確に課題を解消し、組織に効果を還元するか」が重要です。これらを解消することで組織の生産性向上につながります。

　設定型の課題では、組織の理想状態を阻害するであろう課題を定義します。たとえば次のようなものです。

• メンバーが増えてオンボーディングにコストがかかる
• プロダクトの増加によりメンテナンスコストが増えたりリソースが足りなくなったりする
• アクセシビリティ要件への対応が遅れる
• メンバーが減ってリソースが足りなくなる

　設定型の課題は、「組織の将来の姿を高い解像度で見つめ、発生するであろうニーズを探索すること」が重要です。これらを解決することで、組織の付加価値向上につながります。

　「発生型」と「設定型」の課題はそれぞれ成果が求められるタイムスパンや効果が表れるタイミングが異なります。適切にアクションを実行するためにも、時間ごとに課題を分類して定義しましょう。

4. 手段

　最後に定義するのが、課題を解決するための具体的なアクションやソリューションです。たとえば次のとおりです。

• タスク管理と業務プロセスの最適化
• コミュニケーション効率の向上
• UIデザインや実装時の再利用性の向上

　このように定義した手段をもとに、デザインシステムの構築プロセスに取り組むのですが、ここで注意したいのが「すべてのアクションがデザインシステムの取り組みに反映されるわけではない」ということです。

　例を挙げると、「コミュニケーション効率の向上」の具体策としては「デザインガイドラインやコンポーネントライブラリの構築」もあれば「ミーティング設計の見直し」もあるでしょう。

　前者はデザインシステムに関する取り組みのひとつとして進めることが最適ですが、後者はその取り組み外でも実践可能です。プロジェクトの全行動をデザインシステムに依存させてしまうと、本来はクイックに行えるはずだった取り組みも動き出しが遅くなり、課題解決から遠ざかってしまいます。そのため、デザインシステム構築の一環として取り組むものとそうでないアクションは適切に分類し、実践しましょう。