「デザインシステムのドリフト」とは具体的に何を指し、最初からうまく作られていなかったデザインシステムとはどう違うのですか？
ドリフトとは、デザインシステムがもともと明確に定義されていたにもかかわらず、時間の経過とともに実際に本番環境で稼働している成果物がその定義からひそかに乖離していくことを指す。システム自体が最初から不完全に設計されていたわけではない。この区別は重要だ。最初から欠陥のあるシステムは、システム設計の段階に問題がある。ドリフトするシステムは、ローンチ後、システムを現実と整合させ続けるための仕組みが欠けていることに問題がある。
ドリフトの特徴は、段階的で目立たないことだ。ドリフトを引き起こす個々の決定は、その瞬間にはどれも妥当に見える。あるチームが一時的な例外を作る、あるエンジニアが参照テーブルを確認せず記憶から色を入力する。どちらも単独で見れば大したことではないが、積み重なっていくうちに、システムが定義しているものと本番環境で実際に稼働しているものとの間のギャップは、時間が経つにつれて無視できないものになっていく。
なぜレビューのボトルネックが、チームに承認を待たずそのまま公開させてしまうのですか？それは無責任ではありませんか？
レビューのボトルネックの根本的な問題は、チームが一貫性を気にしていないことではなく、プロセスの速度がチームが必要とする出荷速度に追いついていないことにある。デザインレビューが完全に一人か二人のシニアメンバーの手作業に依存している場合、彼らにはもともと自分の仕事があり、レビューの待ち行列は通常、彼らが処理できる速度よりも速く積み上がり、待ち時間は数日、あるいはそれ以上に延びることがある。
この状況下で、チームは現実的なジレンマに直面する。レビューを待って納品を遅らせるか、先に公開してしまうかだ。ほとんどのチームは後者を選ぶが、それは一貫性を軽視しているからではなく、すでに過負荷になっているレビュープロセスを無期限に待つことをビジネス上の圧力が許さないことが多いからだ。これが、解決策が通常「レビューをより厳格に強化する」ことではなく、「レビューを唯一のボトルネックにしない」ことである理由でもある。一般的なコンプライアンスチェックを自動化し、手動レビューは本当に人間の判断が必要な例外だけを扱うようにする——すべての変更が一人か二人の確認待ちで列に並ぶのではなく。
ドキュメントにおける「なぜかを説明する」ことと「何かを列挙するだけ」のことは、実際にどれほどの違いを生むのですか？
その違いは、例外の繰り返しを防げるかどうかにある。「ボタンは何色にすべきか」だけを列挙したドキュメントは、新しい状況（危険なアクションのボタンなど）に直面したとき、ユーザーが自分で推測するしかなく、その推測はシステム本来の設計意図と一致しない可能性が高い。一方、「危険なアクションのボタンが異なる色を使うのは、特定のコントラスト比を満たし、特定の警告の意味を伝える必要があるからだ」と説明するドキュメントは、ユーザーが似ているが完全には一致しない新しい状況に直面したとき、その原則に基づいて自ら合理的な対処法を導き出せる。毎回デザインシステムチームに聞き返す必要がない。
この違いはエッジケースで特に顕著だ。最も不整合を引き起こすコンポーネントは、ほとんど単純なものではなく、境界的な状況だ。カードのタイトルが極端に長い場合どうなるか、モバイル版のエラー状態はどう見えるべきか。「何か」だけを列挙したドキュメントは、通常こうした状況をカバーしていない。エッジケースの組み合わせはほぼ無限であり、すべてを列挙することは不可能だからだ。しかし「なぜか」を説明するドキュメントは、ユーザーに類推する根拠を与え、ドキュメントが明示的にカバーしていない新しい状況にも、その原則を合理的に適用できるようにする。
Claude DesignのようなAIツールで画面を生成している場合、デザインシステムの統治は自分にどう関係するのですか？
もしあなたがチームでデザインシステムの維持を担当している立場なら、この記事で扱っている統治の原則は直接適用できる。システムに明確な責任者がいることを確認する、ドキュメントがルールを列挙するだけでなく原則を説明していることを確認する、アクセシビリティ標準が最後にチェックされるのではなく最初からコンポーネントに組み込まれていることを確認する。これらの原則は、AI生成ツールに切り替えたからといって効力を失うわけではない。チームがインポートするデザインシステム自体の統治が不十分（責任の所在が不明確、ドキュメントが古い）であれば、AIはその問題を新しく生成されるすべての画面により速く複製するだけであり、自動的に修正してくれるわけではない。
もしあなたがチームでの統治のニーズがない個人ユーザーであれば、この記事の価値はむしろ、どのデザインシステムが本当に信頼してインポートする価値があるかを判断する助けになる点にある。ドキュメントが完全で、なぜかを説明し、エッジケースをカバーしているシステムは、インポート後にAIが生成する結果が実際のニーズにより近くなる傾向がある。原則の説明がなく単なるコンポーネントのリストにすぎないシステムは、そのリストがカバーしていない状況に直面した際、AIは結局統計的に推測するしかなく、デザインシステムをまったくインポートしなかった場合とそれほど変わらない。
ほとんどのデザインシステムは一度に崩壊するのではなく、徐々に「ドリフト」していく。あるチームが一見妥当に見える例外を作る。あるエンジニアが参照テーブルを確認せず値をハードコーディングする。外部から参加したエンジニアが、あるコンポーネントがすでに存在することを知らず、独自にゼロから作り直してしまう。これらの決定はどれも単独で見れば大したことに見えず、その瞬間には重大な影響があるとも感じられない。しかしこうした決定は積み重なっていき、時間が経つにつれて、デザインシステムで定義されているものと本番環境で実際に動いているものとの間のギャップは、無視しがたいものになっていく。ボタンのスタイルが微妙にずれ、カラー値がブランドガイドと合わなくなり、半年前にはなかったアクセシビリティの問題が突然現れる。これはデザインの失敗ではなく、統治の失敗であり、デザインチームが規模を拡大する際に最もよく直面する問題の一つだ。
デザインシステムそのものは「何があるか」——コンポーネント、トークン、スタイル、ドキュメントだ。統治は「どう機能するか」——変更がどうレビューされ承認されるか、不整合がどう見つけられ修正されるか、新しい貢献者がどうルールを学ぶか、組織が成長するにつれてシステムがどうブランドガイドラインやアクセシビリティ要件と整合し続けるかだ。どれほど見事に構築されたデザインシステムであっても、統治の仕組みがなければ時間とともにドリフトしていく。統治こそが、システムを長期的に有用に保つ鍵なのだ。
いくつかのよくある破綻点が繰り返し現れる。1つ目はレビューのボトルネック——デザインレビューが手作業で遅く、一人か二人が一貫性の唯一の判定者となり、レビューの待ち行列は彼らが処理できる速度よりも速く積み上がっていく。チームは最終的に承認を待たずに公開してしまう。気にしていないからではなく、プロセスが実用的とは言えないほど遅いからだ。2つ目は単一の情報源がないこと——ブランドガイドラインはある場所に、デザイントークンは別の場所に、アクセシビリティ標準は3つ目の場所に、Figmaのコンポーネントライブラリはさらに別の場所にある。これらすべてを同期させ続けるには追加の人員とリソースが必要であり、それを満たせないことが多い。3つ目は擁有権の曖昧さ——システムの進化に明確に責任を持つ人がいなければ、標準は緩み、採用率は下がる。それが「みんなの責任」であれば、通常「誰の責任でもない」ことになってしまう。4つ目はアクセシビリティのギャップ——アクセシビリティ標準は、最初から組み込まれた要件としてではなく、最終段階のチェックとして扱われることが多く、問題が発覚した頃には修正コストはすでに高くなっている。5つ目は貢献プロセスの混乱——コンポーネントを貢献する際の審査基準が曖昧だと、チームは想定外の厳しい審査に驚き、貢献を断念してローカルで回避策を作ってしまうことが多い。その回避策は決してシステムに還元されることはなく、システムと現実のギャップはさらに広がっていく。
デザインシステムのドキュメントは形式として扱われがちだ——大規模なリファクタリングの後に一度更新され、その後徐々に現実からずれていくWikiページのようなものだ。しかし本当に効果的なドキュメントは、最も重要な統治のツールの一つである。それは作業が行われるまさにその場所に存在し、3回クリックしないとたどり着けない場所には隠れていない。それは「何か」だけでなく「なぜか」を説明する——なぜ破壊的なアクションのボタンは異なる色にすべきなのか、その色の選択はどのコントラスト比を満たす必要があるのかを説明することで、文脈が例外の繰り返しを防ぐ。それはエッジケースに具体的な答えを与える——例えばカードのタイトルが80文字を超えた場合どうなるか、モバイル版のエラー状態はどう見えるべきかなどだ。それはアクセシビリティ標準をコンポーネントのドキュメントに直接組み込み、スプリントの終わりに引っ張り出す別のチェックリストにはしない。そしてバージョン管理と変更履歴があり、チームが自分の見ているものが最新版か、数カ月前に廃止されたものかを推測する必要がない。
デザインとエンジニアリングの間のギャップの多くは、実は引き継ぎのまさにその瞬間から形成され始める。デザイナーがFigmaでコンポーネントを指定し、エンジニアがそれをコードで実装する。この2つの成果物の間のどこかで、ある値がハードコーディングされ、ある間隔トークンが近似値で処理され、ある色がトークンを参照する代わりに16進数値としてそのまま入力される。これらはどれも意図的なものではなく、2つの異なるツール、2つの異なるメンタルモデル、そして公開前にすべての細部を現実的にチェックしきれないレビュープロセスから生まれる自然な結果だ。デザイントークンを共通言語として使うこと、Figmaでデザイナーが呼ぶ名前とコードでエンジニアが呼ぶ名前を一致させること、コンプライアンスチェックを最後に付け足すのではなくワークフロー自体に組み込むこと——この3つが、このギャップを縮める最も直接的な方法だ。
もしあなたのチームがデザインシステムについて「何かがもうしっくりこない」と感じ始めているなら、まず確認すべきなのはコンポーネントライブラリを作り直すべきかどうかではなく、統治の層だ。システムの進化に明確に責任を持つオーナーがいるか、変更レビューのプロセスはチームが実際に待つ気になるほど速いか、ドキュメントは「何か」だけでなく「なぜか」を説明しているか、アクセシビリティ要件は後から付け足すのではなく最初からコンポーネントに組み込まれているか。こうした統治面の修正コストは、システムが誰からも信頼されなくなるほどドリフトしてしまい、システム全体を作り直さなければならなくなる日を待つよりも、はるかに低い。定期的な監査（大規模な手作業でのレビューである必要はなく、自動化されたコンプライアンスチェックの方がはるかに効率的だ）も、何か問題が起きてから慌てて発動するのではなく、プロセスの固定された一部にしておく価値がある。