ブログ

みなさんこんにちは。@ryuzeeです。
10月から毎週火曜日の稼働に空きがでました。技術顧問やプロダクト開発支援を承りますので、興味があればお気軽にお問い合わせください。

2026年9月3日に、ぼくが所属する株式会社アトラクタが主催するイベント「Attractor Talks Reloaded」で、「生成AIでスクラムによる開発はどう変わるか（2026年9月版）」というテーマで登壇しましたので、そのときの資料を公開します。

昨年10月に一度出した内容をアップデートしたものになります。

参考になれば幸いです。

今回の主なアップデート

この1年で、生成AIをめぐる状況はかなり変わりました（というかずっと変わり続けています）。ざっくり言うと「AIがコードを書く」という話から、「生成AIがコードを書くことを前提として、チーム全体の仕事をどう設計し直すか」という話に移ってきたかんじです。今回の資料では、特に以下のような変化を反映しています。

生成AIは「試すもの」ではなく、ふつうの開発ツールになった

ChatGPTやClaudeで何か調べるだけでなく、Claude Code、GitHub Copilot、Cursorなどを使って、実装もテストもドキュメントも生成AIに任せるのがあたりまえになりました。もう生成AIを使っていること自体は、何も特別でもなければ差別化要因でもありません（さすがに使っていないほうが心配……）。

「生成AIを使えば何倍も速くなる」という単純な話ではなかった

生産性（とはなんだ？という議論はさておき）についての調査結果もいろいろ出そろってきましたが、効果にはかなりばらつきがあります。一方ではっきりしたこともあって、それは開発のコスト構造の変化です。コードを書く時間や技術調査の時間は確実に減っている一方で、生成AIに何を伝えるかを考える時間と、出てきたものを確認する時間が増加しています。

実装よりも、レビューや検証がボトルネックになりつつある

生成AIは短時間で大量のコードを生成できますが、人間がそれを理解して、意図どおりか確認して、品質を担保できる量には限界があります。つまり、どれだけ速く作れるかよりも、どれだけ速く確認や検証ができるかが全体としての開発速度を決めるようになったということです。

AIエージェントが長時間、自律的に作業するようになった

人間と対話しながらコードを補完してもらうだけでなく、まとまった作業をエージェントに任せて、バックグラウンドやクラウドで動かして結果を受け取る使い方が増えました。複数のエージェントを並列で動かす例も多数観測しています。ただし、作れる量を増やせば、そのぶんレビュー待ちや統合作業も増えます。並列にすれば速くなるというものではありません（そもそも人間の疲労度もやばい）。

生成AIに渡すコンテキストとして、ドキュメントの重要性がさらに上がった

生成AIは、チームの暗黙知を勝手に忖度してくれません。完成の定義、コーディング規約、用語集、ドメインモデル、アーキテクチャー、受け入れ基準などを生成AIが参照できる形で明示しておく必要があります。とは言えAGENTS.mdやCLAUDE.mdに何でも詰め込めばよいわけでもなく、何を常に読ませて、何を必要なときだけ参照させるのか、というコンテキストの管理も重要になっています。

細かいタスク分解や実装工数の見積りの価値は相対的に下がった

コーディングそのものが以前ほどのボトルネックでなくなれば、実装作業を細かく分解して工数を精緻に見積もる意味も小さくなります（そもそも細かくタスクを分けてJiraに登録するなんていうのもムダになります）。その代わり、レビューや検証にどれくらいかかるのか、不確実性がどこにあるのかを把握することのほうが重要になりました。

「たくさん作る」ことより「何を作るか」がさらに重要になった

作るコストが下がると、あれもこれも並列に作りたくなります。ステークホルダーも「あれば欲しい、これが欲しい、全部欲しい、生成AIならできるでしょ」みたいなことを言うかもしれません。でも、作ったものをユーザーに届けて結果（価値）を検証できないなら意味がありません。作れる量が増えたからこそ、スプリントゴールに集中して、不要なものは作らない、作っても価値がなければすぐ捨てる、というのが重要になってきます。

チームの仕事の重心が「コードを書くこと」から「意思決定と検証」に移りつつある

生成AIが実装を担える範囲が広がるほど、人間に求められるのは、何を作るのかを決めて、適切なコンテキストを渡して、結果を確認して、次の判断をすることになります。だからこそ、モブプログラミングのようにチームで同期しながら意思決定するやり方にも、改めて意味が出てきています。

品質を維持することの難しさがはっきりしてきた

生成AIは既存のコードや与えられたコンテキストをもとにコードを生成します。 元の設計やコードが悪ければ、その問題ごと増幅するということです。短期的には問題なく見えても、時間の経過とともにボディブローのように効いてきて、ビジネスに必要な速度や品質を維持できなくなります。自動テスト、完成の定義、アーキテクチャー、レビューの重要性はむしろ高まっていると言えそうです。

人材育成が新しい課題として認知されるようになった

生成AIは、コードを書く機会を奪うだけでなく、既存のコードを読んだり、自分で試行錯誤したりする機会まで減らしています。生成AIの出力をレビューできるようなシニアを育成するために、意図的に投資する必要がありそうです（まぁ焼畑農業思考の人はそんなことは気にしないのかもしれませんが、後回しにしたツケは数年後にやってくるでしょうね……）。

生成AIの利用量そのものを成果指標にしてはいけない

生成AIの利用率、生成コード量、トークン消費量、PR数。どれも増やそうと思えば増やせますが、増えたところでプロダクト開発が良くなったことにはなりません（このあたりは数字を使う技術でも触れました）。見るべきなのは、価値を届けるまでの時間、レビュー待ち、手戻り、品質、そして実際に得られた成果です。プロダクトが価値を届けて、その対価として組織に金銭的なメリットがもたらす、というのを実現できなきゃ、どんな高性能なツールをたくさん使おうが何も意味はありません。

それでは。