形骸化を防ぐデザインハーネスの運用術
エラーの山は一気に全部直さない
各種linterを導入すると、大量のエラーが検出されることがあります。私が支援したプロダクトで20ほどの画面を検証した際には、1,112件のエラーが検出されました。数値の大きさに驚きますが、原因を分析すると大半が「視認性の低い色の使用」に起因しており、トークン側の定義を1〜2箇所修正するだけで数件〜数百件単位のエラーを一気に解消できる状態でした。
最初に実施すべき作業は、エラーの修正ではなく「現在のエラー件数を記録すること」です。以降は「この件数から増やさなければ許容する」というルールで運用を開始し、既存コードの一括修正は求めません。
「エラー数は多いが、トークンの修正で広範に改善できる」といった構造まで分解して提示すれば、コード修正に馴染みの薄いデザイナーであっても、優先して修正すべきポイントを自ら判断できるようになります。エラーの数値だけを渡すのではなく、エラーの背景にある構造を示すことが重要です。
大量のエラーを発見すると0件を目指して修正したくなりますが、既存のエラーを解消して操作性を向上させる取り組みは、ハーネス構築とは別のプロジェクトとして扱うべきです。既存のエラーには一旦蓋をし、これから新しく生成されるコードの遵守率を高めることに集中します。既存ページを通常の機能改修で触る過程で、デザインと使いやすさが自然に向上していく状態を目指します。
あわせて、チェックがどのように回避されているかも観察します。インラインスタイルへの直接記述や、トークンを装った独自変数の定義といった回避行動が確認された場合は、それを次のルールの対象として追加します。
ルールは「育てる」よりも「削る」
ルールは無制限に増やすのではなく、一覧化していつでも削除できる状態を維持します。検出数がゼロのまま経過しているルール、誤検出が多いルール、前提条件が変更されたルールは削除します。AIにルールを生成させると記述が肥大化し、結果としてAI自身も参照しづらくなるためです。
先行するチームでは、古くなったルール記述を検知して修正のプルリクエストを出す巡回エージェントまで運用している事例もありますが、そこまでの仕組みを構築せずとも「整理に時間をかける」より「機能しなくなったら捨てて作り直す」という方針を優先する方が、ルールの鮮度を保ちやすくなります。
ルールが機能しない場合、その原因が別の構造にあるサインでもあります。例えばプライマリボタンの数を制限するルールを設けたにもかかわらず、人間のレビューを経ても削減できなかったとすれば、問題はボタンの数ではなく画面内に配置された要素全体の設計にあります。ハーネスの限界は、ドメインモデル側の課題を浮き彫りにします。これはハーネスの失敗ではなく、構造上の問題を検知できたことを意味します。
ハーネスで体験の「下限」を担保し、人間が「上限」を広げる
デザインハーネスとは、ハーネスエンジニアリングの骨格を活用し、ユーザー体験の下限を機械的に保証した上で、より良い体験の探求を人間が担うよう設計された仕組みです。品質低下を防ぐ「床」はハーネスが形成し、目指すべき「天井」の高さは人間が決定します。
ハーネスが提供するのはガードレールです。体験が極端に悪化することは防げますが、既存の慣習にない革新的な体験が自動的に生まれるわけではありません。その部分はハーネスの対象外であり、人が取り組むべき領域となります。
まずは今日、「使いづらい」と指摘のある画面を1つ選び、AIに改善案を出させた上で、自身の判定とその理由を記録することから始めてみてください。それが最初のルールの原石となります。ルールが整備された環境では、CIを通過した画面は個人のセンスではなく「仕組みの責任」においてリリースされるため、「なぜこのデザインにしたのか」という問いに対しても根拠を持って説明できるようになります。その状態を構築する具体的な手順について、次回以降詳しく掘り下げていきます。
