AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era

■セッション概要
生成AIの登場により、ソフトウェア開発はかつてないスピードで変化しています。
コーディングやドキュメント作成、資料作成といった“作業”は加速度的に効率化が進み、Vibe CodingやAgentic Codingのように、開発の役割や働き方そのものを揺さぶる変化も生まれています。

では、こうした変化の中で、私たちのマネジメントや開発プロセスは変わらないままでいられるでしょうか。
もし変わらないとしたら――その時、ボトルネックになるのは“人やプロセス”かもしれません。

スクラムは、チーム全体が一つの“全体性”として動くことを支えるフレームワークです。
しかし普及が進むにつれ、その本質は形骸化しがちです。
生成AIと共に働く時代だからこそ、チーム・組織・プロダクトの全体を見渡し、「全体で創る力」がますます問われているのではないでしょうか。

このセッションは、私が答えを提示する場ではありません。
正解が見えない中でも、未来の開発のあり方を妄想し、語り合いながら、「僕らが本当に作りたいスクラムチーム」を一緒に描くための対話の場です。
参加者の皆さんと共に、AI時代のスクラムチームの可能性を探求します。

スクラム祭り2025で登壇したときのスライドです。
https://confengine.com/conferences/scrummatsuri/proposal/23305/ai

■作者
フィードバックやお問い合わせはこちらまで！
https://agile-monster.com/profile/
https://agile-monster.com/contact/
https://x.com/TAKAKING22

Transcript

1. AI時代だからこそ考える、 僕らが本当につくりたいスクラムチーム 及部敬雄 (@TAKAKING22) 2025/10/04 スクラム祭り2025 福岡トラック
2. 世はまさにAI時代
3. 「またAIの話かよ・・・」って思ってませんか？
4. 2022年11月、ChatGPTリリース Photo by BoliviaInteligente on Unsplash
5. 当時は新たな技術の登場にわくわくしていた
6. それから3年が経ち、 目に入ってくるのはAIに関する話題ばかり
7. AI疲れ
8. 第四次産業革命、真っ只中 第一次産業革命（18ʙ19世紀）：蒸気機関 第二次産業革命（19世紀後半ʙ20世紀初頭）：電力、大量生産 第三次産業革命（20世紀後半）：コンピュータ、自動化 第四次産業革命（21世紀ʙ現在）：AI、IoT、ロボット
9. 技術革新を背景に生産方式や社会構造が
 急速かつ大規模に変化する歴史的転換のこと 産業革命
10. AI疲れの正体 ほとんどの人にとって今起きている変化は過去最大級 今目の前で起きている・起きようとしている変化量が大きすぎて 認知の許容量を超えてオーバーフローしている状態 生存本能から現状維持バイアスがかかり、変化を受け入れようと しない
11. https://www.youtube.com/watch?v=nHIlMlpDWzg "The Agilists’Emerging Superpower and Our Planetary Challenge”/ Lyssa Adkins：RSGT2023 Keynote
12. 目の前の変化を乗り越えたら次の変化が来る
13. あれ？ アジャイルソフトウェア開発宣言 スクラムガイド2020
14. 私たちは知っている アジャイル開発やスクラムの普及期、変化を受け入れない現状維 持バイアスと戦って変化を起こそうとしてきた ex. 今仕事ができてるんだから変える必要ないのでは？ ex. そんなよくわからない新しいやり方は採用できない アジャイル開発やスクラム自体、変化に適応することが主な目的
15. アジャイル開発の実戦経験を積み、 コミュニティで研鑽を続けてきた私たちが 今こそAI時代という変化に適応するとき Photo by Thao LEE on Unsplash
17. AI時代だからこそ考える、 僕らが本当につくりたいスクラムチーム 及部敬雄 (@TAKAKING22) 2025/10/04 スクラム祭り2025 福岡トラック
18. AI時だからこそ考える、僕らが本当につくりたいスクラムチーム 生成AIの登場により、ソフトウェア開発はかつてないスピードで変化しています。 コーディングやドキュメント作成、資料作成といった“作業”は加速度的に効率化が進み、 Vibe CodingやAgentic Codingのように、開発の役割や働き方そのものを揺さぶる変化 も生まれています。 では、こうした変化の中で、私たちのマネジメントや開発プロセスは変わらないままでいら れるでしょうか。もし変わらないとしたら――その時、ボトルネックになるのは“人やプロ セス”かもしれません。 スクラムは、チーム全体が一つの“全体性”として動くことを支えるフレームワークです。 しかし普及が進むにつれ、その本質は形骸化しがちです。 生成AIと共に働く時代だからこそ、チーム・組織・プロダクトの全体を見渡し、「全体で創 る力」がますます問われているのではないでしょうか。 このセッションは、私が答えを提示する場ではありません。 正解が見えない中でも、未来の開発のあり方を妄想し、語り合いながら、「僕らが本当に作 りたいスクラムチーム」を一緒に描くための対話の場です。 参加者の皆さんと共に、AI時代のスクラムチームの可能性を探求します。
19. お話のターゲット AIによる変化は感じているものの、具体的に自分たちの仕事への 影響について考える時間を持てていない方
20. Learning Outcome AIがソフトウェア開発に与える具体的な影響を理解できる すでに起きている変化とこの先起こりうる変化の可能性を知るこ とができる AI時代のアジャイル開発やチームのあり方を考えるきっかけを得 られる 正解ではなく、自分たちの答えを描くための視点を持ち帰られる
21. TAKAKING22 及部敬雄 制御不能なアジャイルモンスター 株式会社ホロラボ 執行役員 Silver Bullet Club所属 AGILE-MONSTER.COM アジャイルコーチ
22. アジェンダ AIとソフトウェア開発 スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム
23. アジェンダ AIとソフトウェア開発 スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム
24.  元年 "*
25. ⇒2025年4月時点で1,500万人以上 AI時代のアジャイル開発（XP祭り2024版）
26. 2025年2月から3月くらいの調査期間のレポート
27. AI活用はコード生成とリサーチがメイン https://2025.stateofai.dev/en-US/
28. AIによって生成されたコードの割合は平均28% https://2025.stateofai.dev/en-US/
29. よく使われるモデルはChatGPT、IDEはCursor https://2025.stateofai.dev/en-US/
30. AIエージェント
31. Vibe Coding 2025年にAIエージェントが進化し、Vibe Codingが登場した ことで、ソフトウェア開発の変化のスピードが一気に加速した Claude Codeから定額制が導入されたことも大きい AIエージェントの自走力が上がり、並列開発も可能に 「コードを書く」から「問いを立て、設計する」へ
32. “In one year, AI will be writing 100% of code.” - Dario Amodei -
33. AIとソフトウェア開発の現在（2025/10） Claude CodeやCodex、Gemini CLIなど強力なツールが
 登場し、ソフトウェア開発における生成AI活用が加速している 開発の作業支援からAIエージェントへ Vibe Coding、そしてAgentic Coding 「AIと委託」か「AIと伴走か」
34. AIとソフトウェア開発の現在（2025/10） 作業効率は確実に上がっているが、ソフトウェア開発全体の
 スループットが劇的に変化しているようには感じない Outputの量とスピードが増えたことで、ソフトウェア開発に
 おける問題がより健在化しやすくなった レビュー、品質、人材育成、コミュニケーション・・・ OutputをOutcomeにつなげる部分が追いついていない
35. 再び開発プロセスやチームがボトルネックに
36. Open AI社が唱える5つのステージ Stage 1：Chatbots, AI with conversational language Stage 2：Reasoners, human-level problem solving Stage 3：Agents, systems that can take actions Stage 4：Innovators, AI that can aid in invention Stage 5：Organizations, AI the can do the work of organization
37. 変化は止まらない AIの進化はまだ過程の段階 現時点でプロセスやチームがAIの性能を引き出せていないだけで、
 そこを支援するAI技術の登場や、人・チームの適応によって、
 革命的な変化が急に訪れることも 好むか好まざるかに関わらず、変化のベクトル自体は誰も止められ ない
38. アジェンダ AIとソフトウェア開発 スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム
39. スライド7枚で「スクラム」
40. スクラムの構成要素 スクラムチーム 開発者 プロダクトオーナー スクラムマスター 作成物 プロダクトバックログ スプリントバックログ インクリメント イベント スプリント スプリントプランニング デイリースクラム スプリントレビュー スプリントレトロスペクティブ 1
41. スクラムマスター プロダクトオーナー 開発者 教える 支援する つくる 価値を 最大化する 教える 支援する 2
42. スクラムマスター プロダクトオーナー 開発者 教える 支援する つくる 価値を 最大化する 教える 支援する スクラムチーム 3
43. Day1（水） Day2（木） Day3(金） Day4（月） Day5(火） 9:00 10:00 スプリント プランニング 11:00 12:00 13:00 デイリースクラム 14:00 15:00 スプリント レビュー 16:00 バックログ
 リファインメント 17:00 スプリント
 レトロスペクティブ スプリント 4
44. スクラムのイベントと作成物の関係 1. プロダクトバックログを用意する 2. スプリントバックログを用意する（スプリントプランニング） 3. スプリントを実施する 4. チームの状況を毎日検査をする（デイリースクラム） 5. 成果＝インクリメントを見せる（スプリントレビュー） 6. 開発の様子をふりかえる（スプリントレトロスペクティブ） 5
45. 何度も繰り返す スプリントを何度も繰り返す チームで学習してうまくなっていく 6
46. スクラムのまとめ プロダクトの機能を欲しい順番に並べ変えてその順番につくること
 で成果を最大化する（価値を基準） 短い時間に区切って繰り返す（タイムボックス） 仕事の状況や問題を関係者間で常に共有する（透明性） 定期的に仕事の進捗やプロダクトの方向性や仕事の進め方に
 問題がないかを確認する（検査） もっとうまくやる方法を常に追い求めてやり方を変えていく（適応） 7
47. よくある現実スクラム（私見） チームの人数は4ʙ7人 スプリントの期間は1ʙ週間 プロダクトオーナー、スクラムマスター、開発者 （プロダクトオーナーはいるけどスクラムイベントくらいしか話してない） （会社の役割は変わらないからエンジニアの誰かがスクラムマスター兼任になる） チームで仕事が完結する機能横断型なチームを構成したい （デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち） タスクは個人アサイン型でカンバンで管理 （スウォーミングはわかるけど生産性悪そうだし現実的ではない）
48. この2年間で、 あなたのチームの開発プロセスや構造は
 どれくらい変わりましたか？
49. よくある現実スクラムの最近（私見） 開発者が生成AIツールを使って仕事をするのが普通になってきた ロールの役割や仕事の進め方は以前と変わっていない 生成AIツールを使って作業は効率的はなったけど、チームの OutputやOutcomeが大きく変わった感じはしない
50. どれだけ車が速くなったとしても、 ドライバーや道路環境が変わらなければ スループットは変わらない
51. 「開発プロセス」や「チーム」も変化の対象 Photo by Gift Habeshaw on Unsplash
52. Scrum Guide Expansion Pack https://scrumexpansion.org/ja/scrum-guide-expansion-pack/2025.6/
53. https://www.servantworks.co.jp/resources/created/scrum_overview/
54. Scrum Guide Expansion Pack 2025年6月11日に公開（日本語訳も公開されている） スクラムガイド共同著者ジェフ・サザーランド氏が著者の一人 公式ガイドではなく非公式のパタンライブラリ スクラムガイドを補完する目的で、特に生成AIによって
 もたらされる変化への適応を考慮されて書かれている 役割の再定義と拡張、コミットメントの再定義、理論の強化 GitHub上で公開され、誰でもフィードバックすることができ、
 四半期ごとに更新される予定
55. スクラムはこのままでよいのか この2年間で開発プロセスやチームがあまり変わっていないとし たらそこがボトルネックになっているかもしれない AIによってソフトウェア開発にもたらされる変化に合わせて、
 開発プロセスやチームも適応していかなければならない スクラムも更新されていくが、それ以上のスピードで
 自分たちの開発プロセスもチームも更新していく必要がある
56. 明確に区別する 制約を理解しその中でできることを模索すること、そして成果を 出しながら周囲の信頼を獲得し、制約自体の除去にも取り組んで いくこと 「できることを一生懸命やっている」という自己正当化を行い、 制約に飲まれて妥協したやり方でただこなしていること この2つは明確に区別しなければならない
57. 変化の過程？それとも妥協？ チームの人数は4ʙ7人 スプリントの期間は1ʙ週間 プロダクトオーナー、スクラムマスター、開発者 （プロダクトオーナーはいるけどスクラムイベントくらいしか話してない） （会社の役割は変わらないからエンジニアの誰かがスクラムマスター兼任になる） チームで仕事が完結する機能横断型なチームを構成したい （デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち） タスクは個人アサイン型でカンバンで管理 （スウォーミングはわかるけど生産性悪そうだし現実的ではない）
58. これから起こり得る２極化 AIの進化を吸収してチームで生産性を上げて価値を向上してい くチーム いままでとあまり変わらないチーム
59. アジェンダ AIとソフトウェア開発 スクラムはこのままでよいのか AI時代だからこそ本当につくりたいスクラムチーム
60. AI時代だからこそ本当につくりたいスクラムチーム 柔軟で滑らかな開発サイクル 複数の小さなチームとロールの再定義 学習する組織化
61. 柔軟で滑らかな開発サイクル
62. 生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ “スプリントは1ヶ月以内の決まった長さ” via スクラムガイド2020 コミュニケーションをするタイミングをつくる ex. スプリントプランニング、デイリースクラム、スプリントレビュー… それ以外のスプリント期間で開発を進める
63. 生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ AIによって開発が効率化され、同じ仕事量をこなすまでの時間がかからなくなる すると何が起きるのか
64. 生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ サイクルを変えないままだと、同期間に対応するPBIが増える 相対的に扱う情報量は増え、コミュニケーションコストも増大する
 （プロダクトバックログづくり、仕様の確認、レビュー、受け入れ・・・） バッチサイズが大きくなってしまいフィードバックループの効果が半減する
65. 生成AIによる開発サイクルへの影響 .PO 5VF 8FE 5IV 'SJ ίϛϡχέʔγϣϯ ։ൃ だから開発サイクルを短くする 1週間スプリントから1日スプリントへ
66. 滑らかに変化をできるようにする
67. フラクタル構造 スプリント期間はフラクタル構造をとってもよい プロダクトとチームの全体性を2つの期間から検査・適応する ダブルループ 1日 スプリント 1日 スプリント 1日 スプリント 1日 スプリント 1日 スプリント 1週間スプリント
68. やがてカンバンへ 突き詰まっていくとスプリントというタイムボックス自体が
 不要になる可能性もある カンバンでフローを制御する
69. カンバンガイド カンバンとは、あるシステムを通じて価値の流れ（フロー）を最 適化するための戦略である 以下の3つのプラクティスが連携して機能する ワークフローを定義し可視化する ワークフローの項目を主体的に監視する フローを改善する https://kanbanguides.org/ja/
70. 人間がボトルネックになる！？ 扱わなければいけない情報量が増える 同期間に対応するPBIの量 コミュニケーション（プロダクトバックログづくり、仕様確認、レビュー・・・） それらをマネジメントするケイパビリティがなければ、
 開発の効率があがっても開発サイクル全体の効率はあがらない プロダクトマネジメント プロジェクトマネジメント ピープルマネジメント
71. マネジメント 個人 チーム・組織 会社 ポートフォリオマネジメント 財務 コーポレートガバナンス ・・・ プロジェクトマネジメント プロダクトマネジメント ピープルマネジメント ・・・ ナレッジマネジメント 学習マネジメント ・・・
72. マネジメントにおける重要な要素 成果を上げるために意思決定を行う／ピーター・F・ドラッカー 意思決定の5つのステップ 1. 問題を知る 2. 必要条件を明確にする 3. 何が正しいかを知る 4. 行動に変える 5. フィードバックを行う 情報を持っているか 情報にアクセスできるか 情報を選択できるか
73. 生成AIとのやりとりも意思決定の繰り返し ・・・ どの問題を解くのか どんなプロンプトを入力するか どんなフィードバックをするか レスポンスを受け入れるか どこまで繰り返すか 結果を検証し問題ないと判断する レスポンスは適切か否か 欲しい情報は充足したか 受け入れたうえで次に何をするのか 結果を受け入れるか
74. どうやってケイパビリティをつくるか AIの性能を引き出すことができる開発サイクル 開発サイクルをまわすために必要なチームのかたち 機能するチームになるために必要な学習の仕組み
75. 複数の小さなチームとロールの再定義 Photo by Omotayo Kofoworola on Unsplash
76. スクラムにおけるチーム 小規模で自己組織化されたクロスファンクショナルチーム チームメンバーがお互いに補完するさまざまな知識やスキルを持っている さまざまな変化に対応し、チームで多様な問題を解決できるようにする
77. 人間＋生成AIのチームへ 人間のみのチーム 人間+生成AIのチーム 生成AI 生成AIは多様なドメイン知識、プログラミングスキル、設計スキルをもっている 知識の総量は人間よりもはるかに大きい（今後ますます大きくなっていく） もちろん人間にしかできない領域も存在する
78. より小さなチーム、より多くのチームへ 6人 X 2チーム （1ʙ3人＋生成AI） X 5チーム AI AI AI AI AI 人間＋生成AIのチームであれば、少ない人数でも経験やスキルを補完できるようになる 10人以下（スクラムガイド2020）がよいとされていたチームサイズがより小さくなる 小さなチームが増えるので、これまでよりも多くのチームでコラボレーションをしながら
 開発を進めるシーンが増える
79. ロールの再定義 開発者はAIによってより全体性をもって仕事に取り組み、
 意思決定に関わる機会が増える Outputの量とスピードが上がることでプロダクトオーナーがボ トルネックになりやすくなるので、開発者もプロダクトの意思決 定に直接関わり、一部を代替する 考える人とつくる人の距離が近づき、やがて同一化なる 開発者からアーキテクトへ
80. ロールの再定義 小さなチームになることでチーム内のコミュニケーションコスト は減るが、チーム横断のコミュニケーションコストは増える スクラムマスターは大きなチームの支援に スクラムマスターはチームと個人が自己組織化を支援する スクラムマスターからチームコーチへ
81. 大きなチームと小さなチーム チームコーチ チームサポート 小さなチーム 小さなチーム 小さなチーム 小さなチーム 大きなチーム
82. 学習する組織化
83. 学習の重要度が増す 複雑で変化が激しい状況では学習の重要度も増す AIの使い方 新しい開発プロセス 新たなロール 個人学習に依存することはできなくなるため、
 学習する組織になるための仕組みを積極的に導入する
84. 全体としての意思決定の総数を増やす 小さなチームがそれぞれ自己組織的に運営することを目指す 全体としての意思決定の機会が増え、
 意思決定の打席に立つ人と回数が組織全体に増える 経験を積み、経験から学習をする
85. ペアワーク／モブワーク 小さなチームではペアワークを推奨する ドライバー⇒AI、ナビゲーター⇒人間×2 AIによってOutputの量とスピードが増えるため、
 属人化を防ぐ意味でも常に4つの目を使う必要がある チームを超えた知識移転や学習の機会として、
 モブワークを活用する
86. Team Open Space Technology チームというコンテキストがそろった状態でのOST 個人、相互作用、プロセス、ツール、完成の定義に関して
 検査と適応を行うことを目的とする 神回が常に起こることを目指し、知的コンバットの練習を
 繰り返す
87. AI時代だからこそ本当につくりたいスクラムチーム 柔軟で滑らかな開発サイクル 複数の小さなチームとロールの再定義 学習する組織化
88. AIによって生まれた新しい課題ではない OutputをOutcomeにつなぐ 考える人とつくる人をどうやって近づけるか 人とチームをどう育てるか 課題に向き合わなければいけない必要性が増した AIによって課題に向き合う必要性が増した
89. スクラムの全体性 スクラムフレームワークは不変である。スクラムの一部だけ を導入することも可能だが、それはスクラムとは言えない。 すべてを備えたものがスクラムであり、その他の技法・ 方法論・プラクティスの入れ物として機能するものである。 スクラムガイド2020
90. 変化に向き合う覚悟を持つ 結果としてスクラムではなくなるかもしれないがそれでいい ロールも開発サイクルもチームのかたちも変数にする 複雑な問題を単純化するのではなく、複雑なまま取り扱う 確実に失敗しない挑戦はない
91. 今取り組んでいることを事例としてお話します（予定） https://confengine.com/conferences/regional-scrum-gathering-tokyo-2026/proposal/24521/ai
92. どちらが真実なのか AIはゲームチェンジャー エンジニアの仕事はなくなる アジャイルは死んだ 開発生産性は劇的に変わる AIはそれほど使えない エンジニアの仕事は残る アジャイルは死なない 開発生産性は変わらない
93. A. どっちでもいい
94. まさにやっかいな問題（Wicked Problem） 1. 解決策が真偽でなく善悪である 2. 解決策の試行錯誤ができない 3. 解決策が問題の味方に縛られる 4. 問題だとイイ切れない 5. 解決に終わりがない 6. 問題が唯一無二 7. 多様な問題が絡み合う 8. 明確な問題定義ができない 9. 終わりを決めるルールがない 10.即効性のある解決策がない
95. 安易な二元論にとらわれない AIという大きな変化に「うっ」ときていることを認知する 不確実な状況下でどちらの未来が来るのか予測する必要はない 決定を遅延し、選択肢を広く持ち続ける どちらの未来が来ても成功できる能力を身につける 思考と試行を繰り返し、経験からよりよいやり方を模索する
96. 私たちは変化への立ち向かい方を知っている アジャイルソフトウェア開発宣言 スクラムガイド2020
97. アジャイル開発誕生の背景 アジャイル開発（アジャイルソフトウェア開発宣言）は、
 当時世界各地で変化に挑戦し学びを体系化していた人たちが
 集まり、その集合知を言語化したもの 2001年 スノーバード アジャイル
 開発 知見 知見 知見
98. 1970年代　ウォーターフォール・モデル誕生 2001年　　アジャイルソフトウェア開発宣言
99. 1970年代　ウォーターフォール・モデル誕生 2001年　　アジャイルソフトウェア開発宣言 2030年　　 ？？？ 2025年 私たちの現在の試行錯誤が、 ソフトウェア開発の未来をつくる
100. 未来へバトンをつなぐ 今度は私たちがコミュニティに知見を持ち寄り、
 AI時代の変化に適応するなにかを生み出すとき 更新なのか新規なのかはどちらでもよいが日本発だと嬉しい コミュニティ ？？？ 知見 知見 知見
101. AI時代に突入し、ここからさらに変化が早くなり、 開発プロセスやチームにボトルネックが移っていきます。 そんな時代だからこそ、アジャイル開発やスクラムを通し て、変化に適応できるよいチームを増やしていくことの社 会的意義が増していきます。 そして、その取り組みの中で今のあたりまえを疑い、常に よいやり方を模索し、コミュニティを通して皆さんと知見 を共有しあっていくことで、未来のソフトウェア開発にバ トンを送りたい。
102. @TAKAKING22 及部 敬雄 https://agile-monster.com/ 一緒に取り組んでいきましょう！ 現役のアジャイル開発実践者による アジャイルコーチ お仕事のご相談も雑談もぜひお気軽にお声がけ下さい！