AI時代のスクラムの辛さ
2026-10-01
AI がこれだけ発展した現代においても、スクラムが持つ価値は下がるどころか、益々上がっているように感じます。
一方、AI 導入以前のスクラムの形をそのまま落とし込もうとすると、正直に言って苦しい部分もあります。
結論から言うと、開発速度が上がった以上、スプリントやマイルストーンといったスクラムの一つひとつを、今まで以上に小さく刻む必要があると思っています。
メリハリとリズム感を意識しないと、すぐにだれたり目的が曖昧になったりして、スクラムに追われて良いプロダクト作りができなくなってしまうからです。
今回は、スクラムマスターとして最近感じていることを書いていこうと思います。
プロダクトバックログの重要性の向上
スクラムにおいて、プロダクトバックログはプロジェクトの生命線であることは、言うまでもないと思います。
それゆえに、プロダクトバックログの管理に責任を持つプロダクトオーナーの実力によって、スクラムチームは時として最大限パフォーマンスを発揮できたり、また逆も然りなのですが。
AI の導入によって、開発者の開発速度は飛躍的に向上しました。
一方で、プロダクトオーナーの業務速度については、そこまで劇的に向上したとは言い難いと思っています。
とくにプロダクトバックログアイテムについては、ユーザーストーリーが明確になっていなければ作成することが困難です。
プロダクトオーナーを筆頭に、スクラムチーム全員が最終的なプロダクトに対する具体的なイメージを描けるようになるための速度感が、今まで以上に求められているということです。
今まで以上にボトルネックになりやすいプロダクトオーナー
繰り返しになりますが、AI による開発速度の向上は、プロダクトオーナーに対し今まで以上に強いプレッシャーを与える状態となっているように感じます。
プロダクトバックログアイテムの作成はプロダクトオーナーの責任ですが、すべてを一人でこなす必要はありません。
スクラムガイドにも、他の人に委任できると書かれています。
それでも、委任せずに一人で抱え込んでしまうプロダクトオーナーを、自分はこれまで何人も見てきました。
プロダクトオーナー業務に不慣れな場合、ここが最もボトルネックになりやすいことは、言うまでもありません。
例えば、最終的なプロダクトの具体的な認識を開発者が持ちきれていないケースでは、開発者が率先してプロダクトバックログアイテムを作成することも難しくなります。
そういったケースでは、インセプションデッキを振り返ったり、リファインメントの頻度を上げるなどして、少しずつ認識の向上を行うことが大切であり、ここらへんがアジャイルの面白いところだなとも思うのですが。
たまに、プロダクトオーナー自身が具体的な認識を持ちきれていないケースがあると、正直これはかなり苦しいです。
プロダクトバックログアイテム、つまり仕様が明確でなければ開発を前に進めることができないのは、アジャイルだろうとウォーターフォールだろうと何ら変わりません。
プロダクトオーナーの認識が甘いままプロダクトバックログの作成に追われてしまい、結果的にクオリティの低いインクリメントが作成されていくなんて、目も当てられません。
人を育てる時間がなくなった
スクラムチームはワンチームであるべきであり、プロダクトオーナーが困っていたら、スクラムマスターを中心にプロダクトオーナー業務のカイゼンを図る必要があります。
スクラムマスターの役割そのものは、AI の導入前後でそこまで大きく変わっていないと思っています。
変わったのはスピード感で、目を光らせる頻度やエスカレーションの速さは、明らかに上げる必要が出てきました。
とはいえ、プロダクトオーナーのスキル感が足りないケースでは、正直どうしようもない部分も大きいです。
今までは開発速度が遅かったので、その間にじっくりプロダクトオーナーを育成することができていました。
ところが今は、その暇さえなくなっているというのが正直なところです。
これはプロダクトオーナーに限った話ではありません。
開発速度が上がった分、開発者もプロダクトバックログアイテムの作成に関わることが求められるようになり、一人ひとりに求められる範囲が広がっています。
今までなら、バックログを作りたくないというメンバーが多少いてもなんとかなっていましたが、今はそういったメンバーがいるだけでチームが回りにくくなっています。
理想を言えば、スクラムに対してポジティブに向き合えるメンバーでチームを固めたいところです。
ただ、人の少ないベンチャー企業では、そもそもメンバーを選べない場面のほうが多いです。
勉強会はこれまでも必ず開いてきましたし、レトロスペクティブや 1on1 でも働きかけてはいるのですが、効果的かと言われると、正直手応えは薄いです。
人を育てる時間がなくなったこと、AI 時代のスクラムで自分が一番辛いと感じているのは、ここかもしれません。
小さく刻んでリズムを保つ
一方で、手を打てる部分もあります。
開発者がこれまで以上の速度でプロダクトバックログアイテムをこなせるようになった以上、プロダクトバックログアイテムを今まで以上に積極的に作成していくことが求められます。
ひいては、プロダクトオーナーは今まで以上に長期的な視点でプロダクトの具体的なイメージを持つことと、そのイメージを開発者に浸透させることが重要です。
リファインメントを厚くする
そのためにまず、リファインメントに今まで以上に時間を割く必要があると感じています。
作業アイテムへの分解は AI に任せられるようになり、スプリントプランニングの「どのように」にかかる時間はむしろ減りました。
一方で、「なぜ」と「何を」のすり合わせは減っていません。
その部分をリファインメントで先に済ませておけば、スプリントプランニングはタイムボックスの中に収まるはずです。
と書きつつ、実は自分のチームではまだ実現できていません。
プロダクトオーナーがリファインメントを理解しきれていないというのが、正直なところです。
マイルストーンを小さく刻む
次に、プロダクトゴールをいくつかのマイルストーンに分けているなら、1 つのマイルストーンで目指す範囲は今まで以上に小さく刻む必要があります。
マイルストーンの粒度が粗いままだと、1 マイルストーンあたりに必要なプロダクトバックログアイテムが多くなりすぎます。
すると、マイルストーン単位で行うユーザーストーリーマッピングの粒度も粗くなり、時間もかかりすぎて、その間に開発者がプロダクトバックログを使い切ってしまいます。
マイルストーンを小さく刻み、その区切りごとにインセプションデッキを見直して、足りない問いがあれば足し、目的がずれていればやり直す。
そのうえでユーザーストーリーマッピングを行う、くらいのリズムが必要なのかなと。
ただ、これもプロダクトオーナーがマイルストーンという考え方を理解しきれておらず、まだ実現できていません。
スプリントを短くする
最後に、スプリントの期間もさらに短くするべきだと思っています。
開発速度が上がった以上、スプリントの期間が長いままだと、スプリントゴールが肥大化して曖昧になるおそれが強いです。
スプリントレトロスペクティブで振り返る内容も、大きくすべきではないと思っています。
自分のチームでは毎回 1 週間で回していますが、これは効果的だと感じています。
スプリントゴールは絞られて目的がぼやけなくなり、振り返りの回数が増えてカイゼンも早く回り、ステークホルダーの確認も早く入るので手戻りも減りました。
もちろんケースバイケースではありますが、個人的には 2 週間ですら長く、メリットをほとんど感じません。
結局はプロダクトオーナーに行き着く
結局のところ、打てる手のうち 2 つは、プロダクトオーナーの理解が前提になっています。
そしてそこを育てる時間がないというのが、先に書いた辛さそのものです。
それでもポジティブに受け取ると、アジャイルはさらにアジャイルらしくなり、高い頻度でカイゼンを行うことができるため、スクラムとしての成長曲線自体は急上昇できるようになっているはずです。
まぁ、理想値的な話ではあるとは思いますが。
個人的に、最近のスクラムを見ていて感じていることをざっと書いてみました。
2020 年版スクラムガイドは、AI がここまで開発に入り込む前に書かれたものなので、AI については何も触れられていません。
とはいえ、スクラムガイドはもともと意図的に不完全なフレームワークであり、状況に応じたやり方はチームに委ねられています。
苦しいのはスクラムガイドのせいではなく、打てる手もガイドの中にちゃんとあります。
ただ、その手を回せるだけの人が育つ時間が、AI によって奪われてしまっているのかなと。
そういった困難をどう乗り越えていくか、スクラムマスターとしての手腕が問われる場面でもあるとは思いつつ。
理想的なアジャイルが回せたら、それはそれは楽しいんだろうなと心から思います。