フレームワーク活用ガイドひとことで言うと#
プロジェクトの情報を**「誰に・何を・いつ・どの手段で・誰が」伝えるかを一覧表にまとめた計画書**。場当たり的な報告や「聞いてない」を防ぎ、全ステークホルダーが必要な情報を適切なタイミングで受け取れる状態を作る。
押さえておきたい用語#
- ステークホルダー
- プロジェクトの成果に影響を受ける、または影響を与えるすべての人・組織のこと。スポンサー、クライアント、チームメンバー、エンドユーザーなど。
- プッシュ型コミュニケーション
- 情報を発信側から受信側へ能動的に送る方法。メール、定例報告書、Slack通知など。
- プル型コミュニケーション
- 受信側が必要なときに自分で取りに行く方法を指す。ダッシュボード、Wiki、共有ドライブなど。
- RACI
- Responsible（実行者）・Accountable（責任者）・Consulted（相談先）・Informed（報告先）の4役割を定義する責任分担マトリクスである。
プロジェクト・コミュニケーション計画の全体像#
こんな悩みに効く#
- 経営層に報告する粒度とメンバーに共有する粒度が同じになっている
- 「その話、聞いてないんだけど」がプロジェクト内で頻発する
- 報告のたびに「何を書けばいいか」を考え直している
基本の使い方#
プロジェクトに関わる全ての人を洗い出し、それぞれが「何を知りたいか」を整理する。
| ステークホルダー | 知りたいこと | 関心レベル |
|---|---|---|
| 経営層 | 予算・ROI・主要リスク | 概要のみ |
| スポンサー | マイルストーン達成・課題 | 中程度 |
| チームメンバー | タスクの優先順位・技術判断 | 詳細 |
| クライアント | 納品物の進捗・品質 | 中程度 |
| エンドユーザー | リリース時期・使い方 | 概要のみ |
関心レベルに応じて情報の粒度を変える。経営層に技術詳細は不要だし、エンドユーザーにリスク管理状況は伝えなくてよい。
ステークホルダーごとに「何を・いつ・どの手段で・誰が」をマトリクスにまとめる。
| 対象 | 情報 | 頻度 | 手段 | 発信者 |
|---|---|---|---|---|
| 経営層 | サマリーレポート（1枚） | 月次 | メール | PM |
| スポンサー | 進捗・リスク・予算 | 週次 | 会議30分 | PM |
| メンバー | タスク状況・障害 | 日次 | スタンドアップ | 各担当 |
| クライアント | 成果物デモ | 隔週 | オンライン会議 | PM＋リード |
| 全体 | マイルストーン達成通知 | 都度 | Slack | PM |
このマトリクスがコミュニケーション計画書の本体になる。
報告ごとにフォーマットを標準化する。
- 週次レポート: 進捗サマリー（赤黄緑）＋主要課題3件＋次週の予定
- 月次サマリー: KPI実績＋予算消化率＋主要リスクTOP3＋経営判断事項
- 議事録: 決定事項＋アクション（Who/What/When）＋次回日程
テンプレートはNotionやConfluenceなどチームの標準ツールに配置し、毎回ゼロから作らなくてよい状態にする。
具体例#
状況: Web開発会社。クライアントとの週次ミーティングは実施しているが、「PMが口頭で説明した内容」と「クライアントの理解」がずれることが月 3件 発生。仕様の認識違いによる手戻りが年間 120時間。
コミュニケーション計画の導入
| 対象 | 情報 | 頻度 | 手段 |
|---|---|---|---|
| クライアント担当者 | 進捗・デモ | 週次 | Zoom＋議事録 |
| クライアント部長 | サマリー | 月次 | メール（1枚PDF） |
| 開発チーム | 仕様変更・優先度 | 日次 | Slack |
議事録を 24時間以内 に送付し、「認識相違があれば翌営業日までに指摘」のルールを合意。認識齟齬は 月3件 → 月0.5件 に減少し、手戻り工数は年間 120時間 → 20時間 に削減。
状況: 全社ERP導入PJ（18か月・予算4億円）。ステークホルダーが経営層・事業部長・現場キーユーザー・ベンダーなど 30名超。PMが全員に個別対応しており、1日の 40% がコミュニケーションに費やされている。
3層のコミュニケーション設計
- 経営層（5名）：月次サマリーメール＋四半期ステアリング
- 部長・キーユーザー（15名）：隔週の全体進捗会議＋Confluenceのダッシュボード（プル型）
- ベンダー・開発チーム（10名）：週次レビュー＋日次Slack
PMのコミュニケーション工数は 1日の40% → 20% に半減。「ダッシュボードを見れば状況がわかるので、わざわざPMに聞かなくてよくなった」と部長陣が評価。情報の鮮度（更新から共有までの遅延）は 平均3日 → 当日 に改善。
状況: 4か国（日本・ベトナム・インド・米国）にまたがる開発チーム15名。タイムゾーンが最大 14時間 ずれており、同期ミーティングの時間確保が困難。Slackのメッセージが埋もれて「見逃し」が週 5件 発生。
非同期ファーストのコミュニケーション計画
| 種類 | 手段 | ルール |
|---|---|---|
| 日次進捗 | Slack非同期（ボット） | 各自のTZ朝にテキスト投稿 |
| 技術判断 | GitHub Discussion | 48時間以内にレスポンス |
| 緊急連絡 | Slack＋メンション | 4時間以内にレスポンス |
| 週次同期 | Zoom（唯一の同期会議） | 全TZが参加可能な時間帯 |
「緊急」の定義を明文化（本番障害・ブロッカーのみ）し、それ以外は非同期で対応。見逃しは 週5件 → 週0.5件 に減少し、不要な深夜ミーティングもなくなった。
やりがちな失敗パターン#
- 全員に同じ粒度で報告する — 経営層が欲しいのは1枚のサマリーであり、50ページの詳細資料ではない。受け手に合わせて粒度を変える
- 計画を作って終わりにする — 月次で「情報は適切に届いているか」をステークホルダーにフィードバックを求め、計画を更新する
- プッシュ型だけに頼る — メールや会議は発信側の負荷が大きい。ダッシュボードやWikiなどプル型と組み合わせて、「見たい人がいつでも見られる」状態を作る
- 発信責任者を決めない — 「誰かが報告するだろう」と思っていると誰も報告しない。各コミュニケーション項目にオーナーを明記する
まとめ#
コミュニケーション計画は「伝えたつもり」と「伝わった」のギャップを埋めるための設計図だ。ステークホルダーごとに情報ニーズを把握し、頻度・手段・発信者をマトリクスで明確にすることで、場当たり的な報告から脱却できる。プッシュ型とプル型を組み合わせ、PMの負荷を分散しながら全員が必要な情報にアクセスできる仕組みを目指す。