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

Slide 1

Slide 1 text

daitasu 職種の壁を溶かして開発サイクルを高速に回す ~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~ 2025年9月11日　チーム開発を加速する！エンジニア・デザイナー・ PdMの職種間連携【 D-Plus Tokyo #18】千株式会社システム開発部兼事業企画部

Slide 2

Slide 2 text

自己紹介名前： ● @daitasu お仕事： ● 千株式会社 (2024/4/15 入社) ○ システム開発部マネージャー兼事業企画部 (PdM?Bizdev?) ● 技術は Frontend 中心 React/Vue ● 人材系SIer → SMB向けEC SaaS → 保育/写真業界DX SaaS(now!)

Slide 3

Slide 3 text

会社紹介写真を中心とした、幼保業界の DXプロダクトを展開

Slide 4

Slide 4 text

私の組織の特徴 PdM/デザイナー/エンジニアがマネジメント配下にある、幼職種混合組織

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

職種間連携がうまくいっていないとは？ ● 誰が進めるべきか分からず停滞するボールが多発 ● いつ何が修正されたのかが分からず修正漏れが発生 ● エンジニア/PdM が何を言っているのか会話が噛み合わない ● 「シュッと」できるはずなのに開発/デザインのリソースがない

Slide 7

Slide 7 text

職種間連携がうまくいっていないとは？ ● 誰が進めるべきか分からず停滞するボールが多発 ● いつ何が修正されたのかが分からず修正漏れが発生 ● エンジニア/PdM が何を言っているのか会話が噛み合わない ● 「シュッと」できるはずなのに開発/デザインのリソースがない責務が曖昧情報透明性が低い職種ごとの優先順位・制約条件のズレフロー効率のボトルネック

Slide 8

Slide 8 text

職種間連携がうまくいっていないとは？責務が曖昧情報透明性が低い職種ごとの優先順位・制約条件のズレフロー効率のボトルネック我々はどうあるべきか？職種ごとの責務を明確にする一つの場所にすべてを集約し、意思決定フローを明確にするエンジニアが保守性を、デザインがユーザー体験を、と観点は違っても各専門性で見た意見が出ているということ PdM→デザイナー→エンジニアというフロー開発を見直す

Slide 9

Slide 9 text

デリゲーションポーカーによる権限の再定義 PdM/エンジニア/デザイナーはそれぞれ何を担う人か、各個人に求める役割を意思決定の権限という単位で可視化権限移譲FWを、独自ルールで拡張して実施

Slide 10

Slide 10 text

すべての議論は、Github Discussion に集約 Slack/Figma 上など各処で発散した議論は、最終合意の場を Github Discussion に集約 → 朝会で確定「なぜそうしたの？」が 1つに蓄積される → 朝会は1h に伸びたが、他MTGはほぼ不要になった

Slide 11

Slide 11 text

デザイン変更はバージョン管理し、Github Sub Issue で管理 Figma の修正を見逃さないように、Figmaバージョン管理Issueを作成各バージョンはSub Issue で管理 Slack 通知も飛び、エンジニアの見落としがなくなる

Slide 12

Slide 12 text

意思決定の停滞や仕様/デザイン変更の認知負荷は軽減

Slide 13

Slide 13 text

でももっと抜本的に開発速度をあげていきたいどうすれば・・・

Slide 14

Slide 14 text

AIエージェントの台頭 Claude Code やDevin のようなAIエージェントで開発フローのあり方が見直されつつある

Slide 15

Slide 15 text

弊社が求める開発組織のあり方千では「事業を推進できる開発組織」という言葉がよく使われ、グレード表も越境を意図してPdM/エンジニア/デザイナーといった区切りがない ● 事業推進 ● 組織改革・成長・育成 ● コミュニケーション ● 発信 ● 予算計画・管理 ● 専門性(技術) ● 運用・トラブルシューティング ● 開発プロセス・品質 ● 専門性(デザイン) ● ユーザー理解・課題解決 etc…

Slide 16

Slide 16 text

職種越境のためにAIエージェント試す AIによる越境の加速化で開発サイクルに改革を生めないか実験 PdMもデザイナーもエンジニアも、全員でClaude Code やってみよう！！！全員でAI駆動を育てよう！

Slide 17

Slide 17 text

MCPセットアップ会全員が「Github」や「PostgreSQL」にMCPで繋ぎ、コードやDB、デザインにアクセス可能な状態を作るリポジトリコード DBスキーマアクセス解析 Doc ツールデザインまずは最小限。徐々に見れるものを増やす

Slide 18

Slide 18 text

変化① PdM がコードを読んで会話可能に PdMがコードを読み、既存仕様をおおよそ調査 → アタリがついた状態でエンジニアと対話が可能に AI調査のため精度は確実ではない。しかし、 1. PdM の「調査待ち」がなくなる 2. 外観が見えたうえの調査で「エンジニア負担軽減」 3. 以前より「目線のあった対話」が可能に

Slide 19

Slide 19 text

変化② PdM がデザインモックを作り、デザイナーと対話 PdMがデザインモックを作成 → 頭の中の構想をより具体的にデザイナーと対話が可能に

Slide 20

Slide 20 text

変化③ デザイナーがデザイン変更差分の共有を自動化デザイナーがカスタムコマンドを作成 → デザイン変更差分から画像から検知し、自動で説明文を作成

Slide 21

Slide 21 text

AIエージェントの統一により、職種の壁が溶けつつある

Slide 22

Slide 22 text

まとめ - 責務の曖昧さの課題 - 「権限」という明確な形で整理すると分かりやすい - 情報透明性の課題 - 議論の場の集約、意思決定フローの統一で迷いが消える - Doc 統一はAIフレンドリーにもなる - フロー開発の課題 - AIエージェントによって今後見直しが必要 - まずは「全員で」試し、開発のあり方を育てていく