DRY原則
この技術でできること
- 「一箇所の修正だけで全体が変わる」デザインシステムを構築できる
- 画面ごとに微妙に違う余白や色（Hexコード）の増殖を防ぎ、UXの一貫性を保てる
- エンジニアが「前に作ったコード」を使い回せるようになり、開発スピードが加速する
例: Figma上で #007BFF というカラーコードを至る所にコピペして塗るのではなく、color-primary というデザイントークンとして定義する。ブランドカラーが変更された時、トークンを1つ編集するだけで全画面・全コードのボタンやリンクが一瞬で新しい色に切り替わる。
なぜ難しいか
「コピー＆ペースト」が、短期的には最も速い仕事の進め方だからです。
デザイナーもエンジニアも、急いでいる時は「前に作った似た画面をコピペして、少しだけ文字を変えよう」と考えます。これが続くと、システム内に「似ているが少しずつ違うコードとデザイン」が大量に存在することになります（WET: Write Everything Twice、同じことを何度も別々に書いてしまう状態）。結果として、「ヘッダーの角丸を変えるために、50個のファイルを一つずつ直す」という絶望的な保守作業が発生します。
デザイン時の判断ポイント（Before/After）
パターン: デザイントークンとスタイルの不在
Before（現実の悪い例）:
Figma上でコンポーネント化やスタイル登録をせず、ボタンAには border-radius: 4px、ボタンBには border-radius: 6px を手作業で設定する。エンジニアもそれを拾い上げ、愚直に別々のCSSとして実装する。
→ デザイン修正が起きた際、どこを直せばすべてに反映されるか（Single Source of Truth：信頼できる唯一の情報源）が存在せず、UIがちぐはぐになる。
After（現実的な整理）:
すべてに意味付け（トークン）を行い、ルールにない値の使用を禁止する。
size-radius-sm, size-radius-md など数種類の変数を作り、デザインとコードで完全に同期させる。
なぜ改善されるか（なぜ現実的か）: 「見た目」ではなく「意味」でルール化されるため。新しいデザインを作る時も「いちから数値を考える」必要がなくなり、既存のトークンを当てはめるだけで必然的にUIの統一感が担保されるからです。
代替手段: たまたま画面で必要な「1回限りの特殊なサイズ」については、無理にシステムに組み込まず、インラインで上書きすることを許容する。
アンチパターンと衝突（デザイナー × エンジニア）
❌ 「たまたま見た目が同じだから共通化してほしい」
デザイナーの視点: ログインの入力フォームの中身と、クレジットカード番号の入力フォームの中身が「見た目」として同じ。これらは1つの共通コンポーネントにまとめて再利用すべきだ。（品質＝見た目の同期と作業のショートカット） エンジニアの視点: 見た目は同じだが、入力される文字の入力チェック（バリデーション）も違えば、送信されるサーバーの用途も違う。これらを無理に一緒にすると、後で片方だけ変更したい時に複雑な条件分岐が必要になり破綻する。（品質＝ビジネスロジックの安全性）
なぜ衝突するか（品質の定義差）: デザイナーは「見た目の類似によるDRY」を求め、エンジニアは「ドメイン（ビジネス上の意味）の類似によるDRY」を重視しているため。
どう合意するか:
- 「見た目だけの共通枠（UIコンポーネント）」と「用途が縛られた機能（機能コンポーネント）」に分けて設計する。
- 「本当に二つは同じ理由・同じタイミングで変更されるか？」を問い、別々に変更される可能性があるなら、最初から独立させておく（WETを許容する）。
実践チェックリスト
最低ライン（Must）
[ ] デザインツール内で、色やフォントが単なる「値」ではなく「スタイル（トークン）」として登録されている [ ] 同じようなレイアウトやモジュールを、画面ごとにコピー＆ペーストで作らないルールがある
理想ライン（Better）
[ ] ドメイン（意味）が違うが「たまたま見た目が同じ」要素に対して、安易な共通化を避けている [ ] エンジニアと「Single Source of Truth（ただ1つの信頼できる情報源）」がどこにあるかを合意している
関連技術
前提となる技術
- YAGNI原則 — DRYを意識する前に、そもそも不要なものを作らない
次に学ぶ技術
- 関心の分離 — 共通化する前に「役割」を分ける考え方
まとめ
- この技術の本質: 知識と情報をただ一箇所に集約し、「変更漏れ」というバグを物理的に潰す
- UXへの影響: ボタンの位置や色が画面ごとで変わらないという「高い一貫性」がユーザーの安心感を生む
- 実務での判断軸: 「もしブランドカラーを変更することになった時、10秒で全画面に反映できる構造になっているか？」
- 次に学ぶべき技術: 関心の分離（SoC。繰り返さないのと同時に、役割をどう分けるかを学ぶ）
KISSが「複雑さを減らす」、YAGNIが「未来のために足さない」なら、DRYは「重複を一箇所に集約する」原則です。
目的別のおすすめ:
