Claude Media
Claudeのsprint-planningスキルでスプリント計画と容量見積もりを作る
Claude CodeCoworkClaude連携チュートリアル

Claudeのsprint-planningスキルでスプリント計画と容量見積もりを作る

product-managementプラグインのsprint-planningスキルは、休暇と会議を引いた容量見積もり、P0からP2の優先度、繰り越しの扱いまでを1枚の計画書にします。入力の渡し方と検算のやり方を扱います。

読了目安 約12分

sprint-planningは、Anthropicが公開しているproduct-managementプラグインに入っているスキルです。チームの稼働状況とバックログを渡すと、スプリントの目標、メンバーごとの容量、P0からP2までの作業一覧、リスク、完了の定義、主要な日付を1つの計画書にまとめます。

中身はMarkdown1本のSKILL.mdで、全体で94行です。短いぶん、何を渡せば何が返るかが読み取りやすいスキルです。この記事では、入力の組み立て方、容量見積もりの検算、優先度と繰り越しの扱い、カレンダーやトラッカーとの接続状況を順に見ていきます。プラグイン全体の概観はClaude部門別プラグインの使い方にあります。

sprint-planningスキルは何を作るのか

SKILL.mdのdescriptionは、新しいスプリントの立ち上げ、PTO(休暇)と会議を考慮したバックログの見積もり、P0とストレッチの切り分け、前スプリントからの繰り越しの扱いを使いどころとして挙げています。呼び出しは/sprint-planningの1行です。

スキルが尋ねる入力は5項目あります。

入力内容
Team内容誰がチームにいて、今回何日稼働できるか
Sprint length内容何日、何週間か
Backlog内容優先度つきの作業(トラッカーから取得、貼り付け、口頭のいずれも可)
Carryover内容前スプリントの未完了分
Dependencies内容他チームの作業待ちになっているもの

出力のひな形は、次の7ブロックです。

  • スプリント名・期間・人数・スプリントゴール(成功の姿を1文で)
  • Capacity表(人ごとの稼働日、割り当て、休暇や当番のメモ)
  • Sprint Backlog表(P0・P1・P2、見積もり、担当、依存)
  • 計画した容量と実際の負荷の比率
  • リスク表(リスク、影響、対策)
  • Definition of Done(コードレビューとマージ、テスト通過、必要ならドキュメント更新、プロダクト承認)
  • 主要日程(開始、中間確認、終了とデモ、レトロスペクティブ)

「スプリントゴールは1文で書ける状態にする」という考え方が、ひな形の最初の行に出ています。1文で言えないならスプリントの焦点がぼやけている、というのがSKILL.md末尾のTipsの1つ目です。

導入と呼び出し — Claude CodeとCowork

導入はREADMEにある2行です。

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install product-management@knowledge-work-plugins

Claude Codeの公式ドキュメントでは、プラグインのスキルは/プラグイン名:スキル名の形で呼び出します。product-managementのsprint-planningなら、次のようになります。

/product-management:sprint-planning Sprint 42 (10/28-11/8)

SKILL.mdのargument-hintは[sprint name or date range]で、スプリント名か日付範囲を引数に取る想定です。本文の呼び出し行にある$ARGUMENTSは、入力した引数に置き換わります。インストール後にスキルが見えないときは、/reload-pluginsコマンドで再起動なしに反映できます。マーケットプレイスの仕組みはClaude Codeプラグイン完全ガイドが詳しいです。

READMEは、このプラグインを「主にCowork向けに設計され、Claude Codeでも動く」と説明しています。

渡す情報で計画の質が決まる

スキルはStandalone、つまり何も接続していなくても動く構成を最初に挙げています。実際に動かすときは、5項目を1つのメッセージにまとめて渡す形が扱いやすいです。次は、架空のチームを想定した入力例です。

/product-management:sprint-planning Sprint 42 (10/28-11/8)
 
Team: 4名(A, B, C, D)。スプリントは平日10日
休暇: Bは11/4-11/5、Cは11/7
会議: 計画・レビュー・レトロ・リファインメントで1人あたり1日
Backlog(優先順):
  1. 請求書PDFの出力 (大)
  2. 通知設定画面の刷新 (中)
  3. 検索のバグ修正3件 (小)
  4. 管理画面のCSV出力 (中)
Carryover: 通知APIの移行(残り約3日分、レビュー待ちで止まった)
Dependencies: 請求書PDFは経理チームのテンプレート確定待ち

ここで気をつけたいのは、SKILL.mdの5項目に過去のベロシティ(実績の消化量)が含まれていない点です。見積もりを人日で出すのか、ポイントで出すのかも、スキル側は決めていません。出力ひな形の割り当て欄がpoints/hoursとだけ書かれているためです。チームのポイント換算や直近の消化実績は、入力で自分から渡す必要があります。

前と後

入力の渡し方で変わる点

BEFORE

バックログだけ渡す

人数も休暇も会議も書かないと、Capacity表の根拠になる稼働日が決まりません。計画書の形式は整っても、数字は推測で埋まります。

AFTER

5項目と換算ルールを渡す

稼働日、休暇、会議、繰り越し、依存先を文面に入れると、Capacity表とリスク表の各行に理由が残ります。ポイントの換算も書いておくと、見積もりの単位が揃います。

容量見積もりを手で検算する

スキルが示すのは表の形と、緩衝を持たせるという考え方までです。容量を計算する式は書かれていません。出力された数字は、次のような手順で検算できます。上の入力例を使った算術です。この表はここで組んだ例で、スキルの出力そのものではありません。

メンバー平日休暇会議等計画に使える日数
A平日10休暇0会議等1計画に使える日数9
B平日10休暇2会議等1計画に使える日数7
C平日10休暇1会議等1計画に使える日数8
D平日10休暇0会議等1計画に使える日数9
合計平日40休暇3会議等4計画に使える日数33

SKILL.mdのTipsは「容量の70〜80%で計画する。割り込みは必ず入る」と書いています。33人日にこれを当てはめると、23.1から26.4人日が計画の目安になります。

  • 70%の場合: 33 × 0.7 = 23.1人日
  • 80%の場合: 33 × 0.8 = 26.4人日

Claudeの出力にある「Planned Capacity」と「Sprint Load」の比率が、この範囲に入っているかを見ます。範囲を超えているなら、バックログの合計が積み過ぎです。逆に、休暇を引き忘れていれば、合計が40人日側にずれます。Capacity表のAllocation列を見れば、どこで数字がずれたかが追えます。

落とし穴

Sprint Loadの分母がどの容量か取り違える

比率の分母が、休暇を引く前の40人日なのか、引いた後の33人日なのかで、負荷の数字は変わります。同じ26人日を積んでも、前者なら65%、後者なら約79%です。Claudeが表に書いた分母を、必ず確かめてください。

P0・P1・P2と繰り越しの扱い

Sprint Backlogの優先度は、P0が「出荷必須」、P1が「出荷すべき」、P2が「ストレッチ」と、ひな形のプレースホルダに書かれています。Tipsの3つ目は、ストレッチ項目を特定しておき、作業が長引いたときに何を切るかを把握しておくことです。

70〜80%という目安と組み合わせる一つの組み方があります。

  1. P0の合計を、容量の70%の線(上の例では約23人日)に収める
  2. P1までで、80%の線(約26人日)に近づける
  3. P2は、想定どおりに進んだ場合だけ手をつける項目に回す

この3段階は、スキルが定めた手順ではなく、Tipsを読み合わせた運用例です。チームによってP0に割く割合は変わります。

繰り越しについては、Tipsの4つ目が「正直に繰り越す。出荷できなかったなら、再びコミットする前に理由を理解する」と書いています。入力のCarry over欄に残りの工数と止まった理由を書いておくと、計画書にはリスク表の行としても反映しやすくなります。上の入力例のように、残量(3日分)と原因(レビュー待ち)をセットで渡す書き方です。

入力

繰り越しを渡すときの3点

  • 残りの工数

    元の見積もりではなく、今から終えるまでの残りを書きます。

  • 止まった理由

    レビュー待ち、依存先待ち、見積もり不足など、理由で扱いが変わります。

  • 担当の変更

    メンバーが休暇で外れるなら、担当替えの要否も入力に含めます。

カレンダーとトラッカーは接続されているか

スキルは、接続したツールで強化される構成を最初から想定しています。SKILL.mdの図は次の3つを挙げています。

  • プロジェクトトラッカー: バックログの取得、スプリントの作成、項目の割り当て
  • カレンダー: 容量に反映する休暇と会議の取得
  • チャット: スプリント計画をチームに共有

product-managementプラグインの.mcp.jsonには、Slack、Linear、Asana、monday.com、ClickUp、Atlassian、Notion、Figma、Amplitude、Pendo、Intercom、Fireflies、Google Calendar、Gmail、Similarwebの接続先が並びます。トラッカーに当たるのはLinear・Asana・monday.com・ClickUp・Atlassianです。

ただし、カレンダーまわりには見落としやすい点があります。.mcp.jsonのgoogle calendarのurlは空文字になっていて、gmailも同様です。ほかの接続先はURLが書かれています。このファイルだけでは、Google Calendarに接続できる状態にならないということです。

休暇と会議の取り込みをカレンダー接続に任せようとしていたなら、先に接続が成立しているかを確かめます。接続できていないときは、上の入力例のように休暇と会議を文面で渡せば、スキルは単体でも動きます。Jira側の集計を使ったレポート作成はClaudeでJiraスプリントレポートを作る方法で扱っています。

自チームの流儀をプロジェクトに書いておく

スキルの入力5項目のうち、スプリントごとに変わらない部分は毎回打ち直すと手間です。プラグインのファイルを書き換えずに、Claude Codeのプロジェクト側に前提を置く方法があります。

たとえば、リポジトリのCLAUDE.mdに次のような節を置くと、毎回の入力が短くなります。これはここで組んだ書き方の例です。

## スプリント計画の前提
- スプリントは平日10日、隔週火曜開始
- 会議は1人あたり1日(計画・レビュー・レトロ・リファインメント)
- 見積もり単位は人日。1ポイント = 0.5人日で換算する
- 計画の負荷は容量の70〜80%に収める
- 直近3スプリントの消化実績: 24, 27, 22 人日
- P0は顧客約束のある項目だけ。社内都合はP1以下

直近の消化実績を書いておくと、5項目に入っていない過去のベロシティを補えます。スキルの出力が、実績の範囲を大きく超えた負荷を示していれば、見直しの合図です。

計画書を共有する前の確認

計画書をチームに配る前に、次の点を見ます。

  • Capacity表の稼働日が、休暇と会議を引いた数字になっているか
  • Sprint Loadの比率が、容量の70〜80%の範囲に収まっているか
  • P0に、依存先待ちの項目が混ざっていないか(依存先が止まれば、P0が出荷できなくなります)
  • 繰り越しの項目に、残りの工数と理由が書かれているか
  • Definition of Doneの4項目が、チームの実際の基準と合っているか

Definition of Doneの項目は、ひな形では4つのチェックボックスです。チームの基準が違うなら、CLAUDE.mdに自チームの基準を書いておくか、出力を直してから共有します。

まとめ

sprint-planningは、容量を計算する式ではなく、計画書の型と運用上の目安を与えるスキルです。数字の根拠は、渡した入力で決まります。休暇、会議、繰り越し、依存先、それにチームの換算ルールと消化実績を最初に渡し、Capacity表の分母とSprint Loadの比率だけは自分で検算する、という使い方が合っています。カレンダー接続に頼る場合は、.mcp.jsonのURLが空である点を先に確かめてください。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →