プロジェクトコミュニケーション計画：作成方法（テンプレートと具体例）

コミュニケーション計画は、プロジェクトの ステークホルダーが情報を把握して足並みをそろえられるか、それとも不満と驚きの連続になるかを左右する文書です。計画がなければ、適切な情報が適切な人に適切なタイミングで届くことはほとんどなく、プロジェクトの問題のほとんどはまさにそのギャップに起因しています。

プロジェクトコミュニケーション計画とは何か

プロジェクトコミュニケーション計画とは、誰がどの情報を必要としているか、どのチャネルを通じて、どの頻度で、誰が送信する責任を持つかを定義した文書です。単なる会議のスケジュールではありません。プロジェクトライフサイクル全体を通じて関係者が効果的に動けるよう、すべてのオーディエンスとすべての情報フローを意図的に対応させたものです。

最初のステータス更新が送られる前にプロジェクトチームが交わす合意書と考えてください。スポンサーがスコープ変更の情報を共有されなかったと問い合わせてきたとき、あるいは開発者が新しい締め切りを噂で聞いたと言うとき、根本原因はたいていコミュニケーション計画が存在しないか、無視されていることです。

この計画は、プロジェクト憲章やRAIDログと並ぶ、プロジェクト統治の基礎文書です。プロジェクト開始時に作成し、オーディエンス、配信チャネル、頻度が大きく変化するたびに更新します。

主要なデータ

• PMIの「Pulse of the Profession」レポートによると、**プロジェクト予算のリスクの56%**がコミュニケーション不足に起因しています。
• 同調査では、効果的なコミュニケーション慣行を持つ組織は、そうでない組織に比べて3倍以上のプロジェクトを期日内かつ予算内で完了させていることがわかっています。
• PMIはさらに、ハイパフォーマンスな組織はコミュニケーション計画を標準として文書化している可能性が2.6倍高いとも報告しています。

コミュニケーション計画の主要要素

効果的なコミュニケーション計画はすべて、プロジェクトの規模や業界を問わず、同じ6つの次元をカバーしています。6つすべてを一目で確認でき、抜け漏れが明確になるため、表形式が最もわかりやすい形式です。

この6つを組み合わせることで、特定の情報フローに関するあらゆる疑問に答えられます。1つでも欠けていれば、計画に穴があります。

優れた計画にはコミュニケーションエスカレーションパス（通常のサイクル外で緊急事態が発生した場合の対応方法）も含まれています。大規模プロジェクトでは、フィードバックの仕組みも追加してください。各オーディエンスがコミュニケーションに問題を感じたとき、プロジェクトチームにどのように伝えるかを定めます。

コミュニケーション計画の具体例

以下は、部門横断のオーディエンスを持つ中規模のソフトウェア展開プロジェクトの記入例です。

各行が具体的であることに注目してください。エグゼクティブスポンサーには隔週のメールとステアリングコミッティでの10分間の口頭ブリーフィングの両方が届きます。「定期的な更新」といった曖昧な表現ではありません。この具体性こそが、3カ月後の「知らなかった」という会話を防ぎます。

コミュニケーション計画の作成方法

小規模プロジェクトでは数時間、大規模プロジェクトでは丸1日かかります。以下の6ステップはどちらにも適用できます。

ステップ1：ステークホルダーを特定する

コミュニケーションフローを定義するには、まずオーディエンスが誰かを把握する必要があります。プロジェクトに関わるすべての人、チーム、グループをリストアップしてください。これはステークホルダー分析マトリクスと同じ作業であり、すでに実施済みであればそれを出発点として活用できます。

ステークホルダーを影響力と関心度でソートします。影響力が高く関心度も高いステークホルダー（主にスポンサーや主要な意思決定者）には頻繁で詳細なコミュニケーションが必要です。影響力は高いが関心度が低いステークホルダー（承認はしたが日常業務に関わらないエグゼクティブ）には簡潔で例外事項に絞った更新が必要です。影響力は低いが関心度が高いグループ（変更の影響を受けるエンドユーザー）には、自分たちに関連することについての定期的でわかりやすいコミュニケーションが必要です。

ステップ2：各ステークホルダーが知るべき内容を定義する

各ステークホルダーについて、「彼らはどのような意思決定をするのか、そして質の高い意思決定のためにどんな情報が必要か」を問いかけてください。エグゼクティブスポンサーはプロジェクトが順調かどうか、そして自分の介入が必要なリスクがあるかどうかを知りたいと考えています。開発者は今のSprintで何を作るのか、仕様がいつ確定するのかを知りたがっています。エンドユーザーは何が変わるのか、いつ変わるのか、自分が何をすべきかを知りたいと思っています。

平易な言葉で書き出してください。「プロジェクト更新」のような一般的なラベルは人によって意味が異なるため避けましょう。具体的な表現が常に優れています。「財務情報」ではなく「予算実績と見込み」とします。

ステップ3：各フローに適切なチャネルを選ぶ

チャネルの選択は、媒体をメッセージとオーディエンスの習慣に合わせることです。間違ったチャネルはコミュニケーションがないよりも悪い結果をもたらします。週次メールダイジェストに埋もれた緊急のリスク警告は、実質的に警告なしと同じです。

以下の原則を参考にしてください。

• 緊急かつ重要度が高い場合： ダイレクトメッセージ、電話、または専用会議
• 定期的な構造化更新： メールレポートまたは定例会議
• 必要なときに参照する情報： 共有ドキュメント、ダッシュボード、イントラネットページ
• チームの調整： プロジェクトツールのタスク更新と定期Stand-up

すべてをメールで済ませることに注意が必要です。受信トレイの過負荷は現実の問題です。ステークホルダーがすでにメールを無視しているなら、メールで届けるコミュニケーション計画も同様に無視されます。

ステップ4：頻度を設定する

内容と同様、頻度も重要です。多すぎるとステークホルダーがメッセージをフィルタリングし始めます。少なすぎると、その空白を埋めるために都度更新を求めてきます。それは定期的な頻度を設けるよりも多くの時間を要します。

実際の変化に合わせて頻度を決めます。スポンサーへのプロジェクトステータスレポートは、実行フェーズは週次、比較的落ち着いたフェーズは隔週が適切です。エンドユーザーへの変更通知は主要なMilestoneのタイミングが適切で、軽微なタスク完了のたびに通知する必要はありません。

プロジェクトの自然なリズムに頻度を合わせましょう。Sprintレビュー、Milestoneゲート、プロジェクトキックオフミーティングは、コミュニケーションの起点として自然に機能します。

ステップ5：担当者を割り当てる

計画内のすべてのコミュニケーションに担当者を明記する必要があります。スケジュール通りに制作・配信する責任を持つ人物です。担当者が指定されていなければ、「誰かが送る」が「誰も送らない」になります。

プロジェクトマネージャーはスポンサーやエグゼクティブへの対外的なコミュニケーションの大部分を担います。Scrum Masterまたはチームリードは通常、内部のチームコミュニケーションを担います。特定グループへの技術的なコミュニケーションは専門家や部門リードが担います。コミュニケーション全体の担当関係が複雑な場合はRACIマトリクスを活用してください。

ステップ6：計画をレビューして維持する

キックオフ時に作成してその後一度も更新されないコミュニケーション計画は、根拠のない安心感を生むため、計画がない場合よりも悪い結果をもたらします。各主要Milestoneまたはフェーズゲートでレビューをスケジュールしてください。確認事項は以下の通りです。

• ステークホルダーリストに変更はあったか
• 選んだチャネルは引き続き機能しているか
• プロジェクトの現在地にとって頻度は適切か
• ステークホルダーは実際に受け取った情報を読んで行動しているか

プロジェクトキックオフミーティングからのフィードバックや、主要なステークホルダーとの振り返りの会話を計画に反映させましょう。計画はチェックボックスではなく、生きた文書です。

コミュニケーションチャネルと頻度のガイド

コミュニケーションの目的に応じて、適切なチャネルとリズムは異なります。最も一般的なプロジェクトコミュニケーションの種類を以下に簡単にまとめます。

各チャネルに適した頻度はプロジェクトのペースによって異なります。AgileのSprintサイクルはWaterfallのフェーズよりも速い内部リズムを生み出します。任意のカレンダーではなく、プロジェクトの進行に合わせてコミュニケーションの頻度を調整してください。

ベストプラクティス

計画はプロジェクト開始時に、開始後ではなく作成する。 コミュニケーションの問題は時間とともに悪化します。ステークホルダーが明確な情報なしに過ごす1週間ごとに、思い込みが積み重なっていきます。

短くてスキャンしやすい形式を保つ。 誰も読まないコミュニケーション計画は役に立ちません。表形式を使用し、長文の段落は避けてください。本記事の6列の表形式は、マニュアルにならずに必要な要素をすべてカバーしています。

定期的なサイクルとトリガー型コミュニケーションを分ける。 計画には2つのセクションを設けます。スケジュールされたコミュニケーション（週次レポート、Stand-up、ステアリングコミッティ会議）とトリガー型コミュニケーション（リスクのエスカレーション、スコープ変更、続行可否の判断）です。両方に担当者とチャネルが必要ですが、カレンダーは共有しません。

キックオフ時にステークホルダーの承認を得る。 プロジェクトキックオフミーティングでコミュニケーション計画を説明します。チャネルと頻度が適切かどうかをステークホルダーに確認します。フィードバックによって実際の制約（CFOはSlackをチェックしない、テックリードは会議よりも非同期を好む）が明らかになることが多く、計画の実行可能性が大幅に向上します。

チームが変わったときに見直す。 ステークホルダーが加わったり離れたりしたとき、または新たなリスクが発生して新しいコミュニケーションフローが必要になったとき、計画を更新してください。バージョン番号と最終更新日付きの生きた文書として扱います。

よくある失敗

コミュニケーション計画を会議スケジュールと混同する。 計画はすべての情報フローをマッピングするものであり、カレンダー上の会議だけではありません。ステータスレポート、ダッシュボードへのアクセス、Slackチャネル、メールアナウンスもすべてコミュニケーションフローです。計画に記載されていなければ、一貫性なく行われるでしょう。

すべてに同じチャネルを使う。 すべてのコミュニケーションをメールで行うと受信トレイが混雑し、緊急度が見えにくくなります。目的に応じてチャネルを使い分けてください。緊急事項にはより速いチャネルが必要です。参考情報には検索可能で引き出し型のチャネルが適しています。

担当者欄を忘れる。 何を伝えるかは記載しているが誰が責任を持つかを記載していない計画は、ほぼ即座に機能しなくなります。すべての行に役職やチームではなく、具体的な担当者名が必要です。

計画を一度きりの成果物として扱う。 プロジェクトは変化します。ステークホルダーも変化します。計画フェーズで機能したチャネルが実行フェーズで機能するとは限りません。主要なMilestoneごとにコミュニケーション計画のレビューをスケジュールしてください。

ステークホルダーに不要な情報を与えすぎる。 すべてのステークホルダーがすべての更新を必要としているわけではありません。情報過多はステークホルダーが重要なものも含めてすべてのコミュニケーションをフィルタリングすることにつながります。オーディエンスを慎重に分け、各グループには関連する内容だけを送信してください。

双方向のコミュニケーションを無視する。 情報を発信するだけの計画は全体像の半分しかカバーしていません。フィードバックの仕組みを組み込んでください。定期的な振り返りの質問、ステークホルダーが懸念を提起するための定例アジェンダ項目、またはシンプルな返信可能なメールの仕組みなどが有効です。

よくある質問

コミュニケーション計画には何を含めるべきですか？

最低限、ステークホルダーのリスト、各人が必要とする情報、届けるためのチャネル、頻度、責任者、形式を含めます。大規模プロジェクトでは緊急時のエスカレーションパスとフィードバックの仕組みも含めます。6列の表形式（オーディエンス、メッセージ、チャネル、頻度、担当者、形式）は、これらすべてを1つのスキャン可能な文書にまとめられます。

コミュニケーション計画とステークホルダー管理計画はどう違いますか？

ステークホルダー分析マトリクスは、プロジェクト全体を通じてステークホルダーを特定し、評価し、エンゲージメントを計画することに焦点を当てています。コミュニケーション計画はより範囲が狭く、プロジェクトチームとステークホルダーの間の実際の情報フローを定めます。両者は関連しています。ステークホルダー分析は相手が誰で、どのくらいの影響力を持つかを示し、コミュニケーション計画は具体的に何をいつどのように送るかを定めます。多くのプロジェクトではステークホルダー分析を先に作成し、それをコミュニケーション計画への入力として活用します。

コミュニケーション計画はいつ作成すべきですか？

プロジェクト開始時、プロジェクト憲章と初期リスク評価と並行して作成します。主要なステークホルダーとのレビューと合意をプロジェクトキックオフミーティングで行えるよう、そのミーティングの前に下書きしておきます。実行開始後に作成することも、作成しないよりはましですが、すでに非公式に形成されたコミュニケーションパターンを整理するために余分な時間がかかります。

コミュニケーション計画はどのくらいの長さにすべきですか？

必要な長さにとどめ、それ以上は加えないことが原則です。ステークホルダーが5人の小規模プロジェクトなら1ページに収まるかもしれません。複数の組織にわたる30名以上のステークホルダーを抱える大規模プログラムでは、内部と外部のコミュニケーションを分けたセクションを持つ複数ページの文書が必要になるかもしれません。適切な長さは、余分なものを加えることなくすべての重要なコミュニケーションフローを把握できるものです。

プロジェクト中にコミュニケーション計画は変わりますか？

はい、そして変わるべきです。ステークホルダーリストが変わったとき、プロジェクトスコープが大きく移動したとき、コミュニケーションチャネルが機能しなくなったとき、計画を更新してください。ベストプラクティスは、主要なMilestoneゲートごとに計画を見直すことです。現在のバージョンを示すバージョン番号と最終更新日で変更を管理しましょう。

---

コミュニケーション計画は単独で存在するものではありません。週次プロジェクトステータスレポートを推進し、ステークホルダー会議の頻度を定め、何をいつ伝えたかという記録をlessons learnedに反映させる文書です。最初から正しく整備すれば、プロジェクトの情報はほぼ自動的に流れます。誤れば、本来もうすでに持っているべき更新をステークホルダーに追いかける羽目になります。