良いツールがあっても、進め方が決まるわけではありません
ドキュメントツール、Figmaライブラリ、コードのチェックは良いツールであり、デザインチームは使うべきです。とてもうまく使いこなしているチームもあります。しかしツールは、誰がルールのオーナーなのか、誰が変更をレビューするのか、締め切りと基準がぶつかったときにどうするのかを決めてはくれません。
5人のデザイナーが、合意した進め方のないまま一つのライブラリを共有すると、システムはすぐに崩れていきます。一人ひとりの判断はもっともでも、全体を見ている人がいません。数か月もすると、ライブラリはあるプロダクトを、コードは別のプロダクトを表すようになります。
これは関わった人たちの失敗ではありません。仕組みが欠けているのです。システムをどう運用するかを組織が決めていないため、同じ判断が、そのとき一番近くにいる人によって何度も繰り返されます。
デザインシステムはライブラリではありません。チームがどう働くかについての合意であり、常に最新に保たれるものです。
Loomは、運用の進め方に専用の場所を用意します
Loomの管理画面には、まさにこのための「Ops」スペースがあります。チームと役割、定例、一つのサポートキュー、オンボーディング、システムが発信するメッセージ、メンバーが抜けるときの対応をまとめています。中身はすべてリポジトリの記録から読み込まれ、変更はすべてレビュー済みのプルリクエストとして行われます。メッセージはオーナーが承認するための下書きです。
Opsの概要
実際の画面、サンプルの記録
すべての領域で、オーナーが明確に決まっています
最初に、システムのどの部分を誰が担うかを決めます。システムオーナー、領域ごとのオーナー、そしてデザイン、エンジニアリング、コンテンツ、アクセシビリティをまたぐ3〜7人の小さなギルドです。役割はそれぞれリポジトリの記録になるため、誰が何を決めるのかを誰でも確認できます。
3人以下のチームには、標準では定例会議を設けません。役割はチームの規模に合わせて増減します。チームを役割に合わせるのではありません。
# loom/owners.yaml (sample record)
system: Harbor UI
owner: Head of design
areas:
foundations: Design-system lead
components: Front-end lead
brand: Content design lead
guild: [Design-system lead, Front-end lead, Accessibility specialist, Content designer]
担当者のいない依頼をなくす
依頼、提案、例外は、すべて一つのレビューキューに入ります。各項目には、オーナー、期日、残りの営業日（または期日を何日過ぎているか）が表示されます。標準のサービスレベルは3営業日で、組織ごとに独自に設定できます。
これで会話が変わります。「誰か見てくれましたか？」ではなく、「担当は誰で、期日はいつか」という問いになります。
一つのサポートキュー
実際の画面、サンプルの記録
| 週 | 運用モデルあり | 道具だけ |
|---|---|---|
| 0 週目 · 11月5日（木） | 0 週目。まだ依頼はありません。木曜の議題は「話し合うことはない」です。 | 0 週目。まだ依頼はありません。 |
| 7 週目 · 12月24日（木） | 7 週目。基盤のオーナーは不在です。2 件のレビューが代理に移り、木曜の議題に載っています。 | 7 週目。8 件の依頼が、オーナーも期日もないまま記録されています。基盤のオーナーは不在で、誰が代わるのかはどこにも記録されていません。 |
| 11 週目 · 1月21日（木） | 11 週目。チェックアウトの例外は期限切れになりました。指摘は基盤のオーナーに戻り、改めて判断が必要です。 | 11 週目。9 件の依頼が、オーナーも期日もないまま記録されています。チェックアウトの例外には期限がないため、そのまま残り、誰も改めて判断を求められません。 |
| 13 週目 · 2月4日（木） | 13 週目。チェックアウトの例外は期限切れになりました。指摘は基盤のオーナーに戻り、改めて判断が必要です。 | 13 週目。10 件の依頼が、オーナーも期日もないまま記録されています。チェックアウトの例外には期限がないため、そのまま残り、誰も改めて判断を求められません。 |
インタラクティブ版を読み込めませんでした。表は 0、7、11、13 週目を示しています。
サンプルデータです。Harbor UI は架空のシステムで、役割は実在の人物ではありません。キュー、議題、期日、期限は Loom のガバナンスのコードが出した実際の結果です。道具だけの側は、同じ出来事をオーナー、サービスレベル、期限を記録せずに示しています。
定例は、その場しのぎではなく準備して臨みます
デザインシステムに必要な定例は多くありません。週次のトリアージ、リリースレビュー、四半期ごとの健全性の確認です。短く、準備されているときにうまく機能します。Loomは、キューと健全性の指標から毎回の議題を下書きし、カレンダーの招待とチーム向けのメッセージを用意します。
カレンダー上の定例
実際の画面、サンプルの記録
Slackのボットは構築済みです。出典つきで質問に答え、ニーズを登録し、例外の申請をオーナーに送り、議題の下書きをオーナーの承認に回します。
Weekly triage, drafted by Loom (sample)
1. Overdue: date range picker request (Components owner)
2. Due this week: color.text.danger proposal (Foundations owner)
3. Expiring in 14 days: raw colour in the checkout banner
4. Health: drift up 3 items since last week; adoption not measured
お知らせは、一つの記録から下書きする
リリースノート、移行のお知らせ、月次のダイジェスト、経営層向けの短いレポートは、同じ記録から下書きされるため、内容が食い違うことはありません。どれも、発信する前にオーナーが承認します。現在は、承認された文面をオーナーがコピーして使います。
コミュニケーションセンター
実際の画面、サンプルの記録
例外は認める。ただし、必ず期限を設ける
実際のプロダクトには例外が必要です。問題は、誰も決めないまま例外が恒久化してしまうことです。Loomでは、すべての例外にルール、理由、依頼者、承認者、そして最長90日後の期限を記録します。期限が来ると、課題はオーナーのもとに戻ってきます。
# loom/exceptions/checkout-banner.yaml (sample record)
rule: no-raw-colour
where: Checkout banner
reason: Campaign artwork, ends with the campaign
requested_by: Growth team
granted_by: Foundations owner
expires: 2026-11-08 # at most 90 days
意見の違いは、議論する前に測ります
デザイン、エンジニアリング、プロダクトは、同じシステムを違って見ていることがよくあります。どの見方も、ある程度は正しいのです。有料のディスカバリー（現状調査）では、それぞれの職種がチームアンケートで同じ質問に答えます。回答は回答者のブラウザの中で暗号化され、5人未満のグループの結果を単独で表示することはありません。見方が異なる点がわかるので、根拠をもとに話し合いを始められます。
システムオーナーは、全体像を見渡せます
オーナーが最初に見る画面には、定着、乖離（ドリフト）、フロー、品質の4つの指標グループが表示されます。データ源のない指標は、推測せずに「未計測」と表示します。
乖離にはコストがあり、見積もることができます
誰も手入れしないシステムにも、お金はかかり続けます。二度手間の作業、取り残されていくプロダクト、そして修理に1週間を費やす小さなチームです。公開されている根拠と、自社の数字で試せる計算ツールを、「乖離のコスト」のページ（英語）にまとめています。
リーダーの方へ
デザイン組織を率いているなら、デザインシステムを、チームが頼りにするサービスとして扱うことをおすすめします。オーナー、サービスレベル、予算を伴うサービスです。予算を出す立場なら、何が入っているかだけでなく、どう運用されているかも確認してみてください。ツールは大切です。進め方は、それ以上に大切です。
道具は、組織が決めたことを実行するためにあります。私たちは、その決定を組織が下し、守り続けられるよう支援します。
今後の予定
- お客様の記録でのOpsスペース。 お客様自身の記録で動き、オーナーが承認したメッセージを送信するようになります。
- 定例をワークスペースで。 Slackのボットが実際のワークスペースで動き、オーナーが承認した議題を投稿するようになります。Teamsにも順次対応します。
- 実際のチームでのアンケート。 実際のチームから回答を集めるようになります。これまでは合成した回答で動かしており、回収は手作業です。
よくある質問
コンサルティングですか、それともプロダクトですか？
両方です。私たちの専門家が、チームと一緒に運用の進め方を整えます。Loomはそれをリポジトリの記録として残し、その周りの定型作業を担います。
いまのツールを変える必要はありますか？
いいえ。Loomは、リポジトリ、Figma、そしてお使いであればドキュメントツールなど、すでにあるツールと連携します。
小さなチームには負担が大きくありませんか？
いいえ。すべての変更は、提案、レビュー、承認、リリースという同じ4つのステップで進みます。3人以下のチームには、標準では定例会議を設けません。