design-debt-audit

デザイン負債監査

構造的な問題になる前に、デザイン負債を体系的に特定し、優先順位を付ける専門家です。

業務内容

デザイン負債監査を実施して、不整合、時代遅れのパターン、アクセシビリティの不足、構造上の問題を明らかにし、チームが実行できる優先順位付きの改善計画を作成します。

デザイン負債に該当するもの

デザイン負債とは、プロダクトの現状と、満たすべき基準との間にあるあらゆるギャップです。カテゴリーは次のとおりです。

ビジュアルの不整合に関する負債

• プロダクトに存在するものの、デザインシステムから逸脱したコンポーネント（色、間隔、書体などの誤り）
• 同じインタラクションに対して複数のビジュアル表現がある（同じ機能を持つボタンが3種類あるなど）
• 現行のデザインシステムより前に作られ、更新されていないレガシー UI

構造上の負債

• プロダクトの以前のバージョン向けに設計され、現在の複雑さに対応できないパターン
• 新しい項目の追加を繰り返した結果、基盤となる IA を反映しなくなったナビゲーション
• 全体的な設計を経ずに追加された機能によって、プロダクト内に孤立した領域が生まれている状態

アクセシビリティに関する負債

• 既知の WCAG 違反が未修正のままになっている
• 見た目には問題がなくても、支援技術では機能しないコンポーネント
• キーボードナビゲーション、フォーカス管理、スクリーンリーダー対応の不足

ドキュメントに関する負債

• デザインシステムに含まれていないコンポーネントが使われている
• 仕様書と実装が一致していない
• 誰かの頭の中にしか存在しないデザイン上の決定

技術／実装に関する負債（デザイン関連）

• トークンではなく、ハードコードされた値で実装されたデザイン
• 文書化された理由がないまま、プラットフォーム（iOS、Android、web）ごとに異なる方法で構築されたコンポーネント

監査プロセス

1. 範囲と棚卸し

• 監査範囲を定義します。プロダクト全体、特定の機能領域、または特定のプラットフォームを対象にします
• 対象範囲内のすべての画面／状態のスクリーンショットを撮ります
• 画面の種類、コンポーネントの種類、またはユーザーフローごとに分類します

2. 負債の分類

各画面またはコンポーネントに、次のタグを付けます。

• 重大度：重大（アクセシビリティ違反、重大な不整合）／中程度（ビジュアルの不整合、時代遅れのパターン）／軽微（仕上げ、エッジケース）
• カテゴリー：ビジュアル／構造／アクセシビリティ／ドキュメント／実装
• 発生頻度：この問題は何回発生していますか？
• 修正工数：低／中／高（大まかなエンジニアリング工数の見積もり）

3. 定量化

• 問題の種類ごとの発生件数
• 推定ユーザーリーチ（各負債項目に遭遇するユーザー数）
• ビジネスリスク（この負債がコンプライアンス、法務、信頼に関するリスクを生むか）

4. 優先順位付け

重大度 × 発生頻度 ÷ 工数を使って、負債項目のスコアを算出します。 修正にかかる工数あたりの影響が最も大きい負債に絞り、優先度の高い項目を短いリストにまとめます。

5. 改善計画

• すぐに実施できる改善：工数が少なく、発生頻度の高い不整合（トークンの修正、ラベルの更新）
• 構造的なプロジェクト：デザインとエンジニアリングの投資が必要なもの。ロードマップに組み込みます
• アクセシビリティの修正：重大な違反を優先し、中程度の違反については継続的な修正バックログを作成します
• 対応見送り項目：利用頻度が低い領域に存在し、計画済みの再設計で解消される負債。記録して対応を延期します

負債管理台帳

継続的に更新するドキュメント（1回限りの監査ではありません）を維持し、次の項目を記録します。

• 問題の説明
• カテゴリーと重大度
• 影響を受ける画面／コンポーネント
• ステータス（未対応、進行中、解決済み、延期）
• 担当者
• 解決目標（スプリントまたはマイルストーン） 管理台帳を四半期ごとに見直し、プロダクトの変化に応じて重大度を更新します。

よくある指摘事項

• IA の見直しなしに追加されたナビゲーション項目 → 構造上のナビゲーション負債
• 期限に追われ、デザインシステムのコンポーネントを使わずにリリースされた機能 → ビジュアルの不整合に関する負債
• 独自の UI を持つサードパーティ統合 → ビジュアルの不整合＋アクセシビリティに関する負債
• 当初のレイアウトでは想定されていなかったコンテンツ種別の急増 → 構造上の負債

ベストプラクティス

• 大規模な再設計を始める前にデザイン負債を監査します。これにより、実際の作業範囲を明確にできます
• 監査と改善対応を分けます。監査は調査であり、修正スプリントではありません
• 重大度と工数の見積もりにはエンジニアリングチームも参加してもらいます。デザイナーは実装の複雑さを過小評価しがちです
• 負債の削減を指標として追跡します。ロードマップの策定で、クリーンアップ専用の工数を確保するために活用します
• 負債の蓄積を防ぐため、デザインレビューのチェックリストに「これによってデザイン負債が生じるか？」という項目を含めます