デザイナーもマーケもPRを出す！─ エンジニアから歩み寄る開発文化とAIを使った仕組みづくり

by tetsuro_b

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 3 今日話すことプロダクトエンジニアデザイナーマーケター As Is プロダクトエンジニアデザイナーマーケター To Be 「デザイナー職もマーケター職も、自分たちで PR をあげれたら最高！」開発体制を上記の形に徐々に変革している最中なので、As Is → To Be の状態にするまでに弊社でどんなことをしているのかをお話できればと思います。要望要望 PR PR PR PR

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 6 [課題] プロダクト開発は差し込みだらけプロダクト開発における不確実性を高めるひとつの要因 = 主要機能開発以外の差し込みタスク • LP のこの部分にバナー出すことってできますか？ • ここのテキストの色をグレーに変更することできますか？サクッと対応できるものから要件を整理しないと対応できないものまで粒度はバラバラ。必要な改修であることは間違いないが全員がハッピーではない状態。 • エンジニア：主要機能の開発を期限どおりに進めたい。 • デザイナー：UI/UX 向上させたいが改善点を見つけても実装時期はエンジニア次第…。 • マーケター：適切なタイミングでマーケティング施策を実行したいがエンジニアのリソース次第…。

Slide 7

Slide 7 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 7 [課題] プロダクト開発は差し込みだらけプロダクト開発における不確実性を高めるひとつの要因 = 主要機能開発以外の差し込みタスク • LP のこの部分にバナー出すことってできますか？ • ここのテキストの色をグレーに変更することできますか？サクッと対応できるものから要件を整理しないと対応できないものまで粒度はバラバラ。必要な改修であることは間違いないが全員がハッピーではない状態。 • エンジニア：主要機能の開発を期限どおりに進めたい。 • デザイナー：UI/UX 向上させたいが改善点を見つけても実装時期はエンジニア次第…。 • マーケ：適切なタイミングでマーケティング施策を実行したいがエンジニアのリソース次第…。エンジニア以外の職種の方たちがパワーポイントで資料を作るが如く、やりたいことを PR を投げてもらえる開発体制を作れれば全員ハッピーなのでは。 → これから話す部分のモチベーションとなる点

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 10 誰もが PR を出せる文化作り ■ 【補足】Devin とは？ • Slack からお手軽に実装指示が出せて、自律的に実装をしてくれる AI エージェント • タスクの解析 ~ PR の作成まで指示内容に従い実装を進めてくれる • https://devin.ai/ ■ 【補足】Chromatic とは？ • Storybook と連携して VRT やコンポーネントのインタラクションテストを実行できるツール • PR の push などをトリガーとして CI で実行できる • https://www.chromatic.com/

Slide 11

Slide 11 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 11 誰もが PR を出せる文化作り ■ Chromatic 補足 • PR 上で変更されたデザイン差分を確認できる • Storybook が実装されているコンポーネントであれば全ての Story に対して差分検出が走るのでデザイン修正の影響範囲を簡単に把握可能 • この画面の場合は黄緑色の部分が PR 上のコード変更に伴い変更されたデザインだとわかる • → 非エンジニアでもローカル環境を用意することなくデザインの修正確認が可能 Before After

Slide 12

Slide 12 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 12 誰もが PR を出せる文化作り ■ プロダクトデザイナーによるデザイン修正手順を紹介 1. デザインバックログからプロダクトに取り込みたいタスクを決定 2. Slack から Devin に修正指示 3. PR を作成 4. Chromatic でデザイン差分の検出 5. 意図した修正になっているか Chromatic でデザインを確認 6. エンジニアにコードレビュー 7. コードレビュー 8. マージデザイナーデザイナーデザイナーエンジニアエンジニアデザイナー自動（Devin）自動（Chromatic） ■ デザイナーのプロダクトへの関わり方が変化！ Before：このタスクの実装お願いできますか・・・？ ↓ After：レビューして OK そうだったらマージお願いします。

Slide 13

Slide 13 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 13 誰もが PR を出せる文化作り Q. デザイナーが PR を正しくレビューできるの？ A. 以下のように責務をわけることで運用を回してます・デザイナー：変更されたデザイン（見た目）にのみ責任を持つ・エンジニア：コードにのみ責任を持つこのように役割ごとに責務を分けることで非エンジニアがエンジニアにレビューを出す際の心理的安全性も確保しています！！ → デザインさえ意図した修正になってたらどんどんレビュー出していいよ！というスタンス。 Q. Devin に依頼するとして意図したデザイン修正は可能？ A. かんたんなデザイン修正であればレビュー修正なしで行けるほどの精度で可能！良い：UI パーツの色変更や画面内の一部 UI の変更悪い：新規画面の 0 → 1 実装や、創造的なデザイン修正 ※ レビュー修正事項があれば PR 上で「@devin」でそのまま修正指示

Slide 14

Slide 14 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 14 誰もが PR を出せる文化作り Q. 実際にこのフローはどれくらいワークしている？ A. 多い時には「16 件/月」ほど非エンジニアから PR が上がっていますうち 15 件は実際に本番環境まで反映済み（close されたのは 1 件） Q. デザイナー職以外は誰がどんな PR をあげている？ A. 主にマーケター職の方が以下のような PR の作成に挑戦しています！・追従バナーの実装・ヒートマップツールの導入・文言差し替え・ナビゲーションメニューの変更 ※ ただ、簡単なデザイン修正よりかは実装難易度が高く修正が必要なケースも多い。

Slide 15

Slide 15 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 15 誰もが PR を出せる文化作り ■ 非エンジニア職の AI 活用は次のステージへ… [デザイナー] これで、エンジニア職以外も PR をだせるようになったぞ！んー、でももっとレベルの高い作業をしたい…！！ • Devin に重ね重ね修正させるとコストが心配なので自分で直せるようになりたい！ • Devin に作らせる前にデザイン変更後の印象をイメージ掴んでおきたい！ • 新規機能のデザイン案を AI で色々作って試してみたい！ [エンジニア] じゃぁ、ローカルに開発環境作って挑戦してみます？

Slide 16

Slide 16 text

Slide 17

Slide 17 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 17 エンジニア職以外にローカル環境を解放できるか AI の力で誰でも『コードを書く』ということはできるようになった ⇒ コードをかければ PR を出せるか（No）コーディングにおける知識云々、Git の使い方等もあるがわかりやすい問題として『アプリ起動』 ※ アプリ起動 = 最新の main pull, node-modules の更新など ※ 非エンジニアには当たり前じゃないことの連続 • VSCode 以外にも Docker の立ち上げが必要 • schema に更新があればローカルの DB の migration が必要なケースも • アプリで使っている Node.js バージョンとローカルの Node.js バージョンの不一致 ⇒ 「アプリ起動」周りは AI にまかせてもうまくいかないケースも多かった

Slide 18

Slide 18 text

Slide 19

Slide 19 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 19 Cursor / アプリ起動用コマンドの作成アプリ起動の際のトラブルは AI に全任せてもうまくいかないケースも多い ※ Docker アプリが立ち上がっているかなどは調査してくれない…。など → アプリを起動までの間に何かしら不測の自体が起きてもサポートしてくれるコマンドを作ろう。 ■ アプリ起動用の Cursor コマンド爆誕 Cursor チャットで「/env_init」と入力するだけで… 1. Docker アプリが自動起動！ 2. ターミナルアプリが自動起動！ 3. ブランチが自動で最新化！（差分があれば stash） 4. FE, BE の両方が自動起動！（ポリレポにも対応） 5. 上記の手順でなにかトラブルがあれば自動で対応！

Slide 20

Slide 20 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 20 Cursor / アプリ起動用コマンドの作成 ■ 【補足】Cursor コマンドとは？ “カスタムコマンドを使うと、チャット入力欄で「/」を付けるだけで呼び出せる再利用可能なワークフローを作成できる。コマンドはチーム全体のプロセスを標準化し、よくある作業をより効率的にしてくれる。” （公式ドキュメントより引用） https://docs.cursor.com/ja/agent/chat/commands カスタムコマンド自体はプロジェクト内に↓のように配置 .cursor/commands/*md

Slide 21

Slide 21 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 21 Cursor / 環境構築用コマンドを一部紹介 ■ Docker アプリの起動 → AI は Docker アプリが起動しているか調査してくれない ■ 既存プロセスの停止 → ポートが変わると一部機能に影響がでるので重複しないように停止 ■ ターミナルの起動＆プロセス起動 → Cursor のチャット内でプロセスが起動するとチャット終了とともにプロセスも終了してしまうためターミナルアプリに切り出し

Slide 22

Slide 22 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 22 Cursor / 環境構築用コマンドのユースケース ■ Cursor のアプリ起動用コマンドでこんなことができるようになりました。デザイナー「Devin が作った PR をローカルでレビュー＆微調整したい」デザイナー「モックデザインを Figma 上ではなくローカルで作りたい」 • Before：main ブランチを pull して… yarn dev を実行して…。 • すべてが手動のプロセスだとなにか問題が起きた時に手詰まりになる… • 既に差分があるから pull できない… • package に変更があり yarn dev できない… などなど • After : Cursor を開いて「/env_init」を実行 → ブランチを指定のものに切り替えるだけ • なにか問題が発生しても基本的には Agent が自動で解決してくれる • 修正作業に集中できる！

Slide 23

Slide 23 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 23 Cursor / アプリ起動用コマンドの作成 ■ CLI で順番にコマンド打つのと今回のは何が違うの？ CLI で順番にアプリの起動に必要なコマンドを打ち込むことでも同じようなことは実現できます。ただ以下の観点で Cursor コマンドを使って Agent に任せたほうが楽だとおもっています。 • ① コマンド入力漏れ • 入力コマンドが複数ある場合、人がコピペで実行すると実行漏れのコマンドがでるかも… • ②エラーログへの自動対応（これが一番） • CLI でのコマンド実行だとログを Agent に渡す際にコピペが必要（慣れてない人からしたら大変） • → Cursor チャット内で全部実行されればエラーログも自動で Agent が読み取って対応手段を考えてくれる

Slide 24

Slide 24 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 24 Cursor / アプリ起動用コマンドの作成 • Cursor コマンド周りの話は Zenn にも詳しく書いてます！ • https://zenn.dev/kikagaku/articles/f96c2f24c24151 • このあたりの発想自体は以下の記事を参考にさせていただきました • デザイナーを救う魔法：Cursorの「デザインモード」が開発へのアレルギー減らした話 • https://note.com/kaochannel154/n/nd198ea14f0a5

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 27 現状の課題と今後の展望プロダクトに関わる全員がハッピーな状態に近づいてきた ■ Before • エンジニア：主要機能の開発を期限どおりに進めたい。 • デザイナー：UI/UX 向上させたいが改善点を見つけても実装時期はエンジニア次第…。 • マーケ：適切なタイミングでマーケティング施策を実行したいがエンジニアのリソース次第…。 ■ After • エンジニア：差し込みタスクが減り主要機能の開発に集中できる！ • デザイナー：エンジニアリソースを気にせず UI/UX の改善が可能に！ • マーケ：エンジニアリソースを気にせずマーケティング施策の実践が可能に！

Slide 28

Slide 28 text

©2017-2025 kikagaku, Inc. All Rights Reserved. 28 現状の課題と今後の展望 • 共通の課題 • Devin のコストの観点からエンジニア側での監視サポート体制の強化は必要 • マーケチームの課題 • バナーの設置など単純な改修ばかりではないので閉じられる PR も多い • → マーケティング施策はビジュアル系の要素多め • デザイナーチームの課題 • Storybook が充実していないコンポーネントに対しては Chromatic レビューを活用できないため、エンジニア側で Storybook の継続的な保守が必要 • 共通コンポーネントの変更の際には意図しない部分への影響がでるかもしれないので、影響範囲が広めのタスクは躊躇がある。 • → ローカル環境を Cursor コマンドで使えるようにしたので、タスクによっては Devin に投げる前にローカルで影響範囲の調査など必要に応じて既に動き始めていただいている