AI時代のアジャイルチームを目指して ー スクラムというコンフォートゾーンからの脱却 ー / Toward Agile Teams in the Age of AI

■セッション概要
AI時代のソフトウェア開発
生成AIの登場によって、ソフトウェア開発はかつてない速度で変化しています。特に設計、コーディング、テスティングなどは生成AIの活用が進み、エンジニアの仕事の軸足自体が変化しているように感じます。また、生成AIを組み込んだソフトウェアも増えています。

一方で、こうした技術的な進歩に比べると、チームや開発プロセス、マネジメントの仕組みは大きく変わっていません。生成AI活用によって開発のスループットが上がれば、ボトルネックは別の場所に移動するはずです。

"スクラム" というコンフォートゾーン
アジャイル開発はもともと、当時主流とされていた伝統的開発手法に対するアンチテーゼから生まれました。実践者たちが「あたりまえ」を疑い、試行錯誤し、もっとよい方法を求め続けた結果生まれた集合知です。ちなみに私がアジャイル開発にシンパシーを感じているのはまさにこの反骨精神です。

アジャイル開発の代表格であるスクラムは広く普及し、多くの現場でスタンダードになりました。それが故に、スクラムはよりよい方法を求め続けるものというよりも、とりあえずやっておけばよいものになりつつあります。それらの現場では、もはやスクラム自体が疑うべき「あたりまえ」になってしまっているのかもしれません。

スクラムガイドは2020年版が最新ですが、AI時代の変化に適応するためには、私たち自身がチームや開発プロセスを問い直し、アップデートしていく必要があります。

AI時代のアジャイルチーム
生成AIによって主に開発を中心にスループットが上がった状態を、全体のアウトカムの向上につなげるためには、チームや開発プロセスによって一度に取り扱う情報量を増やす必要があります。

こうした変化に対応するため、私たちはAI時代のアジャイルチームをより小さな単位で構成します。2〜3人＋生成AIで構成されるスモールチームが複数集まり、フラクタルなコミュニケーション構造をもつことで柔軟性と拡張性を保持します。

スモールチームがそれぞれ自律的にソフトウェア開発のフィードバックループをまわし、それを包含する組織では組織単位での意思決定や学習を蓄積するためのフィードバックループをまわします。

たくさんのチームを素早く成長させる必要があるため、横断的なチームコーチやチームサポートをロールとして配置し、個人やチームの学習をサポートします。また、彼らはマネジメントとしてチーム間をつなぐ役割も担います。

このようなチームや開発プロセスの変化に伴って、ロールの再定義やコミュニケーションの再設計も行っています。

もちろんこれらは実験でもあり、変化の過程でもあります。イベント当日までに更に変化をしているかもしれません。しかし、私たちがなにを考え、どのように変化をし、どのように再現性をもたせようとしているのかについて、ご紹介させていただきます。

生成AI疲れしている場合ではない！Nextアジャイル開発を日本から生み出そう！！
このプロポーザルを読んでくださっている皆さんは、おそらくアジャイル開発に取り組まれている方が多いでしょう。私たちはアジャイル開発の実践経験を活かし、今こそ変化に適応するときです。生成AI疲れしている場合ではありません。

We are uncovering better ways of developing software by doing it and helping others do it.
私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。
（アジャイルソフトウェア開発宣言より）

ぜひ日本からNextアジャイル開発を生むために、一緒に考えましょう。

Regional Scrum Gathering Tokyo 2026で登壇したときのスライドです。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2026/proposal/24521/ai

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

Transcript

1. AI時代のアジャイルチームを目指して ー “スクラム”というコンフォートゾーンからの脱却 ー 及部敬雄 (@TAKAKING22) 2026/01/08 Regional Scrum Gathering Tokyo 2026 イッテンハチ RSGT2026＠ベルサール羽田空港大会 1
2. 世はまさに大AI時代
3. 2022年11月、ChatGPTリリース Photo by BoliviaInteligente on Unsplash
4. ChatGPT誕生から約3年間 2023年：生成AI元年 Chat GPT誕生 GPT-4公開 2024年 業務ツールに生成AI標準搭載が進行 マルチモーダルAI 2025年：AIエージェント元年 Claude Code月額課金化 4
5. AI疲れ
6. AI疲れの正体 現在、第四次産業革命真っ只中 第一次産業革命（18ੈلʙ19世紀）：蒸気機関 第二次産業革命（19世紀後半ʙ20世紀初頭）：電力、大量生産 第三次産業革命（20世紀後半）：コンピュータ、自動化 第四次産業革命（21世紀ʙ現在）：AI、IoT、ロボット 産業革命とは、技術革新を背景に生産方式や社会構造が急速かつ大規模に変 化する歴史的転換のこと ほとんどの人にとって今目の前で起きている変化は過去最大級 変化を受け止めきれず、認知の許容量をオーバーフローしている状態 6
7.  アジャイルソフトウェア開発宣言 スクラムガイド2020 Extreme Programming
8. 私たちは知っている 変化に適応すること自体が主な目的のひとつ XP・スクラム・アジャイル開発の普及期、変化を受け入れない 現状維持バイアスと戦って変化を起こそうとしてきた ex. 今仕事ができてるんだから変える必要ないのでは？ ex. そんなよくわからない新しいやり方は採用できない
9. XP・アジャイル開発・スクラム界隈の皆さん、 AI時代の変化を楽しんでいますか？
10. AI時代のアジャイルチームを目指して ー “スクラム”というコンフォートゾーンからの脱却 ー 及部敬雄 (@TAKAKING22) 2026/01/08 Regional Scrum Gathering Tokyo 2026 イッテンハチ RSGT2026＠ベルサール羽田空港大会 10
11. 11 TAKAKING22 及部敬雄 制御不能なアジャイルモンスター 株式会社ホロラボ 執行役員 Silver Bullet Club所属 AGILE-MONSTER.COM アジャイルコーチ
12. セッション概要 AIの進化と普及が進み、ソフトウェア開発の中でAIを活用することは
 もはやあたりまえとなりつつあります 作業レベルでのAI活用が進む一方で、スクラムをはじめとするチームや開発 プロセスはあまり変化できていません AI時代に必要なアジャイルチームとはなにかを考えていること、
 実際の現場で実践していることをお話します このテーマに関心を持ってくださった方と、知見を交換したり、
 ディスカッションをするきっかけになれば嬉しいです 12
13. We shapes our tools, and thereafter our tools shape us. 私たちは道具を形作り、その後、道具が私たちを形作る - マーシャル・マクルーハン -
14. 道具と人 道具によって人間の生活や活動が変わった例 印刷技術：思想や情報が大量複製され、不特性多数に同時に届くメディアが生まれた 蒸気機関：機械動力による大量生産が可能になり、工場制産業が成立した インターネット：情報と人が即時につながる地理的制約のほぼない社会を生んだ AI：？？？ AI（道具）を使って何をするのかよりも、AI（道具）を使う私たち（人 間）はどうあるべきかを考えたい 左記に価値があることを認めながらも右記により価値をおく 14
15. アジェンダ AIとソフトウェア開発 スクラムというコンフォートゾーン AI時代のアジャイルチーム 
16. ChatGPT誕生から約3年間 2023年：生成AI元年 Chat GPT誕生 GPT-4公開 2024年 業務ツールに生成AI標準搭載が進行 マルチモーダルAI 2025年：AIエージェント元年 Claude Code月額課金化 16
17. AIとソフトウェア開発の現在（2026年1月） ソフトウェア開発におけるAI活用は前提となった 90%が仕事でAIを活用している 主な利用用途は、新規コーディング、既存コード修正、
 レビュー、ドキュメント生成、テストケース生成など AIエージェントの進化が実務レベルに近づき、
 開発の「作業支援」から「伴走」「委託」へ 17 “State of AI-assisted Software Development 2025” by Google
18. AIとソフトウェア開発の現在（2026年1月） AI活用による効果は、個人レベルでは高い 一方で組織レベルではそれほど高くない ソフトウェアデリバリーのスループットは2024年 はマイナスだったが微増に転じた ソフトウェアデリバリーの不安定性は昨年より増加 個人やチームレベルでのAI活用は進んでい るが、組織の仕組みが追いついていない 18 “State of AI-assisted Software Development 2025” by Google 組織がボトルネックになっていてAIの性能を活かしきれていない
19. AIが与える影響：開発サイクル これまでの開発サイクルは開発に時間がかかる前提だった 事前の同期コミュニケーション→開発（長い）→事後の同期コミュニケーション AIによって開発にかかる時間が短縮されたときにどのように仕事を
 フローさせるのか 同一時間に対応する仕事量が増えることで、同期コミュニケーションが追いつかなくなる プロダクトバックログの枯渇、レビュー蓄積、属人化… 開発サイクルが短くなっていく傾向 1週間スプリントから1日スプリントへ スプリントという枠は不要になりカンバンへ 19
20. 人間のみのチームではクロスファンクショナルチームが理想とされてきた メンバー同士の経験知やスキル重ね合わせてチームで補完する チームで仕事を完結するために3ʙ7人でチームを組むことが多い AIは多様な知識とスキルを持ち、カバー範囲が人間よりも圧倒的に広い 学習していくスピードも人間よりも圧倒的にはやい もちろん人間にしかできない領域も存在する チームは小規模化する傾向 2ʙ人の人間＋AIのチーム 結果として人間に求められる仕事の責任範囲は拡がる AIが与える影響：チーム 20
21. AIが与える影響：ロール 人間に求められるものが変化している カバー領域を拡げて意思決定できる範囲を拡げる 経験やスキルを深化させて現状のAIでは対応が難しいところが対応できる AIが生成した結果をレビューして品質を担保できる これまで担当しなかった仕事領域やスキルを習得する必要性が上がっている AIの支援を受けることで習得しやすくなっている 考える人とつくる人の距離を縮めやすくなった Vibe CodingやAgentic Coding アジャイル開発が目指してきたことだがAIのインパクトの方が大きかった 21
22. 最近よく聞くチームが抱える問題 最近よく聞くようになったチームが抱える問題 レビュー 技術的負債 属人化 メンバーの育成 ドキュメント（形式知化） これらはもともと抱えていた問題で、AIによって問題が健在化しやすくなった “AIは増幅器として機能する。高いパフォーマンスの組織の強みを拡大し、課題を抱えている 組織の機能不全も拡大する。”（State of AI-assisted SoftwareDevelopment 2025） 22
23. 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 23
24. 変化は止まらない 既に大きな変化をもたらしているが、AIの進化はまだ過程の段階 Stage3（アイデア創出）やStage4（組織）への進化 Physical AI 今は人間がやるべきだと思っていることも数カ月後には変わっているかも ex. AIの生成したものは信頼できないから人間が品質を担保しなければならない ex. Vibe Codingではデモレベルならいいけどプロダクトコードは実装できない ex. 人間が意思決定をしてAIに作業をさせるべき 好むか好まざるかに関わらず、変化のベクトル自体は誰も止められない 24
25. アジェンダ AIとソフトウェア開発 スクラムというコンフォートゾーン AI時代のアジャイルチーム 
27. よくある現実スクラム（私見） チームの人数は4ʙ7人 スプリントの期間は1週間 or 週間 プロダクトオーナー、スクラムマスター、開発者 （プロダクトオーナーはいるけどスクラムイベントくらいでしか話してない） （会社の肩書きは変わらないからエンジニアの誰かがスクラムマスターを兼任している） （デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち） タスクはカンバンで管理し、各メンバーにアサインして仕事を進める （スウォーミングのことは知ってるけど生産性悪そうだし現実的ではない） スクラムイベントをスケジュールして進めている （スプリントレトロスペクティブはコミュニケーションを重視している） （スプリントゴールは設定してみてるけどバックログの集合体みたいになってしまってる） 
28. この3年間で、 あなたのチームや開発プロセスは
 どのくらい変わりましたか？
29. よくある現実スクラムの近況（私見） 開発者がAIツールを使って仕事をすることはふつうになってきた 一方で、チームや開発プロセスは以前とほとんど変わっていない AIツールを使うことで作業は効率的になった気はするけど、
 それが最終的な仕事の成果につながっている気はしない 
30. スクラムのコンフォートゾーン化 スクラムやスクラムのような仕事の進め方がスタンダードになった スクラムがコンフォートゾーン化してしまっていることも スクラムが機能していると、スクラムをやっておけばよいの違い 「透明性」「検査」「適応」が機能不全を起こしている コンフォートゾーン＝悪いではない チームでラーニングゾーンに身を置き続け、
 プロダクトとチームを育てていくフレームワークが
 スクラムである（と個人的に思っている） 30
31. スクラムがコンフォートゾーン化しているときの兆候 1. スプリントレトロスペクティブの主目的がコミュニケーションになっている “スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである”
 （スクラムガイド2020） コミュニケーションは重要だが、スプリントレトロスペクティブだけで充足させるものではない 2. スプリントゴールが形骸化している スプリントゴールが機能しないことで、スクラムのサイクルが
 循環しなくなる スクラムイベントは形としてこなせているようでも、
 チームやプロダクトの全体性が蓄積されていかない 31
32. スクラムガイド拡張パック https://scrumexpansion.org/ja/scrum-guide-expansion-pack/2025.6/
34. スクラムガイド拡張パック 2025年6月11日に公開（日本語訳も公開されている） スクラムガイド共同著者ジェフ・サザーランド氏が著者の一人 公式ガイドではなく非公式のパタンライブラリ スクラムガイドを補完する目的で、特に生成AIによってもたらされる変化への 適応を考慮されて書かれている 役割の再定義と拡張、コミットメントの再定義、理論の強化 GitHub上で公開され、誰でもフィードバックすることができ、四半期ごとに 更新される予定 
35. 今取り組んでいるスクラムのままでよいのか この3年間でチームや開発プロセスがあまり変わっていないとしたら、
 そこがボトルネックになっているかもしれない AIによってソフトウェア開発にもたらされる変化に適応して、
 チームや開発プロセスも適応していかなければならない スクラムガイドや拡張パックも更新されていくが、それ以上のスピードで
 自分たちのチームや開発プロセスを更新していく必要がある 35
36. 現実スクラムは変化の過程かそれとも妥協の産物か チームの人数は4ʙ7人 スプリントの期間は1週間 or 週間 プロダクトオーナー、スクラムマスター、開発者 （プロダクトオーナーはいるけどスクラムイベントくらいでしか話してない） （会社の肩書きは変わらないからエンジニアの誰かがスクラムマスターを兼任している） （デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち） タスクはカンバンで管理し、各メンバーにアサインして仕事を進める （スウォーミングのことは知ってるけど生産性悪そうだし現実的ではない） スクラムイベントをスケジュールして進めている （スプリントレトロスペクティブはコミュニケーションを重視している） （スプリントゴールは設定してみてるけどバックログの集合体みたいになってしまってる） 
37. 明確に区別する スナップショットで見たら同じように見えても明確に違う 組織や環境の制約を理解してできることを模索している、そして仕事の成果を出しながら 周囲の信頼を獲得し制約自体の除去にも取り組んでいこうとしている過程の状態 「できることをやっている」という自己正当化を行い、制約に飲まれて妥協したやり方で ただスクラムっぽいなにかをこなしている状態 この2つは明確に区別しなければならない 37
38. アジェンダ AIとソフトウェア開発 スクラムというコンフォートゾーン AI時代のアジャイルチーム 
39. AIを使う私たちはどうあるべきか AI時代以前はアジャイル開発（スクラム）をベースに、
 どうやって適応・改善させていくのかに取り組んでいけばよかった 今考えると、相対的に変化は緩やかで小さかったからそれでよかった AIによってソフトウェア開発自体が大きく変化していく中で、
 既存のチームや開発プロセスを変えずにAI活用に取り組んだところで、
 人間がボトルネックになってAIの性能を引き出すことはできない AIの性能を引き出すために人間である私たちがどうあるべきかを考える Unlearn（学びほぐし）をする 理想とするチームを定義し、チームや開発プロセスを新たに構築する 
40. AI時代のアジャイルチームに必要なケイパビリティ 意思決定の範囲を拡げ、質を高める チームで扱う変数を増やす 学習する仕組みが備わっている 
41. AIとのやりとりは意思決定の繰り返し ・・・ どの問題を解くのか どんなプロンプトを入力するか どんなフィードバックをするか レスポンスを受け入れるか どこまで繰り返すか 結果を検証し問題ないと判断する レスポンスは適切か否か 欲しい情報は充足したか 受け入れたうえで次に何をするのか 結果を受け入れるか
42. 意思決定の範囲を拡げ、質を高める AI活用を前提にしたソフトウェア開発では、意思決定の範囲と質が
 仕事の成果に直結する 意思決定可能な範囲の仕事はAIに指示することができ、結果を評価することができる 意思決定は意思決定をすることでうまくなる 意図的に個人やチームが意思決定をする機会を増やす仕組みを実装する 
43. チームで扱う変数を増やす これまで暗黙的に定数にしてしまっていたものを変数にして考える チームの人数 ロール 開発プロセス 組織 あたりまえになっていたものを疑い、必要なものを変える 
44. 学習する仕組みが備わっている 複雑で変化が激しい状況において学習の重要度はかなり高い AIの活用方法 新しいチーム 新しいロール 新しい開発プロセス 個人学習に依存していては追いつかないので、チームの営みに学習する仕組み を明示的に組み入れる 
45. チームのコンテキスト チームメンバーは7人 執行役員兼マネージャー（私） プロジェクトマネージャー エンジニア×4人 仕事内容 プロダクト開発・保守（2割） クライアントワーク（8割） 
46. チーム マネージャー アシスタント 大きなチーム 小さなチーム 小さなチーム 小さなチーム 小さなチーム
47. フラクタル構造のチーム 小さなチーム 2ʙ3人の人間＋AI 業務執行の最小単位で、自己組織的なチーム チームは流動的で仕事や状況に合わせてメンバーを組み替える 参考：ダイナミックリチーミング 大きなチーム 複数の小さなチーム＋横断ロール（マネージャー、アシスタント etc..） 戦略執行の最小単位で、小さなチームの自律とチームの成長を支援するチーム 
48. 組織とチームの境目 チームと組織の境目を積極的に溶かす チーム：小規模で密度は高め 組織：中規模で密度は低め 既存の「組織」を「大きなチーム」と置き換え、変数にする 大きなチームという全体の中で、チームの自律や個人の成長を支援することも プロセスとして実装する 組織をチームのような密度で捉えて、フィードバックループをまわしていく 
49. ロールを動的にする ロールが固定であることが変化を阻害する 小さなチームの中で既存のロールをあてはめるのは無理がある 全員アーキテクト（仮称） 必要な仕事を必要なタイミングで必要な人が行う 専門性は重要だが、専門性に合わせてロールを固定することはしない AI活用によって、業務の実行やスキルの習得を進めやすくなっている 同じ名前だと既存の概念に引きずられるので捨てたい（ex. エンジニア、プロジェクトマネー ジャー、スクラムマスター、プロダクトオーナー） 
50. 小さなチームのオーナーを決める 全員がオーナーシップを持つことが望ましいが、最終決定者は決めておく ラストマンシップを醸成する ラストマンシップ：最後のひとりになったとしてもやりきる覚悟をもつ姿勢やマインドセット 
51. AI時代のアジャイルチームのマネージャー 既存の中央集権的なマネジメントスタイルではボトルネックになる 「管理」から「支援」へ マネージャーに求められる機能 大きなチームの方向づけと運用 小さなチームの自己組織化の支援 アジャイルコーチング チームの状況に合わせて積極的な権限移譲 個人へのコーチング 
52. 余談：マネージャーが変わらなければ変わらない アジャイル開発やスクラムを実践してきた経験の中でわかっていること 単純に手法を取り入れるだけでなく文化醸成や組織変容まで見越して取り組む必要がある ボトムアップでチェンジエージェントとして活躍する人もいるがそれはレアケース 経営者やマネージャーが変化の起点をつくり、協力してもらったほうが
 圧倒的に変化がはやい フォロワーシップをもっている人はそこそこいる 現場に変化を求める前に、経営者やマネージャーが率先して変わる 一番のボトルネックは私たち（経営者、マネージャー）だと自覚する 
53. 開発プロセス 小さなチーム 自分たちの開発プロセスを設計し実行する モブプログラミング 大きなチーム 全体性をつくり、小さなチームの実行と学習を支援する Daily Huddles Weekly OST 
54. 自分のハンドルは自分で握れ！ 小さなチームの開発プロセスはチームが設計する 自分たちの開発プロセスを言語化をする 設計した開発プロセスをレビューする 設計した開発プロセスをもとに実行し、フィード バックサイクルをまわしてうまくなっていく 
55. モブプログラミングの再評価 モブプログラミングとは、チーム全員で、同じ仕事を、同じ場所で、
 同じ時間に、同じコンピューターですること チームで常に同期と合意をしながら仕事をすることで、
 仕事のフロー効率を最大化させる仕事の進め方 生産性を気にして実施がしづらい話をよく聞くが、
 AI時代では取り組みやすくなった 属人化の予防・削減やチームの共通コンテキスト
 を貯めるときに有効なもので、AI時代のチームが
 抱える課題の解決策の1つになりやすい 55
56. Daily Huddles 毎日決まった時間に集まり、大きなチーム全体で
 朝礼を実行する 一人一言ずつ話、場にチェックインする 小さなチームが順番にデイリースクラムを行う チーム外のメンバーは観察をし、必要に応じて
 フィードバックをする 
57. Weekly OST 週に1時間Open Space Technologyを実行する Open Space Technology or Lean Coffee 同じ大きなチームに所属していて、
 さまざまな時間を共有してコンテキストが揃っている
 メンバーが集まって話したいことを話す 共有したいこと・議論したいこと・問題や不安・改善や提案 神回を再現させることを目指し、知的コンバットの
 練習をする 
58. チームは他のチームから学ぶ 数年に渡って新卒研修の企画・運営をしてきて、
 チームが他のチームから学ぶ効果を実感している 新卒研修では毎年約10チームが横並びで仕事をする レトロスペクティブツアー 横のチームから学ぶことがふつうになってくると、
 自発的に隣のチームの様子を覗きに行ったり、
 チーム同士で協力して問題解決をするシーンが自然発生する 中央集権的にチームを支援するだけでなく、
 チーム同士で学び合う環境をつくるという発想  https://www.youtube.com/watch?v=cWbFrkrDNHo https://www.youtube.com/watch?v=6AC0PSGXLnE
59. 他のチームから学ぶために必要なもの コンテキストが理解できないと他のチームに興味を持つことができない 大きなチームに所属していて同じ方向づけのもとで活動している Daily HuddlesやWeekly OSTをはじめとして、
 情報共有や一緒に作業や議論をする時間を積み重ねることで、
 他のチームのコンテキストを理解する 59
60. AI時代のアジャイルチームに必要なケイパビリティ 意思決定の範囲を拡げ、質を高める 意思決定に関わる機会を増やす⇒小さなチーム、権限移譲 意思決定の範囲を拡げる⇒動的なロール さまざまなフィードバックを受けてうまくなる⇒フラクタル構造のチーム、コーチング チームで扱う変数を増やす 開発プロセス、ロール、組織は定数ではなく変数として捉える 学習する仕組みが備わっている 小さなチーム同士で学び合う環境をつくる⇒複数の小さなチーム コンテキストを理解し興味をもつ⇒Daily Huddles、Weekly OST 属人化を予防・排除しながらチームに学習を蓄積していく⇒モブプログラミング 
61. できた時間を何に投資するのか AIによって作業が効率化されてできた時間を何に投資するのか 既存のチームや開発プロセスを変えずに、時間を次の作業に投資し続けても
 人間や組織がボトルネックになり仕事の成果にはつながらない AI時代のアジャイルチームを目指して、チームや開発プロセスを試行錯誤す ること、チームや個人のケイパビリティを高めることに時間を投資する AIの性能を引き出すことができるチームに近づいていくことで、仕事の成果 につながっていくという順番 61
62. 数カ月経って観察できた変化 小さなチームでふらっと集まる機会が増えた モブプログラミングや集まって会話をする 小さなチームはとても強力で「集まって話せばいいじゃん」が起こりやすい 中長期的な目線の会話が増えた 属人化をどうやって予防し、解消していくのか プロジェクトのロードマップをどうやって顧客と合意していくのか フィードバックをする・される機会が同時多発的に増加した 誰かから誰かへの一方通行のフィードバックではなく、いろんなところで発生している 62
63. 生物的チーム 生物的組織 “岡田さんの今日の体と明日の体は、新陳代謝によって、違う細胞でできているんですよ。
 でも、古い細胞が死んで、新しい細胞ができたときに、脳は何も命令していないのに、
 同じ形になるんです。細胞と細胞が折り合いをなして、同じ形になるのです。”
 （岡田メソッド） まだまだ変化の過程だが、少しだけ近づいている 
64. まとめ 「AI（道具）を使って何をするのか」と「AI（道具）を使う私たち（人間） はどうあるべきか」はどちらかではなくどちらも追い求める必要がある どうしても前者に偏重しがちなので気をつける 既存のチームや開発プロセスを変えずに、AI活用を進めても、
 人間や組織がボトルネックになっていく未来しか見えない AI時代のチームや開発プロセスを試行錯誤しながら、
 その中でAIをどう使うのかを追い求めていきたい 
65. XP・アジャイル開発・スクラム界隈の皆さん、 AI時代の変化を楽しんでいますか？
66. 私は楽しんでいるし、
 たぶんチームメンバーも楽しんでくれている
67. 変化を恐れない 多くの人にとって過去最大級の変化なのでAI疲れは仕方がない （自分はまだいまのところ人生において疲れたことがありません） どうやったら変化がストレスでなくなるかというと、自ら渦中に飛び込み、
 変化する状況を楽しむ側にい続けること AI時代のチームや開発プロセスについて考えて誰かと話してみる 実際にチームでできることからはじめてみる 
68. 変化を恐れない AI活用が進んでいくことで再びチームや開発プロセスが課題になりつつある AI活用が進んでいくことでこれまでも問題だったことが健在化しやすくなり、
 方法論のようなわかりやすいかたちではなく実力としてのアジャイル力が
 問われている アジャイル開発やスクラムに興味を持ち、変化に適応しようと研鑽を積んでい る私たちが活躍しなければならない状況にいる それぞれの現場の経験知やそこから再現性をもった形式知が「Nextアジャイ ル開発」になるかもしれない それはまた別のお話 
69. @TAKAKING22 及部 敬雄 https://agile-monster.com/ 一緒に取り組んでいきましょう！ 現役のアジャイル開発実践者による アジャイルコーチ お仕事のご相談も雑談もぜひお気軽にお声がけ下さい！