Githubがデザインシステムを作るまでの道のり（前編）

Diana Mounter氏はGithubのプロダクトデザイナーおよびデザインシステムのリーダーです。

デザインと開発において15年近いキャリアをもつ彼女は、Etsyでシニアデザイナーを務めた後、2015年末にGithubのチームに参加しました。

私たちはこのインタビューで彼女に、デザインシステムにおけるベストプラクティスと、デザインシステムの作成・保守の経験から学んだ教訓について聞きました。このインタビューは、動画で見ることもできます。

また、デザインシステムの利点やプロセスについてもっと知りたければ、無料のeブック『Why Build a Design System？』をダウンロードしてください。

Githubのデザインシステムチーム

― デザインシステムチームに加わった経緯について教えてください。

Githubにはプロダクトデザイナーとして雇われ、課題やマイルストーンなどのプロダクトのコアな部分に関する業務を行いました。なので実際には、デザインシステムチームではありませんでした。プロジェクトがキックオフされるまで時間が少しあったので、CSSについて掘り下げて調べてみたり、質問をしたりしていました。

そのときから私は、スタイルガイドを改良する必要があると感じ始めていました。社内にはPrimerと呼ばれるスタイルガイドがありましたが、ドキュメント化されていないスタイルがたくさんあるなどの問題がありました。そのため、新しく入社した人が、すぐにデザインを始めるのが難しい状態でした。そこで私はスタイルガイドの作業を手伝い、プロトタイピングのための準備なども行いました。

そうです、デザインシステムチームは存在しなかったのです。デザインシステムが必要だということは私が言い始めたことだと思います。そして、デザインリーダーのOscar氏とあと何人かの興味がある人たちで、問題点についてのミーティングを開始しました。

このときから真剣に考えるようになって、この作業を進めることが本当に重要だとわかりました。プロダクトの作業と同時進行するのは困難だったので、しばらくして私の正式な職務になりました。

― デザインシステムの作成を担当するのは大変でしたか？

そんなに難しくはなかったと思います。すでにスタイルガイドのPrimerがあったので、完全なスクラッチから始めたわけではないので。ヘッドデザイナーであるMark Coudray氏もデザインシステムを必要だと感じていたのも助けになりました。難しかったのは、PrimerとCSS設計を再構築するための会議にみんなに参加してもらうことと、デザイナーとエンジニアが本当に使えるシステムにすることでした。なので、時間はかかりました。

― デザインシステムに関しては、どのような再構築が必要でしたか？

当時は、あまりフレキシブルなスタイルではありませんでした。そのため、最初に行ったことの１つは、ユーティリティクラスとアトミッククラスを導入することでした。なぜなら、これなら既存のものに追加するだけで済み、システム内のコンポーネントをリファクタリングする必要がなかったからです。これにより、すぐに成果を出すことができ、結果としてタイポグラフィのようなスタイルの基盤となるシステムを導入し始めることができました。

すべてのCSSをリファクタリングするとなると、相当な時間がかかると思います。私たちにはまっさらな状態から作業を開始する時間はありませんでした。なので、多くの作業は既存のものの見直しでした。大きなアップデートが必要なものもありましたが、ほとんどは小さな追加や修正でした。

機能的なCSSやアトミッククラスに不慣れな人たちにとっては、慣れるのに時間がかかったと思います。ですが、これを使ってページ作成をすれば、このCSSで作業をするのをみんなが気に入ってくれて、私に質問をしてきました。

― デザインシステムで解決したかった課題は何ですか？

それは２つの点が挙げられます。１つはデザインから開発へのワークフローを改善することです。つまりブラウザでのデザインをより簡潔にすることです。デザインシステムによって、デザイナーがデザインの初期決定に関して不安を感じないようにすることで、より大きなユーザー体験の問題やプロダクトの決定を考えることに時間に充てられるようになります。デザイン・開発のワークフローを改善することは非常に大切です。

もう１つは、ユーザー体験の一貫性です。もし一貫性のないスタイルでデザインをすれば、ユーザーも一貫性のないスタイルを目にすることになります。またスタイルだけでなく、インタラクションやページのレイアウトも同様です。なので私たちが手掛けるたくさんのプロジェクトに対して、より簡単なスタイルガイドを作ることで２重の利点がもたらされます。またUIも使いやすいものになります。

― デザインシステムのチームは拡大していますか？　それともまだオーナーとマネージャーだけですか？

常勤は私たち２人ですが、協力者の人たちがいます。協力者の人たちは、プロダクトチームや制作チームにまたがっています。私はデザインシステムチームのリーダーで、もう１人のデザイナーはJohn Rayhan氏です。彼はPrimerの仕事を長らく担当しており、エンジニアの経歴からも活かせることがたくさんあります。私たち２人が常勤としてこれを担当しています。またチームに新しいデザイナーを雇おうとしていますので、３人に増えると期待しています。

― デザインシステムの保守とアップデートのプロセスはどのようなものですか？

一般的に作るべきとされるようなフォーマルな提案書のようなものは何もありません。しかし、デザインシステムへのフィードバックのためのガイドラインはあります。たとえば、「これが必要だとずっと思っているのですが、見当たりません」というような小さなリクエストの形で来ます。私はコードベースをすぐに見直して、そのコンポーネントを私たちがどれくらい使っているかを見ます。そして、既存のコンポーネントなどに存在しているか、または存在していないかを調べます。

ただこれは序盤のケースなので、私たちができるときに対処するようなケースです。私たちは定期的にミーティングを行い、優先順位をつけています。これは大抵、より大きなプロジェクトを見るためのものです。細かい課題を対処していくために、私たちは月１回のバグローテーションを行います。これは単にバグを取り除くだけでなく、失われたドキュメントやコンポーネントスタイルの拡張などのような小さなタスクにも対処するためのものです。

また大々的にリデザインを行っていて、新しいコンポーネントが必要となるかもしれないような場合には、プロダクトデザインが仕事の一部になるときもあります。これはそんなに頻繁に起きるものではありませんが、このような場合は協力者の１人がその人物とペアになって、どのようにコンポーネントを作成するかを考えます。

なのでデザインシステムチームだけでなく、他のデザインチームからもリクエストとフィードバックを得ることができています。私たちは単独チームで仕事をしようとはしていないからです。Githubにはたくさんのパーツが稼働しています。なのでプロダクトデザインの点からこれらに目を向けることによって、どれがどの部分と同じようなもので、どのようにスタイルするか再考する必要があるかを気付くのに役立っています。

デザインシステムの課題

― デザインシステムを何年間も作成・発展させてきたわけですが、今直面している課題は何ですか？　

課題はたくさんあります。一番の課題は、チーム外の人たちに参加するように促し、私たちが行っていることの裏側にある「なぜ」の部分をどう説明するかというところです。CSS設計を変える理由の説明もですね。これはずっと課題としていることです。CSSやデザインと開発のワークフローについてたくさんのことを考えてきましたが、同時に、いかにコミュニケーションのことを考えていなかったかにも気付きます。

なので私たちは、チームメンバーへ変更を提案する方法を考え、さらなるアップデートについて伝えなればなりませんでした。私たちの場合、社内ブログがあったので、そこにアップデートを投稿をしていました。またスタイルガイドを通じてコミュニケーションを取ることで、現在の進捗状況をクリアにするようにしています。またフィードバックや変更履歴へのリンクも置いています。

このコミュニケーションという観点では、その重要性に気付くまでいくつかの問題に直面しました。これは大きな挑戦でした。もう１つの課題は、保守作業と大々的なリファクタリング作業とのバランスです。リファクタリング作業は表からはわからないもので、スタイルの変更を伴わないこともあります。

あとは、実際の作業と社内でのアピールのバランスも大事です。私たちが行っていることがその先の革新的な施策のための建設的な業務であると示す必要がありました。そして、私たちがチームとして成長するにつれて、他の人たちも私たちの存在を認識し出します。なのでより多くのチームがデザインシステムを活用するようになっています。

また私たちは、レビューやサポート、フィードバックの依頼を受けることもあります。これは少し煩わしいと感じることもあります。特に大規模なリファクタリング作業をしようとするときは、集中する必要があるのでなおさらです。そのため、私たちは依頼を上手く管理する方法を見つけました。

社内ではFirst Responderと呼んでおり、Githubの多くのチームがこれを活用しています。週ごとにFirst Responderとなる人を決め、その人が依頼などを対処します。他の人たちはプロジェクトの作業に集中することができます。

― 課題の１つが、デザインシステムに人々を参加させることだと言ってました。デザインシステムを有効活用し、広めるための戦略は何かありますか？

役に立ち、利用しやすくすることがその第一歩です。作業をしている誰かが私たちを呼んだり、または呼んでなくても私たちが何かの作業を見たりすると、「既にコンポーネントがあるので、新しくCSSを書く必要はないよ。」と声を掛けました。手助けが必要なときに、利用できるようにすることが大事です。また、Primerに存在せずドキュメント化されていないものもあったので、そのすべてをドキュメント化する作業もありました。

存在を知らなければ、それを使おうとする人はいません。スタイルを可能な限りドキュメント化しようと、私たちは大変な労力を費やしてきました。今はその作業はほぼ完了しており、より有効活用できるものになっています。またそうなると、存在も認知されます。CSSを書くよりも簡単に利用できるので、より多くの人が活用しています。

あと最後に、新しいものが使われ出して、元々の方法でやるよりも新しいものを楽しく使っていれば、みんなそのスタイルでやり続けたいと思うようになります。なので実際にデザインシステムが使って楽しいものであれば、デザインの開発もより簡単になり、ワークフローはより早く簡単で、良いものになります。この点が重要だと思います。

― 既存のデザインコンポーネントを最初に見たとき、予測してなかったような一貫性の無さがたくさん見つかりましたか？

そんなに驚きはしませんでした。たくさんの人が作業している企業で働くのは、初めてではありませんでしたから。予想通りだったと思いますよ。これは何度でも起き得ることです。古い企業ほどデザインシステムチームが必要だとは考えないものです。デザインシステムを作るのは大変なので、集中して取り掛かる人たちが必要になります。

これは数年がかりで、何百人のエンジニアやデザイナーが協力するようなことです。なので私にとっては、すごく驚くようなことは何もありません。多分、私がもっとも驚いたことは、カラーシステムが不足していることです。これは私が最近手がけたのですが、今までそのようなものがなかったことに対しては、戸惑いました。

（続く）