「デザインシステムのよくある悩み」に遭遇しなかった SmartHR Design System の2年間の実践
これは、SmartHR AdventCalendar2022の21日目の記事です。
ご無沙汰しています。SmartHR プロダクトデザイナーの @versionfive です。
ここ1年ほどは、SmartHR基本機能のとある機能のリニューアル開発に携わっていて、楽しく仕事をしています。
2020年11月にSmartHRのプロダクトのデザインシステムの公開をはじめて、立ち上げの経緯や “デザインシステムは、「ユーザー」と「目的」からはじめることが大事だよ“という趣旨の連載をしたのが2021年4月。公開して2年以上、前回の振り返りからも1年半以上も経ってしまいました。
詳細は以下の記事で紹介しています。お手頃価格な電子書籍版もあります。（宣伝）
今回は、SmartHRのプロダクトのデザインシステムのこれまでを年表で紹介しつつ、公開して2年ほど運用して分かったデザインシステムに関する気づきを書いてみたいと思います。
※SmartHRのデザインシステムは、「SmartHR（全体）のデザインシステム」をブランドとプロダクトのどちらもカバーするものにしていくため、プロダクトデザイナーだけでなくコミュニケーションデザイナーも携わっています。本記事ではプロダクトに絞って書きます。
SmartHR Design Systemの目的
社内のプロダクトサイド向けオンボーディングドキュメントで、デザインシステムの目的を以下のように説明しています。このドキュメントも公開後すぐに生まれて都度更新していますが、ここの説明は変わっていません。
プロダクトのデザインシステムの取り組みの目的には、2つの観点があります。
1. 汎用性のあるデザインノウハウなどをまとめた、包括的な「デザインの共通言語」をつくり、以下のブレを低減・向上させることで、プロダクトの「品質」と「生産性」に貢献する。
・プロダクトをデザインする人のアウトプットの速度や品質
・プロダクト開発の生産性やプロダクトの品質
・（デザイナー以外も含めた）プロダクトに関わるすべての人が、デザインしやすくなる。
・ユーザーの体験品質（プロダクト利用時の一時的UXが主な対象）
2. SmartHR 社の急成長による以下のさまざまな複雑化に対応するための仕組みを作る。（予備対応）
・利用企業増による業態や規模の増加（ユースケースの増加）
・導入に関わるお客さまの増加（ユーザーの増加）
・SmartHR側のプロダクトに関わる人の増加（社内ステークホルダーの増加）
・プロダクトデザイングループのメンバーの増加（新規参入者の増加）
・プロダクトの機能や連携アプリの増加
携わるメンバーもコンテンツも増えた現在でも、根っこで共通している部分だと個人的には思っています。
目的の対象は「プロダクト（開発）」であり、プロダクトデザインをデザイナーだけのものにしない、「プロダクトに関わるすべての人への仕組み」を意識して作っています。
年表
社内オンボーディングドキュメントに載せているものをほぼ転記しちゃいます。（大盛りでごめんなさい）
2020.05
・コミュニケーションデザイングループ（コムデ）でやっていた「ブランドデザインガイドライン」と、プロダクトデザイングループ（プロデザ）でやろうとしていた「プロダクトのデザインガイドライン」を合わせてデザインガイドライン「SmartHR Design」をつくっていくことに
・関係者でワークショップをしながら、デザインガイドラインの目的やアリ/ナシなどを目線合わせ
2020.06
・コムデ中心に検討した「パーソナリティ」とプロダクトの関係をワークショプで整理
・SmartHR Designを公開開始。まずはブランド文脈、プロダクト文脈に共通する基本要素から（オープン社内報）
2020.07
・プロダクトのデザインシステムのコンテンツづくりを開始
・コアとなる「デザイン原則」をつくる検討会が発足
2020.09
・ホスティングするツールをFrontifyからzeroheightにお引越し
・「デザインシステム」として表記していくことに（オープン社内報）
2020.11
・デザイン原則とともにプロダクトの項目がリリース（オープン社内報）
2020.12
・約半年間のプロジェクトの振り返り会を実施
2021.01
・（振り返りのTryとして）名称をより明確に「SmartHR Design System」に見直し
・Google Analyticsを導入
2021.03
・より自分たちの体制や運用にあった環境にすべく、zeroheightから自前の管理ツールに移行
・プロダクトの色を基本要素のカラーセットにあわせて刷新
・textlint-rule-preset-smarthrを公開開始
2021.04
・CreatorZineでのプロデザの連載で「 「ユーザー」と「目的」からはじめる業務アプリのデザインシステム」を公開 @versionfive
2021.05
・SmartHR UIのFigmaライブラリを公開開始
2021.06
・管理ツールに新スタイルを反映
・デザインパターンの読み方やページテンプレートが誕生
2021.08
・コンポーネントのページテンプレートが誕生
・全てのコンポーネントのページを公開。まずはProps Tableのリファレンスとして
2021.09
・ウェブアクセシビリティ簡易チェックリストを公開
・社内で運用されていた文言ガイドラインがベースになった、ライティングガイドラインを公開開始（オープン社内報）
2022.01
・管理ツールのスタイル・意匠・構造をアップデート（オープン社内報）
・デザインシステムの運用（主に管理ツール面）をPixelGridさんに協力いただく体制に
2022.03
・クローズド勉強会Design Study Morningで「社員にとってのSmartHR Design System」を登壇発表 @aguringo （note）
・コンポーネントの各ページに、実装例（SmartHR UIのStorybook）の掲載を開始
2022.04
・GitHubの作業レポジトリをPublicに
2022.05
・「アクセシビリティ」セクションがプロダクトの中から全体に移動
・「ライティングガイド」セクションを「コンテンツ」に見直し
2022.06
・ユーザビリティテストに関するドキュメントを公開開始
2022.08
・デザインパターンに実装例（SmartHR Patterns）の掲載を開始
2022.11
・Schema by Figma 2022 Tokyoで「“デザイン”のためじゃないデザインシステム」を登壇発表 @wentz_design （Youtube、note）
結構いろいろありましたね〜
立ち上げ当初は、コムデとプロデザの一部のメンバーが中心でした。
今では、UXライターが中心にライティングに関するドキュメントがどんどん公開されたり、UXリサーチャーが中心にユーザービリティテストに関するドキュメントの公開もはじまり、プロダクトデザイン以外の職能からもコミットが増えています。
こんなSmartHR Design System（のプロダクト部分）を運用して2年間、デザインシステムを運用している企業と情報交換も増え、お話する中で気づいたことを書いていきます。
デザインシステムに影響する要素
デザインシステムは、それを運用する組織の体制や構造に強く影響を受けます。いわゆるコンウェイの法則で、デザインシステムに関わったことがある人は「当たり前でしょ」と感じると思います。
情報交換を通して、デザインシステムの構成や位置づけは、それを運用する組織に強く紐づいていることを実感しています。
SmartHR Design Systemも、カテゴリに対して組織にならう形で構成されています。
「プロダクト」カテゴリ
・プロダクトデザイングループ（UXリサーチャー含む）
・UXライティンググループ
・プロダクトエンジニアグループ
「アクセシビリティ」カテゴリ
・プログレッシブデザイングループ
「基本要素」「コミュニケーション」カテゴリ
・（主に）コミュニケーションデザイングループ
デザインシステムの立ち上げ時は、課題意識や感度が高いデザイン組織が中心となることが多いため、デザインシステムをはじめたデザイン組織の体制や組織上の役割が、そのデザインシステムにも投影されているな、と感じます。
デザインシステムのよくある悩み
情報交換する中で、以下のような悩みがあるけどSmartHRはどう？という話をすることがよくあります。
「ひとまずコンポーネントのバリエーションをまとめたが、プロダクトがバラバラで適用範囲を広げられない」
「コンポーネントをまとめるだけになってしまい、使い方を書くまで手が回らない」
「作ったデザインシステムが浸透しない（エンジニアに使われていない）」
「デザインシステムにどこまで投資すれば（作り込めば）よいのか」
「開発組織からデザインシステムの投資効果を問われている」
深くお話をしていくと、悩みの背景には、デザインシステムを運用している（デザイン）組織の体制や組織上の課題が関連していることが多かったのです。
デザインシステムに関するよくある悩みは、デザインシステムの運用する組織の課題（の裏返し）と言い換えることができるのではないでしょうか。
そして実は、SmartHRでは、これらのよくある悩みを感じることがほとんどありません（今のところ）。2年の運用を経て、その理由がなんとなくわかってきたのでご紹介します。
SmartHR Design System がよくある悩みに遭遇しなかった理由
それは、「プロダクト開発のため（だけ）にデザインシステムを運用していたから」だと考えています。
先述したとおり、SmartHR Design Systemの第一の目的は、プロダクトの「品質」と「生産性」に貢献することです。
この背景には、プロダクトデザイングループが、SmartHR 製品のインターフェース品質と、円滑な開発活動のサポートに責任をもつ組織であることが影響しています。デザインシステムプロジェクトも「もっとプロダクトを作っていく仕組み」の一つとして企画されました。
この前提においては、以下のような実践が生まれます。
開発チームに所属し、プロダクト開発の中で「全体を揃えたほうがよさそうだな」と課題感をもつプロダクトデザイナーやUXライターが、ドキュメント作成をリードする
先にプロダクト開発があり、後に共通化・汎用化したドキュメントが生まれる
プロダクト開発の生産性に関わらないドキュメントは生まれにくい
オーナーや専任担当を置かず、ロードマップも特にない（管理ツールの運用はPixelGridさんに協力いただいています）
結果的に、以下のようなデザインシステムができあがりました。
必要なときに必要なだけの基準を作るので、すべてがWork In Progressで最低限の穴あきドキュメントが公開される
Figmaなどのデザインツールベースではなく、SmartHR UIのコードを埋め込むのに相性がよいツール（GitHubのPull Requestベースの更新、メンバーが慣れ親しんでいるMarkdownでの記述）を自前で作る
「ルール」ではなく、開発の生産性を上げるための「ガイドライン（補助線）」だよ、と都度強調して共有される
課題感を持った人が参加しやすいように、テンプレートや運用ドキュメントが充実する
必要以上に整理されたバリエーションや、すぐには使わない基準はつくられない（つくる体制がない）
具体的な実践例は、Schema by Figma 2022 Tokyoで @wentz_design さんが登壇した「“デザイン”のためじゃないデザインシステム」で詳しく読むことができます。
SmartHR Design Systemはプロダクト開発につながる活動以外をほぼやっていません。デザインシステムを更新することは、実績がある整理された基準が生まれることであり、プロダクトの品質や生産性を上げる活動にそのままつながっています。
ここがSmartHRではよくある悩みを感じない理由だと考えています。
SmartHR Design Systemの今後
近年、デザインシステムが「DesignOps（デザイン業務の運用改善）」の文脈で紹介されることがありますが、SmartHRではデザインの業務改善というよりも、プロダクト開発に必要なこと（だけ）をアウトプットしながら、2年間運用してきました。
今後もしばらくは、オーナーもロードマップもなく、プロダクトの品質と生産性を上げるためにデザインシステムを作り続けていくことになりそうです。
採用情報
SmartHRのプロダクトデザイングループでは、プロダクトとデザインシステムをともに作り上げていく仲間を募集しています！
この記事が気に入ったらサポートをしてみませんか？