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

Slide 1

Slide 1 text

AI時代のアジャイルチームを目指してー “スクラム”というコンフォートゾーンからの脱却ー及部敬雄 (@TAKAKING22) 2026/01/08 Regional Scrum Gathering Tokyo 2026 イッテンハチ RSGT2026＠ベルサール羽田空港大会 1

Slide 2

Slide 2 text

世はまさに大AI時代

Slide 3

Slide 3 text

2022年11月、ChatGPTリリース Photo by BoliviaInteligente on Unsplash

Slide 4

Slide 4 text

ChatGPT誕生から約3年間 2023年：生成AI元年 Chat GPT誕生 GPT-4公開 2024年業務ツールに生成AI標準搭載が進行マルチモーダルAI 2025年：AIエージェント元年 Claude Code月額課金化 4

Slide 5

Slide 5 text

AI疲れ

Slide 6

Slide 6 text

AI疲れの正体現在、第四次産業革命真っ只中第一次産業革命（18ੈلʙ19世紀）：蒸気機関第二次産業革命（19世紀後半ʙ20世紀初頭）：電力、大量生産第三次産業革命（20世紀後半）：コンピュータ、自動化第四次産業革命（21世紀ʙ現在）：AI、IoT、ロボット産業革命とは、技術革新を背景に生産方式や社会構造が急速かつ大規模に変化する歴史的転換のことほとんどの人にとって今目の前で起きている変化は過去最大級変化を受け止めきれず、認知の許容量をオーバーフローしている状態 6

Slide 7

Slide 7 text

アジャイルソフトウェア開発宣言スクラムガイド2020 Extreme Programming

Slide 8

Slide 8 text

私たちは知っている変化に適応すること自体が主な目的のひとつ XP・スクラム・アジャイル開発の普及期、変化を受け入れない現状維持バイアスと戦って変化を起こそうとしてきた ex. 今仕事ができてるんだから変える必要ないのでは？ ex. そんなよくわからない新しいやり方は採用できない

Slide 9

Slide 9 text

XP・アジャイル開発・スクラム界隈の皆さん、 AI時代の変化を楽しんでいますか？

Slide 10

Slide 10 text

AI時代のアジャイルチームを目指してー “スクラム”というコンフォートゾーンからの脱却ー及部敬雄 (@TAKAKING22) 2026/01/08 Regional Scrum Gathering Tokyo 2026 イッテンハチ RSGT2026＠ベルサール羽田空港大会 10

Slide 11

Slide 11 text

11 TAKAKING22 及部敬雄制御不能なアジャイルモンスター株式会社ホロラボ執行役員 Silver Bullet Club所属 AGILE-MONSTER.COM アジャイルコーチ

Slide 12

Slide 12 text

セッション概要 AIの進化と普及が進み、ソフトウェア開発の中でAIを活用することは  もはやあたりまえとなりつつあります作業レベルでのAI活用が進む一方で、スクラムをはじめとするチームや開発プロセスはあまり変化できていません AI時代に必要なアジャイルチームとはなにかを考えていること、  実際の現場で実践していることをお話しますこのテーマに関心を持ってくださった方と、知見を交換したり、  ディスカッションをするきっかけになれば嬉しいです 12

Slide 13

Slide 13 text

We shapes our tools, and thereafter our tools shape us. 私たちは道具を形作り、その後、道具が私たちを形作る - マーシャル・マクルーハン -

Slide 14

Slide 14 text

道具と人道具によって人間の生活や活動が変わった例印刷技術：思想や情報が大量複製され、不特性多数に同時に届くメディアが生まれた蒸気機関：機械動力による大量生産が可能になり、工場制産業が成立したインターネット：情報と人が即時につながる地理的制約のほぼない社会を生んだ AI：？？？ AI（道具）を使って何をするのかよりも、AI（道具）を使う私たち（人間）はどうあるべきかを考えたい左記に価値があることを認めながらも右記により価値をおく 14

Slide 15

Slide 15 text

アジェンダ AIとソフトウェア開発スクラムというコンフォートゾーン AI時代のアジャイルチーム

Slide 16

Slide 16 text

ChatGPT誕生から約3年間 2023年：生成AI元年 Chat GPT誕生 GPT-4公開 2024年業務ツールに生成AI標準搭載が進行マルチモーダルAI 2025年：AIエージェント元年 Claude Code月額課金化 16

Slide 17

Slide 17 text

AIとソフトウェア開発の現在（2026年1月）ソフトウェア開発におけるAI活用は前提となった 90%が仕事でAIを活用している主な利用用途は、新規コーディング、既存コード修正、  レビュー、ドキュメント生成、テストケース生成など AIエージェントの進化が実務レベルに近づき、  開発の「作業支援」から「伴走」「委託」へ 17 “State of AI-assisted Software Development 2025” by Google

Slide 18

Slide 18 text

AIとソフトウェア開発の現在（2026年1月） AI活用による効果は、個人レベルでは高い一方で組織レベルではそれほど高くないソフトウェアデリバリーのスループットは2024年はマイナスだったが微増に転じたソフトウェアデリバリーの不安定性は昨年より増加個人やチームレベルでのAI活用は進んでいるが、組織の仕組みが追いついていない 18 “State of AI-assisted Software Development 2025” by Google 組織がボトルネックになっていてAIの性能を活かしきれていない

Slide 19

Slide 19 text

AIが与える影響：開発サイクルこれまでの開発サイクルは開発に時間がかかる前提だった事前の同期コミュニケーション→開発（長い）→事後の同期コミュニケーション AIによって開発にかかる時間が短縮されたときにどのように仕事を  フローさせるのか同一時間に対応する仕事量が増えることで、同期コミュニケーションが追いつかなくなるプロダクトバックログの枯渇、レビュー蓄積、属人化… 開発サイクルが短くなっていく傾向 1週間スプリントから1日スプリントへスプリントという枠は不要になりカンバンへ 19

Slide 20

Slide 20 text

人間のみのチームではクロスファンクショナルチームが理想とされてきたメンバー同士の経験知やスキル重ね合わせてチームで補完するチームで仕事を完結するために3ʙ7人でチームを組むことが多い AIは多様な知識とスキルを持ち、カバー範囲が人間よりも圧倒的に広い学習していくスピードも人間よりも圧倒的にはやいもちろん人間にしかできない領域も存在するチームは小規模化する傾向 2ʙ人の人間＋AIのチーム結果として人間に求められる仕事の責任範囲は拡がる AIが与える影響：チーム 20

Slide 21

Slide 21 text

AIが与える影響：ロール人間に求められるものが変化しているカバー領域を拡げて意思決定できる範囲を拡げる経験やスキルを深化させて現状のAIでは対応が難しいところが対応できる AIが生成した結果をレビューして品質を担保できるこれまで担当しなかった仕事領域やスキルを習得する必要性が上がっている AIの支援を受けることで習得しやすくなっている考える人とつくる人の距離を縮めやすくなった Vibe CodingやAgentic Coding アジャイル開発が目指してきたことだがAIのインパクトの方が大きかった 21

Slide 22

Slide 22 text

最近よく聞くチームが抱える問題最近よく聞くようになったチームが抱える問題レビュー技術的負債属人化メンバーの育成ドキュメント（形式知化）これらはもともと抱えていた問題で、AIによって問題が健在化しやすくなった “AIは増幅器として機能する。高いパフォーマンスの組織の強みを拡大し、課題を抱えている組織の機能不全も拡大する。”（State of AI-assisted SoftwareDevelopment 2025） 22

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

変化は止まらない既に大きな変化をもたらしているが、AIの進化はまだ過程の段階 Stage3（アイデア創出）やStage4（組織）への進化 Physical AI 今は人間がやるべきだと思っていることも数カ月後には変わっているかも ex. AIの生成したものは信頼できないから人間が品質を担保しなければならない ex. Vibe Codingではデモレベルならいいけどプロダクトコードは実装できない ex. 人間が意思決定をしてAIに作業をさせるべき好むか好まざるかに関わらず、変化のベクトル自体は誰も止められない 24

Slide 25

Slide 25 text

アジェンダ AIとソフトウェア開発スクラムというコンフォートゾーン AI時代のアジャイルチーム

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

よくある現実スクラム（私見）チームの人数は4ʙ7人スプリントの期間は1週間 or 週間プロダクトオーナー、スクラムマスター、開発者（プロダクトオーナーはいるけどスクラムイベントくらいでしか話してない）（会社の肩書きは変わらないからエンジニアの誰かがスクラムマスターを兼任している）（デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち）タスクはカンバンで管理し、各メンバーにアサインして仕事を進める（スウォーミングのことは知ってるけど生産性悪そうだし現実的ではない）スクラムイベントをスケジュールして進めている（スプリントレトロスペクティブはコミュニケーションを重視している）（スプリントゴールは設定してみてるけどバックログの集合体みたいになってしまってる）

Slide 28

Slide 28 text

この3年間で、あなたのチームや開発プロセスは  どのくらい変わりましたか？

Slide 29

Slide 29 text

よくある現実スクラムの近況（私見）開発者がAIツールを使って仕事をすることはふつうになってきた一方で、チームや開発プロセスは以前とほとんど変わっていない AIツールを使うことで作業は効率的になった気はするけど、  それが最終的な仕事の成果につながっている気はしない

Slide 30

Slide 30 text

スクラムのコンフォートゾーン化スクラムやスクラムのような仕事の進め方がスタンダードになったスクラムがコンフォートゾーン化してしまっていることもスクラムが機能していると、スクラムをやっておけばよいの違い「透明性」「検査」「適応」が機能不全を起こしているコンフォートゾーン＝悪いではないチームでラーニングゾーンに身を置き続け、  プロダクトとチームを育てていくフレームワークが  スクラムである（と個人的に思っている） 30

Slide 31

Slide 31 text

スクラムがコンフォートゾーン化しているときの兆候 1. スプリントレトロスペクティブの主目的がコミュニケーションになっている “スプリントレトロスペクティブの目的は、品質と効果を高める方法を計画することである”  （スクラムガイド2020）コミュニケーションは重要だが、スプリントレトロスペクティブだけで充足させるものではない 2. スプリントゴールが形骸化しているスプリントゴールが機能しないことで、スクラムのサイクルが  循環しなくなるスクラムイベントは形としてこなせているようでも、  チームやプロダクトの全体性が蓄積されていかない 31

Slide 32

Slide 32 text

スクラムガイド拡張パック https://scrumexpansion.org/ja/scrum-guide-expansion-pack/2025.6/

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

スクラムガイド拡張パック 2025年6月11日に公開（日本語訳も公開されている）スクラムガイド共同著者ジェフ・サザーランド氏が著者の一人公式ガイドではなく非公式のパタンライブラリスクラムガイドを補完する目的で、特に生成AIによってもたらされる変化への適応を考慮されて書かれている役割の再定義と拡張、コミットメントの再定義、理論の強化 GitHub上で公開され、誰でもフィードバックすることができ、四半期ごとに更新される予定

Slide 35

Slide 35 text

今取り組んでいるスクラムのままでよいのかこの3年間でチームや開発プロセスがあまり変わっていないとしたら、  そこがボトルネックになっているかもしれない AIによってソフトウェア開発にもたらされる変化に適応して、  チームや開発プロセスも適応していかなければならないスクラムガイドや拡張パックも更新されていくが、それ以上のスピードで  自分たちのチームや開発プロセスを更新していく必要がある 35

Slide 36

Slide 36 text

現実スクラムは変化の過程かそれとも妥協の産物かチームの人数は4ʙ7人スプリントの期間は1週間 or 週間プロダクトオーナー、スクラムマスター、開発者（プロダクトオーナーはいるけどスクラムイベントくらいでしか話してない）（会社の肩書きは変わらないからエンジニアの誰かがスクラムマスターを兼任している）（デザイナーやテストエンジニアもチームに入ってほしいけどチーム横断になりがち）タスクはカンバンで管理し、各メンバーにアサインして仕事を進める（スウォーミングのことは知ってるけど生産性悪そうだし現実的ではない）スクラムイベントをスケジュールして進めている（スプリントレトロスペクティブはコミュニケーションを重視している）（スプリントゴールは設定してみてるけどバックログの集合体みたいになってしまってる）

Slide 37

Slide 37 text

明確に区別するスナップショットで見たら同じように見えても明確に違う組織や環境の制約を理解してできることを模索している、そして仕事の成果を出しながら周囲の信頼を獲得し制約自体の除去にも取り組んでいこうとしている過程の状態「できることをやっている」という自己正当化を行い、制約に飲まれて妥協したやり方でただスクラムっぽいなにかをこなしている状態この2つは明確に区別しなければならない 37

Slide 38

Slide 38 text

アジェンダ AIとソフトウェア開発スクラムというコンフォートゾーン AI時代のアジャイルチーム

Slide 39

Slide 39 text

AIを使う私たちはどうあるべきか AI時代以前はアジャイル開発（スクラム）をベースに、  どうやって適応・改善させていくのかに取り組んでいけばよかった今考えると、相対的に変化は緩やかで小さかったからそれでよかった AIによってソフトウェア開発自体が大きく変化していく中で、  既存のチームや開発プロセスを変えずにAI活用に取り組んだところで、  人間がボトルネックになってAIの性能を引き出すことはできない AIの性能を引き出すために人間である私たちがどうあるべきかを考える Unlearn（学びほぐし）をする理想とするチームを定義し、チームや開発プロセスを新たに構築する

Slide 40

Slide 40 text

AI時代のアジャイルチームに必要なケイパビリティ意思決定の範囲を拡げ、質を高めるチームで扱う変数を増やす学習する仕組みが備わっている

Slide 41

Slide 41 text

AIとのやりとりは意思決定の繰り返し・・・どの問題を解くのかどんなプロンプトを入力するかどんなフィードバックをするかレスポンスを受け入れるかどこまで繰り返すか結果を検証し問題ないと判断するレスポンスは適切か否か欲しい情報は充足したか受け入れたうえで次に何をするのか結果を受け入れるか

Slide 42

Slide 42 text

意思決定の範囲を拡げ、質を高める AI活用を前提にしたソフトウェア開発では、意思決定の範囲と質が  仕事の成果に直結する意思決定可能な範囲の仕事はAIに指示することができ、結果を評価することができる意思決定は意思決定をすることでうまくなる意図的に個人やチームが意思決定をする機会を増やす仕組みを実装する

Slide 43

Slide 43 text

チームで扱う変数を増やすこれまで暗黙的に定数にしてしまっていたものを変数にして考えるチームの人数ロール開発プロセス組織あたりまえになっていたものを疑い、必要なものを変える

Slide 44

Slide 44 text

学習する仕組みが備わっている複雑で変化が激しい状況において学習の重要度はかなり高い AIの活用方法新しいチーム新しいロール新しい開発プロセス個人学習に依存していては追いつかないので、チームの営みに学習する仕組みを明示的に組み入れる

Slide 45

Slide 45 text

チームのコンテキストチームメンバーは7人執行役員兼マネージャー（私）プロジェクトマネージャーエンジニア×4人仕事内容プロダクト開発・保守（2割）クライアントワーク（8割）

Slide 46

Slide 46 text

チームマネージャーアシスタント大きなチーム小さなチーム小さなチーム小さなチーム小さなチーム

Slide 47

Slide 47 text

フラクタル構造のチーム小さなチーム 2ʙ3人の人間＋AI 業務執行の最小単位で、自己組織的なチームチームは流動的で仕事や状況に合わせてメンバーを組み替える参考：ダイナミックリチーミング大きなチーム複数の小さなチーム＋横断ロール（マネージャー、アシスタント etc..）戦略執行の最小単位で、小さなチームの自律とチームの成長を支援するチーム

Slide 48

Slide 48 text

組織とチームの境目チームと組織の境目を積極的に溶かすチーム：小規模で密度は高め組織：中規模で密度は低め既存の「組織」を「大きなチーム」と置き換え、変数にする大きなチームという全体の中で、チームの自律や個人の成長を支援することもプロセスとして実装する組織をチームのような密度で捉えて、フィードバックループをまわしていく

Slide 49

Slide 49 text

ロールを動的にするロールが固定であることが変化を阻害する小さなチームの中で既存のロールをあてはめるのは無理がある全員アーキテクト（仮称）必要な仕事を必要なタイミングで必要な人が行う専門性は重要だが、専門性に合わせてロールを固定することはしない AI活用によって、業務の実行やスキルの習得を進めやすくなっている同じ名前だと既存の概念に引きずられるので捨てたい（ex. エンジニア、プロジェクトマネージャー、スクラムマスター、プロダクトオーナー）

Slide 50

Slide 50 text

小さなチームのオーナーを決める全員がオーナーシップを持つことが望ましいが、最終決定者は決めておくラストマンシップを醸成するラストマンシップ：最後のひとりになったとしてもやりきる覚悟をもつ姿勢やマインドセット

Slide 51

Slide 51 text

AI時代のアジャイルチームのマネージャー既存の中央集権的なマネジメントスタイルではボトルネックになる「管理」から「支援」へマネージャーに求められる機能大きなチームの方向づけと運用小さなチームの自己組織化の支援アジャイルコーチングチームの状況に合わせて積極的な権限移譲個人へのコーチング

Slide 52

Slide 52 text

余談：マネージャーが変わらなければ変わらないアジャイル開発やスクラムを実践してきた経験の中でわかっていること単純に手法を取り入れるだけでなく文化醸成や組織変容まで見越して取り組む必要があるボトムアップでチェンジエージェントとして活躍する人もいるがそれはレアケース経営者やマネージャーが変化の起点をつくり、協力してもらったほうが  圧倒的に変化がはやいフォロワーシップをもっている人はそこそこいる現場に変化を求める前に、経営者やマネージャーが率先して変わる一番のボトルネックは私たち（経営者、マネージャー）だと自覚する

Slide 53

Slide 53 text

開発プロセス小さなチーム自分たちの開発プロセスを設計し実行するモブプログラミング大きなチーム全体性をつくり、小さなチームの実行と学習を支援する Daily Huddles Weekly OST

Slide 54

Slide 54 text

自分のハンドルは自分で握れ！小さなチームの開発プロセスはチームが設計する自分たちの開発プロセスを言語化をする設計した開発プロセスをレビューする設計した開発プロセスをもとに実行し、フィードバックサイクルをまわしてうまくなっていく

Slide 55

Slide 55 text

モブプログラミングの再評価モブプログラミングとは、チーム全員で、同じ仕事を、同じ場所で、  同じ時間に、同じコンピューターですることチームで常に同期と合意をしながら仕事をすることで、  仕事のフロー効率を最大化させる仕事の進め方生産性を気にして実施がしづらい話をよく聞くが、  AI時代では取り組みやすくなった属人化の予防・削減やチームの共通コンテキスト  を貯めるときに有効なもので、AI時代のチームが  抱える課題の解決策の1つになりやすい 55

Slide 56

Slide 56 text

Daily Huddles 毎日決まった時間に集まり、大きなチーム全体で  朝礼を実行する一人一言ずつ話、場にチェックインする小さなチームが順番にデイリースクラムを行うチーム外のメンバーは観察をし、必要に応じて  フィードバックをする

Slide 57

Slide 57 text

Weekly OST 週に1時間Open Space Technologyを実行する Open Space Technology or Lean Coffee 同じ大きなチームに所属していて、  さまざまな時間を共有してコンテキストが揃っている  メンバーが集まって話したいことを話す共有したいこと・議論したいこと・問題や不安・改善や提案神回を再現させることを目指し、知的コンバットの  練習をする

Slide 58

Slide 58 text

チームは他のチームから学ぶ数年に渡って新卒研修の企画・運営をしてきて、  チームが他のチームから学ぶ効果を実感している新卒研修では毎年約10チームが横並びで仕事をするレトロスペクティブツアー横のチームから学ぶことがふつうになってくると、  自発的に隣のチームの様子を覗きに行ったり、  チーム同士で協力して問題解決をするシーンが自然発生する中央集権的にチームを支援するだけでなく、  チーム同士で学び合う環境をつくるという発想 https://www.youtube.com/watch?v=cWbFrkrDNHo https://www.youtube.com/watch?v=6AC0PSGXLnE

Slide 59

Slide 59 text

他のチームから学ぶために必要なものコンテキストが理解できないと他のチームに興味を持つことができない大きなチームに所属していて同じ方向づけのもとで活動している Daily HuddlesやWeekly OSTをはじめとして、  情報共有や一緒に作業や議論をする時間を積み重ねることで、  他のチームのコンテキストを理解する 59

Slide 60

Slide 60 text

AI時代のアジャイルチームに必要なケイパビリティ意思決定の範囲を拡げ、質を高める意思決定に関わる機会を増やす⇒小さなチーム、権限移譲意思決定の範囲を拡げる⇒動的なロールさまざまなフィードバックを受けてうまくなる⇒フラクタル構造のチーム、コーチングチームで扱う変数を増やす開発プロセス、ロール、組織は定数ではなく変数として捉える学習する仕組みが備わっている小さなチーム同士で学び合う環境をつくる⇒複数の小さなチームコンテキストを理解し興味をもつ⇒Daily Huddles、Weekly OST 属人化を予防・排除しながらチームに学習を蓄積していく⇒モブプログラミング

Slide 61

Slide 61 text

できた時間を何に投資するのか AIによって作業が効率化されてできた時間を何に投資するのか既存のチームや開発プロセスを変えずに、時間を次の作業に投資し続けても  人間や組織がボトルネックになり仕事の成果にはつながらない AI時代のアジャイルチームを目指して、チームや開発プロセスを試行錯誤すること、チームや個人のケイパビリティを高めることに時間を投資する AIの性能を引き出すことができるチームに近づいていくことで、仕事の成果につながっていくという順番 61

Slide 62

Slide 62 text

数カ月経って観察できた変化小さなチームでふらっと集まる機会が増えたモブプログラミングや集まって会話をする小さなチームはとても強力で「集まって話せばいいじゃん」が起こりやすい中長期的な目線の会話が増えた属人化をどうやって予防し、解消していくのかプロジェクトのロードマップをどうやって顧客と合意していくのかフィードバックをする・される機会が同時多発的に増加した誰かから誰かへの一方通行のフィードバックではなく、いろんなところで発生している 62

Slide 63

Slide 63 text

生物的チーム生物的組織 “岡田さんの今日の体と明日の体は、新陳代謝によって、違う細胞でできているんですよ。  でも、古い細胞が死んで、新しい細胞ができたときに、脳は何も命令していないのに、  同じ形になるんです。細胞と細胞が折り合いをなして、同じ形になるのです。”  （岡田メソッド）まだまだ変化の過程だが、少しだけ近づいている

Slide 64

Slide 64 text

まとめ「AI（道具）を使って何をするのか」と「AI（道具）を使う私たち（人間）はどうあるべきか」はどちらかではなくどちらも追い求める必要があるどうしても前者に偏重しがちなので気をつける既存のチームや開発プロセスを変えずに、AI活用を進めても、  人間や組織がボトルネックになっていく未来しか見えない AI時代のチームや開発プロセスを試行錯誤しながら、  その中でAIをどう使うのかを追い求めていきたい

Slide 65

Slide 65 text

XP・アジャイル開発・スクラム界隈の皆さん、 AI時代の変化を楽しんでいますか？

Slide 66

Slide 66 text

私は楽しんでいるし、  たぶんチームメンバーも楽しんでくれている

Slide 67

Slide 67 text

変化を恐れない多くの人にとって過去最大級の変化なのでAI疲れは仕方がない（自分はまだいまのところ人生において疲れたことがありません）どうやったら変化がストレスでなくなるかというと、自ら渦中に飛び込み、  変化する状況を楽しむ側にい続けること AI時代のチームや開発プロセスについて考えて誰かと話してみる実際にチームでできることからはじめてみる

Slide 68

Slide 68 text

変化を恐れない AI活用が進んでいくことで再びチームや開発プロセスが課題になりつつある AI活用が進んでいくことでこれまでも問題だったことが健在化しやすくなり、  方法論のようなわかりやすいかたちではなく実力としてのアジャイル力が  問われているアジャイル開発やスクラムに興味を持ち、変化に適応しようと研鑽を積んでいる私たちが活躍しなければならない状況にいるそれぞれの現場の経験知やそこから再現性をもった形式知が「Nextアジャイル開発」になるかもしれないそれはまた別のお話

Slide 69

Slide 69 text

@TAKAKING22 及部敬雄 https://agile-monster.com/ 一緒に取り組んでいきましょう！現役のアジャイル開発実践者によるアジャイルコーチお仕事のご相談も雑談もぜひお気軽にお声がけ下さい！