職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~

2025年9月11日　「チーム開発を加速する！エンジニア・デザイナー・PdMの職種間連携【D-Plus Tokyo #18】」 における登壇資料です。
https://d-plus.connpass.com/event/365392/

Transcript

1. daitasu 職種の壁を溶かして開発サイクルを高速に回す ~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~ 2025年9月11日　チーム開発を加速する！エンジニア・デザイナー・ PdMの職種間連携【 D-Plus Tokyo #18】 千株式会社 システム開発部 兼 事業企画部
2. 自己紹介 名前： • @daitasu お仕事： • 千株式会社 (2024/4/15 入社) ◦ システム開発部マネージャー 兼 事業企画部 (PdM?Bizdev?) • 技術は Frontend 中心 React/Vue • 人材系SIer → SMB向けEC SaaS → 保育/写真業界DX SaaS(now!)
3. 会社紹介 写真を中心とした、幼保業界の DXプロダクトを展開
4. 私の組織の特徴 PdM/デザイナー/エンジニアがマネジメント配下に ある、幼職種混合組織
5. 本日のお話 職種の壁を溶かして開発サイクルを高速に回す ~情報透明性 と職種越境から考える AIフレンドリーな 職種間連携 ~
6. 職種間連携がうまくいっていないとは？ • 誰が進めるべきか分からず停滞するボールが多発 • いつ何が修正されたのかが分からず修正漏れが発生 • エンジニア/PdM が何を言っているのか会話が噛み合わない • 「シュッと」できるはずなのに開発/デザインのリソースがない
7. 職種間連携がうまくいっていないとは？ • 誰が進めるべきか分からず停滞するボールが多発 • いつ何が修正されたのかが分からず修正漏れが発生 • エンジニア/PdM が何を言っているのか会話が噛み合わない • 「シュッと」できるはずなのに開発/デザインのリソースがない 責務が曖昧 情報透明性が低い 職種ごとの優先順位・制約条件のズレ フロー効率のボトルネック
8. 職種間連携がうまくいっていないとは？ 責務が曖昧 情報透明性 が低い 職種ごとの優先順位 ・制約条件のズレ フロー効率のボトルネック 我々はどうあるべきか？ 職種ごとの責務を明確にする 一つの場所にすべてを集約し、意思決定フローを明確にする エンジニアが保守性を、デザインがユーザー体験を、と 観点は違っても各専門性で見た意見が出ているということ PdM→デザイナー→エンジニアというフロー開発を見直す
9. デリゲーションポーカーによる権限の再定義 PdM/エンジニア/デザイナーはそれぞれ何を担う人か、 各個人に求める役割を意思決定の権限という単位で可視化 権限移譲FWを、独自ルール で拡張して実施
10. すべての議論は、Github Discussion に集約 Slack/Figma 上など各処で発散した議論は、最終合意の場を Github Discussion に集約 → 朝会で確定 「なぜそうしたの？」が 1つに蓄積される → 朝会は1h に伸びたが、 他MTGはほぼ不要になった
11. デザイン変更はバージョン管理し、Github Sub Issue で管理 Figma の修正を見逃さないように、Figmaバージョン管理Issueを作成 各バージョンはSub Issue で管理 Slack 通知も飛び、エンジニ アの見落としがなくなる
12. 意思決定の停滞や 仕様/デザイン変更の認知負荷は軽減
13. でももっと抜本的に開発速度をあげていきたい どうすれば・・・
14. AIエージェントの台頭 Claude Code やDevin のようなAIエージェントで 開発フローのあり方が見直されつつある
15. 弊社が求める開発組織のあり方 千では「事業を推進できる開発組織」という言葉がよく使われ、 グレード表も越境を意図してPdM/エンジニア/デザイナーといった 区切りがない • 事業推進 • 組織改革・成長・育成 • コミュニケーション • 発信 • 予算計画・管理 • 専門性(技術) • 運用・トラブルシューティング • 開発プロセス・品質 • 専門性(デザイン) • ユーザー理解・課題解決 etc…
16. 職種越境のためにAIエージェント試す AIによる越境の加速化で開発サイクルに改革を生めないか実験 PdMもデザイナーもエンジニアも、 全員でClaude Code やってみよう！！！ 全員でAI駆動を育てよう！
17. MCPセットアップ会 全員が「Github」や「PostgreSQL」にMCPで繋ぎ、コードやDB、 デザインにアクセス可能な状態を作る リポジトリコード DBスキーマ アクセス解析 Doc ツール デザイン まずは最小限。 徐々に見れるものを増やす
18. 変化① PdM がコードを読んで会話可能に PdMがコードを読み、既存仕様をおおよそ調査 → アタリがついた状態でエンジニアと対話が可能に AI調査のため精度は確実ではない。しかし、 1. PdM の「調査待ち」がなくなる 2. 外観が見えたうえの調査で「エンジニア負担軽減」 3. 以前より「目線のあった対話」が可能に
19. 変化② PdM がデザインモックを作り、デザイナーと対話 PdMがデザインモックを作成 → 頭の中の構想をより具体的にデザイナーと対話が可能に
20. 変化③ デザイナーがデザイン変更差分の共有を自動化 デザイナーがカスタムコマンドを作成 → デザイン変更差分から画像から検知し、自動で説明文を作成
21. AIエージェントの統一により、 職種の壁が溶けつつある
22. まとめ - 責務の曖昧さの課題 - 「権限」という明確な形で整理すると分かりやすい - 情報透明性の課題 - 議論の場の集約、意思決定フローの統一で迷いが消える - Doc 統一はAIフレンドリーにもなる - フロー開発の課題 - AIエージェントによって今後見直しが必要 - まずは「全員で」試し、開発のあり方を育てていく