コミュニケーション・マネジメントの計画とは何か？PMBOK第8版のITTOと3つのコミュニケーション方法を解説

「言ったはずなのに、伝わっていなかった」。プロジェクトで起きるトラブルをたどっていくと、最後にはたいていここに行き着きます。

コミュニケーション・マネジメントの計画は、その「伝わらなかった」を、個人の気配りではなく計画で防ぐためのプロセスです。この記事では、PMBOK第8版の内容にもとづいて、このプロセスで何を考え、何を決めるのかを整理していきます^[1]Project Management Institute, Inc., A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition（日本語版）, 第2部 … Continue reading。

コミュニケーション・マネジメントの計画の概要

コミュニケーション・マネジメントの計画とは、プロジェクト・チームの内外にいる特定のステークホルダーと、どのようにコミュニケーションを取るかを計画する活動です。

PMBOK第8版で押さえておきたいのは、このプロセスが単独で存在していない点です。ステークホルダーの特定や分析、エンゲージメント活動と深く重複しており、ステークホルダー・エンゲージメント計画書と密接に連携させることが求められています。連携させることで、コミュニケーション戦略の一貫性が保たれ、ステークホルダーの期待とのズレも起きにくくなります。

裏を返せば、誰がステークホルダーなのかが曖昧なまま「週次で定例会をやりましょう」と決めても、それは計画とは呼べない、ということでもあります。

計画の土台になるのは「情報のカテゴリー分析」

第8版で明確に述べられているのが、コミュニケーションを設計する前に情報そのものを分類するという考え方です。

プロジェクトで扱う情報には、次のようなカテゴリーがあります。

• 内部情報と外部情報
• 機密情報と公開情報
• 一般情報と詳細情報

ステークホルダーの情報ニーズと、これらの情報カテゴリーを分析することが、適切なコミュニケーション・プロセスと計画を確立するための土台（ファンデーション）になる、とされています。

この視点は実務でもそのまま使えます。同じ「進捗」という情報でも、社内の開発チームに渡す詳細な進捗と、クライアントの役員に渡す一般情報としての進捗は、粒度も、渡す頻度も、渡してよい範囲もまったく違います。機密情報にいたっては、誰が公開を承認するのかまで決めておかないと、現場の判断で外に出てしまいます。

「誰に伝えるか」を考える前に、「どの種類の情報を扱うプロジェクトなのか」を先に仕分けする。これが第8版の出発点です。

一度作って終わりではない

もうひとつ押さえておきたいのが、実施のタイミングです。

コミュニケーション・マネジメントの計画は、プロジェクトの立ち上げ時や初期段階に行われますが、そこで完結するものではありません。プロジェクトの環境変化、フェーズの移行、ステークホルダー・コミュニティの変更にともなって、プロジェクト全体を通じて定期的にレビューされ、更新（段階的詳細化）されていくプロセスです。

これは、ステークホルダーの特定やエンゲージメントの計画とまったく同じ性質です。関係者が入れ替われば、伝えるべき相手も、伝え方も変わります。最初に作った連絡体制図を貼ったまま半年が過ぎている、という状態は、それ自体がリスクだと考えてよいと思います。

コミュニケーション・マネジメントの計画のインプット

このプロセスでは、次の文書・情報を材料に使います。

プロジェクト憲章

プロジェクトの目的と、初期段階で認識されている主要なステークホルダーが記載されています。コミュニケーションを取るべき相手に漏れがないかを確認する、最初の手がかりになります。

プロジェクトマネジメント計画書

• 資源マネジメント計画書：どのような個人・団体がプロジェクトに関わっているかを確認します。定例会に出るメンバーだけでなく、会議には出ないデザイナーやコーダー、外注先といった人たちを把握するのに欠かせません
• ステークホルダー・エンゲージメント計画書：それぞれのステークホルダーと、どう関係を築いていくかの戦略が書かれています。コミュニケーションの方法は、この戦略と矛盾しないよう設計します

プロジェクト文書

• 要求事項文書：報告の形式や頻度について、プロジェクト開始前後から要求が出ていることがあります。その内容をここで拾います
• ステークホルダー登録簿：関係者の一覧に加え、プロジェクトへの期待や態度も記録されています

組織体の環境要因（EEF）

組織の文化や政治情勢、ガバナンスの枠組み、人事管理方針、すでに確立しているコミュニケーション・チャネルやツール、施設や資源の地理的な分布などが該当します。

ここで大切なのは、コミュニケーションを円滑にする要因と、阻害する要因を見きわめることです。組織ですでに定着しているチャットツールをそのまま使えるなら、それは追い風になります。一方で、部署間の関係が良くない、決裁に必ず特定の人を通す必要がある、といった事情は、そのまま伝達の遅れに変わります。

組織のプロセス資産（OPA）

情報の作成・交換・保管・検索に関する標準ガイドライン、ソーシャルメディアやセキュリティに関する社内方針、過去の教訓リポジトリ、以前のプロジェクトのステークホルダー情報などです。ゼロから設計せず、使えるものがないかを先に確認します。

コミュニケーション・マネジメントの計画のツールと技法

PMBOK第8版で挙げられているツールと技法は、次のとおりです。

専門家の判断

組織の規模、慣行、政治情勢といった環境要因や、社内のガイドライン・教訓を踏まえて、円滑なコミュニケーションの取り方を検討します。組織内の事情に通じた人に加わってもらうと精度が上がります。

コミュニケーション要求事項分析

ステークホルダーの情報ニーズを特定するための分析です。次のような情報源から、必要な要求事項を洗い出します。

• ステークホルダー情報、組織図
• 潜在的なコミュニケーション・チャネル（パス）の数
• 開発アプローチ
• プロジェクトに関係する専門分野・部門・特殊技能
• 参加人数や所在地といったロジスティックスに関する事項
• 組織内部の情報ニーズ、メディアなど外部の情報ニーズ
• 法的要求事項

チャネル数は、関係者が増えるほど急激に増えていきます。「関係者が2人増えただけ」に見えても、経路の数はそれ以上に増える、という感覚は持っておいて損がありません。

コミュニケーション技術

情報の転送に使う具体的なツール、システム、プログラムのことです。チャットツール、Web会議システム、プロジェクトマネジメント情報システム（PMIS）などがこれにあたります。

コミュニケーション・モデル

情報がどう送られ、どう受け取られるかを表したモデルです。第8版では次のように整理されています。

• 直線的モデル：送り手から受け手へ、一方向に情報が流れるモデル
• 双方向モデル：受け手からのフィードバックを含むモデル
• より複雑な人間要素を含むモデル：感情の状態、文化的背景、先入観といったノイズ・障壁を考慮したモデル

実務で効いてくるのは3つ目です。同じ文面を送っても、受け手が今どういう状況にあるかで、届き方はまったく変わります。「送った」と「伝わった」の間には、この障壁が挟まっているという前提で計画を立てます。

コミュニケーション方法

情報を伝達するための体系的な手続きです。第8版では3つに分類されており、重要な論点なので次の章で詳しく見ていきます。

人間関係とチームに関するスキル

• コミュニケーション・スタイルの評価：支援的でないステークホルダーなどについて、期待されるスタイルとのギャップを特定し、その相手に適した方法を見つける技術です
• 政治的認識：組織内のフォーマル／インフォーマルな権力関係を理解することです。組織図に書かれている決裁ラインと、実際に物事が決まるラインが違うことは珍しくありません
• 文化的な認識：個人や組織の違いを理解し、誤解を最小限に抑えるように振る舞いを適応させる能力です

データ表現

ステークホルダー関与度評価マトリックスを用います。各ステークホルダーの現在の関与度と、望ましい関与度のギャップを視覚的に把握できます。ギャップの大きい相手ほど、コミュニケーションの設計に手をかける必要がある、という判断につながります。

会議

計画を固めるには、プロジェクト・チームとの議論が欠かせません。まずチーム内部の情報の流れを固めてから、外部に広げていく順序が進めやすいと思います。

コミュニケーション方法は3つに分類される

第8版では、情報を伝達する方法が次の3つに整理されています。この分類は、計画を立てるときの実用性が高い部分です。

分類	特徴	主な手段
双方向コミュニケーション	2者以上の当事者間で、リアルタイムに多方向の情報交換を行う	会議、電話、インスタント・メッセージ、ビデオ会議、一部のソーシャルメディア
プッシュ型コミュニケーション	情報を受け取る必要がある特定の受信者へ、直接送信・配布する	手紙、メモ、報告書、電子メール、ファックス、ボイスメール、ブログ、プレスリリース
プル型コミュニケーション	受信者が自分の裁量でコンテンツにアクセスする。大量の情報や大人数が対象のときに適する	Webポータル、イントラネットサイト、eラーニング、教訓データベース、知識リポジトリ

ここで注意したいのが、プッシュ型についてPMBOKが明記している点です。プッシュ型は情報が配布されたことは保証しますが、意図した受け手に届いたことや、正しく理解されたことまでは保証しません。

メールを送った時点で「伝えた」ことにしてしまうと、この保証の範囲を取り違えることになります。相手の理解まで確認したい情報は双方向で扱い、記録として残したい情報はプッシュ型で送り、いつでも参照できるようにしておきたい情報はプル型で置いておく。この3つを、情報の種類ごとに割り当てていくのが計画の中身になります。

アウトプット：コミュニケーション・マネジメント計画書

このプロセスの最重要成果物が、コミュニケーション・マネジメント計画書です。プロジェクトマネジメント計画書の構成要素であり、いつ、誰が、どのようにプロジェクトの情報を管理し、発信するのかを記述したものです。

第8版では、主に次の項目を記載するとされています。

• ステークホルダーのコミュニケーション要求事項
• 言語、形式、内容、詳細レベルなど、伝達する情報
• 問題発生時のエスカレーション・プロセス（上申手続き）
• その情報を配信する理由
• 情報の配布頻度、および受領確認や応答が必要な場合のタイムフレーム
• 情報を伝達する責任者、および機密情報のリリースを承認する責任者
• 情報を受信する個人またはグループ
• コミュニケーション活動に割り当てられる資源（時間や予算）
• 計画書を更新・洗練するための方法
• 一般的な用語集
• 情報フローのフローチャート、承認シーケンス、報告書リスト、会議計画など
• 特定の法律や規制、技術、組織方針から派生する制約条件

第6版の記載事項と見比べると、受領確認のタイムフレーム、機密情報のリリース承認者、承認シーケンスや会議計画といった項目が、より具体的に示されているのが分かります。前の章で触れた「情報のカテゴリー分析」や「プッシュ型は理解まで保証しない」という考え方と、きれいに対応しています。

つまり、機密情報を分類したなら承認者を決める。プッシュ型で送ると決めたなら、いつまでに受領確認をもらうかを決める。ここまで書いて、はじめて計画書として機能します。

その他のアウトプット

コミュニケーション・マネジメント計画書のほかに、次の更新が発生します。

プロジェクトマネジメント計画書の更新

ステークホルダー・エンゲージメント計画書が対象です。コミュニケーションの方法を検討する過程でステークホルダーとの関係の見直しが起きれば、エンゲージメント戦略の側も合わせて更新します。

プロジェクト文書の更新

• ステークホルダー登録簿：連絡先や関与レベルなどに変更があれば反映します
• プロジェクト・スケジュール：コミュニケーションの設計によって、想定より意思決定に時間がかかることが分かる場合があります

スケジュールの更新は見落とされがちですが、影響は小さくありません。たとえばクライアントが世界規模の企業で、海外の担当者を含めて合意を取る必要があるなら、承認一つに要する日数は国内で完結する場合と変わります。その日数はコミュニケーションを設計してはじめて見えてくるものなので、判明した時点でスケジュールに織り込みます。

Web制作の現場では「決め方」を先に決めておく

ここまでPMBOKの枠組みを見てきましたが、私が実務で意識しているのは、次の3点に絞られます。

1. 情報の種類ごとに、伝達方法をあらかじめ割り当てておく

毎週の進捗はプッシュ型（定型のメール報告）、仕様の判断が必要な論点は双方向（打ち合わせかチャットでのやり取り）、確定した仕様書やデザインデータはプル型（共有フォルダやプロジェクト管理ツール）。この振り分けを最初に決めておくと、「重要な判断がチャットの流れに埋もれる」という事故が減ります。

2. エスカレーションの経路を、平時のうちに決めておく

エスカレーション・プロセスは、問題が起きてから考えるものではありません。「現場で決められないことが出たとき、誰に上げるのか」を、双方が穏やかなうちに合意しておきます。これを決めていないプロジェクトほど、こじれたときに止まります。

3. 会議に出ないメンバーへの伝達経路を用意しておく

定例会に出るのは、クライアントの担当者とこちら側の窓口だけ、というケースは多いはずです。しかし実際に手を動かすデザイナーやエンジニアは、その場にいません。会議で決まったことがその人たちに届く経路まで含めて設計しないと、計画は途中で切れてしまいます。資源マネジメント計画書をインプットに置く意味は、ここにあると思います。

まとめ

コミュニケーション・マネジメントの計画は、「こまめに連絡を取り合いましょう」という心構えを、文書に落とし込むプロセスです。PMBOK第8版では、扱う情報を内部／外部、機密／公開、一般／詳細といったカテゴリーで分析することを土台に置き、双方向・プッシュ型・プル型という3つの伝達方法を使い分ける形で設計するよう示されています。

そして、この計画は一度作って終わりではありません。フェーズが移り、関係者が入れ替われば、伝えるべき相手も伝え方も変わります。ステークホルダーの特定やエンゲージメントの計画と同じように、節目ごとに見直していくことが前提のプロセスです。

トラブルの原因が「伝わっていなかった」ことにある以上、その予防に使える時間はいくらでも元が取れます。まずは自分のプロジェクトで、どの情報を、誰に、どの方法で届けているのかを書き出してみるところから始めてみてください。