1. はじめに
どうも、エンジニア＆デザインを担当しているタクシです。
最近、デザイナーとの協業の仕組みを整えまして、手始めにデザインレビューを導入することにしました。
今はAI時代！GeminiやClaudeを使ったりもしつつ、、ではありますが、そもそもレビューに参加する経験自体がまだ浅いです。そのため、やり方を試行錯誤しつつ、毎回新しい発見があります。
一方で、自分自身がデザインを手がける場面では、ここしばらく「実装に入ってから気づくこと」が積み重なってきていました。
そろそろ、自分の中で観点を一度整理しておきたい。これからレビューに参加する機会も増えていくはずなので、その前提となる土台を作っておこう。そう考えて、自分なりのチェックリストを作ってみました。
この記事は、その整理の過程と、その中で考えたことをまとめたものです。社内の現状に合わせて、これから工夫していきたいという方向性を記録するものです！
2. 整理を始めたきっかけ
きっかけは、自分自身のデザイン作業で繰り返し感じていたことでした。
実装に入ってから「このケースを考慮していなかった」と気づくことが、少なくないのです。文字列が極端に長いケース、データが0件のケース、エラー状態の遷移先など、設計段階で押さえておくべきだった観点を、後工程で発見してしまう。
これは個人の注意力の問題というより、観点を体系化していない状態で目視チェックすること自体の限界だと感じていました。新しいプロジェクトだと、早々に実装を進めるためにデザインの時間を短縮したいという気持ちもあり、色々抜けてしまうことが多いです。
そして、これからデザインレビューに本格的に参加していくにあたって、同じ穴に落ちる予感がありました。自分の設計時に拾いきれなかった観点を、他の人のデザインを見る時にだけ毎回完璧に拾えるとは思えなかったからです。観点が体系化されていないまま進むと、毎回違う指摘をしてしまう可能性が高いでしょう。
そう感じて、今のうちに自分の中の観点を一度整理しておくことにしました。整理して誰がみてもわかる判断基準ができれば、より効果的にAIも使えそうです。
3. チェックリスト設計の思想
整理を始めるにあたって、最初に目指すのは「完璧なリストより、現実的に運用できるリスト」です。
ネット上で見かけるアクセシビリティチェックリストやUIレビューのテンプレートはどれも網羅的で理想です。ただ、ああいったリストを業務で使う場面を想像すると、項目が多すぎて毎回全部を確認するのは現実的ではないと感じていました。仕様変更が頻繁に起きる中で、リスト自体がメンテナンスされず形骸化していくような気がしました…
そこで、チェックリストは次の二層構造で設計することにしました。（あくまで準備段階なので、チェックリストはClaudeを使って壁打ちしながら作成した草案です。なので丸々このままを使うわけではありません）
コア項目
- 毎回必ず確認する
- プロダクトや機能が変わっても基本的に変わらない、普遍的な観点
- 数は意識的に絞り、運用負荷を抑える
文脈依存項目
- プロジェクトや機能の性質に応じて追加で確認する
- 「使うかもしれないリスト」として手元には持っておくが、必須ではない
この二層に分けることで、コアは常に同じ精度で見つつ、文脈依存は機能の性質に合わせて選ぶという運用ができます。リスト全体としては網羅的でありながら、毎回の確認作業はミニマルに保てる、というのが狙いです。
4. 5つのカテゴリと観点
整理した結果、チェックリストは5つのカテゴリに分かれました。各カテゴリにコア項目と文脈依存項目を設定しています。
4.1 状態の網羅性
現時点で最も漏れが発生しやすいカテゴリです。「ハッピーパス以外の状態が定義されているか」を体系的に確認します。
コア項目
- 初期表示状態
- ローディング状態
- 空状態(Empty)
- エラー状態(通信/バリデーション/権限の区別)
- 成功状態
- デフォルト / ホバー / フォーカス / アクティブ / 無効
- 状態間のトランジション定義
文脈依存項目
- 権限による表示差分
- 一時的状態(トースト、ツールチップ等)
- 通知・バッジ系の付加情報状態
- 選択中(Selected)/ 読み取り専用(Readonly)
- 部分的失敗 / 楽観的更新
このカテゴリで意識したいのは、デザインカンプに描かれていない状態を能動的に問うことです。「ローディング中はどう見せるか」「エラーが返ってきたらどうするか」といった問いは、設計段階で見落としていた場合に最も価値が高くなります。
4.2 アクセシビリティ
デザインレビュー段階でFigma上の目視確認ができる項目に絞り、スクリーンリーダー対応のように実装後の検証が必要な項目は文脈依存に回しています。
コア項目
- テキストのコントラスト比(通常4.5:1 / 大きいテキスト3:1以上)
- 色のみに依存した情報設計になっていない
- フォーカスインジケーターが視認可能
- フォームのラベルと入力欄の関連付け
- エラーメッセージの位置と内容
文脈依存項目
- タップ領域サイズ(モバイル比重が高い場合)
- インタラクティブ要素の視覚的識別性
- 見出し階層の論理性
- 画像の代替テキスト方針
- スクリーンリーダー対応 / ARIA
- キーボードナビゲーション順序
prefers-reduced-motion対応- スキップリンク / フォーカストラップ
このカテゴリで重要なのは、「全部やる」を目指さないことです。完璧を目指すと運用が破綻するため、まずコントラストとフォーカスから始め、運用が定着してから範囲を広げていく方針が現実的だと考えています。
現状だと、実装段階でAIコードレビューの指摘を都度修正して対応していますが、今後はデザイン→コードのフロー内でチェックできるように仕組み化をしたいと思っています。
4.3 可変性
タイトルに「レスポンシブ」ではなく「可変性」を使っているのは意図的です。担当しているプロダクトはデスクトップ中心で、画面サイズに対する耐性よりも、コンテンツとコンテナの伸縮耐性の方が日常的に必要になるためです。
コア項目
- テキスト長の上下限が想定されている
- テキストの折り返し / 省略方針
- 画像の比率・トリミング方針
- 可変要素と固定要素の区別
- 要素間の余白の振る舞い
文脈依存項目
- ブレークポイント / レスポンシブ対応
- 印刷時のレイアウト
- ブラウザのフォントサイズ変更・ズーム耐性
- ダークモード
このカテゴリで意識したいのは、デザインカンプは代表的な1枚でしかないということです。エンジニアはあらゆるコンテンツ長を想定して実装する必要があるため、「文字が長かったら」「画像の比率が違ったら」を問うことが、後工程の手戻りを減らします。
次のデータ表現と並行して考えることで、より実データを想定したデザイン指示ができるようにしていきたいです。
4.4 データ表現
実データを想定した堅牢性を確認するカテゴリです。デザインカンプ上のサンプル値が、本番で想定しうるケースを表現できているかをチェックします。
文字列と件数に絞ってコア項目を定義しています。数値や日時はフォーマットが決まれば再発しにくい一方、文字列とデータ量は機能ごとに新しい想定が必要になるためです。
コア項目
- 想定文字種の網羅(日本語 / 英語 / 記号 / 数字混在)
- 特殊文字の扱い(改行、絵文字、HTML特殊文字)
- 省略表示の基準と展開UI
- 0件状態(フィルタ結果0件など文脈別含む)
- 1件のみの状態
- 大量件数時の表示方針
文脈依存項目
- 数値の桁数・単位表記・ゼロ/負値の扱い
- 日時のフォーマット統一、相対/絶対の使い分け
- 状態・ラベルの色対応と語彙統一
- 多言語対応時の文字列長変動
- 通貨・地域別フォーマット
- 個人情報・機密情報のマスキング
このカテゴリの背景にあるのは、サンプルデータは常に理想的で美しく、本番データは常にバリエーション豊かで予測不能という現実です。デザインカンプのモック値は読みやすさのために整えられているため、「この値が極端だったら」「想定外の文字が入ったら」を必ず問うようにしたいと考えています。
4.5 実装コスト・パフォーマンス
このカテゴリは他と性質が違います。「デザインの良し悪し」を判断する観点ではなく、「実装側の制約・コストをデザイン段階で共有する」観点群です。デザイナー単独では判断できない情報をエンジニアが提供することで、後工程の手戻りや負債を最小化します。
デザインエンジニアとしてレビューに関わる価値が、このカテゴリに集約されるとも言えます。
コア項目
- 既存パターンとの整合性
- 実装難易度の見積もり共有
- 例外処理がデザインに組み込まれているか(時間制約時は実装フェーズで対応する場合あり)
文脈依存項目
- 類似機能との統合可能性
- 代替案の提示
- アニメーション・トランジションの負荷
- 初期表示パフォーマンス
- 再レンダリング誘発要因
- 仕様変更時の影響範囲
- 特殊ケースの汎用化余地
特に意識したいのは「既存パターンとの整合性」です。デザインシステムが未整備な現場では、レビューの場が事実上のパターン形成の場になり得ます。「これは既存の◯◯と同じ扱いにしましょう」「ここで新パターンを作るなら理由を明確に」といった会話を積み重ねること自体が、将来のデザインシステムの種になっていくと感じています。
ここではエンジニアとしての観点が一番生きると考えています。UIライブラリなどが多く存在する中で、プロダクトごとで異なるライブラリ仕様などを把握しているからこそ、流用するべき部分は流用できるように。また自社開発である強みを活かしながら、自由度も保ち、一貫性をもったプロダクトデザインを目指したいです。
5. 運用上の前提
ここまで5つのカテゴリで観点を整理してきましたが、運用していく上では「チェックリスト通りに毎回完璧に確認する」ことを目指さない方が現実的だと考えています。リストの使い方そのものを状況に合わせて柔軟に変えていく前提で、いくつか方針を整理しておきます。
時間制約下での妥協
レビューや設計に割ける時間は、プロジェクトの状況によって大きく変わるはずです。リリース直前で時間が取れない場合、コア項目の中でも優先順位を付けて、本当に致命的なものだけを確認するという判断も必要になりそうです。
例えば、実装コスト・パフォーマンスの「例外処理がデザインに組み込まれているか」という項目は、時間がある時はレビュー段階で拾いたいですが、特別早くユーザーに届けたい開発の場合など時間がない時は、実装フェーズで補完する前提で先に進めるという選択もあるはずです。
完璧主義に陥ってリスト全項目を毎回回そうとすると、確認作業自体がボトルネックになります。コードレビューにおいて確認項目が肥大化してしまう課題と同様です。「全部やる」ではなく「何を妥協するかを意識的に選ぶ」という運用の方が、結果として品質を保てると考えています。
設計フェーズで拾う / 実装フェーズで拾うの判断
すべての観点を設計やレビュー段階で拾う必要はないと考えています。
例えばアクセシビリティのスクリーンリーダー対応は、Figma上では検証できず、実装後のテストでしか確認できません。こうした観点を設計段階に無理に持ち込んでも、判断材料が揃わないため議論が空転する懸念があります。
「この観点はどのフェーズで拾うのが最も効率的か」という視点でリストを整理した結果、コア項目はデザインの段階で完結できるものに絞り、実装後の検証が必要なものは文脈依存項目として手元に置く構成になっています。
ただ、これはあくまで現状の我々のやり方に沿ったものです。今後はAIデザインツールなどを利用することで、プロトタイピングの段階で拾える項目は増えると思います（Claude Designなど）。そのため、段階的にですが、詳細なチェックリストの運用も大きな負担なくできるようにもなるのではと考えています。
プロダクト特性による重点の違い
このチェックリストはあくまで自分の現場での運用を想定しています。プロダクトの性質が変われば、重点を置くカテゴリも当然変わるはずです。
例えば、自分の場合は可変性カテゴリで「レスポンシブ対応」を文脈依存項目に回しました。担当しているプロダクトがデスクトップ中心で、画面サイズへの耐性よりもコンテンツの伸縮耐性の方が日常的に必要だからです。一方、モバイルアプリやレスポンシブWebサービスを担当する人にとっては、ブレークポイント関連が間違いなくコア項目になるでしょう。
リストは画一的なテンプレートではなく、プロダクトの性質に合わせて重みづけを変えていくものだと捉えています。
様々なプロダクトを展開しているので、ガチガチに仕組みを作るんだ！というわけではなく柔軟に、デザイナーにもエンジニアにも優しいデザインプロセスを構築していきたいです。
6. レビューと設計を行き来する立場として
ここまで観点を整理してきて、改めて感じるのは「自分が立っている場所」のことです。デザインエンジニアとして、設計する側とレビューする側の両方を行き来する立場だからこそ、このチェックリストには独自の意味があるのではないかと考えています。
実装視点を「翻訳者」として持ち込む
デザインを実装する側にいると、デザイン段階では見えにくい制約が日常的に見えています。既存コンポーネントの再利用可能性、特定の表現の実装コスト、データの可変性に対する堅牢性。これらはデザイナー単独では判断材料が揃いにくい領域です。
レビューに参加するときに自分が提供できる価値の一つは、こうした実装側の現実をデザイン段階で先取りして共有することだと考えています。実装に入ってから「これはコストが高いです」と伝えても遅い。デザインがまだ動いている段階で「この表現はAパターンに比べてBパターンの方が再利用性が高い」「ここで新規実装するなら工数がこれくらい増える」といった情報を渡すことで、デザイナーは意思決定に必要な材料を揃えられます。
見た目はシンプルでも実際の現場ではコストがかかるものもあります。特に長年運用しているプロダクトなどの場合、レガシーコード的なものが残り、それが実装のネックになることも少なくありません。
レビューがデザインシステム形成の種になる
デザインシステムが未整備な現場では、レビューの場が事実上のパターン形成の場になり得ます。
デザイナーとキャッチボールしながら、問題点の整理や良いデザインの視点を共有したり、財産となるものを積み上げることができます。
デザインシステムを一気に整備するのは大変ですが、レビューを通じて少しずつパターンを言語化し、共通認識を蓄積していくことはすぐにでも始められそうです。レビューに参加することは、その蓄積を加速させる効果があるのではないかと感じています。
7. おわりに
ここまで紹介してきたチェックリストは、現時点で自分が手元に持っている叩き台のようなものです。これから実際の設計やレビューの現場で使いながら、項目の追加・削除・分類の見直しを続けていく予定です。
完璧なリストを目指しているわけではなく、「自分の現場で運用できる、最低限のもの」を継続的に育てていくというスタンスでいます。誰かにとっての完成形ではなく、自分の現場に合わせて変わり続けるものとしてのリスト。それがこの記事の出発点であり、現在地です。
デザイン知識や経験もまだまだな私。これからもイイモンを作るためには何ができるか勉強して模索していこうと思います！
この記事を読んで少しでもｉｉｍｏｎに興味を持ってくださった方がいらっしゃいましたら、まずはカジュアルにお話しましょう！ ぜひお気軽にご応募ください！
iimon採用サイト / Wantedly / Green
