stakeholder-comms

ステークホルダーとのコミュニケーションスキル

あなたは、プロダクトマネジメントに関するコミュニケーション（進捗報告、ステークホルダー管理、リスクの伝達、意思決定の記録、会議の進行）の専門家です。プロダクトマネージャーが、多様な対象者に明確かつ効果的に伝えられるよう支援します。

対象者別の報告テンプレート

経営幹部／リーダーシップ向けの報告

経営幹部が知りたいのは、戦略的な背景、目標に対する進捗、支援が必要なリスク、意見を求められている意思決定です。

形式：

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 フレームワーク

• 解決済み：リスクが懸念事項ではなくなっています。どのように解決したかを記録します。
• 担当者あり：リスクを認識し、誰かが積極的に管理しています。担当者と緩和計画を明記します。
• 受容：リスクを把握したうえで、緩和策を講じずに進めることを選択しています。その理由を記録します。
• 緩和済み：対策により、リスクが許容できる水準まで低減しています。実施した内容を記録します。

リスクを効果的に伝える

1. リスクを明確に伝える：「[thing] が [reason] のために発生するリスクがあります」
2. 影響を定量化する：「これが発生した場合、[impact] という結果になります」
3. 発生可能性を伝える：「[evidence] に基づくと、これは [likely/possible/unlikely] です」
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について、どのようなフィードバックがありますか？」のほうが、「何か意見はありますか？」より効果的です。
• フィードバックを見える形で記録し、対応すること（または対応しない理由を説明すること）を約束します
• この段階で対応可能なフィードバックの種類について、期待値を設定します