はじめに
こんにちは！AgVentureLabの藁谷です。
AIを入れたら、たしかに手は速くなりました。
その一方で、レビューは重くなる。メンバーごとの差は広がる。気づけば「便利なツールを1つ足した」では済まなくなっていました。
私たちは開発者6人（SM兼任含む）+POのスクラムチームです。スクラムガイドをもとにスプリントを回し、バックログを整理し、レトロスペクティブで改善を積み重ねてきました。
そこにAIが入ってきました。最初は「自分の作業を助ける壁打ち相手」として。いまは、仕様やテストを一緒に組み立てる副操縦士として扱う場面が増えています。
この前編で書くのは、AI活用が個人の工夫で済んでいたLv1から、チームで仕組みを整えないと回らないLv2へ進むまでに何が起きたかです。
この連載の役割はこうです。
- 前編：なぜAI活用が「個人技」では回らなくなり、チームとして運用するLv2までに何を整えたか
- 後編：その先でAIエージェントを作業主体にすると、スクラムのどこを設計し直す必要があるか
「AIを使うと速い。でも、そのままでは苦しい」という矛盾からスタートした話です。
後編はこちら：
この前編で扱うこと
- AI導入で、いま何が起きているのか
- 私たちのチームで、AI活用がLv1からLv2へどう変わったのか
- なぜその延長で、Lv3の設計が次の論点になるのか
AI導入で最初に起きたのは、「速さ」と「信頼」のねじれだった
AIはもう「試すかどうか」の話ではありません。開発者の84%がAIを使い、78%が「生産性が上がった」と感じている。にもかかわらず、AI生成コードへの信頼度は2024年から2025年で69%→54%に下落しています。さらに、上級エンジニアでは複雑タスクのパフォーマンスが約19%低下したという研究もあります（AI and Scrum v2026.1）。
要するに、速くなった実感はある。でも、安心して任せきれない。 このねじれが、いま多くのチームで起きていることだと思います。
さらに、AIの能力進化によってボトルネックは「コーディング」から「何を作るか」「どう品質を担保するか」へ移っています。つまり、変わり始めているのは実装速度だけではなく、チームの役割分担そのものです。
"People should be experimenting. Try all the things, because we just don't know. The whole landscape of what's 'cheap' and what's 'expensive' has all just shifted."
— Kent Beck（TDD, AI agents and coding with Kent Beck, The Pragmatic Engineer, 2025年6月）
データと識者の見解を詳しく読む
スクラムは「意図的に不完全」なフレームワークである
Ken Schwaber と Jeff Sutherland が書いた Scrum Guide 2020 には、こんな一節があります。
"The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it."
スクラムは意図的に不完全なフレームワークです。それを使うチームの集合知によって育てていくものだと言っています。
この言葉は、AI統合を考えるうえで重要な土台になります。スクラムはAIとの共存を禁じていません。むしろ、チームが状況に合わせて知恵を絞り、自分たちのやり方を作ることを期待しているのです。
ボトルネックは「コーディング」から「何を作るか」へ移行している
Ralph Jocham と Jeff Sutherland（スクラムの共同創設者）は、"AI and Scrum" 拡張ガイド（v2026.1） を2026年1月に公開しています。
同ガイドは、AIの能力進化に伴うボトルネックの変化をこう整理しています。
| 時期 | AIの能力 | ボトルネック |
|---|---|---|
| 〜2023年 | ジュニアエンジニア相当 | コーディング・実装 |
| 2024年頃 | シニアエンジニア相当 | 「何を作るか」の判断 |
| 2025年以降 | エキスパート相当 | プロダクトマネジメント・価値の検証 |
「作れるかどうか」から「作るべきかどうか」へ、ボトルネックの重心が移っています。この変化はスクラムのロールや責任のあり方にも影響します。
「速さ」と「信頼」の逆説
同ガイドによると、2025年末時点で開発者の84%がAIコーディングツールを何らかの形で使っています。78%が「生産性が上がった」と感じています。
しかし一方で、AI生成コードへの信頼度は2024年の69%から2025年には54%へと低下しています。上級エンジニアが複雑なタスクでAIアシスタントを使うと、検証・レビューコストが速度向上を相殺し、約19%のパフォーマンス低下が生じたという研究もあります。（AI and Scrum v2026.1）
「速くなった気がする」「でも信頼できない」という矛盾は、多くのチームが感じている感覚です。
Martin Fowler の視点：使い方が結果を決める
Martin Fowler は2025年8月のブログ記事で、こう書いています。
"From what I can tell the vast majority of LLM usage is fancy auto-complete... But those I know who get the most value from LLMs reckon that auto-complete isn't very useful, preferring approaches that allow the LLM to directly read and edit source code files to carry out tasks."
LLMを「高機能な自動補完」として使うのと、「ソースコードを直接読み書きして作業を実行するエージェント」として使うのでは、チームへの価値が全く異なります。「どう使うか」の設計が、結果を左右します。
Kent Beck の言葉：基本は変わらない、むしろ強化される
Agileマニフェストの共著者であり、テスト駆動開発（TDD）の提唱者でもある Kent Beck は、The Pragmatic Engineer のインタビュー（2025年6月）でAIとの協働においてTDDの重要性をあらためて強調しています。
AIエージェントはテストを削除して「パス」させようとすることがあります。それを防ぐのが、しっかりしたテストスイートです。彼はこのインタビューで、AI時代においてTDDなどエンジニアリングの基本的な実践の重要性があらためて高まると強調しています。
"People should be experimenting. Try all the things, because we just don't know. The whole landscape of what's 'cheap' and what's 'expensive' has all just shifted."
— Kent Beck（TDD, AI agents and coding with Kent Beck, The Pragmatic Engineer, 2025年6月）
何が「安い作業」で何が「高い作業」かの常識が、まるごとひっくり返っています。だから、試して確かめていくしかない、と彼は言います。
変わること・変わらないこと
| 領域 | 変わること | 変わらないこと |
|---|---|---|
| コーディング | 生成速度が劇的に向上する | 品質基準、テストの重要性 |
| チームの役割 | 「書く人」から「設計・判断・レビューする人」へ | 自己管理、クロスファンクショナルの価値 |
| ボトルネック | エンジニアリング → プロダクト判断 | 経験的プロセス制御（透明性・検査・適応） |
| 速度の感覚 | ベロシティの意味が変わる | イテレーションとフィードバックのリズム |
私たちのAI活用を3つの型で整理すると
私たちのチームでは、AI活用を次の3つの型で整理しています。
| レベル | 主担当 | AIの役割 | 人間が持つ責任 | 成立条件 |
|---|---|---|---|---|
| Lv1 | 人間 | 壁打ち・調査・補助 | 実装、判断、責任を人間が全部持つ | 個人の試行錯誤 |
| Lv2 | 人間 | 副操縦士として仕様・実装・テストを協働 | 仕様確定、レビュー、承認を人間が担う |
spec.md、SKILLS.md、レビュー方針 |
| Lv3 | AIエージェント | 委任された作業を自律実行 | 委任判断、受け入れ条件、レビュー、承認を人間が担う | 委任ルール、DoD、フィードバックループ |
ここでの整理は、「どれが上位か」という成熟度の話ではありません。誰が主担当なのかで分けています。
私たちはいまLv2を実践中で、Lv3は次の論点として設計を始めています。前編で深掘るのはLv1とLv2です。Lv3は後編で扱います。
Lv1からLv2へ進むと、チームの仕事が変わり始めた
Lv1：AIは「詳しい相談相手」だった
最初は、チャットでの質問や壁打ちが中心でした。コードを書くのはあくまで自分。AIは「詳しい相談相手」です。エディタのインラインサジェストもこの段階に含まれます。
この段階では、AI活用はまだ個人技でした。うまく使える人は速くなるし、使いこなせない人は恩恵が薄い。それでも、チーム全体の仕事の流れまでは変わっていませんでした。
Lv2：AIを副操縦士にすると、個人技では回らなくなった
次第に、コード生成やドキュメント作成にもAIを使い始めました。ここでAIは「相談相手」ではなく、「副操縦士」に近い存在になります。
ただし、この段階で問題がはっきりしました。Lv1までのAI利用には個人差が大きく、成果のばらつきも大きい。 さらに、AIが書いたものを人間がどう受け止めるかについて、チームの共通ルールがありませんでした。
最大の壁は、AI生成コードのレビューコストです。
「ほぼ正しいが微妙におかしい」コードを全量レビューしようとすると、速度向上が検証コストに食われます。速くなったはずなのに、なぜか楽にならない。ここがLv2の難所でした。
だから、レビューの重心をコードから仕様とテストへ移した
この課題に対して、私たちは2段階で対応しました。
まず、チーム全体を「Lv2の最低ライン」まで引き上げること。仕様の書き方のガイドラインとして spec.md の構成を整え、チームが共通で参照するスキルセットとして SKILLS.md を用意しました。
次に、Lv2の後半では仕様駆動開発を導入しました。狙いは、「膨大なコードレビュー」から、「仕様のレビュー」と「テストのレビュー」へ重心を移すことです。
人間とAIが対話しながら仕様を作成し、その仕様をもとにテストケースを設計します。AIがテストコードとプロダクトコードを実装し、人間は「仕様が正しく反映されているか」「テストが意図通りに書かれているか」を確認して承認する、というフローです。
この取り組みにより、1ユーザーストーリーポイントあたりの実績時間で15〜20%程度の改善が見られました。一方で、仕様作成コストとレビューコストが新たなボトルネックになり、現状の改善はこの水準で頭打ちになっています。これが、仕様駆動開発を取り入れたLv2の現在地です。
AI活用は、デイリースクラムとレトロの議題になった
数スプリント回すと、AI活用は個人の工夫ではなく、チームで扱うテーマになりました。実際、デイリースクラムやレトロスペクティブではこんな声が出るようになりました。
- 「AIが書いたコードのレビューに時間がかかる。でも、どこまで信頼していいかわからない」
- 「何を人間がやって、何をAIに任せるか。チームとしての方針がほしい」
- 「依存してしまっていいのか。コードを書く機会が減ることで、エンジニアとしてのスキルはどう変わるのか」
ここでようやく、論点がはっきりしました。AI導入の本質は「便利なツールを増やすこと」ではなく、チームとしてどこまで仕組みにするかだったのです。
後編では、AIを「担当者」にしたときの設計を扱う
ここまでの話は、人間が主担当のままAIを使うLv2までです。
では、1タスクをAIエージェントに「担当者」として渡したら何が変わるのか。変わるのは実装量だけではありません。委任ルール、Definition of Done、タスクボード、デイリースクラムでの透明化まで設計対象になります。
後編では、そのLv3の論点だけを掘ります。前編を読んで「じゃあ、この先どこまで任せていいのか？」が気になったなら、続きを読んでほしいです。
後編はこちら：
参考資料
- Agile Manifesto — Beck, Fowler, Sutherland ほか17名（2001年）
- Scrum Guide 2020 — Ken Schwaber & Jeff Sutherland
- AI and Scrum — Scrum Guide Expansion Pack v2026.1 — Ralph Jocham & Jeff Sutherland（CC BY-NC-ND 4.0）
- Some thoughts on LLMs and Software Development — Martin Fowler（2025年8月）
- TDD, AI agents and coding with Kent Beck — The Pragmatic Engineer（2025年6月）