段階1：一つのチーム
- 形
- 一つのプロダクトチームがシステムを作り、使っています。
- 決めるべき役割
- システムオーナーと、デザイン・エンジニアリング・アクセシビリティを分担する3人のギルド。
- 始める定例
- 週次トリアージと月次のヘルスレビュー。
- 次に起こりがちな問題
- 一人がすべてを抱えてしまう。
- 私たちが始めること
- 2週間のクイック監査。どの場合でも、レポート、ロードマップ、基準値が残ります。
いまの組織の位置から始めましょう。
デザインシステムの運用がどう成長するかについての、私たちの作業モデルです。人数は目安です。
二つの質問に答えると、今の位置と、私たちがどこから始めるかが表示されます。
段階2：複数のチーム
- 形
- コアチームが複数のプロダクトチームを支え、コントリビューションが始まっています。
- 決めるべき役割
- 領域ごとのオーナー、兼任のOpsリード、サポート当番。
- 始める定例
- 週次トリアージに、オフィスアワーとリリースレビューを追加。
- 次に起こりがちな問題
- サポート対応でコアチームが手一杯になる。
- 私たちが始めること
- 2週間のクイック監査。どの場合でも、レポート、ロードマップ、基準値が残ります。
段階3：複数のプロダクト
- 形
- 小さなコア、領域ごとのオーナー、プロダクトのレイヤー。
- 決めるべき役割
- 5〜7人のギルド、専任のOpsリード、指名されたスポンサー。
- 始める定例
- 週次トリアージに、四半期ロードマップとチーム横断の協議会を追加。
- 次に起こりがちな問題
- プロダクトごとにずれが生じ、重複が増える。
- 私たちが始めること
- 2〜4週間のディスカバリーとガバナンス設計。どの場合でも、運用モデルがリポジトリの記録として残ります。
段階4：複数の組織
- 形
- ブランドや地域ごとのレイヤーに、それぞれのオーナーがいます。
- 決めるべき役割
- レイヤーのオーナー、地域ごとのギルド、チームを持つOpsリード。
- 始める定例
- レイヤーごとの協議会と、四半期のリーダーシップレビュー。
- 次に起こりがちな問題
- レイヤーが分岐し、経営層が全体像を見失う。
- 私たちが始めること
- 2〜4週間のディスカバリーとガバナンス設計。どの場合でも、運用モデルがリポジトリの記録として残ります。
5人未満の場合
私たちの支援は5人以上のチームが対象です。無料のヘルスチェックと、オープンソースのデザインシステムLoom Baseをお使いください。