AIコーディングエージェントの進化によって、ソフトウェア開発の前提が大きく変わり始めています。特に、これまでデリバリーの中で大きな時間を占めていたコーディングや単体テストは、AIによって大幅に高速化・自動化されつつあります。
では、AIエージェント時代にスクラムはどう変わるのでしょうか。
以下、スクラムイベントを中心に考えてみます。
スプリント
スプリント周期は、従来週単位で決められることが多かったのですが、AIによってコーディングの時間が劇的に短縮されるなら、その必要性は薄れていきます。場合によっては、1日単位でも価値のあるインクリメントを作れるようになるでしょう。
つまりこれは、開発のサイクルタイムが大幅に短くなるということです。
ですが、スクラムの価値は、決められた期間で作業を管理することではなく、短いサイクルで成果を作り、フィードバックから学ぶことにあります。
同じゴールに向かって取り組み、その結果を一緒に確認することで、チームの中に共通理解が育ちます。AI時代のスプリントは、作業を詰め込む単位ではなく、チームが同じ学習サイクルを共有する単位として、より短く、より濃いものになっていくと考えています。
以下、具体的に見ていきます。
プロダクトバックログリファインメント
AI利用で重要性が増すと言われるのが、人間の「意図」です。そして、その意図を扱う最も重要な場が、プロダクトバックログリファインメントです。もっとも、これはAI時代になって急に重要になったわけではなく、もともと重要だったものですが。
プロダクトバックログの優先順位は、依然として人間の意図に基づく判断です。顧客価値、事業戦略上の狙い、学習したいこと、リスクの大きさなどを踏まえて、何から取り組むのかを決める必要があります。ここはAIに丸投げできません。
一方で、情報収集や整理という面では、AIはプロダクトオーナーやチームの強い味方になります。ユーザーストーリーの分割、受け入れ条件の整理、代替案の洗い出し、リスクの指摘などは、AIによってかなり楽になるでしょう。
ペルソナ、ビジョン、プロダクトゴール、顧客の状況、技術的制約などのコンテキストを適切に与えれば、AIはいわゆるINVEST※に近い形でプロダクトバックログアイテムを分割することもできます。
ただし、リファインメントの本質は、AIにバックログを整理させることではありません。顧客、ステークホルダー、プロダクトオーナー、開発者が同じ対象を見ながら、顧客がどんな問題を解決したいのか、何が価値につながるのか、を見つけ出すことです。
AIが作った分割案や受け入れ条件は、その共同作業の材料になります。しかし、そこから違和感を見つけ、仮説を立て、顧客にとって本当に意味のあるものを探っていくのは人間です。リファインメントは、プロダクトに対する共通理解を作りながら、顧客が本当に欲しいものを見つけ出す場なのです。
完成の定義
AI時代には、「完成の定義」の扱いも変わっていくと考えています。
ここで重要なのは、完成の定義がそのままプロダクトコードの完成条件として使われるというよりも、AIエージェントを安全に動かすためのガードレール、つまりハーネスの完成の定義へと移っていくのではないか、ということです。
従来、完成の定義には、テスト、レビュー、ドキュメント、セキュリティ、運用性などの確認事項が書かれていました。しかし、AIエージェントがコーディングや単体テストの多くを担うようになると、人間が毎回プロダクトコードを直接確認するのではなく、AIが参照し、実行し、検証するためのハーネスを整えることが重要になります。
このハーネスには、テストコード、静的解析、設計ルール、レビュー観点、制約条件、禁止事項、実行手順などが含まれます。開発者は、AIが作業するための環境と検証の仕組みを用意し、そのハーネスが十分に機能するかを確認する必要があります。
したがって、完成の定義は、プロダクトコードそのものの完成条件というより、AIに作業を任せるためのハーネスが完成しているかを判断する基準へと重心が移っていくでしょう。ここは主に開発者が責任を持つ領域です。開発者同士が、どの品質を機械的に検証し、どこを人間が確認し、どの状態ならAIに任せられるのかについて共通理解を持つ必要があります。
見積もり
リファインメントでよく行う「見積もり」は、その重要性が低下すると考えています。
これまでも見積もりは、単に作業量や所要時間を予測するためだけのものではありませんでした。開発者同士が認識の違いを見つけ、難しさを共有し、どう作るかについて共通理解を形成するための重要なプラクティスでもありました。
しかし、コーディングの大部分をAIが担うようになると、開発者同士が以前ほど密接に協力しながらコードを書く必要は下がる可能性があります。ペアプログラミングやモブプログラミングのように、人間同士がコードレベルで協調する場面はかなり減少するでしょう。
そうなると、見積もりを通じて開発者間の共通理解を作る必要性も、相対的に低下します。もちろん、共通理解そのものが不要になるわけではありません。ただ、その中心は「この実装は何ポイントか」ではなく、「何を学びたいのか」「どこに不確実性があるのか」「どこで人間の判断が必要なのか」へ移っていくはずです。
さらに、スプリントが1日以下程度まで短縮するなら、そもそも見積もる必要も小さくなります。今日一日のことなら、見積もりに時間をかけるよりも、すぐに作って、すぐに確認した方が早い場面が増えるでしょう。優先順位判断のためにサイズ感が必要なら、それこそAIに支援させればよいと考えています。
スプリントプランニング
スプリントプランニングでは、人間の意図としてのスプリントゴールは依然として重要です。AIが速く実装できるようになっても、「このスプリントで何を達成したいのか」は人間が決める必要があります。
一方で、スプリントが短くなるほど、スプリントのスコープを細かく決める必要性は下がります。1日単位の短いスプリントであれば、変化を検知して方向修正する頻度は十分に高くなります。少なくとも週次スプリントよりは、変化への追従性が大きく上がるでしょう。
また、これまでプランニングでは、開発者全員である程度の設計を行い、各PBIの作り方について共通理解を形成し、開発に必要なタスクを洗い出していました。これもAIがかなり代替できるようになります。
その代わりに重要になるのが、ハーネスやループの設計です。どのAIに何を任せるのか。どのテストや制約を使うのか。どこで人間が確認するのか。これらはPBIごとに調整が必要です。
これからのプランニングは、コードを書く人間の作業設計から、AIの使い方の設計について、開発者全員が共通理解を持つ場になっていくでしょう。
デイリースクラム
1日スプリントが現実的になるなら、従来型のデイリースクラムは不要になるかもしれません。
もともとデイリースクラムは、スプリントゴールに向けた進捗を確認し、必要に応じて計画を調整するためのイベントです。しかし、計画が1日分であれば、その意味は極めて小さくなります。
それより重要になるのは、開発中に気づいた問題をリアルタイムに共有することです。AIが意図と違う実装をした。ハーネスに漏れがあった。前提として与えた情報が古かった。顧客に確認しないと判断できない論点が出てきた。こうした問題は、その場で共有した方がよいでしょう。
スプリントレビュー
AI時代に最も重要になるスクラムイベントは、スプリントレビューかもしれません。
実装が速くなっても、プロダクトの方向性が正しいかどうかはAIには決められません。顧客にとって価値があるのか。業務の現場で使えるのか。事業上の戦略に合っているのか。次に何を学ぶべきなのか。
これらは、顧客やステークホルダーとの共同作業を通じて判断する必要があります。
毎日スプリントを行う意味は、毎日作業することではありません。毎日フィードバックを得て、プロダクトの方向性を変えられることにあります。もしそこに顧客やステークホルダーが参加しないなら、1日スプリントの意味は大幅に減少してしまいます。
スプリントレビューは、単なる成果報告ではありません。顧客、ステークホルダー、チームが同じインクリメントを見て、会話し、実際の使い方や価値を発見し、次に何を試すかを決める場です。AIによって実装速度が上がるほど、この共通理解の更新頻度と質が重要になります。
スプリントレトロスペクティブ
スプリントが短くなると、レトロスペクティブの扱いも見直す必要があります。
1日スプリントだからといって、毎日きっちりレトロスペクティブを行う必要はないでしょう。毎日KPTを出し、原因を掘り下げ、改善策を決めるのは、1日スプリントの中ではオーバーヘッドが大きすぎます。
ただし、人間のプロセスを改善する場としてのレトロスペクティブは、引き続き重要です。
AIを使うようになると、チームの協働の形も変わります。誰がAIに指示を出すのか。AIの出力を誰が確認するのか。判断が一部の人に偏っていないか。開発者同士の会話が減りすぎて、共通理解が弱くなっていないか。速く作れるようになったことで、顧客やPOとの確認が雑になっていないか。
こうした問題は、ツールやハーネスだけを見ていてもわかりません。人間同士の関わり方、意思決定の仕方、責任の持ち方を振り返る必要があります。
レトロスペクティブは、チームの働き方について共通理解を作り直す場です。AI時代には、毎日行う定例イベントというより、一定期間ごとに人間の協働プロセスを見直す場になっていくのではないでしょうか。
スクラムはKanbanに近づくのか
ここまで考えると、AI時代のスクラムはKanbanに近づいていくようにも見えます。リファインメントとプランニングを一体化し、プロセス改善はリアルタイムで行い、顧客やステークホルダーにはスプリント以外の周期でデモをする。形式的なイベントの必要性は低下していきそうです。
ただし、WIPをモニターし、制御しながらフローを改善するには、それなりの経験が必要です。何を制限するのか、ボトルネックはどこにあるのか、誰がどの判断をするのか。バックログ管理の難易度も上がります。経験の浅いチームがいきなりやると、単にダラダラした行き当たりばったりの開発になりかねません。
その意味で、スクラムのようなフレームワークは、これからも有効な入り口になります。スプリント、プランニング、レビュー、レトロスペクティブといった枠組みは、チームが学習サイクルと共通理解を持つための足場になります。
ただし、Scrumの運用もアップデートしないと、今のままでは時代遅れになる危険をはらんでいます。AIによって開発の前提が変わるなら、スクラムの使い方も更新しなければなりません。
ボトルネックは、デリバリーからディスカバリーへ移る
現在のスクラムは、主にデリバリー領域を扱っています。作るべきものを決めた後、それを短いサイクルで作り、確認し、改善するための枠組みです。なぜそうなったかというと、おそらくそれは、ソフトウェア開発における最大のボトルネックがデリバリー領域だったからでしょう。
しかし、AIによってデリバリーが高速化すると、相対的に遅くなるのはその上流にあるディスカバリー領域です。
何が顧客にとって本当に価値があるのか。どの問題を解決すべきなのか。どの仮説を先に検証すべきなのか。ここは、まだAIに丸投げできる領域ではありません。顧客やステークホルダーとの対話、観察、共同作業が必要です。
一方で、AIはディスカバリーも強力に支援します。大量の顧客フィードバックを整理する。インタビュー記録から論点を抽出する。競合情報を比較する。仮説を複数案に展開する。こうした作業はAIで高速化できます。
分析が高速化できるということは、大量の情報を扱えるということでもあります。したがって、AIはディスカバリーのスピードだけでなく、質そのものを高める可能性があります。
ただし、情報が整理されても、それだけで共通理解が生まれるわけではありません。顧客やステークホルダーと一緒に何を見て、何を学び、何を次に試すのかを確認する必要があります。
AI時代のボトルネックは、「作ること」から「何を作るべきかを見つけ出すこと」へ移ります。スクラムを更新するなら、この変化を避けて通ることはできません。
AIエージェント時代のスクラムは、一段メタな活動へ移る
AIエージェント時代のスクラムでは、プロダクトバックログリファインメントやスプリントレビューの重要性が高まります。実装の自動化が進むほど、プログラミングはコモディティ化し、「どう作るか」よりも「なぜ作るか」「何を学ぶか」「次に何を試すか」が重要になるからです。
これは、スクラムが単に開発者の作業を管理する枠組みでは足りなくなる、ということでもあります。AIエージェントによってデリバリーが高速化するほど、ボトルネックは「作ること」ではなく、「何を作るべきかを見つけ出すこと」に移っていきます。そうなると、スクラムはデリバリーの内側だけに閉じるのではなく、顧客理解、仮説検証、価値探索といったディスカバリー領域も巻き込んでいく必要があるのではないでしょうか。
※INVEST：ユーザーストーリーの理想的な状態を示す考え方。Independent、Negotiable、Valuable、Estimatable、Small、Testableの頭文字を取ったもの。
