この記事は弁護士ドットコムAdvent Calendar 2023の20日目の記事です。 昨日は @dskymd さんのOptimistic Updateに触れてみる でした。
はじめに
こんにちは、弁護士ドットコム本部 デザイナーの林です。 去年のアドベントカレンダーはデザイントークンの記事を書いたのですが、今年は弁護士ドットコムのデザインシステムの取り組みを俯瞰した振り返り的なお話をしたいと思います。ノウハウではなく過去からの学びですが、下記のような方々に読んでいただけると良いのかな、と思っております。
- これからデザインシステムを始める方
- デザインシステムを始めたけれど、どこにリソースを集中したらいいのか迷っている方
デザインシステムは捉えにくいもの
デザインシステム‥この言葉をあなたはどう説明しますか？ そもそも、「デザイン」も「システム」も、一義的に固定された意味がなく非常に抽象度の高い言葉です。その二つを組み合わせたデザインシステムという言葉も「わかるようでわからない、正体の無さ」を感じさせる言葉だなぁと思います。
ちなみに、Wikipediaの「システム」の解説を見ると
システムは、相互に影響を及ぼしあう要素から構成される、まとまりや仕組みの全体。一般性の高い概念であるため、文脈に応じて系、体系、制度、方式、機構、組織といった多種の言葉に該当する。 ウィキペディア
このように説明されており、「とても広い概念の言葉なのだ」というざっくりした感想しか抱けません。 したがって、私たちにおけるデザインシステムの理解は、世間に現存する「デザインシステム」と名付けられた対象をみて、「なるほど、デザインシステムとはこういうものなんだな」というところに落ち着きがちです。
この記事ではそのような日常を離れ、普段そのように「なんとなくこういうものである」と理解しているデザインシステムのことをあらためて考え直してみたいと思います。 また、その思考の整理の中にこれまでのデザインシステムへの取り組みを位置付け、私たちのデザインシステムとはどういうものなのかの言語化を試みようと思います。
デザインシステムは戦略か、戦術か
つい先日、Xのタイムラインにふと流れてきたLINEヤフーの川邊健太郎さんのポストにあった「戦略とは状況を作り出すこと。戦術とは状況を利用すること。」という一文をみて、これはまるでデザインシステムにおける目的とリソースのことのようだ、と感じました（とても学びが深いポストなのでぜひ全文拝読することをお勧めします）
【川邊的戦略論、1週間分まとめ】
— 川邊健太郎 (@dennotai) 2023年12月9日
以前にマネジメントについて1週間、集中投稿をしたら大変評判がよかったので、今度は"戦略"について投稿をしていきます。… pic.twitter.com/RHJsChOz9b
戦略と戦術もまた捉え所がむずかしい言葉ですが、「戦略なき戦術」も「戦術なき戦略」もどちらもうまく行かないことは、多くの方がご自身の経験から推察できる部分ではないでしょうか。 私は、デザインシステムもそのように考えていて、目的のないリソースは思ったほど役に立たないし、リソースが投下されない目的は絵に描いた餅だと思っています。どちらもなくてはならないし、セットで考えるべきものだと思います。
しかしながら、前段であげたようにデザインシステムは「なんとなくこういうもの」と考えられがちです。とはいえ、世間にはたくさんの素晴らしいデザインシステムの前例があり、それを参考にするだけでも一定の成果が出るデザインシステムは作れるんだろうと思います。
ですが、デザインシステムを構想し始めた当時の私たちのデザインチームのリソースで、素晴らしいデザインシステムの単なる後追いを狙えば、リソース不足を起こして中途半端なアウトプットを残したうえ、なんのためにデザインシステムを作ったのかよくわからないということになるのは想像に難くないと思われました。
また、当時はデザインシステムに関しての共通理解がまだまだ少なく、関心があるのはデザイナーとフロントエンドエンジニアの一部の界隈で、かく言う自分自身も恥ずかしながら最初は「デザインシステム≒アトミックデザイン？」くらいの解像度しか持ち合わせていませんでした。 そんな状況ですから、デザインシステムのビジネスへのインパクトに至っては限りなく未知数だったのです。
リソースから考えず、目的から考える
リソースにあまり余剰がない以上、何かしらの「工夫」を考えなくてはなりません。「工夫」を捻り出すには、課題認識が必要です。まさに「必要は発明の母」、デザインシステムをぼんやりながらも「進めてみるべき」だと考えていた私たちは、まずは現状把握をしてみることからスタートしました。具体的には開発に関わるチームメンバーを皮切りにインタビューをすることから始めました。
ここで幸いしたのは、社内の中でもドメイン知識が深い人に「ほかに誰に話を聞きに行ったらいいだろうか？」と質問をしたことです。その時に「プロダクトの歴史を知る人」と「事業目線でプロダクトを考えている人」に話を聞きに行くべきだというアドバイスをもらいました。そのアドバイスに従い、当時の事業部長にも話を聞きに行って、プロダクトを取り巻くビジネス環境とプロダクトに求められることを聞いたとき、これを材料にデザインシステムの大きな方針を決めることにしたのです。
状況を動かしたいなら、まずは状況を把握すること
社内の聞き取り調査をしたことも、ビジネスとプロダクトを取り巻く環境を念頭に大きな方針を決めたことも、いま考えればかなりの部分が運に導かれた試行錯誤でした。
もし、当時の私にアドバイスをするのであれば、ビジネス環境のヒアリングをすることはもちろんですが、計画の前にデザインシステムメトリクスを想定することを勧めたいと思います。 指標を使ってどのようにデザインシステムを評価するかを想定しておけば、漸進的な取り組みにおいても少しづつ成果が出せていることをチームに訴求できますし、次の目標設定も考えやすくなります。それに、現状の達成度合いを前提にすれば、どこから取り組みを始めるのがより効果的なのかが考えやすくなります。
デザインシステムはその性質上、どうしても漸進的な取り組みになりがちです。トップダウンで専属のチームを作れるような環境であればいいのかもしれませんが、日々のプロジェクトと同時並行でデザインシステムの構築に取り組む場合、小さくても目にみえる成果を出すことはとても大事です。そしてもっと大事なのは、今の状況を正しく把握することです。
変えたいところはどこか、どこを変えたら効果的かを考える
すぐに役に立ちそうな指標をざっとあげてみました。定量的に測れるもの・定性的な評価が必要なものが混ざっていますし、もっとたくさんの測定要素が考えうると思います。しかし、下記にあげた指標はわかりやすいものなので、デザインシステム導入前後での比較に貢献しやすいと思います。
- チーム効率
- 市場投入までのスピード
- レビュー時間の短縮
- ユーザーインターフェースの設計の一貫性
- ユーザビリティ問題のバックログ
- コード内のバグ修正の頻度
- コード内の技術的負債の量
- アクセシビリティのスコア
- コンポーネントの利用率（コンポーネントの貢献度の可視化）
- チームメンバーが快適に開発しているか
このような指標をもとに現状を捉え、どこから変えると最もインパクトが出せるのかを考えるのです。私たちの場合は、最初はCSS設計をし、コードの再利用性を高めバグを引き起こす頻度を減らしました。また、インターフェースインベントリを行い、デザイン指針を明文化しガイドラインを作成しました。
その次に取り組んだのはデザイントークンです。これにはコンポーネントから表層のデザインだけを剥がすという狙いがあります。いま現在のデザインのコミュニケーションの質を高めること・品質担保をすることと同時に、フロントエンドの方針が変わっていってもトークン自体は新しい実装に適応可能にするためです。
大きく考えて小さく実行する
デザインシステムのような時間を要する取り組みを始めるときに、少し気をつけていることがあります。それは「大きく考えること」、そして「小さく始めること」です。
小さく始めるには何がその取り組みの要諦になるかを見極めなくてはなりませんが、最初から決めうちで小さな枠組みの中で考えると、前提を置き間違える可能性があります。取り組みをしてみて「間違った」と気づいて後戻りするより、最初に少しでも大きく広く考えた方が小さなコストに収まることも多いのです。
とは言っても、無限に大きく考えればそれはそれで最初のコストがかかりすぎてしまいます。ある程度の確信を得たら、実行できるタスクに落としこみ、その結果に学んできめ細かに軌道修正すればいいのです。そう考えれば、肩の力を少し抜いて前に進んでいける気がしませんか？
そのデザインシステムは「誰のためのものか」「何のためのものか」
実践から学ぶとき、役に立ってくれるのは当初に描いた「目的」と「指標」です。目的に照らして、達成度合いを測れば、取り組みが確実に前に進んでいることをチームみんなで共有できます。 デザインシステムには多くの時間がかかり、多くの人との関わりが生じます。「目的」はみんなで同じ方向を目指すうえで欠かせないものです。 目的を設定するのは容易ではありませんが、そのデザインシステムは「誰のためのものか」「何のためのものか」ということを考えて、現実と真摯に向き合うことが結局は一番大事なのだと思います。
最後に、一体どちらに進むのかもわからないうちからインタビューに応じてくれた同僚たちに感謝の意を述べてこの記事を締めくくりたいと思います。同僚たちのおかげで私たちのデザインシステムはビジネスとプロダクトを前提とした目的を据えることができました。 そしてまた明日からも、新たな学びを言語化できるように日々の歩みを進めていきたいと思います。
最後までお読みいただき、ありがとうございました。弁護士ドットコム Advent Calendar 2023 の明日の担当は @et_tei さんの「FireHOLで公開されているブラックリストからの接続を Akamai でブロックする」です。
