AIが作るデザインの レビューコストと向き合って分かったこと. -正社員デザイナー1人の組織でデザインハーネスを立ち上げた話-

Transcript

1. デザインハーネス The Beginning 2026.10.29 AIが作るデザインの レビューコストと向き合って分かったこと 正社員デザイナー1人の組織でデザインハーネスを立ち上げた話 家高 秀樹 ／ プロダクトデザイナー 0:00 – 0:15 01 / 20
2. はじめに こんな方に向けて話します 組織のデザイナーが少ない AIでデザインしたいが、何から始めればいいか分からない AIで作り始めたが、レビューが大変 今日の話 0:15 – 0:35 明日から真似できる話です。デザインハーネスを導入して、ぶつかった壁をどう越えてきたかを話します。 02 / 20
3. デザイン体制 正社員デザイナー 1人で、全プロダクトを見ています 2026年2月 入社 一人目の正社員デザイナーとして入社。業務委託デザイナーと一緒に動いている。 6プロダクト 全部を横断して見る Biz 0:35 – 1:05 03 / 20
4. デザインハーネス導入前 1人のデザイナーが、頭の中のルールで回していたころ 導入前 導入後 これから
5. デザインハーネス導入前 デザインの判断が、自分ひとりに属人化していた UIコンポーネント集はあった。でも「どれをいつ使うか」は書かれておらず、 自分がレビューすることで、なんとか回っていた。 UIコンポーネント集 自分の頭の中 どこにも書いていない細かいルール 「登録」と「保存」の使い分け セクションの間はこの余白、カードの中はこの余白 ＋ 色の乗った背景の上では、文字色を一段濃くする 危険な操作のボタンは、この位置にこの色で ※DSの部品見本の一部。表示中のデータはダミーです 1:10 – 1:40 04 / 20
6. デザインハーネス導入前 デザインの判断が、自分ひとりに属人化していた UIコンポーネント集はあった。でも「どれをいつ使うか」は書かれておらず、 でも、開発のスピードが上がるほど 自分がレビューすることで、なんとか回っていた。 デザインがボトルネックになってきた UIコンポーネント集 自分の頭の中 どこにも書いていない細かいルール 「登録」と「保存」の使い分け ▼ セクションの間はこの余白、カードの中はこの余白 なので、エンジニアにAIでデザインを作ってもらうことにした ＋ 色の乗った背景の上では、文字色を一段濃くする 危険な操作のボタンは、この位置にこの色で ※DSの部品見本の一部。表示中のデータはダミーです
7. デザインハーネス導入前 デザインの判断が、自分ひとりに属人化していた UIコンポーネント集はあった。でも「どれをいつ使うか」は書かれておらず、 でも、開発のスピードが上がるほど 自分がレビューすることで、なんとか回っていた。 デザインがボトルネックになってきた UIコンポーネント集 自分の頭の中 どこにも書いていない細かいルール 「登録」と「保存」の使い分け ▼ セクションの間はこの余白、カードの中はこの余白 なので、エンジニアにAIでデザインを作ってもらうことにした ＋ 色の乗った背景の上では、文字色を一段濃くする 危険な操作のボタンは、この位置にこの色で ※DSの部品見本の一部。表示中のデータはダミーです 柔軟に引き受けてくれた エンジニアチームに感謝
8. デザインハーネス導入前  問題 エンジニアが作るデザインは増え続ける レビューするのは自分とPdMだけ さらにエンジニア採用が進む。サービスも増える。でもデザインルールはデザイナーの頭の中のまま。 よくあった指摘 1:50 – 2:20 「登録」と「保存」が混在 既存画面とボタン位置が違う 余白に強弱がない 要らない説明文 05 / 20
9. デザインハーネス導入後 ルールを書き出し、AIに渡し始めてから 導入前 導入後 これから
10.  やったこと ルールをハーネス化 書かれたルールがない状態から、 頭の中のルールを明文化してSkillに AIで実装をインベントリし、実態に即したルールを作っていった。「どれをいつ使うか」は自分で書き足した。  実装をAIでインベントリ リポジトリから部品・色・文言を洗 い出す ＋ Skill｜AIに渡せるルール どれをいつ使うか 例：新規は登録、変更は保存 ▶ ※Skillファイルの一部（表記を簡略化）  支援：小木曽さん（Lumilinks） 新しいDSのStorybookへの集約、Skill配布の一本化 2:25 – 3:00 06 / 20
11.  やったこと ルールをハーネス化 書かれたルールがない状態から、 頭の中のルールを明文化してSkillに AIで実装をインベントリし、実態に即したルールを作っていった。「どれをいつ使うか」は自分で書き足した。 Skillで、レビューの指摘は一定数減った Skill｜AIに渡せるルール  それでも、指摘はまだ多い ＋ 実装をAIでインベントリ どれをいつ使うか リポジトリから部品・色・文言を洗 い出す 例：新規は登録、変更は保存 ▶ ※Skillファイルの一部（表記を簡略化）  支援：小木曽さん（Lumilinks） 新しいDSのStorybookへの集約、Skill配布の一本化
12.  気づき Skill化のあと、指摘の内訳 自分の指摘を調べて分類すると、多かったのは 「文言の整合性」「既存画面との整合性」「DSのルール違反」 デザインレビューでの指摘の内訳（主に自分が指摘・6プロジェクト） 表記ルール（句点・例：など） 9% トークン・色・スタイル 11% 寸法・余白 12% DS部品の使い方 6% キャンバスの整理 6% 決定・プロトの反映漏れ 10% 画面間の不整合 10% 用語のゆれ ▶ 既存画面・ルールと比べて見つかる ▶ PRで作る・前例索引で減らし始めた 9% 3% ▶ まずここをLintに任せた 比べないと分からない 41% 8% 状態の漏れ・矛盾 3:05 – 3:40 ▶ 12% 既存仕様・前例との相違 仕様の注記不足 Lintで拾える 44% ▶ 人の判断が要る 13% 状態の漏れなど。レビューで見る。 07 / 20
13.  やったこと ハーネスを強化 チェックをルールから切り出し、Lintとして独立させた ルールに書くだけだと、守られるかはAI次第。機械的に判定できる4割は、必ず回すLintにした。  前提 Lintで拾いやすかった 正解が1つに決まる  Lintでは難しく、人が確認 文脈で正解が変わる 表記のゆれ・NG語 情報のヒエラルキー トークン外の色 余白の強弱 グリッド外の余白・文字サイズ その要素は要るか 手組みの部品 既存画面との整合 すべてをLintで拾おうとしない。今までの作業が半分に減れば十分。 3:40 – 4:10 08 / 20
14.  やったこと 既存画面との整合性への打ち手 既存画面とのズレを減らすため、 UIコンポーネントをコード化した HTMLで描き直すとズレやすい。部品をStorybookにそろえ、PRで本物を使えるようにした。 Skill ＋ Lint ▶  チャットで作る ▶  PRで作る ルールを渡す Skill ＋ Lint ＋ Storybook コード化したUIコンポーネント 4:10 – 4:25 HTMLで描き直す（これまで） 本物の部品で、実装そのものを作る（新しく） 09 / 20
15.  実験 同じ題材で比べてみた 同じチケットを、PRとチャットで作り比べてみた 条件｜同じチケット・同じSkill・同じ依頼文で作成 結果｜判断は同じ。既存画面とのズレはPRの方が少ない（手直し PR 0件／チャット 1件）  PRで作る チャットで作る コード化されたDSの部品をそのまま使う リポジトリのzipを渡して作る 出力 ドラフトPRとStorybookのプレビュー 出力 HTMLプロトタイプ 作成時間 5分 作成時間 5分 良い点 既存の見た目のまま作れる（手直し0件） そのまま実装まで終わる 良い点 複数案を作って、並べて比べやすい 案と説明を、1枚で見せられる 気になる点 案の出し分けや、説明を添えて見せるのは苦手 気になる点 描き直す分、既存とズレる（手直し1件） 向く場面 作るものが決まった小さめの改修 向く場面 新機能や、複数案の比較 4:25 – 4:55 10 / 20
16.  実験 同じ題材で比べてみた 同じチケットを、PRとチャットで作り比べてみた 条件｜同じチケット・同じSkill・同じ依頼文で作成 結果｜判断は同じ。既存画面とのズレはPRの方が少ない（手直し PR 0件／チャット 1件） AIのデザインのズレは減ってきた  PRで作る チャットで作る コード化されたDSの部品をそのまま使う リポジトリのzipを渡して作る 出力 しかし、 レビューのボトルネックは解消しない ドラフトPRとStorybookのプレビュー 出力 HTMLプロトタイプ 作成時間 5分 作成時間 5分 良い点 既存の見た目のまま作れる（手直し0件） そのまま実装まで終わる 良い点 複数案を作って、並べて比べやすい 案と説明を、1枚で見せられる 気になる点 案の出し分けや、説明を添えて見せるのは苦手 気になる点 描き直す分、既存とズレる（手直し1件） 向く場面 作るものが決まった小さめの改修 向く場面 新機能や、複数案の比較
17. お疲れさまです。一覧画面への絞り込み機能（ステータ スや期間などの条件で一覧を絞り込める機能）の追加 と、詳細画面への項目（更新日・担当者）の追加につい AIの文章は長くて、 読むのが大変 て、デザインのレビューをお願いしたく、背景と対応内 容をまとめました。少し長くなりますが、ご確認いただ けると助かります。 現状、一覧画面には検索窓しかなく、件数が増えてくる と目的のデータを探すのに時間がかかるという声が、利 用者（主に週に数回以上利用している方）から複数件寄 ※文章はイメージ せられていました。また、詳細画面では更新日や担当者 が表示されておらず、誰がいつ変更したのかを確認する ために、別の画面を開き直す必要がありました。 そこで、一覧画面の上部にステータスと期間で絞り込め るフィルタ（初期状態では折りたたみ、開くと条件を選 択できる形式）を追加し、詳細画面には更新日と担当者 の項目を追加しました。あわせて、フィルタの並び順や
18.  問題 でも楽にならなかった 原因は、Skillの外にある「要件の読み解き」だった 仕様の把握に時間がかかったレビュー依頼 約 4割 レビュー依頼の件数（5月 ▶ 9月） 約 2.4 倍以上 AIが書いたレビュー依頼は文章が長くなりがちで、何の デザインを作ってくれるエンジニアが増え、依頼も増 改修か、どこを見ればいいかをAIに読み解いてもらって えた。 からレビューしていた レビューが重い理由 5:05 – 5:35 ボタン1つの追加でも、それが最適かを判断するには、誰が・何のために押すかの理解が要る 6プロダクトを行き来するたびに、頭を切り替えるコストがかかる 11 / 20
19.  やったこと 依頼する 読み解きを減らすため、レビュー依頼の形を 「目的・概念図・Before/After・論点」に 依頼フォーマットに沿ってSkillが自動で出力（ELI5の考え方がベース）。 以前 いま Skillが自動で作るレビュー依頼ページ 文字だらけで、何の改修か分からない 目的 概念図 ▶ Before / After 論点  5:35 – 6:00 ▶ ▶ ▶ 1 2 詳細（画面ごとの変更・メリデメ・根拠）はトグルで隠す 12 / 20
20.  やったこと 依頼する 4つの項目で、レビュアーの負荷を軽くする 目的 概念図 ▶ 何のための改修か、最初に分かる 背景を読み解く手間がなくなる Before / After ▶ 変わるところだけ見ればいい どの画面・流れの話か一目で分かる 前提をつかみ直す手間が減る 1 2 画面全体を見比べずに済む 結果 ▶ 論点 何を判断すればいいか分かる レビューする範囲が決まる 1次レビュー担当から「何を見ればいいかすぐ分かる」の声。効果は計測中 6:00 – 6:35 13 / 20
21. これから 仕組みを育て、デザイナーは画面の外へ 導入前 導入後 これから
22.  これから 育てる 仕組みは使われないと育たない  検討中 Skillを育てる   今は自分の判断しか入っていない エンジニアやPdMの判断も一箇所に集め、選んでSkillに入れる 6:40 – 7:05 14 / 20
23.  これから その先 デザイナーは画面の外へ 自分はUIの作成・レビュー工数を圧縮して、サービスデザインに時間を使い始めた。 自分の時間の使い方（イメージ） 以前  UIを作る・レビューする いま  UIを作る・レビューする（仕組みで軽く） 7:05 – 7:35  サービスデザイン 15 / 20
24. 明日からやるなら 完璧を目指さず、小さく始める  まだAIでデザインを作っていないなら  レビューで詰まっているなら AIが読めるルールを作る レビュー依頼のフォーマットを1枚作る まずリポジトリをAIに読ませてインベントリから。 目的・概念図・Before/After・論点。 ルールはゼロから書かなくていい。 レビュー依頼のページ自体もAIが自動で作る。 以前｜文字だけの依頼 いま｜図で伝える依頼 ▶ ※どちらもダミー。「以前」は文字をぼかしています 7:35 – 7:55 16 / 20
25.  まとめ ハーネスだけでなく、 レビュー依頼の方法まで整えて、 デザインフローを円滑に回す そうして空いた時間で、デザイナーこそ画面の外へ出よう 7:55 – 8:15 17 / 20
26. ハンディについて 高校に届く紙の求人票をデジタル化し、 生徒が自分で仕事を探せるようにする 「Handy進路指導室」は、就職を希望する高校生の約70％を支える、進路指導のインフラです 就職を希望する高校生のうち 約 70 % 導入高校 2,500 全国の高校が導入 学校・生徒の利用料 校以上 0 円 導入も月額利用も無料 を「Handy進路指導室」で支えています 70年来変わらない、高卒就活の仕組みを変える ※数値は公開済みのプレスリリース（2026年3月13日・4月21日）より。約70％は2026年1月31日時点、厚労省「令和7年度版全国高等学校便覧」をもとに自社算出 8:15 – 8:35 18 / 20
27.  仲間を探しています 2人目の正社員デザイナーを募集しています エンジニア・PdMも募集しています エンジニアもデザインに参加してくれる、チームです 人事の責任者も来ています。 懇親会で気軽に声をかけてください！ カジュアル面談 ↗ 採用ページ 8:35 – 8:45 19 / 20
28. ありがとうございました Special thanks：小木曽さん（Lumilinks） デザインハーネスの立ち上げを支援いただきました 8:45 – 8:50 20 / 20