[AI × Scrum] 開発者としてAIもバックログリファインメントに参加できるか検証してみた
はじめに
AIの発展によって開発のあり方が日々進化していく中で、スクラムイベントにも積極的にAIを使っていこうとスクラムマスターとして色々試しています。
今回はバックログリファインメントにスクラムチームの開発者としてAIエージェントにも参加してもらうというのを試してみたので紹介します。
前提条件
この記事は、以下の方を対象に書いています。
- スクラム開発における基本的な用語の理解がある
- Notion AIを利用できるワークスペース環境がある
- Claude Codeの初期セットアップが完了している(
/claudeコマンドでClaude Codeを立ち上げれる状態になっている)
ゴール
Claude CodeからNotionで管理しているバックログを読み込んで、リファインメント済みのバックログを元に新しくリファインメントするバックログのストーリーポイントを推定してもらう。
デモ用のPBIを用意する
実際のプロジェクトの情報を公開するわけにはいけないので、デモ用の雑なプロダクトバックログアイテム(以下、PBI)を用意します。
今回はスクラムチームがオンライン上でプランニングポーカーができるアプリを題材にしてみます。
簡単な要件を定義して、ClaudeにPBIを作成してもらいました。(本筋ではないので詳細は割愛します🙏)
Notionでのバックログ管理
クロステック・マネジメント社ではバックログ管理にNotionを活用しています。普段はNotionの「スプリント機能」をベースにゴリゴリにカスタマイズして運用していますが、今回のデモではシンプルなタスクデータベースを用意して検証します。
データベースのプロパティにはタスクに必要な基本的なプロパティに加え、数値型の「ストーリーポイント」と、タスクに自動で採番してくれる「ID」を追加しました。
また、今回はストーリーポイントの相対的な推定を行いたいので、ある程度のPBIに事前にストーリーポイントを入れておきます。(この記事の内容と前後しますが、今回構築したAIエージェントでポイントを推定してもらいました)

作成したPBIの内容は以下のように必要最低限のユーザーストーリーと受け入れ基準のみを記載しています。

これでNotion側の準備は完了です。
Claude CodeとNotionをMCPで接続する
次にClaude CodeとNotionをMCPで接続します。
MCPとは?(簡単に)
MCP(Model Context Protocol)とは、Claude CodeのようなAIアプリケーションと外部のアプリケーションやデータソースなどを接続するためのオープンな標準規格です。
今回の場合はClaude CodeがMCPホスト、NotionがMCPサーバーという関係性になり、Claude Codeが人間の代わりにNotionの機能に直接アクセスして作業を行えるようになります。
Notionは公式でリモートNotion MCPというMCPサーバーを出しているので、今回はそれを使用してClaude Codeと接続していきます。OAuth認証で簡単に接続が可能です。
実際に接続してみる
ターミナルを開き、任意の場所に作業ディレクトリを作成し移動します。(まだClaude Codeは起動しない)
mkdir backlog-refinementor
cd backlog-refinementor
次に以下のコマンドを実行して作業ディレクトリ内にNotion MCPの設定を追加します。
claude mcp add --transport http notion https://mcp.notion.com/mcp
この状態でClaude Codeを起動し /mcp コマンドを実行するとMCPの一覧を確認できます。
一覧の中に先ほど追加したNotion MCPがあるはずなので選択してEnterを押します。
notion △ disconnected · Enter to login
そうするとブラウザが立ち上がるので、MCP接続するワークスペースの選択やアクセス権の確認などを行います。
ブラウザ側の操作が完了した後にもう一度 /mcp コマンドを入力して、以下のように表示されていたらMCP接続完了です✅
notion ✔ connected · Enter to view details
CLAUDE.mdを作成する
Claude Codeでは、プロジェクトディレクトリに CLAUDE.md ファイルを配置することで、そのプロジェクト固有の指示をAIに与えることができます。
つまりはここでAIエージェントに開発者としての人格をインストールします。
先ほど作成したプロジェクトディレクトリのルート配下に CLAUDE.md ファイルを作成して、以下のように指示を書きました。
# バックログリファインメント支援
## 役割
あなたはスクラムチームの経験豊富な開発者として、バックログリファインメントに参加します。既存のリファインメント済みのプロダクトバックログアイテム(以下、PBI)との相対比較により、一貫性のある見積もりを行ってください。
## タスク
1. Notionから既存のリファインメント済みPBIを読み込む
2. 新しいPBIの内容を分析する
3. 既存アイテムとの相対比較により、新しいPBIのストーリーポイントを推定する
4. 推定根拠を既存PBIとの比較で明確に説明する
5. 不明確な点や疑問点があれば質問し、推定精度の向上を図る
6. 参考にした類似のPBIを最大3つまで比較対象として挙げる
## 推定アプローチ
**相対比較による推定**を行ってください:
- 既存アイテムと新規アイテムの作業内容を比較
- 複雑度、影響範囲、不確実性などを既存アイテムと対比
- このチームの過去の見積もり傾向を尊重
- フィボナッチ数列(0.5,1,2,3,5,8,13,21)の中から選択
## 主なNotionの参照先
### バックログDB
データベースID:XXXXX_NOTION_DATABASE_ID_XXXXX
## 出力形式
### 推定結果
- **推定ストーリーポイント**: Xポイント
### 相対比較による推定根拠
- **基準アイテム**: 「アイテムID/アイテム名(Yポイント)」との比較
- **類似する点**: 共通する作業内容や特徴
- **異なる点**: 複雑度や作業量の違い
- **推定理由**: なぜこのポイントが適切か
### 類似アイテムとの比較
- **アイテムID/アイテム名A(Yポイント)**: より複雑/シンプル/同等な理由
- **アイテムID/アイテム名B(Zポイント)**: より複雑/シンプル/同等な理由
- **アイテムID/アイテム名C(Wポイント)**: より複雑/シンプル/同等な理由
### 質問・確認事項
- 推定精度向上のための質問があれば記載
### 分割提案(必要に応じて)
- 既存の大きなアイテムと比較して分割が適切な場合は提案
これにより、Claude Codeがバックログリファインメントのコンテキストを理解し、一貫性のあるストーリーポイント推定を行えるようになります。
Claude Codeは人間の指示に基づいてNotionからよしなにデータを探してくれますが、今回のように参照してほしい場所が明確な場合は、そのページやデータベースのIDを明示しておくことでパフォーマンス向上を図っています。
今回はバックログデータベースのみ扱っていますが、実際のプロジェクトでは以下のような情報もNotinoのページにまとめて指定してあげるとより精度の高いアウトプットが期待できそうです。
- プロジェクト概要
- インセプションデッキ
- 技術仕様書等
などなど。
実際にポイントを推定してもらう
環境構築が完了したので、いよいよClaude Codeにリファインメントをやってもらいます。
まだストーリーポイントが設定されていない新しいPBIについて以下のように依頼してみました。
「見積もり結果表示」について、既存のアイテムを参考にストーリーポイントを推定してください。
すると30秒ほどで以下のような回答が返ってきました。
推定結果
推定ストーリーポイント: 2ポイント
相対比較による推定根拠
基準アイテム: 「ID:6/ストーリー登録(2ポイント)」との比較
- 類似する点:
- 両方ともデータの表示・処理機能
- UIコンポーネントの作成が主な作業
- バックエンドとの連携が必要
- 異なる点:
- 見積もり結果表示は統計的な計算処理(最頻値、平均値等)が必要
- ストーリー登録は入力フォームの実装が中心
- 推定理由: 統計計算のロジック実装が追加で必要だが、全体的な作業規模は同程度
類似アイテムとの比較
- ID:7/ストーリー選択(1ポイント): より複雑 - 統計計算や分布表示などの追加ロジックが必要
- ID:2/ルーム参加(2ポイント): 同等 - UIコンポーネント作成とデータ処理の複雑度が類似
- ID:4/カード一斉公開(3ポイント): よりシンプル - リアルタイム同期や状態管理の複雑度が低い
質問・確認事項
- 統計計算のアルゴリズムに特別な要件(精度、パフォーマンス)はありますか?
- 「大きく離れた見積もりのハイライト」の判定基準は具体的に決まっていますか?
- 見積もり結果のグラフ表示(ヒストグラムなど)は含まれますか?
CLAUDE.md ファイルに書いた指示に基づいていい感じにポイントの推定とその思考プロセスをアウトプットしてくれています。
もうひとつ別の依頼を投げてみました。
「リアルタイム状態同期」のストーリーポイントを推定してください。
推定結果
推定ストーリーポイント: 8ポイント
相対比較による推定根拠
基準アイテム: 「ID:3/カード選択(5ポイント)」との比較
- 類似する点:
- 複数のユーザー間でのリアルタイム状態管理が必要
- UI状態の同期処理が中心的な機能
- 異なる点:
- リアルタイム状態同期はWebSocket/Server-Sent Events等の双方向通信実装が必要
- 接続断・再接続の複雑なエラーハンドリング機能が必要
- 複数の状態(入退室、カード選択、ファシリテーター操作)を統合管理
- 推定理由: インフラレベルでのリアルタイム通信機能実装により、カード選択よりも大幅に複雑
類似アイテムとの比較
- ID:4/カード一斉公開(3ポイント): より複雑 - 一斉公開は一時的な状態変更だが、常時リアルタイム同期が必要
- ID:1/ルーム作成(3ポイント): より複雑 - ルーム作成は一回限りの処理だが、継続的な状態監視・同期が必要
- ID:3/カード選択(5ポイント): より複雑 - カード選択機能に加えてリアルタイム通信基盤の構築が必要
質問・確認事項
- WebSocketやServer-Sent Eventsなどのリアルタイム通信技術の選択は決まっていますか?
- ネットワーク接続断からの復旧時の状態復元の仕様は具体的に定義されていますか?
- 同時接続ユーザー数の上限や性能要件はありますか?
分割提案(必要に応じて)
- 8ポイントは比較的大きなタスクのため、以下の分割を検討:
- 「基本リアルタイム通信機能(5ポイント)」:WebSocket接続とメッセージ送受信
- 「再接続・エラーハンドリング(3ポイント)」:接続断検知と自動復旧機能
こちらは「8ポイント」と大きめのポイントを推定したので、PBIの分割案も出してくれました。
まとめ
ストーリーポイントは複雑さや曖昧さを相対的に評価する指標であり、ポイント自体ではなくその決定プロセスでの認識合わせこそが本質です。
今回AIエージェントに算出してもらった結果からも、ポイント自体よりも推定理由や根拠に着目すべきことが改めて確認できました。AIの推定値を見た瞬間にバイアスがかかり、開発者同士の議論が浅くなってしまわないよう注意が必要です。
開発作業そのものはAIによる代替が進んでいますが、どんなにAIが進歩しても意思決定の主導権は人間が持つべきです。
AIは対話を代替する存在ではなく促進する存在であることを意識し、スクラム運用でも積極的にAIを活用していきたいと思います。
おわりに
クロステック・マネジメント社は、「教育×AI」で次世代の学びを創造するために生まれた芸術大学発のスタートアップです。
ご興味のある方は、ぜひお気軽にお問い合わせいただけると嬉しいです!
京都芸術大学のテックブログです。採用情報:hrmos.co/pages/xtm/jobs 芸大など5校を擁する瓜生山学園は、通信教育で国内最大手、国内で唯一notionと戦略パートナー契約を結ぶなどDX領域でも躍進、EdTech領域でAIプロダクトを開発する子会社もあり、実は多くのエンジニアがいます。
Discussion