---
title: AIとの開発にスクラムを取り入れる
tags:  #ai #aiエージェント #プログラミング #scrum #agile #orca  
author: [dyamada](https://image.docswell.com/user/dyamada)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/K74Z6G23E1.jpg?width=480
description: AIエージェントを使った開発のプロセスを、なるべくスクラムっぽい感じにできるようにして、人間はPOと会話しながら作りたいものを考え、AIによる開発チームに開発してもらったものを人間が確認するという流れを構築しました。
published: November 08, 26
canonical: https://image.docswell.com/s/dyamada/ZMQPEL-2026-11-08-161712
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/K74Z6G23E1.jpg)

AI との開発に
スクラムを
取り入れる


# Page. 2

![Page Image](https://bcdn.docswell.com/page/LJ1RVDMZJG.jpg)

人間と AI で進める開発の全体像
スクラムを実践できるよう、役割とイベントを取り入れる
人間
対話して具体化する
方向・優先順位・採用を判断
計画
開発者 → 開発チーム
人間が承認
開発者
AI
2人が1つずつ
案を作る
開発可で着手
PO AI
対話の結果を
Issue にする
作成・更新
GitHub Issue
実装・検証
作って、確かめる
開発者どうしでレビュー
成果の確認
AI の PO が受け入れ確認
↓
人間が確認・採用判断
ふりかえり
開発チームが改善案
人間が採否を判断
AI の PO：結果を受け取り、次の仕様・Issue へ反映
開発チーム AI
この流れ全体を管理
結果を
申し送り
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJW1LY36E2.jpg)

人間と AI の役割分担
人間 ステークホルダー・PO
作る方向と優先順位を
PO と相談して決める
計画・成果・改善案を
確かめて判断する
開発チーム AI
Issue ごとの進行を管理し、
2つの実装案を比べる
採用後にマージ・後片付け・
ふりかえりを行う
⇄
対話して
具体化する
PO AI
人間と優先順位を検討し、
仕様・Issue に整理する
成果を受け入れ条件と
照らして確認する
開発者 AI
同じ Issue を2人が別々に
計画・実装・検証する
互いの PR を
レビューする
AI は PO・開発チーム・開発者の3つの役割。独立したスクラムマスターは置いていない
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/4EZPMXVRJ3.jpg)

スクラムのイベントと関連する活動 リファインメント プランニング
開発
レビュー
リファインメント：やりたいことを仕様と Issue にする
人間
やりたいことを
PO と相談し、
方向と優先順位を決める
対話して
具体化
⇄
PO AI
相談の結果を
仕様（spec.md）に書き、
今回作る範囲を
Issue に切り出す
ふりかえり
Issue（PBI）
書く
→
スクラムのプロダクト
バックログアイテム
（PBI）の代わり。
目的・範囲・
受け入れ条件を書く
PO が着手順を決めて「開発可」ラベルを付けると、開発チームが起動し、プランニングへ
スクラムでは開発者もリファインメントに加わるが、
このプロセスでは人間と AI の PO が中心で、開発者はプランニングから加わる
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/Y76MN451EV.jpg)

スクラムのイベントと関連する活動 リファインメント プランニング
開発
レビュー
プランニング：何をどう作るかを合意する
ふりかえり
スプリント期間は設けず、Issue ごとにスプリントの流れを踏襲する
開発者
AI
Claude Code
同じ Issue を読み、
自分の計画を立てる
開発者
AI
Codex
同じ Issue を読み、
自分の計画を立てる
計画
（2つ）
→
開発チーム AI
2つの計画と
確認したいことを、
人間に示す
計画
→
人間
作りたいものと照らして
確認・調整し、承認する
仕様の穴が見つかったら、
PO に戻して決め直す
↩
人間が承認すると、開発者2人がその計画でそれぞれ実装・検証に進む（開発へ）
デイリースクラムは取り入れていない
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/G75Z5QYLJ4.jpg)

スクラムのイベントと関連する活動 リファインメント プランニング
開発
レビュー
開発：2人がそれぞれ作り、互いにレビューする
ふりかえり
人間が承認した計画で、同じ Issue から2つの案を作る
開発者
AI
Claude Code
自分の計画で
実装・検証し、
PR（案1）を出す
互いの
PR を
レビュー
⇄
開発者
AI
Codex
自分の計画で
実装・検証し、
PR（案2）を出す
PR（2つ）
と
レビューの
結果
→
開発チーム AI
2つの案と
レビューの結果を
受け取り、比べる
比べた結果から、開発チームが推薦する PR を選び、POと人間とのレビューへ
承認された計画に沿う開発に人間の作業はなく、AI が実装・検証・相互レビューを進める
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/9J2RNPG37R.jpg)

スクラムのイベントと関連する活動 リファインメント プランニング
開発
レビュー
レビュー：成果を確かめ、採用を決める
ふりかえり
開発者どうしのレビューを終えた成果を、AI の PO → 人間の順に確かめる
開発チーム AI
2つの案と
レビューの結果を比べ、
推薦する PR を選ぶ
推薦
→
PO AI
受け入れ条件・仕様と
照らして受け入れ確認
（コードは見ない）
差し戻しなら、
開発チームが直して再確認
↩
確認の
結果
→
人間
実物を確かめ、
採用か、修正か、
条件の見直しかを決める
条件を見直すときは、
PO と仕様・Issue を直す
↩
採用が決まると、開発チームがマージと後片付けをして、ふりかえりへ
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/DEYDP5V8EM.jpg)

スクラムのイベントと関連する活動 リファインメント プランニング
開発
ふりかえり：進め方を改善し、次へつなぐ
レビュー
ふりかえり
採用した成果を取り込んだあと、Issue 1本の進め方をふりかえる
開発チーム AI
検証・レビューの
記録からふりかえり、
根拠のある改善案を示す
改善案
→
人間
改善案ごとに
採否を判断する
採用した
改善
→
開発チーム AI
採用した改善を
手順・文書へ反映し、
仕様についての発見を
PO へ申し送る
申し送りを受けた AI の PO が、人間と次の仕様・Issue を検討する（リファインメントへ）
反映した改善の効果は、次の Issue で確かめる。採用・反映・効果の確認は別のこと
8