運用
部品を作ったところで、システムは始まっていません。使われているかどうかを数えて、初めて始まります。
図の中身を文字で読む
- 形骸化する経路
- 急ぎの案件で個別に実装する
- システム外の実装が増える
- 参照されなく
- なる
- デザイン負債
- が蓄積する
- 起点は「手続きが不明で、聞く相手も分からない」こと。技術ではなく運用の問題。
- 運用で決めておくこと
- 誰が承認するか どこに出すか 何を基準に通すか どう廃止するか
- 判断者を1人に決める 申請の手順と回答の目安 何箇所で使うか、代替はないか 移行期間と削除の時期
- 健康状態は「完成度」ではなく「導入率」で測る
- ボタン実装のうちシステム経由の割合／トークンを経由しない色指定の件数／使われていない部品の数。数えれば改善が測れる。
ひと目で#
- デザインシステム
- 部品、トークン、指針、運用体制をまとめた仕組み。部品だけでは足りない
- スタイルガイド
- 見た目の規則を書いた文書。動く部品を伴わない
- ガバナンス
- 何を足し、変え、廃止するかを決める手続き
- 導入率
- 実際にどれだけ使われているか。システムの健康はこれで測る
- 唯一の情報源
- 正しい値を持つ場所を1つに定めること
- デザイン負債
- その場の判断が積み重なり、あとの変更を難しくしている状態
使い分け#
図の中身を文字で読む
- 「部品が使われない」と気づいたところから、道が二つに分かれる
- ✕ 承認を厳しくする
- 導入率が上がらない 野良実装が減らない レビューで差し戻す回数を増やす システムの外へ逃げる
- ○ 部品の側に原因を探す
- 見つからない／足りない／使いにくい 使うほうが速くなる
- 使わない理由は、たいてい使う人ではなく部品の側にある。まず1人に聞き取り、詰まった箇所を直す。
- 月1回、この3つだけ数える
- システム経由のボタン実装 62% 先月 54%
- トークンを通さない色指定 41件 先月 68件
- 半年間使われていない部品 3件 先月 3件
- 数字は評価のためではなく、直した効果が見えるようにするために取る。件数は例。
| こう感じたら | 見るところ |
|---|---|
| 部品を作ったのに使われない | 導入率。原因はほぼシステムの側にある |
| 実装とデザインファイルが食い違う | 唯一の情報源。どちらが正かを決める |
| 急ぎのたびに個別の実装が増える | ガバナンス。申請と回答の手順が見えていない |
| ボタンが7種類ある | デザイン負債。まず数えて見えるようにする |
| 使われない部品が残っている | 廃止の手順が決まっていない |
間違えやすいところ#
- 部品を作っただけでシステムと呼ぶ指針と運用がなければ、形だけになる
- 承認を厳しくして品質を保とうとするシステムの外の実装が増えるだけ
- 導入率を強制で上げる使いにくさが残ったままなら、形式的な採用で終わる
- 完成度を上げれば使われると考える見つけやすさと使いやすさのほうが効く
- 廃止の手順を決めない使われない部品が残り、選ぶたびに迷う
- 既製のシステムをそのまま出す差別化が失われる。トークンの差し替えが最低限
- 1つのプロジェクトに複数のシステムを混ぜる設計の考え方がぶつかる
決めておく4項目#
| 項目 | 内容 |
|---|---|
| 判断者 | 誰が承認するか |
| 手順 | どこに、どう出すか。回答までの目安 |
| 基準 | 何か所で使うか。既存で代わりが利かないか |
| 廃止 | 移行の期間と削除の時期。破壊的な変更の知らせ方 |
測り方#
数えれば、改善が測れます。数える対象は3つで足ります。
| 数えるもの | 数え方 |
|---|---|
| システム経由の割合 | 部品を使った実装 ÷ 同じ役割の実装すべて |
| トークンを通さない指定 | 部品の CSS に残った色コードと固定 px の件数 |
| 使われていない部品 | 半年のあいだ参照が0だったものの数 |
周期は月1回、数え方は毎回同じにします。数字が動いたかどうかだけを見て、次にどこへ手を入れるかを決めます。決定の経緯まで公開している例として、実物のデザインシステムに挙げた GitLab の Pajamas が読みやすい入口です。
直す例#
架空の案件を1つ例にとります。どこを見て、何をどう直すかを書きます。
例として、半年かけて部品を20個そろえたのに、新しい画面のコードを見ると、その多くが独自の実装でした。作った側からは「使ってくれない」と見えます。書いた本人に1人だけ聞いてみると、答えは「探すのに5分かかったから、自分で書いたほうが速かった」でした。
ここで承認を厳しくすると、逆に進みます。レビューで差し戻す回数を増やしても、締め切りは動きません。システムの外で実装されるだけです。直すのは部品の側です。この案件では、置き場所を1ページにまとめ、部品名を実装で使う名前と一致させ、コピーできるコードを各部品の先頭に置きました。翌月の計測で、システム経由の実装は 54% から 62% に動きました。
数え方は3つだけにします。システム経由の実装の割合、トークンを通さない色指定の件数、半年使われていない部品の数。毎月同じ数え方で記録すれば、直した効果が見えます。数字は評価のためではなく、次にどこへ手を入れるかを決めるために取ります。
そのうえで、追加・命名・廃止・違反対応の4つを先に決めておきます。下のシートは、その4つを1枚に収める形にしたものです。
確認する#
- 追加を断ったとき、代わりに何で作るかを必ず添えている
- 廃止予定の印と、乗り換え先が同時に書いてある
- 導入率の数字が、前回の計測と並べて比べられる形で残っている
この話が要る場面#
このページが答えになる、現場の困り事です。困り事の側から探すと、同じ場所に着きます。
使う人が見つけられていない。名前と置き場所と、直してほしいときの窓口を先に決める。
名前・置き場所・問い合わせ窓口を先に決める
例外の置き場所を決めておく。決めないと、例外が本体を侵食する。
このコードで動いている見本です
この場面のほかの困り事と、そのまま貼れる部品は同じものを同じに作るにまとめてある。逆引きには全188件。
運用ルールを書く#
部品とトークンがそろっても、裁き方が決まっていないと、システムの外の実装が増えていきます。追加・命名・廃止・違反対応の4つを、このシートで先に決めます。見本は架空のECの運用ルールです。
下書きの元を切り替えると、記入欄は選んだ内容に置き換わります。
空欄のテンプレは次のとおりです。4つの見出しはそのまま使い、中身だけ差し替えます。
# 運用ルール: （プロジェクト名）
作成: （日付） ／ 見直し: （周期）
判断者: （誰が承認するか。回答までの目安）
## 追加の裁き方
（受け付ける条件。何か所で使うか・既存で代わりが利くか・仕様が書けているか）
（受け付けないとき、何を添えて返すか）
## 命名の門番
（トークンを通さない指定を、どう見つけてどう差し戻すか）
（名前の付け方の正。参照してよい層はどこまでか）
## 廃止の手順
（廃止予定の知らせ方と、乗り換え先の示し方）
（移行期間の長さと、削除の時期）
## 違反を見つけたら
（何を数えて、どの周期で記録するか）
（件数が減らないとき、どこに原因を探すか）この道具は JavaScript で動きます。無効の場合は、下のテンプレを写して使ってください。
出典#
- デジタル庁デザインシステム
- Alla Kholmatova『Design Systems』