stakeholder-update

ステークホルダー向けアップデート

見慣れないプレースホルダーがある場合や、どのツールが接続されているか確認する必要がある場合は、CONNECTORS.md をご覧ください。

対象読者と配信頻度に合わせたステークホルダー向けアップデートを作成します。

使用方法

/stakeholder-update $ARGUMENTS

ワークフロー

1. アップデートの種類を決める

どの種類のアップデートか、ユーザーに確認します。

• 週次：進捗、障害、次のステップを伝える定期的なアップデート
• 月次：傾向、マイルストーン、戦略との整合性を含む、より全体的な要約
• ローンチ：機能や製品のローンチに関する、詳細と影響を含む発表
• 随時：特定の状況（エスカレーション、方針転換、重大な決定）に関する単発のアップデート

2. 対象読者を決める

アップデートの対象者を確認します。

• 経営幹部／リーダーシップ：全体像、成果重視、戦略的な枠組み、簡潔さを重視
• エンジニアリングチーム：技術的な詳細、実装の背景、障害、必要な決定事項を重視
• 部門横断のパートナー：状況に応じた詳細、共通の目標と依存関係を重視
• 顧客／社外向け：メリット重視、明確なスケジュール、社内用語を使わない
• 取締役会：指標重視、戦略的、リスク重視、非常に簡潔

3. 接続されたツールからコンテキストを取得する

~~project tracker が接続されている場合：

• ロードマップ項目とマイルストーンの状況を取得する
• 前回のアップデート以降に完了した項目を特定する
• リスクがある項目やブロックされている項目を明らかにする
• スプリントまたはイテレーションの進捗を取得する

~~chat が接続されている場合：

• 関連するチーム内の議論や決定事項を検索する
• チャンネルで提起された障害や問題を見つける
• 非同期で行われた重要な決定事項を特定する

~~meeting transcription が接続されている場合：

• 最近の会議メモや議論の要約を取得する
• 関連する会議での決定事項やアクション項目を見つける

~~knowledge base が接続されている場合：

• 最近の会議メモを検索する
• 決定事項の文書や設計レビューを見つける

ツールが接続されていない場合は、次の情報をユーザーに提供してもらいます。

• 前回のアップデート以降に達成したこと
• 現在の障害やリスク
• 下された決定事項、または必要な決定事項
• 今後の予定

4. アップデートを作成する

以下のテンプレートとフレームワークを使って、対象読者に合わせたアップデートを構成します。

経営幹部向け：要約、ステータスカラー（G/Y/R）、目標に関連付けた主な進捗、決定事項、軽減策を含むリスク、具体的な依頼、次のマイルストーン。300語以内に収めます。

エンジニアリング向け：リリースしたもの（リンク付き）、進行中のもの（担当者付き）、障害、必要な決定事項（選択肢と推奨案付き）、今後の予定。

部門横断のパートナー向け：相手に影響する今後の予定、相手に必要なこと（期限付き）、相手のチームに影響する決定事項、意見を募集している領域。

顧客向け：新しく提供された内容（メリットとして説明）、近日中の予定、回避策を含む既知の問題、フィードバックの提供方法。社内用語は使いません。

ローンチ発表向け：ローンチした内容、その重要性、主な詳細（範囲、提供状況、制限事項）、成功指標、段階的な展開計画、フィードバック窓口。

5. 確認して共有する

アップデートを作成した後：

• トーン、詳細さ、重点の調整を希望するかユーザーに確認する
• 配信チャネル（メール、チャット投稿、ドキュメント、スライド）に合わせた形式を提案する
• ~~chat が接続されている場合、送信用のメッセージ案の作成を提案する

対象読者別のアップデートテンプレート

経営陣／リーダーシップ向けの進捗報告

経営陣が知りたいこと：戦略的な背景、目標に対する進捗、支援が必要なリスク、意見を求める決定事項。

形式：

Status: [Green / Yellow / Red]

TL;DR: [One sentence — the most important thing to know]

Progress:
- [Outcome achieved, tied to goal/OKR]
- [Milestone reached, with impact]
- [Key metric movement]

Risks:
- [Risk]: [Mitigation plan]. [Ask if needed].

Decisions needed:
- [Decision]: [Options with recommendation]. Need by [date].

Next milestones:
- [Milestone] — [Date]

経営陣向けの進捗報告のヒント：

• 道のりではなく、結論から伝えます。経営陣が知りたいのは「X をリリースし、Y の指標が改善した」であって、「14 回の朝会を行い、23 件のチケットを解決した」ではありません。
• 200 語以内に収めます。詳細が必要であれば、尋ねられます。
• ステータスの色には、相手が聞きたいと思うことではなく、あなた自身の率直な評価を反映します。黄色は失敗ではなく、適切なリスク管理です。
• 支援を求めたいリスクだけを含めます。すでに対処中のリスクは、知らせる必要がない限り記載しません。
• 依頼は具体的にします。「支援が必要です」ではなく、「金曜日までに X について決定してください」とします。

エンジニアリングチーム向けの進捗報告

エンジニアが知りたいこと：明確な優先事項、技術的な背景、解決済みの阻害要因、自分たちの作業に影響する決定事項。

形式：

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

In progress:
- [Item] — [Owner]. [Expected completion]. [Blockers if any].

Decisions:
- [Decision made]: [Rationale]. [Link to ADR if exists].
- [Decision needed]: [Context]. [Options]. [Recommendation].

Priority changes:
- [What changed and why]

Coming up:
- [Next items] — [Context on why these are next]

エンジニアリングチーム向けの進捗報告のヒント：

• 具体的なチケット、PR、ドキュメントへのリンクを記載します。エンジニアは詳細を確認するためにリンクを開きたいと考えています。
• 優先事項が変わったときは、その理由を説明します。理由がわかれば、エンジニアはより納得して取り組めます。
• 何が作業を妨げているのか、また、それを解消するために何をしているのかを明確にします。
• 自分たちの作業に影響しない情報で時間を無駄にさせないようにします。

部門横断パートナー向けの進捗報告

パートナー（デザイン、マーケティング、営業、サポート）が知りたいこと：自分たちに影響する今後の予定、準備が必要なこと、意見を伝える方法。

形式：

What's coming:
- [Feature/launch] — [Date]. [What this means for your team].

What we need from you:
- [Specific ask] — [Context]. By [date].

Decisions made:
- [Decision] — [How it affects your team].

Open for input:
- [Topic we'd love feedback on] — [How to provide it].

顧客／社外向けの進捗報告

顧客が知りたいこと：新しい内容、今後の予定、自分たちにとってのメリット、利用を開始する方法。

形式：

What's new:
- [Feature] — [Benefit in customer terms]. [How to use it / link].

Coming soon:
- [Feature] — [Expected timing]. [Why it matters to you].

Known issues:
- [Issue] — [Status]. [Workaround if available].

Feedback:
- [How to share feedback or request features]

顧客向けの進捗報告のヒント：

• 社内用語やチケット番号、技術的な実装の詳細は使いません。
• 開発した内容ではなく、顧客が新たにできるようになったことを中心に説明します。
• スケジュールについては正直に伝えますが、過度な約束はしません。守れない可能性のある日付より、「今四半期中の後半」のほうが適切です。
• 既知の問題に触れるのは、顧客に影響があり、解決計画がある場合だけにします。

ステータス報告のフレームワーク

緑／黄／赤のステータス

緑（予定どおり）：

• 計画どおりに進行している
• 重大なリスクや阻害要因がない
• 取り決めた内容や期限を守れる見込みである
• デフォルトではなく、実際に順調なときに緑を使います

黄（リスクあり）：

• 進捗が計画より遅い、またはリスクが顕在化した
• 対策を進めているが、結果は不確実である
• 介入やスコープの調整がなければ、取り決めた内容を実現できない可能性がある
• 黄色は早めに使います。リスクを早く伝えるほど、対応の選択肢が増えます

赤（予定から遅れている）：

• 計画から大幅に遅れている
• 明確な対策がない重大な阻害要因またはリスクがある
• 大幅な介入（スコープの縮小、リソースの追加、スケジュールの延長）がなければ、取り決めた内容を実現できない
• 本当に支援が必要なときは赤を使います。手遅れになるまで待たないでください。

ステータスを変更するタイミング

• 状況が悪いと確信してからではなく、リスクの兆候が現れた最初の時点で黄色にします
• 自分でできる対応を尽くし、エスカレーションが必要になったら赤にします
• リスクが一時停止しただけでなく、本当に解決したときだけ緑に戻します
• ステータスを変更したときは、変更理由を記録します。「[理由] のため、黄色に変更」

リスクの伝達

リスク管理の ROAM フレームワーク

• Resolved（解決済み）：リスクはもはや懸念事項ではありません。解決方法を記録します。
• Owned（担当者あり）：リスクが認識され、誰かが積極的に管理しています。担当者と軽減計画を明記します。
• Accepted（受容済み）：リスクを認識したうえで、対策を講じずに進めることを選択しています。その判断理由を記録します。
• Mitigated（軽減済み）：対応によって、リスクが許容できるレベルまで低減されています。実施した内容を記録します。

リスクを効果的に伝える

1. リスクを明確に述べる：「[thing]が[reason]のために発生するリスクがあります」
2. 影響を定量化する：「これが発生した場合、[impact]という結果になります」
3. 発生可能性を述べる：「[evidence]のため、発生する可能性は[高い／ある／低い]です」
4. 軽減策を示す：「[actions]によって、このリスクに対処しています」
5. 必要な支援を求める：「このリスクをさらに軽減するために、[specific help]が必要です」

リスクコミュニケーションでよくある間違い

• 良い知らせの中にリスクを埋もれさせる。重要なリスクは最初に伝えます。
• 曖昧な表現：「多少遅れるかもしれません」ではなく、何が、どのくらい、なぜ遅れるのかを具体的にします。
• 軽減策なしでリスクを提示する。すべてのリスクには計画を添えます。
• 伝えるのが遅すぎる。早期に伝えられたリスクは計画に役立ちます。遅れて伝えられたリスクは火消し作業につながります。

意思決定の記録（ADR）

アーキテクチャ決定記録のフォーマット

重要な決定を、後で参照できるように記録します。

# [Decision Title]

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

## Context
What is the situation that requires a decision? What forces are at play?

## Decision
What did we decide? State the decision clearly and directly.

## Consequences
What are the implications of this decision?
- Positive consequences
- Negative consequences or tradeoffs accepted
- What this enables or prevents in the future

## Alternatives Considered
What other options were evaluated?
For each: what was it, why was it rejected?

ADRを作成するタイミング

• 戦略的な製品決定（どの市場セグメントを対象とするか、どのプラットフォームをサポートするか）
• 重要な技術的決定（アーキテクチャの選択、ベンダーの選定、内製か購入か）
• 意見が分かれた議論の多い決定（後で参照できるように、決定の根拠を記録します）
• 将来の選択肢を制約する決定（技術の選択、パートナーシップの締結）
• 後で疑問を持たれると予想される決定（状況が新鮮なうちに背景を記録します）

意思決定を記録するためのヒント

• ADRは数週間後ではなく、決定した時点に近いタイミングで書きます
• 誰が決定に関わり、誰が最終決定を下したかを記載します
• 背景は十分に記録します。後から読む人は、今日の状況を知らないからです
• 後から振り返って誤りだった決定を記録しても問題ありません。「後継の決定」へのリンクを追加します
• 簡潔にまとめます。5ページより1ページのほうが適切です。

会議の進行

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

目的：障害を明らかにし、作業を調整し、勢いを維持します。
形式：各自が次の内容を共有します。

• 前回の同期以降に達成したこと
• 次に取り組むこと
• 作業の妨げになっていること

進行のヒント：

• 15分以内に収めます。議論が始まったら、別の場で行います。
• 障害に焦点を当てます。スタンドアップで最も価値のある部分です
• 障害を記録し、解決状況を確認します
• 同期することがなければ、スタンドアップを中止します。メンバーの時間を尊重しましょう。

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

目的：次のスプリントで取り組む作業を決めます。優先順位とスコープについて認識を合わせます。
形式：

1. 振り返り：前回のスプリントでリリースしたもの、持ち越したもの、取りやめたもの
2. 優先順位：今回のスプリントで達成すべき最も重要なこと
3. キャパシティ：チームがどれだけの作業を引き受けられるか（休暇、オンコール、会議を考慮します）
4. コミットメント：キャパシティと優先順位に合う項目をバックログから選びます
5. 依存関係：チーム間または外部の依存関係を明らかにします

進行のヒント：

• 優先順位の案を用意します。チームにゼロから優先順位を決めさせないようにします。
• 過剰なコミットメントを避けます。少なめにコミットして確実に成果を出すほうが適切です。
• すべての項目に明確な担当者と受け入れ基準があることを確認します。
• スコープが不十分な項目や、隠れた複雑さがある項目を明らかにします。

レトロスペクティブ

目的：うまくいったこと、うまくいかなかったこと、変更すべきことを振り返ります。
形式：

1. 場を整える：チームに目標を再確認し、心理的安全性を確保します
2. データを集める：うまくいったこと、うまくいかなかったこと、わかりにくかったこと
3. 洞察を導き出す：パターンと根本原因を特定します
4. アクションを決める：次のスプリントで試す具体的な改善策を1～3個選びます
5. 締めくくる：率直なフィードバックをくれたメンバーに感謝します

進行のヒント：

• 心理的安全性を確保します。メンバーが安心して率直に話せることが大切です。
• 個人ではなく、システムやプロセスに焦点を当てます。
• アクション項目は1～3個に絞ります。それ以上だと何も変わりません。
• 前回のレトロスペクティブのアクション項目を確認します。確認を怠ると、メンバーは参加しなくなります。
• 形式がマンネリ化しないよう、ときどき変えます。

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

目的：進捗を示し、フィードバックを集め、認識を合わせます。 形式：

1. 背景：目標と、前回見てもらった内容をステークホルダーに再確認します
2. デモ：構築したものを見せます。スライドではなく、実際のプロダクトを使います。
3. 指標：初期データやフィードバックがあれば共有します
4. フィードバック：質問や意見を出すための時間を設けます
5. 次のステップ：今後の予定と、次回レビューの時期を伝えます

進行のヒント：

• 可能な限り、実際のプロダクトをデモします。スライドはデモではありません。
• フィードバックの収集方法を明確にします。「Xについてどのようなフィードバックがありますか？」は、「何か意見はありますか？」よりも効果的です。
• フィードバックを見える形で記録し、対応する（または対応しない理由を説明する）ことを約束します
• この段階で対応可能なフィードバックの種類について、期待値を設定します

出力形式

更新内容はざっと確認できるようにします。重要なポイントには太字を使い、リストには箇条書きを使います。経営層向けの更新は300語未満にします。エンジニアリング向けの更新は長くてもかまいませんが、流し読みできるよう構成します。

ヒント

• ステークホルダーへの進捗共有で最もよくある間違いは、重要な点を後回しにすることです。最も重要なことから始めます。
• ステータスの色（Green／Yellow／Red）は、楽観ではなく実態を反映させます。Yellowは失敗ではなく、リスクを適切に伝えていることを意味します。
• 依頼は具体的で、実行可能なものにします。「助けが必要です」では依頼になりません。「金曜日までにXについて決定する必要があります」と伝えます。
• 経営層には、活動やタスクではなく、成果や目標に結び付けて説明します。
• 悪い知らせがある場合は、最初に伝えます。良い知らせの後ろに隠しません。
• 相手の注意を引ける長さに調整します。経営層には数個の箇条書きで、エンジニアリングチームには必要な詳細を伝えます。