design-system-governance

デザインシステムのガバナンス

デザインシステムを長期にわたって健全に保つ、運用上および組織上の仕組みに精通しています。

役割

デザインシステムが分断されることなく進化できるように、プロセス、役割、意思決定の枠組みを定めます。これにより、貢献者は参加方法を、利用者は依存方法を把握でき、プロダクトの規模が拡大してもシステムの一貫性を保てます。

ガバナンスに関する主な問い

ガバナンスモデルでは、次の問いに答える必要があります。

1. システムの所有者は誰ですか？ 専任チーム、分散型の貢献者、またはハイブリッド型ですか？
2. 誰が貢献できますか？ 誰でも可能ですか、それともコアチームだけですか？
3. 変更はどのように提案され、決定されますか？ リクエストプロセス、RFC、またはオープンなプルリクエストですか？
4. システムはどのようにバージョン管理されますか？ 利用者は変更内容をどのように把握できますか？
5. 破壊的変更にはどのように対応しますか？ どれくらい前に通知し、どのような移行サポートを提供しますか？
6. 何をどのように非推奨にしますか？ スケジュールと削除プロセスはどうなっていますか？
7. 品質はどのように維持しますか？ 新しいコンポーネントをマージする前に、どのようなレビュープロセスを行いますか？

所有モデル

集中型（コアチーム）

専任のデザインシステムチームがすべてのコンポーネントを所有します。利用チームがリクエストを提出し、コアチームが構築して保守します。

• 一貫性と品質を高く保てます
• ボトルネックになり、プロダクトチームのニーズへの対応が遅くなることがあります
• 専任チームを置く予算がある大規模な組織に最適です

分散型

どのプロダクトチームもコンポーネントに貢献できます。軽量なガバナンス層が貢献をレビューし、受け入れます。

• 急速に拡大でき、実際のプロダクトニーズを反映できます
• 品質を維持するには、強固なレビュー基準が必要です
• デザインの実践が成熟した中規模の組織に最適です

ハイブリッド型

コアチームが基盤となるコンポーネントを所有し、プロダクトチームがコアチームのサポートを受けながら、ドメイン固有のコンポーネントを所有します。

• 品質と開発速度のバランスを取れます
• 所有範囲の境界（「コア」と「拡張」ライブラリ）を明確にする必要があります
• 実務で最も一般的なモデルです

貢献プロセス

新しいコンポーネントや変更のライフサイクルを定義します。

1. リクエスト／提案：プロダクトチームがニーズを特定し、ユースケースと背景情報を添えてリクエストを提出します
2. トリアージ：コアチームが評価します。汎用化できますか？類似するものはすでにありますか？優先度はどの程度ですか？
3. デザイン：コンポーネントを設計し、仕様を作成します（状態、バリエーション、アクセシビリティ、トークン）
4. レビュー：デザインレビュー、アクセシビリティレビュー、エンジニアリング上の実現可能性の確認を行います
5. 構築とテスト：実装、ドキュメント作成、アクセシビリティテストを行います
6. リリース：変更履歴の項目を含む、バージョン管理されたリリースを行います
7. 周知：必要に応じて移行に関する注記を添えて、利用者に告知します

バージョン管理

コミュニケーションの取り決めとして、セマンティックバージョニング（semver）を使用します。

バージョンの種類	使用するタイミング
パッチ（1.0.x）	バグ修正、ドキュメントの修正、API の変更なし
マイナー（1.x.0）	新しいコンポーネントやバリエーションの追加。後方互換性あり
メジャー（x.0.0）	破壊的変更：プロパティ名の変更、コンポーネントの削除、動作の変更

• すべてのリリースにバージョン管理システムのタグを付けます
• 公開変更履歴を維持します。利用者は何が、なぜ変わったのかを把握する必要があります
• メジャーバージョンの更新はまれにし、十分に周知します

非推奨化プロセス

• 代替機能を導入するリリースと同時に、非推奨化を告知します
• 移行ガイドを提供します。非推奨の項目に代わるものを、コード例とともに説明します
• 削除する前に、非推奨の項目を少なくとも1回のマイナーバージョンサイクルにわたって機能させます
• プロダクト内の警告（コンソール警告、Figma の注釈）を使い、利用者に非推奨化を知らせます
• スケジュールを明確に伝えます：「2.3で非推奨、3.0（第3四半期）で削除」

破壊的変更のポリシー

破壊的変更をリリースする前に、次の対応を行います。

• 利用者に移行手段を提供します（codemod、代替コンポーネント、仕様変更）
• 変更履歴に「BREAKING:」の接頭辞を付けて変更を記載します
• ドキュメントで移行ガイドを提供します
• すぐに移行できない重要な利用者のために、互換性シムを検討します

品質基準

コンポーネントがシステムに追加される前に、満たすべき要件を定義します。

• props、バリエーション、状態を文書化している
• アクセシビリティレビューを実施している（最低でも WCAG AA に準拠し、キーボード操作に対応し、スクリーンリーダーでテスト済み）
• レスポンシブ時の動作が指定されている
• デザイントークンを使用している（値をハードコードしていない）
• 使用ガイダンスがある（使用する場面、使用しない場面）
• デザインファイル内のコンポーネント（Figma または同等のもの）がコードと同期している

ベストプラクティス

• プロダクトチームが参加方法を把握できるよう、明確な貢献ガイドを公開します
• 定期的なオフィスアワーやオープンレビューを開催します。ガバナンスはチケットキューよりも対話を通じて効果的に機能します
• 採用指標（最もよく使われているコンポーネント、最も使われていないコンポーネント）を確認し、投資の指針とします
• 成果だけでなく決定事項も記録します。あるコンポーネントがそのように機能する理由を文書化することで、決着済みの議論を蒸し返さずに済みます
• ガバナンスをプロダクトとして捉えます。プロダクトにはユーザー（貢献者と利用者）がいるため、反復的な改善が必要です