sprint-review-document

name	sprint-review-document
description	作成手順「sprint-review-document」（self-evolving-agent から自動同期）: スプリントレビュー資料作成手順

スプリントレビュー資料作成手順

用途: Event Discovery チーム（またはその他スクラムチーム）のスプリントレビュー向け骨子・資料を workspace/sprint-review.md 等に作成するとき。

1. 対象読者を冒頭に明記

• PM（Oz・Meicy）や外部パートナー（電通等）が読む前提なら、冒頭ヘッダーに想定読者を記載する。
• 技術詳細より 成果の可視化 を優先し、冒頭30秒でスキャンできる表形式を使う。

2. 必須4セクション構成

セクション	要点
ゴール達成状況	表形式で「ゴール / 状況（✅/⚠️/❌）/ 補足」を並べる
主要アウトプット	リリース・品質・プロセス改善など軸を設けて分類
学びと課題	「課題 → 根本原因 → 対処アクション・担当・期限」まで記述。課題羅列で終わらせない
次スプリントへの引き継ぎ	優先度付き（🔴高/🟡中/🟢低）。クロスチーム作業は「TimeTree側 / パートナー側」で責任分担を明示

3. 空セクションを避ける

• 素材がないセクションは 省略するか構造だけ残す。余白目的の空セクションは入れない。
• 「メモ」「その他」のような汎用セクションを追加する場合は、最低1件の内容を入れるか省略する。

4. プレースホルダー管理

• 未確定の数値・日付・担当者は [説明付きラベル]（例: [タイムゾーン P1 担当者]）で明示する。
• Result冒頭に「埋める項目リスト（番号付き）」を置き、Andy が最初に何をすべきか明確にする。

5. クロスチーム連携タスク

• 電通など外部チームとの連携タスクは、「TimeTree側アクション / 電通側アクション / 期限」の列構成で表にまとめ、責任の曖昧さを排除する。

6. 素材から内容を積極的に推測する

• 「次スプリントゴール」「引き継ぎアクション」など、素材から論理的に導ける内容は、[チームで合意するその他ゴール] のような汎用プレースホルダーを避け、素材を根拠にした具体的な案を記述する。
  • 例: 今スプリントの素材に「AIコードレビューのパイロット開始」があれば、次スプリントゴールに「AIコードレビューパイロットの評価完了」と記載する。
• （要確認） を付けてよい条件: 素材から距離のある 創造的推測（素材にない別ゴール設定、数値予測、因果が飛躍する推論）のみ。
• （要確認） 不要の条件: 素材から 直接論理的に導ける結果（「X を開始した → 次スプリントで X を評価」「Y が未完了 → 次スプリントで完了」のような A → 次A パターン）は確認不要で記述する。過剰に （要確認） を付けると骨子が自信なさげに見える。
• 素材中に明示された事実（例: 「リリース完了」）は、該当セクションを完全なプレースホルダーにせず、最低1行その事実を反映した記述を入れる。
• 汎用プレースホルダーを残してよいのは、素材から推測できる手がかりが何もない場合のみ。

7. 文書の日付

• 「作成日」には 今日の日付を自動的に使わない。スプリント終了日またはレビュー実施日（素材から読み取れる場合）を使い、読み取れない場合は [レビュー実施日: YYYY-MM-DD] プレースホルダーを残す。
• 作成日とスプリント終了日が大きく乖離すると、ステークホルダーが文書の鮮度を誤解する。