stakeholder-communication

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

適切な情報を、適切な人に、適切なタイミングで、行動に移せる形で届けます。技術スタックを問いません。部門横断のステークホルダーと連携するあらゆるチームに適用できます。

---

使用する場面

• 週次または月次の状況報告を書くとき
• 経営陣によるレビューや取締役会への報告に備えるとき
• 技術的な意思決定を技術に詳しくない人に共有するとき
• 遅延、未達、品質問題について伝えるとき
• 支援、リソース、意思決定を求めるとき
• マネージャーやスポンサーへの報告を管理するとき
• プロジェクトのコミュニケーション頻度を設計するとき
• 社内告知の草案を作成するとき

使用しない場面

• 顧客向けのコミュニケーション（マーケティング／サポートのスキルを使用）
• 公開コミュニケーションや報道対応（異なるフレームワークとリスクが伴います）
• インシデント発生中のコミュニケーション（incident-responseを使用）
• 時間的制約のない社内文書（documentation-strategyを使用）
• 特定の配信形式（スライド資料のデザイン、メールの文調など）— このスキルの対象は内容と構成です

---

必須の入力情報

• 対象者（具体的に誰か、その人の状況、関心事）
• 目的（情報共有、意思決定、エスカレーション、依頼、祝賀）
• 内容（実際に何が起きているか）
• 媒体（メール、文書、会議、スライド、チャット）
• 時間的制約（いつまでに必要か）

---

フレームワーク：5つの質問

ステークホルダーとのコミュニケーションの前に、次の質問に答えます。

質問 1：対象者は誰ですか？

具体的に考えます。「経営陣」では曖昧すぎます。CFOとエンジニアリング担当VPでは、関心事が異なります。

対象者を一人ずつ挙げ、次の点を確認します。

• 何に関心がありますか？（収益、リスク、品質、スピード、コスト、顧客）
• すでに何を知っていますか？（省略できる背景情報）
• どの程度の詳細さを許容しますか？（経営幹部は要点を、ICは詳細を求めます）
• どのような行動を期待しますか？（確認、意思決定、支援、行動不要）

質問 2：要点は何ですか？

一文しか読まれないとしたら、何を持ち帰ってもらうべきですか？

要点を最初に置きます。必ずです。説明は要点を補足し、データは要点を裏付けます。

これが、多くのステークホルダーとのコミュニケーションにおける最大の問題です。背景から始めて結論にたどり着こうとします。ステークホルダーが求めるのは、まず結論です。

質問 3：それが意味することは何ですか？

ステークホルダーは、暗に「それで？」と問いかけます。明確に答えましょう。

• 「マイルストーンの80％を達成しました。」→ それで？
• 「マイルストーンの80％を達成しましたが、その結果、ローンチは計画より1週間遅れます。」→ これが「それで？」への答えです。

それが意味することを示すと、情報を行動につなげられます。

質問 4：何を求めていますか？

コミュニケーションで求めることは、通常、次のいずれかです。

• 情報共有： 対応は不要です。状況を共有するだけです。
• 意思決定： 決定が必要です。選択肢と推奨案を示します。
• エスカレーション： 問題が停滞しています。支援が必要です。
• 依頼： 具体的な依頼です（リソース、紹介、レビュー）。
• 祝賀： 成果を共有します。対応は不要ですが、士気の向上が大切です。

どれに当たるかを明示します。依頼を埋もれさせないでください。

質問 5：どの形式ですか？

• 非同期の文章（文書、メール）：情報量が多く、意思決定の経緯を残せて、後から参照しやすい
• 同期の文章（チャット、チケットのコメント）：素早いやり取りに適し、会話的
• 同期の口頭コミュニケーション（会議、通話）：細かなニュアンス、議論、認識合わせに適する
• 混合（文書＋会議）：文書は事前に読み、会議では意思決定する

多くの状況報告では、非同期の文章が適しています。同期の時間は、実際の議論のために確保しましょう。

---

構成：逆ピラミッド

ステークホルダー向けのコミュニケーションは、エッセイではなくニュース記事のように構成します。

Headline (one sentence)

The "so what" and the request (one paragraph)

Status / progress (the body)

Risks and asks (what we need)

Detail / appendix (what curious readers want)

下から削ります。報告が短縮されても、最初の部分は残ります。

---

更新テンプレート

週次プロジェクト報告

**Project:** [Name]
**Status:** [On track / At risk / Off track]
**Headline:** [One-sentence summary]

**This week:**
- [Specific accomplishment]
- [Specific accomplishment]
- [Specific accomplishment]

**Next week:**
- [Specific plan]
- [Specific plan]

**Risks / blockers:**
- [Risk + what we're doing about it / what we need]

**Metrics:**
- [Metric: value vs target]
- [Metric: value vs target]

ステータス表示（順調／要注意／遅延）は不可欠です。ステークホルダーはそこを見ます。

経営陣レビュー

**Headline:** [The summary, one sentence]

**Key points:**
1. [Point with one supporting sentence]
2. [Point with one supporting sentence]
3. [Point with one supporting sentence]

**Decisions needed:**
- [Decision A: options and recommendation]
- [Decision B: options and recommendation]

**Asks:**
- [Specific request]

**Detail:** [Linked doc or appendix]

経営幹部はざっと目を通し、関心があれば詳細を確認します。

悪い知らせ

適切に書くのが最も難しい報告です。

**Headline:** [The bad news, plainly stated]

**What happened:**
[Specific facts, no euphemisms]

**Impact:**
[Who's affected, how much, by when]

**What we're doing:**
[Specific actions and owners]

**What we need:**
[Specific asks, if any]

**Timeline:**
[When the next update will land]

要点をぼかさないでください。悪い知らせを曖昧な言葉で伝えると、知らせそのものより早く信頼を損ないます。

意思決定の依頼

**Decision:** [What needs to be decided]

**Context:** [The minimum needed to understand]

**Options:**
1. [Option A: description, pros, cons]
2. [Option B: description, pros, cons]
3. [Option C: description, pros, cons]

**Recommendation:** [Option X, because...]

**Need by:** [Date]
**Decision rights:** [Who decides]

推奨案を示すことが重要です。推奨案を示さないと、判断を下す人に作業を押し戻すことになります。

---

トーンと文体

相手に応じた調整

相手	トーン	詳細度	長さ
直属のマネージャー	率直、簡潔	中程度	中程度
上位のマネージャー／VP	洗練され、明快	低め	短め
部門横断の同僚	協調的、具体的	中〜高	中程度
経営幹部／取締役会	要点を端的に、確信を持って	低め（必要に応じて詳細を提示）	短め
チーム／個別貢献者の関係者	詳細かつ率直	高め	長め

避けること

• 確信があるのに曖昧にすること。「たぶん、もしかするとできるかもしれません」ではなく、言いたいことをそのまま伝えます。
• 不確実なのに確信を装うこと。 リスクがあるのに「金曜日に必ずローンチします」とは言いません。確度に応じて表現します。
• 技術に詳しくない相手への専門用語。 平易な言葉に置き換えます。
• 要点を後回しにすること。 まず結論を伝えます。
• 依頼を暗示すること。 相手に何をしてほしいのか明示します。
• 活動が90％、成果が10％の進捗報告。 成果を中心にし、活動は裏付けとして示します。

---

ワークフロー

ステップ1：相手と目的を定める

書き始める前に、上記のQ1〜Q5に答えます。多くの場合、下書きを始める前にメッセージが明確になります。

ステップ2：見出しを書く

一文で要点を示します。見出しを書けないなら、何を伝えるのかがまだ定まっていません。

ステップ3：逆ピラミッド型で書く

見出し、重要性、本文、依頼、詳細の順にします。

ステップ4：削る

最初の下書きは、通常30〜50％長すぎます。

• 成果につながっていない活動を削ります
• 形容詞（すばらしい、最高の、優れた、わくわくする）を削ります
• 埋め草（単に、本当に、とても、実際には）を削ります
• 確信がある場合は、曖昧にする表現（ある意味、なんとなく、多少）を削ります
• 情報を加えない文を削ります

ステップ5：依頼内容を確認する

読み直します。依頼は明確ですか？ 具体的ですか？ 期限を明示していますか？

ステップ6：相手の立場で確認する

受け取る人が読むところを想像します。見出しの意味は伝わりますか？ 相手に必要な背景を省いていませんか？ 不要な背景を加えていませんか？

ステップ7：送信してフォローアップする

送信後：

• 適切な人に届きましたか？ 適切なチャネルで確認します。
• 内容は理解されましたか？ 混乱した返信がないか確認し、あれば対応します。
• 相手は行動しましたか？ 対応されていない依頼をフォローアップします。

---

報告頻度の設計

相手によって適切な報告頻度は異なります。

高頻度（週1回以上）

• 直属のチーム、マネージャー、スポンサー
• 進行中のプロジェクトの関係者
• 日々の意思決定を行う人

中頻度（隔週〜月1回）

• 上位のマネージャー
• 部門横断のパートナー
• 隣接チーム
• 戦略上の関係者

低頻度（四半期ごと）

• 経営幹部向けレビュー
• 取締役会向けの報告
• 組織全体
• 外部の関係者（該当する場合）

適切な頻度とは、カレンダーを埋めるための頻度ではなく、必要な頻度です。新しい情報があるときに共有し、無理に報告を作り出さないでください。

---

失敗パターン

要点の前に長い前置きがある。 背景を3段落説明してから、重要な一文が出てきます。要点から始めましょう。

ステータス：黄色。 3週間連続で同じステータスです。変化のない黄色は赤です。進捗を正直に伝えましょう。

明確な依頼のない更新。 「取り組んでいます」。それで、何をしてほしいのでしょうか？何もなければ、「対応は不要です」と伝えましょう。

悪い知らせを良い知らせで挟む。 「XとYを完了しました。残念ながらZは遅れていますが、Wも完了しました」。悪い知らせが埋もれてしまいます。見出しにする内容なら、最初に伝えましょう。

長文の壁。 長すぎて読まれません。構成を整理して簡潔にしましょう。

活動と成果を混同する。 「チームと会議。計画を確認。チケットを更新」。それで何が変わったのでしょうか？「リリース日に間に合わせるためにスコープを縮小」は成果です。

相手ごとに異なる更新内容。 5種類のバージョンを維持すると、作業量が倍になります。共通の更新内容を1つ作り、伝え方を調整しましょう。

実際には依頼なのに、ステータス更新として伝える。 長いステータス報告の中に依頼を埋め込んでいます。依頼を切り出し、目立たせましょう。

楽観的な予測。 「来週には予定どおりに戻ります」。でも、戻りません。また同じことを繰り返します。信頼が損なわれます。見通しを正直に伝えましょう。

依頼へのフォローアップがない。 判断を依頼したのに返答がなく、そのまま先に進みました。今やプロジェクトは行き詰まっています。フォローアップしましょう。

追い込まれてから初めて悪い知らせを伝える。 関係者は、別の人から、あるいは期限を逃してから知ることになります。信頼を失います。先回りして伝えましょう。

特定の1人に向けた見せかけのコミュニケーション。 更新内容がすべて、上司への売り込みのようになっています。関係者には見透かされます。率直に伝えましょう。

新しい情報がないときに連絡しない。 沈黙より「今週は変化なし」のほうがましです。連絡の頻度について期待値を設定し、それを守りましょう。

---

出力形式

プロジェクトのコミュニケーション計画には、次の内容を含めます。

• ステークホルダーマップ： 名前、関心事、意思決定権を持つ人
• 連絡頻度： 誰に、どのような更新を、どのくらいの頻度で送るか
• テンプレート： 繰り返し使う更新の標準形式
• エスカレーション経路： リスクが生じたときに誰を巻き込むか
• 意思決定ログ： 決定事項、決定者、理由を記録した継続的な記録

個々のコミュニケーションには、次の内容を含めます。

• 見出し： 要点
• 本文： 要点を裏付ける構成
• 依頼： 明確に示した要望
• 配信先： 誰に、どの形式で伝えるか

---

参考ファイル

• references/update-templates.md：注釈付きの例を含む、よくあるステークホルダーとのコミュニケーションにすぐ使えるテンプレート。