status-updates

対象者別の更新形式

リーダー／経営層向けの更新

リーダーが必要とする情報：戦略的な背景、目標に照らした進捗、自身の介入が必要なリスク、意見を求められている決定事項。

テンプレート：

Status: [Green / Yellow / Red]

Summary: [Single sentence — the one thing they must know]

Progress:
- [Outcome delivered, linked to OKR or strategic goal]
- [Milestone completed, with business impact noted]
- [Key metric shift]

Risks:
- [Risk statement]: [Mitigation underway]. [Specific ask if applicable].

Decisions required:
- [Decision topic]: [Options with a recommendation]. Needed by [date].

Upcoming milestones:
- [Milestone] — [Target date]

ガイドライン：

• プロセスではなく、結論から始めてください。リーダーが知りたいのは、会議やチケットの一覧ではなく、「X をリリースし、指標 Y が改善した」という情報です。
• 200 語以内に収めてください。詳しい情報が必要であれば、リーダーから求められます。
• ステータスの色は、率直な評価を反映させてください。黄色は、健全にリスクを認識していることを示すものであり、失敗を意味するものではありません。
• 支援が必要なリスクのみを取り上げてください。すでに対処中のリスクは、経営層が把握する必要がない限り省略してください。
• 依頼は明確にしてください。「合意が必要です」ではなく、「木曜日までにベンダーの選定を承認してください」と伝えます。

エンジニアリングチーム向けの更新

エンジニアが必要とする情報：優先順位の明確さ、技術的な背景、ブロッカーの解消、作業に影響する決定事項の把握。

テンプレート：

Shipped:
- [Feature or fix] — [Link to PR/ticket]. [Impact note if relevant].

In flight:
- [Work item] — [Owner]. [Expected delivery]. [Blockers if any].

Decisions:
- [Decided]: [Rationale]. [Link to ADR if available].
- [Pending]: [Background]. [Options]. [Recommended path].

Priority shifts:
- [What moved and the reason behind it]

On deck:
- [Upcoming items] — [Why these are sequenced next]

ガイドライン：

• チケット、プルリクエスト、ドキュメントへのリンクを記載してください。エンジニアは詳細を確認したいと考えています。
• 優先順位が変わる場合は、その理由を説明してください。理由がわかれば、エンジニアはより積極的に取り組めます。
• 何が作業の妨げになっているかを明示し、解消するための計画を説明してください。
• 作業に関係のない情報は省略してください。

部門横断パートナー向けの更新

デザイン、マーケティング、営業、サポートのパートナーが必要とする情報：各チームに影響する変更の事前通知、必要な準備、意見を伝えるための窓口。

テンプレート：

Upcoming:
- [Feature or launch] — [Date]. [Implications for your team].

Action items for your team:
- [Specific request] — [Context]. Needed by [date].

Decisions finalized:
- [Decision] — [How it impacts your workflow].

Open for feedback:
- [Topic where input is welcome] — [How to submit it].

外部向け／顧客向けの更新

顧客が知りたい情報：新しくなったこと、今後予定されていること、顧客にとってのメリット、その活用方法。

テンプレート：

What's new:
- [Capability] — [Benefit stated in customer language]. [Link or instructions].

On the roadmap:
- [Capability] — [Approximate timing]. [Why it matters to you].

Known issues:
- [Issue] — [Current status]. [Workaround if one exists].

Share your feedback:
- [Channel or method for submitting feature requests and feedback]

ガイドライン：

• 社内用語をなくしてください。チケット ID やアーキテクチャに関する説明は含めません。
• チームが何を開発したかではなく、顧客が何をできるようになったかを中心に説明してください。
• 過剰な約束をせず、スケジュールについて率直に伝えてください。実現できない可能性のある日付を示すより、「今四半期後半」のほうが適切です。
• 既知の問題を含めるのは、顧客に見える問題であり、かつ解決に向けた道筋を示せる場合に限ってください。

信号機式ステータスフレームワーク

定義

緑（順調）：

• 作業は計画どおりに進んでいます
• 重大なリスクや障害はありません
• コミットメントと期限を守れる見込みです
• 緑は、物事が本当に順調に進んでいる場合に限って使い、デフォルトにしないでください

黄（リスクあり）：

• 進捗が遅れている、またはリスクが顕在化しています
• 軽減策を進めていますが、結果はまだ不確実です
• 介入やスコープの調整がなければ、コミットメントを果たせない可能性があります
• リスクが見えれば見えるほど、選択肢が多く残ります。早い段階で黄色にしてください

赤（計画未達）：

• スケジュールから大幅に遅れています
• 明確な解決策のない重大な障害があります
• 大規模な介入（スコープの縮小、追加リソース、またはスケジュールの延長）がなければ、コミットメントを果たせません
• 自力で使える選択肢をすべて使い果たし、外部の支援が必要になったら赤に引き上げてください

移行ルール

• 問題が起きたと確信してからではなく、リスクの兆候が初めて現れた時点で黄色にしてください
• 利用可能な手段をすべて使い、エスカレーションが必要になったら赤にしてください
• 根本的なリスクが実際に解消された後にのみ緑に戻してください。一時的に停止しただけでは不十分です
• ステータスを変更する際は、必ず理由を記録してください：「[説明]のため、黄色に変更」

リスクを効果的に伝える

ROAM 分類

• 解決済み：リスクはもはや該当しません。解消方法を記録します。
• 担当あり：リスクが認識され、誰かが積極的に管理しています。担当者と軽減策を明記します。
• 受容済み：リスクを認識したうえで、チームは積極的な軽減策を講じずに進めます。その理由を記録します。
• 軽減済み：対策によってリスクが許容できる水準まで低下しています。実施した内容を記録します。

5 段階のリスクコミュニケーションパターン

1. 率直に伝える：「[原因] によって [事象] が発生するリスクがあります」
2. 影響の大きさを示す：「これが現実化した場合、[具体的な影響] が生じます」
3. 発生確率を見積もる：「[根拠] があるため、これは [高い確率で発生する／発生する可能性がある／発生する可能性は低い] と考えられます」
4. 対応策を説明する：「[実施済みまたは予定しているアクション] によって対応しています」
5. 必要な支援を明示する：「このリスクをさらに低減するには、[具体的な支援または判断] が必要です」

避けるべき落とし穴

• 好調な進捗報告の中にリスクを埋もれさせること。重大なリスクがある場合は、最初に伝えましょう。
• 曖昧な表現：「多少の遅れが生じるかもしれません」ではなく、何が、どれくらい、なぜ遅れる可能性があるのかを必ず明示しましょう。
• 対応計画を添えずにリスクを提示すること。すべてのリスクに、緩和策または依頼事項を含めましょう。
• 開示が遅れること。早期に明らかになったリスクは計画の判断材料になります。遅れて明らかになったリスクは危機につながります。

意思決定記録

簡潔な ADR の構成

組織の記憶として、重要な意思決定を記録します。

# [Decision Title]

## Status

[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]

## Situation

What circumstances necessitate this decision? What constraints and pressures exist?

## Resolution

What was decided? State the choice clearly and unambiguously.

## Tradeoffs

What follows from this decision?
- Benefits gained
- Downsides or compromises accepted
- Future possibilities opened or closed

## Options Evaluated

What alternatives were considered?
For each: a brief description and the reason it was not chosen.

意思決定記録を作成するタイミング

• 戦略的な製品選択（ターゲット市場、プラットフォームのサポート、価格モデル）
• 重要な技術的決定（アーキテクチャの方針、ベンダーの選定、自社開発か購入か）
• チーム内で意見が分かれた決定（後から参照できるよう、判断の根拠を残します）
• 将来の柔軟性を狭める決定（特定技術へのロックイン、パートナーシップの確約）
• 後から疑問が呈されると予想される決定（状況が新鮮なうちに背景を記録します）

実践的なヒント

• 数週間後ではなく、決定した時点に近いタイミングで記録を書きます
• 参加者と、最終的な決定権を持つ人を記録します
• 周辺の状況を十分に記録します。後から読む人には、今日の状況を把握する知識がありません
• 後から誤りだと判明した記録にも価値があります。「後継の決定」への参照を追加します
• 簡潔さは強みです。5 ページより 1 ページのほうが優れています。

会議進行のパターン

デイリー同期／スタンドアップ

目標：ブロッカーを明らかにし、作業を同期させ、勢いを維持します。

各参加者が共有する内容：

• 前回の同期以降に完了した作業
• 現在注力していること
• 進捗を妨げていること

効果的に進めるには：

• 15 分以内に収めます。長い議論は後で行うために保留します。
• ブロッカーを優先します。スタンドアップで最も効果の大きい議題です。
• ブロッカーを明確に記録し、解決するまでフォローアップします。
• 同期することがなければ、会議を省略します。メンバーの時間を大切にしましょう。

イテレーション／スプリント計画

目標：次のサイクルで行う作業について合意し、範囲と優先順位を調整します。

アジェンダ：

1. 振り返り：リリースしたもの、持ち越したもの、対象外にしたもの
2. 優先順位の提示：次のスプリントで達成する最も重要な成果
3. キャパシティの評価：休暇、オンコール業務、会議を考慮した現実的な稼働状況
4. コミットする項目の選定：キャパシティと優先順位に合う項目をバックログから選びます
5. 依存関係のマッピング：チーム間または外部との調整が必要な事項を明らかにします

効果的に進めるには：

• 優先順位の案を用意して臨みます。チームにゼロから整理させてはいけません。
• 過剰なコミットを避けます。目標を安定して達成できない状態が続くより、確実に少なめの成果を出すほうが信頼につながります。
• 選定した各項目に、明確な担当者と曖昧さのない受け入れ基準を設定します。
• 隠れた複雑さがある項目や、スコープが十分に定まっていない項目を明らかにします。

振り返り

目標：うまくいったこと、うまくいかなかったこと、チームが今後変えることを率直に振り返ります。

進め方：

1. 会話の枠組みを整える：スプリントの目標を振り返り、心理的安全性を確保します
2. 観察事項を集める：うまくいったこと、期待に届かなかったこと、混乱の原因を確認します
3. パターンを特定する：繰り返し現れるテーマと根本原因を見つけます
4. 改善策を選ぶ：次のサイクルに向けて、具体的な変更を1～3件決定します
5. 締めくくる：チームが率直に話してくれたことに感謝します

うまく進めるために：

• 心理的安全性は必須です。誰もが安心して率直に話せる必要があります。
• 個人ではなく、システムやプロセスに焦点を当てます。
• アクションアイテムは1～3件に絞ります。それを超えると、何も実行されなくなります。
• 前回の振り返りで決めたアクションを再確認します。実行が伴わない状態が続くと、参加意欲が損なわれます。
• 新鮮さを保つため、振り返りの形式を定期的に変えます。

ステークホルダーデモ／レビュー

目標：進捗を示し、フィードバックを求め、認識をすり合わせます。

進め方：

1. 背景を共有する：目的と、前回何を見たかをステークホルダーに思い出してもらいます
2. ライブデモ：スライドではなく、実際に動作するプロダクトを見せます
3. データを共有する：初期の指標やユーザーフィードバックがあれば提示します
4. 構造化されたフィードバック：質問を具体的なトピックに誘導します
5. 今後の予定を共有する：次に何をするか、次回のレビューをいつ行うかを予告します

うまく進めるために：

• 可能な限り、実際のプロダクトをデモします。スライドは代わりにはなりません。
• フィードバックの依頼は具体的にします。「Xについてどう思いますか？」は「何か意見はありますか？」より効果的です。
• フィードバックを見える形で記録し、各項目への対応、または対応しない理由の説明を約束します
• 現段階で対応可能なフィードバックの種類を明確にします