翻訳記事：連合型デザインシステムの誤り
気になる文章、読むときについでに訳しとこう活動？ですが、今回は、日本のデザインシステムの現場でも参照されることの多い、Nathan Curtis（@nathanacurtis）の最新記事を訳してみました（本人許諾済み）
訳し出したのを後悔するほど長文です😂
例によって記事内に過去記事へのリンクが点在してます。興味ある人はそちらも記事も目を通すと良いと思いますが、膨大です。
この記事では、以前「連合型（Federated）」がデザインシステムのサポートチームの育成モデルとして効果的な方法として推奨していましたが、実際には、「中央型（Centeral）」が前提条件であり、連合型だけでは持続可能ではないと述べています。
日本の場合、連合型という名のもとに片手間でデザインシステムをやり、結果的に途中で座礁・頓挫するケースを多く見ているので、やるなら中央型を意識して取り組むべき、と個人的には思ってたりしますが、とはいえ本業のプロダクト開発とある意味内部向け作業との予算の割り振りはとても難しいので、一概に何が良いかは言えないのが実情。むむのむ。
ちなみに、🌴本『デザインシステムの育て方』にはNathanの「連合モデル」についての説明（P.131）を含めた「ガバナンスと貢献」という章があるので、興味ある人は日本語なのでそちらも読んむのも良いかも。
本記事では🌴本の翻訳に合わせて「連合モデル」と訳しましたが、個人的には「Federated Design Systems」は「連合モデル」ではなく「Central（中央集権型）」に対する「Decentral（非中央/分散型）」的な意味合いで「連邦モデル」という言い方のほうが好きですですが、まぁ、どっちでもよき。
あと、そもそもの連合モデル（Federated Design Systems）などの考え方については、実践されてるサイボーズさんのこちらの記事も参考になります。
以下、翻訳（著者許諾済み）
連合型デザインシステムの誤り
誤ったモデルを賛美することによる損害やストレスを避けよう。
By Nathan Curtis
September 14, 2024
私の「どうお手伝いできますか？」という問いかけは、デザインシステムの混乱に直面しました。
6ヶ月前、デザインシステムチームは解散しました。その代わりに、デザインとエンジニアリングのスタッフからなる「連合モデル」が作られました（ちなみに誰も他の責任から解放されず、です）。それでも、システムは停滞しています。アセットは老朽化し、信頼は揺らぎます。皆が何をすべきか悩み、頭をかかえています。将来のプロジェクトが危険にさらされる中、私は率直に「まあ、あなたは仕事をする責任のある人を解放したのだから、何を期待していたのですか？」と答えました。
・・・
2015年に、私はデザインシステム拡張のためのチームモデル：孤立型、中央集権型、連合型の3つを確立しました。この記事では、それぞれのモデルを進めていき、単独型を嘲笑し、中央集権型を考慮し、連合型を支持するという形で、各セクションの位置付けと比率について説明しました。
それ以来、私たちデザインシステムコミュニティの実践者たち（後術の記事を例として参照）、思考を整理し、機会を促進し、ステークホルダーたちにシステムの連合型を追求する理由と方法を売り込むために、モデルを活用し拡張してきました。
連合型を優先したことは間違いでした。そして、間違っています。約10年前に発表して以来、私は自分の書いたことを明確にし、ニュアンスを加え、時には矛盾させてきました。今こそ、事実を正す時です。
この記事では、連合モデルは選択肢ではなく、一つの側面であることを掘り下げて説明します。実際には、連合モデルは決して最初に追求されることはなく、中央モデルの投資なしには進められません。ほとんどの場合、それは任意であり、その結果は非常に高額でフラストレーションを引き起こすことがあるため、追求する価値がありません。さらに悪いことに、連合モデルを主要な目的として位置づけることは、多くのステークホルダーの神話を解き明かす必要が生じ、システムの可能性が失われ、その存在さえも脅かす可能性があります。
・・・
連合の夢は多くの人々の現実ではない
一般的に組織は、特にシステム実践者は、人々を巻き込むことを目指しています。デザインシステムにおける「人々」の部分は不可欠であり、努力を要し、ときに困難です。私の同僚であるJina Anneは、彼女の長年にわたる有名な「デザインシステムは人のためにある」という講演で、その人々の重要性を強調しています。
人々のために、そして人々によって？
人々に焦点を当てることと、ガバナンスに対する期待を結びつけると、会話はすぐに原則的な領域になってしまいます。デザインシステムは単に人々のためだけでなく、人々によって、そして人々のものであるべきですよね？多くの考え方では、それはすべての人々のための、すべての人々による、そしてすべての人々のものであることを意味します。
しかし、実際的かつ歴史的な観点から見ると、すべての人々がデザインシステムを作るというのは、実際にはそうはなりません。私が出会うデザインシステムは、直接責任を持ち、専念しているチーム、個々のデザイナー、あるいは開発者によって作られています。つまり、「中央の人々」が製品としてのデザインシステムを作り、他の製品にサービスを提供しているのです。
確かに、参加を促進し、影響を与え、さらには貢献を支えるコミュニティをサポートするサービスもあります（これらは異なる概念ですので、注意してください）。これらの貢献は重要ですよね？そうだと思います。しかし、実際にはほぼすべての生産的な成果は中央の人々によって提供されています。
連合のみの例外は会話を混乱させる
「連合専任がうまくいった！」と言う人がいるのが聞こえます。
確かに、限られた文脈や一時的な取り組みではうまくいくかもしれません。しかし、そのような状況は、私がデザインシステムを定義する方法とは一致しません。デザインシステムとは、進化し、理想的にはミラーリングされたデザインとコードライブラリを通じて、スケーリングする組織が依存する基盤とUIコンポーネントを提供することです。
確かに、極めて稀な条件が整えば機能するかもしれません。私は、中央のデザインシステムチームなしで製品の成果を推進するために、揺るぎない才能、鋭い知性、卓越した自信、そして揺るがない権威を兼ね備えた専門家を知っています。また、デザインシステムなしで製品を進化させる、協力的でハイパフォーマンスなコーディング能力を持つデザイナーの小さなグループの正当な主張を読んだこともあります（それでも、どこかにシステムは存在します）。連合の夢が実現します！
連合の人々は、（追加の）システム作業を優先できないし、しない
しかし、私の経験から言えるのは異なる現実です。独立した連合モデルの貢献者から生まれる整合性のある成果への希望は、誤った期待です。最悪の場合、それは無謀なほど見当違いです。私は、組織が製品を進化させるために優先順位を設定し、個人がその優先順位に合わせて調整し、誰もシステムへの貢献のための余裕を確保しないのを見てきています。
私はデザインシステムのコンサルティングを80回以上行い、多様な状況（セットアップ）に携わっています：製品やマーケティング、大規模（100人以上）または小規模（10数人）の採用者コミュニティ、デザインのみまたはデザインとコードの両方など。すべての組織はシステムの成功を求め、投資する意欲がありました。
連合のみを魔法で実現するための自信に満ちた魔法使い、十分に協力的な文化、または連合のみにするための他の秘訣を持っていた組織はどれくらいあったのでしょうか？
Steve Carrellが映画『マネー・ショート 華麗なる大逆転』で演じた軽蔑的な専門家マーク・バウムの名言を借りるなら、「ゼロ！ゼロ！[デザインシステムが中央に配置された人々の支援なしで成功したことは]ゼロパーセント」です。」
中央のキャパシティへの投資なしに、連合のみで成功した例はありません。連合のみは選択肢ではありません。
・・・
連合型は誤った選択肢である
では、本題にはいろう。なぜ連合のみが選択肢ではないのか？
図の配置は選択肢を示唆していますが、残念ながらそうではありません。あなたのデザインシステムは中央管理型であるべきか、それともフェデレーテッドコミュニティであるべきか？
記事は「もし中央モデルが合わない場合、より複雑な道を追求することになる…」と誤解を招くように連合型に橋渡しをしました。その暗示は明確でした：連合型を選べ！うんざりです。中央型と連合型を相互排他的な選択肢として位置づけたのは間違いでした。
連合型を採用することは中央型を避けることを意味しない
これは二元論的な考え方であり、白黒思考 (Black-and-White Thinking)：複雑な世界における二元的思考の負担でよく説明されています。二つの選択肢があるからといって、それらが相互排他的であるわけではありません。連合型が望ましいからといって、中央型が望ましくないということにはなりません。その「または」を「そして」に置き換えて考えるべきです。
私の経験では、成功するデザインシステムは常に中央チームがあり、同時に常に連合コミュニティからの参加（そして、価値があれば貢献）を求めています。両者に様々な異なる形で投資される進化するモデルです。
単に連合型だけでは機能しない
議論が厳しくなるときは、不快な極端な例をあげて会話を設定しましょう。意図的に実現不可能な主張を挿入することで、中央に配置された人々の価値を確立できます：
空のFigmaライブラリファイル、空のコードリポジトリ、空のZeroHeightインスタンスを作成し、貢献者に好きにやらせるべき、ということではありません。
代わりに、中央の人々がアーキテクチャを設定し、ツールを作成し、プロセスを定義し、プレイブックを作成し、プラットフォームを100%の時間サポートします。常に、中央の人々がコアコンポーネントを作成し、維持します。
連合型を選ばない。その代わり、連合型を追加していく。それも徐々に。
システムの将来を考える際には、中央でサポートされる取り組みに連合型の貢献を段階的に追加する方法を検討してください。
もし連合型の作業が本当に成功すれば、状況に応じて中央投資を減らすこともできるかもしれません。安定して完全なコアアーキテクチャ（デザインシステムが世代交代の期間を経ていない場合）は、連合型の貢献と中央のキュレーションへの投資を減らすことで進化することができます。それでも、期待しないでください。過去10年間で、安定や完全である状況が長く続くのを経験したことはほとんどありません。両方が続くこともなおさらです。
連合型は任意
一部のチームは、階層や共有ライブラリを通じて、徐々に統合型の影響を取り入れています。しかし、多くのシステムは貢献に注目せずとも繁栄し、とても大きな価値を生むことができます。中には貢献を超越し、コミュニティに自立させるために責任を委ねるシステムもあります。
私はAtlassianのデザインシステムを尊敬しており、長年Atlaskitのコードカタログを活発な貢献の融合として引用してきました。彼らのコミュニティサポートのEditorコンポーネントは、最近メジャーバージョン197に到達しました！しかし、Editorは現在、コアシステムとは別の懸念事項となっているようで、明示的に貢献を修正のみに制限しています：
現在、私たちは … 修正 …を受け付けています。現時点では、 [小さな改善、主要な改善、新しいコンポーネントやパターン] の貢献を受け入れることができません。
彼らはおなじみの価値観を根拠として引用しています：広く共有されるニーズのために構築し、品質を確保し、ボトルネックを避けること。Editorがコンポーネントであり、コミュニティによって提供され、進化しているからといって、それが「デザインシステムに入る」というわけではありません（たとえ明らかにシステムの一部であっても）。I Love it！
・・・
連合型アンカーの有害な神話
ステークホルダーたちは、図を見た瞬間に仮説を係留（固定）します。
アンカリングバイアスとは、ステークホルダーが最初に提示された情報（およびその解釈）に大きく依存し、新しい情報がそのアンカーに対して参照されるため、客観的に考慮されない認知バイアスです。これにより新しい情報が歪められ、影響力や意思決定が損なわれます。
これらの仮説の多くは、有害な神話であり、以下のようなものがあります：
⚓︎ 誰もが貢献でき、貢献すべきであり、貢献する。
⚓︎ 作成されたすべてのコンポーネントはシステムに組み込まれる。
⚓︎ UIを作成する人は誰でも貢献できる。
⚓︎ どのレベルの構成のUIコンポーネントでも歓迎される。
⚓︎ 連合型への貢献は主要な成功指標である。
⚓︎ 連合型によりデザインシステムが無料で手に入る。
ステークホルダーたちを教育する際には、先手を打つことが重要です。彼らが影響、機会、リスク、そして今後の努力を理解できるように、自信を持って合理的なケースを構築する必要があります。上司の誤った仮説を修正するために繰り返し「ノー」と言う立場にはなりたくありません。
したがって、選択に直面します：係留された神話をそのままにするか、ステークホルダーたちに反論して神話を解きほぐすか。アンカーを外すことは困難で労力がかかり、最悪の場合、リスクを伴います。それぞれについて詳しくみていきましょう。
神話：⚓ 誰もが貢献でき、貢献すべきであり、貢献する。
事実：意味のある新機能や改善を貢献する人はほとんどいない。
待って、ほとんど誰も貢献しないなら、これはみんなが作ったものではないの？
（はい。）
それは良くないね。
中央のチームが全員が依存するライブラリを作ることは非常に良いことです。中央のチームは詳細に集中し、共有されたニーズを求め、小さな部分を全体に統合し、文書化してリリースし、他の人をサポートできます。連合の人々はそれを行わず、できず、または行おうとしません。
神話：⚓ 作成されたすべてのコンポーネントはシステムに組み込まれる。
事実：チーム間で作成されたほとんどのコンポーネントはシステムには属さない。
待って、つまりシステムには私たちの組織が作ったコンポーネントがほとんどないし、みんなが作るUIのほとんどは共有されないの？
（はい。）
それは最悪です。
デザインシステムは広く共有されるニーズに応えるアセットを提供し、多くのグループに提供するために安定的に進化できる機能を優先します。
チームは依然としてシステムのアセットを使用してかなりのUIを作成する必要があると予想すべきです。また、チームが作成するほとんどのコンポーネント ー低レベルのコンポーネントでさえー は、他のチームと共有されるニーズに応えないため、システムには属さないと予想すべきです。
神話：⚓ UIを作る人は誰でも貢献できる。
事実：ほとんどの貢献者は、システム経験が一般的に不足しており、このシステムのアーキテクチャに関する具体的な知識も不足しているため、効率的に貢献できない。
待って、つまり人々はスキルが不足しているから貢献できないの？
（はい。）
それは酷く敷板が高く、士気を損なうリスクがあるな。
デザインシステムはビジネス価値に関するものです。貢献を管理するコスト（すべての参加者の労力とメンテナンスおよび機会費用）がビジネスの利益（再利用可能な資産の価値とスタッフの個人的な成長）を超える場合、その貢献は悪いアイデアです。価値がある場合にのみ行うべきです。
さらに、直接責任を負う個人（DRI）やチームを特定することは、満足のいく職場に必要な明確さをもたらします。有能で才能のあるスタッフをDRIの役割に配置することは強みです。
最後に、中央システムの実践者はシステムの統合をサポートし、他の人とペアになり、発生した貢献をキュレーションする責任があります。知識を共有し、迅速にインシデントを解決することは、システムの実践者が皆の能力を高める方法の一つです。
神話：⚓ どのレベルのコンポーネントも歓迎される。
事実：デザインシステムは通常、低レベルのUIコンポーネントのライブラリを通じて織り込まれた視覚的な基盤であり、チームが独自にデジタル体験を構成できるようにします。
待って、システムのUIコンポーネントは低レベルのウィジェットの集まりに限定されているの？
（はい、少なくともコアライブラリでは。）
それはつまらなく、ビジネス価値が欠けてる。
そこには多くのビジネス価値があります。button、alert、textInput あるいは modal の何がシステムに含まれているか見たことがありますか？それぞれはコンポーネントの解剖学、プロパティ設定、レイアウト、動作、その他の10や100の視覚的属性に依存しています。これは測定可能な作業であり、高いアクセシビリティ品質でデザインとコードライブラリとしてパッケージ化されているため、他のチームがそれらを作成する必要がありません。
神話：⚓ 連合型への貢献は私たちの主要な成功指標である。
事実：中央チームによって作成されたコアライブラリは、外部からの貢献が含まれなくても非常に価値があります。
待って、私たちの目標がライブラリを作成し、他の人にそのライブラリを使用させることなら、ライブラリに貢献するユーザーは重要ではないの？
（その通り。）
それは変に感じる。
半年ごとまたは年次の計画シーズンが来ると、連合型の貢献はほとんど公表された目標項目には入らず、（Figma共有ライブラリのような取り組みは二次的に追求されるにも関わらず）中央の人々の能力のフォーカスの大部分を当てるべき存在には決してなりません。
代わりに、連合型への投資はしばしば周辺にあり、他の取り組みへの優先から、優先順位が下げられます。それは決して単一のフォーカスとなることはなく、システムチームに責任を持つ人々がシステムの成果物を作成し、他の人がそれを成功裏に使用できるようにすることに集中しています。
神話：⚓ 連合型によりデザインシステムが無料で手に入る。
事実：成功した連合型の活動には、プラットフォームを作成し維持し、連携した人々をサポートし、貢献をキュレーションするための非トリビアルな資本支出と継続的な運用コストが必要です。これは無料ではありません。
待って、つまり、私はたくさんの人たちにプラットフォームを構築してそれをすべて機能させるためにお金を払わなければならないの、数秒前にはこれがほとんど無料だと思っていたのに？
（はい。）
高額です。
長期的に連合に移行することは、デザイナーのプレイブック（しばしば読まれない）や開発者の CONTRIBUTING.md を構成する以上のことを意味します。さらに多くの作業が必要となります。
一度構築されると、プラットフォームを使用は開発者にとって大きな変化ではありません。システムでのコーディングは馴染み深いはずです：モジュール化して構築し、依存関係を管理し、テストスイートを実行し、リポジトリにコミットし、プルリクエストをレビューする。タスクは馴染み深く（いくつかのシステムスパイスを加えた場合でも）、セットアップが完了すれば、プラットフォームの運用は予測可能になります。ただし、コアエンジニアリングのメンテナンス担当者が行うべきキュレーション、品質、そして承認作業を行う必要があります。
デザイナーにとっては馴染みが薄く、さまざまなタスクがシステム特有の期待（ルール）が伴います。共有されたニーズを監査して統合する。既存のコンポーネントの例を比較する。APIを考案する。使用法を文書化する。高品質のFigmaアセットを作成してテストする。これらは基準は高く、スキルは「通常の製品デザイン作業」とは異なります。
学習は、練習とシステムの専門家との協力の時間が必要です（運用コスト）。それにより良いものを生み出し、個人的にも成長します。私はその仕事が好きで、非常に大きな内面的報酬があります。しかし、それには時間がかかります。自業自得なのです。
・・・
あなたは、これらの神話を説明するのがどれほど冗長であるかに気づきましたか？上記のテキストを実態に読読みましたか？それとも心ここにあらずでざっと目を通しただけですか？
さて、あなたがステークホルダーで、しばしば下位の人や異なるグループの人が自分の信じていることに反論するのを聞かなければならないと想像してみてください。だから注意が必要です。連合型の貢献について理解できないことを説明するのは、単に複雑なだけではありません。苛立ち、退屈、気が散ること、十分な時間がないこと、憤慨、そして軽視といった感情を引き起こすリスクがあります。このような感情は軽視すべきではありません。
中央モデル vs. 連合モデルの参考資料
以下の記事はすべて「デザインシステムを成長させるためのチームモデル」で説明されている中央モデルと連合モデルの概念に言及しています。
The Salesforce Team Model for Scaling a Design System by Jina Anne, 2015
Designing a Design System (a step by step guide) by Louis Henrich, 2017
The Paradox of Design Systems by Brendon Manwaring and Josh Mateo, 2018
Design Systems: Why Do They Matter? by Marcela Morales, 2021
Remarkable UX Design Teams by Isadora Agency, After 2019
How do teams work with your Design System? by Raktim Chatterjee, 2022
Is your design system performing? by Alicia Cheung and Rebecca Holland, 2022
Design Systems: Investing in the People Behind the System by Reneé Cagnina Haynes, 2022
From Vision to Reality: The Roadmap to Building an Enterprise Design System by Oleksii Popovych, 2023
Opening up the Design System for Everyone — The Federated Model by Anirudh Hothur, 2023
Implementing a Design System in an Existing Product byJustyna Klimkowska, 2024
The merits of design systems by Balanet, 2024
How to build effective enterprise design systems for your company by Webflow, 2024
Keeping design system contributions in check by Wart Burggraaf
翻訳以上。