こんにちは、木本です。 先日スクラムフェス福岡に参加しましたので、今回はそのレポートと、生成AI時代のスクラム（特にスプリント）について考えたことを書きます。
実は昨年7月にScrum Allianceの「認定スクラムマスター(CSM)」に合格したのですが、その後なかなかスクラム関連のイベント等に参加できておらず、今回が「スクラム」イベント初参加となります。 ただ、申込時点ですでに現地参加のチケットが売り切れになっており、自宅からのオンライン参加となりました。
最も印象に残ったセッション
今回のスクラムフェスでは、導入事例やワークショップに加えて、チームや組織に関する話題も幅広く扱われていました。 そんな中で、僕が最も印象に残ったのは、2日目の最後に行われた 「AI×スクラムの「新・セオリー」を探す旅 — AI推進派の二人が直面した、予想外のジレンマ」 というセッションでした。
このセッションは最初から「答えを出すものではない」という前置きで始まり、会場全体で45分悩み抜く“公開探索”でした。 紹介文の中で一番刺さったのはこの一文です。
「これまでの正解だったスクラムのセオリーが、逆にスピードを殺していないか?」
というのも、僕自身が生成AIを使って仕事を進めていく中で、「生成AIの登場によって、スクラムの在り方も変わってくるのではないか？」という疑問が頭に浮かんでいる状態だったからです。
認定スクラムマスターになったとはいえ、僕は自分の関わるプロジェクトでは「スクラム」というフレームワークをそのまま採用しているわけではありません。 ですが、プロジェクトをマネージメントする上で「スクラムのエッセンス」は常に意識しています。
そのため、特にバイブコーディングのような形で生成AIが開発の現場に深く入ってくることで、「人間で構成されたチームが動くためのフレームワーク」であるスクラムが、これまでの形のままでフィットし続けるのだろうか、という疑問が頭の中に浮かんでいました。
スクラム／アジャイルは生成AIを想定していない（はず）
そもそも、スクラムもアジャイルも生成AIの存在を想定して作られたものではありません。 アジャイルでは「プロセスやツールよりも個人と対話」という価値が示されていますし、スクラムはそれを現場で実践しやすくする枠組みとして、経験主義（透明性・検査・適応）を基盤としています。
スクラムが体系化されたのは2000年代初頭であり、この時代に想定されていた前提は、次のようなものだったはずです。
- 成果物を作る主体は人間
- 作業速度の差はあっても、人間の認知速度の範囲内である
- 実装・設計・判断は人間が担う
ところが生成AIの登場によって、コードや設計のたたき台が、人間の理解が追いつかない速さで出てくる場面が増えました。 その結果、実装や設計の一部はAIに任せやすくなりましたが、同時に「AIが出した案」を前提に話が進み、何を作るかの判断がそちらに寄ってしまう可能性もあります。
セッションで扱われた論点（3つの焦点）
このセッションでの議論の焦点は以下の3つでした。
- 焦点① 「固定長スプリント」は足枷になり得るのか?
- 焦点② 「バックログ爆発」とリファインメントの皮肉
- 焦点③ 「職能横断」の完成と、役割の消失
一言でまとめると、生成AIによって「スクラムの前提」が揺らぎ始めていないか、という話だったように思います。
僕が特に印象に残ったのは、焦点①の「固定長スプリントは足枷になり得るのか？」でした。 この記事では、まずこの論点に絞って、自分なりに考えたことを書いてみます。
そもそもスプリントとは何か
スプリントは単なる作業期間ではなく、検査と適応を回すための区切りです。 スクラムの定義では「1スプリントは1か月以内」とされていますが、実務では2週間がよく使われます。これは、人間の認知や合意形成のリズムに合わせやすいからだと思います。
また、スプリントは固定長で運用して一貫したリズムを作る意図があるため、“早く終わったから短くする”発想とは相性がよくありません。 空いた時間は改善や学習、場合によっては休息に使えばよい、という考え方が根底にあります。 このリズムがあるからこそ、検査と適応が「たまに」ではなく「習慣」として回り続ける、というのがスプリントの強みだというのが僕の理解です。
固定長スプリントのリズムは維持できるのか
ただし、人間によって成果物が速くできる場合と、生成AIによって速くできる場合は、同列には扱えません。 生成AIを使えば、コードやドキュメントといったアウトプットは一気に生まれます。タスクの粒度によっては、半日〜1日で「それっぽい成果物」が出てくる場面もあるでしょう。
そのスピードだけを見れば「3日スプリントでもいいのでは？」と思うのは自然です。 スプリントはリズムを作る意図があるので、3日間でもそのリズムが保てるなら、問題ないとも言えそうです。
しかし、短くすればすべてがうまく回るとは限りません。作る速度が上がっても、人が理解し、判断し、話し合う部分は同じようには速くならないからです。
スプリント期間を短くすると、人間側の負荷が別の形で増えていきます。
1) リズム／運用の負荷
スプリントが短くなるほど、プランニングやレビュー、レトロスペクティブといったイベントも短い周期で回ります。準備や切り替えが増え、余力が削られやすくなります。
2) 検査の負荷
AIの出力は速い一方で、その成果物が「期待されたものである」という保証はありません。そのため、妥当性の確認は人間が行う必要があります。 生成AIを使った作業を続けていると「とんでもない速さで作業ができるかわりにやり直しも多い」という状況に出くわすことがあります。バイブコーディングによって「作る作業は減ったけど、そのかわり延々とレビューが続いてる」という声もよく聞きます。
3) 合意形成・意思決定の負荷
プロダクトオーナーは、その成果物からプロダクトの価値と方向性を判断しなければいけません。判断は「速いアウトプット」に比例して速くなるわけではなく、関係者との対話や合意形成も必要です。
AIによってアウトプットが早くなったからといって、そのペースにあわせてサイクルを短くしてしまうと、人間がそのサイクルに忙殺されてしまいます。 イベントは回っているのに、成果を見てやり方を変える時間が取れず、いつの間にか「形だけのスクラムを維持する」ことが目的になってしまいそうな気もします。 また、セッション参加者の方からは「開発スピードが早くなった分、期間を短くすると、開発の成果物への理解が疎かになるのでは？」という声もあがっていました。たしかにその通りだと思いました。
僕自身も生成AIの作業スピードに振り回されて、タスクのゴールを見失いそうになることがあります。 これはスクラムやアジャイルに固有の問題ではなく、「人間同士であれば作業速度がある程度そろっている」という暗黙の前提が揺らいでいるのだろうと思います。
つまり、生成AIが速くしたのは「作る」ですが、スプリントが支えてきた人間のリズムや判断は同じ速度では回らない、ということです。
と、ここまで書いてきて、自分が何を書こうとしてるのかちょっとわからなくなってきています（笑） ただ、スプリントの期間を短くするか・しないか、みたいな単純な話ではないという点には到達できたような気がします。
ですので、最後に「期間の長短」ではなく、スプリントが同時に担ってきた役割を分解して考えてみます。
スプリントが担ってきた役割を分解する
スプリントはこれまで、以下の役割を同時に担ってきたと思います。
- 成果物を生み出す作業単位
- 検査と適応のタイミング
- チームの集中と回復のリズム
- ステークホルダーとの対話の区切り
生成AIによって、成果物生成の速度だけが突出して速くなった結果、これらの役割が同じテンポで回らなくなり始めているのだと思います。 ただ、スプリントはAIのスピードに合わせるための仕組みではなかったはずです。
であれば、人間とAIが共存するチームにおいて、どのリズムを人間のために設計し直すのかがとても重要なのでしょう。 おそらく、その答えはまだ誰も持っていません。 スクラムというものが、どのプロダクト開発にも同じように適用できる「手法」ではないのと同じだと思います。
おわりに
今回スクラムフェス福岡に参加し、さらにこのブログを書くにあたって、再度「スクラムってなんだっけ？」ということを考えなおしました。 そして、「スクラムって、変化が起きることが前提になったフレームワークだったよね」ということを改めて思い出しました。
当初はソフトウェア開発前提の用語・文脈が多かったスクラムの定義も、IT特化の表現を意図的に削除して、より汎用的なプロダクト開発に適用しやすくするなど、何度かの大きな変化を経験しています。
であるなら、生成AIが登場したことで「スクラムを支えていた前提条件」は揺らいでいるとしても、スクラムの原則は何も変わっていないと考えることができそうです。
冒頭で書いたように、僕自身は認定スクラムマスターでありながら、自分のプロジェクトではそのフレームワークをそのままは採用していません。 おそらく、それは「このプロジェクトはスクラムでやる」と宣言した途端に、「スクラムではこうしなければならない」という考えに囚われてしまい、変化に対応できなくなってしまう恐れがあったからなのではないか、と今は思っています。
スクラムフェス福岡に参加して、何か明確な答えが得られたわけではありません。 それは、イベント自体が「答えを提示する」ものではないし、もっと言えばスクラムが「答えを与える」ものではないからです。 その代わり、考えなければいけないことが、以前よりももう少し具体的な形になったという意味では、とても貴重な経験だったと思います。
最後に、関連する記事としてこちらにも触れておきます。
AIで爆速になろうと開発速度は同じでいい。吉羽氏に聞く「アジャイルの“逆説的な”加速の仕方」 | レバテックラボ（レバテックLAB）
インタビューに答えている吉羽龍太郎さんは、僕が認定スクラムマスター研修を受けたときの講師を務めていた方です。 AIで“作れる量”が増えても、アウトプットを増やすこと自体が目的化すると本質を見失う、という視点が印象的でした。 今回の「スプリント短縮＝解決ではない」という違和感に対しても、ひとつの方向性がすでに示されていると感じました。
サービス一覧 www.alterbooth.com cloudpointer.tech www.alterbooth.com
