生成AIでスクラムによる開発はどう変わるか 2026年9月版

9/3に行ったAttractor Talks Reloaded #4での登壇資料です

スクラム

Yoshiba Ryutaro
2026/09/04 06:22
Scrum
38
22
Show Slide Vertically
Show Embedded Code

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でスクラムによる開発はどう変わるか 2026年9月版 2026/9/3 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でスクラムによる開発はどう変わるか 2026年夏版今日のテーマ ▸ 生成AIは検証段階ではなく、日常的に使うものになった ▸ 利用することがプラスなのではなく、利用しないことがマイナス ▸ ただし一律で「開発が速くなった」というわけでもない ▸ 組織による速度のばらつき、人によるばらつきが大きい ▸ 傾向としては、コードを書くのは「安く」「速く」なり、確認のコストが上昇（コスト構造が変化） ▸ コスト構造が変わると、スクラムの前提が変わる ▸ 時間の使い方 / 作業の進め方 / 品質維持の方法 / チーム構成 ▸ ということで、このような観点でスクラムの変化について見ていく 4

5. 生成AIでスクラムによる開発はどう変わるか 2026年夏版今日の話の範囲 ▸ 扱うこと：生成AIを「作る道具」として使うスクラムチームで、何が変化するか、何が起きるか ▸ 扱わないこと：AI機能を含むプロダクト自体を作る話 ▸ 前提：スクラムの基本的な用語とイベントは説明しない 5

6. 生成AIでスクラムによる開発はどう変わるか 6 スクラムの全体像（3-3-5）プロダクトバックログ完成の定義プロダクトの改善に必要なことを記載し並び替える。規模は開発者が見積もる。アイテムの追加は自由だが実施有無や順番はプロダクトオーナーが最終決定権限を持つ。スクラムチームの作業の唯一の情報源になる何をもって「完成」とするかを定義したリスト＝品質基準プロダクトバックログリファインメントプロダクトオーナーデイリースクラムこのまま進めてスプリントゴールが達成できるかを毎日最長15分間で検査し、必要に応じて今後の計画を調整する次回以降のスプリントに向けてプロダクトバックログアイテムを見直したり、上位のアイテムを着手可能な状態にしたりするスプリントプランニング開発者スプリント最大1か月までの固定の期間各スプリントの長さは同一で、作業が早く終わっても短縮せず、終わらなくても延長しない毎日の繰り返しスプリントバックログスプリントレビュースプリントゴールとその実現に向けて選択したプロダクトバックログアイテムと、実行計画の3つをあわせたものステークホルダーを招待し、スプリントで開発したインクリメントをデモしながらプロダクトの今後の適応を検討するスプリントレトロスペクティブ今回のスプリントでうまくいったこと、問題だったことを話し合った上で今後の改善計画を立案するスクラムマスタースクラムガイドで定義されたスクラムがきちんと実践され、チームが有効に機能することについて説明責任を持つ価値ある有用なインクリメント複数回スプリントを繰り返すそのスプリントでどんな価値を新たに生み出すか検討し(スプリントゴール)、それを実現するために必要なプロダクトバックログアイテムを選択し、実行計画を立案するプロダクトの価値を最大化することに説明責任を持ち、プロダクトバックログが適切に管理されていることに責任を持つ。スクラムチームに1人プロダクトの開発を行う。作業規模の評価を行う、完成の定義を守って品質を作り込む責任があり、スプリントゴールを確約するステークホルダープロダクトの利用者、出資者、管理職などの利害関係者。スプリントレビューに必要に応じて招待する

7. 生成AIでスクラムによる開発はどう変わるか 2026年夏版生成AIによってスクラムの実装のどこが変わってきているのか ▸ フレームワークの変化というよりは実装の変化（フレームワークは最小限で、全部やってスクラムなので） 7

8. 今までのスクラムの前提

9. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 9 スクラムで開発するときの一般的な時間配分（いままで）項目時間社内全体会議 1 事務手続き・報告・メール 2 研修 2 休暇 4 スクラムイベント 5 プロダクトバックログリファインメント 2 開発作業 24 合計 40 ▸ 開発時間をなるべく増やせるように、それ以外のことを削ろうとする ▸ （当たり前だが、1週間40時間をプロジェクトやプロダクトに使えるなんて思ってはいけない）

10. 生成AIでスクラムによる開発はどう変わるか 2026年夏版この配分は「実装が遅い」という前提によるものだった ▸ 実装にいちばん時間がかかる＝実装がスプリントの律速要因 ▸ 設計や計画の段階で「実装効率」を目指す／並列作業でスループットを最大化する ▸ タスク分解の粒度を「実装しやすさ」基準にする ▸ 「誰がどれだけ書けるか」に強い関心を持つ ▸ そのため、効率化のために長い時間をかけて見積りや分解を含めた準備をしていた ▸ スクラムの運用も、実装が遅くて高コストであることを前提に最適化されていた ▸ 生煮えのプロダクトバックログアイテムをスプリントに投入しない ▸ ベロシティを計測して、入り切らないアイテムを計画に含めない ▸ スプリントゴールが達成できそうかを毎日検査して再計画する ▸ 生成AIによって、この前提が崩れつつある 10

11. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 11 生成AIが標準ツール化 ▸ LLMベースの支援が実務レベルで利用可能になった ▸ 調査、実装、テスト支援、ドキュメント生成など ▸ 調査 ▸ ChatGPT、Gemini、Claudeなど ▸ 実装 ▸ GitHub Copilot、Claude Code、Cursorなど State of AI-assisted Software Development 2025, p.27, DORA ▸ プロトタイピングの高速化 ▸ コーディングにかかる時間が大幅に短縮されることも ▸ もはや標準ツール。調査回答者の大多数が業務で使い、多くが生産性向上を実感しているとされている ※ DORA: DevOps Research and Assessment。2018年からGoogle Cloud傘下。開発組織の年次調査とDORAメトリクスで知られる

12. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 12 一方で、体感と実測結果が一致していない（まだゆらぎがある） ▸ ランダム化比較試験（16人。同一人物においてタスクごとにAI利用の有無をランダム化）を実施（METR、 Model Evaluation & Threat Research、2025/2〜6。2026/2から再実験を検討中） ▸ AI使用不可のタスクに比べて、AI使用可能なタスクの完了時間は19%遅くなった ▸ にもかかわらず、本人たちは20%速くなったと感じていた ▸ ヘビーユーザーの産出量は非利用者の4〜10倍。だが差の大部分はAI以前から存在していた（GitClear、 2026/1） ▸ 過去の自分と比べた速度向上は25%程度 ▸ 効果は新規コードでは大きく、レガシーへの変更では小さい（スタンフォード大学での研究、2025） ▸ 「生成AIで何倍速くなる」といった単純な話ではなさそう ▸ ただし時間の使い方には大きな変化

13. 生成AIでスクラムによる開発はどう変わるか 2026年夏版変わったのは速度ではなくコスト構造 ▸ 減ったもの ▸ 技術的な調査の時間 ▸ コードを書く行為そのものの時間 ▸ 増えたもの ▸ AIから望む結果を得るための事前作業の時間（何を伝えるか） ▸ AIの出力を検証するための事後作業の時間（何を確かめるか、検証税とも言える） ▸ 全体として劇的に時間が減ったというより、時間を使う場所が移動 ▸ 実装より、事前準備と事後検証で詰まりやすくなった（実装作業自体の前後に移動） ▸ この変化がスクラムの各要素に影響する 13

14. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 14 スクラムの時間配分の変化（今こんな感じのチームが増えつつある）項目時間社内全体会議 1 事務手続き・報告・メール 2 学習・実験・研修（+2） 4 休暇 4 スクラムイベント 5 仕様の記述、リファインメント（+3） 5 実装（AIへの指示も含む） 9 レビュー・検証（+10） 10 合計 40 ▸ いままでの開発時間が仕様記述、実装、検証の3つに分かれる ▸ いちばん大きいのが「レビュー・検証」になる ▸ 学習の量が増える ▸ この数字は例。自分たちの実績を計測すること

15. ドキュメントへの投資

16. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 AIによるコーディングの制約 ▸ AIは「考えを想像」してくれない（人間はある程度想像してくれる。忖度？） ▸ コンテキストを正しく「伝える」必要がある ▸ 当然ながら、暗黙知のままでは伝わらないので、知識をテキスト化しなければいけない ▸ プロンプトでの試行錯誤はテキストが消失してしまう ▸ その結果、以前よりドキュメントを書く意味が大きくなった ▸ 従来は、「共通理解」に至れば、ドキュメントの多寡はあまり問題ではなかった ▸ 「包括的なドキュメントよりも動くソフトウェアを」（Manifesto for Agile Software Development） ▸ ここで書くドキュメントの目的は網羅ではなく、検証にかかる時間を下げるために書く 16

17. 生成AIでスクラムによる開発はどう変わるか 2026年夏版投資先のシフト ▸ プロンプトを繰り返すのは非効率 ▸ 最初に良いドキュメントを作るほうが効率的 ▸ チームでのドキュメント整備が重要になる ▸ そこで検査と適応を繰り返して改善していく ▸ スプリントレトロスペクティブなどで扱うテーマになる ▸ チームとしての取り組み ▸ 共通テンプレートや書き方のガイド ▸ モブでのドキュメント作成やレビュー ▸ ドキュメントの再利用性や検索性の向上 ▸ 良いドキュメントを書けることが競争力に直結する 17

18. 生成AIでスクラムによる開発はどう変わるか 2026年夏版どのドキュメントから投資するか（効果が高いものからやるべき） ▸ まず書く（AIの出力品質に直接影響する） ▸ 完成の定義（品質基準）／コーディング規約 ▸ 用語集・ドメインモデル（用語がぶれると出力もぶれる） ▸ アーキテクチャーの概要と「やってはいけないこと」 ▸ 直近のプロダクトバックログアイテムの受け入れ基準とテストケース ▸ 次に書く（頻繁に参照されるもの） ▸ API/スキーマ仕様／テスト戦略／デプロイ・運用手順 ▸ 会議の議事録、決定に至らなかった議論、参照されない設計文書などは後回しでよい ▸ 迷ったら「これはAIと人間のどちらが何回読むか」で判断する 18

19. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 AIに渡すためのドキュメント化 ▸ 誤解しにくいドキュメントが必須 ▸ 前提が不足していたり、曖昧な単語を使ったりすると出力の質が下がったり、試行回数が増えたりする ▸ コツ ▸ 前提条件・入力・出力を具体化する ▸ 例と反例を示す（Speci cation by Example） ▸ 参照先（設計・コード・テスト）を紐付ける ▸ 用語の一貫性を保つ。用語の定義を明記する ▸ 「AIに食わせるドキュメント」としての品質が重要 fi ▸ 逆に言うと「ゴミを入れるとゴミが出る」 19

20. 生成AIでスクラムによる開発はどう変わるか 2026年夏版コンテキストにあわせる ▸ 「マークダウンで書く」「バージョン管理する」は当たり前 ▸ 常に読ませるものと都度参照させるものを分ける ▸ 常時：完成の定義、コーディング規約、用語集、アーキテクチャー概要 ▸ 都度：個別の仕様、過去の決定の経緯、運用手順 ▸ 常時読ませるファイルが肥大化すると、内容を飛ばしたり、ルールを守らなくなる ▸ AGENTS.md / CLAUDE.md に全部足していくと劣化する ▸ 定期的に切り出したり削ったりする。スプリントレトロスペクティブの議題にする、PBI化する ▸ バージョン管理は必須 ▸ AIによる試行は規模が大きくなりがちで、間違いも多い。いつでも戻せるようにする 20

21. 急いでたくさん作る悪癖への対処

22. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 22 エージェントを並列に走らせるやり方をよくみかけるけど…… ▸ エージェントの自律度の向上 ▸ エージェントの平均セッション長が2025 Q1の4分から2026 Q1の23分へ。1セッションあたり平均47回のツール呼び出し（Anthropic「2026 Agentic Coding Trends Report」） ▸ 開発者の待ち時間が増えるのを避けるために、1人が複数のエージェントを同時に走らせる現場も…… ▸ worktreeやブランチで作業を隔離し、差分レビューとマージを人間が握る ▸ 手元で対話するもの、バックグラウンドで走らせるもの、クラウドに投げてPRを受け取るものを使い分ける ▸ いままでは開発者の数だけ並列化していたチームが、「開発者数 x エージェント数」で並列化できなくもない ▸ ただし、「並列作業できるからといって、それをするかは別の問題」

23. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 23 問い「なぜ急いでたくさん作ろうとするのか」 ▸ 並列化の議論は「何本走らせられるか」が多いが、そもそも「完成しなければ無意味」 ▸ スクラムの制約は産出量ではなく、仮説を検証できる速度 ▸ スプリントゴールは仮説なので、それが本当にプロダクトゴールに寄与するかは検証が必要 ▸ 検証待ちを増やしても無意味 ▸ 「急いでたくさん」が正当化できるのは、作るものが正しいと事前にわかっているときだけ（あるのか？） ▸ そこまで確信があるなら、そもそも反復して進める必要がない ▸ 並列化できるからといって、並列化する理由にはならない ▸ 「なぜ並列にするのか」「なぜ急ぐのか」「急ぐことが正しいのか」を合意する必要

24. 生成AIでスクラムによる開発はどう変わるか 2026年夏版そもそも並列にできない構造も多い ▸ worktreeが隔離するのは作業ディレクトリであって設計ではない ▸ 同時に触るとよく壊れるもの ▸ 共有モジュール、DBマイグレーション、スキーマ定義、生成ファイル、ロックファイル、設定 ▸ コンフリクトはテキストではなく意味で起きる ▸ マージは成功しても挙動が壊れることはある。バージョン管理は何も教えてくれない ▸ 自動テストが薄いコードベースでは、破壊が検出されない ▸ 並列度はモジュール境界の質で決まる ▸ つまりアーキテクチャーが適切かどうか ▸ 巨大なモノリス、複雑な設計、陳腐な設計が重荷になってくる 24

25. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 25 レビューが追いつかない ▸ レビューにある程度の時間が必要な場合、並列度にはおのずと限界がある ▸ 実装時間が減ると、リードタイムの大部分がレビュー待ちになる（レビュー待ちは仕掛りなので負債） ▸ レビューの量が多いほど、レビューの質が落ちる ▸ たくさんのレビューをする人が、ずっと同じ質を維持して読み続けるのは無理 ▸ 対処方法は「人間が見る範囲を決めること」 ▸ 機械に任せる：形式・規約・カバレッジ・依存関係・脆弱性 ▸ 人間が見る：意図との一致、アーキテクチャーの整合性、境界の設計、…… ▸ 線引きは完成の定義に書き、適宜更新していく

26. 生成AIでスクラムによる開発はどう変わるか 2026年夏版モブプログラミングの有効性 ▸ 少人数で同じ画面を見ながら、仕様とコードとテストを同時に編集する ▸ 意思決定は同期（何を作るか、何を受け入れるかは全員で同時に決める） ▸ 合意形成を同期的に行うことで、後戻りを大きく減らす ▸ レビューが「事後の検査」から「リアルタイム作業」に変わる ▸ 実行は非同期にできるが、検証できる数が並列の上限 ▸ ツールの上限ではない ▸ チームの学習も同期で進むので、新しいことに早くキャッチアップできる ▸ 個人のスピードより、チームの集合知の効き目が大きくなる 26

27. 生成AIでスクラムによる開発はどう変わるか 2026年夏版チームサイズの縮小傾向 ▸ 大きなチームのままだと、問題が起こる ▸ モブが大人数化しても、効果は線形比例しない ▸ 同時並行で着手すると、マージで問題が起こる ▸ 小さなチームのほうがコミュニケーションコストが低く、合意形成が速く、待ち時間が少ない ▸ ただし、小さくすればレビュー可能な量も小さくなる ▸ 「人を減らしてAIで補う」ではなく「意思決定の速度に合わせてチームのサイズを決める」 ▸ プロダクトを適切に分解する必要がある 27

28. 生成AIでスクラムによる開発はどう変わるか 2026年夏版プロダクトをドメインなどで分割し、複数チーム化する ▸ 大規模チームでは依存関係が増えるため、ドメイン分割する ▸ 数人のチームでメンテナンス可能なサイズくらいが目安 ▸ そのチームが独立して価値を出せる構造を意図的に作る ▸ チームトポロジーとダイナミックリチーミングを参考にする ▸ イネイブリングチームやプラットフォームチームなどを作ることもある ▸ 開発速度が速くなったことに伴い、チーム構成が流動的になる可能性も（FAST） ▸ https://www.fastagile.io/ 28

29. スクラムの要素はどう変わるか

30. 生成AIでスクラムによる開発はどう変わるか 2026年夏版スプリント ▸ 実装自体が速くなるので、スプリント期間も短くなる傾向 ▸ いままでは1〜2週間スプリントが多かったが、1週間もしくは数日ということもありえる ▸ もちろんチーム内部のレビューや検証にかかる時間に依存する ▸ スプリント期間の短縮によって、論理的にはフィードバックサイクルも短縮する（はず） ▸ 検査と適応を高頻度で実施できる ▸ ただしスプリントレビューでステークホルダーを集める頻度には限界がある ▸ そのためスプリントレビューのサイクルがスプリントと一致しなくなる可能性も ▸ 内部的には2-3日サイクルで回しつつ、スプリントレビューのリズムは維持するなどの対応も ▸ スプリント期間を短くするほど、1スプリントで行える判断の量は減る 30

31. 生成AIでスクラムによる開発はどう変わるか 2026年夏版プロダクトバックログリファインメント ▸ プロダクトバックログアイテムを詳細化し、AIに渡せる程度の粒度・詳細度にする ▸ 何をAIに渡すかで出力が決まるので、チームで議論しながらモブで記述するのが理想 ▸ 直近取り組みそうなアイテムをAI Readyにする ▸ スプリントプランニングでも十分間に合うようになれば、タイミングを遅らせる ▸ 事前作業の重要性が増して、リファインメントが開発の重要な作業になる ▸ 「余った時間でやる会議」みたいに捉えられがちだったが、ここをちゃんとやらないと地獄 31

32. 生成AIでスクラムによる開発はどう変わるか 2026年夏版スプリントプランニング ▸ いままではスプリントプランニングで詳細化をしていては遅かった ▸ スプリントプランニングが長時間化する ▸ 見切り発車で生煮えのプロダクトバックログアイテムを投入する ▸ 過小見積りして、スプリントに収まるサイズということにしてしまう ▸ だが、AIによってコーディングが早くなるので詳細化を遅らせても間に合うものも増えた（全部ではない！） ▸ スプリントプランニング中に詳細化する選択肢が取れるようになった ▸ その場でモブ的に詳細化すればよい ▸ タスク分解は合意形成のための最小限の範囲でよくなった ▸ 実装のための分解は必要性が低下（Jiraに細かいタスクを切るなんてことも不要に） 32

33. 生成AIでスクラムによる開発はどう変わるか 2026年夏版スプリントゴールへの集中 ▸ スプリント期間が短くなるほど、明確なテーマ（=スプリントゴール）が必要になる ▸ スプリントゴールが明確だと、明確なドキュメントが書けるようになる ▸ これによって集中が促進される ▸ スプリントゴールを達成できれば、すべてのプロダクトバックログアイテムを完成させる必要はない ▸ AIをコーディングに活用し早めにスプリントゴールを達成し、リスクを減らす ▸ とはいえ、スプリントゴールも仮説なので、結果的に外れることもある ▸ 開発が速くなったからこそ、不発の機能はどんどん捨てる 33

34. 生成AIでスクラムによる開発はどう変わるか 2026年夏版プロダクトバックログアイテムの粒度と書き方が変わる ▸ 「1スプリントに入る大きさにする」という原則自体は不変 ▸ AIで実装が速くなったため、大きめなプロダクトバックログアイテムでも1スプリントで完成できる ▸ 作業規模よりも1スプリントで判断、意思決定できる大きさが制約になることが増えた ▸ AIに人間の意図通りに作らせるには、ドキュメントを十分に書く必要がある ▸ 以前は、共通理解が重要で、ドキュメント化自体は重要ではなかった ▸ 受け入れ基準やテストケースを先に検討する ▸ プロダクトバックログアイテム自体をAIに生成させる手も有効 ▸ ただし確率論的なアプローチなので、網羅性を重視して余計なものを入れがち ▸ 人間がコントロールする必要がある 34

35. 生成AIでスクラムによる開発はどう変わるか 2026年夏版見積りの対象が変わる ▸ 開発作業にかかる時間が大幅に減り、ボトルネックではなくなるため、工数の見積りの重要性が低下 ▸ 実装が律速要因でなくなったので、そこを精緻に見積もる意味が薄い ▸ ベロシティの必要性も減る ▸ 一方で、見積もる価値が上がったものがある ▸ レビューと検証の負荷／検証にかかる不確実性 ▸ 不確実性が高い箇所を見積もらないと計画は当たらない ▸ 「実装工数の見積り」と「リリース時期の予測」は分けて考える ▸ 予測は依然として必要。ロードマップなどで十分な場合が多い ▸ アイテムを大きくするとばらつきは増えるので、予測はむしろ難しくなる 35

36. 生成AIでスクラムによる開発はどう変わるか 2026年夏版デイリースクラム ▸ スプリントゴール達成の可能性を最適化するイベントであることは変わらない ▸ スクラムガイド2017までは「3つの質問」がよく使われたが、個人に関心はない ▸ モブで作業していれば、常にデイリースクラムをしている状態になる ▸ ただし、エージェントが非同期・バックグラウンドで動き、変化が速いので同期点の必要性は上がる ▸ 適応対象が今後の作業計画であることは変わらないが、レビューがテーマになりやすい ▸ AIを使っていても、スプリントゴールを確約するのは開発者自身 ▸ 毎日検査することで、エージェントに仕事をさせていても、開発者が現状を説明できる状態を維持する ▸ ＝説明責任からは逃れられない 36

37. 生成AIでスクラムによる開発はどう変わるか 2026年夏版スプリントレビュー ▸ インクリメントを検査して適応するイベントであることは変わらない ▸ ステークホルダーの参加がないとスクラムが機能しない。これはAIの有無に関係ない ▸ サイクルの高速化が進むと、ステークホルダーが参加できる頻度がボトルネックになる ▸ 誰をいつどんな頻度で、どのようなスプリントゴールのときに招待するかを考える ▸ ステークホルダーは「AIを使っていることを前提とした」期待や懸念を表明する ▸ すぐにプロトタイプが欲しい……／品質は大丈夫なのか…… ▸ ステークホルダーと期待値調整が必要になる 37

38. 生成AIでスクラムによる開発はどう変わるか 2026年夏版スプリントレトロスペクティブ ▸ 「AIの使い方を改善する」というトピックの重要性が増す ▸ AI自体の進化が異常に早いので、頻繁に検査と適応する必要がある ▸ 固定のトピックにしてもよいくらい ▸ 具体的な議題の例 ▸ 常時読ませているドキュメントは効いているか。削るべきものはないか ▸ 並列数は適切か。レビュー待ちは溜まっていないか ▸ アクションアイテムや新しいアイテムにAI関連の実験・調査が追加される ▸ スクラムチームは一定の時間を常に実験・検証・調査に費やす ▸ （そもそも改善をスプリントレトロスペクティブまで待つ必要もない） 38

39. いま起きている問題

40. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 40 コードを読まないという選択肢 ▸ 実装コードを一切読まない例も登場 ▸ テスト・型・lint・メトリクス・別モデルのレビューで問題を検知する仕組みを作る ▸ そういう完成の定義でよいという合意が前提 ▸ 他にも複数の前提が必要：静的解析が効く言語、新規、少人数、自分たちのプロダクト、問題があったときのリスクを許容できること ▸ とはいえ、現実的に説明責任を果たす上では難しい選択 ▸ この手の話は、組織やプロダクトによって違うので、鵜呑みにしない

41. 生成AIでスクラムによる開発はどう変わるか 2026年夏版説明責任の問題 ▸ AIに責任を渡さない（渡せない）。最終的に決めるのは人間 ▸ なぜそうしたかをドキュメントで残す。あとでたどれるようにする ▸ 「AIがそう言ったから」は根拠にならない ▸ スクラムチームとして説明責任を担う。AIは説明責任を果たさない ▸ 当然、AIにスクラムマスターを任せることはできない ▸ 「完成」を表明するのはスクラムチーム ▸ 何を記録するか、何を機械で確認するか、何を人が確認するかを完成の定義に入れる ▸ 「AI and Scrum」（Scrum Guide Expansion Pack, 2026/1）も参照 ▸ 経験主義・透明性・人間の説明責任を保ったままAIを使うという立場 41

42. 生成AIでスクラムによる開発はどう変わるか 2026年夏版品質のばらつきの問題 ▸ AIによる実装の品質は、主に2つの要因でばらつく ▸ 何を入力するか／現状のコードがどうなっているか ▸ = 入力と既存コードを高品質に保つことが何よりも重要 ▸ 定跡に沿ったアーキテクチャー、保守しやすいコード、誤解されない入力をチームで作る ▸ Lintなどで厳しいルールを採用しても、AIであれば文句を言わずに実装できる ▸ GitClearの調査では、品質問題の兆候が見えつつある ▸ 重複コードブロックは増え続け、2023年比で8割増（2026年） ▸ 例外を握り潰すcatchのような、エラーを隠す構造が47%増 ▸ AI利用の増加とデリバリーの不安定性の増加には相関がある ▸ AI自体の変化も激しいので、昨日の最善が今日の最善とは限らない。検査と適応を頻繁にやるしかない 42

43. 生成AIでスクラムによる開発はどう変わるか 2026年夏版 43 人材育成の問題 ▸ 良いアーキテクチャー、良いドキュメントを作るには、コーディングスキルが不可欠（だと思う） ▸ だが、コーディングがAIで行われるようになった結果、プロダクト開発を通じてスキルを養う機会が激減 ▸ 書く機会だけでなく、既存コードを読み直す機会も減っている ▸ シニアのレビューで品質を担保するなら、「そのシニアをどう育てるか」という問題が出現する ▸ 短期的には問題にならないが、年単位で見ると大きな問題になる（焼畑農業に目をつぶらない） ▸ 組織として、スキル獲得への投資が欠かせない ▸ 一定割合の時間を確保する仕組みを作る ▸ レビューを育成の場として設計する。読む訓練を意図的に入れる ▸ マネージャーが目先だけにこだわると、組織の持続性に悪影響を及ぼす

44. 生成AIでスクラムによる開発はどう変わるか 2026年夏版測り方を間違えるとすべて壊れる ▸ やってはいけない測り方 ▸ トークン消費量やAI利用率を社内で競わせる（使うこと自体が目的化する） ▸ 生成行数・PR数・コミット数を成果とみなす（安くなったものを数えても意味がない） ▸ 見るべきもの ▸ リードタイム（レビュー待ちを含む）／変更失敗率／デプロイ後の手戻り率 ▸ マージ後すぐに書き換えられたコードの割合 ▸ 生成AIの導入直後に数字が悪化するのはよくあること ▸ 新しいものを導入したときにいきなり成果はでない（J字カーブ（DORA、2026/4）） ▸ 学習曲線、検証税、パイプライン適応 44

45. 生成AIでスクラムによる開発はどう変わるか 2026年夏版（再掲）生成AIによってスクラムの実装のどこが変わってきているのか ▸ フレームワークの変化というよりは実装の変化（フレームワークは最小限で、全部やってスクラムなので） 45

46. まとめ

47. 生成AIでスクラムによる開発はどう変わるか 2026年夏版まとめ ▸ コードを書く時間は減ったが、レビューや検証に使う時間は増えている ▸ その変化に合わせて、チームの時間配分も見直す ▸ ドキュメントはたくさん書けばよいわけではない。AIと人が何度も使うものから書く ▸ エージェントをたくさん並列実行できても、それだけで開発が速くなるわけではない ▸ 人間が確認できる量を超えて作らない ▸ スプリントを短くできるなら、早く作るためではなく早く確かめるために使う ▸ 実装工数より、レビューや検証にどれくらいかかるかを見る ▸ AIが扱いやすいコードとアーキテクチャーを維持する ▸ AIを使っても、人を育てるための時間は意図的に確保する 47

48. 生成AIでスクラムによる開発はどう変わるか 2026年夏版変わらないもの ▸ 説明責任を人が担うこと ▸ スプリントゴールを中心に置くこと ▸ 透明性・検査・適応 ▸ 経験主義：やって得られた事実を踏まえて、次にどうするかを決める 48

Comment

No comments...