生成AIでスクラムによる開発はどう変わるか

10/17に技術顧問先の社内イベントで登壇した際のスライドです

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. 生成AIで スクラムによる開発はどう変わるか 2025/10/17 fi 株式会社アトラクタ / Certi ed Scrum Trainer （CST） 吉羽 龍太郎 （@ryuzee）
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. 生成AIでスクラムによる開発はどう変わるか 4 今日のテーマ ▸ 生成AIはもはや検証段階ではなく、日常的に使いこなす段階になった ▸ 多くの現場で利用されており、利用することがプラスなのではなく、利用しないことがマイナスな状況 ▸ その結果、スクラムでの開発にも大きな変化を及ぼしている ▸ 時間の使い方 ▸ 作業の進め方 ▸ 品質維持の方法 ▸ チーム構成 ▸ その変化とはどんなものなのかを詳しく見ていく AIの導入はほぼ当たり前になった。調査回答者の 大多数（90％）が仕事の一環としてAIを利用して おり、80％以上がAIによって生産性が向上したと 考えている。 State of AI-assisted Software Development 2025
5. スクラムの全体像と 従来の時間の使い方
6. 生成AIでスクラムによる開発はどう変わるか 6 スクラムの全体像（3-3-5） プロダクトバックログ 完成の定義 プロダクトの改善に必要なことを記載し並び替える。規 模は開発者が見積もる。アイテムの追加は自由だが実 施有無や順番はプロダクトオーナーが最終決定権限を 持つ。スクラムチームの作業の唯一の情報源になる 何をもって「完成」 とするかを 定義したリスト＝品 質基準 プロダクトバックログリファインメント プロダクトオーナー デイリースクラム このまま進めてスプリントゴールが達成で きるかを毎日最長15分間で検査し、必要に 応じて今後の計画を調整する 次回以降のスプリントに向けてプロダクトバックログ アイテムを見直したり、上位のアイテムを着手可能な 状態にしたりする スプリントプランニング 開発者 スプリント 最大1か月までの固定の期間 各スプリントの長さは同一で、作業が早く終わって も短縮せず、終わらなくても延長しない 毎日の繰り返し スプリントバックログ スプリントレビュー スプリントゴールとその実現に向 けて選択したプロダクトバックロ グアイテムと、実行計画の3つを あわせたもの ステークホルダーを招待し、スプ リントで開発したインクリメントを デモしながらプロダクトの今後の 適応を検討する スプリントレトロスペク ティブ 今回のスプリントでうまくいったこ と、問題だったことを話し合った上 で今後の改善計画を立案する スクラムマスター スクラムガイドで定義されたスクラムがき ちんと実践され、チームが有効に機能する ことについて説明責任を持つ 価値ある有用なインクリメント 複数回スプリントを繰り返す そのスプリントでどんな価値を新たに生み 出すか検討し(スプリントゴール)、それを実 現するために必要なプロダクトバックログ アイテムを選択し、実行計画を立案する プロダクトの価値を最大化することに 説明責任を持ち、プロダクトバックログ が適切に管理されていることに責任を持つ。 スクラムチームに1人 プロダクトの開発を行う。 作業規模の評価を行う、完成の定義を守って 品質を作り込む責任があり、スプリントゴール を確約する ステークホルダー プロダクトの利用者、出資者、管理職などの 利害関係者。スプリントレビューに必要に応じ て招待する
7. 生成AIでスクラムによる開発はどう変わるか 7 スクラムで開発するときの一般的な時間配分（いままで） ▸ 開発時間をなるべく増やせるように、それ以外のことを削ろうとする 項目 時間 社内全体会議 1 事務手続き・報告・メール 2 研修 2 休暇 4 スクラムイベント 5 プロダクトバックログリファインメント 2 開発作業 24
8. 生成AIでスクラムによる開発はどう変わるか いままでの時間配分は、実装作業に時間がかかることに由来していた ▸ 実装にいちばん時間がかかる ▸ すなわち実装がスプリントの律速要因 ▸ 「誰がどれだけ書けるか」に強い関心を持つ ▸ そこで、実装作業を効率化すべくさまざまな取り組みをする ▸ 設計や計画の段階で「実装効率」を目指す ▸ 並列作業でスループット最大化しようとする ▸ タスク分解の粒度を「実装しやすさ」基準にする ▸ つまり、効率化のために長い時間をかけて見積りや分解を含めた準備をする 8
9. 生成AIでスクラムによる開発はどう変わるか いままでのスクラムの最適化の観点 ▸ 実装が遅い（高コストである）ことを前提に、その遅さとリスクを少しでも減らすように最適化していた ▸ 生煮えのプロダクトバックログアイテムをスプリントに投入しないようにする ▸ ベロシティを計測して、入り切らないプロダクトバックログアイテムを計画に含めないようにする ▸ スプリントゴールが達成できそうかどうかを毎日検査して再計画する ▸ この前提が変わると、スクラム全体が変わる 9
10. 生成AIの登場と変化
11. 生成AIでスクラムによる開発はどう変わるか 11 生成AIの普及 ▸ LLMベースの支援が実務レベルで利用可能になった ▸ 調査、実装、テスト支援、ドキュメント生成など ▸ 調査 ▸ ChatGpt、Gemini、Claudeなど ▸ API/ライブラリ探索の時短 ▸ 実装 ▸ GitHub Copilot、Claude Code、Cursorなど ▸ 実装スピードの桁違いの短縮 ▸ プロトタイピングの高速化 ▸ すでに多くの現場で導入が進み、標準ツールに近づく State of AI-assisted Software Development 2025, p.27
12. 生成AIでスクラムによる開発はどう変わるか 12 生成AIによって何が変わったか ▸ 技術的な調査の時間と実装作業の時間が劇的に減少 ▸ 実装がもはやボトルネックではなくなる ▸ 一方で以下の時間が増加した ▸ AIから望む結果を得るための事前作業の時間 ▸ AIの出力を検証するための事後作業の時間 ▸ これら2つに課題が移動 しかし注目すべき点として、回答者の30％はAIが 生成したコードをほとんど、あるいはまったく信用 していないと報告しており、これは批判的検証ス キルの必要性を示している State of AI-assisted Software Development 2025
13. ドキュメント中心化
14. 生成AIでスクラムによる開発はどう変わるか AIによるコーディングの制約 ▸ AIは「考えを想像」してくれない（人間はある程度想像してくれる。忖度？） ▸ コンテキストを正しく「伝える」必要がある ▸ 当然ながら、暗黙知のままでは伝わらないので、知識をテキスト化しなければいけない ▸ プロンプトでの試行錯誤はテキストが消失してしまう ▸ すなわちドキュメントの重要性が急上昇した ▸ 従来は、「共通理解」に至れば、ドキュメントの多寡はあまり問題ではなかった ▸ 「包括的なドキュメントよりも動くソフトウェアを」（Manifesto for Agile Software Development） 14
15. 生成AIでスクラムによる開発はどう変わるか スクラム関連のドキュメントの例 従来からドキュメント化しているものもあるが、AIの活用有無や度合いによって詳細度が変化する（※） ▸ プロダクトバックログ ▸ スプリントゴールやスプリントバックログ ▸ 完成の定義（品質基準） ▸ プロダクトバックログリファインメントの記録と決定事項 ▸ スプリントレビューでのフィードバックログ ▸ スプリントレトロスペクティブの実験・改善事項 ▸ …… ※ 全種類ドキュメント化しろという意味でもないし、全部詳細に書くといいという意味でもないので注意 15
16. 生成AIでスクラムによる開発はどう変わるか ソフトウェア全般のドキュメントの例 従来からドキュメント化しているものもあるが、AIの活用有無や度合いによって詳細度が変化する（※） ▸ アーキテクチャーの説明 ▸ コーディング規約 ▸ API/スキーマ仕様 ▸ テスト戦略 ▸ セキュリティ・プライバシーの対応方針 ▸ パフォーマンス要件とSLO/SLA ▸ デプロイ／運用手順 ▸ 用語集やドメインモデルカタログ ▸ …… ※ 全種類ドキュメント化しろという意味でもないし、全部詳細に書くといいという意味でもないので注意
17. 生成AIでスクラムによる開発はどう変わるか AIに渡すためのドキュメント化 ▸ 誤解しにくいドキュメントが必須 ▸ 前提が不足していたり、曖昧な単語を使ったりすると出力の質が下がったり、試行回数が増えたりする ▸ コツ ▸ 前提条件・入力・出力を具体化する ▸ 例と反例を示す（Speci cation by Example） ▸ 参照先（設計・コード・テスト）を紐付ける ▸ 用語の一貫性を保つ。用語の定義を明記する ▸ 「AIに食わせるドキュメント」としての品質が重要 fi ▸ 逆に言うと「ゴミを入れるとゴミが出る」 17
18. 生成AIでスクラムによる開発はどう変わるか 投資先のシフト ▸ プロンプトを繰り返すのは非効率 ▸ 最初に良いドキュメントを作るほうが効率的 ▸ チームでのドキュメント整備が中心課題になる ▸ そこで検査と適応を繰り返して改善していく ▸ スプリントレトロスペクティブなどで扱うテーマになる ▸ チームとしての取り組み ▸ 共通テンプレートや書き方のガイド ▸ モブでのドキュメント作成やレビュー ▸ ドキュメントの再利用性や検索性の向上 ▸ 良いドキュメントを書けることが競争力に直結する 18
19. 生成AIでスクラムによる開発はどう変わるか 19 プロダクトバックログリファインメントでのドキュメント化 スクラムチームが将来のスプリントのために、事前にプロダクトバックログアイテムの手入れをする。 どの程度手を入 れるかは、そのアイテムにいつごろ着手しそうかによる。 ▸ プロダクトバックログアイテムを詳細化し、AIに渡せる程度の粒度・詳細度にする ▸ 何をAIに渡すかで出力が決まるので、チームで議論しながらモブで記述するのが理想 ▸ 直近取り組みそうなプロダクトバックログアイテムをAI Readyにする ▸ スプリントプランニングでも十分間に合うようになればタイミングを遅らせる
20. 生成AIでスクラムによる開発はどう変わるか 20 ドキュメントのテキスト化とバージョン管理 ▸ ドキュメントはAIに渡しやすい形にする必要がある ▸ パワーポイントやExcelではなく、テキストベース（マークダウンなど） ▸ AIが頻繁に参照するものはプロジェクトのなかにドキュメントを含める（AGENT.mdやCLAUDE.md だけではない） ▸ 完成の定義、コーディング基準、ユビキタス辞書、アーキテクチャー概要…… ▸ テキスト化することでコンテキストを与えやすくなる ▸ バージョン管理は必須 ▸ AIによる試行は規模が大きくなりがち ▸ 間違えることも多いので、いつでも元の状態に戻せるようにする
21. コーディングスタイルとチーム編成
22. 生成AIでスクラムによる開発はどう変わるか AIによるコーディングのインパクト ▸ コードが素早く大量に生成できるようになった ▸ 開発者によるコーディングの並列作業の必然性が大きく低下 ▸ ボトルネックは、合意形成と品質確保に移る ▸ これらの要素が速度を決める ▸ チームは「速く書く」より「速く認識を揃える」ことに集中する ▸ モブ作業の合理性が向上 ▸ 品質を確保する仕組みがないと膨大なコードによって破綻する ▸ 自動テストを含めた安全装置の重要性が従来以上に高まる 22
23. 生成AIでスクラムによる開発はどう変わるか 従来のスタイル：並列コーディング ▸ 複数人が並列でコードを書き、それによって総量やスピードを稼ぐ ▸ チームが大きいほど総生産量は増える（ことを期待する）が、調整コストも増える ▸ 後で結合すると、整合性や品質で大きな問題が発生しがちだった ▸ しかし「書くのが遅い」前提だと、それなりに合理的な戦略のように見えた 23
24. 生成AIでスクラムによる開発はどう変わるか これからのスタイル：モブプログラミング ▸ 少人数で同じ画面を見ながら、仕様とコードとテストを同時に編集 ▸ AI生成の出力をその場で査読し、即座に修正と学習を回す ▸ 合意形成を同期的に行うことで、後戻りを劇的に減らす ▸ レビューが「事後の検査」から「リアルタイム作業」に変わる ▸ チームの学習も同期で進むため、新しいことに早くキャッチアップできる ▸ 個人のスピードより、集合知の質の効き目が大きくなる 24
25. 生成AIでスクラムによる開発はどう変わるか チームサイズの縮小傾向 ▸ 並列コーディングの必要が薄れ、小さなチームで回せるようになる ▸ そのまま大きなチームのままだと、問題が起こる ▸ モブが大人数化しても、効果は線形比例しない ▸ 同時並行で着手すると、マージで問題が起こる ▸ 小さなチームのほうがコミュニケーションコストが低く、合意形成が速く、待ち時間が少ない ▸ プロダクトを適切に分解する必要がある 25
26. 生成AIでスクラムによる開発はどう変わるか プロダクトをドメインなどで分割し、複数チーム化する ▸ 大規模チームでは依存関係が増えるため、ドメイン分割する ▸ 数人のチームでメンテナンス可能なサイズくらいが目安 ▸ そのチームが独立して価値を出せる構造を意図的に作る ▸ チームトポロジーとダイナミックリチーミングを参考にする ▸ イネイブリングチームやプラットフォームチームなどを作ることもある ▸ 開発速度が速くなったことに伴い、チーム構成が流動的になる可能性も（FAST） ▸ https://www.fastagile.io/ 26
27. スクラムの変化
28. 生成AIでスクラムによる開発はどう変わるか スプリント ▸ 実装が速くなるので、スプリント期間も短くなる傾向 ▸ いままでは1〜2週間スプリントが多かったが、1週間もしくは数日ということもありえる ▸ スプリント期間の短縮によって、論理的にはフィードバックサイクルが早まる ▸ 検査と適応を高頻度で実施できる ▸ ただしスプリントレビューでステークホルダーを集める頻度には限界がある ▸ そのためスプリントレビューのサイクルがスプリントと一致しなくなる可能性も ▸ 内部的には2-3日サイクルで回しつつ、レビューは2週間に1回にするなど 28
29. 生成AIでスクラムによる開発はどう変わるか スプリントプランニング ▸ いままではスプリントプランニングで詳細化をしていては遅かった ▸ スプリントプランニングが長時間化する ▸ 見切り発車で生煮えのプロダクトバックログアイテムを投入する ▸ 過小見積りして、スプリントに収まるサイズということにしてしまう ▸ だが、AIによってコーディングが早くなるので詳細化を遅らせても間に合うように ▸ スプリントプランニング中に詳細化する選択肢が取れるようになった ▸ その場でモブ的に詳細化すればよい ▸ タスク分解は合意形成のための最小限の範囲でよくなる 29
30. 生成AIでスクラムによる開発はどう変わるか スプリントゴールへの集中 ▸ スプリント期間が短くなるほど、明確なテーマが必要になる ▸ すなわちスプリントゴールが重要になる ▸ 明確なスプリントゴールがあると、明確なドキュメントが書けるようになる ▸ これによって集中が促進される ▸ スプリントゴールを達成できれば、すべてのプロダクトバックログアイテムを完成させる必要はない ▸ AIをコーディングに活用し早めにスプリントゴールを達成し、リスクを減らす ▸ とはいえ、スプリントゴールも仮説なので、結果的に外れることもある ▸ 開発が速くなったからこそ、不発の機能はどんどん捨てる 30
31. 生成AIでスクラムによる開発はどう変わるか プロダクトバックログアイテムの粒度と書き方が変わる ▸ 今までは以下を守る必要があった ▸ 1スプリントに入る大きさにする。 共通理解が重要で、ドキュメント化自体は重要ではない ▸ しかし…… ▸ AIで実装が速くなったため、大きめなプロダクトバックログアイテムを許容できる ▸ 一方で、AIに間違いなく作らせるためには、ドキュメントを十分に書く必要がある ▸ 受け入れ基準やテストケースを先に検討する ▸ プロダクトバックログアイテム自体をAIに生成させる手も有効 ▸ ただし確率論的なアプローチなので、網羅性を重視して余計なものを入れがち ▸ 人間がコントロールする必要がある ▸ 見積もる意味も減った（後述） 31
32. 生成AIでスクラムによる開発はどう変わるか プロダクトバックログアイテムの見積りの重要性の低下 ▸ 開発作業にかかる時間が大幅に減り、ボトルネックではなくなるため、見積り自体の重要性が低下 ▸ それに伴ってベロシティの必要性も減る ▸ もちろん、全体としての計画や進捗自体は重要 ▸ ロードマップなどで十分になる 32
33. 生成AIでスクラムによる開発はどう変わるか デイリースクラム ▸ スプリントゴール達成の可能性を最適化し、必要に応じて再計画するイベント ▸ スクラムガイド2017までは「3つの質問」がよく使われた ▸ だが、個人作業が減り、モブで作業するようになった ▸ 常にデイリースクラムをしている状態 ▸ 結果的にイベントとしての「デイリースクラム」の重要性が下がる 33
34. 生成AIでスクラムによる開発はどう変わるか 34 スプリントレビュー ▸ スプリントレビューではステークホルダーの参加がとてつもなく重要（それがないとスクラムが機能しない） ▸ これはAIの有無に関係ない ▸ しかしAIの登場でサイクルの高速化が進むと、ステークホルダーが「スプリントレビューに参加できる頻度や周 期」がボトルネックになる ▸ 誰をいつどんな頻度でどのようなスプリントゴールのときに招待するかを考える ▸ ステークホルダーは「AIを使っていることを前提とした」期待や懸念を表明する ▸ すぐにプロトタイプが欲しい…… ▸ AI時代の開発について、ステークホルダーと期待値調整が必要になるかも
35. 生成AIでスクラムによる開発はどう変わるか スプリントレトロスペクティブ ▸ 「AIの使い方を改善する」というトピックの重要性が増す ▸ つまりAIの使い方を頻繁に検査と適応する ▸ AI自体の進化が異常に早いので、頻繁に実施する必要がある ▸ 固定のトピックにしてもよいくらい ▸ アクションアイテムや新しいプロダクトバックログアイテムにAI関連の実験・調査が追加される ▸ スクラムチームは一定の時間を常に実験・検証・調査に費やす ▸ （そもそも改善をスプリントレトロスペクティブまで待つ必要もない） 35
36. 現場の課題
37. 生成AIでスクラムによる開発はどう変わるか 説明責任の問題 ▸ AIに責任を渡さない（渡せない）。決めるのは人にする ▸ なぜそうしたかをドキュメントで残す。あとでたどれるようにする ▸ 「AIがそう言ったから」は根拠にならない ▸ チームとして責任を担う ▸ 当然、AIにスクラムマスターを任せることはできない ▸ AI生成箇所を明示して検査可能にする ▸ すなわち、完成の定義に説明可能性と記録要件を入れる 37
38. 生成AIでスクラムによる開発はどう変わるか 品質のばらつきの問題 ▸ AIによる実装は、主に以下の要因によって品質がばらつく ▸ 何を入力するか ▸ 現状のコードがどうなっているか ▸ つまり、入力や現状のコードを高品質に保つことが何よりも重要 ▸ これらを無視すると、あっという間に崩壊する ▸ 定跡に沿ったアーキテクチャー、保守しやすいコード、誤解されない入力をチームで作る ▸ レビューやガイドライン、テンプレートなどの重要性が向上 ▸ 一方でAI自体の変化も激しいので、昨日の最善が今日の最善とは限らない ▸ 検査と適応を頻繁に 38
39. 生成AIでスクラムによる開発はどう変わるか 39 人材育成の問題 ▸ 良いアーキテクチャー、良いドキュメントを作れるようにするには、コーディングスキルが欠かせない ▸ だが、コーディングがAIによって行われるようになった結果、プロダクトの開発を通じて「コーディングスキルを養 う」機会が激減 ▸ 経験豊富なシニアによるレビューによって品質を担保するときに、「そのシニアをどう育てるか？」という問題が出現 する ▸ 短期的には問題にならないが、年単位で見ると大きな問題になる（焼畑農業に目をつぶらない） ▸ 組織として、コーディングスキルの獲得への投資が欠かせない ▸ 常に一定割合の時間をコーディングを始めとするスキルの獲得に使う枠組みを作る ▸ マネージャーが目先だけにこだわると、組織の持続性に害を及ぼす
40. まとめ
41. 生成AIでスクラムによる開発はどう変わるか まとめ ▸ AIで実装が速くなった世界を踏まえて、時間の使い方を見直す（並列作業の意味が減少） ▸ スプリントを短くして学習速度を上げる ▸ ドキュメントを「AIのインフラ」として扱う ▸ モブ化・小チーム化でアラインメントのコストを下げる ▸ スプリントゴールに集中し、寄り道をしない ▸ プロダクトバックログアイテムの粒度を「AI入力単位＋検査容易性」で設計する ▸ 見積りに時間をかける意味が減った。その分内容の合意に時間をかける ▸ スプリントレトロスペクティブでAI活用方法の改善を取り上げ、アクションを検討する ▸ 持続可能なアーキテクチャーにして、品質を維持する仕掛けを用意しておく ▸ 説明責任を人が担うこと / スプリントゴール中心 / 透明性・検査・適応の重要性は不変 ▸ 学習に投資し続ける 41
42. アトラクタのアジャイルコーチングで 持続的に成果を出し続けるアジャイルチームを作る 「あなたのゴールは、他人から押し付けられるアジャイルの行動規範に依存するのではなく、 自分たちで考えることのできる、生産的なアジャイルチームを育てることです」 書籍『アジャイルコーチング』（Rachel Davies、Liz Sedley 著、永瀬美穂、角征典 訳、オーム社、2017） なぜアジャイル開発では「コーチ」なのか 変化に気づき、対応するを養う 顧客志向の目的と行動様式を獲得する コーチの経験と知見の力を借りた素早い立ち上がり

Comment

No comments...