DESIGN SYSTEM / SYSTEMS & ORGANIZATIONAL LEADERSHIP
コンポーネントではなく、その背後にあるOperating Modelまでリードした。
表面的な課題は、FigmaとProduction Componentの不一致でした。
しかし本質的な課題は組織にありました。DesignとEngineeringがどのように判断し、変更を評価し、実装し、Accessibilityを検証し、各TeamへReleaseするのかという共通Operating Modelが必要でした。
Figma、React Component、Design Token、Accessibility Standard、Engineering WorkflowをつなぐUX ArchitectureとGovernanceをリード。
Design SystemをComponent Libraryではなく、DesignとEngineeringをつなぐ共通Operating Modelとして設計。
重複実装と曖昧さを減らし、Contribution、QA、Releaseまでを含む再現可能な運用モデルを構築。
責任範囲は、UI Componentを作ることだけではなかった。
Figma、React Component、Design Token、Accessibility Standard、Engineering Workflowをつなぐ、スケーラブルなDesign SystemのUX ArchitectureとGovernanceをリードしました。
DesignとEngineeringがどのように意思決定し、Systemへ変更を加え、ImplementationをValidateし、各TeamへReleaseするかという運用まで設計しました。
私自身はArchitecture、Interaction / Component Rule、Design-system Pattern、Accessibility Expectation、Figma Alignment、Documentation、Validationを担当しました。
Product DesignerとEngineerはProduct Use Case、Technical Implementation、Feasibility、Platform-specific Requirementを担当しました。
Design Systemを、明確なOwnershipとDecision Ruleを持つ共通Operating Modelとして定義する。
- 複数のFileやLibraryではなく、一つのShared Productとして扱いやすくなった。
最も重要だったのは、Componentそのものの判断ではなかった。
Design Systemを「承認済みUI Library」として扱うのではなく、DesignとEngineeringをつなぐ共通Operating Modelとして構造化しました。
一貫性とProduct TeamのAutonomyを両立する必要がありました。
- Design Consistency
- Technical Feasibility
- Performance
- Accessibility
- Platform Constraints
- Long-term Maintenance
- Product-specific Requirements
共通化すべきDecisionはStandardizeし、正当なProduct-specific Variationには明確なPathを用意する。
- 硬直したSystemにも、例外だらけのLibraryにもならないGovernanceを構築。
DesignとEngineeringが、変更を一緒に評価する仕組みにした。
Product DesignerとEngineerと直接連携し、新しいComponentや変更を複数の観点から評価しました。
UX Need、Consistency、Accessibility、Feasibility、Performance、Platform Constraint、MaintenanceをImplementation前に検討しました。
DesignまたはEngineeringのどちらか一方だけをSystem DecisionのOwnerにしない。
- Shared Decision-making Processを構築。
- Technical Constraintをより早い段階で可視化。
- UX IntentをVisual Specificationだけで終わらせずImplementationへ反映。
ProposalからReleaseまでの変更プロセスを定義した。
Design Systemは、変更方法が分からなければスケールしません。
Design Assessment、Technical Assessment、Alignment、Implementation、QA、Releaseを一つのFlowとして整理しました。
- Design Assessment
- Engineering Assessment
- Cross-functional Alignment
- Implementation
- Accessibility / QA Review
- Documentation / Release
- 繰り返し使えるContribution Processを構築。
- Productionで不整合になる前にChangeを評価できるようになった。
Architectureだけで終わらず、Implementation・QA・Releaseまで関与した。
Foundational ArchitectureからImplementation、Storybook Validation、Accessibility Review、QA、Documentation、Versioning、Releaseまで継続して関与しました。
Recurring Cross-functional Reviewと定期的なFigma Releaseによって、Systemが進化する中でDesignとProductionのDriftを減らしました。
- Figma Component Update
- React Implementation
- Storybook Validation
- Accessibility Review
- Design QA
- Documentation
- Release / Versioning
- Design IntentとRunning Codeを同じ場でReviewできるようになった。
- AccessibilityとInteraction StateをImplementation Validationに含めた。
価値は、曖昧さ・重複・同じ意思決定の繰り返しを減らしたこと。
Reusable FoundationによってPrototypingとProduct Developmentを加速しながら、Implementationの一貫性を高めました。
またGovernanceによって、すべてのDecisionをCentral Teamへ集約せずにSystemを成長させられる基盤を作りました。
- Duplicate Component Implementationを削減。
- DesignとEngineering間の曖昧さを低減。
- Prototype・Feature DevelopmentでのReuseを促進。
- QA・Accessibility Expectationの一貫性を向上。
- OnboardingとContribution Pathを明確化。
- Product-team Autonomyを維持できるScalable Governanceを構築。
次の成熟段階は、Design System自体をProductとして計測すること。
現在説明できるImpactは定性的なものが中心です。Portfolioを強く見せるために存在しない数値を作るべきではありません。
次の段階ではDesign-system AdoptionとDevelopment Efficiencyを計測し、Business Valueを定量化します。
- Systemを利用するProduct Team数。
- Component Adoption Rate。
- 削減したDuplicate Component数。
- Design-to-development Turnaround。
- Accessibility Defect Rate。
- Contribution / Release Cycle Time。
- Prototype / Implementationで削減した時間。
Design-system PerformanceをProduct Performanceとして計測する。
- 将来のInvestmentをQualitative FeedbackだけでなくEvidenceで説明できる。
JAPAN / U.S. TEAM LENS
Global Design Systemには、異なる意思決定文化でも機能するGovernanceが必要。
すべての日本企業・米国企業が同じように働くという意味ではなく、Operating Modelを設計する際の観点です。
日本の組織では、Decision Rationaleや履歴を明文化し、Consensusを可視化することが有効な場合がある。
米国型Product Organizationでは、明確なOwnership、Rapid Contribution、Decentralized Decision-makingが重視される場合が多い。
Global Systemでは、SpeedのためのOwnershipと、Collective AlignmentのためのDocumentation・Transparencyの両方が必要。
WHAT THIS PROJECT DEMONSTRATES
Design Systemは、Componentとして表現された組織システム。
Componentは目に見えるLayerにすぎません。
本当のDesign WorkにはArchitecture、Governance、Ownership、Contribution、Accessibility、Technical Alignment、そして安全にSystemを変更できる仕組みが含まれます。
強いDesign Systemは意思決定をなくすのではない。同じ意思決定を何度もする必要をなくす。