Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Layermate・Claude Codeで挑む エンジニア→デザイナーの越境
Search
まっきー
September 03, 2025
0
65
Layermate・Claude Codeで挑む エンジニア→デザイナーの越境
まっきー
September 03, 2025
Tweet
Share
More Decks by まっきー
See All by まっきー
振り返りについてのあれやこれや_2023-09-28
makky_1995
0
80
ITILをもとにインシデントフロー作成しました
makky_1995
0
510
Featured
See All Featured
A better future with KSS
kneath
239
17k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Designing for humans not robots
tammielis
253
25k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
The Cost Of JavaScript in 2023
addyosmani
53
8.9k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
What's in a price? How to price your products and services
michaelherold
246
12k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Transcript
デザイナー×エンジニア猛暑対策LT AIでつながNight! Layermate・Claude Codeで挑む エンジニア→デザイナーの越境 プロダクトエンジニア 蒲田 眞希
2 自己紹介 2 1995年生まれ 大阪府出身 2021年4月 株式会社リブ・コンサルティング 住宅・不動産向けVertical SaaSを開発 エンジニア2人目入社→UXLead
2025年5月~ アセンド株式会社 プロダクトエンジニア 物流向け運送管理SaaSを開発 蒲田 眞希 Kamada Maki プロダクトエンジニア 自己紹介
3 ロジックスの紹介 3
4 プロダクトエンジニアとは 4 4 Technology Domain UX Design 機能開発の全体にオーナーシップ •
Technology ◦ 1機能を単独で実装できる技術力(フルスタックさ ◦ 技術力ゆえのソリューションの多様さ ◦ 検証イテレーションを早く回す開発生産性 • UX Design ◦ 仮説検証、Lean開発、仕様策定 ◦ 顧客体験のデザイン、OOUI、情報アーキテクチャ • Domain ◦ 高い解像度での顧客理解 ◦ 事業・KPI・ビジネスモデル 参考:プロダクトエンジニアとは何者か
エンジニア →デザイナーの越境の壁を どのように乗り越えるか with AI 5 本日のテーマ 5
越境に立ちはだかる2つの壁 ▪少人数体制 ×全員プロダクトエンジニア 各メンバーがオーナーシップを持って 遂行する結果、画面や機能ごとに体験に 差分が出てくるケースがある。 スピードを落とさず開発を進めつつ、 デザインのイネーブルメントを実施した い。 ▪Figmaデザインの難易度
何でもできる一方で学習コストが高い。 オートレイアウト、バリアント etc.. ▪既存の制約や実装ベースでの発想 1人でデザイン→実装を担うため 人格分けが難しい。 まずは理想を起点にユーザーにとって 違和感なく滑らかな体験を構想したい。 6 6 作成の壁 QAの壁 Layermateによる 自然言語でのデザイン作成 Claude Codeによる デザインレビュー
7 7 Layermateによるデザイン作成 自然言語で Figmaデザインを作成可能
Layermateあれこれ ▪既存コンポーネントを参照可能 既存プロダクトのデザインに寄せて作成す ることで、 渡すコンテキストを最小化できる。 v0やFigma Makeで一から全体を構築する よりも速い。 ▪アウトプットを編集可能 「ここだけ編集したい」に対応できる。
作成したコンポーネントを用いて、 Figma Makeで全体構築も可能。 8 8 良いところ 惜しいところ ▪拭いきれない“AIっぽさ” 絵文字の多用やカラーリングは、 どうしてもAIっぽさを感じさせる。 ▪既存コンポーネントの使用不可 参照して似たようなUIを作成可能だが、全 く同じではないので修正が必要。 実務で十分使える。ちょっとした UI改善から1領域の機能開発まで、 ほぼ毎日使用中
9 9 Claude Codeによるレビュー /design-review {対象のURL} カスタムスラッシュコマンドで呼び出し
10 10 Claude Codeによるレビュー 実装画面のキャプチャをレビュー デザインガイドライン、 ルールをコンテキストとして渡す 実装前:Figma MCP 実装後:Playwright
Figmaのデザインをレビュー
Claude Codeあれこれ ▪MCP接続 Figma、Playwrightの設定も一瞬。 Claude Codeから一発で呼び出せるのが◎ ▪最低限のベースラインの担保 サポートサイトのURLがあるか、文言の統一など 必要だけど人間の確認が面倒なものを一定担保できる 11
11 良いところ 惜しいところ ▪ドキュメンテーションコスト 適切なコンテキストを渡せないとあまり機能しない。 機能要件を詳細に渡さないと期待する結果が得られない ことが多く、ドキュメンテーションコストがかかる ▪ガイドライン、デザインシステ ムの有無、クオリティ次第 弊社のケースだとガイドラインをもう少し具体に詰めた ほうが良さそう。土台づくりに時間がかかる いかに適切なコンテキストを渡すか。まだまだ試行錯誤中。
エンジニア →デザイナーの越境の壁をどのように乗り越えるか • 作成の壁:Layermateによる自然言語でのデザイン作成 • QAの壁:Claude Codeによるデザインレビュー 12 まとめ 12
まだまだ思考錯誤中なので、是非皆さんの取り組みを教えてください!
We are hiring !!! 13 デザインエンジニア、大募集中です!!!! 日本で最もデジタル化の遅れた物流産業で、 最高の業務体験を一緒に作りましょう!!
None