この記事は「Salesforceのデザインシステムはどのように作られているのか（前編）」の続きです。
デザインシステムの更新とリリース
―デザインシステムを更新するプロセスはどうなっているのでしょうか？
社外に公開しているデザインシステムに関しては、オープンソースのプロジェクトページから機能リクエストができます。ただ、それは氷山の一角で、実際の社内デザインシステムでは若干異なるプロセスがあります。現時点でどれだけプロセスが整理されているかはわかりませんが、さまざまなチャネルからの要望を同じ人に集約するようにして、適切な人にタスクを割り振れるようにしています。
たとえば、プラットフォームを担当しているデザイナーからが50％、残りの50％は個別の機能開発チームからの小さい要望で、デザインシステムには含まれていないけれど、（彼らとしては）絶対に入れたいと思っているものなどが来ます。更新はその時々によって大きく異なります。公開前のときもあれば、公開後のときもあります。実際、正式なプロセスがあるのかどうかわからないので、これについてはチームに確認しなければわからないのが現状です。
―デザインシステムの将来について、どのような目標を持っていますか？
デザインシステムチーム以外の社内外の人がドキュメントやコンポーネントを追加できるように、コラボレーション機能を改善することです。私たちは今これに取り組んでいます。小さな機能や微調整だけでなく、まったく新しいコンポーネントやパーツの追加ができるようにしたいです。
またリグレッションテストは大きな問題です。デザインシステムに貢献してくれた人それぞれが、ロールバックして別の人のものを台無しにしていないことを知れるように、リグレッションテストを改善しようとしています。500を超えるコンポーネントと状態があるので、予期せぬ影響を避けるためには、優れたテスト機能が非常に重要です。大まかにいうと、私たちはアーキテクチャを点検し続けているのです。今後数週間に私たちが何をリリースするのか注意していただけると、その側面でたくさんの変化が起きているのがわかると思います。とてもワクワクしていますよ。
―デザインシステムのリリーススケジュールはどのようなものですか？
現在はコミットされるたびに内部リリースをして、ステージング環境に反映させ、どこかのタイミングで変更が承認されます。ステージング環境では多くのリグレッションテストが行われています。誰かがプルリクエストを出したり、マスターブランチにマージされたりするたびに、たくさんのテストが行われますが、それらはすべてドキュメントに反映されます。
そして、週１回か隔週で内部の本番環境にリリースをします。基本的には外部に公開されているものより常に１つ先のリリースに取り組んでいます。たとえば、今コミットをすると、次のリリースで反映されるということです。コミットに「2.3.0 beta 7」のようなバージョンのタグをつけて、巨大な製品のすべてのCSSとアセットを管理を担当するチームに渡します。これによって、NPMを使っている私たちのチームにも共有することができます。
変更を反映する方法はたくさんありますが、それを一般に公開するのは年に３回ほどです。実際のリリースは、大きな修正が必要になったとき、つまり外部の顧客やエンジニアに影響を与えるときです。奇妙なリリースプロセスと言えるでしょう。しかし、私たちはこのプロセスを守る必要があります。もっと頻繁にリリースできたら良いなと思っているのですが、Salesforceが継続的デプロイや継続的インテグレーション、より良いリリース管理のために多くの作業を行っていることも知っています。いつか、３〜６ヶ月も待つことなくコミットを直接ユーザーに届けられるようになることを願っています。
顧客やステークホルダーとの関係
― デザインシステムの仕事でもっとも難しく感じたのは何でしょうか？
良い質問ですね。繰り返しになりますが、Salesforceは大企業であり、多くのプロセスが同時に進行しているので、アジャイル開発は必ずしも簡単ではありません。ゆるい仕事場で働いていた私のような人間には、Salesforceのような非常に組織化された場所で働くことは少しだけ難しいかもしれません。
たとえばイベントなど、マーケティングのチームが私たちのプロダクトの用途を見せる機会なども多く、それに対する配慮やスケジュールがあります。トレーニング教材を提供するプラットフォームなども存在します。私たちが改良を加えるたびに、これらに対してどのようなインパクトを及ぼすのかを考慮する必要があります。これだけの情報量と影響力が、CSSの書き方やそれをどうリリースするかなどの小さいことにのしかかってくるのです。
―デザインシステムにはどのようなメリットがありますか？
ベストプラクティスの普及があります。
１つ明らかなのは、すべてのチームにエキスパートを雇うことはできないということです。70名のフロントエンドの専門家を雇用し、１チームごとに１名ずつ配置することはできません。そんなことは不可能です。規模が拡大してフロントエンドの品質が向上したのは、素晴らしい成果でした。デザインシステムがなければ、同じパターンを何度も作り直すのに費されていただろう時間は想像もできません。また、私たちが期待した品質の高さについても、まったく異なっていたでしょう。
私たちの成功事例の１つで、いくつか面白い事例を最近目にしました。そのうちの１つは、昨年のメジャーリリースにまつわる話です。私たちはナビゲーションに大きな変更を加えることに決めました。以前だったら変更には何ヶ月も掛かるものだったものが、たったの１～２回のスプリントで済みました。複数のチーム間のプロジェクトであっても、CSSで少し変更するだけでそれが実現できると証明できたのは大きな成果で、経営陣やステークホルダーに、デザインシステムに大きな価値があることが証明できました。
もう１つは、カスタムCSSを本番環境から減らしたことです。これをすることで、顧客に提供するCSSの量が少なくなります。これが優れた成果なのは、顧客がダウンロードするものが少なくなるので、より早いページになるからです。
―デザインシステムの評価にはどのような指標を使用するのですか？
CSSコードの削減量と、アプリの各メイン画面がデザインシステムを利用している量です。
私たちは、経営陣が評価を理解できるようにビジュアルを押し出したプレゼンテーションを作成しました。経営陣は優れたプレゼンテーションを気に入るものです。スライドに使用したヘッダーはすべてデザインシステムにあり、ページヘッダーもまた、すべてデザインシステムにあります。そして、スライドを進んでいくうちに、いくつかのことが明らかになるのです。美しいスライド上で、いくつかの領域が緑に色付けされます。私たちはスクリーンショットを撮り、デザインシステムがあるところは緑色にし、デザインシステムを使用していないところは赤色にしました。去年時点ではすべて赤色だったものを示したのちに、次のページに行くと突然すべてが緑色になるのです。
経営陣は、将来的にデザインシステムのおかげで、コンテンツの密度や色、微調整などのデザイン変更の際に、70あるチームにドロップダウンのマークアップをわずかに変更するよう頼む必要がなくなることを理解したでしょう。すべてが１つの場所にあるので、私たちが技術的負債を生み出す代わりに、未来への賭けをしているように彼らは感じたかもしれません。……言い表すのが難しいですね。技術的負債は、逆に技術的投資にすることができるという比喩を目にしたことがあるのですが、私たちのデザインシステムはこの比喩の通りではないでしょうか。
― デザインシステムを進める中で、どのような教訓がありましたか？
私が個人的に遭遇したいくつかの事柄は、全体的なプロセスと大きく関係しています。学んだことは、何もかも一朝一夕では変えられないということです。
特にサポートは本当に難しいものです。私たちはオープンソースから多くのサポートの要求を受け取りますが、それ以外にも内部の顧客などからも膨大なリクエストを受け取っています。そのすべてに対応してサポート戦略を一貫させることは本当に難しい作業です。私たちはまだその表面に手を加え始めたに過ぎず、実際にはその体制もろくに整えられてもおらず、もし誰かが休暇を取ったら、２週間ほどすべてのチャネルのサポートが放置となってしまうような状態でした。
そして、顧客はそのような事態を好みません。これが私たちが学んだことの１つで、当たり前ですがサポートはきわめて重要だということです。製品を構築するときは、サポートを全体的な戦略の１つとして考慮する必要があります。サポートは製品を構築することの一環です。
これは私たちが経験した困難の一部ですが、全体としては素晴らしい成果を収めることがほとんどでした。私たちが進んでいく際にちょっとしたハードルにはなりましたが、「どうしよう、なんでこんなことをしてしまったんだろう」と認識を大きく改めることはあまりありませんでしたね。
厳密に言えば、もう１つあります。ドキュメンテーションは大事だということです。外部の文書だけでなく、コード内のドキュメントです。自分の書いたコードを６ヵ月後に解読するのは、特にCSSでは難しいことです。ですから、当時の奇妙な意思決定をコード内に文書化する必要があります。いつかまた自分のCSSに戻る必要ができたとき、「私は何を考えていたんだろう」と戸惑うことになります。誰かの実装を邪魔するかもしれないので、そのコードを何ヶ月も改善しなければなりません。そう考えると、やはり成果物はドキュメント化するべきでしょう。
― Nathan Curtis氏は、デザインシステムの作業は、複数の製品に役立つ製品を開発することだと述べています。この主張は正しいと思いますか？
私は、Salesforceがこの主張をもっとも実証している企業だと思います。私はNathan Curtis氏の主張は適切だと思っています。この作業はまさにSalesforceのデザインシステムチームがやっていること、つまり、製品やそれを取り巻くツールセット、一連のガイドラインなどを構築することです。デザインシステムは、完璧に需要が約束された製品です。今私たちは20人以上でこの作業をしていますが、本当に実感しています。
会社には複数のチームが存在します。CSSとリリースプロセスを担当するチームや、もっとUXエンジニアリングをベースにしたチームがあります。ほかにもプロトタイプを構築してデザインシステムに情報を伝えるチームがあったり、よりクリエイティブなチームがあったりします。パターンと全体的なデザイン戦略に気を配るチームや、もっとミクロな視点から、インターフェイスのそれぞれのパーツの動かす深い原則まで熟知しているチームもいるでしょう。すべてのチームが必ずしも100％デザインシステムを基に働いているわけではなく、仕事がときに交差することもあります。主にWebサイトの構築に目を向けるチームがある一方で、別のチームではより多くまたはすべてのアイコンするチームもあるのです。
―初めてデザインシステムを構築しようとしている人にアドバイスはありますか？
スモールスタートで始めるのがいいでしょう。これは多くの人が実践していることです。そして、できるだけ早く承認を得てください。会社のトップからの承認を得ないまま機能するとは思えないので、経営陣からの承認を取ることきわめて重要です。私にとって会社のデザインシステムを構築する中で一番難しいのは、その承認をビジネスの課題に適合させること、そしてその承認に沿うものを提供することです。デザイナーやエンジニアは必ずしも上手な営業ができるわけではないので、実際決定的に重要な点だと思います。
すべてはGina氏のような、ビジョンとアイデアを兼ね備えた人々から始まり、彼らがそのビジョンをさらに高い段階に共有できる人に伝えたのが始まりだったと私は思います。デザインシステムが資金を得て、実際に私たちがチームを作り出したからこそ機能したのです。
幹部からの承認を私たちが得られていなかったら、このようなことは起こらなかったでしょう。
