デザインシステムとアカウンタビリティ

デザインシステムのプロジェクト推進においては、それ自体の設計や運用のノウハウは数多く公開されているが、経営層やマネジメント層へのアカウンタビリティ（説明責任）について解説された記事は少ない。

わたし自身、明確な答えを持ち合わせているわけではないが、これまでの経験を踏まえて、デザインシステムとアカウンタビリティに着目しつつ、プロジェクト推進の鍵となる要素について、考えをまとめてみたいと思う。

目的

デザインシステムをやってみたい、というデザイナーは多い。直近で、デザイナー採用に関わる中でも実感する。一方で、デザインシステムとは何なのかと聞かれれば、その答えは十人十色である。

ある人は、よく利用するUIパーツをまとめたコンポーネントのカタログを思い浮かべ、ある人は自社やプロダクトのデザイン哲学を言語化した、リッツカールトンのクレドのようなものを思い浮かべる。

まずはデザインシステムとは何なのか、認識を合わせなければならない。とはいっても、辞書的な意味を確認したり、原理主義的な主張を展開したところで何の進展もない。ステークホルダーの考え方のギャップを認識することと、その上で何を目的にしてプロジェクトを推進するか、ということである。

スコープ

目的を定めれば、あるべきスコープも導き出しやすい。スコープと聞くと、開発の文脈では「どこまで作るか」の範囲を示すことが多いが、やらないことを言語化しておくのも同じくらい重要だ。なぜなら、後で状況が変わった時に、判断に悩まなくて済むからだ。

往々にして、とある時点では考えられる限りベストな意思決定だったとしても、状況の変化に際して、その前提を疑わざるを得なくなるケースに遭遇する。その際、過去のコンテキストが抜け落ちていると、同じ過ちを繰り返すことになる。

目的から考えよう。何が課題だったのだろうか。「ちゃんとしたデザインシステム」を作りたくて、やりたいことは膨らんでいるかもしれない。しかし、実際はUIコンポーネントのカタログがあれば十分なのかもしれない。最小限のトークン（カラーやタイポグラフィの定義）があるだけで御の字なのかもしれない。あるいは、指針となるデザイン哲学が言語化されていれば、他には何も必要ないのかもしれない。

アカウンタビリティ

前段で、目的・スコープについて記述したのは、その2つが、まさしくアカウンタビリティの設計で重要な要素になるからだ。アカウンタビリティとは、ざっくりと説明責任を指すが、経営の目線でなぜそれを行うべきなのか、ロジックを組み立てておかなければならない。

デザインシステムに限らず、企業で行われる活動のほとんど全てには、コストがかかっている。例えば、正社員1人につき、ざっくりと毎月100万円のコストがかかっているとしよう。デザインシステムのプロジェクト開始に際して、まずはミニマムに週1人日程度の工数を使うとする。毎月の営業日を20日とすると、内訳は20%程度で、毎月20万円のコストが発生する。デザインシステムに関わるメンバーが5人だったとすれば、20万円 × 5人 = 100万円。1年で1200万円を投じることになる。

経営としては、それをやることでペイできるのか、様々なやるべきことがある中で、それをやると選択する意義は何なのかを理解して決断しなければならない。

このあたりがフワッとしたままプロジェクトが進むと、ちょっとした風向きの変化でプロジェクトが中止されたり、簡単に空中分解してしまう。では、どういう方針でアカウンタビリティを組み立てるのかといえば、次の2つの要素が分かりやすいのではないかと考えている。

業務効率化文脈

デザインシステムのプロジェクト立ち上げの背景として、いわゆる技術的負債のような、デザイン負債の影響がよく挙げられる。機能開発において、本来であれば一貫したパターンで対処できそうなところを、UIパーツがバラバラで現場の判断コストが上昇している。

その場合、例えばデザインシステムによって、このくらいの工数が削減できる、というロジックが組み立てられると良さそうだ。そのためには、現状のプロセスを分析し、ネックになっている工程にかかっている時間を割り出すところから始めることになるだろう。定量化すれば、経営判断もしやすくるなる。

しかしながら、業務効率化文脈だけで突破しようとすると、正直厳しい側面がある。なぜなら、デザインシステムの主な受益者が社内のデザイナーだったとすれば、多くの場合デザイナーやデザイン組織は人数の少ないマイノリティであり、仮に工数削減といったところで、たかが知れているからだ。数十万、数百万のインパクトしかないのであれば、新しい施策をガンガンやってよ、という具合である。

よって、インパクトを出すために受益者を増やす方向に持っていったとする。分かりやすいのは、海外のテック企業が公開しているような、UIコンポーネントやトークンを、コードと紐づけた形のデザインシステムであり、目的の設定も、フロントエンドの技術的負債を絡めたものにするのだ。その場合、今度はステークホルダーの増加により、プロジェクト推進自体の難易度が指数関数的に増加していくのは理解しておかなければならないだろう。

もちろん、そもそもデザインシステムをやりたい理由として、発端は開発者体験（Developer Experience）のようなところにあったとしても、突き詰めればエンドユーザーに快適なサービスを提供したいからに他ならない。とはいえ、その定量化には随分と骨が折れることになるだろうし、そうなると、やはり考えやすいのは工数削減という業務効率化文脈となるだろう。

エモーショナル文脈

とはいえ、経営が全てにおいて数字の論理で行われるわけではない。例えば、昨今のIT業界であれば、「ミッション・ビジョン・バリュー」を策定している企業は多い。それらを定義したからといって、短期的に売上に直結するわけではない。しかし、多くの企業が、マネージャー層や経営層を一堂に集めて、少なくない時間（コスト）を投じている。

これらの活動は、いわば数字の論理の枠外にある、会社の色、美意識、個性によって行われるものである。だから、デザインシステムも、そのような例えで提案してみるのも良いだろう。

例えば、社内の行動指針や判断基準を司るものとして、いくつかのバリューを掲げている会社は多い。デザインシステムがないということは、デザインにおいてバリューがない状態であり、この会社にとってふさわしいデザインとは何なのか。どうあるべきなのかを言語化したい。このように熱く訴え掛ければ、ゴーサインをもらえるかもしれない。（やや根性論の様相を呈してきたが）

とはいえ、それで好意的な反応をもらえたとして「来月からまるまる3年間、デザインシステムに時間を使わせてください」と言えば、「ちょっと待ってくれ」ということになるだろう。その塩梅の決め方こそ、アカウンタビリティによって左右される点であり、前述したような定量的なアプローチは大いに役立てることができるだろう。

おわりに

まとめると、業務効率化文脈と、エモーショナル文脈、両方のバランスを踏まえたアカウンタビリティの設計が重要、ということになる。こう書くと、最後には結局「ロマンとそろばん」という一般論に回帰したような感覚も否めないが、案外そんなものなのだろう。

デザインシステムに限らず、どんな企業活動においても、そこで当たり前とされていることを除けば、新しい取り組みには確実にアカウンタビリティが求められるのだから。