DMN Design Management Report #041
デザインシステムのABC
デザインシステムのチームを運営するためのAZガイド
マイク・ディック Mike Dick
SurveyMonkey、Twitch、Quora、
今回は、
The ABCs of Design Systems
The A-Z guide for operating your design systems team
Illustrations by Francisco Morales
Aは採用（Adoption）
人々がデザインシステムをどのように使っているか
（あるいは使っていないか）を測定する。
デザインシステムを採用する必要があるのは、
SurveyMonkeyでは、採用率を測定するために、
- 赤：チームはシステムがあることを知らない。
- オレンジ：チームはシステムのどの部分も採用していない。
- 黄色：チームはロードマップにシステムの採用を優先している。
- グリーン：チームはデザイン言語を使っているが、
コードは使っていない。 - ブルー：チームはデザイン言語とコードの両方を使っている。
健全な採用を促進するために、前もってエンジニア参加させます。
Bはベータ（Beta）
少人数のベータテスターに新しいリリースを
試験的に提供する
コンポーネントに少しでも変更を加えると、
最初の頃は、命名規則が明確ではないことや、
Cは規範（Canon）
システムに新しい要素を加えるときの公式基準
私たちは、
自社の規範を厳密に管理して、トークンやコンポーネントがいつ、
デザインシステムはデザインの問題を解決するが、
それにはエンジニアリングのソリューションを使う。
Dはディストリビューション（Distribution）
変化をどのようにチームに伝え、届けるか
Sketchで素晴らしいシンボルを作成したり、
ガイドラインを書いたり、 エンジニアと協力してすべてをコードで構築するのに何ヶ月もかけ ることができます。しかし、 そのシステムを使っている人たちがどのような体験をしているのか 、考えたことはありますか？ アップデートを受け取るのは簡単ですか？ それは手動ですか？ それとも変更は自動的に同期されますか？ 優れたディストリビューションは、
優れたカプセル化から始まります。 最新のデザインツールのほとんどは、
破壊的なツールを内包しています。しかし、 アップデートの度に手動でダウンロードしなければならないSke tchライブラリを使う必要性を、 Sketchのプラグインはどのように置き換えることができるで しょうか？ エンジニアであれば、ローバリューやHTMLをコピー＆ ペーストする必要性をどのように改善できるでしょうか？ 50行のHTMLを、 1行のコードにカプセル化するにはどうしたらいいでしょうか？ 最近のテックライブラリのほとんどは、 このようなカプセル化の哲学に基づいて構築されています（ Reactやウェブコンポーネントなど）。
Eはエコシステム（Ecosystem）
あなたのデザインシステムを構成するすべての微妙なバランス
熱帯雨林のエコシステムのように、
デザインシステムのそれぞれのパートが重要な役割を担っていて、 すべてがスムーズに機能するためには、 全体が効果的に連携する必要があります。そして、 デザインシステムのエコシステムは、 UIコンポーネントをはるかに超えて広がっています。 私たちのデザインシステムのエコシステムには、 以下の4つのシステムが含まれていると考えています。 健全なシステムを維持するためには、 そのすべてが協調して機能する必要があります。
- ディストリビューション：
リリースとアップデートのコミュニケーションの自動化（ デプロイ、npm、変更ログ、Slack） - ツール化：システムの利用方法を効率化する（
Sketchプラグイン、VScodeプラグイン、 プロトタイピングツールなど） - 教育：システムをうまく使えるように手助けする（ドキュメント、
ガイドライン、オンボードトレーニング） - システム：デザイン言語とUIコンポーネント（これは楽しい！）
熱帯雨林の真ん中にシロクマを放り込むことを想像してみてくださ
い。周りの野生動物は大混乱に陥り、 シロクマも苦しむことになるでしょう。私たちのシステムも、 それと同じように考えています。 大きな文脈の中で意味をなさないものをデザインシステムに導入す ると、システムは徐々に悪化していきます。
Fは永遠（Forever）システムへの追加のたびに、それを維持することが誓いとなる
新しいコンポーネントを出荷して別の作業に移るときは、
お祝いしたい気分になりますよね？ もう振り返りたくないところではありますが、 デザインシステムに機能を追加するたびに、 責任と義務が増えていくことを忘れてはいけません。 気をつけていないと、突然、 コアシステムを維持するので手一杯になってしまって、 システムをさらに成長させるための時間がなくなってしまうかもし れません。 何か新しいものを追加する前には、
長期的なサポートのコストを考えてみてください。 システムがより大きな責任を担うようになったら、 それに応じたスピードでチームを成長させていきましょう。
Gはグルー（接着剤）
他のチームがサイロから抜け出して一緒に仕事をするきっかけにな
る あなたのデザインシステムは、すべての人の中心にあって、
製品体験の全体を包括的に見ることができます。あなたには、 人々が同じような問題に取り組んでいるのを見つけ出し、 その問題を解決するために人々を集めるという強力なアドバンテー ジがあります。そうでなければ、 彼らは顔を上げてその機会に気づくことはなかったかもしれません 。私はこのような機会損失を「シーム（継ぎ目）」 と呼んでいますが、 デザインシステムはシームをつなぎ合わせるための接着剤となりま す。


あなたのデザインシステムは、縫い目をつなぎ合わせるための接着剤です。
Hはヘルプ（Help）
他の人がどのように貢献できるかを明確かつ具体的に示す
デザインシステムは孤立していない方がいいので、
オープンソースモデルのように、 それを使う人からの支援や貢献を受け入れるプロセスを設定するこ とが重要です。しかし、ただの手助けではだめです。 チームが助けを必要としていることと、 必要ないことをはっきり明白にして、 貢献のためのガイドラインを設定します。 私たちのデザインシステムチームは、 膨大な作業を行って明白な基盤を整えるまで、 外部からの貢献を受け入れる準備ができていませんでした。 準備が整ったところで、ロードマップとプロセスを作成し、 効果的な貢献のための方法を明確にしました。
Iはインビジブル（Invisible）
採用者のプロセスをできる限り混乱させない
私たちのデザインシステムの指標のひとつは、
チームのワークフローをできるだけ乱さないことです。 相手に自分のワークフローに合わせてもらうのではなく、 相手のワークフローに合わせることを目指してください。 人によって仕事のやり方は違いますし、 チームの運営方法も異なります。あなたの役割は、 彼らの運命を決めることではありません。むしろ、 彼らがどのように働いているのかを聞き、 それに合わせてシステムを設計し、 彼らのプロセスの中で見えないようにすることがあなたの役割なの です。
Jは仕事（Job）
今日の小さな仕事が、後にフルタイムの仕事になることがある
デザインシステムには、
やるべきことがたくさんあると言っても過言ではありません。 今やっているすべての小さな責任は、 後になってフルタイムの仕事になる可能性があります。 今は小さな仕事でも、システムの規模が大きくなるにつれて、 その範囲も膨らんでいきます。範囲が大きくなると、 システムの運用にショックを与えることになります。 優先順位をつけることは、 オペレーションを回復させるための重要な味方となります。 チームの人数が増えるまで、 どのタスクの優先順位を下げておくかを決めておきましょう。 Kはナレッジ（Knowledge）
集中化で得た知識を文書化して共有する
多くのデザイナーやエンジニアのプロセスの中心にいるということ
は、 文書化されていない豊富な知識を頭の中に蓄えているということで す。知識の管理者でいるのもいいですが、 あたなの頭の中にある知識を文書化することはとても強力で、 組織全体がさらにいい仕事をするための力となります。 非公式な方法で自分の知識を文書化するプロセスを見つけ、
チームが何に価値を見出すかを確認しましょう。そして、 ドキュメントやガイドラインに正式に記載する準備が整うまでそれ をチームで共有してください。
Lはライブ（Live）
デザインファイルは、デザインシステムを静的に表現したもの— 実際のデザインシステムではない
私たちはReactのような最新のテクノロジースタックに移行し
つつあり、変更はエコシステム全体（ドキュメント、 Sketch、コード）で自動的に同期することができます。 理論的には、システム内のすべてのUIコンポーネントが、 どこにでも一緒に存在することを意味します。 まず、
システムの真実の源がコードであることを確認してください。 その生きたコードを、 実例の中ですぐにレンダリングするドキュメントサイトを構築しま す。Sketchのプラグインのようなツールを構築し、 コード化されたコンポーネントを Sketchのシンボルに変換する作業を自動化することで、 チームが手作業で UI キットを描く必要をなくします。これにより、 人為的なミスによる下流でのバグを避けることができます。
Mは測定（Measure）
デザインシステムの効果を測定し、その価値を証明する
初期段階のデザインシステムチームは、
成熟したチームとは異なるものを測定します。 まずは約束したものを提供することに注力するわけです。 それはUIコンポーネントです。この段階では、 UIキットや新しいコンポーネントなど、 チームがどれだけ多くの具体的なものを作り、 提供できたかを測定します。しかし、それが済んだら、 デザインシステムが組織にもたらす影響や価値を測定し始める必要 があります。 この段階での測定基準は、
あなたの会社がすでに重視している測定基準と一致している必要が あります。例えば、私たちのエンジニアリングチームは、「 プルリクエストをクローズするまでの時間」 をすでに測定しています。またこれとは別に、 どのチームがデザインシステムを使っていて、 どのチームが使っていないかを記録しています。 これらのデータをマッピングすると、 デザインシステムを使っているエンジニアリングチームは、 プルリクエストのクローズにかかる時間が短いことがわかります。 これはWin-Winの関係で、 私たちのデザインシステムの価値を証明することができて、 エンジニアリングチームが効率を上げるために私たちのデザインシ ステムを採用するインセンティブにもなります。 デザイン部門やエンジニアリング部門が何を測定しているかを調べ
て、データをセグメントしてみましょう。
Nはニーズ（Need）
あなたのシステムは、ビジネスニーズを解決していないため、
専用のリソースを得ることができない デザインの問題を解決するためにシステムを売り込んでも、
誰も聞いてはくれません（例えば、 色やタイポグラフィの改善など）。たとえ、 それが顧客体験を向上させ、 川下での収益増加につながるとアピールしたとしてもです。 確かにそうかもしれませんが、 通常ビジネスでは優先順位を考えることはありません。 その代わりに、ビジネスが抱えているニーズを特定し、
そのニーズをデザインシステムで解決できることを提案することか ら始めましょう。彼らの関心は、 あなたがそのニーズを解決しようとしていることであって、 必ずしもあなたがデザインシステムを立ち上げてそれを実現しよう としていることではないのです。 SurveyMonkeyでは、
新しいブランドをできるだけ早く製品全体に適用することがビジネ スニーズでした。別の会社では、法務チームが、 サイト全体でアクセシビリティのガイドラインを満たしているかど うかを確かめるというビジネスニーズを持っていましたが、 私たちはデザインシステムでそのニーズを解決することを約束しま した。
ビジネスに必要なニーズを特定し、そのニーズをデザインシステムで解決することを提案する
Oはオンボーディング（Onboading）
デザインシステムを導入の方法について、チームを教育・訓練する
ある日、基盤が安定し、
新たに追加されるコンポーネントの数が急激に減少する時がくるで しょう。そこに採用率の上昇が加わると、 デザインシステムのボトルネックは、 まだパターンが存在しなかったときと状況が変わります。 新たなボトルネックとなるのは、どうやって始めるのか、 どうやってシステムを正しく使うのかという未知の部分です。 この問題を解決するためには、
適切なタイミングでトレーニングに投資する必要があります。 新しいコンポーネントを出荷することがより重要なときには早すぎ ず、 より多くのチームがデザインシステムを採用するための大きな障害 を作るほど遅くてもいけません。
Pは人（People）
顧客はあなたの同僚
初期のデザインシステムは、
プロダクトデザイナーが草の根的に開発したものが多く、 彼らは自然に顧客中心のデザインプロセスを持ち込んでいます。 その結果、デザインシステムチームは、 実際にデザインシステムを使って下流のお客様に製品を提供するデ ザイナー、エンジニア、 PMのためにデザインシステムを構築するのではなく、 顧客のためにデザインシステムを構築するという罠に陥ってしまう のです。 最終的に製品として出荷されるものは、
あなたの責任ではありません。あなたの責任は、 そのシステムを使う人たち、 つまりあなたの同僚の生産性と人間関係を向上させるデザインシス テムを構築し、 彼らが可能な限り迅速に優れた判断ができるようにすることなので す。
Qは取り締まりをやめる（Quit Policing）
会社のライブアプリや製品は、あなたの優先事項ではない
デザインシステムチームは、
製品出荷のゲートキーパーになってはいけません。 顧客に製品を届けるのは、製品デザインチームの責任です。 もしあなたがその一線を越えて、 出荷直前のデザインを取り締まっているとしたら、時すでに遅し。 プロセスの間違った部分に焦点を当てています。 より多くのチームがデザインシステムを使うようになると、 すべてのリリースを監視して、 出荷されるすべてのデザインがシステムを正しく使用しているか、 他のチームが使用しているデザインと一致しているかを確認するこ とは、時間的に困難になります。 その代わりに、積極的な教育やトレーニングに力を注ぎましょう。
彼らが設計や構築を始める前に、 自分たちのリソースを知っておいてもらうのです。 デザインシステムを効果的に使う方法を教育すれば、 彼らは将来のプロジェクトでもっといい判断ができるようになりま す。
Rはリレーションシップ（Relationships）
デザインシステムは専門分野間のギャップを埋める
デザインシステムの能力は、
専門分野の間のギャップを埋めるという点で、 最大の力を発揮します。あなたのデザインシステムは、 デザイナーとエンジニアの1対1のコラボレーションをはるかに超 えたところにあります。それは、 社内のすべてのデザイナーやエンジニアが共通の言語で会話できる ようにすることで、お互いの関係を深める可能性を秘めています。
Sはスケール（Scale）
繰り返し可能なプロセスとガイドラインを設定することで、
チームの能力を拡大する デザインシステムチームは、
会社の他の部分に比べると小さいですが、 会社全体をサポートするという任務を担っています。 計算が合わないのですが、1人のデザインシステムチームが、 100人のシステム利用者をサポートしているのをよく見かけます 。もし、その内の数人からペアコードやデザインを頼まれたら、 チームの1週間分の時間を費やすことになります。 これに対抗するためには、チームの能力をスケールアップして、
人が判断する必要がないようにする必要があります。 正しく行えば、一つのスキルセット（ビジュアルデザインなど） を一人から無制限にスケールアップすることができます。
Tはシステム的な思考（Thinking Systematically）
システム思考はチームのスーパーパワー
従来、製品組織は、製品、エンジニアリング、
デザインの3つの役割で構成されていました。そのため、 この3つの役割で構成されるデザインシステムチームをよく見かけ ます。しかし、デザインシステムチームでは、 どんなエンジニアやデザイナーでも成功するわけではありません。 最大の資産は、問題を体系的に、 全体的なレベルで解決することによって、 周囲の人々の生産性を高めるコツを持ったエンジニアやデザイナー なのです。
Uはディシプリンの統一（Unifying Disciplines）
デザインによるエンジニアリング、
エンジニアリングによるデザイン デザインシステムがすべての中心に位置するとき、
興味深い機会があります。それは「すべてを統一する！」 ことです。デザイン、コード、プロセスなど、 何もかも統一してしまいましょう。 デザインシステムのコミュニティとして、
どのようにして規則を統一し、 より良い仕事ができるようにすることができるでしょうか？ 私たちには、 コードとデザインのプロセスを統一するツールを作ることで、 コードとデザインを融合させるチャンスがあります。 バージョンコントロールを導入することで、 デザイナーをエンジニアのように働かせることができます。また、 デザイナーがコードを書くことなく、 コードでプロトタイプを作成できるプロトタイピング・ サンドボックスを構築することもできます。 デザインシステムの能力は、
専門分野間のギャップを埋めるスーパーパワーです Vはヴィジョン（Vision）
自分のデザインシステムがどうあるべきか、明確なビジョンを持つ
デザインシステムは、デザイン、エンジニアリング、
プロダクトの各分野の橋渡しをするものであるため、 各人がシステムに期待することは異なります。つまり、最初から、 あなたのシステムがすべてであり、 すべての人のためのものだと思われてしまう可能性があるのです。 このような高尚な期待は、非現実的で危険です。 強力なビジョンを確立し、製品組織全体にそれを伝道します。
あなたのシステムが何であるか、そしてさらに重要なのは、 何でないかを説明することです。
Wはラングラー（Wrangler）
「私はPMになったのか？」と悟った瞬間
デザインシステムのクリエイターとして、
あなたはそのシステムを存続させるために必要なことは何でもする ことになります。システムの規模が大きくなってくると、 以前よりもプログラムマネージャーのように行動していることに気 づくかもしれません。日々の仕事は、 現場での作業からオペレーションの管理や調整へと移行していきま す。プロジェクト計画、ロードマップ、タイムライン、 フィードバックの統合......あら、 私はPMになったのだろうか？
Xは「X」
何かを「X 」すること、そして「NO」と言えること
誰もがあなたのシステムの次の大きなアイデアを求めてきます。
彼らは、自分たちの締め切りに間に合わせるために、 ある期日までに新しいコンポーネントを集めて欲しいと依頼してき ます。システムの価値を早期に証明できるため、つい「イエス」 と言ってしまいがちですが、境界線を設けることが大切です。 1つのチームのニーズを解決するために多くの時間を割かないよう に注意してください。全体的な視点に立ち、 単一のチームやプロジェクトだけでなく、 すべての人にメリットのある仕事を優先します。
Yはあなた（You）あなたのデザインシステムにはあなたがいる
あなたのデザインシステムは、あなたが顔を出し、
積極的に草の根活動をすることから始まります。 たとえ自分一人ではできなくても、他の人に「 これはサポートする価値がある」と思わせるためには、 あなたがインスピレーションを与え、導く必要があります。 誰かにデザインシステムの鍵を渡されるのを待つ必要はありません 。あなたの情熱とハードワークが、あなたのシステムを、 勝利のためのデザインシステム専門チームに成長させるのに必要な のです。
Zは動物園（Zoo）
動物園だからこそ、動物園のように感じられる
システムを草の根的に立ち上げ、
小さな種から専用のチームへと成長していく様子を見るのは、 まさに旅のようなものです。 秩序と平穏がすぐそこにあるように感じられるでしょうが、 新たなチャレンジがあちらこちらに待ち受けています。 それでいいんです！カオスを受け入れて、 それが自分をどこへ連れて行くのか見てみましょう。 最高のイノベーションは、たいていはカオスから生まれます。 自分のビジョンを信じて、一歩ずつ前進し、チームをまとめて、 混沌から秩序を生み出しながら進んでいくのです。 ・ ・ ・
この記事は、2019年8月に公開されました。
英文はMediumで閲覧できます。 ●The ABCs of Design Systems / The A-Z guide for operating your design systems team
https://medium.com/curiosity-
by-design/the-abcs-of-design- systems-b1dc6198bb7c （DMN編集部）
https://www.petermerholz.com
http://tinyurl.com/
https://www.youtube.com/watch?
