はじめに
EMやテックリードをやっていると、週のどこかで必ず「この時間、本当に必要か」と思う作業がある。バックログのチケット整理、スプリントプランニング前の容量計算、レトロスペクティブのまとめ——どれも重要だが、頭を使っているというより手を動かしているだけの時間が長い。
あらかじめ断っておくと、この記事は四半期や年次の技術ロードマップを立てる話ではない。2週間スプリントの日常運営を楽にするための実践だ。毎週のバックログリファインメントに費やす1〜2時間、レトロのまとめに費やす30〜60分——そういう細かいが積み重なる時間泥棒に、Claude Codeをどう使うかという話をする。
ROADMAP.mdで「今どこにいるか」を毎回説明しない
Claude Codeとの会話を始めるたびに「今のプロジェクトはこういう状況で」と説明し直すのは、じわじわとストレスになる。これを解決するシンプルな方法が、ROADMAP.mdをリポジトリに置くことだ。
ブロガーのBen Newtonが実践しているのは、プロジェクトの「中央神経系」としてROADMAP.mdを機能させるやり方だ。
# ROADMAP.md 構造例
<h2>高優先度</h2> - [ ] ユーザー認証リファクタリング（8pt） - [-] 🏗️ 検索機能改善 [2026-04-12 開始]
<h2>中優先度</h2> - [ ] レポートエクスポート機能（5pt）
<h2>完了</h2> - [x] ✅ パフォーマンス最適化 [2026-04-10 完了]
CLAUDE.mdにこう書いておく。
<h2>プロジェクト管理ルール</h2>
- 作業開始前に必ずROADMAP.mdを確認する - タスク開始時に [-] と🏗️タイムスタンプを追加 - 完了時に [x] と✅タイムスタンプを更新
これだけで、Claude Codeは毎回「今どこにいるか」を把握した状態で作業を始める。数週間ぶりにプロジェクトに戻ってきたときも、ファイルを読めば文脈が揃っている。コードと同じ場所にプロジェクト状態を置くことで、新メンバーのオンボーディングにも使える。
スプリント計画の準備をClaude Codeに任せる
Backlog.mdが整備されていれば、プランニング前の容量計算をClaude Codeに任せられる。
Backlog.mdの未着手チケットを読んで、今スプリント（10営業日、
チーム5名・1人あたり6pt/日）に収まる組み合わせを提案して。 優先度・依存関係・見積もりを考慮して。
プランニング会議に入る前の段階で「このスプリントに収まる候補と優先度の根拠」が揃っている状態を作れる。議論の出発点がデータになる。
コーディング中にバックログを追加したいときも、スプレッドシートを開かずに済む。`/add-backlog` というカスタムスラッシュコマンドを定義しておけば、コードを書きながら気づいた技術的課題をそのままBacklog.mdに追記できる。Brent Petersonが実践しているこのやり方は、コンテキスト切り替えのコストを下げるという意味で地味に効く。
なお、チーム全員でAPIベースのバックログを共有したい場合は、Memory MCPやSlack MCPと連携したBacklog APIを構築するという方法もある。実装ハードルは高いが、本格的な運用を考えるなら参考になる。
レトロのまとめ・バグ対応を自動化する
スプリント終了後のレトロスペクティブで、EMが最も時間を使うのは「付箋の山を整理して議事録にまとめる」作業だ。MiroやデジタルホワイトボードのテキストをそのままClaudeに貼り付けると、30〜60分かかっていた作業がほぼゼロになる。
以下のレトロスペクティブのメモを整理して。
「うまくいったこと」「改善したいこと」「アクションアイテム（担当者・期限付き）」 の3セクションにまとめて、Confluence/Notionに貼れる形式で出力して。
[レトロメモをここに貼る]
単純な整理ではなく「担当者・期限付きのアクションアイテム」まで出力させるのがポイントだ。会議の最後に「では誰がやる？」という曖昧な締め方をせずに済む。
バグ対応の優先順位整理も似た構造だ。
Backlog.mdの「バグ」ラベルがついたチケットを優先度順に並べて。
各チケットについて「再現手順」「影響範囲」「推定修正時間」を コードベースを読んで補足してほしい。
実際に取り組んだチームでは、バグ対応にかかる時間が大きく短縮されたという報告がある。コードを読んで影響範囲を推定する作業をClaudeが担うことで、エンジニアは「これを今スプリントで直すべきか」という判断に集中できる。
スプリント終盤にバーンダウンが想定より遅れているときも、こういうプロンプトが使える。
このスプリントのバーンダウンが想定より遅れている。
残りチケットの見積もりを見直して、今スプリント内で完了できそうなものと 次スプリントに移すべきものを分けて提案して。
「どれを諦めるか」の議論の前に、選択肢と根拠が整理された状態を作れる。
スクラムマスター サブエージェントというパターン
GitHub上の awesome-claude-code-subagents（VoltAgentが公開）では、Claude CodeのサブエージェントにScrum Masterロールを定義するパターンが公開されている。スプリント計画の促進、デイリースタンドアップ管理、レトロスペクティブ促進、バックログリファインメント、メトリクス追跡など8つの機能を委譲できる設計だ。
設計仕様上の想定数値として平均ベロシティ47ポイント（予測可能性95%）・チーム満足度8.2/10などが示されているが、これは実際の効果ではなく設計時の想定値だ。実際の効果はチームの状況やコードベースによる。
このパターンで重要なのは数値よりも役割分担の考え方だ。「進行・記録」をサブエージェントが担い、「対話・合意形成」に人間が集中するという設計。プランニング会議の前にClaudeが容量計算と候補を整理し、会議本番では人間が優先度の議論だけをする——そういう分業が実現できる。
「整理・可視化」はAIに任せ、「判断」に集中する
バックログリファインメント・レトロまとめ・進捗レポートといった作業は、重要だが頭を使っているとは言い難い。Claudeが最も得意な「構造化・整理・可視化」の領域だ。
EMが本来使うべき時間は、1on1でメンバーの状態を把握すること、アーキテクチャの判断、チームの優先度をビジネスと擦り合わせること——こういう「整理ではなく判断」を要する仕事だ。
ただし、限界は明確にしておく必要がある。ビジネス価値・技術リスクの最終判断はEMが下す。Claude Codeに任せていいのは「整理・可視化・候補提示」までだ。また、Jiraなど既存ツールとBacklog.mdの二重管理になるリスクもある。どちらをSingle Source of Truthにするかをチームで決めておかないと、どちらも信頼されなくなる。
アジャイルセレモニーの自動化を進めすぎると、セレモニー本来の意義——コミュニケーションや共有理解の形成——が薄れる可能性もある。Claude Codeは「準備と記録」を担う存在として位置づけ、場そのものは人間が作る、というバランスが現実的だと思っている。
まとめ
スプリントの日常運営で発生する「地味な重さ」は、少しずつ対処できる。
一番ハードルが低いのはROADMAP.mdをリポジトリに置くことだ。30分でできるし、毎回の「状況説明」がなくなる。次のプランニング前に容量計算プロンプトを一度投げてみると感覚がつかめる。レトロ後の付箋テキストも、整理させてみると「案外これでいけるな」と思うはずだ。
週1〜2時間使っていた整理作業が少しずつ減っていく。空いた時間を、メンバーとの対話と判断に使ってほしい。
コメント