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

by mk-0A0

Embed

Start on current slide

Slide 1

Slide 1 text

歴史あるプロダクトで小さくはじめるデザインハーネス 2026.10.29 デザインハーネス The Beginning 〜これから始めるデザインハーネス〜 aito-ika mk-0A0 伊藤あゆ美上條桃香

Slide 2

Slide 2 text

デザインハーネス4層を整える 2

Slide 3

Slide 3 text

デザインハーネス4層を整えるよりも手前の話 3

Slide 4

Slide 4 text

AI 駆動の開発にデザイナー介入ができていない ● AI 駆動で、少人数・速度重視の開発体制が開始 ● 機能要件優先で、パーツの整合性やユーザビリティの判断を保留してリリース UIの生成精度を少しでも上げていきたい 4

Slide 5

Slide 5 text

プロジェクトの状況 ● エンタープライズ向けマルチテナンシーシステム ● 大手企業の事業に直結するため、経緯と意図の維持が重要 ● 50人弱のチームで、大小5プロダクトを高速に開発しているデリバリー速度は保ちたい 5

Slide 6

Slide 6 text

現場の課題 ● 膨大な資産があるが整備されていない ● 改修・新規実装が並走していて、資産整備に時間を割けない ● コード量が膨大で破壊的なことはできない未整備資産がボトルネックで動きづらい！ 6

Slide 7

Slide 7 text

「しっかり整備してから動く」はできない 7

Slide 8

Slide 8 text

とりあえず動くにはどうすればいいか？ 8

Slide 9

Slide 9 text

置き場所や分け方は後回し散らばった材料を仮置きする場所を作る 9

Slide 10

Slide 10 text

置き場所や分け方は後回しで仮置きする Figma デザイン / コンポーネント PdM のワイヤー・マスターに未統合の分割されたデザインファイル・実装に追いついていないマスターデータ開発 Wiki Storybook ・プロダクトの背景情報・利用ルールが未記載・各種議事録・粒度が未整理実コード必要なプロダクトの情報、最低限のデザインルールを抽出 DRになるべきものあちこちに散らばっている Jira Slack #… GitHub Issues DESIGN.md 10

Slide 11

Slide 11 text

ちいさく検証：何を渡すと生成画面の再現度が上がるか生成対象生成ルール既存画面 1枚 ● 対象画面の実装は隠し、採点に使う ● 入力は「DESIGN.md ＋もう1つ」に絞る ● HTML 骨格・Wiki 要件・Storybook などを順に試した 11

Slide 12

Slide 12 text

検証の結果再現度が高かった組み合わせ Storybook ＋使うのは既存コンポーネントだけ理由がなければ作らない未整備のStorybookが一定働いたことで過去の資産の整備方針が見えた 12

Slide 13

Slide 13 text

検証はできた 13

Slide 14

Slide 14 text

抽出したプロダクト情報やデザインルールだけでは解決できなかったこともある 14

Slide 15

Slide 15 text

資産未整備のままでは解決できなかったこと ● ● コンポーネントの粒度の調整など DESIGN.mdだけでは解決できない問題が残っていた集約する情報が膨らむと AIの参照効率が下がる懸念があった DESIGN.md内の仮置き情報の整備に加えて、適切なSSOTの用意が必要 15

Slide 16

Slide 16 text

色々エンジニアと話した結果 SSOTは既存資産のコードに寄せると良いという話にエンジニアパートでお話しします 16

Slide 17

Slide 17 text

検証・情報整備の流れ画面生成 ● DESIGN.mdから情報を分離 ● 積めなかった情報を追加＋整理必要なルールを適切な場所に配置 or 課題として記録デザインルールと突き合わせて評価ずれた原因を分類・不足していたルールを定義 17

Slide 18

Slide 18 text

ルールからずれた原因の特定引用リスト何を根拠にしたか推測リストどう推測したか AIの判断理由を人がみえるようにした 18

Slide 19

Slide 19 text

評価後の対応ルールを追加・調整不足していた情報 → 適切なファイルに追記書いてあるけど読めていない → 書き方・置き場所を見直す原因を課題として記録画面固有の問題 → プロンプト側の課題として記録共通コンポーネントの問題 → Storybook の整備課題整備することで、ルールが機能し生成精度が上がった 19

Slide 20

Slide 20 text

これってデザインハーネスなのでは？ 20

Slide 21

Slide 21 text

整備は後からできるその他整備ファイルを情報ごとに分割画面要件の壁打ちスキル DESIGN.md 1ファイル検証結果の調整・拡充などなどトークンや使い分けルールは Storybookへ小さくはじめたから整備までたどり着けた 21

Slide 22

Slide 22 text

エンジニアと連携整備を進めるためにも SSOT (Single Source of Truth) の定義が必要 22

Slide 23

Slide 23 text

AI が動ける環境づくり文脈に合わせたコンポーネントの使い分けルールを置く場所を検討 ● コンポーネントが Figma とコードで二重管理になるのは避けたい ● SSOT をコードに寄せるとデザイナーもコードベースでフィードバックを行うことになるこれまでの資産を活かすためにも Storybook がいいのでは？ 23

Slide 24

Slide 24 text

Storybook を SSOT 化するうえで重視したこと制約がある中で現実的にできることから小さくはじめる 24

Slide 25

Slide 25 text

SSOT 化のプロセス 1 必要な Storybook を整備既存資産を活かすためにコンポーネントごとに Story を再整備 2 トークンの整備色やタイポグラフィといったベースとなるスタイルを整備 3 ルールの言語化コンポーネントのデザイン意図を .mdx に言語化し、Storybook で表示 4 組み合わせの例示実際のページを Storybook に起こし、AI に実装サンプルとして渡す 25

Slide 26

Slide 26 text

モックアップ画面作成の流れ AI 1 画面要件を指示 2 コンポーネントを選ぶ生成ルール＋Storybook を把握して選択 3 組み合わせを検討 4 モック画面を生成 5 検証 6 本実装プロダクトによっては既に運用可能エンタープライズ向けにはまだ調整が必要本実装に必要なパターンが揃っているかモックのコードを引き継げる 26

Slide 27

Slide 27 text

実際の生成物（デモ）元の画面新規作成ハーネスあり 27

Slide 28

Slide 28 text

一連の取り組みで大事にしたこと ● 風呂敷を広げすぎず、確実に成果を出す手段を選ぶ ● デザイナーとエンジニア両方の視点でルールを磨く進め方デザイナーがルールを言語化し、エンジニアが既存実装とのズレをレビュー既存プロジェクトにもすぐハーネスを適用でき、生成精度も上がる 28

Slide 29

Slide 29 text

最初から4層をきれいに設計するだけでなく歴史あるシステムに合わせて泥臭くはじめられる 29

Slide 30

Slide 30 text

まとめ当初の検証から地続きで小さくはじめられている 30

Slide 31

Slide 31 text

プロダクトの課題を一緒に解決します。最適な技術と、適切な手段で。 Gaji-Laboはフロントエンド開発者と UI デザイナーがチームメンバーとして参画するスタートアップ支援の会社です。フロントエンド開発や UI デザインなどの専門技術の提供を軸に、成長支援のためのチームワークの提供を一番大切にしています。 https://www.gaji.jp/ 31