この記事は「Githubがデザインシステムを作るまでの道のり（前編）」の続きです。
GithubのプロダクトデザイナーおよびデザインシステムのリーダーのDiana Mounter氏
デザインシステムはデザイナーのためだけではない
― デザインシステムチームにエンジニアのバックグラウンドがあることは業務において有利だと思いますか？
それは絶対です。デザインシステムの作成に役立てられますので。実際に作成することができれば、成功の可能性と実用性がより高くなるでしょう。エンジニアとの関係構築には真剣に取り組む必要があるでしょう。彼らに「これを作ってくれませんか？」とお願いし、すべてのものをきちんと完成させたと言えるためにです。これはあり得ないと言うわけではありませんが、自分自身で作成をすることができれば、それはとても力強いことでしょう。
またそうすれば、これがエンジニアにとって何を意味するかをより良く理解することができると思います。デザインシステムの作成は、デザイナーだけのためではありません。フロントエンドで作業するすべての人のためのものです。この種のスキルが実際になければ、どのようにアプローチをすべきか絶対に分からなかったと思います。
― クリエイティビティの余地を残しつつ、一貫性を持たせたデザインシステムを作るのは大変ですか？
ひとりで作成しているのでなければ、他の人と常に協力することになります。そうすると、いくらかの妥協が必要になるでしょう。デザインシステムのチームにとっては、同僚が第１のユーザーであり、彼らのためにすることが顧客の利益にもなります。
またデザインをしていると、他の人に共感をしたり彼らのニーズを考慮したりすることもあります。つまり、デザイナーが好むようなやり方で作業をすると、エンジニアには負担になるかもしれない点を理解することは大事です。なのでそのことについて話し合ったり、どちらにも有効なやり方を見つけたりすることが必要です。
このことがクリエイティビティを損なうとは、私は思いません。些細な日常の意思決定をしなくて良くなる代わりに、より大きな問題を考える余裕が生まれます。たとえばEdwin氏は、「ボタンに使うべきカラー」というのをいつも活用します。新しい機能をデザインしているときは、考慮すべきたくさんの問題が生じます。そのときどのようにCSSを書くかを考える負担を、デザイナーらに負わせたくないと私は思っています。
― デザイナーとエンジニア両方の利益のためには、妥協が必要なときもあると言ったのはとても興味深いです。たとえばどのような例があるのでしょうか？
許容できる範囲の妥協なのですが、たとえば単一目的のクラスやユーティリティクラスで解決できる問題が生じた場合、往々にしてマークアップ側に負荷がかかります。そのようなケースが続き、効率の悪いマークアップが続くと、エンジニアとしては不満が募ります。また、一貫性が損なわれることにも繋がります。
一般的にはReactなど使用して、CSSとJavaScriptで構成されたコンポーネントを切り出したりします。現在私たちのスタックには、そういうものはありません。私たちはコンポーネントとして切り出す方法を把握してはいるものの、ユーティリティのクラスを何度も繰り返し使うよりも、敢えてCSSコンポーネントをグループとしてまとめる方法を取ることもあるのです。
それが私にとっての妥協ですが、現在の状況では極めて理にかなった方法です。でももしこれが個人的なプロジェクトだったならば、そうはしないかもしれませんし、私の意見にみんなを同意させようととにかく説得するかもしれません。
チーム作業をする上で私が好きなことの１つが、みんなが喜ぶ決定を行い、みんなが望むことをしていると思うときですし、妥協とは、必ずしもマイナスではありませんよ。
― Githubは、デザインシステムと共に進化していますか？ それともデザインシステムがあったことによって進化しましたか？
私たちは今、その進化の段階へと進み始めたと思います。
正直に言って、ベースとなるデザインシステムが作られるまで、私たちにはすべきことがたくさんありました。現在私たちはどのようにデザインシステムをまとめて、Primerからどうプルしていくべきかを考えています。現時点ではデザインシステムに関連するすべてがGithub上で管理されており、変更があればすぐさまリポジトリにプッシュできるようになっています。
ですが、それもいずれ変更したいと思っています。エンジニアリングの面でサポートをしてくれるWebシステムチームと話し合いながら、ほかのチームにとっても便利なソリューションを考えています。いまは実行をし始めたところなので、まだ大きな変化は起きていません。
デザインシステムへの評価
― デザインシステムの成功は、どのような指標で判定しますか？
私たちが今まさに真剣に取り組もうとしていることです。私たちは指標を見て、なにを成功の指標とするべきか話し合ってきました。私たちはGithub.comだけでなく、カンファレンス用サイトや開発者向けサイトなどたくさんの外部サイトを持っています。そして、まだすべてのサイトでデザインシステムが活用されているわけではありません。
なので成功の指標の１つとして挙げられるのは、すべてのサイトがデザインシステムを持つことです。それだけでなく、そのデザインシステムを最新のものに維持する作業をより簡単に行うこともです。そのため、私たちはそれらをパッケージ化したものをどのように配布すべきかを考えているところです。これこそが指標です。
そのため、私たちのコードベースで、デザインシステムをがどのくらい利用されているかという観点から統計を見てきました。たとえば、コードベースの何パーセントが新しいカラーシステムを使っているのかといったことを、それぞれのプロジェクトで調べていました。成功したかどうかを可視化することは本当に重要だと思います。
しかし、見るべきなのは、デザインシステムを利用しているサイト数だけではありません。目的に沿った形でデザインシステムを活用することが大事です。上書きされたコンポーネントや、１回しか使われなかったコンポーネントもあります。なのでこれらの指標を、私は追跡しようと思っています。まさに今、私たちが取り掛かっていることです。
― デザインシステムは、アップデートの効率化や一貫性の改善につながっていますか？
ええ、昨年たくさんの新しい機能が導入されましたが、デザインシステムはとても役立っています。何かを作り直す際に、より簡単に新しいシステムを使えています。またデザイナーやエンジニアからの評判も上々で、開発スピードが上がったと言われています。デザイナーがいないプロジェクトもありました。
またある２人のエンジニアは、新しいデザインシステムを使うことで、デザイナーがボトルネックにならず、プロジェクトが早く進んだそうです。これはとても良いことです。
― つまりデザインシステムがなければ、開発プロセスにおいてデザインがボトルネックになるのですか？
面白い質問ですね。必要な人数のデザイナーがいる企業はそう多くないでしょう。私達の場合、エンジニアが最初に何かを作り始めた時にデザインプロセスがあったかと言われると、なかったかと思います。プロダクト思考やデザインに対する意識はあったかと思いますが、それを明確に定義する人間がいなかっただけです。
ですので、正直言って質問に対する答えになっているかは分かりません。デザイン思考はどこかで必要になるとは思いますが、必ずしもそれがデザイナーによるものである必要はないと思います。
エンジニアやプロダクトマネージャーも、ちゃんとした決定を行うことができます。シンプルなデザインの決定ならば、ドキュメント化さえされていれば、デザイナーがいなくてもどうにかなります。しかし、大きなデザインに関する決定が必要なときなどでは、デザイナーからのアシストが必要でしょう。
デザインシステムチームの役割と優先順位
― Githubでのデザインシステムの作業すべてを振り返って、何か特別に行ったことはありますか？
あります。私たちには社内からさまざまな依頼がきていたので、最初のころは一度に集中して取り掛かれることは１つか２つの部分でした。そのため、すべてをやろうとはしないようにしました。常に忙しかったですね。ここをやろう、次はここ、そして他のところを、という感じでしたから。自分たちがやっていることが明確ではなかったので、チームへの評価といった面でも苦労しました。
なので、優先順位を明確にして、時間を無駄にしないようにして、チームへの評価を守るようにしました。もちろん、どのプロジェクトも重要ですが、１度に行うプロジェクトを絞って集中し、もっと良い仕事をすることができると思います。
多分これは、私が学んだもっとも大変な教訓の１つです。とてもシンプルで、今となっては当たり前のことですが、それを理解して優先順位をより良い形で計画するには時間がかかりました。始めるときは、すべて重要なことに思えたのです。
― あれこれと手を付けるのではなくて、絞ったタスクだけに集中しているのですか？
はい、できるだけそうしてます。常に質問やヘルプの要望が来るのがこの仕事の性質だと思っています。デザインシステムは成熟しつつ、まだやるべき仕事はたくさんあります。リファクタリング作業もたくさんあります。なので私たちは、１度に行うプロジェクトは数個のものに集中することにしています。
私たちはFirst ResponderのスケジュールとCSSのバグローテーションの活用を試みているところです。そうして、頻繁に寄せられるより小さなリクエストに対処しようと思っています。その方がより集中することができますし、より頻繁に成果物を出せるとも感じています。
― チームではどのように優先順位を付けていますか？ チーム全体で行いますか、それとも自主的に行っていますか？
プロジェクトやタスクの規模に寄ると思います。小さなタスクなら、それぞれが優先順位を決めます。不確かなタスクであれば、私やほかの誰かに回ってきますので、それを素早くチェックします。
また広く議論する必要があると思うことがあれば、そのためのスケジュールを組みます。より大きな提案であれば、Web制作チームのマネージャーやデザインヘッドに相談します。彼らは２人ともプロジェクトを見ることができる人物です。また私が協調すべき人物なのに、私がそれに気づいていない場合は、私にアドバイスをくれます。
― デザインシステムを作ろうとしている人に対して、何かアドバイスを頂けますか。
すべてを一番最初からドキュメント化していくことが大事です。
ドキュメント化するに当たって、美しい見栄えにする心配はありませんが、とにかく最初から残すことが大事です。何度も言った通り、１度に集中するのは数個のものだけにしてください。これが私からのアドバイスです。そして人々の体験の中で、どの課題がもっとも大きいかを理解しましょう。
チームのほかの人のためにデザインシステムを作るのであれば、自分の味方となってくれる人を見つけましょう。デザインシステムが拡大していくにつれ、その人たちがあなたの支持者となってくれるでしょう。
