なぜ、LLM AIコーディングのせいでスクラムの衰退が叫ばれるのか？

はじめに

「なぜ、LLM AIコーディングのせいでスクラムの衰退が叫ばれるのか？」という問いには、すでに二つの罠が仕込まれています。一つは、AIによってスクラムが本質的に時代遅れになった、と短絡することです。もう一つは、そもそも「スクラム衰退」という現象が実体を伴った事実として確立しているかどうかを、検査せずに受け入れてしまうことです。

本稿は「スクラムを守れ」とも「スクラムを捨てろ」とも単純には言いません。AIが露出させているのは方法論の優劣ではなく、組織が複雑性をどう扱ってきたかという実装態度の問題だからです。

そもそも「スクラム衰退」は本当に起きているのか

議論を進める前に、出発点を疑う必要があります。「スクラムの衰退が叫ばれる」と書いたとき、その「叫び」は誰の声で、どこで観測されたものなのかという問題です。X(旧Twitter)を含むIT論壇の声と、企業の実際の採用動向は別物です。第18回State of Agile Reportは、AIと自動化が計画・実行・測定方法を変えていると述べていますが、スクラムが消えたとは言っていません。

つまり、衰退論はまだ実証されたマクロ現象ではなく、現場で増えつつある違和感の集合体として読むのが正確です。そうであれば、本稿の議論にも反証圧力がかかります。たとえば、経験主義を高水準で回していた成熟チームがAI導入後も従来のスクラムをほぼそのまま維持しているなら、本稿の処方箋は適用範囲が狭まります。

この点を最初に置いておく理由は、「衰退の説明」を急ぐと、衰退の有無の検証をスキップしてしまうからです。本稿が扱うのは、衰退論が叫ばれるときに何が露出しているかという構造分析であり、衰退が普遍的事実だという主張ではありません。

スクラムはなぜ既製服化したのか

スクラムが広く受け入れられた理由の一つは、アジャイルの中では比較的、外形が分かりやすかったことです。プロダクトオーナー、スクラムマスター、開発者というロールがあり、スプリント計画、デイリースクラム、レビュー、レトロスペクティブというイベントがあり、プロダクトバックログ、スプリントバックログ、インクリメントという成果物があります。この構造は、本来は経験主義を回すための最小限の骨格でした。

ところが、硬直した経営・管理者にとっては、それが都合よく見えました。スプリントは小さな工程に見え、デイリースクラムは進捗会議に見え、バックログは作業一覧に見え、ベロシティは生産性指標に見えました。つまり、経験主義の道具だったものが、工程管理の道具として読み替えられたのです。

この読み替えは、フレデリック・テイラーの科学的管理法的な発想と相性が良すぎました。人間の作業を分解し、標準化し、測定し、管理するという発想です。本来のアジャイルは、そうした作業量管理では扱いきれない不確実性や学習を扱うための態度でしたが、スクラムという見える形を通じて、逆にテイラー主義的管理へ吸収されやすくなりました。

テイラー主義はテーラリングが大嫌い、というややこしい話

ここで一度、英語のいたずらに付き合っていただきます。フレデリック・テイラー(Taylor)のテイラーと、洋服のテーラー(tailor)は、綴りまで同じであり、日本語のカタカナ表記でも区別がつきにくい単語です。ところが、両者の哲学は、驚くほど正反対です。

服のテーラーは、客一人ひとりの肩幅や腕の長さを採寸し、その人だけのスーツを仕立てます。個別最適化の権化です。一方、テイラー主義のテイラーは、現場の個別性を測りません。むしろ、現場の作業を分解し、標準化し、誰がやっても同じ結果になるよう設計します。全体標準化の権化です。

つまり、発音はほぼ同じなのに、思想としては、テイラー(Taylor)はテーラー(tailor)を構造的に大嫌い、という関係になっています。本人が知ったら、たぶん渋い顔をするでしょう。日本のスクラム導入では、この音と意味の取り違えがしばしば起きているように見えます。本来は現場ごとに採寸すべきフレームワークが、標準作業の既製服として配られ、しかも採寸係であるはずのスクラムマスターが作業量監視員に化けるという事故が、各社で発生してきました。

ウォーターフォール型の重厚プロセスにも、標準プロセスを案件に合わせて調整するという意味でのテーラリングが一応含まれています。テイラー主義的管理は、その意味でのテーラリングすら嫌います。スクラムが問題を起こしたのではなく、採寸しないスクラム導入が問題を起こしたのです。

LLM AIコーディングが何を変えたのか

LLM AIコーディングが変えた最大の点は、実装そのものの限界を部分的に押し下げたことです。叩き台の作成、テストケース案の生成、既存コードの読解補助、局所的な修正案の提示が、短時間で行えるようになりました。これによって、チケットを消化しているように見える速度は大きく上がります。

しかし、ここで上がるのは主に生成速度です。プロダクト価値の妥当性、設計境界の正しさ、既存システムとの整合性、テストの十分性、レビューの深さ、セキュリティ上の問題、責任ある統合判断まで自動的に上がるわけではありません。DORAの2025年レポートも、AIは組織の強みと弱みを増幅する存在であり、投資効果はツールそのものより基盤となる組織システムに左右されると整理しています。

このため、AI時代のボトルネックは実装から、検証と統合判断へ移ります。AIが高速に作ったものが本当に採用可能かを見極めるには、受け入れ条件、回帰テスト、設計制約、変更影響、レビュー証跡が必要です。チケットの消化速度だけを見ている組織ほど、AIによって「進んでいるように見える未検証成果物」を大量に抱えることになります。

衰退と言われるものの正体

スクラムの衰退が叫ばれるとき、実際に衰退しているのは多くの場合、スクラムそのものではありません。衰退しているのは、スクラムをアジャイルの既製服として配り、スプリント、ポイント、ベロシティ、会議体を回していれば現代的な開発だと考える運用です。つまり、カーゴカルト・スクラムです。

アジャイル原則は、価値あるソフトウェアの早期かつ継続的な提供、変更要求の歓迎、短い期間での動くソフトウェアの提供、ビジネス側と開発者の日常的協力、技術的卓越性と良い設計、定期的な振り返りと調整を掲げています。これはAI時代でも消えるどころか、むしろ強まります。AIによって試作と変更が速くなるほど、早く見せ、早く検査し、早く調整する必要は増します。

したがって、「スクラムの衰退」は「アジャイルの衰退」と同義ではありません。アジャイルを理解しないままスクラムを採用していた組織が、AIによって逃げ場を失っているということです。本当にアジャイルを理解している組織なら、スクラムが合わなくなれば、フロー、カンバン、DevOps、プロダクト運営モデル、AI向け検証フレームへ作り替えればよいだけです。

検証ボトルネックの本命は検証インフラ側にある

ここで重要な分岐があります。「ボトルネックが検証へ移った」という診断から、すぐに「スプリントを短くしよう」という処方箋へ飛ぶのは、論理として直結していません。検証ボトルネックの本命の解決策は、まずもって検証インフラ側にあります。

具体的には、継続的インテグレーション、契約テスト、プロパティベーステスト、変更影響解析、レビューゲートの自動化、回帰テストの並列実行、テストデータ管理、ステージング環境のオンデマンド化といった、機械側の検証能力を引き上げる打ち手です。AIが生成速度を上げたのなら、AIに合わせて検証速度も上げる必要があります。生成側だけ加速して検証側を放置すれば、未検証差分が雪だるま式に積み上がるだけです。

スプリントを刻むかどうかは、これらと独立に決めることができます。むしろ、検証インフラが弱いままスプリントだけ短くすれば、レビュー待ち行列が増え、儀式オーバーヘッドだけが膨らみます。先に手をつけるべきは、スプリント境界ではなく検証パイプラインの容量であり、ここを取り違えると、AI時代のアジャイル改革は形だけのチューニングに堕ちます。

しかし実は「AI最適化スクラム」ではなく、別物?

検証インフラを整えたうえで、スプリントを一日から二日相当の検証単位にまで短くし、デイリーへ計画とリファインメントを統合し、レビューを随時化し、レトロスペクティブをイベント駆動にし、指標を未検証差分、レビュー滞留、検証コスト、変更失敗率へ移したとします。ここで率直に言うべきことがあります。

それは、もはやスクラムとは言えないかも知れません。スプリント境界を中心に経験主義を回すという定義から外れた瞬間、それはフロー型開発に近づきます。カンバン、継続デリバリ、DevOps、トランクベース開発、必要に応じてXP(エクストリーム・プログラミング)の技術プラクティスを組み合わせたものです。

ここで「AI最適化スクラム」というブランドにこだわると、自分で否定したはずの名前保存を自分でやってしまう事になりかねません。守るべきものは、スクラムという呼称以上に、複雑な開発において早く価値を確かめ、早く間違いを見つけ、早く適応する能力です。

AI時代の判断ギャップと責任の偏り

このフロー型運用への移行が示唆するもう一つの構造があります。それは、判断負荷の集中です。AIが大量のそれらしい成果物を出し、検証インフラが粗い差分を機械的にふるい落とすようになると、最後に残る判断は、設計境界、責任分界、統合可否、ビジネス価値の妥当性といった、AIが代替しにくい領域に絞られていきます。

そして、それらの判断を実際に下せる人間は、組織内に多くはいません。結果として、フロー型のAI開発組織は、見かけ上は民主的に流れているのに、実態としては少数の高判断力エンジニアにすべての設計と責任が静かに集中する、という非対称構造になりがちです。これはアジャイルが解消するはずだった構造ではなく、AIによって再増幅された別種の非対称性です。

ここはIT士業化の議論や「隠れた設計者」の議論と連続的な現象です。スクラムの衰退論は、単なる方法論交代の話ではなく、AI時代に責任がどこへ寄っていくのかという、より大きな労働構造の再編の前触れだと読むのが妥当です。

まとめ

LLM AIコーディングによってスクラムの衰退が叫ばれる理由は、AIがスクラムを本質的に不要にしたからではありません。AIによって、スクラムが企業内で既製服化され、テイラー主義的な作業量管理として使われてきたことが露出したからです。衰退しているのは、アジャイルではなく、カーゴカルト・スクラムです。

ただし、「スクラム衰退」という現象自体が、マクロな実証事実として確立しているわけではなく、現場の違和感の集合体として読むのが正確です。本稿の主張は、この衰退論が叫ばれるときに何が露出しているかという構造分析として提示されています。

ボトルネックは実装から検証へ移っており、本命の解決は検証インフラの強化です。スプリント境界の組み替えはその後の話であり、極端まで刻めばそれはもはやスクラムというよりはフロー型開発と呼ぶべきものに近いです。

また、フロー型運用への移行は、AI時代の判断ギャップと責任の偏りを同時に増幅する構造を持っています。スクラム衰退論は、方法論の置き換え論ではなく、AIによる労働構造の再編現象として読まれるべきです。