ニジボックス主催のイベント「BUSINESS & CREATIVE」では、毎回ビジネスとクリエイティブに関する現場発・最前線の情報を発信しています。第20回となる今回のイベントテーマは「失敗から学ぶデザインシステム：成功への道をエンジニアと共に」。実際の『失敗』ケースを紹介しながら、成功への道をどのように模索すれば良いのかを考えます。

オープニング

モデレーターはニジボックスのデベロップメント室長の古川陽介。古川の自己紹介とパネリスト、クリエイティブ室光門の自己紹介からイベントはスタートしました。

デザインシステムとは？

まずは古川より、そもそも「デザインシステム」とは何を意味するものなのかが紹介されました。

「簡単に言うならば、デザインシステムとはルールやガイドラインを一括でまとめた仕組みや決まり事という感じです。デザインや操作性でWebサイトやアプリを提供するための仕組みとして定義されています。例えば画面のコンポーネントごとに伝えるガイドやコンポーネントカタログなどを用意するということも、デザインシステムの一部ですし、それだけでなくデザインの決まりごとやデザインの哲学みたいなものも掲載するということも多いですね」（古川）

デザインシステムを構築するメリットとは？

メリットとしてまず挙げられることは、使いやすいコンポーネントを検討して定義することで再利用しやすくさせて、開発の効率を上げられるということがあるのだとか。また、一貫性のあるデザインになっていることにより、プロダクト全体で見た際のトンマナがそろい、利用者の学習コストを下げることにも寄与してくれるといいます。

「プロダクトの狙いや背景となる哲学をデザインシステムとして定義しておくことにより、デザイナーやエンジニア、プロダクトマネージャーそれぞれが共通認識を作りやすくなり、そこから外れたことが生じにくくなるということもありますね」（古川）

デザインシステムにまつわる失敗談とその原因・対策

ここからは古川と光門とともに、デザインシステムに関連した失敗談とそこから学べることがディスカッションされました。

ケース①：デザインシステムを導入したけれど使われなくなってしまった

「まず、既存システムにデザインシステムを導入したけれど使われていないという問題から参りましょう。これは、あるあるだと思うのですがいかがでしょう？」（古川）

「一生懸命作ってみたものの、忘れ去られて運用されていないということはあるあるですよね（笑）」（光門）

「プロダクトが進化してページの画面構成もどんどん変わり、コンポーネントの呼び出し方なども変わってしまっているのに、デザインシステム上はそのままになっているというのはよくありますよね。よく見たらデザインシステムがちゃんと表示されていないとか……」（古川）

ケース①：その原因・対策とは？

「原因としてはデザインシステムを運用するための学習コストをしっかりと払っていないということがあると思っています。本来は学習コストを払って関係者全員にデザインシステムをしっかり共有したほうがその後の生産性は上がるのに、その学習コスト自体を生産性が低いと判断したりその他の要因で優先順位を下げたりした場合、未来的に運用がまわらなくなると思うんです。このあたりどう思います？」（古川）

「そういう意味では個々のメンバーの当事者意識も大切ですよね。『やれと言われてやってみたけど……』みたいなテンションではなく、ひとり一人が意志をもってデザインシステムだけでなく学習コストへの必要性も感じながら、デザインシステムを運用することができたら結果は違うと思いますね」（光門）

「おっしゃる通りですね。デザインシステムを作った人自身はこれを使って生産性を上げていくのだという思い入れがあると思うのですが、その人が今後もずっとそのポジションにいるわけではないですし、運用を継続させるためにデザインシステムを作った背景や熱量が、5年後10 年後にも伝わっていないといけないですよね。そのためにはそれぞれが当事者意識、いわゆるオーナーシップのようなものを持っていかなければならない」（古川）

「デザインシステムは、ステークホルダーが大きくなっていったときに必要になってくるものですし、そのあたりを意識してから作ることが大切ですね。あとは、作ることが目的になってしまっているケースも失敗につながりやすいと思います。何のために作るのか、目的に立ち返って考えていかないといけない」（光門）

「そうですね。『デザインシステムがあれば生産性が上がる』という思考のもと、デザインシステムに問題をあてはめていくのではなく、問題からスタートしてそれを解決するためにデザインシステムを作る。そして、関係者全員にオーナーシップを醸成させるため学習コストを払うことが理想ですね」（古川）

ケース②：デザインシステムを導入したら運用コストが増えてしまった

「既存サービスのマージンルールやスタイルガイドなどを改めて『こうあるべきだ』と定義してみたものの、実装されているものとデザインシステムに大きな乖離が出てしまい、これを改修するとなると結構コストが掛かってしまうという状況も結構あるあるなのかなと思います」（光門）

「たしかにこういったケースも多々ありそうですね。ルールが変わらないとサービスも良くなっていかないですし」（古川）

「こういう場合、デザインシステム側に柔軟性を持たせる改修をするのか、それとも実装面をデザインシステムに合わせて改修するのか、どちらが良いでしょうね？　ここではそのあたりもディスカッションしたいです」（光門）

ケース②：その原因・対策とは？

「やはりこの原因としては、プロダクトやサービスをリリースすることに優先順位が高く設定されてしまうというところが大きいと思いますね。理想としては、ケース➀で古川さんが言われていた『学習コスト』を最初から検討して進めることが大切だとは思いますが、実態としてはそうでないことが多いと思うんです」（光門）

「そうですね。こういった場合はやはり中長期的な視点で段々と改修を進めていく、というのがいいのではないですか？　既存の法律が改定される際の猶予期間のような考え方に近いですね。そう考えると、新たにデザインシステムを導入する際はその猶予期間中にどのように改修を進めてルールを適用していくのか、ということも検討したほうが良いのかもしれないですね。ルールの中にも強制力の優先度があるような気もしますし。でも、その強制力の調整次第では、ケース➀のように使われなくなるというリスクもあるという（笑）」（古川）

「たしかに、新たなルールが守られないことによってどういったリスクもあるのか、そしてそれを防ぐために何をするのか、というところまでチームですり合わせを行ったほうが良さそうですね」（光門） 「そういう意味ではやはり先程出てきた『オーナーシップ』はとても重要ですね。そして、繰り返しになってしまいますが、本来デザインシステムはプロダクトにあった形で構築する必要があり、そこにはそれに適した学習コストが存在する。だからこそ、世の中に公開されているデザインシステムをまねて作ってしまったり、既存サービスのルールを無視して作ってしまったりすると、実装されているものとの乖離が大きくなり運用コストが多くかかってしまう、という感じですね」（古川）

ケース③：フロントエンドとデザイナーの接続がうまくいかなかった

「我々のところで実際に起きた話です。Tailwind CSSをさらに拡張したUIフレームワークでFlowbiteというものがあるのですが、これをエンジニア発信で技術的なものとして使おうという話がありまして。その後、それを元にしたデザインシステムを作ろうとしたときに、実装を元にデザインシステムを作ろうとしているのでプロダクトとの乖離が結構激しく……」（光門）

「このときはデザインシステムを後から作る際に、Tailwind CSS やFlowbiteの状況がデザイナーにちゃんと共有できていなかったことが問題でしたね」（古川）

「フロントエンドとデザイナーの連携がうまくとれていなかったんですね。これも結構あるあるな感じがしますね」（光門）

ケース③：その原因・対策とは？

「具体的に細かく言うとCSSやUIのフレームワークって、例えば『ボタンといえばこれ』のようなことがもう決まってしまっている部分があるんです。そこがUIフレームワークの良さというか、誰かが定義してくれているものがあるからこそ、それをただ活用するだけで開発が進められるということは良いわけですが、プロダクトのほうの実装したいものを見たら、全然それに合うものじゃなかったという（笑）」（古川）

「なるほど、要件の部分でマッチしていなかったんですね」（光門）

「そうなんです。ですので、ケース➀と②をまとめながら話すと、まずオーナーシップが必要だということ。そして、もうひとつが既存のルールとの乖離をちゃんと見ながらデザインシステムを決めていく必要があるということ。最後にフロントエンドやデザイナー、関わる人同士でちゃんと話し合いながらデザインシステムを作っていく必要があるということですね」（古川）

失敗しないデザインシステムの始め方

ここまでは失敗談を中心に対談が進みましたが、最後にそれを踏まえどのようにデザインシステムを導入していけば良いのかということをテーマにディスカッションが行われました。

ポイント➀：起点はデザイナーの課題。小さく始める

「まず、これからデザインシステムを作る方にオススメしたい本がありまして。SmartHR Design Systemの運営チームが出版した『ちいさくはじめるデザインシステム』がとても参考になるのでぜひ手に取ってみてほしいですね。先程のディスカッションで出てきた『オーナーシップ』という言葉は出てこないものの、この本ではそれに近いことを言っているんですよね。要は『デザインシステムを作る』ことではなく、あくまでも自分たちの生産性を上げることを目的としています」（古川）

「私も読みました。いろんな人がいろんなページをデザインしていて、それが各ページにバラバラに実装されてしまい……、というくだりですね。それを共通化したいという彼ら自身のモチベーションを起点にして、そこから段々とUIガイドを決めてみたり、色味などを統一したり、チーム内の用語集を作ったりと、結果的にデザインシステムを構成していくという流れはとても共感できますよね」（光門）

「私も非常に共感できる部分が多かったな。それらがデザインシステムという形になるかどうかはさておき、デザイナーの作業効率を上げることが目的化されていれば、必然的に同じコンポーネントを作らないようにするルールやトンマナを共通化するルールが生まれていくというのはとても納得感がありました。ときにはおのおのがバラバラに作ったほうが早いこともあるかもしれないですが、そうすると2次、3次実装みたいなものが発生する可能性も高まりますからね」（古川）

ポイント②：他者が作ったデザインシステムをまねしない

「これも先程ちらっと話しましたが、誰かが作ったデザインシステムを『参考』にするのは良いかもしれませんが、『まね』をすることは本質的に違うというのは『オーナーシップ』を醸成するためにも大切なことですよね。小さく始めながら段々と作りあげていくことがブランドフィロソフィーを生成するという意味でも大切なのでは」（古川）

「そうですね。『ちいさくはじめるデザインシステム』の中にも出てきましたが、結果としてプロダクトの中だけに閉じず、営業組織の方々が使う資料のテンプレートなど、ブランド全体に浸透するデザインシステムが作れればなお一層効果的ですよね」（光門）

ポイント③：原則を言語化する

「次に、プロジェクトを進める中で原則が生まれたら、それを全員の共通認識として言語化することも大切ですよね。デザイナー同士で差分が生まれてしまったときはルールや原則を定義するチャンスだと思っていて。そういったところを糸口にしてどんどん課題を解決していきたい」（光門）

「あとはそういった中身のある議論ができる状況を作れる環境づくりも大事ですね。何が言いたいかというと、この本に書いてあることで私が印象的だったのが『まずは志のある少人数で進める』という言葉だったんです。つまり、原則を言語化する際に意見のない人がたくさんいても何も決まらないし、ぼやっとした折衷案が生まれるリスクが生じてしまう。だからこそ、明確なフィロソフィーや考え方を持っている少人数だけでまずはデザインシステムを検討することが重要だと思います」（古川）

ポイント④：デザインシステムの強制力をマネジメントする

「デザインシステムの中にも優先順位があって、みたいな話がケース②でも出てきましたが、デザインシステムの強制力も重要なポイントですね。有名な事例ですが、デジタル庁のデザインシステムの決め方も参考になると思います」（古川）

「過去来さまざまな省庁が独自の背景を持ってデザインを実装してきた中で、どんなユーザーであってもそれらを公的機関のサイトとしてアクセシビリティ高く使用できることを目指した彼らの取り組みは面白いですよね。ポイントは各省庁のオリジナリティーを生かしながらも、共通化したルールに関してはかなりの強制力を持って装着したというところかなと考えます」（光門）

「民間企業でも、複数のプロダクトをヨコ串で見ている組織が作った新しいルールがあったとして、もしそのルールの強制力がなかったら各プロダクトはそれぞれのルールで動いてきたわけなので、『こっちはこっちのルールでやりますので』となってしまいますからね。民間企業ではあれほど大きな規模の仕組みを作る機会はあまりないかもしれないですが、どのルールをどう優先順位をつけて決めていくのかというプロセス自体は民間企業で働いている私たちでも勉強になるのかな」（古川）

ポイント⑤：オーナーシップを広げていく

「今日、何度も言っていますが、やはりデザインシステムを運用する上で最も重要なのはオーナーシップであり、それをどう普及していくのかがポイントなのでしょうね。先程の失敗談の一番大きな要因はこれが欠けてしまっていることだと思うんですよね。ですから、オーナーシップ自体を定義し醸成すること。その上で、ボトムアップで始めて運用上の課題を洗い出すこと。そして最後にオーナーシップを普及させるためにもコミュニケーション、コラボレーションの方法を検討すること。この3つがデザインシステムを作る上での原則となるのでしょうね」（古川）

「3つの原則が見いだせましたね！　オーナーシップを普及させるという点でも『ちいさくはじめるデザインシステム』に参考になるエピソードがありましたよね」（光門）

「『草の根運動』のくだりですね。SmartHR Design SystemではSlackをフル活用して『デザインシステムとは何かをふむふむする会』などのグループを作って意見交換し、何か新しいサービスがリリースされたら皆で積極的に共有してリアクションを取り合って、みたいなエピソードがありましたが、地道な運動ではありますがこういったことはとても大切ですよね。あとは、SmartHR Design Systemの話でいくと、彼らは比較的初期の段階から社外に自社のことを結構発信していて、そのリンクを社内で共有するという方法をとっています。マーケティング戦略のひとつだと思うのですが、社内のみで広めるよりも社外を1回通してから拡散されたものを社内に広めるという手法は面白いですよね。オーナーシップを広げていくためには多くの人を巻き込まなければいけないわけですし」（古川）

まとめ

「今日はありがとうございました。普段はデザイナー組織の中でデザイナー同士で仕事をすることが多いわけですが、今回のようにフロントエンドの方の意見をもらったりコミュニケーションをとったりする場をもっと増やしたら、より良い課題解決方法が出てくるのではないかなと思いました。今後も仕事上でデザインシステムに関わることを多く経験していくと思うのですが、いかにデザイナー以外の方々も含め周囲を巻き込んでいけるかというところを大切にしていきたいですね」（光門）

「実は以前まで私はデザインシステム自体に疑問を感じていたんです。というのは先程の失敗談にもあった通り『導入したけど使われなくなった』『導入したけど運用コストが増えちゃった』というケースをよく見てきたので……。『勝手に細かいルールを作って、自分たちで自分たちの首を絞めちゃっているな』と思っていました。ただ、実際に深く勉強してみると、しっかりとデザインシステムの運用ができれば確実に開発の生産性が上がったり、チーム全体のプロダクトへの理解やブランドへの意識向上が図れたりするものなのだということが分かる。そして、それに気付くためにはデザインシステムを現場で実際に使ってみることが大切であることも同時に気付けましたね。そういう意味ではまずは実践してみて、失敗も経験しながら学ぶことも大切なのかなと思いました」（古川）

「実際に失敗したり、うまくいかないなと思ったりした際に、『なぜそうなったのか？』と自身で考えることが成長するために一番大切なのかもしれないですよね」（光門）

「おっしゃる通りですね。失敗は失敗のまま終えてしまうことが一番の問題ですし、次につながる失敗であれば、結果としては失敗ではないですからね。本日はありがとうございました」（古川）