書籍では読めないデザインシステム制作現場のリアルな課題と解決アイデア

会社の枠組みを超えた有志を募って開催している、全5回に渡るデザインシステム雑談会。第二回はKOEL（NTTコミュニケーションズ）、リンクアンドモチベーション、マネーフォワード、インクリメンツ、ピクスタ、エキサイト、クラウドワークス、ベイジといった企業のデザイナー陣が集いました。

第一回は初回ということでテーマは設けませんでしたが、今回は「デザイン編」という形で、主にデザイナーの視点に寄せたテーマにしてみました。しかし結果的に話は良い意味で全方位に広がりました。

第一回にも共通して言えますが、デザインシステムについて語りだすと、構築時～運用時という時間軸と、制作に関わるチーム作り、という2つの枠組みに話が広がる傾向がありました。第二回のレポートとしてはこの枠組みに沿って、当日議論した内容をご紹介したいと思います。

1. 構築時の課題

1-1. 初期構築は結局どこまでを目標にすれば良いの？

デザインシステムを始める時は、誰もが手探りです。ネット上で見かける有名企業の完成度の高いデザインシステムを目の前にして、自分はどこから手を付けて良いのか、粒度はどうすべきか、何を基準に要素の不必要を判断するのかに迷う人がほとんどで、スコープ決めの難しさをよく耳にします。

私も漏れなく同じで、参加者に「UIモジュールのリストは何を基準に網羅していますか?」という質問を投げたくらいです。これはおそらく、今ネット上で見かけるデザインシステムの完成度が高く、そのレベルを満たしていなければデザインシステムと呼べない、と考えているからのように思います。

しかし、デザインシステムを外向けに公開している企業の思惑としてはブランディングも含まれているはずです。品質の高いデザインシステムは精度や網羅性もあり、一見すると完璧に見えます。それを見れば、憧れをもつデザイナーやエンジニアを囲い込むことができます。

業務効率化の枠組みを超えて、ブランドや採用にも寄与するデザインシステムを作るのは理想的です。しかし、雑談会に参加したメンバーの話を聞いていると、このハイレベルなデザインシステムを最初から求めるのは目的がかなり飛躍しすぎているように感じました。

第一回、第二回の雑談会で共通して「ミニマムスタート」という言葉がありました。先進企業のように完璧なデザインシステムを最初から作ることを目標に置くのではなく、あくまでも目の前のプロダクト、アプリ、サービス作りの生産性を上げる最短距離は何か？に視点を合わせる、ということです。

目的達成の方法は自由で、大手企業のデザインシステムをとりあえず真似るも良し、HTMLで定義される最低限の要素を定義する方法もよし、作った画面の中の要素で最小公倍数となる要素をとりあえずFigmaやXDにまとめるもよし、正解は無いものだと思います。

デザインシステムは、生産性にもブランディングにも寄与する完璧な存在、と捉える人も居ると思います。しかしまず現場で働くデザイナーやエンジニアが目指すべきなのは、ぎこちなくても不格好でも、昨日より一歩生産性が上がったよね、と言い合える「工夫の結晶」なのではないでしょうか。

初期構築範囲に悩んだ時の解決アイデア
・壮大な物を作ろうとせずとにかくミニマムスタートを心掛ける
・とりあえず大手企業のデザインシステムを真似るところから始める
・HTMLで定義される最低限の要素を定義する

1-2. 複数サービス共通で使える大規模デザインシステムを作る際の留意点

複数のサービスを持つ企業で「すべてのサービスの体験に一貫性を持たせたい」といった要望が持ち上がることがあります。一つのサービスでデザインシステムを作るのでさえもなかなか難しい中、複数サービスを横断したユーザビリティやブランドの統一を図るのは、なかなか難しい問題です。

しかも会社によっては内部制作の体制がなく、サービスごとに別々の外部パートナーに制作を依頼している、というケースもあります。こうしたケースではさらにデザインシステム作りの難易度は上がります。

簡単ではありませんが、何から始める？と考えると、やはり基本は「ミニマムスタート」という考え方に立ち戻ります。まずは1サービスで最低限のデザインルールを整備し、運用する中で必要・不必要の判断基準や運用のルールを作り、ある程度まとまった時点で他サービスに展開する方法です。

一つのヒントとして、参加者からMVP（Minimum Viable Product）というキーワードが挙がりました。MVPは「必要最小限の機能のみを持つもっともシンプルな製品」と訳され、完璧な製品を開発するために膨大なリソースをかけず、素早くプロダクトを市場に投入する、というものです。

複数サービスを跨ぐような巨大なデザインシステムであっても、一番初めは必要最小限の機能のみを再利用可能な形で整備し、徐々に包括範囲を広めていくのが現実的且つ正しい進め方のように思えました。壮大なものを作るのではなく、等身大の目標設定が大切になる、ということです。

複数サービスをまたぐデザインシステム作りで悩んだ時の解決アイデア
・まず1サービスで最低限のデザインルールを整備する
・1サービスである程度ルールが固まったら他サービスに横展開する

2. 運用時の課題

2-1. 後から運用に関わると全貌が把握できなくて恐い

初期構築に関わったメンバーと、運用時から関わったメンバーとの違いは、全貌を把握できているか？という点です。参加者からは、何か一つのプロパティを変えるのにも「そこかしこに影響が起こったらどうしよう…」「文字色ひとつ変えるのも恐い…」といった意見が挙がりました。

やはり運用に入って関係者が増えるほどに、コンポーネントリストの要素が増えてしまって認識合わせに手間がかかってしまうという問題は、どこの企業でも起こりうる問題のようでした。ここではコンポーネントリストの肥大化を防ぐために、どんな決まりが必要なのか？が焦点となりました。

認識合わせに時間を取ることは当たり前にやるとして、参加者の中からはさらに具体的な行動が挙げられました。例えば、1ヵ月使われていないものはアーカイブ化する、追加すべきでないパターンは何かを言語化しておく、といった手法で、確かにこれらは肥大化を防ぐために有用だと思えました。

加えて、よく使うパーツとそうでないパーツを分けておく、という話もありました。このルールがあれば、初めてデザインシステム運用に関わるメンバーであっても、各要素の重要度や再利用頻度が理解できそうです。こうした小さな工夫で、全貌理解を促すことができるのだと感じさせられました。

運用時に起こるチーム内での認識のズレに悩んだ時の解決アイデア
・認識合わせをするための予定を必ず定期的に設定する
・一定期間使われていない要素はアーカイブする
・新たな要素を追加する／しないのルールは言語化して共有する
・利用頻度の高いものと低いものを分けておく
・あったらないいなで新しいルールを作らない

2-2. 全体を見直してメンテナンスする時間がとれない

サービスの各種改善施策を進める中で、新しく生まれた要素のデザインシステムへの反映はどうしても緊急度が下がります。「後で追加しよう」と考えていても、また目の前に新たな作業が割り振られると、どうしても後回しになりがちです。

ここでは、問題をチケット化して改善点を都度見える化する、メンテナンスの時間を定例化する、といった解決アイデアが挙げられました。加えて、運用に時間を割いてでもデザインシステムを整備した方が開発にとってメリットがあることを、関係者に啓蒙することも必要のように感じました。

全体をメンテナンスする時間の取り方で悩んだ時の解決アイデア
・毎日1時間をデザインシステム編集に充てる
・週に一度デザインシステム調整を行う「もくもくタイム」を設ける
・隙間時間にチケットとして必要な対応をストックしておく
・メンテナンスを怠ることのデメリットについて関係者で認識を合わせる

3. チーム作りの課題

先にもお伝えした通り、デザインシステム作りについてはどんなトピックを持ち出しても必ず「チーム作り」の話にたどり着きます。今回の雑談会の中でも多くの時間が、このトピックについて議論する形となりました。

3-1. デザイン原則に対する判断基準の難しさ

デザインシステム作りに関わるメンバーは事業やサービスへの理解度も、デザイナーとしての経験値も、デザインに対する好みも違います。多種多様な考え方が入り乱れる中で、一言「親しみ」というキーワードを投げたとしても、出てくるアウトプットはどうしても異なります。

これらを解消するために必要とされるのが「デザイン原則」になるわけですが、アラ・コルマトヴァの著書「Design System（デジタルプロダクトのためのデザインシステム実践ガイド）」の中にはこのような一節があります。

「シンプル、便利、楽しい」という原則は、皆さんよくご存じでしょう。（中略）便利で楽しいプロダクトにする必要があるとわかっていても、デザインが決めやすくなるわけではありません。これらの特徴は様々に解釈可能だからです。チームやプロダクトにとって、それらの言葉が何を意味するのかを正確に理解することが大切です。

つまり意識合わせのためにはまず実用的で覚えやすいデザイン原則を作ることが大切としつつ、原則をただ作っただけで終わらせず、関係者全員がいつも実践の中で「使えるもの」にするための認識合わせも必要になるということです。雑談会に参加したメンバーの言葉の中にも「言葉はあるが定義がずれる」という話があったのが、この重要性を物語っているように思います。

この問題に対して「『っぽい』で話せるチームは強い」という意見がありました。具体的には、新しく作ったUIパーツをこれまでのパーツ群の中に置いて関係者で眺めた際、違和感があるかないかを意見しあうというものでした。定性的ながら、このような活動が日常的に行われているチームであれば、言葉の解釈のズレも少なくなりそうだと感じました。

また、〇〇はやらない、〇〇はダメ、といったNGルールを固めるのが良いんじゃない？という議論にもなったのですが、その時私が思い出して参加メンバーに語ったのが、NETFLIXの組織作りで大切にされている「コントロールではなくコンテキスト」というエピソードでした。

簡単に説明すると、能力の高い人が集まったチームであれば、細かいルールを沢山決めるより、〇〇な時は〇〇すべきだよね、という認識合わせに時間を使い、現場での細かな判断はその人に委ねるというものです。こうすることで、クリエイティビティを制限してしまうリスクを減らせます。

逆に考えると、チームメンバーの経験値が少ない場合は、コンテキストよりもコントロールを重視したレクチャーに力を入れた方が、デザインシステムの精度は上がるということになります。チームメンバーのスキルセットや特性を見極めながら、適切な啓蒙方法を検討する必要があると言えます。

完成度の高いデザイン原則は明確に言語化されていて、それに沿うことで誰もが間違いない選択ができるというものではなく、言語化された領域以外もきちんと認識合わせを行う活動がセットになるものだと、当日の会話から感じさせられました。

デザイン原則の判断基準の共有で悩んだ時の解決アイデア
・新要素を既存の要素群の中に置き、関係者で違和感が無いかを意見しあう
・経験値が低いメンバー向けに具体的なOK／NG例を作ってストックする
・経験値が高いメンバーは具体例よりも判断基準の言語化に力を入れる

3-2. デザイナー間でのコミュニケーションの難しさ

今回の参加者は主にデザイナーだったため、デザイナー間でのやりとりの難しさについては特に話が盛り上がりました。ツールの習熟度といった基本的な問題から、運用しているデザインシステムにほころびがあった際、そのほころびを察知しているのか？察知しているけど改善しようとしないのか？どっち！？といった意見がありました。

ほころびを認識しているけど改善しない人が増え、それが常態化してしまうとデザインシステムは破綻します。そうならないために地道な工夫が必要になるわけですが、残念ながら雑談会の中ではクリティカルな解決方法は出ませんでした。それだけ解決は難しいということだと思いました。 

デザイナー間でのコミュニケーションで悩んだ時の解決アイデア
・基本的なことながら、都度話をする

3-3. デザイナー対エンジニア間でのコミュニケーションの難しさ

この話題は次回のテーマだったのですが、話の流れで体験談が挙がりました。とある企業の中では昔堅気のエンジニアの方がおられ、その方はチームに逐一状況を共有することが当たり前と考えない方だったそうです。特殊な例ながら、双方の間で目的が共有できていない状態と言えそうです。

ここに対する解決ヒントは「巻き込み」です。デザイナーとエンジニアが日頃から話し合える環境を作ったり、デザイナーが作った物に対してエンジニアからアドバイスを貰ったり、課題感を共有する場を作ったり、といった地道な歩み寄りが大切になるよね、という意見が沢山挙がりました。

雑談会参加メンバーの中で、特に印象に残っている話があります。事業会社に入社して間もなく、上司から現状のwebサービスの酷いルールの不ぞろい箇所を見せられ「これぶっちゃけどう思う？」と問われたそうです。

そこであれこれと改善点を正直に伝えたところ「そうだね、これが起きないようにするのが大切なんだ」と上司から伝えられたそうです。

ある程度経験を重ねたデザイナー、エンジニアであれば、デザインルールの破綻には自然と違和感を覚え、気が付くはずです。その感覚を逆手にとり、デザインルールの負債をあえて見せることで、デザインシステムの精度を上げる重要性を上手く伝えるディレクションであると感じました。

デザイナー対エンジニア間でコミュニケーションに悩んだ時の解決アイデア
・負債の箇所をチームであえて見合わせ、デメリットを共有しあう

4. 参加者の声

当日は参加者の方々から、雑談会に参加して感じたことを素直に言葉にしていただきました。上記のまとめと合わせてお読みいただけると、より理解が深まるかと思います。

デザインシステムの作成の難しさや当時の哲学を失わず運用していくことの難しさが実感できました。また、デザイン「システム」とはいいつつ、画一的にできるものではなく、組織やプロダクトのフェーズ etc...さまざまな要因が複雑に絡み合ってできているのだなあ、とも。デザイナー、エンジニア、はたまたディレクターまで。いろんな人たちと密にコミュニケーションをとって巻き込んでいかないと完成しえない総合チーム戦...ってイメージがすごくしっくりきました。逆に、デザインシステムをうまく構築・運用できるようになると組織力もぐんと上がり、採用にもうまくつながっていきそうかも?みたいなフワッとしたイメージも浮かんできました。(デザインシステムの構築の難しさを知ってる人にしか響かないかもですが...(笑))難しさも理解しつつ、はじめからカンペキを目指さなくてもよさそうだと「初めの一歩」のハードルは下がった気がします。
（web制作会社勤務／女性）

色々とお話を伺う中で、「デザインシステムの構築・運用は、組織づくりなんだなぁ」と強く感じました。意義や目的をすり合わせ、職能や役割を横断して連携を取っていくプロセスは、美しいデザインシステムを構築するだけでは、決して実現し得ないなぁと。「プロダクト同じように、チームもデザインするべき」と最近よく思うのですが、そのエッセンスが凝縮されたのがデザインシステムなのだと感じました。スモールチャレンジで、試行錯誤を繰り返していきたいと思います。
（事業会社勤務／男性）

デザインシステムの共有のしづらさを再確認しました。組織やフェーズに合ったデザインシステムで形が違うのだなと思いました。エンジニア巻き込むのはマスト。デザインシステムも使われることが大事なので、誰に使われるのか？デザイナーなのかエンジニアなのか？デザイナー同士で整理するのデザインシステムと、エンジニアと整理するデザインシステムの領域が違うのでそれぞれの領域があることを理解して整理できると扱いやすそうに思いました。0→1でのビジュアルデザインの話ならデザイナーだし、コンポーネントの運用にあたってはエンジニアだし。結果としては、近道はなくて、関係者と一緒に進めていくのがいいのだと思いました。
（事業会社勤務／男性）

巷では「UIコンポーネントやコードスニペットの集合体」として扱われがちなデザインシステムに関心を寄せて集まった人たちが、組織の在り方や動き方について話している時間が長いのが非常に面白いです。美麗なグラフィックでモダンなコードのデザインシステムを、ある日突然誰かが導入したとしても機能しないんだろうと、2回の雑談会を通して確信を持ちました。人々に多く求められているトピックは以下のようなものではないでしょうか。

1. 混沌とした既存プロダクトに、ごく小さなデザインシステムを導入する手立て
2. 導入した後にデザインシステムを拡張し、プロダクト全体に一貫性を持たせる道のり
3. ある程度浸透した上で、チームのメンバーが変わったり増えたりしても、当初の哲学が立ち消えない風土

そして、世に公開されているデザインシステムは上記の2番までは完遂。場合によっては3番まで取り組んでいる印象があります。2や3まで問題が無い状態は憧れはしますが、あまりにもゴールが遠く見えてしまいます。日本全体のデザインに寄与しようと考えると、かっこ悪い姿を見せないといけないけれど「今はまだ大半がカオス、しかし、何割かだけはデザインシステムが生きている箇所がある」な状態の人たち同士で知見を共有しあうのは効果的かと思います。
（事業会社勤務／男性）

デザインシステムは、進めていくにつれ、着手段階に考えられることに比べてよっぽどやらなければいけないことがどんどん増えていくなあ、と前回からさらに強く感じた気がします。デザイナー以外をどう巻き込むか（組織づくり）、どんなデザイナーが必要か（採用や教育）、運用はどうするか（システムの啓蒙）などなど...。個人的には、既存サービスにおけるデザインシステムの導入〜運用まで、一連の流れでの連載記事は大作になりそうだな、という妄想もあります。また国内サービスのデザインシステムの事例はたしかにそれなりに公開されてはいるものの、どんなものができたか、ではなく、命名の考え方、チーム規模に対するデザインシステムの規模の考え方、困ったときにどうするか、の思考はまだまだ情報が少ない気がしています。みなさんでどんなときにどんなことを考えて意思決定をしたか、も話をしてみたいなと思っています。
（事業会社勤務／女性）

デザインシステムには正解がないこと、皆さんのもやもや、共有&共感できたのは、個人的には気持ちがラクになった会でした。デザインシステム構築にあたって、もう一度デザインの指針になる思想を持って社内の人をポジティブに巻き込んで運用して行くつもりです。まずはできるところから。
（事業会社勤務／女性）

デザインシステムに関して、どんなやり方が正しいのか手探りな状態でしたが、みなさんのお話を伺いながら、正解は自社事業自身の中にしかないのだと確信に変わっていきました。作っていくのも大変なのですが、作ったものをどのように運用・管理していくのか、定義付けしていく事の難しさをひしひしと感じています。デザインシステムがある程度の型が見えたところで、どのように全体を巻き込んでグラデーションしていくか。その為には、POやエンジニア、デザイナー、マーケターなど、プロダクトメンバーとの横の繋がり、組織づくりが基盤にあるのだと思いました。他社さんの事例含めて、デザインシステムに関してゆるゆるとお話する機会をいただけて楽しかったです。
（事業会社勤務／女性）

最後に

第二回目を迎えたデザインシステム雑談会では改めて、デザインシステムというものがただ単に必要となるUI要素をまとめ、デザイナーとエンジニア間で利活用できるフォーマットを作るだけのものではない、ということを更に強く実感しました。

今後も引き続き、「開発編」「デザイン原則編」を開催する中から、私が学んだ「デザインシステムとは何なのか？」を発信していきたいと思います。もし少しでもこの記事を見てご興味持たれた方は、12/18（金）の大忘年会（最大定員50名）にご参加いただいて、意見交換していただけると楽しいかと思います！