AI時代の強いチームの作り方

Transcript

1. 2 02 6.0 7 .31 | AI駆動開発Conference Summer AI時代の強いチームの作り方 S PEA KER Yuki Yoshida KDDIアジャイル開発センター株式会社
2. 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
3. 突然ですが 最近、みんなの心すり減ってません？ KDDI Agile Development Center Corporation 2
4. 奴（AI）はとんでもないものを盗んでいきました。あなたの心です。 KDDI Agile Development Center Corporation 3
5. AI利用の最前線であるKAGもみんないっぱいいっぱい KDDI Agile Development Center Corporation 4
6. AI利用拡大に伴い・・・ KDDI Agile Development Center Corporation 5
7. 多くの開発会社がAI利用費に投資し、人件費を減らせるか検討している KDDI Agile Development Center Corporation 6
8. 追い打ちをかけるように KDDI Agile Development Center Corporation 7
9. Anthropic主催のハッカソンで非エンジニアが優勝 KDDI Agile Development Center Corporation 8
10. もうソフトウェアエンジニアは不要なの？ KDDI Agile Development Center Corporation 9
11. 一方SNSでは KDDI Agile Development Center Corporation 10
12. 2026年3-5月はこんな書き込みが目立ちました KDDI Agile Development Center Corporation 11
13. チームも不要なの？ KDDI Agile Development Center Corporation 12
14. 否 KDDI Agile Development Center Corporation 13
15. AIで速く作れる = “安心安全” だといつから錯覚していた？ KDDI Agile Development Center Corporation 14
16. “開発会社”だからこそ出来ることがある KDDI Agile Development Center Corporation 15
17. “開発会社”だからこそ出来ることがある ❝ AIは契約主体にはなれません。 約束をして責任を取る、という主体にはなれないのです。 一方で、組織はそれができます。 ❞ （中略） では、組織にしかできないことは何か。それは「永続性」だと私は思います。人の命、人格は長くても百年です。 しかし、法人格は終わりを想定していない、つまり永続を前提としています。 — 南場智子（DeNA 代表取締役会長） 出典：「DeNAが挑む『AIネイティブカンパニー』への全社的取り組み」フルスイング by DeNA（2025） 開発会社を使うメリットは圧倒的にコレ KDDI Agile Development Center Corporation 16
18. 開発会社が作るメリットは分かった でも・・・ KDDI Agile Development Center Corporation 17
19. ”AIの力でチームを縮小出来る” これは事実だよね？ KDDI Agile Development Center Corporation 18
20. そうとも限らない KDDI Agile Development Center Corporation 19
21. 例えば、AIを最大限上手く活用出来た時、 人の数を1/3にすることが出来ると仮定します ※1/2でも1/100でも自社に合わせた数字に脳内変換してください KDDI Agile Development Center Corporation 20
22. 現実的にあり得るかは置いておいて偉い人達が考えているのはきっとこういうこと KDDI Agile Development Center Corporation 21
23. 現実的にあり得るかは置いておいて偉い人達が考えているのはきっとこういうこと KDDI Agile Development Center Corporation 22
24. 本当に出来ますか？ KDDI Agile Development Center Corporation 23
25. （理論的には） この6名がめっちゃ有能なら 短期的には恐らく出来ます KDDI Agile Development Center Corporation 24
26. そのチーム、サステナブル（持続可能）ですか？ KDDI Agile Development Center Corporation 25
27. なら、どうする？ KDDI Agile Development Center Corporation 26
28. 人を増やしたら成果もスケールする仕組みを考える KDDI Agile Development Center Corporation 27
29. 人を増やしたら成果もスケールする仕組みを考える KDDI Agile Development Center Corporation 28
30. “言うは易し” ではない KAGは複数チームで実現しています KDDI Agile Development Center Corporation 29
31. ということで、やっと今日の本題へ KDDI Agile Development Center Corporation 30
32. AI時代を生き抜く強いチームの作り方を復習するぞ！ KDDI Agile Development Center Corporation 31
33. AI時代に強いチームは必要なのか？ KDDI Agile Development Center Corporation 32
34. AI時代、弱いチームは速く壊れ、強いチームは速く学ぶ ※DORA Research: 2025 https://dora.dev/research/2025/ KDDI Agile Development Center Corporation 33
35. ”強いチーム” とは？ KDDI Agile Development Center Corporation 34
36. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 35
37. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 36
38. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 37
39. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 38
40. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 39
41. AI駆動開発時代でも学び続けるチームが最強って話 KDDI Agile Development Center Corporation 40
42. 逆にたぶんこれが最悪のやり方（学びにならない） KDDI Agile Development Center Corporation 41
43. 強いチームを目指すための前提条件 KDDI Agile Development Center Corporation 42
44. チームの外にいる管理職の考えを変える必要がある（マグレガーのX理論・Y理論） KDDI Agile Development Center Corporation 43
45. チームの外にいる管理職の考えを変える必要がある（マグレガーのX理論・Y理論） KDDI Agile Development Center Corporation 44
46. では、ここからうちのチームの働き方 KDDI Agile Development Center Corporation 45
47. 1年ほどスクラムベースのAI-DLCを継続中 KDDI Agile Development Center Corporation 46
48. 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
49. AI-DLCの原則 White Paperの10原則はマインド面での説明が多く ”AIをどう使うか”についての記述は少なめ 詳細については過去の登壇を参照ください https://speakerdeck.com/yuukiyo /ai-dlc-deep-dive KDDI Agile Development Center Corporation 48
50. AI-DLCの原則 + White Paperはマインド面を指していて、Workflowは実践面を指しているため 【原則が生まれ変わった】ではなく【合わせて考えるべき】という理解（私見） KDDI Agile Development Center Corporation 49
51. AI-DLC原則も一気にやらず少しずつ実践していくのが良い あ、この手があったか！ という発見は意外と身近にある 例えば・・・先日KAG内のAI駆動開発勉強会で KDDI Agile Development Center Corporation 50
52. AI-DLCのフェーズ（簡易版） White Paperの3フェーズで実施。難しく考えず、こう読み替えればOK Inception フェーズ ≒ Construction フェーズ 設計 ≒ 要求を理解し、 「何を・どう作るか」を決める 実装 設計をもとに、 動くソフトウェアを作り上げる 正確にはOperationフェーズもあるが、まずは「設計 → 実装 → 運用」と捉えればOK ※aidlc-workflows v2ではInitializationとIdeationフェーズもありますが上記はv1 KDDI Agile Development Center Corporation 51
53. スクラムベースのAI-DLC KDDI Agile Development Center Corporation 52
54. スクラムベースのAI-DLC KDDI Agile Development Center Corporation 53
55. スクラムベースのAI-DLC KDDI Agile Development Center Corporation 54
56. スクラムベースのAI-DLC KDDI Agile Development Center Corporation 55
57. スクラムベースのAI-DLC ちょっとだけここを深堀り!! KDDI Agile Development Center Corporation 56
58. KDDI Agile Development Center Corporation 57
59. KDDI Agile Development Center Corporation 58
60. レビューで鋭い指摘がバンバン飛んでくるため 事前のAIとの対話でめちゃくちゃ真剣に調査する KDDI Agile Development Center Corporation ＝ ジュニアエンジニアが めちゃくちゃ成長する環境 59
61. KDDI Agile Development Center Corporation 60
62. Constructionフェーズ KDDI Agile Development Center Corporation 61
63. Constructionフェーズ KDDI Agile Development Center Corporation 62
64. Constructionフェーズ KDDI Agile Development Center Corporation 63
65. Constructionフェーズ KDDI Agile Development Center Corporation 64
66. フェーズまとめ かけてる時間としては「設計8 : 実装2」 Inceptionフェーズ（設計） Constructionフェーズ（実装） モブワーク モブワーク 全体情報共有 全体情報共有 以前までは「実装してみないとわからない」だったものがAI駆動になって設計フェーズで議論出来るように なった、且つAIのお陰で実装にかける工数を圧縮できたこともあり設計に重きを置けるようになった KDDI Agile Development Center Corporation 65
67. 基本は常にモブプロ 設計 or 実装が終わるごとに全員で同期 KDDI Agile Development Center Corporation 66
68. ここまでは普通 （毎日6時間モブプロ出来るチームを普通と呼ぶかは置いておいて） KDDI Agile Development Center Corporation 67
69. スクラムベースのAI-DLC KDDI Agile Development Center Corporation 68
70. スクラムベースのAI-DLC うちのチームが凄いのは ここがスケーラブルであること KDDI Agile Development Center Corporation 69
71. なぜスケール出来るのか KDDI Agile Development Center Corporation 70
72. 答えはフィーチャーチーム KDDI Agile Development Center Corporation 71
73. この一年で4度チームの働き方について登壇してます 共通して伝えていることはフィーチャーチームが必要であるということ KDDI Agile Development Center Corporation 72
74. フィーチャーチーム？ KDDI Agile Development Center Corporation 73
75. フィーチャーチームならエンドツーエンドで価値を提供できる 必要なケイパビリティがチーム内で完結してる 他チームとの依存関係が少ない 品質にチーム全体で責任を持てる 顧客視点で開発しやすい 完成の定義が明確になる KDDI Agile Development Center Corporation 74
76. KAGで試行しているのはもっと小さい単位 KDDI Agile Development Center Corporation 75
77. フィーチャーモブ KDDI Agile Development Center Corporation 76
78. 顧客価値をE2Eで完結する動的に編成された2〜3名体制のモブ KDDI Agile Development Center Corporation 77
79. フィーチャーモブの進め方 KDDI Agile Development Center Corporation 78
80. 全モブが全システム触れるので優先順位が上のものからDoneにできる KDDI Agile Development Center Corporation 79
81. フィーチャーモブは良いことばかり 意思決定がスムーズ • 自モブでどう進めたいか意思決定をしてからチーム 全体に対して投げかけて合意をとる • うちの場合、”No”と言う人がいなければ合意 • 声が小さい人の意見が通りづらいなどある • “Five Fingerは遅い”という意見があった 開発のリードタイムが極小 • 開発ブランチはmain直Push • PR利用しないためレビュー待ち時間がない • デプロイは環境ブランチ（本番のみ承認制） • コンフリクトはモブ間で話してすぐ解決 ここでコンフリクト の調整をしない ここで会話 1人のエースに頼らない && 誰が休んでも進む • 常に複数人で意思決定をすることが習慣化され、 特定個人のエースが不在の時でも前に進む • 突然の退職や休職でも大きな影響を受けない • 「全員が1人で全部やれるようになる」を目指す ⇢ フルサイクルエンジニアの育成 KDDI Agile Development Center Corporation 80
82. フルサイクルエンジニア(Full Cycle Developer)とは ソフトウェアライフサイクルの全工程(設計・開発・ テスト・デプロイ・運用・サポート)に対して責任を 持つ開発者、およびそのような責任範囲でチームを 構成する開発モデル。 提唱 Netflixが2018年に提唱 特徴 開発者個人の超人性に頼るのではなく、プラッ トフォームチームが提供するツールと自動化に よって全工程の担当を可能にする。 AmazonのYou build it, you run it（自分で作って自分で運用しなさい）に近い KDDI Agile Development Center Corporation 81
83. なぜ今フルサイクルエンジニアを目指すのか KDDI Agile Development Center Corporation 82
84. AIがコードを書く時代、求められるのは「判断力」と「守備範囲の広さ」 ソフトウェアエンジニアの価値が、 「書くこと」から「判断すること」へ移った 実装やデザインなど、作業そのものはAIが加速する。 AIの答えを鵜呑みにせず、良し悪しを見極める能力こそが鍵となる。 品質と結果に責任を持つ判断力こそ、これからの人材に求められる。 「守備範囲の広さ」が判断力を底上げする 専門外だったインフラや監視、障害調査にも、AIに聞きながら踏み込める。 これまで数年を要した隣接領域の学習が、AIによって短縮された。 （これからは、対応できる守備範囲の広さが重要になる） 出典：スティーブン・R・コヴィー著『完訳 7つの習慣 人格主義の回復』（キングベアー出版）より引用。 ❝ すべての生命に、成長と発達のしかるべき順序がある。子供はまず寝返りを覚えてから、座り、はいはいすることを学ぶ。 その次に、歩き、走ることができるようになる。どの段階も重要であり、時間がかかる。省略できる段階は一つもない。人生のさまざま な段階で能力を開発するのも同じである。ピアノが弾けるようになることも、同僚とうまくコミュニケーションをとれるようになること も、段階を踏まねばならない。これは個人にも、夫婦や家族にも、組織にも当てはまる原則である。 ❞ 「判断力」と「守備範囲の広さ」を育てるには、経験を積み続けるしかない。 設計「だけ」でも運用「だけ」でも判断力は身につかない。自ら設計し作ったものを運用して初めて「設計の答え合わせ」ができる。 この往復を、ひとつの現場だけではなく多様な現場で繰り返す必要がある。 KDDI Agile Development Center Corporation 83
85. フルサイクルエンジニアなら様々な案件に参画できて更に経験を積みやすい KDDI Agile Development Center Corporation 84
86. まとめ 弱いチームは速く壊れ、強いチームは速く学ぶ 強いチームは学び続けて実験を続けるチーム フルサイクルチームはスケールできる 「判断力」と「守備範囲の広さ」こそが大事 フルサイクルを目指すにはフィーチャーモブから 始めることでジュニアエンジニアも育てやすい KDDI Agile Development Center Corporation 85
87. KAGメンバーのAI実践事例LTイベントを開催しました！ サイトにて資料や録画を公開中 KDDI Agile Development Center Corporation 86
88. Be a Change Leader. アジャイルに力を与え 共に成長し続ける社会を創る