歴史あるプロダクトで小さくはじめるデザインハーネス

Transcript

1. 歴史あるプロダクトで 小さくはじめる デザインハーネス 2026.10.29 デザインハーネス The Beginning 〜これから始めるデザインハーネス〜 aito-ika mk-0A0 伊藤あゆ美 上條 桃香
2. デザインハーネス4層を 整える 2
3. デザインハーネス4層を 整えるよりも手前の話 3
4. AI 駆動の開発にデザイナー介入ができていない • AI 駆動で、少人数・速度重視の開発体制が開始 • 機能要件優先で、パーツの整合性やユーザビリティの判断を 保留してリリース UIの生成精度を少しでも上げていきたい 4
5. プロジェクトの状況 • エンタープライズ向けマルチテナンシーシステム • 大手企業の事業に直結するため、経緯と意図の維持が重要 • 50人弱のチームで、大小5プロダクトを高速に開発している デリバリー速度は保ちたい 5
6. 現場の課題 • 膨大な資産があるが整備されていない • 改修・新規実装が並走していて、資産整備に時間を割けない • コード量が膨大で破壊的なことはできない 未整備資産がボトルネックで動きづらい！ 6
7. 「しっかり整備してから動く」 はできない 7
8. とりあえず動くには どうすればいいか？ 8
9. 置き場所や分け方は後回し 散らばった材料を 仮置きする場所 を作る 9
10. 置き場所や分け方は後回しで仮置きする Figma デザイン / コンポーネント PdM のワイヤー ・マスターに未統合の分割されたデザインファイル ・実装に追いついていないマスターデータ 開発 Wiki Storybook ・プロダクトの背景情報 ・利用ルールが未記載 ・各種議事録 ・粒度が未整理 実コード 必要なプロダクトの情報、 最低限のデザインルールを抽出 DRになるべきもの あちこちに散らばっている Jira Slack #… GitHub Issues DESIGN.md 10
11. ちいさく検証：何を渡すと生成画面の再現度が上がるか 生成対象 生成ルール 既存画面 1枚 • 対象画面の実装は隠し、採点に使う • 入力は「DESIGN.md ＋もう1つ」に絞る • HTML 骨格・Wiki 要件・Storybook などを 順に試した 11
12. 検証の結果 再現度が高かった組み合わせ Storybook ＋ 使うのは既存コンポーネントだけ 理由がなければ作らない 未整備のStorybookが一定働いたことで 過去の資産の整備方針が見えた 12
13. 検証はできた 13
14. 抽出したプロダクト情報や デザインルールだけでは 解決できなかったこともある 14
15. 資産未整備のままでは解決できなかったこと • • コンポーネントの粒度の調整など DESIGN.mdだけでは 解決できない問題 が残っていた 集約する情報が膨らむと AIの参照効率が下がる懸念 があった DESIGN.md内の仮置き情報の整備に加えて、 適切なSSOTの用意が必要 15
16. 色々エンジニアと話した結果 SSOTは既存資産のコードに 寄せると良いという話に エンジニアパートでお話しします 16
17. 検証・情報整備の流れ 画面生成 • DESIGN.mdから情報を分離 • 積めなかった情報を追加＋整理 必要なルールを 適切な場所に配置 or 課題として記録 デザインルールと 突き合わせて評価 ずれた原因を分類 ・ 不足していた ルールを定義 17
18. ルールからずれた原因の特定 引用リスト 何を根拠にしたか 推測リスト どう推測したか AIの判断理由を 人がみえるようにした 18
19. 評価後の対応 ルールを追加・調整 不足していた情報 → 適切なファイルに追記 書いてあるけど読めていない → 書き方・置き場所を見直す 原因を課題として記録 画面固有の問題 → プロンプト側の課題として記録 共通コンポーネントの問題 → Storybook の整備課題 整備することで、 ルールが機能し生成精度が上がった 19
20. これって デザインハーネス なのでは？ 20
21. 整備は後からできる その他整備 ファイルを情報ごとに分割 画面要件の 壁打ちスキル DESIGN.md 1ファイル 検証結果の 調整・拡充 などなど トークンや使い分けルールは Storybookへ 小さくはじめたから整備までたどり着けた 21
22. エンジニアと連携 整備を進めるためにも SSOT (Single Source of Truth) の定義が必要 22
23. AI が動ける環境づくり 文脈に合わせたコンポーネントの使い分けルールを置く場所を検討 • コンポーネントが Figma とコードで 二重管理になるのは避けたい • SSOT をコードに寄せるとデザイナーもコードベースで フィードバックを行うことになる これまでの資産を活かすためにも Storybook がいいのでは？ 23
24. Storybook を SSOT 化するうえで重視したこと 制約がある中で 現実的にできることから 小さくはじめる 24
25. SSOT 化のプロセス 1 必要な Storybook を整備 既存資産を活かすためにコンポーネントごとに Story を再整備 2 トークンの整備 色やタイポグラフィといったベースとなるスタイルを整備 3 ルールの言語化 コンポーネントのデザイン意図を .mdx に言語化し、Storybook で表示 4 組み合わせの例示 実際のページを Storybook に起こし、AI に実装サンプルとして渡す 25
26. モックアップ画面作成の流れ AI 1 画面要件を指示 2 コンポーネントを選ぶ 生成ルール＋Storybook を把握して選択 3 組み合わせを検討 4 モック画面を生成 5 検証 6 本実装 プロダクトによっては 既に運用可能 エンタープライズ向けにはまだ調整が必要 本実装に必要なパターンが揃っているか モックのコードを引き継げる 26
27. 実際の生成物（デモ） 元の画面 新規作成 ハーネスあり 27
28. 一連の取り組みで大事にしたこと • 風呂敷を広げすぎず、確実に成果を出す手段を選ぶ • デザイナーとエンジニア両方の視点 でルールを磨く 進め方 デザイナーがルールを言語化し、 エンジニアが既存実装とのズレをレビュー 既存プロジェクトにもすぐハーネスを適用でき、生成精度も上がる 28
29. 最初から4層をきれいに設計するだけでなく 歴史あるシステムに 合わせて 泥臭くはじめられる 29
30. まとめ 当初の検証から 地続きで 小さくはじめられている 30
31. プロダクトの課題を一緒に解決します。 最適な技術と、適切な手段で。 Gaji-Laboはフロントエンド開発者と UI デザイナーが チームメンバーとして参画するスタートアップ支援の会社です。 フロントエンド開発や UI デザインなどの専門技術の提供を軸に、 成長支援のためのチームワークの提供を一番大切にしています。 https://www.gaji.jp/ 31