#69「書籍『デザインシステムの育て方』からの学び 後編」
書籍 『デザインシステムの育て方』のチャプター5～10を読みながら、ミツエーリンクスのコーポレートサイト、採用サイトで取り組んだデザインシステムについての振り返りを交えつつ、デザインシステムの役割や取り組み方などの話をしました。
※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。
加藤: 皆さん、こんにちは！ミツエーリンクスの加藤です！
佐竹: 佐竹です！
加藤: はい、今回もミツエーテックラジオやっていきたいと思います。ミツエーテックラジオは、株式会社ミツエーリンクスのスタッフが、Webデザイン、Webフロントエンドなどの、Web技術に関するニュースやツールをシェアするポッドキャストです。前回のエピソードでは、昨年発売された『デザインシステムの育て方』という書籍について、当社の取り組みを交えつつ、紹介しました。今回はその後編となります！
佐竹: よろしくお願いします！
加藤: よろしくお願いします。前回はチャプター1～4までお話しして、最後に、デザインシステムの取り組みを軌道に乗せるにはどうすればいいか？というところで終わりましたね。
佐竹: そうですね。では、その答えが見つかるのか、チャプター5「パイロットプロジェクトーデザインシステムの着手と維持に最適の方法」から話していきましょう。
加藤: チャプター5では、Webサイトやアプリなどの既存プロジェクトと連動させると、デザインシステムもスムーズに進むと紹介されていました。デザインシステムを作るぞ！と始めるよりも、別のプロジェクトを進めつつ、その中から共通化できそうなコンポーネントを見つけて取り込む、みたいなイメージですね。
佐竹: はい。ニュートンの慣性の法則が例として出されていましたよね。 静止した物体はその後も静止し続ける。動いている物体は動き続ける。だからデザインシステムのイニシアチブを動かしたいなら、すでに動いているシステムとつなげればいいということでした。
加藤: はい。まずは連動しやすいプロジェクトをどう見つけるかですが、書籍では8つの選定基準が紹介されています。
佐竹: えー、いくつか抜粋しますと、そのプロジェクトに他のプロダクトでも使えるコンポーネントやパターンが多く含まれているか、ビジネスに大きな価値をもたらしそうなコンポーネントやパターンがあるか、などがありましたね。
加藤: そうですね。汎用的なコンポーネントが多く含まれているプロジェクトがパイロットに向いているっていうのは、なんとなくイメージしやすいですよね。選定基準ごとに点数をつけていって、平均点が高いプロジェクトから取り組んでいくのがよい、ということでした。あとは、テストしたい観点によって連動の仕方も異なるようで、こちらもいくつかのパターンが紹介されています。
佐竹: あのー、インディアナ・ジョーンズ型というユニークな名前のパターンがありましたよね。
加藤: はい、ありましたね。これはあのー、とある映画の中で、インディアナ・ジョーンズというキャラクターが、罠が作動しないように同じ重さの黄金と砂袋を置き換えるシーンがあるんですけど、それと同じように、見た目のデザインやUXは変えずに、固有のパーツをデザインシステムにあるパーツに置き換えることができるかどうかっていうのを検証するっていう方法ですね。
佐竹: はい。すでに見た目や動きはできているので、これならタイミングがあればいつでも対応することができますね。さらに3種類のパイロットプロジェクトを同時進行して、3つのプロダクトチームと1つのデザインシステムチームの計4チームで動くことで、より汎用的な想定ができて、多すぎない範囲で、幅とバリエーションを確保できるとありました。
加藤: たしかに、複数のプロジェクトを参考にしたほうが、使い勝手の悪いコンポーネントを量産してしまうリスクは避けられますよね。そのほか、このチャプターでは実際に著者が、エクソンモービル社のデザインシステム構築に携わったときの事例などを交えながら、具体的に紹介されていたので、これからデザインシステムに取り組もうとされている方には、とても参考になるのではないかなと思います。
加藤: 続いてチャプター6「ガバナンスと貢献」では、デザインシステムに関する取り組みを誰が、いつ、どのように行うか、そしてプロダクトチームとデザインシステムチームの活動を、どう連動させていくかのヒントが書かれています。
佐竹: はい。フローウィークとシステムウィークを交互に組み込む方法が紹介されていましたね。フローウィークはプロダクトチームが通常通りプロダクト開発を行う週で、システムウィークはフローウィークで作られたコンポーネントをデザインシステムに組み込めるかを判断する週のことをさしています。それを交互に繰り返していくっていうイメージですね。
加藤: 実際のプロジェクトだと、プロダクト開発以外のことってどうしても後回しになりがちなので、システムウィークとしてあらかじめ時間を確保しておく、というのは参考になりますね。
加藤: 続いてチャプター7「役割と職責」では、フロントエンドエンジニアやデザインシステムチーム自体の役割について書かれています。とくにHTMLの重要性についても書かれていて、当社の木達さんも過去に「HTML軽視されすぎ問題」という講演を行っていたんですけど、ちょっとつながった感じがしましたね。フロントエンドエンジニアの呼び名をデザイナーにするのはどうか、っていうくだりは個人的には目からウロコでした。
佐竹: あーそうですねー。デザイナーさんがFigmaやXDなどのデザインツールでデザインを表現するのと同じように、HTMLとCSSでデザインを表現するという見方でしたよね。言われてみればで気づきましたけど、そういう見方もできますよね。
加藤: そうなんですよね。自分自身、肩書きにとらわれているところがあったなぁと思ったので、ちょっと視野が広がったかなと思います。また心理的安全性についても書かれてましたね。デザインシステムの本で心理的安全性が出てくるのは、ちょっと意外だったんですけど。
佐竹: はい。Googleの「ピープルズオペレーション」チームが、優れたチームの特徴を調査したところ、チームの成功を予測する指標として最も頼りになるのが心理的安全性だった、とありました。これは採用サイトのリニューアルでもすごく実感していて、やっぱり新しいことを始めるときに周りから受け入れてもらえるかどうかっていうのは、プロジェクトの進めやすさに影響しますね。
加藤: そうですね。続いてチャプター8「デザインシステムのプロセスとワークフロー」では「ホットポテトプロセス」で進めていくやり方が紹介されています。ホットポテトプロセスって私はこの本で初めて知りましたね。
佐竹: 私もです。ホットポテトプロセスについては著者のBlogに記事があったので、そちらを見てもらうといいと思うんですけど、簡単に言うとデザイナーと開発者でペアプロをするみたいな感じですね。
加藤: はい、そうですね。私が参加するプロジェクトでは、一通りデザインができ上がったら、デザインファイルを受け取って開発に取り組むっていうスタイルが、わりと一般的なんですけど、そういうプロセスだと、デザインファイルを見れば全部わかるように作ってほしいって思っちゃうんですよね。
佐竹: わかります。デザインと一緒にスタイルガイドとかルールもまとめてもらえていると、すごく助かりますよね。
加藤: そうですね。そのやり方だと、デザイナーと開発者のやり取りは少なくて済むかもしれないんですが、一緒に作るってそういうことなんだっけ？って改めて考えさせられましたね。ホットポテトプロセスでは “「こんな感じ」が最高のフレーズ” というのがポイントらしくて、デザイナーさんの隣の席に開発者が座って、デザイナーさんは参考サイトを見ながら「こんな感じにしたい！」って伝えて、開発者はそれを見ながら「こんな感じでどう？」って聞く、みたいな進め方をするみたいです。
佐竹: だから「こんな感じ」が最高のフレーズなんですね。ちなみになんですけど、採用サイトのときがそんな感じでした。席はデザイナーさんと離れてはいたんですけど、制作の早い段階からお互いにプロトタイプを作って、アニメーションの速度とか動きだったり位置なんかを画面共有したり、動画にしたり、デモサイトにアップしたり、といろんな方法で「こんな感じ」っていうのを見せ合っていましたね。
加藤: あーまさにホットポテトですね。今だとノーコードツールとかを使えば、デザインファイルを作らずに直接ページを作れる時代にもなってきているので、いわゆるデザインカンプを作る目的っていうのは今一度見直してみてもいいのかもしれないですね。
加藤: そしてチャプター9「デザインシステムの成功の指標」では、デザインシステムがどれだけ効果を出しているかをどう測るかについて書かれていました。
佐竹: 「効率」と「一貫性」の2つが代表的な指標として挙げられていて、たとえば、効率の面では、作業時間が短くなっているかとか、プロダクトをリリースするスピードが上がっているか、あとはバグが減ったかなどがポイントになります。一貫性のほうだと、開発者目線で考えるなら冗長なCSSが減っているか、みたいなところですね。
加藤: はい。あとはデザインシステムをうまく取り入れていくには「安定派」と「冒険派」の両方に投資するということが必要だとも書かれてます。
佐竹: 安定派はプロセスを大事に、確実に機能するものを作るタイプの人で、冒険派は新しい表現や仕組みにどんどんチャレンジしていくタイプの人ですね。あのー、個人的に一緒に制作するときに、私が安定派よりで加藤さんが冒険派よりかなと思っていて、最終的にちょうどいいのができている気がするので、どちらかに偏りすぎるのではなくって、両方の視点がチームには必要だっていうのは納得感がありますね。
加藤: あー自覚はなかったんですけど、私は冒険派なんですね笑
佐竹: ま、逆転しているときもありますけどね笑
加藤: なるほど笑 えーやっぱりデザインシステムにどういう人が関わるかっていうことも、デザインシステムそれ自体が、安定的になるか、冒険的になるか、っていうところに影響しそうな気もするので、やっぱり多様な視点は必要そうですね。 そして最後、チャプター10「伝道に終わりはない」では、実在するおもちゃ屋さんのレイアウトを例に、魅力的なデザインシステムの在り方について提案されています。具体的には、このデザインシステムで何が作れるのかを伝えるために、プロダクトの実例を最初に示すべきだと書かれています。たしかに、いきなりコンポーネントの一覧を見せるよりも、「このプロダクトがこのデザインシステムで作られています」っていうのを最初に見せたほうが、デザインシステムの価値は伝わりやすいですよね。
佐竹: そうですね。あとは使う人がデザインシステムの使い方をイメージできるということも大事で、コンポーネントはもちろんデザインシステムには欠かせない要素の1つなんですけど、コンポーネントを組み合わせて作れるものがわからないと、デザインシステム自体を活用してもらえなくなってしまうんですね。
加藤: そうですね。そして好事例として、アメリカ宇宙軍のデザインシステムである「Astro」が紹介されています。Astroではプロダクトの実例を示すだけではなく、プロダクトの構成をコンポーネントに分解して示していたり、Gitリポジトリへのリンクも載せていて、このような示し方が最高のデザインシステムだと称賛されていたので、こちらも参考にしたいですね。
加藤: はい。ここまで2回にわたって『デザインシステムの育て方』という書籍の内容をベースに、当社の取り組みや、私たちの気づきなども、交えながらお話してきましたが、佐竹さん今後に活かせそうですか？
佐竹: そうですね。デザインシステムの役割や取り組み方がわかってきたので、できるところからプロジェクトに取り入れていこうと思います！そして、引き続きデザイナーさんや関係者の皆さんと「こんな感じ」って言いながらプロトタイプを見せ合うっていうのは、これからも続けていこうかなと思っています。
加藤: あーいいですね。ホットポテトプロセスは私もぜひやってみたいなと、思いました。最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでチェックしてみてください。 また、このPodcastはApple Podcast、Amazon Music、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、最新のエピソードをすぐ視聴できます！こちらもぜひご活用ください。「#ミツエーテックラジオ」でご意見、ご感想、こんなこと話してほしいというリクエストなどもお待ちしております。 それでは今日はこの辺で！ありがとうございましたー！
佐竹: ありがとうございました！