Slide 1

Slide 1 text

2 02 6.0 7 .31 | AI駆動開発Conference Summer AI時代の強いチームの作り方 S PEA KER Yuki Yoshida KDDIアジャイル開発センター株式会社

Slide 2

Slide 2 text

Yuki Yoshida(吉田 祐樹) Principal Engineer @KDDIアジャイル開発センター(KAG) 好きな技術領域 • • • • スクラム / XP / Kanban / Crystal Git / Vim / AWS Claude Code / Codex AI-DLC(Not Workflows) 特徴 • 15年以上アジャイル開発の現場に生息 • スクラムやXPを愛している • KAG全体のAI駆動開発推進リード • よく言う言葉「やってから考えようぜ!」 • AIのお陰で「やらなくても分かる」が増えてきた • 「全てのモデルは間違っている」前提で考えている KDDI Agile Development Center Corporation 1

Slide 3

Slide 3 text

突然ですが 最近、みんなの心すり減ってません? KDDI Agile Development Center Corporation 2

Slide 4

Slide 4 text

奴(AI)はとんでもないものを盗んでいきました。あなたの心です。 KDDI Agile Development Center Corporation 3

Slide 5

Slide 5 text

AI利用の最前線であるKAGもみんないっぱいいっぱい KDDI Agile Development Center Corporation 4

Slide 6

Slide 6 text

AI利用拡大に伴い・・・ KDDI Agile Development Center Corporation 5

Slide 7

Slide 7 text

多くの開発会社がAI利用費に投資し、人件費を減らせるか検討している KDDI Agile Development Center Corporation 6

Slide 8

Slide 8 text

追い打ちをかけるように KDDI Agile Development Center Corporation 7

Slide 9

Slide 9 text

Anthropic主催のハッカソンで非エンジニアが優勝 KDDI Agile Development Center Corporation 8

Slide 10

Slide 10 text

もうソフトウェアエンジニアは不要なの? KDDI Agile Development Center Corporation 9

Slide 11

Slide 11 text

一方SNSでは KDDI Agile Development Center Corporation 10

Slide 12

Slide 12 text

2026年3-5月はこんな書き込みが目立ちました KDDI Agile Development Center Corporation 11

Slide 13

Slide 13 text

チームも不要なの? KDDI Agile Development Center Corporation 12

Slide 14

Slide 14 text

否 KDDI Agile Development Center Corporation 13

Slide 15

Slide 15 text

AIで速く作れる = “安心安全” だといつから錯覚していた? KDDI Agile Development Center Corporation 14

Slide 16

Slide 16 text

“開発会社”だからこそ出来ることがある KDDI Agile Development Center Corporation 15

Slide 17

Slide 17 text

“開発会社”だからこそ出来ることがある ❝ AIは契約主体にはなれません。 約束をして責任を取る、という主体にはなれないのです。 一方で、組織はそれができます。 ❞ (中略) では、組織にしかできないことは何か。それは「永続性」だと私は思います。人の命、人格は長くても百年です。 しかし、法人格は終わりを想定していない、つまり永続を前提としています。 — 南場智子(DeNA 代表取締役会長) 出典:「DeNAが挑む『AIネイティブカンパニー』への全社的取り組み」フルスイング by DeNA(2025) 開発会社を使うメリットは圧倒的にコレ KDDI Agile Development Center Corporation 16

Slide 18

Slide 18 text

開発会社が作るメリットは分かった でも・・・ KDDI Agile Development Center Corporation 17

Slide 19

Slide 19 text

”AIの力でチームを縮小出来る” これは事実だよね? KDDI Agile Development Center Corporation 18

Slide 20

Slide 20 text

そうとも限らない KDDI Agile Development Center Corporation 19

Slide 21

Slide 21 text

例えば、AIを最大限上手く活用出来た時、 人の数を1/3にすることが出来ると仮定します ※1/2でも1/100でも自社に合わせた数字に脳内変換してください KDDI Agile Development Center Corporation 20

Slide 22

Slide 22 text

現実的にあり得るかは置いておいて偉い人達が考えているのはきっとこういうこと KDDI Agile Development Center Corporation 21

Slide 23

Slide 23 text

現実的にあり得るかは置いておいて偉い人達が考えているのはきっとこういうこと KDDI Agile Development Center Corporation 22

Slide 24

Slide 24 text

本当に出来ますか? KDDI Agile Development Center Corporation 23

Slide 25

Slide 25 text

(理論的には) この6名がめっちゃ有能なら 短期的には恐らく出来ます KDDI Agile Development Center Corporation 24

Slide 26

Slide 26 text

そのチーム、サステナブル(持続可能)ですか? KDDI Agile Development Center Corporation 25

Slide 27

Slide 27 text

なら、どうする? KDDI Agile Development Center Corporation 26

Slide 28

Slide 28 text

人を増やしたら成果もスケールする仕組みを考える KDDI Agile Development Center Corporation 27

Slide 29

Slide 29 text

人を増やしたら成果もスケールする仕組みを考える KDDI Agile Development Center Corporation 28

Slide 30

Slide 30 text

“言うは易し” ではない KAGは複数チームで実現しています KDDI Agile Development Center Corporation 29

Slide 31

Slide 31 text

ということで、やっと今日の本題へ KDDI Agile Development Center Corporation 30

Slide 32

Slide 32 text

AI時代を生き抜く強いチームの作り方を復習するぞ! KDDI Agile Development Center Corporation 31

Slide 33

Slide 33 text

AI時代に強いチームは必要なのか? KDDI Agile Development Center Corporation 32

Slide 34

Slide 34 text

AI時代、弱いチームは速く壊れ、強いチームは速く学ぶ ※DORA Research: 2025 https://dora.dev/research/2025/ KDDI Agile Development Center Corporation 33

Slide 35

Slide 35 text

”強いチーム” とは? KDDI Agile Development Center Corporation 34

Slide 36

Slide 36 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 35

Slide 37

Slide 37 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 36

Slide 38

Slide 38 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 37

Slide 39

Slide 39 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 38

Slide 40

Slide 40 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 39

Slide 41

Slide 41 text

AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 40

Slide 42

Slide 42 text

逆にたぶんこれが最悪のやり方(学びにならない) KDDI Agile Development Center Corporation 41

Slide 43

Slide 43 text

強いチームを目指すための前提条件 KDDI Agile Development Center Corporation 42

Slide 44

Slide 44 text

チームの外にいる管理職の考えを変える必要がある(マグレガーのX理論・Y理論) KDDI Agile Development Center Corporation 43

Slide 45

Slide 45 text

チームの外にいる管理職の考えを変える必要がある(マグレガーのX理論・Y理論) KDDI Agile Development Center Corporation 44

Slide 46

Slide 46 text

では、ここからうちのチームの働き方 KDDI Agile Development Center Corporation 45

Slide 47

Slide 47 text

1年ほどスクラムベースのAI-DLCを継続中 KDDI Agile Development Center Corporation 46

Slide 48

Slide 48 text

AI-DLCとは? 方法論の原典 White Paper と、現行実装 Workflows v2 の2系統ある MET HO D DEF IN IT ION P A P ER (2 02 5 年7 月) AI D LC-WORKF LOWS v2 + 2 .0 SPE CI F I CATI ON White Paper Workflows 2.0 方法論の原典 — 思想と語彙を定義 現行の実装 — 方法論の定義と実行が一体化 • 3フェーズ: Inception / Construction / Operations • 5フェーズ・32ステージ(Initialization / Ideation を追加) • Bolt・Mob Elaboration など固有の用語と儀式を定義 • 14エージェント体制 + 9段階の adaptive scope • 「なぜ既存 SDLC に AI を後付けせず再設計するのか」という前提 と原則 • 全ステージに承認ゲート、修正をルール化する学習ループ • 導入提案・概念理解のための読み物 • 方法論を再設計する根拠としてWhite paperの10原則 • Claude Code / Kiro / Codex CLI 等へ単一ソースから配布 • ユーザーの修正から学んだ内容を記録し、同じ誤りを繰り返さない 仕組みを持つ • 自律実行アーキテクチャの設計思想としてSpecification の9原則 • エージェントに配布される実行時のルールCore Principles の7原則 White PaperとWorkflow v2それぞれの原則とフェーズ、考え方を参考にアレンジして実践 Source: aws.amazon.com/blogs/devops/ai-driven-development-life-cycle / github.com/awslabs/aidlc-workflows (v2) KDDI Agile Development Center Corporation 47

Slide 49

Slide 49 text

AI-DLCの原則 White Paperの10原則はマインド面での説明が多く ”AIをどう使うか”についての記述は少なめ 詳細については過去の登壇を参照ください https://speakerdeck.com/yuukiyo /ai-dlc-deep-dive KDDI Agile Development Center Corporation 48

Slide 50

Slide 50 text

AI-DLCの原則 + White Paperはマインド面を指していて、Workflowは実践面を指しているため 【原則が生まれ変わった】ではなく【合わせて考えるべき】という理解(私見) KDDI Agile Development Center Corporation 49

Slide 51

Slide 51 text

AI-DLC原則も一気にやらず少しずつ実践していくのが良い あ、この手があったか! という発見は意外と身近にある 例えば・・・先日KAG内のAI駆動開発勉強会で KDDI Agile Development Center Corporation 50

Slide 52

Slide 52 text

AI-DLCのフェーズ(簡易版) White Paperの3フェーズで実施。難しく考えず、こう読み替えればOK Inception フェーズ ≒ Construction フェーズ 設計 ≒ 要求を理解し、 「何を・どう作るか」を決める 実装 設計をもとに、 動くソフトウェアを作り上げる 正確にはOperationフェーズもあるが、まずは「設計 → 実装 → 運用」と捉えればOK ※aidlc-workflows v2ではInitializationとIdeationフェーズもありますが上記はv1 KDDI Agile Development Center Corporation 51

Slide 53

Slide 53 text

スクラムベースのAI-DLC KDDI Agile Development Center Corporation 52

Slide 54

Slide 54 text

スクラムベースのAI-DLC KDDI Agile Development Center Corporation 53

Slide 55

Slide 55 text

スクラムベースのAI-DLC KDDI Agile Development Center Corporation 54

Slide 56

Slide 56 text

スクラムベースのAI-DLC KDDI Agile Development Center Corporation 55

Slide 57

Slide 57 text

スクラムベースのAI-DLC ちょっとだけここを深堀り!! KDDI Agile Development Center Corporation 56

Slide 58

Slide 58 text

KDDI Agile Development Center Corporation 57

Slide 59

Slide 59 text

KDDI Agile Development Center Corporation 58

Slide 60

Slide 60 text

レビューで鋭い指摘がバンバン飛んでくるため 事前のAIとの対話でめちゃくちゃ真剣に調査する KDDI Agile Development Center Corporation = ジュニアエンジニアが めちゃくちゃ成長する環境 59

Slide 61

Slide 61 text

KDDI Agile Development Center Corporation 60

Slide 62

Slide 62 text

Constructionフェーズ KDDI Agile Development Center Corporation 61

Slide 63

Slide 63 text

Constructionフェーズ KDDI Agile Development Center Corporation 62

Slide 64

Slide 64 text

Constructionフェーズ KDDI Agile Development Center Corporation 63

Slide 65

Slide 65 text

Constructionフェーズ KDDI Agile Development Center Corporation 64

Slide 66

Slide 66 text

フェーズまとめ かけてる時間としては「設計8 : 実装2」 Inceptionフェーズ(設計) Constructionフェーズ(実装) モブワーク モブワーク 全体情報共有 全体情報共有 以前までは「実装してみないとわからない」だったものがAI駆動になって設計フェーズで議論出来るように なった、且つAIのお陰で実装にかける工数を圧縮できたこともあり設計に重きを置けるようになった KDDI Agile Development Center Corporation 65

Slide 67

Slide 67 text

基本は常にモブプロ 設計 or 実装が終わるごとに全員で同期 KDDI Agile Development Center Corporation 66

Slide 68

Slide 68 text

ここまでは普通 (毎日6時間モブプロ出来るチームを普通と呼ぶかは置いておいて) KDDI Agile Development Center Corporation 67

Slide 69

Slide 69 text

スクラムベースのAI-DLC KDDI Agile Development Center Corporation 68

Slide 70

Slide 70 text

スクラムベースのAI-DLC うちのチームが凄いのは ここがスケーラブルであること KDDI Agile Development Center Corporation 69

Slide 71

Slide 71 text

なぜスケール出来るのか KDDI Agile Development Center Corporation 70

Slide 72

Slide 72 text

答えはフィーチャーチーム KDDI Agile Development Center Corporation 71

Slide 73

Slide 73 text

この一年で4度チームの働き方について登壇してます 共通して伝えていることはフィーチャーチームが必要であるということ KDDI Agile Development Center Corporation 72

Slide 74

Slide 74 text

フィーチャーチーム? KDDI Agile Development Center Corporation 73

Slide 75

Slide 75 text

フィーチャーチームならエンドツーエンドで価値を提供できる 必要なケイパビリティがチーム内で完結してる 他チームとの依存関係が少ない 品質にチーム全体で責任を持てる 顧客視点で開発しやすい 完成の定義が明確になる KDDI Agile Development Center Corporation 74

Slide 76

Slide 76 text

KAGで試行しているのはもっと小さい単位 KDDI Agile Development Center Corporation 75

Slide 77

Slide 77 text

フィーチャーモブ KDDI Agile Development Center Corporation 76

Slide 78

Slide 78 text

顧客価値をE2Eで完結する動的に編成された2〜3名体制のモブ KDDI Agile Development Center Corporation 77

Slide 79

Slide 79 text

フィーチャーモブの進め方 KDDI Agile Development Center Corporation 78

Slide 80

Slide 80 text

全モブが全システム触れるので優先順位が上のものからDoneにできる KDDI Agile Development Center Corporation 79

Slide 81

Slide 81 text

フィーチャーモブは良いことばかり 意思決定がスムーズ • 自モブでどう進めたいか意思決定をしてからチーム 全体に対して投げかけて合意をとる • うちの場合、”No”と言う人がいなければ合意 • 声が小さい人の意見が通りづらいなどある • “Five Fingerは遅い”という意見があった 開発のリードタイムが極小 • 開発ブランチはmain直Push • PR利用しないためレビュー待ち時間がない • デプロイは環境ブランチ(本番のみ承認制) • コンフリクトはモブ間で話してすぐ解決 ここでコンフリクト の調整をしない ここで会話 1人のエースに頼らない && 誰が休んでも進む • 常に複数人で意思決定をすることが習慣化され、 特定個人のエースが不在の時でも前に進む • 突然の退職や休職でも大きな影響を受けない • 「全員が1人で全部やれるようになる」を目指す ⇢ フルサイクルエンジニアの育成 KDDI Agile Development Center Corporation 80

Slide 82

Slide 82 text

フルサイクルエンジニア(Full Cycle Developer)とは ソフトウェアライフサイクルの全工程(設計・開発・ テスト・デプロイ・運用・サポート)に対して責任を 持つ開発者、およびそのような責任範囲でチームを 構成する開発モデル。 提唱 Netflixが2018年に提唱 特徴 開発者個人の超人性に頼るのではなく、プラッ トフォームチームが提供するツールと自動化に よって全工程の担当を可能にする。 AmazonのYou build it, you run it(自分で作って自分で運用しなさい)に近い KDDI Agile Development Center Corporation 81

Slide 83

Slide 83 text

なぜ今フルサイクルエンジニアを目指すのか KDDI Agile Development Center Corporation 82

Slide 84

Slide 84 text

AIがコードを書く時代、求められるのは「判断力」と「守備範囲の広さ」 ソフトウェアエンジニアの価値が、 「書くこと」から「判断すること」へ移った 実装やデザインなど、作業そのものはAIが加速する。 AIの答えを鵜呑みにせず、良し悪しを見極める能力こそが鍵となる。 品質と結果に責任を持つ判断力こそ、これからの人材に求められる。 「守備範囲の広さ」が判断力を底上げする 専門外だったインフラや監視、障害調査にも、AIに聞きながら踏み込める。 これまで数年を要した隣接領域の学習が、AIによって短縮された。 (これからは、対応できる守備範囲の広さが重要になる) 出典:スティーブン・R・コヴィー著『完訳 7つの習慣 人格主義の回復』(キングベアー出版)より引用。 ❝ すべての生命に、成長と発達のしかるべき順序がある。子供はまず寝返りを覚えてから、座り、はいはいすることを学ぶ。 その次に、歩き、走ることができるようになる。どの段階も重要であり、時間がかかる。省略できる段階は一つもない。人生のさまざま な段階で能力を開発するのも同じである。ピアノが弾けるようになることも、同僚とうまくコミュニケーションをとれるようになること も、段階を踏まねばならない。これは個人にも、夫婦や家族にも、組織にも当てはまる原則である。 ❞ 「判断力」と「守備範囲の広さ」を育てるには、経験を積み続けるしかない。 設計「だけ」でも運用「だけ」でも判断力は身につかない。自ら設計し作ったものを運用して初めて「設計の答え合わせ」ができる。 この往復を、ひとつの現場だけではなく多様な現場で繰り返す必要がある。 KDDI Agile Development Center Corporation 83

Slide 85

Slide 85 text

フルサイクルエンジニアなら様々な案件に参画できて更に経験を積みやすい KDDI Agile Development Center Corporation 84

Slide 86

Slide 86 text

まとめ 弱いチームは速く壊れ、強いチームは速く学ぶ 強いチームは学び続けて実験を続けるチーム フルサイクルチームはスケールできる 「判断力」と「守備範囲の広さ」こそが大事 フルサイクルを目指すにはフィーチャーモブから 始めることでジュニアエンジニアも育てやすい KDDI Agile Development Center Corporation 85

Slide 87

Slide 87 text

KAGメンバーのAI実践事例LTイベントを開催しました! サイトにて資料や録画を公開中 KDDI Agile Development Center Corporation 86

Slide 88

Slide 88 text

Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る