デザイン負債監査完全ガイド｜UI・UXの問題を可視化し、優先順位を付けて改善する方法

長期間運用されているデジタル製品では、最初から意図的に不統一な画面を作っているわけではなくても、機能追加、組織変更、納期優先の改修、ブランド刷新、担当者交代、技術移行などが積み重なることで、少しずつデザイン上の不整合が生まれます。同じ役割のボタンなのに高さが違う、似た意味の色が複数登録されている、設定画面だけ古いナビゲーションを使っている、あるフォームではエラー表示が丁寧なのに別のフォームでは技術的な文言しか表示されない、といった小さな差異が代表例です。一つひとつは致命的な問題に見えなくても、製品全体へ広がるとユーザーの学習負担が増え、チーム側では修正箇所や判断基準が増えるため、開発速度と品質の両方を下げる原因になります。

デザイン負債監査では、こうした問題を感覚的に「古い」「統一されていない」と指摘するだけではなく、どこに、どの種類の問題が、どれだけ存在し、何を原因として発生しているのかを体系的に確認します。画面の見た目だけではなく、コンポーネント、デザイントークン、文言、ナビゲーション、情報構造、アクセシビリティ、デザインファイル、実装コード、ドキュメント、レビュー方法まで対象にすることで、表面的な症状だけではなく、負債を生み続けている構造そのものを見つけることができます。

さらに重要なのは、監査結果を大量のスクリーンショットや問題一覧として残して終わらせないことです。ユーザーへの影響、利用頻度、影響する画面数、修正コスト、再発可能性などを評価し、改善バックログへ変換することで、監査結果を実際の製品開発へ接続できます。デザイン負債監査は、過去の問題を批判する活動ではなく、今後の製品品質を安定させるために現状を正確に理解する活動として進める必要があります。

1. デザイン負債を製品全体の構造から捉える

デザイン負債監査を始めるとき、特定画面だけを見て「この余白が違う」「この色が古い」と指摘する方法では、問題の根本原因を十分に把握できません。同じ不整合が20画面に存在していたとしても、その原因が一つの古い共通コンポーネントであれば、20画面を個別修正するより共通部品を修正した方が効率的です。反対に、見た目は似ていても業務要件が異なる場合は、無理に統一すると使いにくくなる可能性があります。そのため監査では、画面、コンポーネント、トークン、実装、運用ルールを複数階層で確認し、どの階層に原因があるのかを判断する必要があります。

また、デザイン負債は「見た目が古い」という意味だけではありません。操作方法が画面ごとに異なる、同じ用語が複数名称で表示される、アクセシビリティ対応がコンポーネントによって違う、デザインファイルと実装コードで仕様が一致していない、廃止した部品がまだ利用されているといった問題も含まれます。製品全体を一つのシステムとして捉え、ユーザー体験と制作・開発プロセスの両方に存在する不整合を確認することが、質の高い監査につながります。

1.1 視覚的不整合を発生場所と役割で記録する

同じ役割を持つボタンでも、ある画面では高さ40ピクセル、別の画面では44ピクセル、さらに別の画面では独自の角丸や影が付いているという状態は、長期運用製品でよく発生します。こうした違いを単純に「ボタンが不統一」と記録するだけでは、修正方法を判断できません。主要操作なのか補助操作なのか、どの画面群に存在するのか、公式コンポーネントを利用しているのか、独自実装なのかを合わせて記録することで、その差異が必要なものなのか、偶然生まれたものなのかを判断しやすくなります。

視覚的不整合を監査するときは、色、余白、文字サイズ、角丸、境界線、影、アイコン位置などを細かく見るだけでなく、その違いがユーザーの理解にどの程度影響するかまで確認することが重要です。例えばカードの角丸が2ピクセル違うだけなら優先度は低いかもしれませんが、主要ボタンと危険操作ボタンの見分けが付きにくい場合は誤操作につながります。見た目の差をすべて同じ重要度で扱うのではなく、意味と操作への影響を含めて評価することで、監査結果を改善判断へつなげやすくなります。

1.2 操作方法の不整合を実際のフローから確認する

デザインファイルの静止画だけを確認していると、見た目が同じ部品でも動作が異なる問題を見逃します。例えば同じ「保存」というラベルでも、ある画面では押した瞬間に保存され、別の画面では確認画面が表示され、さらに別の画面では保存後にページ全体が閉じるといった差が存在する場合があります。ユーザーは見た目と名称から動作を予測するため、同じ表現が異なる結果を生む状態は学習負担を高め、誤操作を起こしやすくします。

そのため監査では、登録、検索、編集、削除、購入、設定変更など主要な利用フローを実際に操作し、押下後の動作、読み込み中表示、完了通知、エラー表示、戻る位置なども確認します。操作上の違いが業務上必要な差なのか、それとも各チームが別々に実装した結果なのかを確認し、共通化できる動作パターンを見つけます。視覚監査と操作監査を組み合わせることで、ユーザーが実際に感じる不整合をより正確に捉えることができます。

1.3 実装上の重複をUI品質の問題として扱う

ユーザーから見れば同じ見た目に見えていても、コード内部では似たボタンが5種類、モーダルが4種類、入力欄が3種類実装されていることがあります。現在の画面だけを見れば問題がなくても、それぞれが別コードとして存在していると、一つの不具合修正やアクセシビリティ改善をすべての部品へ反映しなければなりません。一部だけ更新されると、時間の経過とともにユーザーから見える差異へ発展します。

このためデザイン負債監査では、コード上の重複も将来的なデザイン品質を不安定にする原因として記録します。同じ目的を持つ実装が複数ある場合、利用箇所、機能差、状態差を比較し、共通部品へ統合可能かを確認します。単純にコード量を減らすことが目的ではなく、将来一か所を改善すれば関連画面全体へ反映できる構造を作ることが重要です。

1.4 未使用資産と廃止済みパターンを確認する

デザインライブラリやコードベースには、現在どの画面でも利用されていない古いコンポーネントやトークンが残っている場合があります。使用されていないから害がないように見えますが、新しく参加したメンバーが古い部品を正式な選択肢だと判断して再利用すると、負債が再び製品へ戻る可能性があります。選択肢が増えることで、どれを使うべきか判断する時間も増えます。

監査では、現在利用されている資産だけではなく、登録されているが使用されていない部品、廃止予定なのに資料へ残っているパターン、過去のブランド色、旧アイコンなども確認します。削除が難しい場合は「廃止予定」「新規利用禁止」と明示し、移行先を示すことで再利用を防ぎます。負債監査には、増えすぎた選択肢を減らし、チームが迷わず正しい設計を選べる状態を作る役割もあります。

1.5 負債の原因を個人ではなく仕組みから分析する

デザイン負債が見つかったとき、「誰がこの画面を作ったのか」という方向へ議論が進むと、監査は改善活動ではなく責任追及になってしまいます。実際には、多くの負債は短い納期、デザインシステム不足、古い技術制約、複数チーム間の連携不足などから生まれます。当時の条件では合理的だった判断が、その後の製品拡大によって負債へ変わることもあります。

そのため監査では、個別のミスより「なぜ同じ問題が繰り返し発生したのか」を確認します。独自コンポーネントが多いなら、既存部品では要件を満たせなかったのかもしれません。直接色指定が多いなら、必要な意味トークンが不足していた可能性があります。原因を仕組みとして理解すれば、過去の問題を修正するだけでなく、新しい負債が生まれる条件そのものを変えられます。

2. 監査対象を明確にして調査範囲を制御する

大規模な製品では、画面数、コンポーネント数、状態数が非常に多いため、すべてを同じ深さで確認しようとすると監査期間が長くなり、結果が完成する前に製品側が変化してしまいます。監査を実務につなげるためには、最初に対象範囲を明確にし、どこを詳しく調べ、どこを今回は対象外とするのかを決めることが重要です。対象を絞ることは品質を妥協することではなく、改善可能な単位で問題を把握するための方法です。

特に利用者数、利用頻度、事業上の重要度、既知の問題件数などを利用して対象範囲を決めると、監査結果から大きな改善効果を得やすくなります。最初に影響の大きい領域を監査し、その後別領域へ広げる段階的な方法なら、監査結果を早い段階から改善へ反映できます。

2.1 主要ユーザーフローを優先する

ログイン、会員登録、検索、購入、申請、顧客登録、レポート作成など、製品価値へ直接つながるフローは優先的な監査対象になります。利用者が頻繁に通過する画面に負債がある場合、小さな問題でも多数の利用者へ継続的な負担を与えます。反対に、ほとんど利用されない管理機能の細かな視覚差を先に直しても、ユーザー体験全体への効果は限定的です。

主要フローを選ぶ際には、アクセス数だけではなく、途中離脱率、問い合わせ件数、誤操作件数なども利用できます。例えば利用頻度が中程度でも、問い合わせが集中している画面は監査価値が高い可能性があります。実際の利用データとデザイン監査を組み合わせることで、「目立つ問題」ではなく「影響の大きい問題」から確認できます。

2.2 プラットフォームごとの差を確認する

Web、iOS、Androidなど複数環境で同じ製品を提供している場合、プラットフォームごとに自然な操作慣習が異なります。そのためすべてを完全に同じ見た目へ統一する必要はありません。しかし機能名称、情報階層、主要操作の意味まで異なると、複数端末を利用するユーザーにとって学習負担が大きくなります。

監査では、プラットフォーム固有の差と不要な差を分けて記録します。例えばナビゲーション位置が異なることは自然でも、同じ機能がWebでは「保存」、モバイルでは「確定」と呼ばれているなら用語統一を検討できます。プラットフォーム差を理由にすべての不整合を許容せず、共通すべき意味と固有に最適化すべき操作を整理することが重要です。

2.3 新旧画面が混在する境界を特定する

長期間運用されている製品では、新しいデザインシステムを利用する画面と、それ以前の独自設計画面が混在することがあります。この状態では、古い画面だけが異なる余白やナビゲーションを持ち、ユーザーが画面移動時に別製品へ移動したような印象を受ける場合があります。

監査時には、画面ごとに利用しているコンポーネント世代や制作時期を記録すると、負債の分布を理解しやすくなります。問題が特定の世代に集中しているなら、個別修正より「旧画面群を新システムへ移行する」というまとまった改善計画を立てられます。画面単位ではなく世代単位で見ることによって、より効率的な移行戦略を作ることができます。

2.4 管理画面と利用者向け画面を別基準で見る

社内管理画面と一般利用者向け画面では、求められる情報密度や操作速度が異なります。管理画面では一画面に多数のデータを表示することが必要な場合がある一方、一般利用者向け画面では理解しやすさや段階的な情報提示がより重要になる場合があります。同じ評価基準だけで両方を判断すると、本来必要な差まで負債として扱ってしまう可能性があります。

そのため対象領域ごとに、重要となる評価軸を調整します。ただしアクセシビリティ、用語統一、共通コンポーネントの状態、色の意味など、製品全体で共有すべき品質は横断的に確認します。領域固有要件と製品共通ルールを分けることで、過剰な統一を避けながら一貫性を維持できます。

2.5 対象外領域を明示して次回監査へ残す

今回の監査で確認しない領域を明確にしておくことも重要です。例えば本体アプリは対象だが、マーケティングサイト、メール通知、管理者専用画面は次回監査とする、といった形です。対象外が明記されていないと、監査資料を見た人が「製品全体に問題がない」と誤解する可能性があります。

また対象外一覧は、次回監査の候補として利用できます。一度の巨大な監査で全製品を確認するより、四半期ごとに領域を分けて確認した方が、監査結果を新鮮な状態で改善へつなげやすくなります。監査範囲を管理すること自体が、デザイン負債監査を継続可能な活動へするための重要な設計です。

3. デザイン資産を棚卸しして重複と欠落を可視化する

デザイン負債を正確に把握するためには、現在製品で利用されているデザイン資産を一覧化する必要があります。公式デザインシステムに登録されている部品だけを見ても、実際の製品にはそこに存在しない独自コンポーネントが使われている可能性があります。逆にデザインライブラリには存在するものの、実装側では既に利用されていない部品もあります。

そのため棚卸しでは、デザインファイル、実際の製品画面、コードの三つを比較します。「正式仕様」と「実際に使われているもの」の差を見ることで、デザイン負債がどこから発生しているのかを理解しやすくなります。

3.1 ボタンを役割と状態ごとに一覧化する

ボタンはほぼすべての製品で繰り返し利用されるため、デザイン負債の状態を把握するのに適した部品です。まず、主要操作、補助操作、危険操作、文字リンク型、アイコン型など、実際の役割ごとに分類し、それぞれの高さ、横余白、文字サイズ、角丸、色、アイコン位置などを比較します。同じ「主要操作」という役割でありながら複数の高さや色、サイズが存在する場合は、共通部品が十分に利用されていない、あるいは過去の画面ごとに個別実装が積み重なっている可能性があります。

監査では、単純に画面上のボタンを数えるのではなく、「役割」と「見た目」の関係を整理することが重要です。特に、同じ目的で使われているボタンが異なるコンポーネントとして実装されていないか、逆に見た目は似ていても用途や優先度が異なるため本来は別のバリエーションとして定義すべきものが混在していないかを確認します。

通常状態だけではなく、ホバー、押下、フォーカス、無効、処理中などの状態まで確認することも重要です。通常表示は統一されていても、一部の独自ボタンだけフォーカス表示が存在しない、押下時のフィードバックが異なる、処理中にローディング表示へ切り替わった際にボタン幅が変化するといった問題が隠れている場合があります。また、状態によって文字色やコントラストが不足しているケースもあるため、見た目の一致だけでなく、操作可能性やアクセシビリティまで含めて確認する必要があります。

このように、ボタンを一つの静止画としてではなく、**「役割を持ち、複数の状態へ変化する操作単位」**として監査することで、実際の利用体験に近い評価ができます。さらに、発見した差異を単に「ボタンAとボタンBが違う」と記録するのではなく、「なぜ異なるボタンが存在するのか」「どのコンポーネントやトークンが原因なのか」まで追跡することで、個別の修正ではなく共通部品の統合や廃止ルールの整備といった根本的な改善につなげられます。

3.2 フォーム要素を入力状態まで含めて比較する

フォーム入力欄は、通常、通常状態、フォーカス、入力中、入力済み、エラー、成功、無効、読み取り専用など、多数の状態を持っています。さらに、ラベル、プレースホルダー、必須表示、補足文、エラーメッセージなどの周辺要素も含めて設計されるため、単純に入力欄の見た目だけを比較しても十分な監査にはなりません。画面ごとに独自実装されていると、エラー色や境界線、補足文の位置、ラベルの表示方法、メッセージの出現タイミングなどがばらばらになり、ユーザーは画面が変わるたびに異なる入力ルールを理解しなければならなくなります。

監査では、入力欄だけでなく、選択欄、チェックボックス、ラジオボタン、日付入力、検索欄、ファイルアップロードなども同じ観点で確認します。特に、各コンポーネントについて「どの状態が定義されているか」「状態ごとの見た目が統一されているか」「状態変化のタイミングが一致しているか」「補足情報やエラーメッセージの扱いが共通化されているか」を比較することが重要です。必須表示、補足文、エラー通知、入力例などの文章部分も含めて確認することで、視覚的な負債だけでなく、コンテンツ設計やアクセシビリティに関する負債も発見できます。

フォームは主要タスクの完了率や入力ミス、離脱率に直接影響するため、デザイン負債監査において優先度の高い対象です。特に、同じ入力操作でありながら画面によって異なるエラー表示や入力ルールが存在する場合は、単なる視覚的な不一致として扱わず、コンポーネント設計、デザイントークン、バリデーションロジック、文言管理などの根本原因まで確認する必要があります。

3.3 アイコンを意味と操作範囲から確認する

アイコンの負債は、単純に線幅や形が違うだけではありません。同じ「編集」という意味で複数のアイコンが使われていたり、同じ三点アイコンが画面によって異なる操作を開いたりすると、ユーザーは意味を予測しにくくなります。またアイコンだけのボタンでは、クリック領域が小さすぎる、読み上げ用ラベルがないなど別の問題も発生しやすくなります。

監査ではアイコン名、意味、利用場所、サイズ、クリック領域、補助ラベルを記録し、重複する表現を比較します。見た目が違っても意味が明確なら問題にならない場合もありますが、同じ意味で複数表現が混在している場合は統一候補になります。アイコンを装飾資産ではなく、情報伝達と操作を担う部品として扱うことが重要です。

3.4 カードとパネルの派生を役割から確認する

カードやパネルは新しい機能を追加するときにコピーされやすく、少しずつ異なる派生が増えやすい部品です。背景色、影、境界線、内部余白、タイトル位置、操作ボタン位置などが微妙に異なるカードが多数存在すると、デザインシステム側でもどれを正式パターンとするか分からなくなります。

監査では、カードを見た目だけで分類するのではなく、「情報一覧」「選択可能」「操作対象」「統計表示」など役割で分類します。同じ役割なのに異なる構造を持つものは統合候補になり、役割が明確に異なるなら正式なバリエーションとして残すことができます。必要な差と偶然生まれた差を分けることが、過度な共通化を避けるうえでも重要です。

3.5 空状態・読み込み・エラーも正式な画面状態として監査する

通常状態だけを棚卸しすると、ユーザーが実際に困りやすい場面が監査から抜けます。データが存在しない空状態、読み込み中、通信失敗、権限不足、検索結果なしなどは、製品利用中に必ず発生する重要な状態です。しかし新機能開発では通常画面が優先され、補助状態は各開発者が個別に実装している場合があります。

監査では、文章、アイコン、次の操作、余白、再試行方法などを横断的に比較します。空状態で「データがありません」とだけ表示される画面と、「最初の項目を作成する」操作まで提示される画面が混在しているなら、コンテンツ設計にも負債があります。補助状態を正式なデザインシステム対象として扱うことで、ユーザーが問題に遭遇したときの体験も一貫させられます。

4. デザイントークンの乱立と直接指定を監査する

デザイントークンを導入している製品でも、実際のコードに直接色や余白が大量に残っている場合があります。また長期間の運用で似た意味を持つトークンが追加され続け、「どれを使えばよいか分からない」状態になっていることもあります。トークンが存在すること自体ではなく、製品全体で一貫した役割を果たしているかを確認する必要があります。

監査では、値の種類だけでなく、トークン階層、命名、利用率、直接指定数、廃止状況まで確認します。値を単純に減らすことではなく、設計判断を少数の意味ある選択肢へ集約することが目的です。

4.1 色コードの直接指定を用途ごとに追跡する

CSSやスタイル定義へ#333333や#F5F5F5のような色コードが直接書かれている場合、将来ブランドカラーやテーマを変更するときに、すべての利用場所を個別に探す必要があります。さらに、同じ色が本文、境界線、背景など異なる意味で利用されている場合、単純な一括置換では意図しない画面まで変更される可能性があります。直接指定が増えるほど、変更範囲を予測することも難しくなり、デザインシステム全体の保守性が低下します。

そのため監査では、直接指定されている色を抽出した後、どのコンポーネントで、どの目的に使われているかを確認します。単純に「直接指定が何個あるか」を数えるだけではなく、同じ値がどのような役割で繰り返し使われているかを分類することが重要です。

本文色、境界線、補助背景など役割が明確になれば、それぞれを正式な意味トークンへ移行できます。重要なのは、単純に色コードの数を減らすことではありません。具体値への依存を減らし、「何のための色なのか」という意味ベースの参照へ変えることで、将来的なブランド変更やテーマ追加にも対応しやすい構造を作ることが目的です。

コード例：色コードを抽出する

grep -RhoE '#[0-9a-fA-F]{3,8}' src/ \  | sort \  | uniq -c \  | sort -nr

4.2 似たトークンの役割重複を確認する

gray-500、neutral-medium、text-mutedなど、名前は異なるのに同じ値を持つトークンが複数存在することがあります。一見すると不要な重複に見えますが、値が同じだからといって、必ず統合すべきとは限りません。現在は同じ値でも、本文補助色と境界線色では将来別々に変更する必要がある可能性があるためです。

監査では、まず同じ値を持つトークンを一覧化し、その後に名称、利用箇所、用途、変更意図を確認します。特に重要なのは「同じ値か」ではなく、「同じ意味を持っているか」という観点です。

同じ役割を持つトークンが複数存在するなら統合候補になりますが、異なる意味を持つものは、現在の値が同じでも分離したまま維持する方が将来変更しやすくなります。トークン監査では「数を減らす」ことを目的にするのではなく、「誰が見ても役割を判断できる状態」を作ることを優先する必要があります。

4.3 余白の任意値から設計規則の不足を探す

製品内に8、12、16、24といった共通余白スケールが存在しているにもかかわらず、13、19、27のような値が大量に使われている場合、チームが定義されたスケールを十分に利用できていない可能性があります。こうした任意値が増えると、画面間の微妙なズレが蓄積するだけでなく、新しい画面を作る際にも「どの値を使えばよいか」という判断が毎回必要になります。

ただし、スケール外の値をすべてルール違反として扱うべきではありません。例外値が頻繁に発生しているなら、既存のスケール自体が実際のレイアウト要件を十分に支えられていない可能性もあります。

監査では、スケール外の値を自動抽出し、実際の利用箇所と理由を確認します。単発の例外なら個別修正できますが、特定の値が多数利用されている場合は、無理に既存値へ置き換えるのではなく、正式なトークンとして追加する方が自然かもしれません。つまり、ルール違反を探すだけではなく、現在のルールそのものが現実の設計要件に合っているかを評価することも監査の重要な役割です。

4.4 トークン名と現在の意味が一致しているか確認する

ブランド変更やテーマ追加を繰り返すと、blue-primaryという名前なのに実際には紫色が設定されている、といった状態が生まれます。コード自体は正常に動作していても、名前と実際の意味が一致していなければ、デザイナーや開発者はそのトークンを正しく判断できません。特に新しいメンバーが既存コードを参照すると、名前から意味を推測して誤った用途に利用する可能性があります。

監査では、トークン名、現在の値、利用箇所、実際の用途を照合し、名前が現在の意味を正しく表しているか確認します。

具体色を名前へ含める方式から、「主要操作」「本文」「補助背景」「危険状態」など、用途や意味を表す名称へ移行できないかを検討します。命名変更は既存の利用箇所やコードへ影響するため、即時にすべてを変更するのではなく、旧トークンを非推奨化して新しい意味トークンへ段階的に移行する方法が現実的です。長期的には、テーマ変更やブランド展開が発生しても、トークン名そのものを変更せずに値だけを差し替えられる構造を目指します。

4.5 未使用トークンを廃止計画へ移す

使われていないトークンが大量に残っていると、デザイナーや開発者は現在有効な選択肢を判断しにくくなります。特に、古いトークンと新しいトークンが同じ一覧に並んでいると、どちらを使うべきかが明確にならず、新規画面で古いトークンが再利用される可能性があります。その結果、すでに減らしたはずのデザイン負債が別の場所で再発してしまいます。

監査では未使用トークンを単純に削除対象として扱うのではなく、利用状況や公開範囲を確認した上で、状態を分類します。

他製品や外部パッケージから利用されている可能性もあるため、単純に検索結果がゼロだから削除するのではなく、公開範囲や依存関係を確認してから移行します。最終的には、現在有効なトークン、移行中のトークン、廃止予定のトークンが明確に区別され、開発者が「どれを使うべきか」を迷わず判断できる状態にすることが重要です。未使用トークンの整理は単なるコードの掃除ではなく、新しい負債を生み出さないためのガバナンスとして位置づける必要があります。

5. コンポーネントの重複と派生を監査する

デザイン負債が大きくなりやすい領域の一つがコンポーネントです。新しい要件が出るたびに既存部品をコピーし、少し変更した別部品を作る方法を繰り返すと、同じ役割を持つ実装が増えていきます。最初は開発が速くても、後から一つの不具合修正やアクセシビリティ改善をすべての派生へ反映する必要が生じます。

監査では、見た目が似ているかだけではなく、構造、状態、操作、公開インターフェース、利用数を比較します。本当に別部品である必要があるのか、それとも一つの部品の正式なバリエーションとして扱えるのかを判断します。

5.1 同じ役割を持つ複数実装を探す

コードベースにButton、PrimaryButton、ActionButton、SubmitButtonなど複数の部品が存在していても、実際の役割や利用方法がほぼ同じ場合があります。名前が異なるため、単純な文字列検索だけでは重複を判断しにくく、実際にどの画面で、どのような目的で利用されているかまで確認する必要があります。特に、見た目が少し違うだけの部品や、過去の仕様変更によって名前だけが残っている部品には注意が必要です。

監査では、各部品の利用数、対応している状態、見た目、操作結果、利用されている画面や機能を比較し、実際に統合できるかを判断します。統合できる場合でも、古い部品を即座に削除するのではなく、新しい部品への移行方法、対象画面、担当範囲、移行期限などを決めます。移行計画を持たないまま統合すると、旧部品と新部品が長期間併存し、結果として管理対象が増えてしまう可能性があります。

5.2 派生を正式なバリエーションへまとめられるか確認する

サイズだけが異なるボタンや、危険操作用に色だけを変更したボタンが、それぞれ別コンポーネントとして存在している場合、一つの共通部品へまとめられる可能性があります。例えばsizeやvariantのような明確な属性によって差分を表現できれば、見た目だけでなく、ホバー、フォーカス、無効状態、ローディング状態などの処理も共通化できます。これにより、修正時の漏れや実装ごとの挙動差も減らせます。

ただし、すべての派生を一つの巨大なコンポーネントへ集約することも危険です。条件分岐や設定項目が増えすぎると、利用方法が分かりにくくなり、異なる操作目的を持つ部品まで無理に一つへまとめる結果になります。監査では、構造と意味が同じで、差分を属性として説明できるものだけを共通化し、操作目的や情報構造が異なるものは独立した部品として残します。

5.3 古い部品の利用場所を移行計画へ変える

新しいコンポーネントを用意しただけでは、既存のデザイン負債は減りません。旧コンポーネントが多数の既存画面で利用され続けると、製品内には新旧二つの体系が残り続けます。新規開発では新しい部品を使うようになっても、既存画面との見た目や操作感の違いが残るため、ユーザーから見える不整合も長期間解消されない可能性があります。

そのため監査では、旧部品がどの画面や機能で利用されているかを一覧化し、移行件数、影響範囲、改修難易度を把握します。利用数が少なく影響範囲も小さいものから段階的に移行する方法や、関連機能を改修するタイミングに合わせて置き換える方法など、状況に応じて移行方法を決めます。さらに移行率や残存件数を定期的に確認できるようにすると、単に「移行する予定」ではなく、負債削減の進捗を具体的な数値で管理できます。

5.4 デザインライブラリとコードの部品数を比較する

デザインツール上ではボタンが5種類しかないのに、コード側には20種類存在する場合、実装時に独自の派生コンポーネントが増えている可能性があります。逆に、コード側では一種類の共通部品しか存在しないのに、デザイン側では多数の独自パターンが作られている場合は、デザイン作成時の再利用やライブラリの運用が十分に機能していない可能性があります。

このように両方の部品構成を比較すると、デザイン負債や実装負債がどちら側から生まれているのかを把握しやすくなります。デザイン側だけ、またはコード側だけを正解と決めつけるのではなく、現在の製品要件やユーザー体験に適した正式な構造を定義し、その構造へデザインとコードの双方を合わせていくことが重要です。また、差分が生まれた理由まで確認することで、単純な統合作業ではなく、同じ問題が再発しないための運用改善にもつなげられます。

5.5 利用率の低い共通部品を再評価する

一つの画面だけで利用される非常に特殊な部品を共通ライブラリへ追加すると、他の開発者から見た場合には正式な再利用候補として認識される可能性があります。しかし、実際には特定の画面や機能専用であり、他の場所へ無理に再利用すると不自然な設計になったり、不要な設定や条件分岐が増えたりする場合があります。

監査では、共通部品ごとの利用数、利用されている画面、利用目的、他の領域への適用可能性を確認し、本当に共通ライブラリへ置いておく必要があるかを再評価します。利用範囲が非常に限定的なものは製品側のローカルコンポーネントへ戻し、共通ライブラリには複数の画面や機能で再利用できる部品を中心に残します。こうすることで、開発者がライブラリを見たときに「何を使うべきか」を判断しやすくなり、不要な派生コンポーネントが増えることも防ぎやすくなります。

6. 情報構造とナビゲーションの負債を確認する

製品へ機能が追加され続けると、メニュー項目、設定項目、一覧画面、詳細画面なども増え、情報構造が徐々に複雑になります。新機能を追加するたびに「空いている場所」へ入口を置いていると、ユーザーがどこから目的の機能へ行けばよいか分からなくなることがあります。

情報構造の負債は、色や余白を統一しても解決しません。名称、分類、階層、移動経路などを含めて確認し、ユーザーが製品をどのような構造として理解しているかを見る必要があります。

6.1 同じ機能への入口が増えすぎていないか確認する

便利さを高めるために、同じ機能へのリンクやボタンを複数の場所へ追加することがあります。適切に設計されていればユーザーが自分の作業場所から目的の機能へアクセスしやすくなりますが、入口ごとに名称や見た目、表示条件、動作が異なると、ユーザーは別の機能だと認識する可能性があります。また、複数の入口がそれぞれ独立して実装されていると、一つだけが更新され、他の入口が古い画面や古い処理へ移動する状態も発生しやすくなります。

監査では、同じ目的地へ移動するリンクやボタンを一覧化し、それぞれの名称、配置、表示条件、遷移先、遷移後の状態を比較します。複数の入口が必要であれば、ユーザーが同じ機能だと理解できるように意味や表現を揃え、不要な入口については主要な経路へ集約します。ただし、入口数を単純に減らすことが目的ではありません。ユーザーがどの画面や作業の途中でその機能を必要とするのかを確認し、必要な入口と重複しているだけの入口を区別することが重要です。

6.2 メニュー分類の一貫性を確認する

メニュー項目が機能追加ごとに増えていくと、最初は「顧客」「商品」のような対象別分類だったにもかかわらず、一部だけ「分析」「設定」のような目的別分類が混ざることがあります。また、ある項目は業務プロセスに基づいて分類され、別の項目は画面の種類やデータの種類によって配置されるなど、複数の分類ルールが同時に存在する場合もあります。分類原則が混在すると、ユーザーは項目名を正確に知らなければ目的の機能を見つけられなくなります。

監査では、現在のメニューがどのような基準で分類されているのかを言語化し、その基準から外れている項目や、複数のカテゴリに入れそうな項目を確認します。必要であればユーザー調査や検索行動、アクセスログなども利用し、実際の利用者がどのような考え方で機能を探しているかを確認します。その結果をもとに、単に項目を並べ替えるのではなく、ユーザーの理解モデルに近い情報構造へ修正することが重要です。メニューは単なるリンクの一覧ではなく、製品全体の機能関係を表す重要な構造として評価します。

6.3 用語の揺れを製品全体から探す

同じ対象を「顧客」「取引先」「クライアント」のように複数の名称で表現すると、ユーザーはそれぞれが別の対象や異なる状態を意味していると考える可能性があります。チーム内部では同じものだと理解していても、画面ごとに異なる用語が使われていれば、新規利用者にはその関係を判断できません。特に、メニューでは「顧客」、詳細画面では「クライアント」、通知では「取引先」といった揺れは、製品全体の理解を難しくします。

監査では、画面タイトル、メニュー、ボタン、通知、エラーメッセージ、ヘルプ、入力ラベル、検索条件などを横断して用語を確認し、同じ概念が異なる名称で表現されていないかを確認します。そのうえで、製品として使用する正式名称を決め、必要な場所へ適用します。ただし、単純な一括置換を行うのではなく、業務上本当に意味や対象範囲が異なる場合は、それぞれの用語を区別して残します。用語辞書やコンテンツルールを整備し、新機能のデザインレビューや実装レビューでも確認することで、同じ問題が再発することを防ぎやすくなります。

6.4 深すぎる階層と頻繁な往復を確認する

重要な設定や機能へ到達するために何階層も移動する必要がある場合、現在の情報構造が実際の利用方法に合わなくなっている可能性があります。製品の初期段階では利用頻度が低かったため深い場所に配置されていた機能でも、利用者の増加や業務フローの変化によって主要機能へ変わることがあります。その状態で古い階層構造を維持すると、ユーザーが毎回同じ画面を何度も経由する必要が生まれます。

監査では、単純な階層数だけではなく、その機能の利用頻度、到達までの操作数、滞在時間、戻る回数、途中で別画面へ移動する割合なども含めて評価します。特に頻繁に利用する機能が深い階層へ配置されていたり、複数の画面を往復しなければ作業を完了できなかったりする場合は、情報構造そのものの見直しを検討します。主要画面から直接アクセスできる入口を追加する方法や、関連機能を同じ場所へまとめる方法など、実際の利用フローに合わせて構造を再設計することが重要です。

6.5 戻る操作と現在位置の表示を確認する

画面を深く移動した後に一覧へ戻る方法が分からない、戻った際にフィルター条件や検索条件が消える、スクロール位置が先頭へ戻ってしまうといった問題も、情報構造上の負債として扱う必要があります。ユーザーは単に前の画面へ戻りたいだけなのに、条件を再入力したり、同じ場所までスクロールし直したりしなければならず、結果として一つの作業に必要な操作数が増えてしまいます。

監査では、パンくず、戻るボタン、一覧への復帰、ブラウザバック、モーダル終了後の復帰位置、検索条件やフィルター状態の保持などを確認します。また、単純に「戻るボタンが存在するか」だけではなく、その操作を行った後にユーザーが作業を自然に再開できるかまで確認します。ナビゲーションは現在位置を示すだけの仕組みではなく、ユーザーがそれまで行っていた作業の文脈を維持したまま移動できる仕組みとして評価することが重要です。

7. 文言とコンテンツの負債を監査する

UI上の文章は、デザインと機能をユーザーへ説明する重要な要素です。しかし複数チームが長期間にわたり文言を追加すると、同じ操作の名称が変わったり、文章の丁寧さや長さが画面ごとに異なったりします。

文言の負債はコード上の不具合ではないため後回しにされやすいものの、理解しやすさ、操作成功率、問い合わせ数に直接影響します。そのためデザイン監査の一部として扱う必要があります。

7.1 ボタンラベルと実際の動作を一致させる

「保存」「更新」「適用」「確定」など、似た意味を持つ言葉が同じ製品内で混在すると、ユーザーはそれぞれの違いを判断しにくくなります。特に同じ画面内で複数の表現が使われている場合、それぞれが異なる範囲やタイミングで作用するように見えることがあります。実際には同じ処理を実行しているにもかかわらず名称だけが違う場合、ユーザーは操作前に挙動を推測する必要があり、不要な迷いが生まれます。

監査では、ボタンのラベルだけを一覧化するのではなく、そのボタンを押した後に何が起きるのか、どのデータが変更されるのか、画面状態がどう変化するのかまで記録します。同じ結果になる操作については用語の統一を検討し、結果や対象範囲が異なる場合は、その違いをユーザーが理解できる名称へ変更します。言葉の統一は単なる文章修正ではなく、ユーザーが操作を予測できるようにするための操作モデルの統一として扱う必要があります。

7.2 エラーメッセージの品質を比較する

あるフォームでは「メールアドレスを入力してください」と具体的に表示される一方で、別のフォームでは「エラーが発生しました」だけが表示される場合があります。さらに、開発者向けのエラーコードやAPIのレスポンス内容がそのまま画面に表示されるケースもあります。同じ種類の問題であっても画面によって説明の詳しさが異なると、ユーザーが問題を解決するために必要な情報を得られない場合があります。

監査では、エラーが発生したことだけでなく、何が問題なのか、なぜ問題が発生したのか、ユーザーが何を修正すればよいのかまで伝わっているかを確認します。また、入力項目の近くに表示するのか、画面上部にまとめるのかなど、表示位置や状態変化も比較します。共通ルールを作ることで、各開発者が毎回独自の文言や表示方法を考える必要がなくなります。特にフォーム部品とエラーメッセージをセットで標準化すると、入力状態からエラー表示まで一貫した体験を維持しやすくなります。

7.3 古い名称や廃止済み表現を検索する

機能名やブランド名を変更した後も、通知文、ヘルプ、ツールチップ、空状態、確認ダイアログなどに旧名称が残ることがあります。メイン画面では新しい名称になっていても、別の場所で古い名前が表示されると、ユーザーはそれが同じ機能なのか、別の機能なのか判断できなくなる可能性があります。また、検索結果や通知など普段あまり確認されない場所ほど、こうした古い表現が長期間残りやすくなります。

監査では、コード、翻訳ファイル、コンテンツ管理システム、ヘルプページなどを横断して全文検索を行い、旧名称や廃止済み表現を洗い出します。発見したものは単純な修正リストとして管理するだけでなく、どの画面やコンテンツで使用されているか、ユーザーへの影響がどの程度あるかも確認します。さらに、名称変更が頻繁に発生する製品では、名称を共通定数やコンテンツ管理へ集約できるかを検討し、一部だけ古い表現が残る問題を構造的に防ぐことも重要です。

7.4 内部用語が利用者向け画面へ出ていないか確認する

開発チームでは理解できる「同期処理」「識別子」「内部状態」「ジョブ」などの言葉でも、一般の利用者には具体的な意味が分からない場合があります。開発者が実装上使用している名称をそのままUIへ流用すると、ユーザーはシステムの内部構造を理解しなければ操作できない状態になります。特にエラーメッセージや設定画面に内部用語が多く残ると、製品そのものが難しく感じられる原因になります。

監査では、その用語をユーザーが知る必要が本当にあるのかを確認し、必要がなければユーザーが理解すべき目的や結果を説明する文章へ置き換えます。例えば内部処理の名称をそのまま表示するのではなく、「最新の情報を取得する」「データの同期を開始する」のように、ユーザーが行う操作や得られる結果を基準に表現します。一方、専門知識が前提となる業務製品では、専門用語そのものを排除するのではなく、製品内で意味と表記を統一し、必要な場面では初回利用時の説明やヘルプを提供することが重要です。

7.5 空状態の文章を次の操作まで含めて評価する

「データがありません」「該当する結果はありません」とだけ表示される空状態は、現在の状況を説明することはできますが、ユーザーが次に何をすればよいのかまでは伝えていません。特に新規利用者の場合、まだデータを作成していないのか、検索条件が間違っているのか、権限がないのかを判断できないことがあります。同じ空状態でも原因によって必要な行動は異なるため、単一の文章だけでは十分に対応できない場合があります。

監査では、なぜ空になっているのか、その状態からユーザーが次に何をできるのか、必要な操作への入口が提供されているかを確認します。例えば初回利用時であれば「最初のデータを作成する」ためのボタンを提示し、検索結果がない場合は検索条件を変更する方法を示すなど、状況に応じて案内を変える必要があります。空状態を単なる空白を埋めるための文章として扱うのではなく、現在の状態を説明し、次の行動へ自然に導くための画面として設計することで、初回利用時の理解やタスク完了率も改善しやすくなります。

8. アクセシビリティ負債を監査する

アクセシビリティ問題は、一つの古いコンポーネントが多数の画面で利用されることで広範囲へ影響する場合があります。また新しい画面では改善されていても、古い画面にはフォーカス表示不足やラベル不足が残っていることがあります。

自動検査だけではすべての問題を発見できないため、キーボード、拡大表示、画面読み上げなど複数の方法を利用します。共通コンポーネントで問題が見つかった場合は、個別画面より高い優先度で改善する価値があります。

8.1 キーボードだけで主要操作を完了できるか確認する

クリック可能なdivや独自実装のドロップダウン、カスタムモーダルなどは、マウス操作では問題なく利用できても、キーボードから操作できない場合があります。特に古い画面では、標準HTML要素を使わず、見た目をデザインに合わせることを優先した独自実装が残っていることがあります。その結果、キーボード利用者が重要な操作へ到達できなかったり、途中で操作を継続できなくなったりします。

監査では、主要なユーザーフローを実際にキーボードだけで操作し、Tab、Enter、Space、矢印キー、Escapeなどが適切に機能するかを確認します。単にすべての要素へフォーカスできるかだけではなく、フォーカス順序が自然か、メニューやダイアログを開いた後に操作できるか、閉じた後に適切な場所へ戻れるかまで確認します。同じ問題が共通コンポーネントに由来している場合は、部品側を修正することで複数画面を一度に改善できるため、優先度を高く設定する価値があります。

8.2 フォーカス表示の差を確認する

一部の画面では明確なフォーカスリングが表示される一方で、別の画面ではデザイン上の理由からoutline: noneが設定されていたり、背景とほぼ同じ色のフォーカス表示になっていたりすることがあります。キーボード操作では、現在どの要素が選択されているのかを視覚的に確認できることが重要です。フォーカス位置が分からない状態になると、ユーザーはどの操作が実行されるのか判断できず、操作を継続することが難しくなります。

監査では、フォーカス表示の有無だけでなく、通常状態との差、背景とのコントラスト、表示位置、リングの太さや形状なども確認します。また、ボタン、リンク、入力欄、メニュー項目など、異なる種類の操作部品で表示方法が大きく異なっていないかも比較します。共通のフォーカストークンやスタイルルールを導入し、すべての操作部品で一定の品質を保てるようにすると、画面ごとの実装差を減らし、今後追加される部品でも同じ問題が発生することを防ぎやすくなります。

8.3 文字と背景のコントラストをトークン単位で確認する

補助文章、説明文、無効状態、プレースホルダー、境界線などでは、画面をすっきり見せたり視覚的な優先度を下げたりするために、薄い色が使われやすくなります。しかし、背景との差が小さすぎると、表示環境や画面の明るさ、視力などによって文字や情報を読み取りにくくなる場合があります。一つの色が複数の画面で利用されている場合、その影響は特定の画面だけに限定されません。

監査では、単純に画面上の色を確認するだけでなく、どのカラーや意味トークンが問題を引き起こしているのかを特定します。画面ごとに個別の色を修正すると、同じ問題が別の場所に残ったり、デザイン体系そのものが不統一になったりする可能性があります。そのため、問題のある共通トークンを特定し、テキスト、背景、境界線、状態色などの意味トークン単位で修正できるかを検討します。基盤側を改善できれば、複数画面へ一貫した修正を適用できます。

8.4 アイコンや入力欄の名前不足を確認する

視覚的にはゴミ箱のアイコンを見れば「削除」と理解できても、画面読み上げソフトにはその意味を示す適切な名前が伝わっていない場合があります。また、アイコンだけで操作を表現しているボタンでは、同じアイコンであっても画面によって目的が異なることがあります。入力欄についても、プレースホルダーだけをラベル代わりに使用すると、入力後に項目名が確認できなくなったり、読み上げ時に何を入力する欄なのか分かりにくくなったりします。

監査では、画面上で表示される視覚的なラベルと、支援技術へ伝わる機械的な名前の両方を確認します。ボタンや入力欄だけでなく、アイコン、フォーム項目、ダイアログ、画像など、意味を伝える必要がある要素についても確認します。同じアイコンボタンや入力部品が複数画面で利用される場合は、共通コンポーネント側で適切な名前の指定を必須にするなど、実装時に漏れを防ぐ仕組みを用意することが重要です。

8.5 拡大表示で固定レイアウトが崩れないか確認する

文字サイズやブラウザ表示を拡大すると、固定高さのボタンから文字がはみ出す、カード同士が重なる、ダイアログの内容が見切れる、横スクロールが必要になるといった問題が発生する場合があります。通常の表示倍率だけを確認していると、このような問題は開発段階で見つからず、実際の利用環境で初めて発覚することがあります。特に固定高さや固定幅を多用した古いレイアウトでは注意が必要です。

監査では、主要な画面を拡大表示し、文字や操作要素が欠けたり重なったりせず、必要な情報と操作へアクセスできるかを確認します。また、単一画面のレイアウトだけでなく、共通カード、ボタン、フォーム、モーダル、ナビゲーションなど、複数画面で使用されるレイアウト部品にも同じ問題がないか確認します。問題が共通レイアウトや固定サイズのトークンに存在する場合は、個別画面を修正するよりも基盤側のサイズルールやレスポンシブ設計を改善することを優先し、同じ負債が新しい画面へ広がることを防ぎます。

9. デザインファイルと実装の差を監査する

デザインファイルに正式仕様が存在していても、実装側が数年前の状態で止まっている場合があります。反対に、開発側で改善された仕様がデザインライブラリへ戻されていないこともあります。その状態では、次の機能開発時にどちらを正しい仕様として使うべきか判断できません。

監査ではデザイン、実装、実際の製品画面を三方向から比較し、差そのものだけではなく、どの更新経路が機能していないのかまで確認します。

9.1 サイズや余白の差を確認する

デザインファイルでは高さ40ピクセルとして定義されているボタンが、実装では38ピクセルになっているような小さな差は、単体で確認すると気付きにくいものです。しかし、複数のボタンや入力欄、カードなどを同じ画面上に並べると、上下の位置が揃わなかったり、要素間の余白が微妙に異なったりすることで、製品全体に細かな不統一が広がります。こうした差が多数積み重なると、ユーザーからは明確な理由が分からなくても、画面全体が整っていない印象につながります。

監査では、サイズや余白の差を発見した後、どちらを正式な仕様として扱うのかを決定します。ただし、デザインファイルに記載されている値が常に正しいとは限らず、実装側で得られた改善や技術上の制約が、現在の製品要件により適している場合もあります。そのため、単純にデザインへ合わせるのではなく、実際の利用状況やアクセシビリティ、レスポンシブ対応なども含めて判断します。最終的には一つの基準へ戻し、その基準をデザインとコードの双方へ反映して同期状態を作ることが重要です。

9.2 状態仕様の不足を双方で確認する

デザインではホバー、フォーカス、無効、エラー、ローディングなどの状態が定義されているのに、コード側には通常状態しか実装されていない場合があります。逆に、コードでは非同期処理のためのローディング状態やエラー状態が実装されているにもかかわらず、デザイン資料にはその状態が存在しない場合もあります。このような差が残ると、実装時に開発者が独自判断で見た目を決めたり、デザイナーが実装済みの状態を把握できなかったりします。

監査では、コンポーネントごとに必要な状態の一覧を作成し、デザインとコードの双方で定義・実装されているかを確認します。通常状態だけを比較するのではなく、ユーザーが実際に操作した際に発生するすべての重要な状態を対象にします。また、状態仕様を正式なドキュメントやコンポーネント仕様として共有し、デザイン変更と実装変更の両方から参照できるようにします。これにより、どちらか一方だけが更新されて状態仕様が分離する問題を減らせます。

9.3 コンポーネント名称を共通言語へ近づける

デザインでは「主要ボタン」、コードではCTAButton、仕様書では「確定操作」のように、それぞれ異なる名称で同じコンポーネントを呼んでいると、会話のたびに「これは同じものなのか」を確認する必要があります。小さな問題に見えますが、デザイナー、エンジニア、プロダクトマネージャーなど関係者が増えるほど、この確認作業が積み重なり、レビューや仕様確認に余計な時間がかかります。

監査では、デザインライブラリ、コード、仕様書、チケット、ドキュメントなどで使用されている名称を比較し、同じ概念が異なる名前で管理されていないか確認します。可能な範囲で正式名称を統一し、技術上の理由などから名称を完全に揃えられない場合は、デザイン名とコード名の対応関係を明確にドキュメント化します。共通言語が整備されると、レビューや不具合報告で対象を特定しやすくなり、名称の誤解から新しい派生部品が作られることも防ぎやすくなります。

9.4 廃止コンポーネントが片方だけ残っていないか確認する

コードではすでに削除されたコンポーネントがデザインライブラリには残っていると、デザイナーが新しい画面を作る際に古い部品を再利用してしまう可能性があります。逆に、デザイン側では廃止済みになっているにもかかわらず、コード側に多数の利用箇所が残っている場合は、実装上の負債が継続します。この状態が長く続くと、新旧コンポーネントが再び増え、過去に解消したはずの問題が別の形で再発する可能性があります。

監査では、各コンポーネントについて現在の状態を双方で確認し、現行、非推奨、移行中、廃止済みなどのステータスを明確にします。廃止する場合は、移行先となる新しいコンポーネント、利用停止の時期、既存利用箇所の移行期限なども合わせて定義します。単に古い部品へ「非推奨」と表示するだけでは再利用を防ぎきれないため、コード側で新規利用を検出するLintやレビュー時のチェックなど、技術的に再利用を検知できる仕組みも検討します。

9.5 更新フローの断絶そのものを負債として記録する

同じ種類の差分が何度も発生している場合、それは個別の仕様差ではなく、デザインとコードを更新するプロセスそのものに問題がある可能性があります。例えば、デザイン変更が開発チームへ共有されない、実装上の制約や改善結果がデザインチームへ戻されない、コンポーネント更新後に双方のライブラリを確認する担当者が決まっていない、といった状態です。この場合、目の前の差分だけを修正しても、次の変更で同じ問題が再び発生します。

監査では「デザインとコードのどちらが間違っているか」だけを判断するのではなく、「なぜ同期されなかったのか」「どの段階で情報が失われたのか」まで確認します。そのうえで、デザインシステム更新時のレビュー、変更通知、実装確認、公開手順など、双方を同期するための更新フローを整理します。個別の差分修正と同時にプロセスそのものを改善することで、同じ種類の負債が繰り返し発生する可能性を減らし、長期的にデザインとコードの整合性を維持しやすくなります。

10. デザイン負債と他の問題を区別する

製品には、デザイン負債だけでなく、単発の表示不具合、技術的負債、UX課題、デザインシステム不足など複数種類の問題が存在します。すべてをデザイン負債として一つのバックログへ入れると、修正方法や担当者が分からなくなります。

監査では問題を分類し、どの仕組みで解決するべきかを明確にします。分類は問題を分断するためではなく、適切な改善方法へ接続するために行います。

10.1 単発UI不具合との違い

単発のUI不具合は、正式な仕様や共通ルールがすでに存在しているにもかかわらず、一部の画面だけ実装が間違っている状態です。例えば、正式なボタン高さが40ピクセルと定義されているのに、一つの画面だけ20ピクセルで実装されている場合は、基本的に対象箇所を修正すれば問題を解消できます。一方、デザイン負債では、そもそも正式仕様が複数存在していたり、同じ役割の旧部品が多数残っていたりするため、個別画面だけを修正しても別の場所で同じ問題が発生する可能性があります。

単発不具合を監査中に発見した場合も、発生箇所や原因を記録しておく必要があります。ただし、デザイン負債として扱う構造改善項目とは分けて管理した方が、優先順位や担当者を明確にしやすくなります。分類を行うことで、短時間で修正できる単発不具合が、大規模な負債改善プロジェクトの後ろへ埋もれてしまうことも防げます。

10.2 技術的負債との違い

技術的負債は、古い依存関係、複雑なコード構造、テスト不足、性能上の問題、保守しにくいアーキテクチャなど、幅広い技術上の問題を含みます。デザイン負債はユーザーから見えるUI・UXやデザイン資産の不整合を中心に扱いますが、コンポーネントの重複、直接的なスタイル指定、共通基盤の複雑化など、両方の領域にまたがる問題も存在します。

両者が重なる問題では、デザイン側だけで改善計画を立てず、技術基盤の改善と合わせて検討する必要があります。例えば、旧コンポーネントを統合するために内部構造の大規模な変更が必要な場合、その作業はデザイン負債の解消であると同時に技術的負債の改善にもなります。監査結果を両方のバックログへ適切に関連付けることで、同じ作業を別々の計画として重複管理することも防げます。

10.3 一般的なUX課題との違い

UX課題は、ユーザーが目的を達成できない、情報を理解できない、必要な機能を発見できない、操作手順が分かりにくいなど、非常に幅広い問題を含みます。そのため、新しく作ったばかりの画面でもUX課題は発生する可能性があります。一方、デザイン負債は時間の経過とともに蓄積した不整合、古い設計、重複した部品、過去の仕様が残っていることなどが原因となる場合が多くなります。

実際には、デザイン負債がUX課題の直接的な原因になっている場合もあります。例えば、同じ操作に異なる名称が使われていたり、画面ごとに異なるナビゲーションが存在したりすると、それ自体がユーザーの混乱につながります。そのため完全に別々の問題として扱うのではなく、監査で発見した問題のうち利用者の行動や理解を検証する必要があるものをUX調査へ渡すなど、監査とユーザーリサーチをつなげることが重要です。

10.4 デザインシステム不足との違い

デザインシステムが存在しないこと自体は、必ずしも問題ではありません。小規模な製品や少人数のチームでは、少数の明確なデザインルールと共有された部品だけで、一貫した設計を維持できる場合があります。しかし、製品やチームの規模が拡大しているにもかかわらず、共通部品やデザイントークン、状態仕様などが整備されていない場合は、画面ごとの独自実装が増え、不整合が急速に蓄積する可能性があります。

監査では、「デザインシステムを作ればすべて解決する」と考えるのではなく、現在の負債がどのような仕組み不足から生まれているのかを確認します。例えば、ボタンや入力欄だけ共通化すれば十分な製品に対して、最初から巨大なデザインシステムを構築する必要はありません。現在の規模と問題に必要な共通基盤だけを整備し、実際の負債削減につながる範囲から段階的に拡張する方が効果的な場合があります。

10.5 全面リニューアルとの違い

デザイン負債が多く蓄積すると、「すべて作り直した方が早い」という議論が出ることがあります。しかし、全面リニューアルでは既存機能の再実装だけでなく、データや状態の移行、既存ユーザーへの影響確認、回帰テスト、旧画面との並行運用など、大きなコストが発生します。また、新しいデザインへ置き換えたとしても、コンポーネントの管理ルールやレビュー方法が改善されていなければ、数年後に同じ種類の負債が再び蓄積する可能性があります。

監査によって負債の原因が特定のコンポーネント、情報構造、デザイントークン、更新フローなどに限定されていると分かれば、製品全体を作り直さなくても大きな効果を得られる場合があります。重要なのはリニューアルそのものを目的にするのではなく、現在存在している問題を最も効率よく解決できる方法を選ぶことです。全面リニューアルが必要な場合でも、監査結果を利用して対象範囲と優先順位を明確にし、単なる見た目の刷新ではなく、負債が再発しにくい構造と運用まで含めて計画する必要があります。

11. 負債をスコアリングして改善順序を決める

監査を詳細に行うほど、多数の問題が見つかります。しかし数百件の問題をすべて同時に修正することは現実的ではありません。問題件数だけを見て優先順位を決めると、簡単な見た目修正ばかり進み、重大な操作問題が残る可能性があります。

ユーザー影響、利用頻度、影響範囲、修正コスト、再発リスクなどを評価することで、改善の順序を判断しやすくなります。スコアは絶対的な答えではなく、チーム間で優先順位を議論するための共通基準として利用します。

11.1 ユーザー影響を最も重要な軸として評価する

同じ不整合であっても、カードの角丸が数ピクセル違う問題と、購入ボタンの意味を誤認させる問題では、ユーザーへの影響が大きく異なります。特に、ユーザーが操作を完了できない、誤った操作を実行する、重要な情報を理解できない、現在の状態を判断できないといった問題は、高い影響度として扱う必要があります。一方で、見た目だけの差であっても、重要な状態や意味を誤認させる場合には、単なるビジュアル上の問題として低く評価しないことが重要です。

影響度は数段階のスコアとして定義し、評価者によって判断が大きく変わらないよう、各段階に具体的な例を用意します。例えば「操作不能」「重大な誤操作につながる」「作業効率を低下させる」「軽微な視覚的不整合」といった基準を設定しておくと、異なる監査担当者でも比較しやすくなります。ユーザー影響を最初の評価軸に置くことで、単純に目立つ問題ではなく、実際の利用体験を大きく損なう問題を優先して扱えるようになります。

11.2 利用頻度を実際のデータから判断する

毎日多くのユーザーが利用する画面と、年に数回だけ利用される管理画面では、同じ問題が存在していても製品全体への総影響量は大きく異なります。そのため、可能であればアクセス解析、操作ログ、イベント計測、画面別の利用状況などを利用し、担当者の感覚だけで利用頻度を判断しないようにします。特に監査対象が大規模な製品になるほど、実際の利用データを使うことで優先順位の精度を高められます。

また、単純な利用者数だけではなく、一人当たりの操作回数や作業時間も重要な指標になります。例えば少数の業務担当者しか利用しない画面でも、一人が一日に数百回同じ操作を繰り返しているのであれば、その画面の小さな不整合や操作負担は大きな累積コストになります。利用者数と操作頻度を組み合わせて評価することで、表面的なアクセス数だけでは見えない負債の影響を把握できます。

11.3 共通原因が影響する範囲を評価する

一つの共通入力コンポーネントを修正することで50画面の問題を同時に改善できるのであれば、その改善は非常に高い費用対効果を持ちます。そのため、監査では画面単位で問題数を単純に数えるのではなく、同じ原因がどれだけの画面、機能、ユーザーに影響しているのかを確認します。10画面に同じ問題がある場合でも、10個の独立した問題なのか、一つの共通部品が原因なのかによって、適切な改善方法は大きく異なります。

特に共通トークン、主要ナビゲーション、共通フォーム、ボタン、モーダルなど、製品全体で広く利用される要素は、個々の問題が小さく見えても優先度が高くなる場合があります。共通原因を特定してまとめることで、一度の修正によって広範囲へ効果を反映できるだけでなく、同じ問題が新しい画面へコピーされることも防ぎやすくなります。監査結果を原因ベースで整理することは、デザイン負債を効率的に削減するための重要な考え方です。

11.4 修正コストを影響度とは別に評価する

重要度が同程度の問題が複数存在する場合、短期間で修正でき、大きな効果を得られるものから改善することで、早い段階から成果を作りやすくなります。しかし、修正コストが高いという理由だけで重大な問題を永遠に後回しにすることも避ける必要があります。例えば、基盤の大規模変更が必要な問題でも、ユーザー影響が非常に大きいのであれば、中長期的な改善計画へ明確に組み込む必要があります。

そのため、ユーザー影響と修正工数を一つの数値へ混ぜるのではなく、それぞれ別の評価軸として管理します。影響度、利用頻度、影響範囲などから「どれだけ重要か」を判断し、工数や技術的な難易度から「どれだけ実施しやすいか」を判断します。これにより、短期的に実施する改善候補と、中長期的に計画する基盤改善候補を分けながら、どちらもバックログから失われない状態を作れます。

11.5 将来の再発可能性を含めて判断する

現在は一画面にしか存在しない問題であっても、新しく作られる画面が同じ独自パターンをコピーし始めているのであれば、将来的に急速に広がる可能性があります。反対に、古い一画面だけに存在し、その画面自体が近い将来に廃止される予定であれば、現在の影響が多少あっても優先度を下げられる場合があります。このように、現在の件数だけでは将来的な負債の大きさを判断できません。

スコアリングでは現在のユーザー影響や利用頻度だけでなく、今後その問題が増える可能性も評価します。正式な共通部品が存在しない領域、複数チームがそれぞれ独自実装している領域、コピー＆ペーストによって画面が増えている領域などは、再発リスクが高いと判断できます。将来の増加可能性まで含めて評価することで、「今は小さいから後回し」という判断によって、数年後に大規模な負債へ成長することを防ぎやすくなります。

コード例：簡易的な優先度計算

複数の評価軸を使って優先度を簡易的に算出する場合は、ユーザー影響を最も重くし、利用頻度、影響範囲、再発リスクを加算したうえで、修正工数によって割る方法があります。これにより、影響が大きく、広範囲に利用され、再発しやすい問題ほど優先度が高くなり、同程度の効果なら少ない工数で修正できるものを先に選びやすくなります。

function calculateDebtPriority({
 userImpact,
 frequency,
 reach,
 recurrenceRisk,
 effort
}) {
 const value =
   userImpact * 3 +
   frequency * 2 +
   reach * 2 +
   recurrenceRisk * 2;

 return value / Math.max(effort, 1);
}
 

ただし、この計算結果をそのまま最終的な意思決定に使うのではなく、あくまで候補を比較するための補助指標として扱います。特にアクセシビリティや重大な操作ミスにつながる問題など、数値だけでは表現しにくいリスクについては、スコアとは別に必須対応として扱う判断も必要です。重要なのは計算式そのものではなく、監査担当者が同じ基準で問題を比較し、なぜその項目を優先したのかを説明できる状態を作ることです。

12. 監査結果を実行可能な改善バックログへ変換する

監査資料に大量の問題を記録しても、開発担当者が「何を直せば完了なのか」を理解できなければ改善は進みません。スクリーンショットだけを並べた資料は問題共有には役立ちますが、実際の作業計画としては不足します。

監査結果を、原因、対象範囲、改善方法、完了条件、担当領域を持つ作業単位へ変換することが必要です。こうすることで、通常の製品開発計画へ負債改善を組み込みやすくなります。

12.1 画面単位ではなく原因単位で改善項目を作る

同じ旧ボタンが20画面に存在する場合、「画面Aのボタン修正」「画面Bのボタン修正」のように20件のタスクとして登録するより、「旧ボタンを新しい共通ボタンへ移行する」という一つの改善項目にまとめた方が、根本原因と改善方針を追跡しやすくなります。画面単位で管理すると作業量は細かく見える一方で、同じ問題を何度も別々に扱うことになり、共通部品の変更や移行方針がバックログ上で見えにくくなる可能性があります。

改善項目には対象となる画面や機能を子項目として持たせ、どこまで移行が完了しているかを管理できるようにします。また、修正途中で新しい旧ボタンの利用箇所が見つかった場合も、別の問題として登録するのではなく、同じ改善項目へ追加できるようにします。原因単位で管理することで、個別画面の修正件数ではなく、共通原因がどの程度解消されたかを基準に進捗を判断できます。

12.2 完了条件を具体的に定義する

「フォームを統一する」「ボタンを改善する」「古いコンポーネントを移行する」といった表現だけでは、どの状態まで対応すれば作業完了なのか判断できません。例えばボタンを置き換えただけで完了とするのか、通常状態だけでなくホバー、フォーカス、エラー、無効、ローディングなどの状態まで確認するのかによって、必要な作業量は大きく変わります。対象画面や旧部品の削除まで含める必要がある場合もあります。

そのため改善項目では、対象範囲、対応する状態、デザイン更新、コード変更、旧部品の利用停止、関連画面の確認などを具体的な完了条件として定義します。完了条件が明確であれば、修正後の再監査でも同じ基準を使って確認でき、対応漏れを発見しやすくなります。また、デザイン側では完成しているがコード側では未対応、あるいはコード側では実装済みだがデザイン仕様が更新されていないといった「完成」の認識差も防ぎやすくなります。

12.3 スクリーンショットに実装情報を追加する

問題箇所のスクリーンショットは、視覚的な不整合や操作上の問題を短時間で理解するために非常に有効です。しかし、画像だけを改善項目へ添付すると、修正担当者が改めて画面を探し、該当するコンポーネントやコード位置を調査する必要があります。監査と修正の間に再調査が発生すると、監査で得た情報が十分に活用されないまま作業時間が増えてしまいます。

そのため、スクリーンショットだけでなく、URL、画面名、機能名、コンポーネント名、コード上の位置、再現条件、対象ユーザー、発生する状態など、監査時点で確認できた実装情報も合わせて記録します。特に「どこに問題があるか」だけでなく「なぜ問題と判断したか」「何へ置き換える予定か」まで記録しておくと、担当者が調査を最初からやり直す必要がなくなります。監査担当者がすでに調べた情報を改善担当者へ引き渡せる形にすることで、監査から修正までの距離を短くできます。

12.4 所有チームと意思決定者を明確にする

共通ボタンはデザインシステムチーム、特定画面は製品チーム、ブランドカラーはブランド担当というように、デザイン負債ごとに実際の所有者や意思決定者が異なる場合があります。特に複数チームが利用する共通部品では、誰かが修正するだろうという状態になりやすく、問題が重要であっても長期間バックログへ残り続ける可能性があります。

改善項目には担当するチームや領域を設定し、複数チームにまたがる場合でも主担当を一つ決めます。また、実装担当者だけでなく、仕様変更を最終的に承認できる意思決定者も明確にしておくことが重要です。誰が作業するのか、誰が仕様を決めるのか、誰が完了を判断するのかを分けて整理することで、チーム間の責任範囲が曖昧になることを防ぎ、改善に関する議論も止まりにくくなります。

12.5 すべてを同じ期限で解消しない

デザイン負債の中には、早急な対応が必要なアクセシビリティ問題や重大な操作ミスにつながる問題がある一方で、関連機能を改修するタイミングで対応すれば十分な低影響の視覚差もあります。すべての項目に同じ期限を設定すると、通常の製品開発計画と衝突しやすくなり、結果として期限を守れない項目が大量に残り、負債改善そのものが形骸化する可能性があります。

そのため、即時対応、短期対応、四半期内対応、関連機能の変更時に対応、将来の画面廃止時に対応するなど、複数の解消方法を用意します。重要度だけでなく、修正コスト、再発リスク、製品ロードマップとの関係も考慮し、それぞれに現実的なタイミングを設定します。監査結果をすべて一度に解消することを目標にするのではなく、通常の開発プロセスへ継続的に組み込み、一定期間ごとに残存件数や優先度を見直すことで、負債を長期的に減らしていくことが重要です。

13. コード監査で目視では見つけにくい負債を発見する

大規模なコードベースでは、人間が全画面を目視するだけでは、直接色指定や旧コンポーネント利用などをすべて発見することは困難です。コード検索や静的解析を利用することで、広範囲を短時間で確認できます。

ただし自動検索は「問題候補」を見つける手段であり、検索結果そのものを負債と断定してはいけません。利用目的や必要性を人間が確認し、実際の問題か判断します。

13.1 直接指定されている値を一覧化する

色、文字サイズ、余白、角丸、線幅などの値をコードベースから抽出すると、デザインシステムで定義されているトークン以外の値がどれだけ利用されているかを把握できます。特に、同じ直接指定値が数百回単位で繰り返し使われている場合、それは単純な例外ではなく、まだ正式なデザイントークンとして定義されていない共通ルールである可能性があります。逆に、一度しか使われていない値であれば、特定のレイアウトや状態に必要な例外である可能性もあります。

コード例：ピクセル値を集計する

grep -RhoE '[0-9]+px' src/ \
 | sort \
 | uniq -c \
 | sort -nr

抽出結果を頻度順に並べ、どの値が大量に利用されているのか、公式トークンに対応する値が存在するのかを確認します。ただし、抽出された値をすべて機械的にトークンへ置換するのは避けます。レスポンシブ対応や特殊なレイアウトなど、直接値が必要なケースも存在するため、それぞれが本当に例外なのか、正式な共通値として定義すべきなのかを判断してから修正します。

13.2 古いコンポーネントの利用場所を検索する

廃止予定のコンポーネント名が分かっている場合、コード検索だけでも現在の移行規模を比較的短時間で把握できます。例えば旧ボタンが何画面で利用されているか、どの製品領域に集中しているかを確認することで、移行作業の優先順位や担当チームを決めやすくなります。また、同じ検索を定期的に実行すれば、旧部品の利用数が実際に減っているかを数値として追跡できます。

コード例：旧部品を検索する

grep -R "<LegacyButton" src/

検索結果は単純な件数だけで管理するのではなく、画面、製品領域、チーム、利用方法などに分類すると、どこから移行を始めるべきか判断しやすくなります。特に利用数が少ない箇所を早期に移行して残存箇所を減らす方法や、大量利用されている領域をまとめて移行する方法など、状況に応じた計画を立てられます。最終的には利用数をゼロにするだけでなく、利用がゼロになった時点で旧部品そのものを削除するところまで計画することが重要です。

13.3 インラインスタイルの利用を確認する

インラインスタイルは、動的な位置計算やユーザー操作に応じた一時的な値など、適切な用途で利用される場合があります。一方で、色、余白、文字サイズ、角丸などの固定値を大量にインラインで指定している場合は、共通トークンやコンポーネントを迂回して独自の値を追加している可能性があります。この状態が増えると、同じ見た目を実現するための方法が複数存在し、後から一括変更することも難しくなります。

コード例：インラインスタイル候補を探す

grep -R "style={{" src/

検索後は、すべてのインラインスタイルを問題として扱うのではなく、動的な値と固定的なデザイン値を分けて確認します。例えばユーザーの操作位置に応じて変化する座標は許容し、ブランドカラーや標準的な余白などは共通トークンへ移行する、といった基準を設定できます。単純にインラインスタイルを全面禁止するのではなく、どの種類の値が負債を生みやすいのかを明確にルール化する方が、実際の開発現場では運用しやすくなります。

13.4 繰り返し問題を静的検査へ変換する

監査を行うたびに同じ問題が発見されるのであれば、人間が毎回コードを検索するのではなく、自動検査へ移行できる可能性があります。例えば、廃止済みコンポーネントの新規利用、特定の直接色指定、フォーカス表示を無効化する記述、禁止されたスタイルパターンなどは、一定の条件を決めれば機械的に検出できます。これにより、監査は過去に発生した負債を探す作業から、新しい負債の発生を早期に検知する仕組みへ変えられます。

コード例：禁止候補を簡易確認する

const forbiddenPatterns = [
 /LegacyButton/,
 /outline:\s*none/,
 /#[0-9a-fA-F]{6}/
];

function inspectSource(source) {
 return forbiddenPatterns.filter((pattern) => {
   return pattern.test(source);
 });
}
 

実際の運用では、最初から大量のルールを導入するのではなく、誤検出が少なく、判断基準が明確なルールから段階的に導入することが重要です。検出結果のほとんどが正当な例外であったり、毎回手動で無視する必要があったりすると、開発者が警告そのものを無視するようになります。そのため、ルールごとに例外方法や修正方法も定義し、実際の開発フローの中で継続的に利用できる精度を維持する必要があります。

13.5 指標を定期取得して負債の増減を見る

一度の監査で「直接指定が500件存在する」と分かっても、その数字だけでは改善しているのか、別の問題が増えているのかを判断できません。翌月に400件へ減っているのであれば改善が進んでいると判断できますが、600件へ増えているのであれば、新しい負債が既存の改善速度を上回っている可能性があります。そのため、単発の件数ではなく、同じ条件で継続的に計測して変化を見ることが重要です。

旧部品の利用数、直接色指定の数、未使用トークン数、独自コンポーネント数、非推奨部品の残存数など、自動計測できる指標を定期的に保存します。さらに、単純な総数だけでなく、前月比や削減率、増加率なども確認すると、改善活動が実際に効果を出しているか判断しやすくなります。こうした指標を継続的に取得することで、監査を一度だけ実施するイベントから、デザイン品質を継続的に管理する仕組みへ変えることができます。

14. 改善と同時に新しい負債の発生を防ぐ

既存の負債を修正している間にも、新しい機能開発は続きます。毎月10件の負債を解消しても15件増えているなら、全体状況は悪化しています。そのため監査後は、既存問題の解消と新規発生の防止を同時に進める必要があります。

新規開発を止めて負債だけを修正する必要はありません。新しい画面では最新部品を使う、独自部品追加時に軽いレビューを入れるなど、通常開発へ小さな防止策を組み込むことが重要です。

14.1 新規画面では最新の標準部品を優先する

既存画面に旧部品が多数残っているからといって、新しく作る画面でも同じ旧部品を利用すると、移行対象は減るどころか増え続けます。既存画面を少しずつ改善していても、新規開発によって旧部品の利用箇所が追加されれば、全体として負債を削減できない状態になります。そのため、新規開発では原則として最新の標準部品を利用し、旧部品は既存画面との互換性を維持するために限定して残すようにします。

新規画面から負債を増やさない状態を作れば、既存画面を段階的に移行するだけでも製品全体に占める旧部品の割合を徐々に下げられます。また、単にガイドラインへ「旧部品を使わない」と書くだけでは、担当者が知らずに利用する可能性があります。旧部品の新規利用を静的検査で検出したり、コードレビューで警告したりすることで、ルールを実際の開発フローへ組み込むことが重要です。

14.2 独自部品追加前に再利用可能性を確認する

既存部品では要件を満たせないと感じたとき、すぐに新しいコンポーネントを作成すると、似た役割を持つ部品が増え、将来的な重複や使い分けの混乱につながります。新しい部品を作る前に、既存部品へ正式なバリエーションを追加できないか、既存の別部品で対応できないか、同じ要件が他の画面にも存在していないかを確認します。特に複数チームで同じような独自部品が作られている場合は、共通部品として整理する価値が高くなります。

ただし、すべての新規部品を共通ライブラリへ集約する必要はありません。特定画面だけで使用する特殊な表現や、その画面固有の情報構造まで共通化すると、共通部品側の条件分岐が増えてしまいます。そのため、短い相談や簡単な提案手順を設け、再利用可能な要件なら共通部品へ追加し、特定領域だけの特殊要件ならローカル部品として閉じる、という判断を素早く行えるようにします。

14.3 新規追加と旧部品廃止をセットで考える

新しいコンポーネントを追加するだけでは、製品内の選択肢が一つ増えるだけで、既存の負債が自動的に解消されるわけではありません。旧部品をいつまで利用できるのか、どの部品へ移行するのか、最終的にいつ削除するのかまで決めなければ、開発者は新旧どちらを使うべきか判断し続けることになります。その結果、旧部品が長期間残り続け、新しい部品との二重管理が発生します。

新しい部品を正式採用する時点で、移行先、移行対象、廃止予定日、新規利用禁止日などを定義しておくと、コンポーネントのライフサイクルを管理しやすくなります。また、コード側だけで旧部品を非推奨にするのではなく、デザインライブラリ側でも同じ状態を表示し、デザイナーと開発者が同じ判断をできるようにします。追加と廃止を一つの計画として扱うことで、部品数が無秩序に増えることを防げます。

14.4 デザインレビューへ負債防止項目を組み込む

新しい画面のデザインレビューで見た目やレイアウトだけを確認していると、既存コンポーネントとの重複、新しいトークンの乱立、既存用語との不一致などを見逃す可能性があります。例えば「このUIは既存部品で実現できないか」「新しい色を追加する本当の理由はあるか」「既存の用語と一致しているか」「既存パターンと異なる状態を追加する必要があるか」といった観点を確認することで、設計段階から負債の発生を抑えられます。

ただし、レビュー項目を増やしすぎると通常の開発速度を低下させるため、すべてを細かく確認するのではなく、過去の監査で繰り返し発見された問題を中心に少数の重要項目へ絞ることが重要です。監査で「毎回同じ問題が見つかる」のであれば、その問題をレビュー項目へ戻すことで、発生後に修正するだけでなく、設計段階で防止できるようになります。

14.5 コードレビューにも設計基盤の観点を追加する

デザインファイルが標準部品や正式なトークンを利用していても、実装時に直接色を指定したり、独自CSSを追加したり、既存コンポーネントとは異なるHTML構造を作ったりする場合があります。そのため、デザイン側のレビューだけで負債の発生を防ぐことはできません。実装が設計基盤から外れていないかを、コードレビューの段階でも確認する必要があります。

コードレビューや静的検査では、旧部品の新規利用、トークン外の直接指定、不要な独自スタイル、意味のないHTML構造、既存コンポーネントで代替可能な独自実装などを確認します。すべてを人間が判断するのではなく、機械的に検出できるものは自動検査へ移すことでレビュー負担も抑えられます。デザインと開発の双方が同じ品質基準を持ち、設計段階と実装段階の両方で確認することで、既存負債を減らすだけでなく、新しい負債が蓄積する入口そのものを小さくできます。

15. デザイン負債監査を継続的な製品運用へ組み込む

数年に一度だけ大規模監査を行うと、毎回大量の問題が見つかり、修正計画も大きくなります。監査が特別なイベントになるほど、通常の製品開発から切り離され、結果が実行されない可能性も高くなります。

小規模な監査を定期的に行い、デザインシステム更新や主要機能開発と組み合わせることで、問題が大きくなる前に発見できます。最終的には「監査をする」より「常に状態を把握できる」運用へ移行することが理想です。

15.1 四半期ごとに対象を変えて小規模監査を行う

毎回製品全体を一度に監査する必要はありません。対象範囲が広すぎると、確認項目が表面的になり、問題を発見しても改善計画まで十分に整理できない場合があります。そのため、第一四半期はフォーム、次はナビゲーション、その次は設定領域というように対象を分け、各回の監査で一つの領域を深く確認する方法が有効です。特に過去の監査で問題が集中していた領域や、最近大きく変更された領域を優先すると、監査の効果を高められます。

また、新しい問題を探すだけではなく、前回監査で登録した改善項目の進捗も同時に確認します。旧部品の利用数が減っているか、改善項目の完了条件を満たしているか、修正後に同じ問題が再発していないかなどを確認することで、発見と改善確認を一つの運用へまとめられます。継続的に実施することで、監査で使用するチェック項目や計測方法自体も改善でき、製品に合った監査プロセスへ徐々に最適化できます。

15.2 負債件数だけを成果指標にしない

100件のデザイン負債を50件へ減らしたとしても、その中に重大な操作不能問題やアクセシビリティ問題が残っていれば、製品品質が十分に改善したとは言えません。反対に、軽微な視覚的不整合が多少残っていたとしても、購入や登録など主要なユーザーフローが大きく改善されているのであれば、実際の製品価値は大きく向上しています。そのため、単純な負債件数だけを成果指標にすると、重要度の低い問題ばかりを優先して件数を減らすような判断につながる可能性があります。

高影響問題の残存数、旧コンポーネントの利用率、標準部品の採用率、アクセシビリティ問題数、主要フローでの問題数など、複数の指標を組み合わせて評価します。さらに、ユーザーからの問い合わせや操作成功率など、利用体験に近い指標を利用できる場合は合わせて確認します。重要なのは「何件減ったか」だけではなく、ユーザー体験と開発効率が実際に改善しているかを継続的に確認することです。

15.3 解消数と新規発生数を同時に追跡する

毎月どれだけの負債を解消したかだけを確認していると、その裏で新しい負債が同じ速度、あるいはそれ以上の速度で増えていることに気付けない場合があります。例えば月に20件を解消していても、毎月25件の新しい負債が発生していれば、全体としては改善していません。そのため、既存負債の解消数と、新しく発見または発生した負債数を分けて記録します。

新規発生数が継続的に減少していけば、デザインレビュー、コードレビュー、静的検査、デザインシステムなどの予防策が機能している可能性があります。一方、解消数だけが増えて新規発生数が変わらない場合は、既存問題を処理する仕組みは改善していても、負債を生み出す原因は残っていると判断できます。こうした両方の指標を見ることで、「負債を減らせる組織」だけでなく「負債が生まれにくい組織」へ変化しているかを確認できます。

15.4 デザインシステム利用率と品質を合わせて見る

共通コンポーネントの利用率が高くなれば、画面間の一貫性を維持しやすくなり、個別実装の重複も減らしやすくなります。しかし、共通部品そのものにアクセシビリティ上の問題や操作上の不具合が存在する場合、その問題が多くの画面へ同時に広がる可能性があります。そのため、「標準部品をどれだけ使っているか」だけを成功指標にするのは危険です。

標準部品の採用率と合わせて、アクセシビリティ問題数、共通部品に起因する不具合数、ユーザーからの指摘、操作成功率などを確認します。利用率が高く、かつ品質も維持されている状態を目標とすることで、単純な共通化ではなく、信頼できる設計基盤を作ることができます。また、問題のある共通部品については利用率をさらに上げる前に修正するなど、品質と普及率をセットで管理することも重要です。

15.5 負債改善を通常の製品計画へ統合する

デザイン負債を「時間が余ったときに直すもの」として扱うと、通常の機能開発や売上に直結する施策が常に優先され、改善が後回しになり続けます。一方で、毎回まとまった期間を確保して大規模な負債改善を行う方法も、製品開発のスケジュールやチーム体制によっては継続が難しくなります。そのため、負債改善を特別なイベントではなく、通常の製品計画へ組み込むことが重要です。

例えば、既存機能を改修するときに関連する旧コンポーネントも同時に移行する、四半期ごとに一定の開発容量を共通基盤や負債改善へ割り当てる、重大なアクセシビリティ問題は通常の優先順位とは別に必須対応として扱う、といった方法があります。こうした仕組みを継続することで、負債が一定量蓄積してから大規模に対応するのではなく、日常的な開発の中で少しずつ解消できるようになります。最終的には、負債改善を「追加の仕事」ではなく、製品品質と開発速度を維持するための通常業務として扱える状態を目指します。

おわりに

デザイン負債監査で最も重要なのは、製品内に存在する細かな違いを大量に見つけることではありません。同じ役割の部品がなぜ複数存在するのか、なぜ直接指定が増え続けるのか、なぜ古い画面だけ異なる操作方法を持つのかという原因まで遡り、ユーザー体験と開発体制の両方へ影響している構造的な問題を見つけることが本当の目的です。単純に「見た目が違う」「このボタンだけサイズが違う」といった表面的な差異を列挙するだけでは、負債が生まれた背景や、同じ問題が繰り返される理由を把握できません。画面だけを修正しても根本原因が残っていれば、数か月後には別の場所で同じ負債が発生し、結果として修正作業だけが積み重なっていきます。

そのため、監査ではデザインファイル、実際の画面、コンポーネント、デザイントークン、コード、文言、情報構造、アクセシビリティ、更新プロセスを横断的に確認する必要があります。デザイン上は統一されていても実装側で別の値が指定されている場合や、共通コンポーネントとして定義されていても実際には各画面で独自のスタイルが追加されている場合など、単一の成果物だけでは発見できない問題も多く存在します。発見した問題はユーザー影響、利用頻度、影響範囲、修正コスト、再発可能性によって評価し、単なる修正項目ではなく、原因単位の改善バックログへ変換します。共通コンポーネントやトークン、設計ルールなど根本原因を改善できれば、一度の修正で多数の画面を改善でき、個別対応を繰り返すより大きな効果を得られます。

さらに、既存負債を減らすことだけでは十分ではありません。監査によって一度すべてを整理しても、日々の開発プロセスで同じような独自実装が追加され続ければ、デザイン負債は再び増加してしまいます。そのため、新規画面では標準部品を優先して使う、独自コンポーネントを追加する前に既存部品を確認する、旧部品には廃止期限や移行先を設定する、コード上の禁止パターンを自動検出するなど、新しい負債を生みにくい仕組みを通常開発へ組み込む必要があります。また、デザイン側だけでルールを管理するのではなく、デザイナーとエンジニアが同じ基準で判断できる状態をつくることも重要です。デザイン負債監査を一度限りの清掃活動ではなく、製品品質を継続的に観測し改善する仕組みとして扱うことで、UI・UXの一貫性だけでなく、開発速度、保守性、チーム間の共通理解まで長期的に向上させることができます。