Beyond Scrum AIの力で開発プロセスを変革し続けるチーム 2025.10.30: AI駆動開発Conference Autumn KDDIアジャイル開発センター株式会社 Yuki Yoshida 

1 KDDI Agile Development Center Corporation Yuki Yoshida（吉田 祐樹） Senior Engineer@KDDIアジャイル開発センター • 15年以上アジャイル開発の現場に生息 • スクラムやXPを愛している • アジャイルコーチやテックリードとしての参画が多い • 「やったら片付ける」「小さくやる」などスクラムは 仕事以外でも私に大切なことをたくさん教えてくれた • 2025年3月KAG Join（出戻り） 特徴 好きな技術領域 • スクラム • Git • Vim • 自動化全般 

2 KDDI Agile Development Center Corporation 皆さん、KDDIグループのソフトウェア開発って どんなイメージを持ってますか？ 

KAGはAIに関する情報発信を積極的に実施！ 気づけば、ナレッジが山ほどたまってました 

4 KDDI Agile Development Center Corporation Q. 皆さんAIの進化についていけてますか？ 

5 KDDI Agile Development Center Corporation A. 私はついていけてます！ （AI駆動開発文脈なら） 

6 KDDI Agile Development Center Corporation Q. 皆さんの開発プロセスは 上手く回っていますか？ 

7 KDDI Agile Development Center Corporation A. 私はかなりの数つまずきましたが、 その分だけ効果が出てきました！ 

8 KDDI Agile Development Center Corporation 今日は2025年に向き合ってきた課題と どうチームで乗り越えてきたのかを共有します 

9 KDDI Agile Development Center Corporation 本題に入る前に うちの最高のチームを紹介 

10 KDDI Agile Development Center Corporation 全員が全部をやる（言い換えると「専業しない」ということ） • SREな何でもやる人、デザイナーな何でもやる人、等で構成されている（フィーチャーチーム） • 退職や長期休暇が発生しても特定の技術領域に穴が開かない（エースに依存しない） • 未経験な領域をやってもらうことが多いので立ち上げには時間がかかる（何も問題ない） • 一人で作業しない（常にモブワーク） • 1日中Slackハドル起動して作業内容を互いに共有 • mainブランチ1本のPullRequestを利用しないトランクベース開発 • 常に誰かと作業しているので常にレビューしてるよね、という話（/reviewもやってる） • PullRequestに対するAIコードレビューも試した結果「俺達には不要だね」となっている • 毎時50分前後に必ず10分休憩いれる（次のMTGに行く人も休めるように。ポモドーロも試した） • 基本フルリモートだがオフィス対面も試している（オフィスの食事は早い安い美味い綺麗） 常に何が効くか実験を繰り返している 今のチーム（5名）の特徴 誰にでも合うやり方だとは思っていない。今の自分たちには合っているのでこうしている。 来月は真逆のことをやっているかもしれない（自分たちで選択出来ることが大切） 

11 KDDI Agile Development Center Corporation 今はどんな課題を解決しようとしているのか （本題） 

12 KDDI Agile Development Center Corporation それを話すために2025年の前半から 振り返ります 

13 KDDI Agile Development Center Corporation Product Backlog #1 #2 #3 ・ ・ ・ #4 Product Owner Sprint Backlog #1-1 #1-2 #2-1 #2-2 #2-3 • 欲しいものの明文化（Why, What） • バックログの優先順位付け • バックログ作り • ステークホルダーとの調整 PO SM Developers Scrum Team 計画会議でサブタスクに分解 Developers 開発&テスト& リリース&振り返り プロダクト インクリメント ユーザー フィードバック SM プロセスの責任者 合計10名以下 • ユーザーからのフィードバック集め 欲しいものが優先順位順に並んだもの #1 #2 スクラムの役割とプロセスを整理（2025年頭） 繰り返す 

14 KDDI Agile Development Center Corporation 1週間の流れ（2025年頭） Day1（水） Day2（木） Day3（金） Day4（月） Day5（火） 開発 計画会議 開発 デイリースクラム リファインメント 開発 開発 デイリースクラム 開発 デイリースクラム デイリースクラム 開発 レビュー 振り返り 

15 KDDI Agile Development Center Corporation 普通！ で、ここに開発補助（AI） が入る 

16 KDDI Agile Development Center Corporation Product Backlog #1 #2 #3 ・ ・ ・ #4 Product Owner Sprint Backlog #1-1 #1-2 #2-1 #2-2 #2-3 • 欲しいものの明文化（Why, What） • バックログの優先順位付け • バックログ作り • ステークホルダーとの調整 PO SM Developers Scrum Team 計画会議でサブタスクに分解 Developers プロダクト インクリメント ユーザー フィードバック SM プロセスの責任者 合計5名（当時） • ユーザーからのフィードバック集め 欲しいものが優先順位順に並んだもの #1 #2 スクラムの役割とプロセスを整理（〜2025/4月） 繰り返す 開発補助 （AI） 入力補完中心の支援 GitHub Copilot 開発&テスト& リリース&振り返り 

17 KDDI Agile Development Center Corporation Day1（水） Day2（木） Day3（金） Day4（月） Day5（火） 開発 計画会議 開発 デイリースクラム リファインメント 開発 開発 デイリースクラム 開発 デイリースクラム デイリースクラム 開発 レビュー 振り返り おかわり計画 ここらへんで開発が完了 して、バックログのおか わりが発生する 良いね！ ベロシティが上がるので それを見積もりに反映し て次のスプリントでは もっとたくさんバックロ グ消化できるね！ でもこのままだと・・・ おかわり開発 おかわり開発 開発補助AIは単純に開発時間が短くなる 

18 KDDI Agile Development Center Corporation バックログが足りない！ 正確には、おかわりするために明確になってる バックログがどんどん足りなくなる 

19 KDDI Agile Development Center Corporation リファインメントを増やそう 

20 KDDI Agile Development Center Corporation Day1（水） Day2（木） Day3（金） Day4（月） Day5（火） 開発 計画会議 開発 デイリースクラム リファインメント 開発 開発 デイリースクラム 開発 デイリースクラム デイリースクラム 開発 レビュー 振り返り リファインメントが増えたこと で、計画会議の時間も減った 基本5分で終わる！（最高） 毎日リファインメントやるのが習慣化 この時点でサブタスク出しまで実施 うちのチームはこの時点でどのファイル にどんな関数（In/Out）を作るのか、 も考えてサブタスク化します リファインメント リファインメント リファインメント リファインメント 1週間の流れ（〜2025/4月） 

21 KDDI Agile Development Center Corporation 2025/5 Claude Code襲来 

22 KDDI Agile Development Center Corporation Claude Codeによるパラダイムシフト AIが「開発補助」ではなく「エージェント」へ • 小規模プロダクトなら「2-3日」かかるものが「2-3時間」で出来るようになった • 当時Clineを使う人が多くいたが定額で最新モデルを多用できるClaude Codeが一気に普及 現場はパニック • Claude Codeに任せた方がほとんどのケースで速いが、ハマると人がやる方が速いことがある • このムラについて原因を特定することが出来ない • モブ開発で交代制のため、人ごとに入力するコンテキスト量が違うのが原因か？ • コードベースを理解していないのか？あるいはコンテキストが消えているのか？ • 料金プランやセッション保持の仕組みが関係しているのか？ • このムラが原因で見積もり精度が低下しベロシティが安定しない 

23 KDDI Agile Development Center Corporation なら実験だ 

24 KDDI Agile Development Center Corporation どこからどこまでAIに任せて良いのか実験が始まる（2025/6-7） 1. 人がサブタスクを超大雑把に切ってAIに実装させる • リファインメント時間短縮に繋がる期待があった（実際サブタスク出しの時間は削れた） • 今までは「Inputがxxx型の配列でoutputがyyyの関数で〜」のような粒度のサブタスク出しだっ たものを「バックエンド実装」程度の粒度にして、ユーザーストーリーと共に指示してみる • イケてない実装、書いてほしいファイルに書いてくれない、全然駄目 2. リファインメント中の設計とサブタスク出しをAIに任せてみる • 自分達なりの100点満点の設計を超えた120点のアイデアが短時間で出てくる期待があった • 設計に考慮不足が多く待ち時間が長く、駄目（コンテキストが少ないので今思えば当たり前） • 自分達で先に設計し「AIは人間と同じサブタスクを出せるのか」も検証したが 「膨大なプロンプトを渡せば出来る」という結論が出た 3. 今まで通り関数のI/Fレベルまで人間がサブタスクを切って実装させる • めちゃくちゃ上手くいく。ちゃんと設計したらちゃんと実装される！ その他様々な実験を行ったが結果・・・ 

25 KDDI Agile Development Center Corporation 実験結果まとめ（2025/7時点） え、つまり・・・ 実装 正しい設計情報を渡すことが出来ればAIは良い実装してくれる 必要な背景情報（非機能要件、対向先の情報、完成の定義など 多数）を適切に渡すことが出来ればAIは良い設計をしてくれる 必要な 背景情報 良い設計 良い実装 ってことぉ！？ 設計 

26 KDDI Agile Development Center Corporation ”最近SDDというのが流行ってるんです” 

27 KDDI Agile Development Center Corporation と、2025年入社の新卒メンバーが教えてくれた 

28 KDDI Agile Development Center Corporation SDD（Spec-Driven Development）とは 定義 ワークフロー Start a spec 仕様要件 （requirements.md） Happy? 設計文書 （design.md） 実装計画 （tasks.md） Happy? Edit or Request changes Yes No Edit or Request changes No SDDでよく使われるツール例 • Kiro ・Spec Kit • cc-sdd ・OpenSpec • コードを書く前に仕様を厳密に定義し、テスト・実装・ドキュメントを派生させる開発手法 • 仕様要件、設計文書、実装計画の順番でドキュメントを残してから開発を行う Yes 日本語は表記ゆれが多い • 仕様駆動開発 ・仕様書駆動開発 • スペック駆動開発 ・Spec駆動開発 

29 KDDI Agile Development Center Corporation これを俺達のスクラムに取り入れてみた 

30 KDDI Agile Development Center Corporation スクラムの中でSDDを実践していく！ PO リファインメントまでに整理 リファインメントで整理 開発 ChatGPT ほしいもの やりたいこと 壁打ち SM Kiro SM PO Developers Kiro 設計文書 （design.md） 実装計画 （tasks.md） Developers Claude Code （cc-sdd） 成果物 （GitHub） モブで議論 しながら 仕様要件 （requirements.md） ステアリング ・技術情報更新 ステアリング ・製品情報 ・対向システム情報 ・完成の定義 など ※cc-sddはKiroと同じファイルが見れるため、Kiro使いのうちのチームには必須ツール 

31 KDDI Agile Development Center Corporation めっちゃ良さそう！ と思ったが・・・ 

32 KDDI Agile Development Center Corporation 計画会議が終わらない 

33 KDDI Agile Development Center Corporation 無限計画会議編へ。。。 むしろ事前にリファイ ンメントでも同じこと をやっていたので、 もっと長時間やってい たと言える 振り返りで「SDDやめま しょう」と何人が言い出 すか不安になる。。。 議論が白熱しすぎなの と設計書が膨大で 計画会議が終わらない Day1（水） Day2（木） Day3（金） Day4（月） Day5（火） 開発 計画会議 デイリースクラム リファインメント 開発 開発 デイリースクラム デイリースクラム デイリースクラム 開発 レビュー 振り返り リファインメント リファインメント 開発 開発 リファインメント 開発 開発 リファインメント 開発 開発 計画会議 計画会議 計画会議 

34 KDDI Agile Development Center Corporation SDDの振り返り みんなSDDに前向き KAGリードSREからのコメント 普段、実装中に「あっこれチームで議論しなくちゃ」ってものを先に議論できている 感覚があって、これが最効率なのかもしれないと感じてきました。 

35 KDDI Agile Development Center Corporation その後、数スプリント回した結果 わかってきた 

36 KDDI Agile Development Center Corporation SDDは開発時間が短縮される PO リファインメントまでに整理 リファインメントで整理 開発 ChatGPT ほしいもの やりたいこと 壁打ち SM Kiro SM PO Developers Kiro 設計文書 （design.md） 実装計画 （tasks.md） Developers Claude Code （cc-sdd） 成果物 （GitHub） モブで議論 しながら 仕様要件 （requirements.md） ステアリング ・技術情報更新 ステアリング ・製品情報 ・対向システム情報 ・完成の定義 など こっちめちゃくちゃ時間かかって こっちめっちゃ早い バックログ次第ではあるものの体感平均 8:2 くらい （ちなみにSDDやる前は2:8くらい） 

37 KDDI Agile Development Center Corporation SDDやってみて分かったこと メリット • 手戻りが少なく、実装が着実に前に進んでいる感覚が味わえる（早いとは感じづらい） • 設計段階で技術要素の不明点をめちゃくちゃ喋るからチームの認識が合う • （人がしっかりレビューすれば）変な設計や変な実装をされることが少ない 戸惑ったが乗り越えたもの • Specやrequirementsの粒度を価値ベースで書くと設計が膨れ上がる • 価値ベースじゃないと何をテストすれば良いのかを見失う • SDDの前段で設計をして、SDDはAPI単位でやるのが良いのでは？が今の個人的な解 デメリット • バックログのスライスが難しい(これが致命的だが、これは後述) • 見積もりが難しい • スプリントの大半が計画で消えていく中、実装部分だけを見積もることに価値があるのか？ • requirements（orもっと前）段階でざっくりとした見積もりを入れるしかなさそう ※発表者はスクラム大好き芸人です 経験積んだら早いって感じてきました 

38 KDDI Agile Development Center Corporation チームで議論して出た仮説 

39 KDDI Agile Development Center Corporation SDDは「スプリントと相性が悪い」のでは？説 

40 KDDI Agile Development Center Corporation Day1（水） Day2（木） Day3（金） Day4（月） Day5（火） 計画会議 バックログ1つ目 計画会議 バックログ1つ目 計画会議 バックログ2つ目 計画会議 バックログ2つ目 開発 バックログ1つ目 開発 バックログ1つ目 開発 バックログ2つ目 （終わらない、知ってた） SDDとスプリントの相性が悪いと感じるとき • 設計やタスク出し後、スプリント期間内に 収まらないことに気付いてもrequirements からやり直す選択肢を取れない • スクラムを正しく行うためにrequirements を割ることに時間を割くのは違和感がある バックログのスライスが出来ない 開発が終わらない、予想通り • バックログ1つ目のみのレビュー、振り返り となる • 振り返りの内容をバックログ2つ目から活か すべきかもしれないのに反映できない レビュー 振り返り 計画会議の終了タイミングが分からなくなる • バックログ1つ目の実装計画完了後、「1週間あるならもう一個バックログいっとく？」となるも、 次のバックログの実装計画をたててみないと「あと1ついけるのか？」すらわからない • スクラムガイドには「計画会議は1ヶ月スプリントなら8h以内」と書いてあるので、1週間スプリ ントの場合2h以内と考えるともうこの時点でアウト ※発表者はスクラム大好き芸人です 

41 KDDI Agile Development Center Corporation スプリント無しのスクラムやってみる？ 

42 KDDI Agile Development Center Corporation スクラムガイド2020年版から抜粋 （前略） ここで概要を述べたように、スクラムフレームワークは不変である。 スクラムの一部だけを導入することも可能だが、それはスクラムと は言えない。 すべてを備えたものがスクラムであり、その他の技法・方法論・プ ラクティスの入れ物として機能するものである。 ❝ ❞ つまり、スクラムからスプリントを取ったらそれはスクラムではない、ということ 

43 KDDI Agile Development Center Corporation そんな折 AWSが発表したAI-DLCに出会う https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ 

44 KDDI Agile Development Center Corporation AI-DLC（AI-Driven Development Life Cycle）意訳 スクラムとの大きな違い AI-DLCとは • 既存の開発手法（SDLC）そのものをAI利用前提で再発明した • 人間は監督と意思決定、AIが主導する • [例]Google Map: 人間が目的地（意図）を指定しシステムが道順 （手法と推奨）を提示し道中の監督は人間が行う スクラム AI-DLC 計画の固定度 プロセス固定 意図に応じてAIが柔軟に計画 イテレーション スプリント（1ヶ月以内） ボルト（数時間 – 数日） 設計技法 チームに委ねる DDD/BDD/TDDが推奨 （現行ホワイトペーパーはDDD） ワークの方法 チームに委ねる モブワークが中心 

45 KDDI Agile Development Center Corporation 今チームで検討しているAI-DLCフロー 

46 KDDI Agile Development Center Corporation 2. Construction（Mob Construction & Testing） 3. Operations AI-DLCとSDDを組み合わせたフロー（仮） 1. Inception（Mob Elaboration ） 技術制約 （外部アクター、インフラの制約等） ＋ .kiro/steering/domain-ubiquitous-language.md ユビキタス言語、ドメインイベント .kiro/steering/bounded-contexts.md Bounded Context（≒Unit一覧） .kiro/steering/context-map.md Context Map （≒Unit同士の繋がりを可視化したもの） ① ② ③ Unit 1 Spec（=Unit） Requirement （仕様要件） Design （設計書） Bolt（1Bolt 2時間から2日以内） Unit 2 Bolt 1 Task Group （10個以内目安） Bolt振り返り （5– 10分） … 本番デプロイ Unit振り返り （1h） ビジネス要件 （Intent） テスト Task Groups 

47 KDDI Agile Development Center Corporation ビジネス要件をモデリングしコンテキストに分割（仮） ① Intentの構造化（軽いイベントストーミング） Intent/技術制約からDDD前提で分解。ユースケース、主要ドメインイベント、用語候補を列挙。 同名異義語や用語衝突も抽出して、用語集を更新して。 主要ユースケース・ドメインイベント・用語候補を洗い出しユビキタス言語を更新 上のIntent/用語/イベントから、Bounded Context候補を列挙して。 各候補に「主要責務・主要アグリゲート・入出力イベント・外部依存」を付与。 ヒューリスティクス（用語衝突/変更速度/NFR/規制/外部SaaS/組織）に照らして理由も記述。 • コンテキスト同士の依存関係を把握し全体像の可視化を行う 各コンテキストの流れを明記し、Published Language / Open Host Service / Anti- Corruption Layer適切なパターンを割り当てて context-map.md を更新。理由も書いて。 ② Bounded Context（≒Unit一覧）更新 ③ Context Map（≒Unit同士の繋がりを可視化したもの）更新 • 「販売」「配送」「在庫」など、理解しやすい単位で揃える • 用語衝突の解消 • 販売コンテキストの「注文」＝購入意思（商品、数量、金額） • 配送コンテキストの「注文」＝配送指示（住所、希望日時、配送方法） 1. Inception（Mob Elaboration ） .kiro/steering/domain-ubiquitous-language.md ユビキタス言語、ドメインイベント .kiro/steering/bounded-contexts.md Bounded Context（≒Unit一覧） .kiro/steering/context-map.md Context Map （≒Unit同士の繋がりを可視化したもの） ① ② ③ 技術制約 （外部アクター、インフラの制約等） ＋ ビジネス要件 （Intent） 

48 KDDI Agile Development Center Corporation まとめ • 今までもこれからもチームみんなで考えて決めていく • 一度スクラムをやめてAI-DLCに挑戦し、また次の改善策に挑戦していく • ただし開発手法系は短期間触っただけで結論出すのは早計（SDD、スクラムもそう） チームの今後の方針 今分かってる課題と期待してる解決策 • Agentic Codingは技術力が上がりづらい（気持ちになる） • 確かにコードを書く力は落ちたが、頭を使う機会が減ったのか？というとそうではない。 • AI-DLCではDDDなど設計技法を学べるのでコードを書く以外の技術力は着く（はず） • ジュニアエンジニアの育て方 • Agentic Codingのモブワークだけでは育成は難しいと感じている • 今はSDDの設計中の会話の中で学んでもらっている。これは結構手応えあり ※発表者はスクラム大好き芸人です 

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