Kaelig Deloumeau-Prigent氏は、SalesforceのLightning Design Systemチームのシニアデザイナーです。
フロントエンド開発とデザインにおいて長年の経験を持つKaelig氏から、デザインシステム構築のアドバイスについて教えてもらいました。デザインシステムのメリットやプロセスの詳細については、無料の電子書籍『Why Build a Design System?』をダウンロードしてください。
Salesforceのデザインシステムチームへの参加
― どのようにしてSalesforceのデザインシステムチームに参加したのですか？
これには面白い経緯があります。私の妻はAppleに就職するために米国に引っ越しました。彼女はアメリカ人ですが、私たちはしばらくロンドンに住んでいたのです。「妻を追って行こうかな」と思い、私は彼女を訪ねるためにシリコンバレーに行き、そこで多くの人たちと、どんな仕事をしているのかについて話をしました。
ある日の昼食で、私はSalesforceのGina氏とSteph氏に出会い、彼らは自分たちが担当しているLightning Design Systemについて話してくれました。デザインシステムは、この時点ではまだ非常に初期の段階でしたが、問題なく制作が進んでおり、非常に有望なものでした。
私は彼らがビジョンとインフラの面で目指しているものを聞きました。それは驚くべきものでした。これまで私は、SalesforceをUXの思考を持った企業として見たことはありませんでしたが、その考え方は完全に変わり、いかにSalesforceがUXを推進しているのかを知ることになりました。
そして、私はそのチームに入りたいと思いました。実際には、彼らの方から昼食の際にこんな話をしてくれたんです。「おや、シリコンバレーに引っ越すんですか？ ということは、いつかは仕事を探し始めるということですよね。」とても自然で、ぴったりの言葉でした。私はそれ以来、約１年半そこに住んでいます。
― 2015年に初めてデザインシステムチームに加わったとき、主な仕事はどのようなものでしたか？
最初はCSSの作業をしていました。コードの革新部分に関するレビュー依頼などが多く、この中で自動化できるものを見つけるのには多くの時間を費しました。すぐに私は、プロセスにおいて改善できる箇所を探し始めました。これは基本的なもので、たとえばLintツールの導入や、デプロイの自動化などです。まずは良いCSSを提供する際に邪魔になる小さな障害をすべて見直したんです。
― 初めて参加したときは、デザインシステムチームはどのように構成されましたか？
分野横断のチームでした。マネージャーのChris氏は、デザイナーであり最高の上司でした。彼は私が加わった直後に異動してしまいましたが、彼はデザインシステムのチームと会社のほかのメンバーとの間の調整役でした。彼は、私たちと会社を繋ぐインターフェースの役割を果たしていたんです。
その後、Steph氏がリーダーになりました。彼女は今でもCSSアーキテクチャのリーダーです。
Adam氏は、おそらく初期のころからずっと「Theo」に取り組んでいました。聞いたことがあるかどうかわかりませんが、これはデザイントークンを利用するための優れたツールです。これについてはのちほど説明しますが、彼はコードのインフラ構成に関わる専門家のひとりです。
Brendon氏はCSSを扱い、クリエイティブディレクターとしての膨大な背景知識を持ち、コードを変換するのが本当に上手です。多くのコンポーネントを構築しています。
それから、デザインと知識の伝達という役割にはGina氏がいて、デザインをより大きな規模で統合する方法について考えていました。ほかにも素晴らしいグラフィックデザイナーがいて、Salesforce専用の多くのアイコンを作りだしていました。Gina氏は彼らの背後で働く人でした。そして、私はもっと技術的な人間として参加しました。
デザインシステムを発展させる中で
― Salesforceに入ったとき、直面していた最大の課題は何ですか？
Salesforceのような大企業におけるもっとも大きな挑戦は、その規模の中でいかに速くて効率的な優れたプロセスを生み出せるかということです。Salesforceは、現在に至るまで過去18年間も続いた独自のやり方やプロセスを持つ大きな組織でした。そのため、私にとって難しかったのは、広い視野を持ちながら、デザインシステムを利用するチームのプロセスを観察し、それに合わせたシステムを作ることでした。
― 変更しなければならなかった、あるいは完全に再構築しなければならなかったプロセスは何でしたか？
社内の全員がパッケージ管理ツールのNPMを使用しているわけではなかったので、リリースのサイクルには多くのプロセスが発生します。メインでお客様にデリバリーするような新機能などのリリースは年に３回あるのですが、デザインシステムをエラー修正などで日々対応していきたい場合、必ずしもこのサイクルにうまく組み込まれるとは限りません。
「新しい機能のためにアイコンが欲しい」という依頼の場合、我々は少し時間を割いてそのアイコンを作成し、デザインシステムに追加するのですが、これにより次のような大きな疑問が生まれます。
「そのアイコンが本番環境に反映されたかをどのように確認すれば良いのか？ デザイナーとエンジニアはどのようなプロセスで共に仕事を進めれば良いのか？ アイコンはどこに保存されているのか、そして具体的にはどのリリースにて反映されるのか？」。
私たちは常に同時に２つから３つのリリースに取り組んでいます。すべてのアセットがどこにあり、何が利用可能なのかを知ることは、私たちが解決しようとしている課題です。
私自身がやっているのは、私たちのプラットフォームの側でできるだけ自動化をすることですが、まだやるべきことはたくさんあります。我々が取り組んでいるのそういったことです。
― 現在Salesforceでは、デザインシステムのアセットはどこにありますか？
私たちのデザインシステムは、複数のGitHubリポジトリの集合です。最終的に１つの情報源を頼るわけですが、デザインシステムは、私たちにとっての唯一の情報源としています。私たちは、すべてのエンジニアやデザイナーが参照でき、リソースを見つけることができる、社内ポータルを持っています。
グラフィックデザイナーやUXデザイナーのような役職の人なら、すべてを収集するためにデザインシステムを利用したいかと思うので、今は内部ツールをベータテストしています。アイコンのようなデザイナーのアセットやイラストを探すたびにWebページに行く必要がないように、Sketchなどのソフトウェアと上手く連動するデスクトップアプリのようなものを開発しています。
恐らく結果的には複数の情報源になってしまうものと推測していますが、そのほとんどを自動化することによって機能するようにしたいと考えています。やはりアイコンなどは需要も高いので、そういったことに現在私たちは取り組んでいます。
― Lightning Design Systemでもっとも進化したのはどこでしたか？
間違いなくコンポーネントの面です。
私が仕事を始めたときは、主にユーティリティクラスとフォームがありましたが、これは基礎的なコンポーネントでしかありません。一方今では、私たちはきわめて大規模で複雑なコンポーネントに取り組んでいます。高品質なコンポーネントは、会社全体でもっとも必要とされているものでした。同時に数十のスクラムチームがそれぞれの機能を開発しており、どのチームも素材と素早さを求めています。ここが私たちがもっとも成長してきた領域です。現在は、デザインガイドラインやより良いドキュメントの作成についてなど、そのほかの分野の改善も検討しています。
―ドキュメントの改善が目標の１つということについて、もう少し詳しく教えてください。
セルフサービスのように使えるということは、必ずしもデザインシステムでもっとも重要な点ではありません。それぞれの意思決定がなされた裏にある考え方を理解することも重要で、１つのコンポーネントが多くのデザインの意思決定に大きな影響を与えることもあります。そのため、コンポーネントの使用方法について相互ガイドラインがあると良いでしょう。また、なぜこのコンポーネントがこのように構築されたのか、どのような考えがあるのかについても私たちは見ています。
それはリサーチによって得られた知見であったり、現在のコンポーネントに至ったデザインパターンなどです。私たちのデザインシステムには、アクセシビリティとJavaScriptは含まれていません。そのため、JavaScriptの開発者のために、複数のフレームワークにおいてデザインシステムのコンポーネントを実装する方法を相互ガイドラインに含める必要があります。つまり、ベストプラクティスを幅広く適応するためには、優れたドキュメントを持つことが重要なのです。
Salesforceのような場所では、特にドキュメントは重要になります。
この記事の後編はこちら
