PM初心者が押さえたいコミュニケーション計画の作り方：誰に・何を・いつ伝えるか

「報告はしていた。でも伝わっていなかった」——プロジェクトのトラブルを振り返ったとき、こういう結論に至ることがよくあります。技術的な問題ではなく、情報の届け方の設計ミスが原因です。PMIの調査では、プロジェクト失敗の約56%がコミュニケーションの問題に起因するとされており、これは多くのPMが実感として持っている数字でもあります。

コミュニケーション計画とは何か、何でないか

コミュニケーション計画とは、誰に・何を・いつ・どうやって伝えるかをあらかじめ設計した文書です。

よくある誤解は、「計画を作ること」が目的になってしまうことです。20行を超える精緻な表を作っても、誰も見なければ意味がありません。コミュニケーション計画の本来の目的は「情報が届くべき人に、届くべきタイミングで届く状態をつくること」です。最初は5〜8行で十分です。

項目	計画なし	計画あり
情報共有のタイミング	思い出したとき	定期的・事前に決まっている
報告の抜け漏れ	頻繁に発生	仕組みで防止できる
ステークホルダーの不満	「聞いていない」が多発	期待値が揃っている
問題発覚のタイミング	深刻化してから	早期に察知できる

計画に含める5つの問い

難しく考えなくていいです。以下の5つに答えるだけで、骨格ができます。

① 誰に（対象者）

「チーム全員」という括り方はしない。「開発リーダー」「営業部長」のように、具体的な個人・役職で書きます。括りが大きいほど、誰かへの共有が漏れます。

② 何を（内容）

「プロジェクトの状況」は曖昧すぎます。「予算消化率・スケジュール遵守率・直近のリスク3件」のように、項目を絞って書きます。受け取る側が「何が来るか」を事前に想定できる粒度が理想です。

③ いつ（頻度・タイミング）

「定期的に」ではなく「毎週月曜10時」のように固定します。頻度の目安は次のとおりです。

対象	推奨頻度
経営層・スポンサー	月1回または節目ごと
プロジェクトチーム	週1回
外部ベンダー	週1〜2回

④ どの手段で（チャネル）

緊急度が高いものを長いメールで送るのはやめましょう。「速報はSlack・詳細はメール・意思決定は会議」のように、内容と手段を対応させます。

⑤ 誰が伝えるか（送信者・責任者）

担当が「PM」だけに集中していると、PM不在時に情報共有が止まります。「ベンダーとの調整は開発リーダー」のように役割を分散させます。

ステークホルダー別に伝え方を変える

同じ内容を全員に同じ形で伝えるのは非効率です。経営層には細かい技術仕様は不要で、チームメンバーには「何をすればいいか」が明確でなければなりません。

経営層・スポンサー

求めているのは「予定通りか否か」「追加投資が必要か」「経営判断が必要なリスクはあるか」の3点です。1ページのサマリーを月1回、というスタイルが最も読まれます。細かい数字や技術的な詳細は別添付にして、本文には触れない方が伝わります。

プロジェクトチームメンバー

「何をすれば良いか」が常に明確な状態を保つことが目標です。タスクの優先順位・ブロッカーの解消・次のアクションを週次で同期します。毎週月曜の15分スタンドアップが機能しているチームは、情報の滞留が起きにくいです。

外部ベンダー・パートナー

社内事情を共有しすぎないよう注意が必要です。「彼らに何をしてほしいか」を軸に情報を絞り、確認・依頼事項を明確にして伝えます。週次定例＋毎回の議事録共有がベースとして機能します。

すぐ使えるテンプレート

No.	対象者	内容	頻度・タイミング	手段	担当者	備考
1	経営層・スポンサー	月次進捗報告（予算・スケジュール・リスク）	毎月第1月曜	報告書 + 月次会議30分	PM	1ページサマリー形式
2	開発チーム全員	週次進捗確認・タスク優先順位・ブロッカー共有	毎週月曜10:00	スタンドアップ会議15分	PM	各自5分以内で発言
3	外部ベンダーA社	仕様確認・納品スケジュール調整	毎週水曜14:00	オンライン会議30分	開発リーダー	議事録をSlackで共有
4	営業部	リリース日程・機能仕様の変更連絡	変更発生時	メール	PM	変更から24時間以内に送付
5	プロジェクト全体	リスク管理表の更新共有	隔週金曜	Notionドキュメント更新 + Slack通知	PM補佐	全員が閲覧できる権限設定

うまくいかないときの4パターン

報告が遅れる・忘れる

報告のタイミングが「なんとなく」になっており、リマインドがないと動かない状態です。カレンダーに定例を登録するだけでなく、「報告書作成（30分）」という準備作業もブロックしておくと大幅に改善します。

情報が多すぎて読まれない

「念のため全部入れた」報告書が10ページを超え、受け取った側が読むのを諦めるパターンです。経営層への報告は「3分で読める量」が目安です。結論を最初に書くBLUF（Bottom Line Up Front）形式も有効です。

計画を作ったまま更新されない

プロジェクト開始時に作ったきりで、メンバーが増えたり状況が変わっても計画が変わらない状態です。月次レビューの議題にコミュニケーション計画の見直しを入れるだけで鮮度が保てます。

担当者がPM一人になっている

すべての情報発信をPMが担当していると、PM不在時に情報共有が止まります。PMはハブではなく、仕組みの設計者であるべきです。「誰が担当するか」を計画に明記して、役割を分散させます。

AIを使ってコミュニケーション計画の叩き台を作る

関係者のリストとプロジェクト概要をAIに渡すと、計画の叩き台が数分で完成します。

プロンプト例

以下のプロジェクトのコミュニケーション計画を作成してください。
表形式（対象者 / 内容 / 頻度 / 手段 / 担当者）でまとめてください。
5〜8行程度で実用的な内容にしてください。

【プロジェクト概要】
・新しい勤怠管理システムの導入（クラウドツール移行）
・期間：3ヶ月
・関係者：経営層、人事部、エンジニア2名、外部ベンダー1社、全社員（エンドユーザー）

出力サンプル

対象者	内容	頻度	手段	担当者
経営層	進捗・予算・重要リスクの報告	月1回	報告書＋月次会議30分	PM
人事部	要件確認・仕様変更の共有	週1回	定例会議15分	PM
エンジニア	タスク優先順位・ブロッカー確認	週1回	スタンドアップ15分	PM
外部ベンダー	仕様確認・納期調整	週2回	オンライン会議＋メール	PM
全社員	リリース日程・操作案内	リリース前後2回	社内メール＋説明会	PM＋人事
プロジェクト全体	リスク表の更新共有	隔週	Notionドキュメント＋Slack通知	PM補佐

AIが出した計画は叩き台として使い、「この関係者、抜けていないか？」を自分でチェックするのがポイントです。

結局、最初にやるべきことは3つだけ

コミュニケーション計画は、プロジェクト開始時に完璧なものを作る必要はありません。最初に決めるべきことは3つです。

経営層・スポンサーへの定期報告（頻度・形式・担当者）
チーム内の週次同期（いつ・どこで・何を話すか）
緊急時の連絡ルート（誰に・どの手段で・何分以内に）

この3点が決まっているだけで、プロジェクトの安定感は変わります。その後2〜4週間ごとに「計画通りに情報が届いているか」を振り返り、実態に合わせて更新していく。コミュニケーション計画はプロジェクトと一緒に育てていくものです。