【2026年最新】Claude Code×スクラム開発｜チーム運用7パターン

「Claude Codeを入れたら、スクラムイベントは減らせますか？」

研修や導入相談で、ここはかなりよく聞かれます。正直に言うと、イベントを減らすことを最初の目的にすると失敗しやすいです。デイリースクラム、スプリントレビュー、レトロスペクティブには、人間同士で認識を合わせる役割があります。Claude Codeが強いのは、その前後で発生する調査、差分確認、実装、テスト、PR説明、運用メモ化なんです。

私自身、最初にClaude Codeをチーム運用へ入れる時に迷ったのは、「どこまでをAIの仕事にして、どこからを人間の合意事項に残すか」でした。たとえば、受け入れ条件が曖昧なまま実装に進むと、Claude Codeはそれらしい変更を出せます。でもスプリントレビューで「欲しかったものと違う」となれば、速く作った意味が薄れます。

そこでこの記事では、Claude Codeをスクラム開発に組み込む7つの運用パターンを、イベント別・ロール別・設定別に整理します。Claude Code公式ドキュメントで確認できる機能だけを前提にし、架空の導入成果や削減率は置きません。

事例区分：本記事は実装パターン解説です。特定企業の実測事例ではありません。Claude Codeの機能・設定は2026年7月7日に公式ドキュメントで確認した内容をもとにしています。最新仕様は必ず公式ドキュメントと所属組織のセキュリティ規程で確認してください。

Claude Code×スクラム開発の全体像

Claude Codeは、コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携できるエージェント型のコーディングツールです。公式概要では、ターミナル、IDE、デスクトップ、ブラウザで利用でき、複数ファイルにまたがる機能実装、バグ修正、テスト作成、lint修正、依存関係更新、リリースノート作成などに使えると説明されています（Claude Code Overview, 参照日: 2026-07-07）。

スクラム開発に入れる時の見方は、単純な「開発者1人の補助」では足りません。スクラムでは、プロダクトバックログ、スプリントバックログ、インクリメント、Definition of Ready、Definition of Done、レビュー、ふりかえりがつながっています。Claude Codeをどこか1点にだけ入れると、速くなる箇所と詰まる箇所がずれます。

おすすめは、次のようにスクラムの流れへ対応づけることです。

スクラムの場面	Claude Codeで扱う作業	人間が残す判断
バックログリファインメント	既存コード調査、影響範囲、技術的論点の抽出	優先順位、価値、スコープ合意
スプリントプランニング	実装計画、テスト観点、依存関係の洗い出し	スプリントゴール、担当、容量判断
スプリント中	実装、テスト追加、リファクタ、PR説明作成	設計判断、仕様判断、レビュー承認
デイリースクラム	差分要約、ブロッカー候補、次アクション整理	チーム内の調整、割り込み判断
レビュー・レトロ	リリースノート草案、失敗ログ、改善案の整理	受け入れ、学習、次スプリントの改善コミット

チーム導入の全体像は、既存記事のClaude Codeチーム展開ガイドでも整理しています。本記事では、その中でもスクラムイベントに寄せた運用パターンに絞ります。

導入前の準備：スクラムチームで決める5つの前提

Claude Codeをスクラムに入れる前に、ツール設定より先に決めることがあります。ここを飛ばすと、各メンバーが好きなやり方で使い始め、PR粒度、テスト観点、レビュー期待値がばらけます。

1. AIが触ってよい作業を決める

まず、Claude Codeに任せる作業の境界を決めます。たとえば、テスト追加、ドキュメント更新、既存パターンに沿った小変更は進めやすい一方、権限設計、課金処理、個人情報処理、DBスキーマ変更は人間レビューを厚くするべきです。

公式ドキュメントでは、permissionsによってClaude Codeが何を実行できるかを細かく制御でき、allow、ask、denyのルールを設定できると説明されています（Configure permissions, 参照日: 2026-07-07）。この仕組みは、スクラムチームの「AI作業ポリシー」を実装する場所になります。

2. DoRとDoDをClaude Codeに読ませる

Definition of ReadyとDefinition of Doneは、人間だけが読むチェックリストではなく、Claude Codeにも読ませるべきです。Claude Codeには、プロジェクトや組織の永続的な指示としてCLAUDE.mdを使える仕組みがあります。公式ドキュメントでは、CLAUDE.mdはプロジェクト、ユーザー、組織単位で置けると説明されています（How Claude remembers your project, 参照日: 2026-07-07）。

スクラムチームなら、CLAUDE.mdに次のような項目を入れます。

# Scrum working agreement

## Definition of Ready
- issue has business context, acceptance criteria, and test expectations
- dependencies are listed
- unclear requirements must be asked before implementation

## Definition of Done
- tests added or updated when behavior changes
- lint/typecheck/test commands run before PR
- PR description includes user impact, test evidence, and risks
- if assumptions were made, list them explicitly

## Claude Code behavior
- start risky or multi-file work in plan mode
- do not change database schema without explicit approval
- ask questions when acceptance criteria are incomplete

ポイントは、「いい感じに実装して」ではなく、スクラムチームの合意事項を実行可能な言葉にすることです。

3. 権限モードの使い分けを決める

Claude Codeには複数のpermission modeがあります。公式ドキュメントでは、defaultは読み取りのみが自動、acceptEditsはファイル編集などを自動承認、planは読み取りのみ、autoは背景安全チェックつきで長いタスク向け、dontAskは事前承認済みツールのみ、bypassPermissionsは隔離されたコンテナやVM向けと説明されています（Choose a permission mode, 参照日: 2026-07-07）。

スクラムチームでは、次のように使い分けると混乱しにくいです。

場面	推奨モード	理由
リファインメント、見積もり、影響範囲調査	plan	変更前に読み取りと計画で止められる
小さな実装、テスト追加、ドキュメント更新	defaultまたはacceptEdits	レビューしながら進めやすい
CI上の限定タスク	dontAsk	事前許可されたツールだけに閉じられる
隔離VMでの一括修正	bypassPermissionsは慎重に検討	公式にも隔離環境向けとされるため、通常PCでは避ける

権限設計の詳細は、Claude Code権限設計チームガイドでも扱っています。

7パターン早見表：どのスクラムイベントに効くか

ここからは本題の7パターンです。すべてを一度に入れる必要はありません。最初のスプリントでは、パターン1、2、5だけでも十分です。運用が安定してから、MCP、hooks、GitHub Actions、agent teamsを広げてください。

パターン	主な場面	使うClaude Code機能	最初の導入単位
1. バックログ精査	リファインメント	Plan mode、@参照、MCP	1ストーリー
2. DoR/DoD標準化	全イベント	CLAUDE.md、.claude/rules	1リポジトリ
3. ストーリーからPR	スプリント中	MCP、GitHub Actions	小さなissue
4. ペアプロ/モブプロ補助	実装・設計	IDE連携、Plan mode、会話履歴	1セッション
5. レビューと品質ゲート	PRレビュー、DoD	hooks、permissions、Stop hook	lint/testのみ
6. 並列スパイク	技術検証	subagents、worktrees、agent teams	調査だけ
7. レトロ改善ループ	ふりかえり	auto memory、CLAUDE.md更新、DORA/SPACE指標	1改善テーマ

パターン1：バックログ精査をPlan modeで始める

最初に効くのは、実装ではなくバックログ精査です。スプリントプランニングの場で「このストーリー、どのファイルが関係するんだっけ？」と議論が止まることがありますよね。Claude Codeはここで使いやすいです。

Plan modeは、Claudeがコードを読み、探索し、計画を出すが、ソースを編集しないモードです。公式ドキュメントでは、Shift+Tabやclaude --permission-mode planで使えると説明されています。複数ファイルを変更する時や、不慣れなコードを触る時に向いています（Best practices for Claude Code, 参照日: 2026-07-07）。

バックログ精査の手順

1. スプリント候補のissueを1つ選ぶ。
2. Plan modeでClaude Codeを起動する。
3. issue本文、関連ファイル、受け入れ条件を渡す。
4. 変更候補、テスト観点、未確定事項を出させる。
5. 未確定事項をPO/PMと確認してから、スプリントに入れる。

claude --permission-mode plan

Issue ENG-241 をスプリント候補として精査してください。

目的:
- このストーリーが今のコードベースでどの程度の変更になるかを知りたい

確認してほしいこと:
- 変更が必要そうなファイル
- 既存実装の類似パターン
- 受け入れ条件として不足している点
- テスト観点
- 実装を始める前に人間へ確認すべき質問

制約:
- まだファイルは編集しないでください
- 推測した点は「仮定」と明記してください
- 不足している情報があれば、最初に質問してから作業を開始してください

ここで出てきた「人間へ確認すべき質問」が、リファインメントの材料になります。個人的には、この使い方が一番スクラムに馴染みやすいです。Claude Codeが見積もりを決めるのではなく、見積もるための情報を集める役割に置くからです。

パターン2：DoR/DoDをCLAUDE.mdとrulesに落とす

スクラム運用で一番もったいないのは、毎回同じ指摘をすることです。「テストがない」「PR説明が薄い」「影響範囲が書かれていない」「仕様の仮定が混ざっている」。こういう指摘は、Claude Codeに先に読ませるルールへ落とせます。

公式ドキュメントでは、CLAUDE.mdはチーム共有のプロジェクト指示として使え、.claude/rules/でファイル種別やパスに応じたルールも整理できます。大規模チームでは組織単位のCLAUDE.mdも扱えますが、設定は強制、CLAUDE.mdは行動指示という役割の違いがあります。

DoDをPR品質に変換する

たとえば、スクラムチームのDefinition of Doneを次のように具体化します。

# .claude/rules/pr-quality.md

When preparing a pull request:
- include the related issue ID
- describe user-visible behavior changes
- list test commands actually run and their results
- list risk areas and rollback notes when relevant
- do not claim that tests passed unless command output confirms it
- if no tests were run, explain why and suggest the smallest useful check

このルールがあると、Claude CodeにPR説明を書かせる時の品質が安定します。もちろん、最終的にPRを出すか、マージするかは人間の責任です。AIは補助ツールであり、スクラムチームの合意やレビュー責任を置き換えるものではありません。

プロンプト例：DoDに沿ったPR説明

今回の差分を確認し、Definition of Doneに沿ったPR説明を作成してください。

必ず含める項目:
- 関連issue
- ユーザー影響
- 変更ファイルの要約
- 実行したテストコマンドと結果
- まだ確認できていないリスク
- レビュアーに重点的に見てほしい点

数字と固有名詞は、根拠またはコマンド出力を添えてください。
仮定した点は必ず「仮定」と明記してください。

このパターンは、個人の使い方ではなくチームの型です。Claude Codeを入れてもレビューが荒れるチームは、AIの問題というより、DoDが文章として曖昧なケースが多いです。

パターン3：ストーリーからPRまでをMCPとGitHub Actionsでつなぐ

スクラム開発では、issue、デザイン、仕様、PR、CI、レビューコメントが別々の場所に散らばります。Claude CodeはMCPを通じて外部ツールに接続できます。公式ドキュメントでは、MCPによりissue tracker、GitHub、Slack、Figma、データベース、監視ツールなどのデータソースと接続でき、Jira issueをもとに実装してGitHubでPRを作る例も示されています（Connect Claude Code to tools via MCP, 参照日: 2026-07-07）。

さらにGitHub Actions連携では、PRやissueのコメントで@claudeに依頼し、コード分析、PR作成、機能実装、バグ修正などを行えると公式に説明されています（Claude Code GitHub Actions, 参照日: 2026-07-07）。

MCP連携の手順

1. issueテンプレートに「背景」「受け入れ条件」「非対象」「テスト期待値」を必須化する。
2. MCPまたはGitHub Actionsで、Claude CodeがissueとPRにアクセスできる範囲を限定する。
3. 最初は「実装」ではなく「実装計画のコメント作成」から始める。
4. 次に小さな修正だけを@claudeでPR化する。
5. PRは人間がレビューし、Claudeの提案は自動マージしない。

issueテンプレート例

## 背景
ユーザーにとって何が困っているか:

## 受け入れ条件
- [ ] 条件1
- [ ] 条件2

## 非対象
- 今回やらないこと:

## 技術メモ
- 関連ファイル:
- 類似実装:

## Claude Codeへの依頼方針
- まずPlan modeで影響範囲を整理
- 実装前に未確定事項を質問
- PR説明にはテスト結果を含める

注意点は、MCPを入れるほど「便利」と「危険」が近づくことです。外部ツールへ書き込める権限は、読み取り専用から始めて、レビュー後に段階的に広げるのが安全です。MCP運用の具体手順は、Claude Code MCP実践ガイドも参考になります。

パターン4：ペアプロ・モブプロの補助役にする

Claude Codeは、ひとりで黙々と使うだけではありません。ペアプロやモブプロの場で、第三の参加者のように使うと便利です。特に、既存コードの読み解き、代替案の整理、テストケースの抜け漏れ確認に向いています。

ここでのコツは、Claude Codeを「実装者」ではなく「記録係兼問い返し役」にすることです。人間同士で設計判断を話し、Claude Codeにはコードベース上の事実確認と、変更計画の整理を任せます。

モブプロでの進め方

1. モブプロ開始時に、対象issueと作業範囲をClaude Codeへ渡す。
2. まずPlan modeで既存構造と変更候補を整理させる。
3. 人間が方針を選ぶ。
4. Claude Codeに小さな単位で実装させる。
5. 各変更ごとにテストとdiffを人間が確認する。

これからモブプロで ENG-318 を進めます。
あなたは実装方針の整理役です。

最初にやること:
- 関連ファイルを調べる
- 既存パターンを3つまで挙げる
- 変更案をA/Bで比較する
- 不明点を質問する

まだ実装しないでください。
チームが方針を選んだ後に、最小差分で進めます。

これ、実際にやると会議の質が変わります。発言の強い人の直感だけで決めるのではなく、「既存コードはどうなっているか」「どの変更が小さいか」を横に置けるからです。ただし、Claude Codeの提案が正しいとは限りません。コード、テスト、プロダクト要求を見て、最後はチームで判断します。

パターン5：レビューと品質ゲートをhooksで固定する

スクラム開発では、スプリント終盤に品質チェックが溜まりがちです。Claude Codeを使うなら、品質ゲートは後回しにせず、作業中に寄せるべきです。

Claude Codeのhooksは、セッションの特定タイミングでシェルコマンド、HTTP endpoint、LLM promptなどを実行する仕組みです。公式ドキュメントでは、PreToolUse、PostToolUse、Stop、TaskCompletedなど多数のイベントが定義され、ファイル編集後にlintを走らせたり、危険なBashコマンドをブロックしたりできます（Hooks reference, 参照日: 2026-07-07）。

最初に入れるならPostToolUseだけでよい

いきなり全イベントにhookを入れると、開発体験が重くなります。最初は、EditまたはWriteの後にフォーマットや軽いlintを走らせる程度が現実的です。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-after-edit.sh"
          }
        ]
      }
    ]
  }
}

#!/bin/bash
set -euo pipefail

cd "$CLAUDE_PROJECT_DIR"

if [ -f package.json ]; then
  npm run lint -- --quiet
fi

この例はあくまで最小構成です。実運用では、リポジトリの規模、言語、CI時間、ローカルマシン性能に合わせて調整してください。重すぎるhookは、スクラムの流れを良くするどころか、開発者の集中を切ります。

失敗しにくい品質ゲートの順番

1. formatだけを自動実行する。
2. lintを軽い対象に限定して追加する。
3. テストは変更ファイル周辺だけにする。
4. Stop hookやTaskCompleted hookは、運用が固まってから入れる。
5. 本番DB、秘密情報、外部API書き込みはpermissionsのdenyやaskで守る。

品質メトリクスの設計は、Claude Code品質メトリクス自動修正ガイドとも相性がよいです。

パターン6：並列スパイクはsubagents、worktrees、agent teamsを慎重に使う

スプリント中に、技術スパイクが複数走ることがあります。たとえば「認証方式A/Bを比較する」「UI実装案を2つ試す」「既存APIの移行影響を見る」といった場面です。Claude Codeには並列作業を支える機能があります。

公式ドキュメントでは、subagentsは独自のコンテキストを持つ専門アシスタントで、調査やログ確認などメイン会話を汚しやすい作業を切り出せると説明されています（Create custom subagents, 参照日: 2026-07-07）。また、複数のClaudeセッションをworktreesやWeb、Desktop、agent teamsで並列に使えることもベストプラクティスで紹介されています。

一方で、agent teamsは公式ドキュメント上でもexperimentalで、デフォルトでは無効です。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを設定して使う機能であり、トークン使用量や調整コストも増えます（Orchestrate teams of Claude Code sessions, 参照日: 2026-07-07）。スクラムチームで使うなら、最初は調査だけに限定してください。

スパイクの依頼例

このスプリントでは認証エラーの原因調査スパイクだけを行います。

3つの観点で並列調査してください:
- フロントエンドの状態管理
- APIレスポンスとエラー変換
- セッション/トークン更新処理

制約:
- まだコードは編集しない
- 各観点で根拠ファイルと該当行を示す
- 最後に「最も可能性が高い仮説」と「次に書くべき最小テスト」を提案する
- 不明点は仮定と明記する

この使い方の価値は、スプリント内の意思決定を速くすることです。ただし、同じファイルを複数セッションが同時に編集すると衝突しやすいので、実装に進む時は担当範囲とworktreeを分けてください。

パターン7：レトロスペクティブでClaude Code運用を更新する

Claude Codeの運用は、最初から完成しません。スクラムらしく、スプリントごとに改善します。特に見直すべきなのは、プロンプトではなく、ルール、権限、品質ゲート、PR粒度です。

公式ドキュメントでは、Claude CodeにはCLAUDE.mdのほか、Claudeが学習したメモを蓄積するauto memoryがあります。ただし、auto memoryやCLAUDE.mdは行動を導く文脈であり、強制設定ではありません。強制したい場合はpermissionsやPreToolUse hookを使う必要があります。この違いはレトロでかなり重要です。

レトロで見る項目

観点	確認する質問	更新先
受け入れ条件	Claude Codeが仮定で進めた箇所はあったか	issueテンプレート、DoR
レビュー	同じ指摘が複数PRで出たか	CLAUDE.md、.claude/rules
品質	CI失敗は事前に検出できたか	hooks、ローカルテスト手順
権限	許可が広すぎた、または狭すぎた場面はあったか	permissions、managed settings
生産性	リードタイム、レビュー待ち、手戻りはどう変わったか	DORA/SPACE計測

Claude Codeの効果測定をスクラムに接続したい場合は、Claude Code×DORA/SPACE生産性指標の記事もあわせて読むと整理しやすいです。

レトロ用プロンプト例

このスプリントのClaude Code運用をふりかえります。

入力:
- merged PR一覧
- CI失敗ログ
- レビューコメントの要約
- スプリントゴール
- 完了/未完了のストーリー

出力してほしいこと:
- Claude Codeが役立った場面
- 逆に手戻りを増やした場面
- CLAUDE.mdへ追加すべきルール
- permissionsまたはhooksで強制すべきルール
- 次スプリントで試す改善を3つ

注意:
- 成果を断定しないでください
- 数字は入力データにある範囲だけ使ってください
- 仮定した点は「仮定」と明記してください

こうして、Claude Codeの使い方そのものをスクラムの改善対象にします。ツールを入れて終わりではなく、チームの作業協定を毎スプリント少しずつ磨くイメージです。

スプリントイベント別の使い方

7パターンをイベント別に並べ替えると、現場で使いやすくなります。スクラムマスターやEMがチームへ説明する時は、この表から入るのがおすすめです。

イベント	Claude Codeの使い方	避けること
バックログリファインメント	影響範囲、未確定事項、テスト観点を整理する	Claude Codeに見積もりを決めさせる
スプリントプランニング	Plan modeで実装計画を作り、人間が容量判断する	不明点を残したままスプリントへ入れる
デイリースクラム	前日差分、ブロッカー候補、次アクションを要約する	人間の同期を完全に置き換える
スプリントレビュー	PR差分、テスト結果、ユーザー影響を説明資料にする	動作確認なしで「完成」と言う
レトロスペクティブ	失敗パターンをCLAUDE.md、rules、hooksに反映する	個人の感想だけで終わる

デイリースクラム用プロンプト

昨日から今日までの差分を、デイリースクラム用に整理してください。

確認対象:
- git diff
- merged/open PR
- failing CI
- 自分が担当しているissue

出力形式:
- 昨日やったこと
- 今日やること
- ブロッカー候補
- チームに確認したいこと

注意:
- 実際に確認できた事実と推測を分ける
- 人間に確認が必要な点を最後にまとめる
- 長くしすぎず、1分で話せる粒度にする

デイリースクラムで便利なのは、話す内容を作ることではなく、ブロッカーを見落としにくくすることです。ここでもClaude Codeは「会議の代替」ではなく「準備の補助」です。

チームロール別：誰が何を使うか

Claude Codeは開発者だけのものに見えますが、スクラム運用ではロールごとに使い方が違います。

ロール	主な使い方	注意点
開発者	実装計画、コード変更、テスト追加、PR説明	Claudeの変更を自分の責任でレビューする
テックリード	CLAUDE.md、rules、permissions、設計レビューの整備	ルールを増やしすぎて開発体験を壊さない
スクラムマスター	ブロッカー可視化、レトロ改善、運用合意の更新	AI利用を個人責任にせず、チームの作業協定にする
プロダクトオーナー/PM	受け入れ条件、非対象、リリース説明の整理	仕様判断をClaude Codeに委ねない
EM/VPoE	導入ポリシー、権限、教育、効果測定	速度だけで評価せず、品質・学習・安全性を見る

法人導入の稟議や運用設計まで含める場合は、Claude Code法人導入ガイドも参照してください。

30日導入ロードマップ：1スプリントから始める

スクラムチームにClaude Codeを入れるなら、全社展開より先に1チーム、1スプリント、1リポジトリで試すのが現実的です。ここでは2週間スプリントを想定した30日ロードマップとして書きます。これは試算モデルではなく、導入手順の例です。

Day 1-3：作業協定を決める

• Claude Codeで扱ってよい作業と扱わない作業を決める。
• DoR、DoD、PRレビュー基準をCLAUDE.mdへ書く。
• permissionsの初期方針を決める。
• Plan modeを使う対象を決める。

Day 4-10：1ストーリーで試す

• リファインメントでPlan modeを使う。
• 実装は小さな差分に分ける。
• PR説明をClaude Codeに草案化させる。
• レビューで「Claude Codeが見落とした点」を記録する。

Day 11-20：品質ゲートを足す

• PostToolUse hookでformatまたはlintを追加する。
• CI失敗ログをClaude Codeに要約させる。
• 同じレビュー指摘をCLAUDE.mdまたはrulesへ反映する。
• 権限が広すぎる場合はdeny/askを追加する。

Day 21-30：次スプリントへ残す型を決める

• レトロで運用パターンをふりかえる。
• 継続するプロンプト、やめるプロンプトを分ける。
• チーム共通のPR説明フォーマットを確定する。
• 次スプリントでMCPやGitHub Actionsを広げるか判断する。

ここで大事なのは、最初の30日で「削減率」を断定しないことです。測るなら、PR作成までの時間、レビュー待ち時間、CI失敗回数、再レビュー回数、未確定事項の持ち越し数など、チームが継続して観測できる指標にします。

プロンプト集：スクラム運用でそのまま使える7本

ここでは、スクラムチームで使いやすいプロンプトをまとめます。すべてに「不足情報があれば質問」「仮定は明記」を入れています。これは事故防止のためです。

1. バックログ精査

次のプロダクトバックログアイテムを、実装前に精査してください。

入力:
- issue本文
- 受け入れ条件
- 関連しそうなファイル

出力:
- 変更が必要そうな箇所
- 既存パターン
- 不明点
- テスト観点
- スプリントに入れる前に確認すべき質問

まだ実装しないでください。
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。

2. スプリント計画

このissueをスプリントに入れる前提で、実装計画を作ってください。

含める項目:
- 作業分解
- 依存関係
- 変更ファイル候補
- テスト方針
- レビューで重点確認すべき点
- 1日で終わらない場合の分割案

制約:
- ファイル編集はしない
- 仕様判断が必要な点は質問として列挙する
- 数字や固有名詞は、根拠を添える

3. デイリースクラム準備

今日のデイリースクラムで話す内容を1分以内に整理してください。

確認対象:
- git diff
- 自分のopen PR
- failing CI
- 担当issue

出力:
- 昨日やったこと
- 今日やること
- ブロッカー候補
- チームに確認したいこと

確認できた事実と推測を分けてください。
不足している情報があれば、最初に質問してから作業を開始してください。

4. PR説明

現在の差分からPR説明を作成してください。

必須項目:
- 概要
- 関連issue
- ユーザー影響
- 技術的変更点
- 実行したテスト
- リスクとロールバック観点
- レビュアーに見てほしい点

テストを実行していない場合、実行済みのように書かないでください。
仮定した点は必ず「仮定」と明記してください。

5. レビュー観点

このPRをレビューするための観点を整理してください。

観点:
- 受け入れ条件を満たしているか
- 既存設計に沿っているか
- テストが不足していないか
- セキュリティや権限の懸念がないか
- リリース時の注意点がないか

変更内容を鵜呑みにせず、コード差分とテスト結果を根拠にしてください。
不足している情報があれば質問してください。

6. スプリントレビュー準備

このスプリントで完了したPRから、スプリントレビュー用の説明を作成してください。

出力:
- スプリントゴールとの対応
- ユーザーに見える変更
- デモで見せる順番
- まだ見せない/未完了の範囲
- リスクと次スプリントへの持ち越し

完了していないものを完了扱いしないでください。
数字は入力データにある範囲だけ使ってください。

7. レトロ改善

このスプリントのClaude Code利用をふりかえってください。

入力:
- レビュー指摘
- CI失敗
- PR説明
- 未完了issue
- チームメンバーのメモ

出力:
- 継続する使い方
- やめる使い方
- CLAUDE.mdに追加するルール
- permissionsまたはhooksで強制する候補
- 次スプリントで試す小さな改善

成果を断定せず、確認できる事実と仮説を分けてください。

よくある失敗パターンと回避策

Claude Code×スクラム開発で失敗しやすいパターンは、技術より運用にあります。ここは本当に要注意です。

失敗1：Claude Codeに見積もりを決めさせる

❌「このissueは何ポイントですか？」

⭕「このissueの変更範囲、未確定事項、テスト観点を整理してください。見積もりはチームで行います。」

なぜ重要か：スクラムの見積もりは、コード量だけでなく、理解度、リスク、依存関係、チーム容量を含む会話です。Claude Codeは材料を出せますが、見積もりの合意はチームの仕事です。

失敗2：DoDが曖昧なまま実装させる

❌「実装してPRを作って」

⭕「受け入れ条件、テスト方針、PR説明項目、リスクを書いたうえで、最小差分で実装してください。」

なぜ重要か：Definition of Doneが曖昧だと、Claude Codeは見た目上それらしい完成形を出します。しかしレビューでテスト、例外系、リリース観点が抜けると、スプリント終盤に手戻りが出ます。

失敗3：権限を広げすぎる

❌「面倒だから常にbypassPermissionsで使う」

⭕「通常はdefaultまたはplanから始め、必要な範囲だけallowし、危険操作はdenyまたはaskにする。」

なぜ重要か：公式ドキュメントでもbypassPermissionsは隔離されたコンテナやVM向けの位置づけです。チームの通常開発では、permissionsとhooksで境界を作る方が安全です。

失敗4：AI利用を個人技にする

❌「使いたい人だけが、それぞれ好きに使う」

⭕「チームのCLAUDE.md、issueテンプレート、PRテンプレート、レビュー基準をそろえる。」

なぜ重要か：Claude Codeの利用が個人技になると、強い人だけが速くなり、チームの透明性はむしろ下がります。スクラムに入れるなら、作業協定として共有する必要があります。

FAQ：Claude Code×スクラム開発でよくある質問

Q1. Claude Codeを入れるとスクラムマスターは不要になりますか？

不要にはなりません。Claude Codeは差分整理、ブロッカー候補の抽出、レトロ材料の整理を支援できますが、チーム合意、対話促進、組織的な障害除去は人間の役割です。

Q2. スプリントプランニングでClaude Codeに見積もりさせてもよいですか？

見積もりの材料を出させるのは有効ですが、ポイントや容量判断をClaude Codeだけで決めるのは避けた方が安全です。変更範囲、未確定事項、テスト観点を出し、最終判断はチームで行います。

Q3. Plan modeは毎回使うべきですか？

毎回ではありません。公式ベストプラクティスでも、Plan modeは複数ファイル変更、不慣れなコード、方針が不明な作業に向く一方、小さな修正ではオーバーヘッドになると説明されています。

Q4. MCPでJiraやGitHubにつなぐ時の注意点は？

最初は読み取り中心で始め、書き込み権限は段階的に広げるのが現実的です。issue更新、PR作成、Slack投稿などは便利ですが、所属組織のセキュリティ規程と監査方針に従ってください。

Q5. hooksでテストを強制すれば品質は上がりますか？

品質向上を支援できますが、hookを重くしすぎると開発体験が悪化します。最初はformatや軽いlintから始め、チームが納得した範囲でテストやStop hookを追加するのが安全です。

Q6. agent teamsはスクラムチームで使うべきですか？

すぐに使う必要はありません。公式ドキュメント上でもexperimentalで無効が初期状態です。使う場合は、実装よりも調査、レビュー、技術スパイクに限定し、トークン使用量と調整コストを見ながら判断してください。

Q7. Claude Codeの成果は何で測るべきですか？

単純な「何パーセント削減」ではなく、PR作成までの時間、レビュー待ち時間、再レビュー回数、CI失敗から復旧までの時間、未確定事項の持ち越し数など、スクラムチームが継続して観測できる指標で見るのがおすすめです。

Q8. 非エンジニアのPOやPMもClaude Codeを使えますか？

コード編集ではなく、受け入れ条件、非対象、レビュー観点、リリース説明の整理に使えます。ただし、仕様判断や優先順位判断はPO/PMの責任であり、Claude Codeの出力は補助として扱ってください。

参考・出典

• Claude Code Overview — Anthropic（参照日: 2026-07-07）
• Choose a permission mode — Anthropic（参照日: 2026-07-07）
• Configure permissions — Anthropic（参照日: 2026-07-07）
• Claude Code settings — Anthropic（参照日: 2026-07-07）
• How Claude remembers your project — Anthropic（参照日: 2026-07-07）
• Connect Claude Code to tools via MCP — Anthropic（参照日: 2026-07-07）
• Hooks reference — Anthropic（参照日: 2026-07-07）
• Create custom subagents — Anthropic（参照日: 2026-07-07）
• Orchestrate teams of Claude Code sessions — Anthropic（参照日: 2026-07-07）
• Claude Code GitHub Actions — Anthropic（参照日: 2026-07-07）

まとめ：次のスプリントで始める3つのアクション

1. 今日やること：次スプリント候補のissueを1つ選び、Plan modeで影響範囲、未確定事項、テスト観点を整理する。
2. 今週中にやること：DoR、DoD、PR説明項目をCLAUDE.mdへ書き、チームでレビューする。
3. 今月中にやること：軽いPostToolUse hook、permissions、レトロ改善ループを1リポジトリだけで試す。

あわせて読みたい記事として、チーム展開はClaude Codeチーム展開ガイド、法人導入はClaude Code法人導入ガイド、Plan modeの具体運用はClaude Code Plan Mode実践ガイド、権限設計はClaude Code権限設計チームガイドを参照してください。

次回予告：次の記事では、Claude Codeを使ったスプリントレビュー資料とリリースノート作成の実務フローを扱います。

著者プロフィール

佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。

Claude Codeのチーム導入やスクラム運用で整理したい論点があれば、お問い合わせフォームからご相談ください。

あわせて読みたい

• ▸ 【2026年7月】Claude 5コンテキスト新ルール×CLAUDE.md実践
• ▸ 【2026年】Claude Opus 5をClaude Codeで使う移行実務
• ▸ AIソフトウェア工場はなぜ失敗するか｜Claude Code並列運用の3つの律速
• ▸ 【2026年最新】Claude Codeのシークレット管理｜秘密情報を守る7原則
• ▸ 【2026年最新】Claude Code×Kubernetes運用術｜実践7選