スクラムのイベント（リファインメント）を支える Claude Code スキルの設計

公開日：2026/10/26

こんにちは、FREEMINDの開発部です。

近年、AIエージェントを使用したcodingが進んでおり、私はClaude Codeのskills機能を使用してcodingを行うことが多くなりました。

今回は、弊社の勉強会の延長として取り組んでいるアプリ開発にて作成したスキルを紹介します。

まず、スクラムの流れを「プランニング」「リファインメント」「実装」「レトロスペクティブ」に分け、それぞれにスキルを作成してスムーズに進められるよう設計しました。

本記事では、そのスキルの中身と、設計で気をつけた点を紹介します。プランニングや実装のスキルも用意していますが、ここではリファインメントに絞ります。

リファインメントとは？

プロダクトバックログアイテムを、スプリントプランニングで選択できる状態にするために、分割したり詳細を加えたりする継続的な活動です。今回は、次のスプリントに入りそうな issue が着手できる状態かを診断し、Epic の依存関係を洗い出して分割する場として運用しています。

1. 前提：バックログは GitHub で管理している

プロダクトバックログもスプリントバックログも、GitHub Issues に置いています。優先順位（PRIORITY）・見積もり（ESTIMATE）・実施スプリント（ITERATION）は、GitHub Projects のフィールドで持たせています。

issue の粒度は 2 つです。大きい単位の Epic と、Epic を分割した task です。task は sub-issue として親（Epic）にぶら下がります。

GitHub Projects のバックログ（内容はサンプル）

2. 3 つのスキルで役割を分けた

スキル	役割
refinement	進行役。会全体を仕切る
compose-issue	issue の本文を書く
decompose-issue	issue を分ける

進行役の refinement は、次の順で動きます。

候補を集める — 次のスプリントに入りそうな issue を洗い出す
一つずつ診断する — 「このまま着手できる状態か」を判定する
議題リストを出して合意する — 何を扱うか、人に決めてもらう
担当スキルへ渡す — 本文が薄ければ compose-issue、大きすぎれば decompose-issue
記録を残す — 扱った issue にコメントし、セッションの要約を作る

3. 着手できる状態かを診断する

issue の状態は Definition of Ready の考え方で判定します。

補足：Definition of Ready（DoR）とは

「この issue は、スプリントで着手できる状態になっているか」を判断する目安です。スクラムガイドの正式な要素ではありませんが、Definition of Done（完成の定義）と対になる考え方として広く使われています。

判定には INVEST という 6 つの観点を使い、次の３段階で評価します

✓（問題なし）　△（気になるが致命的ではない）　✕（手を入れた方がいい）

機械的に測れるものは数字にしました。たとえば S（Small）は「数時間〜数日で終わる作業規模か」です。

診断結果	次にやること
本文が空・薄い	本文を書く
大きすぎる	縦に分割する
分からないことがある	調査タスクを切り出す
隣の issue との境界が食い違っている	両方を直す
受け入れ条件が曖昧	本文を補強する
大きめで、まだ作業に分けていない	タスクに分解する
問題なし	何もしない

この表には、意図的に「止める側」のルールを 2 つ入れています。

△ は議題に載せない — 指摘をすべて拾うと、リファインメントが終わらないため
問題がなければ何もしない — 最後の行にわざわざ書いておかないと、改善案が出続けるため

もうひとつ、診断をスプリント投入の関門にはしていません。スキルには次のように書いています。

DoR はゲートではなくガイドライン。「Ready 未達」を理由にスプリント投入を拒否・保留する提案をしない。診断は案内であって門番ではない。

投入するかどうかは、プランニングで PO と開発者が話し合って決めることで、AI が判断することではありません。

4. 依存関係は「分けるとき」に決める

タスクに分けると「A が終わらないと B を始められない」という関係が出てきます。この関係を、実装のときではなくEpic-issue分割時に洗い出します。手順は 3 ステップです。

Step 1：触る場所にタグを付ける

各タスクがどこを触るかを推定し、タグを付けます。判定材料は、issue 本文のファイルパス、ラベル、タイトルや本文のキーワードです。

タグ	該当条件
`shared`	共通の型・スキーマを変更する
`db`	DB のエンティティ定義を変更する
`api`	サーバー側だけを変更する
`web`	フロント側だけを変更する
`infra`	インフラ定義を変更する

Step 2：4 つのルールを順に当てる

タグが付いたら、ルールを順番に適用します。ポイントは、それぞれに理由を書いてあることです。

ルール	内容	理由
R1	shared / `db` を変更するタスクは、必ず最初の Wave に入れる	型の定義元が変わると、参照側の型チェックが壊れるため
R2	同じ Epic-issueに `api` と `web` があれば、`web` は `api` に依存させる	フロントはサーバー側の型を参照しているため
R3	インフラを触るタスクは、同じ Wave に 2 つ入れない	Terraform などの状態ファイルはロックされるため、同時に適用しようとすると片方が待たされたり失敗したりするため
R4	同じファイルを変更する見込みのタスクは、順番に並べる	並列にしてもマージで衝突するため

Step 3：Wave に分ける

依存が出そろったら、着手できる順にタスクを束ねます。この束を Wave と呼んでいます。依存先がすべて完了しているタスクを 1 つの Wave にまとめ、それが終わったら次の Wave へ移ります。循環している場合はエラーにします。

1 つの Wave に入れる上限は 3 つです。API の同時実行制約とディスク負荷、そして 人が一度に追える PR の数が理由です。並列にできても、レビューが追いつかなければ意味がありません。

なお、ルールで導けるのは「構造上こうなるはず」という依存だけです。「この機能を先に作らないと次の判断ができない」といった業務上での依存は、推測させずに対話で確認します。

記録は 2 か所に残す

洗い出した依存関係は、2 つの形で記録します。

親 issue の本文に、mermaid の図と Wave の表で — 人が読むため
子 issue に、GitHub の依存関係の機能で — 機械が読むため

親 issue の本文は、次のような形になります（内容はサンプルです）。GitHub は本文中の mermaid を描画するため、issue を開くだけで実装順序が見えます。

親 issue に載せる依存関係図（GitHub 上では mermaid で描画）。点線は親 issue の外にあるタスク

Wave	task	pt	blocked by
1	#31 コメントのエンティティ + 型定義（`db` `shared`）	2	—
2	#32 コメント投稿 API（`api`）	3	#28, #31
2	#33 コメント一覧取得 API（`api`）	2	#31
3	#34 コメント表示・投稿 UI（`web`）	3	#32, #33

図には、親 issue の外にあるタスク（#28）も描きます。どこで待ちが発生するかが一目で分かるようにするためです。

5. 分割と本文作成に置いた制約

分割案には、3 つの問いを当てる

大きい issue を分けるとき、放っておくと「まずスキーマ」「次にサーバー側」「最後に画面」という切り方になりがちです。技術の層ごとに分ける切り方で、どの断片も単体では動きません。

スクラムで求められるのは、小さくても動くものを 1 つずつ積み上げる形です。そこで、分割案には必ず次の 3 つを確認させています。

この断片だけを、ユーザーに見せられるか
この断片だけを、捨てられるか
断片どうしの大きさは、だいたい揃っているか

1 か 2 が「いいえ」なら、切り方が間違っています。

本文には、書きすぎない制約を置く

制約	理由
書く項目を 4 つに固定する（ストーリー / 受け入れ条件 / 含まないもの / 参照）。全体で 2500 字以内	項目を自由にすると、際限なく書き足されるため
1 セクションずつ確認する。選択肢は多くて 4 つまで	まとめて聞かれると、人は読まずに承認してしまうため
新規作成時は、似た issue を先に検索する	既存 issue との重複を防ぐため
生成後に自己点検させる	曖昧な言葉や、観測できない受け入れ条件が残るのを防ぐため