standup-meeting

スタンドアップミーティング

このスキルは、曖昧な日々の調整を、1つの誠実な頻度の判断、1つの小さな根拠資料、1つのフォローアップ経路にまとめる必要がある場合に使用します。

standup-meeting が扱うもの：

• 日々の調整における頻度の実態
• 定例の同期が妥当な場合のスタンドアップ形式の選択
• ブロッカー／引き継ぎの可視化
• 短い進行フローと更新テンプレート
• 中核となる同期とフォローアップの小規模な打ち合わせの明確な切り分け
• ステータス報告だけの場になることを防ぐガードレール
• 毎日の儀式が妥当でない場合に、less-frequent／no recurring standup の結果を明示

特殊なケースや、依頼の範囲が広がり始めた場合は、以下のリファレンスを読んでください：

• references/cadence-gates-and-exceptions.md
• references/facilitation-modes.md
• references/intake-packets-and-route-outs.md

このスキルを使う場合

• ユーザーが、毎日のスタンドアップ、デイリースクラム、デイリー同期、または非同期チェックインの形式を求めている。
• チームが、ボードウォーク、ブロッカー優先、非同期、ハイブリッド、従来の3つの質問によるスタンドアップのいずれかを選ぶ前に、毎日のライブ開催が依然として妥当か判断する必要がある。
• 毎日の儀式が長引きすぎている、ステータス報告に流れている、または横道の議論が多すぎる。
• リモートまたはハイブリッドのチームが、ブロッカーや引き継ぎを調整するための、より軽量な方法を必要としている。
• リリース／マイルストーン／火消し対応の期間に、一時的な毎日の開催が妥当となる場合がある。通常はより軽量な方法が適切な場合でも同様。
• 次に作成すべき成果物が、頻度の判断、形式（該当する場合）、エスカレーション経路をそれぞれ1つずつ示す調整頻度ブリーフである。

このスキルを使わない場合

• 本当の目的が、バックログの分解、スプリント準備、または実行可能な粒度への分割である → task-planning。
• 本当の目的が、見積もり、確信度の提示、またはキャパシティに関する意見の相違である → task-estimation。
• 本当の目的が、プロセスの振り返り、定例の儀式に関する問題、またはデリバリー後のアクションの実行である → sprint-retrospective。
• 本当の目的が、障害対応の指揮、リリース対応の対策会議、またはインシデントのトリアージである → デバッグ／インシデント／リリース固有のスキル。
• ユーザーが主に、マネージャー向けのステータス収集やパフォーマンス報告を求めている。このスキルが対象とするのは横方向の調整であり、上向きの見せかけの報告ではありません。

手順

ステップ1：まず頻度を分類し、必要な場合のみ主要な形式を1つ選ぶ

形式を提案する前に、依頼の内容を整理してください。

standup_intake:
  cadence_decision: live-daily | async-daily | hybrid-daily | less-frequent-sync | no-recurring-standup
  primary_mode: board-walk | blocker-first | async-check-in | hybrid-async-plus-live | classic-three-questions | none
  team_shape: colocated | hybrid | distributed | cross-functional | unknown
  work_source: jira | linear | github-projects | trello | docs | hacknplan | mixed | unknown
  main_problem:
    - blockers-hidden
    - too-long
    - status-theater
    - timezone-friction
    - board-stale
    - too-many-side-discussions
    - low-dependency-work
    - ritual-inertia
    - unclear
  current_signal: strong-board | weak-board | weak-updates | mixed | unknown
  delivery_risk: low | medium | high
  escalation_need: low | medium | high | unknown
  output_shape: coordination-cadence-brief | template-only | facilitation-reset | unknown

1回の実行につき、頻度の判断は必ず1つだけにしてください：

• live-daily — 現在のブロッカー／依存関係の圧力により、毎日のライブ同期が妥当
• async-daily — 毎日の可視性は引き続き重要だが、ライブ参加の負担が大きすぎる
• hybrid-daily — 毎日の更新は文章で行い、ライブでの話し合いは例外的な場合のみ
• less-frequent-sync — 定例のチェックポイントには依然として利点があるが、毎日は過剰
• no-recurring-standup — 儀式的な毎日の同期よりも、ボード／ドキュメントの可視化と必要に応じたエスカレーションのほうが適している

頻度に定例のスタンドアップ形式が含まれる場合に限り、主要な形式を1つ選んでください：

• board-walk — 会話はボードを中心に進める
• blocker-first — 今日の主な目的は、障害を明らかにし、迅速に支援につなぐこと
• async-check-in — 文章での更新を標準とし、ライブでの話し合いは任意
• hybrid-async-plus-live — まず文章で可視化し、その後、短いライブのエスカレーションを行う
• classic-three-questions — チームが小さく、この形式から実際に有用な情報が得られる場合に限る
• none — 最適な答えが no-recurring-standup の場合に使用

複数の頻度や形式を混ぜて、曖昧な回答にしないでください。

ステップ 2：信頼性のある最小限の調整パケットを集める

references/intake-packets-and-route-outs.md を使用してください。

最低限必要な証拠パケット：

• 現在のボード／課題トラッカー／ドキュメントの情報源
• 進行中の作業とブロックされている作業
• 判明している場合は、直近のデリバリー目標またはスプリント目標
• 明らかな引き継ぎや依存関係
• 関連する場合は、タイムゾーン／ハイブリッド勤務の制約
• ボードが信頼できるか、古くなっているか、重要な作業が抜けているか

証拠が不十分な場合は、確実性を作り出すのではなく、確信度を下げてください。

ステップ 3：毎日の実施が妥当かを判断し、リスクを捉えられる範囲で最も負担の少ない形式を選ぶ

デフォルトの頻度ルール：

• ブロッカーの発生頻度が高く、依存関係が密で、ローンチ／マイルストーン／インシデントへの対応が急務 → live-daily
• 毎日の可視性は重要だが、リアルタイムで重なる時間を確保するのが難しい → async-daily
• 書面での更新に加え、例外がある場合のみ短時間のハドルを行うのが最適 → hybrid-daily
• 作業の大半が独立している、複数日にわたる、または信頼性の高い成果物ですでに可視化されている → less-frequent-sync
• ボードやドキュメントの整備が行き届いており、ブロッカーを定例の場まで保留せず、すぐにエスカレーションすべき → no-recurring-standup

頻度がスタンドアップ形式に値する場合の形式ルール：

• 信頼できるボードがあり、複数の作業項目が進行中 → board-walk
• ブロックされている作業や依存関係による圧力が支配的 → blocker-first
• タイムゾーンの分散や、集中作業時間の確保が主な課題 → async-check-in
• 書面での可視性に加え、例外がある場合のみ短時間の同期をチームが望んでいる → hybrid-async-plus-live
• 小規模で同じ場所に集まるチームで、シグナルの質が高く、形式化による形骸化がほとんどない → classic-three-questions

ボードが古くなっている場合は、診断の一部としてその点を明示してください。スタンドアップで、信頼できる唯一の情報源の不備をいつまでも補うことはできません。 チームが一時的に頻度を上げるだけでよい場合は、その点を明確にしてください。リスクの高い期間は毎日の形式を使い、その後、頻度を元に戻すかどうかを見直します。

ステップ 4：同期を含む場合は、中心となる同期の時間を限定する

頻度が live-daily、async-daily、hybrid-daily、または less-frequent-sync の場合：

• 実施する場合、リアルタイムの中心的な同期は最大 10～15 分にします
• 作業の進捗、ブロッカー、引き継ぎ、直近のデリバリーリスクに集中します
• 深い問題解決は、関係者だけを集めたフォローアップのハドルに移します
• 経営陣向けではなく、チームと作業に向けて話します
• ボード、チケットの整備、更新ルールそのものがブロッカーになっている場合は、明確に伝えます

頻度が no-recurring-standup の場合：

• 定例の代わりとなる成果物またはチャネルを示します
• ブロッカーにすぐ対応するためのエスカレーション条件を明示します
• リスクが再び高まった場合に、頻度をいつ見直すかを伝えます

ステップ 5：調整頻度の概要を 1 つ作成する

一般的なアジャイルの解説ではなく、コンパクトなパケットを 1 つ返してください。

# Coordination Cadence Brief

## Recommended cadence
- Cadence:
- Why this cadence fits:
- Review trigger:

## Recommended mode
- Mode:
- Why this mode fits:

## Goal for this coordination loop
- ...

## Evidence used
- Work source:
- Strongest signals:
- Missing but important:

## Core facilitation flow or replacement path
1. ...
2. ...
3. ...

## What each person should report or update
- ...

## Blocker / handoff routing
- Keep in core sync:
- Escalate immediately when:
- Move to follow-up huddle:
- Who should stay after:

## Template
```text
...

避けるべきアンチパターン

• ...
• ...

関連する引き継ぎ

• ... の場合は task-planning を使用します
• ... の場合は task-estimation を使用します
• ... の場合は sprint-retrospective を使用します

### Step 6: Tailor the packet to the chosen mode or no-meeting outcome
Use [references/intake-packets-and-route-outs.md](references/intake-packets-and-route-outs.md) for stable packet shapes.

Mode reminders:
- **board-walk** — review blocked, aging, in-progress, and ready-for-review work before asking for personal diaries
- **blocker-first** — name owner, missing input, and next action quickly; do not solve the blocker in the room
- **async-check-in** — prefer prompts like “What moved?”, “What is stuck?”, and “What needs help today?” over ritualized filler
- **hybrid-async-plus-live** — treat written updates as the base layer and the live sync as escalation only
- **classic-three-questions** — keep only if it still stays short, lateral, and work-focused
- **none** — say which board/doc/channel replaces the ritual and exactly when the team should pull an ad hoc huddle

### Step 7: Route adjacent PM work explicitly
Before finalizing, say when the next job changed:
- use `task-planning` for backlog cleanup, sprint prep, or scope slicing
- use `task-estimation` for effort, confidence, or capacity disputes
- use `sprint-retrospective` when repeated daily-sync pain should become a process change
- do **not** turn this skill into roadmap planning, status theater, or incident command

## Output format
Always return a **Coordination Cadence Brief** with these qualities:
- exactly one cadence decision
- exactly one primary mode or `none`
- one small evidence packet
- explicit separation between core sync and follow-up huddle when a sync exists
- explicit replacement path when the answer is `no-recurring-standup`
- visible blocker / handoff routing
- short reusable template
- clear route-outs to the rest of the PM cluster when the job changes

## Examples

### Example 1: Overlong sprint standup
**Input**
> Tomorrow’s standup keeps running 25 minutes because everyone gives long updates. We have two blockers and one item waiting for review.

**Good output direction**
- cadence: `live-daily`
- mode: `board-walk` or `blocker-first`
- blocked and in-progress work comes first
- follow-up huddle only for the blocked items
- anti-pattern callout: no round-robin biographies

### Example 2: Distributed team
**Input**
> We have engineers in California, Europe, and Korea. Should our daily standup be async?

**Good output direction**
- cadence: `async-daily` or `hybrid-daily`
- mode: `async-check-in` or `hybrid-async-plus-live`
- written template centered on movement, blockers, and help needed
- explicit escalation path for urgent coordination

### Example 3: Manager-facing status theater
**Input**
> Our daily scrum feels like reporting to the manager. Fix it without changing our whole process.

**Good output direction**
- cadence may stay `live-daily`, but the answer must justify it rather than assume it
- mode: `board-walk` or `blocker-first`
- names status theater directly
- keeps the sync lateral and work-focused
- routes recurring ceremony pain to `sprint-retrospective`

### Example 4: Daily ritual no longer justified
**Input**
> Most of our work is independent and already tracked in Linear. The daily standup feels like obligation, not coordination. Should we keep it?

**Good output direction**
- cadence: `less-frequent-sync` or `no-recurring-standup`
- mode: `none` if the ritual should disappear
- replacement path uses board hygiene plus explicit blocker escalation
- review trigger says when the team should re-introduce temporary daily cadence

## Best practices
1. **Optimize for work movement, not recital** — the ritual should clarify today’s coordination job.
2. **Justify cadence before format** — first decide whether daily is warranted at all.
3. **Choose the lightest mode that still catches risk** — not every team needs the same ceremony weight.
4. **Triage blockers in the sync, solve them elsewhere** — follow-up huddles are a feature, not a failure.
5. **Protect maker time** — async or hybrid modes often beat default live meetings for distributed teams.
6. **Treat source-of-truth hygiene as a first-class issue** — stale boards and missing updates are real blockers.
7. **Route repeated pain outward** — planning, estimation, retrospectives, and incident work are different jobs.

## References
- Scrum Guide — https://scrumguides.org/scrum-guide.html
- Scrum.org, *What is a Daily Scrum?* — https://www.scrum.org/resources/what-is-a-daily-scrum
- Atlassian, *Standups for agile teams* — https://www.atlassian.com/agile/scrum/standups
- GitLab Handbook, *Asynchronous communication* — https://handbook.gitlab.com/handbook/company/culture/all-remote/asynchronous/
- Martin Fowler / Jason Yip, *It’s Not Just Standing Up* — https://martinfowler.com/articles/itsNotJustStandingUp.html