なぜAIは チーム開発を 速くしないのか

AIで個人の開発スピードは劇的に上がった。しかしチーム開発では思ったほど成果が出ていない現場が多いのではないでしょうか？

本セッションでは、AI導入の現場で実際に起きたエピソードから、問題の構造を掘り下げ、ボトルネックの正体を考察します。 後半では、上流工程をAIで自動化する「Team Kit」というツールを紹介します。

Transcript

1. なぜAIは チーム開発を 速くしないのか 上流工程の自動化という回答 ── Team Kit
2. 自己紹介 Go Tanaka X: @tan_go238 フリーランスエンジニア 普段はマネジメントが中心ですが、 最近はAIを活用した開発プロセスの改善に取り組んでいます。 2
3. 宣伝 「要件定義の教科書」 を Zenn で無料公開しています。 ベテランPMと若手エンジニアの対話形式で、 炎上しないプロジェクトの作り方を解説しています。 30分程度で読める分量なので、要件定義に苦手意識がある方もぜひ。 https://zenn.dev/tan_go238/books/f4cdf93523210f 3
4. 宣伝 【AI駆動開発】開発環境共有会 #1 https://connpass.com/event/383067/ 4
5. デモ プロンプト このディレクトリ以下にTeamKitをダウンロードして使って検証＆使い方を確認してスライドに使い方の説明を追加してください。 コマンドと同等のファイルを作るのではなく、必ず実行してください。 1. TeamKitをダウンロードされていることを確認する。 2. 会議室の予約システムの要件を作成する。 3. /app-init コマンドでシステムの要件の質問に答えていってください。 - https://github.com/tango238/teamkit/blob/main/.claude/commands/teamkit/app-init.md を参照 - シンプルにコマンド実行してください 4. 一番最初に要件定義しないといけない機能のディレクトリに対して README.md があるか確認する。 5. 4のディレクトリに対して /generate コマンドを実行してモックとマニュアルが生成されることを確認する。 - https://github.com/tango238/teamkit/blob/main/.claude/commands/teamkit/generate.md を参照 - `--all オプション` は不要です - シンプルにコマンド実行してください 6. Webサーバーを起動して、生成されたモックをブラウザで表示してください。 5
6. デモ結果：生成されたファイル .teamkit/ ├── README.md ← システムの要件 ├── room-management/ ← app-initで生成 │ ├── README.md ← 要件定義（app-initで生成） │ ├── workflow.yml ← ワークフロー定義 │ ├── usecase.yml ← ユースケース分析 │ ├── ui.yml ← 画面設計 │ ├── screenflow.md ← 画面遷移図 │ └── mock/ ← 画面モック ├── reservation-management/ ← app-initで生成 └── user-authentication/ ← app-initで生成 6
7. 今日話すこと 第1部：いま現場で何が起きているか AIを導入しても成果が出ない2つのパターン 第2部：原因を突き止める 個人開発との比較から見えるボトルネックの正体 第3部：Team Kit という回答 上流工程を自動化するオープンソースツールの紹介と設計思想 7
8. AI駆動開発への期待 GitHub Copilot、ChatGPT、Claude ── ツールは急速に進化し、コードを書くスピードは飛躍的に向上しました。 しかし、チーム開発では思ったほど成果が出ていない現場が多いのではないのでしょうか？ 実際に現場で起こったエピソードについて紹介します。 8
9. エピソード① 子供にピストル ビジネス側のメンバーがAI研修後、バイブコーディング（AIにプロンプトだけでアプリを作らせる手 法）でアプリを作成。本番環境にデプロイし、既存システムのDBを直接更新しようとしていたた め、慌てて止めた。 怖さを知らない子供にピストルを渡すと、事故が起きる 9
10. エピソード② 大人は水鉄砲を欲しがる エンジニアが効率化のために、AI導入したいと言ってきた。 しかし、コードレビューの補助にしか使わず、チームに合わせたカスタマイズもしない。 結果として、全体のスピード感はあまり変わらなかった。 大人は、ピストルよりも 安全な水鉄砲 を欲しがる。 10
11. AIが武器を渡してくれる時代 武器の危険さは理解しつつも、威力を出していかないといけない 「水鉄砲では威力が足りない」 では、どうすればいいのか？ 11
12. 原因を突き止める 個人開発との比較から、ボトルネックの正体を探る 12
13. 個人開発はなぜ上手くいくのか まわりを見ていると、個人開発は 劇的に成果が出ている ように思える。 その理由は明確で、個人開発には コミュニケーションコストが存在しない から。 この視点で先ほどの2つのエピソードを振り返り、チーム開発で何が問題だったのかを考えてみる。 13
14. 個人開発 vs チーム開発 個人開発 チーム開発 意思決定 即断 会議・承認フロー 認識合わせ 不要 仕様書・レビュー・手戻り 待ち時間 ゼロ 依存関係・ブロッカー 仕様変更 即対応 影響範囲の調査・再合意 品質基準 自分次第 レビュー・テスト・承認 個人開発にはコミュニケーションのオーバーヘッドがない。 だからAIの恩恵を 100% 受け取れる。 チーム開発で成果が出ない原因は、この差にあるのではと思っています。 14
15. エピソード① を深掘りする：何が問題だったか ビジネス側がAIでアプリを作り、本番環境にデプロイしようとした。 【問題の根本】 AIが書いたコードの中身を理解していない 本番環境に触れることのリスクを知らない 「動いた＝完成」だと思い込んでいる 技術を理解しないまま危険な操作ができてしまう状況が生まれた 15
16. エピソード① の対策：ガードレール＋最低限のIT知識 安全装置（ガードレール）を用意する 本番環境に直接操作できない仕組みが必要。 Web APIやリードレプリカを用意する。 「できてしまう」状態を、 仕組みで防ぐ 最低限のIT知識を学んでもらう セキュリティの基本、技術用語、デプロイの意味、ステージング環境... まず 「何が起こり得るか」を理解 してもらう。 AIが武器を渡してくれる時代だからこそ、使う側にも最低限の訓練 が必要 16
17. 最低限のIT知識とは？ 技術が何もわかっていない人に対して、いきなりシステム開発は無謀。 かといって、IT用語は概念の理解も難しい。 。 まずはレベル別に分けて、段階的にAIを利用してもらうようにする。 レベル 範囲 ツール例 レベル0 自分の業務範囲をプロンプトを使って楽にする Claude Code レベル1 チームの業務をプロンプトを使って楽にする OpenClaw(セキュリティ注意) レベル2 チームの業務をシステム化して自動化する n8n レベル3 チームの業務をシステム化して自動化、外部システムとの連携を行う n8n + 自作 17
18. エピソード② を深掘りする：何が問題だったか AI導入を、補助程度にしか使わず、スピード感はあまり変わっていない。 【問題の根本】 過去の経験から慎重になりすぎている AIの適用範囲を自分で狭めてしまっている ツールの進化に追いつけず、初期設定のまま使い続けている 武器の威力を知っているからこそ、暴発を恐れて引き金を引けない。 18
19. エピソード② の対策：安全設計＋継続的なプロセス改善 プロジェクトに合わせた安全設計 ピストルが暴発しないよう設計する。 例：無限にレビューコメントが続くときは、どういう基準で止めるか決めておく（無限課金防止） 暴発しない範囲を見極めて利用する チームでの情報共有と日々の改善 AIは日々新しい機能がアップデートされている。 こうした情報をチーム内で共有し、継続的に改善し続けることが不可欠。 「導入して終わり」ではなく、日々のプロセス改善やメンテナンスを行う 19
20. 2つのエピソードから見えた構造 エピソード① 子供にピストル エピソード② 大人は水鉄砲 問題 リスクを知らず暴走 慎重すぎて威力が出ない 対策 ガードレール＋IT知識の習得 安全設計＋継続的プロセス改善 共通点 「仕組み」で解決すべき問題 「仕組み」で解決すべき問題 チームとして適切な仕組みを用意できていないことが原因。 では、なぜ仕組みが整わないのか？ ── その根本を探る。 20
21. チーム開発の根本的な課題 コミュニケーションコスト 21
22. チーム開発の根本的な課題：コミュニケーションコスト 前述の比較表で見たとおり、個人開発には認識のズレ・伝達ロス・待ち時間がない。 チーム開発ではAIが生む速度を、コミュニケーションコストが打ち消している。 特に深刻なのは 「認識のズレ」 ビジネス側が頭に描いているものを、エンジニアが最初から理解して、仕様書に落とし込むことは不 可能に近いし、役割分担が増えるほどコミュニケーションコストがかかるようになる。 AI駆動開発では、少人数で多岐に渡る役割をこなせないといけなくなってくる 22
23. なぜ少人数で多岐に渡る役割をこなせないのか 何をしているか分からない役割はできない ビジネス側 要望を伝えればシステムができるものだと思っている → 開発プロセスがブラックボックスになっている エンジニア 売上はビジネス側が考えるものだと思っている → 売上構造がブラックボックスになっている 23
24. ブラックボックスをなくしていくには ビジネス側は「要望を伝えるだけ」で終わらず、PoCを積極的に行う エンジニアは「技術だけ」でなく、プロダクトの価値そのものに注力する AIによって 「業務の境界が曖昧」 になりました。 全員が領域を越えて踏み込むことで、初めてAIの恩恵がチームに行き渡る つまり、少人数チームで回すには全員が今までよりもフルスタックに動く必要がある。 しかし現実には、それは難しい。── 開発プロセス全体を見てみましょう。 24
25. AIは「正解」は出すが、 「価値」は出さない 開発プロセス全体を見ると： AIは実装フェーズを劇的に速くしたが、実装は 開発プロセス全体の一部 でしかない。 「何を作るべきか」 「なぜ作るのか」 「誰のためなのか」 仕様や要件に 「正解」 は出してくれるが、 「価値」 を考えてくれるわけではない。 25
26. ボトルネックは上流にある 実装が速くなった結果、相対的に上流工程の遅さが目立つようになった。 「この機能、何を作ればいいんだっけ？」→ 要件確認の会議 「仕様書と画面イメージが合わない」→ 認識合わせのやり直し 「ここ、こういう意味じゃなかった」→ 作り直し AIで実装が10倍速くなっても、上流の手戻りが3回発生すれば、プロジェクト全体は速くならない。 26
27. ここまでの整理 エピソードごとの対策： ① ガードレール＋最低限のIT知識 → 安全に使える環境を作る ② 安全設計＋日々のプロセス改善 → 威力を引き出す運用を作る チーム開発の構造的な課題： ①コミュニケーションコスト → 認識のズレが手戻りを生む ②既存の役割に縛られている → 全員が領域を越える必要がある 関係者が集まる上流工程がボトルネックになりやすい これらをまとめて解決する仕組みはないだろうか？ 27
28. もし上流工程そのものをAIで自動化できたら？ ガードレールと威力を両立し、 コミュニケーションコストを減らし、役割の壁を越える 28
29. Team Kit という回答 上流工程を自動化するオープンソースツール 29
30. Team Kit とは Claude Code と連携し、要件定義 → 仕様書作成 → モックアップ生成までを自動化するツール コードを書く前の「上流工程」をAIで自動化する curl -fsSL https://raw.githubusercontent.com/tango238/teamkit/main/install.sh | bash -s -- . 30
31. 設計思想 ― 安全な射撃場 自動化する領域を「実装の前」に絞る AIで実装を速くするツールはすでにたくさんあるので、上流工程に焦点を当てている。 安全と威力の両立 生成するのは モックアップとドキュメント だけ。 本番コードは生成しない。インフラにも触れない。 ビジネス側が自由に動いても、事故は起きない。 実際に動く画面を見ながら議論できるので、手戻りリスクも減らせる。 31
32. ワークフロー全体像 たった 4ステップ で、要件から仕様書とモックアップが出来上がる。 32
33. Step 1：README.md に要件を書く .teamkit/<YourFeature>/README.md に自然言語で要件を記述する。 # 顧客管理 ## 背景 既存のExcel管理では顧客情報の共有・検索が困難。 ## 目的 顧客情報を一元管理し、対応履歴を可視化する。 ## 主要アクター 営業担当者、マネージャー ## 要件 - 顧客の登録・編集・削除 - 顧客一覧の検索・フィルタリング - 対応履歴の記録 特別なフォーマットは不要。ビジネス側でも書ける。 33
34. Step 2：/teamkit:generate README.md を入力にして、仕様書とモックアップを一括生成する。 Claude Code 上でスラッシュコマンドを実行： /teamkit:generate <YourFeature> --all 処理は自動で順次実行される。 34
35. 生成されるファイル構成 機能単位（.teamkit/<YourFeature>/ ） ├── README.md ← 手動作成（要件） ├── workflow.yml ← ワークフロー定義 ├── usecase.yml ← ユースケース分析 ├── ui.yml ← 画面設計 ├── screenflow.md ← 画面遷移図 ├── manual.md ← 操作マニュアル（--all時） ├── acceptance-test.md ← 受入テスト（--all時） └── mock/ └── index.html ← HTMLモックアップ 自然言語の要件が構造化された仕様書に変換される。 ビジネス側もエンジニアも、同じファイルを見て議論できる。 35
36. Step 3：ブラウザで確認 .teamkit/<YourFeature>/mock/index.html をブラウザで開くだけ。 ページ遷移が動作するHTMLファイル群 実際のUI要素（フォーム、テーブル、ボタン）が動く Figma でもワイヤーフレームでもなく、ブラウザで動くHTML。 画面をみながらフィードバックを行う。 36
37. フィードバックサイクル モックアップを見て気づいた点を、その場で反映できる。 /teamkit:feedback <YourFeature> --preview "住所欄を都道府県と市区町村に分割して" 自然言語でフィードバックを入力するだけ --preview オプションでモックアップに即時反映 「ここ、こうしたい」がその場で形になる。会議が前に進む。 37
38. フィードバックを仕様に反映 フィードバック結果を、仕様書にも反映する。 /teamkit:apply-feedback <YourFeature> フィードバックの内容を仕様書（workflow.yml, ui.yml 等）に反映 モックアップと仕様書が常に同期された状態を維持 仕様書を「書いたら終わり」ではなく、常に最新のドキュメントにする。 38
39. マニュアル自動生成 モックアップだけでなく、操作マニュアル（PDF） も自動生成できる。 /teamkit:generate-manual <YourFeature> --capture 操作手順、画面一覧、入力ルール、画面遷移、注意事項を網羅 --capture オプションでモックのスクリーンショットを自動撮影しマニュアルに埋め込み Markdown から PDF を生成（Marp形式） 統合コマンドでも生成可能： /teamkit:generate <YourFeature> --manual --capture 39
40. マニュアルの編集と再生成 生成された manual.md は手動で編集・調整できる。 .teamkit/<YourFeature>/ ├── manual.md ← Marp形式。テキストエディタで編集 ├── manual.pdf ← PDF出力 └── mock/screenshots/ ← --capture で撮影した画像 テキスト修正、改ページ追加、画像サイズ調整が自由に可能 編集後は marp-cli でPDF再生成 仕様書もマニュアルも「生きたドキュメント」 として運用できる。 40
41. 受入テスト acceptance-test.md は、要件を元に開発されたシステムに対して E2Eテストを実行する ためのファイル。 【このファイルの使い方】 実行対象の URL やアクセスに必要な情報と一緒ににエージェントに渡す Playwright を起動し、受入テストの項目を自動で検証（エージェントによる） 画面操作・表示確認・遷移チェックまで、ブラウザ上で動作確認 テスト実行には e2e-runner エージェントの利用がおすすめ。 仕様書から生まれたテスト項目で、実装の正しさを自動検証できる 41
42. 役割分担の変化 Before（従来） After（Team Kit） ビジネス側 要件を口頭やドキュメントで伝達 → 認識ズレ多発 README.mdに 要件 を書く → モックで即確認 エンジニア 要件ヒアリング > 仕様書作成 > 実装 → 手戻り 自動生成された仕様・モックを レビュー → 設計と実装に集中 AI あくまで補助のみ（水鉄砲） 上流工程の自動化（安全な射撃場） 42
43. Team Kit が実現する世界 フルスタック人材がいなくても、ビジネス側とエンジニアが Team Kit を介して 協働すれば、 少人数チームで高いパフォーマンスが出せる。 AIが 「人の代わり」 になるのではなく 「人と人の間」 を埋める。 43
44. 子供も大人も、同じ射撃場に立てる それがチーム開発における AI の正しい使い方 AIがチーム開発を速くしない原因は、コードではなく 上流工程 にあった。 人とAIではなく、人と人の間 をAIで埋める ── それが Team Kit の設計思想。 44
45. はじめる curl -fsSL https://raw.githubusercontent.com/tango238/teamkit/main/install.sh | bash -s -- . オープンソース（MIT License） Claude Code があればすぐに使える GitHub: github.com/tango238/teamkit 45
46. ありがとうございました！ 46