翻訳記事：デザインシステムチームなしでデザインシステムを構築する
某DSチャネルで上がってきて目に止まり、わりと参考になるな、と思って9月頃に翻訳したまま寝かしていた記事🤣ですが、師走の忙しい時期とはいえ、頑張って🎄前に公開。 デザインシステム Advent Calendar 2023 の20日目の記事です。
一部のメガベンチャーみたいに豊富な社内リソースがある企業は別として、たぶん、現状のほとんどの国内企業の状況ってこんなんじゃないのかな？と思います。昨今、「デザインシステムやってます！」ってのは会社のブランディングや採用時の強みにもなるっぽいですが、よく聞く話は海外のように専任リソースはない状況が実情。
とはいえ、海外もGoogleやAtlasiaon、Neflixみたいな大手なら別ですが、殆どの場合は経験上、AORなデジタルエージェンシーに基本的な部分を一緒に構築して一緒に育てていくのが主流なのかな？と思います。
実際、例えばNikeなんかも初期はR/GAやAKQA、現在はInstrumentがやっていたりします（運用とプロジェクトレベルの開発のバランスは知りませんｗ
デザインシステムチームの成熟度という観点では、古いですが@yhassyのこちらの記事も参考になるかと思います。
以下、記事本文：
デザインシステムチームなしでデザインシステムを構築する
Foursquareにおけるデザインシステムのガバナンスとプロセス
By Andrea Nguyen, Koi Studios
デザインシステムとFoursquareは、私が所属する以前から数年間、やったりやらなかったりの曖昧な関係でした。そうこうしているうちに、一連の合併を経て、Foursquareには膨大な製品ポートフォリオとそれに付随する複数のデザインシステムが残されました。新機能のローンチや、プロダクトとエンジニアリングチーム間のコミュニケーションチャネル不足が重なり、デザインシステムは統一されたものというよりも、個性的なものになっていきました。その結果、Foursquareの下に複数の異なるブランドが存在することになり、プロダクト間でUI/UXが一貫せず、プロダクトデザインのワークフローも非効率的なものになってしまいました。
2022年の第2四半期、私たちは選択を迫られました。プロジェクトが思ったより進まない傾向にある現状をこのまま続けるべきか、それとも、一貫性のある効率的なプロダクトを作るために重要な、異なるプロダクトチーム間で使用されるデザインとコンポーネントライブラリの両方を統一する新しいシステムを構築することで、この状況を改善するべきなのか？
失敗したモデルの物語
ボタンを作るには何人のデザイナーが必要でしょう？私たちは、デザインシステム（ちなみにCupcakeと呼ばれています）に取り組み始めた当初、ハードな方法を発見してました。まず、私たち6人のデザイナーは各々、それぞれのUIに散らばっているさまざまなボタンについて、それぞれのプロダクトを監査しました。そこから、私たちはすべての異なるバリエーションを検討し、一緒にデザインを考えました。全員に意見を言う機会がありました。その後、私たちはそれぞれの場所に戻って、新しいボタンデザインをそれぞれのプロダクトのいくつかのページに差し込み、デザインが機能しないエッジケース（ページレイアウトを崩す、見た目がおかしいなど）を特定できるかどうかを確認しました。私たちは次のミーティングまで1週間待ち、そこで再び意見を出し合いました。そしてボタンを更新し、それを繰り返すことを続けました。そして最後についにデザインが完成したのです。
素晴らしいコラボレーション、ディスカッション、ストレステスト......ただ、3週間ガッツリかかっりました！ボタンのデザイン ー 最も単純なコンポーネントの一つであるボタン ー にこれだけ時間がかかったとしたら、もっと複雑なコンポーネントのデザインにはどれだけの時間がかかるのでしょうか？
私たちが経験したコラボレーションとフィードバックのサイクルは有益でしたが、いくつかのことがペースを落とす原因でした：
他のデザイナーのフィードバックを聞くことは、成功するデザインシステムの構築に非常に重要なことですが、キッチンに料理人が多すぎると、効果的な意思決定を行うことが難しくなります。
フィードバックを週に1回、あるいは2週間に1回のミーティングに限定していたことがデザインプロセスの妨げになっていた。
役割分担を明確にしていなかったので、誰が何に責任を負っているのか、理解するのが難しかった。
最初のコンポーネントから学ぶことで、早い段階でガバナンスモデルとプロセスの構築に時間を投資する必要があることが明らかでした。
ハイレベルなガバナンス
ブロッカーを最小限に抑え、合理化するために、デザインディレクターは、すべてのデザイン作業のためのポイントパーソン（私）を設置することが適切であると考えました。コンポーネントをデザインし、ドキュメント化し、開発パートナーと協力してビルドしてリリースするのは私の責任になりました。もう一人のデザイナーは、すべてのアセットをデザインアセット管理システム（ウェブサイト）にポートする作業を割り当てられました。そして最後に、すべてのコンポーネントは、エーテルに入る前（訳注：「エーテル （ether）」は宇宙空間／天空の意味。デザインシステム世界の意）にデザインマネージャーを経由して承認を得ることになりました。ここで重要なのは、誰もフルタイムでデザインシステムに携わっていなかったということです。
プロセスについて話そう
スプリントで作業
私は、Cupcakeと他の製品の仕事の間で時間を分けなければならなかったので、シンプルなMVPのコンポーネントの大半をデザインできるまで、2週間ごとにスプリントで作業することが効果的だとわかりました。これらは製品にすでに存在していたコンポーネントでしたが、再利用可能なコンポーネントにまだなっていなかったものです。このプロセスはまず自分の製品の作業をストーリーポイントで始めます。また、デザインシステムのために各コンポーネントの設計とドキュメント作成にかかる作業もストーリーポイントで見積もります。その後、残りの余裕に応じてコンポーネントを取り組みます。時には他のデザイナーもコンポーネントを拾うことができました。適切なデザインプロセスを経てコンポーネントが一貫して構築されている限り、問題はありませんでした。
まだ存在しないコンポーネントについてはどうだろう？
私たちは、Cupcakeのパターンガイドラインに適合する新しいデザインを考え出し、レスポンシブ性を組み込み、テストし、ステークホルダーからフィードバックを集め、複数の製品で確実に機能するようにしなければなりませんでした。
私はすぐに、製品の仕事、古いコンポーネントのキャッチアップ、新しいコンポーネントの作業の間で、私のワークフローが持続可能でないことに気づきました。
そこで私は、仕事の一部をチームの他のデザイナーに任せることを目標に、新しいプロセスを設計しました。
その前提条件として、デザイナーは新しいコンポーネントやバリアントをリクエストする前に、既存のコンポーネントを使用してすべての選択肢を使い果たしていることを確認する必要がありました。
新しい部品については、次のような疑問について考える必要がありました：
他のチームはこのコンポーネントから恩恵を受けるだろうか？
既存のコンポーネントでどのようなオプションを試し、なぜうまくいかなかったのか？
このソリューションはテスト済みか？
新しいバリアントについては、彼らはこう答えます：
既存のバリアントと新しいバリアントはどんなときに使うのか？
この新しいバリアントが既存のものよりうまく機能する例を示してくれているか？
新しいコンポーネントやバリアントが必要だというコンセンサスに達した後、私たちは以下のステップを含む私たちのプロセスに従うことを確認しました：
Jiraチケットの作成
コンポーネントのファーストパスをデザインし、ユーザビリティと有効性をテストする
デザイン批評でそのコンポーネントのフィードバックを収集する
フィードバックに基づいて繰り返す
そこから、チケットは私に再割り当てされ、Cupcake用に "適合 "させることができる。これは通常、製品固有のデータを削除したり、追加のユースケースをデザインしたり、アプリケーションと開発のためのドキュメントを書いたりすることになります。最後に、そのコンポーネントはデザイン・マネージャーを通して最終的なレビューを行い、納品となります。
開発への引き継ぎ
コンポーネント開発はSolverチームが担当し、Cupcakeをボランティアで手伝ってくれた異なる製品チームのエンジニアで構成されていました。しかし、私たちのデザインチームと同様、エンジニアは相反する製品の優先順位、時差のあるスプリント日程、限られたバンドワイズ（稼働可能時間）など、それぞれの課題に直面していました。そのため、コンポーネントは、製品のニーズに基づいて、散発的にピックアップされ、構築されていました。
専任の開発リソースがなければ、製品スプリントからデザインシステムの構築と統合のための時間を取り戻すのが精一杯でした。現在の機能プロジェクトに必要なコンポーネントが最初に優先されました。
このプロセスには多くの愛情が必要でした。前にも述べたように、コンポーネントを構築するための勢いは、優先順位の欠如とリソースの割り当て不足のために遅れていました。例えば、ボタンを開発してローンチするのに8週間以上かかりました。しばしば、Solverチームのエンジニアは、コンポーネントのすべてのユースケースを構築するために十分なスプリント時間を持っていなかったため、別のチームが残りの作業を引き継ぐまで、コンポーネントの半分が構築されたままになっていました。リリースを計画したり、予測可能な成果を提供したりすることができませんでした。
プロジェクトに時間を割り当てるために、製品チームとエンジニアリングチームの両方がコミットする必要があります。デザインシステムの作業に時間を割り当てる方法の1つは、製品イニシアチブを書くことでした。これにより、製品チーム（およびそれぞれのエンジニアリングチーム）が、各四半期の開始時にデザインシステムを計画できるようになりました。これは部分的には機能しましたが、デザインシステムが負担になるよりも役立つ場所に到達するためには、さらに多くのリソースとコミットメントが必要でした。40のコンポーネントを構築する必要があるとわかっていたので、このワークフローは持続可能ではないことがわかりました。そのため、私たちは積極的にバンドワイズ（稼働可能時間）を増やす方法を探し、Cupcakeのリソースを推進するように努めました。
しかし、それは別の記事の話です。
結論
他の製品と同様、私たちはこれらのプロセスを確立する前に、何度も反復とストレステストを繰り返した。それでもなお、私たちが予期していなかった新たな問題にぶつかると、プロセスは頻繁に変更される。
最後に、この経験から私が最も重要だと感じたことを挙げたいと思います。
デザインシステムを売り込むための努力と重要性を過小評価しないでください。システム自体を設計する上で、製品マネージャーやエンジニアチーム、幹部と何度も会議を重ねて賛同を得る必要がありました。時間がとてもかかります。
最終的、リソースが必要になるでしょう。デザインシステムに関しては前例のない進歩を遂げ、自分たちで作業するための余裕を作る方法を見つけましたが、時間の経過とともに持続不能になることは明らかです。デザインシステムは専任の仕事であり、チームメイトにいつまでも時間をボランティアで提供してもらうことはできません！ですので、引き続きリソースを求め、将来を見据えることを続けてください。長期的に考えてください。
デザインシステムは比較的新しいトピックなので、舞台裏にあるものについての情報を見つけるのは難しいです。 ー チームの構築、プロセスの作成、コミュニケーションの管理。さらに薪を投げ込むと、一つのチームにうまくいくことが別のチームにはうまくいかないこともあります。実際のところ、多くの組織がまだ専用のデザインシステムチームを持つという贅沢をしていないのです。Foursquareもその一つです。ですので、これが現在私たちのデザインチームでうまくいっていることです。あなたのチームにも何か役立つ情報が見つかるといいですね！
・・・
この記事で表現されている意見や考えは私個人のものであり、Foursquareの公式方針や立場を反映したものではありません。
翻訳以上。
補足：Cupcakeについては、Andreaのポートフォリオに詳しく書いてるので興味ある方はそちらも参考にどうぞ。