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

未知のプレースホルダーが表示される場合、またはどのツールが接続されているかを確認する必要がある場合は、CONNECTORS.md を参照してください。

ステークホルダー向けのアップデートをオーディエンスとペースに合わせて生成します。

使用方法

/stakeholder-update $ARGUMENTS

ワークフロー

1. アップデート種別の決定

ユーザーにどのような種類のアップデートかを確認します:

• Weekly (週次): 進捗、障害、次のステップに関する定期的なアップデート
• Monthly (月次): トレンド、マイルストーン、戦略的整合性を含むより高いレベルの概要
• Launch (ローンチ): 機能またはプロダクトローンチの発表、詳細と影響
• Ad-hoc (臨時): 特定の状況 (エスカレーション、ピボット、重要な決定) のための一度限りのアップデート

2. オーディエンスの決定

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

• Executives / leadership (経営陣): 高いレベル、結果指向、戦略的フレーミング、簡潔
• Engineering team (エンジニアチーム): 技術的詳細、実装コンテキスト、障害、必要な判断
• Cross-functional partners (クロスファンクショナルパートナー): 文脈に適切な詳細、共有される目標と依存関係に焦点
• Customers / external (顧客/外部): メリット焦点、明確なタイムライン、内部用語なし
• Board (ボード): メトリクス駆動、戦略的、リスク焦点、非常に簡潔

3. 接続ツールからコンテキストを取得

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

• ロードマップ項目とマイルストーンの状態を取得
• 前回のアップデート以降に完了したアイテムを特定
• リスク状態またはブロック状態のアイテムを表示
• スプリントまたはイテレーション進捗を取得

chat が接続されている場合:

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

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

• 最近の会議ノートと議論の概要を取得
• 関連する会議からの決定とアクションアイテムを検索

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

• 最近の会議ノートを検索
• 決定書またはデザインレビューを検索

ツールが接続されていない場合は、ユーザーに以下を提供するよう依頼します:

• 最後のアップデート以降に達成されたこと
• 現在の障害またはリスク
• 行われたまたは必要な重要な決定
• 次に来ること

4. アップデートを生成

以下のテンプレートとフレームワークを使用して、ターゲットオーディエンス向けにアップデートを構成します。

経営陣向け: TL;DR、ステータスカラー (G/Y/R)、目標に紐付けられた重要な進捗、行われた決定、軽減策付きのリスク、具体的なリクエスト、次のマイルストーン。300語以下に保ってください。

エンジニアリング向け: 提供されたもの (リンク付き)、進行中のもの (オーナー付き)、障害、必要な決定 (オプションと推奨付き)、次に来ること。

クロスファンクショナルパートナー向け: 彼らに影響を与えるもの、彼らから必要なもの (期限付き)、彼らのチームに影響を与える決定、フィードバック用にオープンなエリア。

顧客向け: 新しいもの (メリットとしてフレーム)、近日公開予定、既知の問題と回避策、フィードバック提供方法。内部用語なし。

ローンチ発表向け: ローンチされたもの、その重要性、重要な詳細 (スコープ、可用性、制限)、成功メトリクス、ロールアウト計画、フィードバックチャネル。

5. レビューと配信

アップデートを生成した後:

• トーン、詳細レベル、または強調を調整したいかどうかをユーザーに確認
• 配信チャネル (メール、チャット投稿、ドキュメント、スライド) のフォーマット提供を申し出る
• chat が接続されている場合、送信用のメッセージドラフトを提供することを申し出る

オーディエンス別のアップデートテンプレート

経営陣/リーダーシップ向けアップデート

経営陣が欲しいもの: 戦略的コンテキスト、目標に対する進捗、彼らの助けが必要なリスク、彼らの入力が必要な決定。

フォーマット:

Status: [Green / Yellow / Red]

TL;DR: [1つの文 — 知っておく最も重要なこと]

Progress:
- [達成された結果、目標/OKRに紐付け]
- [達成されたマイルストーン、インパクト付き]
- [重要なメトリクスの動き]

Risks:
- [リスク]: [軽減計画]。[必要な場合はリクエスト]。

Decisions needed:
- [決定]: [推奨付きのオプション]。[日付]までに必要。

Next milestones:
- [マイルストーン] — [日付]

経営陣向けアップデートのコツ:

• 過程ではなく結論から始めてください。経営陣は「14回のスタンドアップを開催して23個のチケットを解決した」ではなく「Xを提供してYメトリクスを動かした」を望みます。
• 200語以下に保ってください。彼らがもっと欲しければ、彼らが聞くでしょう。
• ステータスカラーはあなたの真摯な評価を反映すべきで、彼らが聞きたいと思うことではありません。Yellowは失敗ではなく、良好なリスク管理です。
• すでに対応しているリスク、彼らが知る必要のないリスクは含めないでください。彼らが助けてほしいリスクのみを含めてください。
• リクエストは具体的である必要があります。「金曜日までのXの決定」であり「サポートが必要」ではありません。

エンジニアリングチーム向けアップデート

エンジニアが欲しいもの: 明確な優先事項、技術的コンテキスト、解決された障害、彼らの仕事に影響を与える決定。

フォーマット:

Shipped:
- [機能/修正] — [PRへのリンク/チケット]。[注目される場合はインパクト]。

In progress:
- [アイテム] — [オーナー]。[予想完了]。[ある場合は障害]。

Decisions:
- [行われた決定]: [根拠]。[ADRへのリンク (ある場合)]。
- [必要な決定]: [コンテキスト]。[オプション]。[推奨]。

Priority changes:
- [変更されたもの、理由]

Coming up:
- [次のアイテム] — [これらが次である理由についてのコンテキスト]

エンジニアリングアップデートのコツ:

• 特定のチケット、PR、ドキュメントにリンクしてください。エンジニアは詳細をクリックして確認したいものです。
• 優先事項が変更される場合は、理由を説明してください。エンジニアは理由を理解するとより承認します。
• 何が彼らをブロックしているのか、そしてあなたがそれをアンブロックするために何をしているのかについて明示的にしてください。
• 彼らの仕事に影響しない情報で時間を無駄にしないでください。

クロスファンクショナルパートナー向けアップデート

パートナー (デザイン、マーケティング、セールス、サポート) が欲しいもの: 彼らに影響を与えるものが来ていること、彼らが準備する必要があること、入力を与える方法。

フォーマット:

What's coming:
- [機能/ローンチ] — [日付]。[これがあなたのチームにとって何を意味するか]。

What we need from you:
- [具体的なリクエスト] — [コンテキスト]。[日付]までに。

Decisions made:
- [決定] — [これがあなたのチームに与える影響]。

Open for input:
- [フィードバックをしたいトピック] — [提供方法]。

顧客/外部向けアップデート

顧客が欲しいもの: 新しいもの、来ているもの、それがどのようにメリットか、始める方法。

フォーマット:

What's new:
- [機能] — [顧客用語でのメリット]。[使用方法 / リンク]。

Coming soon:
- [機能] — [予想タイミング]。[これがあなたに重要である理由]。

Known issues:
- [問題] — [ステータス]。[利用可能な場合は回避策]。

Feedback:
- [フィードバックを共有またはリクエスト機能を提出する方法]

顧客向けアップデートのコツ:

• 内部用語はありません。チケット番号はありません。技術的実装の詳細はありません。
• すべてを顧客が今できることの観点からフレーミングしてください、あなたが構築したもの以外。
• タイムラインについて正直ですが、過度にコミットしないでください。「このクォーターの後半」は逃すかもしれない日付より良いです。
• 既知の問題は顧客に影響を与える場合、そして解決計画があるときのみ言及してください。

ステータスレポート用フレームワーク

Green / Yellow / Red ステータス

Green (予定通り):

• 予定通りに進行中
• 重大なリスクまたは障害なし
• コミットメントとデッドラインを満たすための軌道上
• 事態が本当に良好なときにGreenを使用してください。デフォルトではありません

Yellow (リスク中):

• 進捗が予定より遅い、またはリスクが顕在化している
• 軽減が進行中だが、結果は不確かです
• 介入またはスコープ調整がないとコミットメントを逃すかもしれません
• 積極的にYellowを使用してください。リスクを早くフラグするほど、より多くのオプションがあります

Red (予定外):

• 計画から大幅に遅れている
• 明確な軽減のない大きな障害またはリスク
• 大幅な介入 (スコープカット、リソース追加、タイムライン延長) がないとコミットメントを逃します
• 本当に助けが必要なときにRedを使用してください。遅すぎるまで待たないでください。

ステータスいつ変更するか

• リスクの最初の兆候で、事態が悪いことが確かになるまでYellowに移動
• 自分のオプションを使い尽くしてエスカレーションが必要なときにRedに移動
• リスクが一時停止されただけでなく、本当に解決されたときのみGreenに戻す
• ステータスを変更するときに何が変わったかを文書化してください — 「[理由]のため、Yellowに移動」

リスク通信

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

• Resolved (解決): リスクはもはや懸念事項ではありません。それがどのように解決されたかを文書化してください。
• Owned (所有): リスクが認識されており、誰かがそれを積極的に管理しています。オーナーと軽減計画を述べてください。
• Accepted (承認): リスクは既知ですが、軽減なしで進めることを選択しています。根拠を文書化してください。
• Mitigated (軽減): アクションがリスクを許容可能なレベルに削減しました。何が行われたかを文書化してください。

リスク通信を効果的に行う

1. リスクを明確に述べる: 「[事柄]が起こるリスクがあります、なぜなら[理由]」
2. インパクトを定量化する: 「これが起こると、結果は[インパクト]です」
3. 可能性を述べる: 「これは[可能性が高い/可能/可能性が低い]です、なぜなら[証拠]」
4. 軽減を示す: 「私たちはこれを[アクション]によって管理しています」
5. リクエストを行う: 「このリスクをさらに削減するために[具体的なヘルプ]が必要です」

リスク通信での一般的な間違い

• 良いニュースの中にリスクを埋める。重要な場合はリスクで始めてください。
• 曖昧であること: 「遅延があるかもしれません」 — 何を、どのくらい、そしてなぜかを指定してください。
• 軽減なしでリスクを提示する。すべてのリスクは計画を伴うべきです。
• 待つのが遅すぎる。早期に通信されるリスクは計画入力です。遅く通信されるリスクは火事です。

決定文書化 (ADRs)

アーキテクチャ決定レコード形式

将来の参照のために重要な決定を文書化してください:

# [決定タイトル]

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

## Context
決定を必要とする状況は何ですか？どのような力が作用していますか？

## Decision
何を決定しましたか？決定を明確かつ直接的に述べてください。

## Consequences
この決定の意味は何ですか？
- 肯定的な結果
- 受け入れられた否定的な結果またはトレードオフ
- これが将来実現または防止すること

## Alternatives Considered
どの他のオプションが評価されましたか？
各について: それは何でしたか、なぜそれは拒否されましたか？

ADRを書くべきとき

• 戦略的製品決定 (どの市場セグメントをターゲットするか、どのプラットフォームをサポートするか)
• 重大な技術決定 (アーキテクチャの選択肢、ベンダー選択、構築対購入)
• 人々が不同意だった論争のある決定 (将来の参照のため根拠を文書化)
• 将来のオプションを制限する決定 (テクノロジーの選択、パートナーシップへの署名)
• 人々が後で質問することを期待する決定 (それが新しい間に文脈をキャプチャ)

決定文書化のコツ

• ADRを決定がなされた直後に書いてください、週後ではなく
• 決定に関わった人と最終的な判断をした人を含めてください
• コンテキストを寛容に文書化してください — 将来の読者は今日のコンテキストを持っていません
• 後から見て間違っていた決定を文書化することは問題ありません — 「superseded by」リンクを追加してください
• 短く保ってください。1ページは5ページより良いです。

会議の進行

スタンドアップ / 日次シンク

目的: 障害を表面化、作業を調整、モメンタムを維持。 フォーマット: 各人が以下を共有:

• 最後のシンク以降に達成したこと
• 次に取り組むこと
• 何が彼らをブロックしているか

進行のコツ:

• 15分以内に保ってください。議論が出現する場合は、オフラインで取り上げてください。
• 障害に焦点を当ててください — これはスタンドアップの最も高い価値の部分です
• 障害を追跡し、解決をフォローアップしてください
• 同期するものがない場合はスタンドアップをキャンセルしてください。人々の時間を尊重してください。

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

目的: 次のスプリントの作業にコミット。優先事項とスコープを整合させる。 フォーマット:

1. Review: 最後のスプリントで提供されたもの、引き継がれたもの、カットされたもの
2. Priorities: このスプリントで達成する最も重要なもの
3. Capacity: チームが引き受けられる量 (PTO、オンコール、会議を考慮)
4. Commitment: 容量と優先事項に合うバックログからアイテムを選択
5. Dependencies: すべてのクロスチーム外部依存関係にフラグ

進行のコツ:

• 提案された優先度順を持ってきてください。チームに最初からの優先順位を求めないでください。
• 過度なコミットメントに押し返してください。より少ないにコミットして確実に配信する方が良いです。
• すべてのアイテムに明確なオーナーと明確な受け入れ基準があることを確認してください。
• 過度にスコープされているか隠れた複雑性を持つアイテムにフラグを立ててください。

レトロスペクティブ

目的: 何が上手くいったか、何がそうでなかったか、何を変えるかについて反映。 フォーマット:

1. Set the stage: チームに目標を思い出させ、心理的安全性を作る
2. Gather data: 何が上手くいったか、何がそうでなかったか、何が混乱していたか
3. Generate insights: パターンと根本原因を特定
4. Decide actions: 次のスプリントで試す1-3の具体的な改善を選択
5. Close: 正直なフィードバックのため人々に感謝

進行のコツ:

• 心理的安全性を作ってください。人々は正直であることが安全に感じる必要があります。
• システムとプロセスに焦点を当ててください、個人には焦点を当てないでください。
• 1-3のアクションアイテムに制限してください。それ以上だと、何も変わりません。
• 前回のレトロアクションアイテムをフォローアップしてください。フォローアップしなければ、人々は関与を停止します。
• 時々レトロ形式を変えて陳腐化を防いでください。

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

目的: 進捗を示す、フィードバックを集める、整合性を構築する。 フォーマット:

1. Context: 目標とステークホルダーが最後に見たものを思い出させる
2. Demo: 構築されたものを示す。スライドではなく実際のプロダクトを使用。
3. Metrics: 初期データまたはフィードバックを共有
4. Feedback: 質問と入力のための構成された時間
5. Next steps: 次に来るものと次のレビューがいつであるか

進行のコツ:

• 可能な限り実際のプロダクトでデモしてください。スライドはデモではありません。
• フィードバック収集をフレーミングしてください: 「Xについてどのようなフィードバックがありますか?」は「何か思考ありますか?」より良いです。
• フィードバックを目に見える形で捕捉し、それに対応することをコミットしてください (または、なぜ対応しないかを説明)
• この段階でどのような種類のフィードバックが実行可能かについて期待を設定してください

出力形式

アップデートをスキャン可能に保ってください。重要なポイントは太字、リストは箇条書き。経営陣向けアップデートは300語以下である必要があります。エンジニアリングアップデートはより長くできますが、スキミング用に構成すべきです。

コツ

• ステークホルダー向けアップデートでの最も一般的な間違いはリードを埋めることです。最も重要なことから始めてください。
• ステータスカラー (Green/Yellow/Red) は楽観主義ではなく現実を反映すべきです。Yellowは失敗ではなく、それは良好なリスク通信です。
• リクエストは具体的で実行可能である必要があります。「ヘルプが必要」はリクエストではありません。「金曜日までのXでの決定が必要」です。
• 経営陣の場合、活動とタスク以外のすべてを結果と目標の観点からフレーミングしてください。
• 悪いニュースがある場合、それで始めてください。良いニュースの後それを隠さないでください。
• 長さをオーディエンスの注意に合わせてください。経営陣は数個の箇条書きを得ます。エンジニアリングは彼らが必要な詳細を得ます。