近年、プロジェクトマネジメントの現場では、非常に便利なタスク管理ツールやチャットツールが当たり前のように導入されるようになりました。
「ツールを入れたのだから、誰が何をしているか可視化されて、コミュニケーションは劇的に円滑になるはずだ!」
そう期待していたのに、いざプロジェクトを進めてみると、「聞いていません」「そういう意味だとは思いませんでした」といったコミュニケーションの齟齬が後を絶たない……。そんな悩みを抱えるプロジェクトマネージャーは少なくありません。
実は「ツールの導入 = コミュニケーションの円滑化」とは限りません。ここで重要になるのが、仕組みが本当に機能しているかをチェックし、改善し続ける視点です。
今回は、PMBOK第8版における「コミュニケーションの監視(Monitor Communications)」について、実務でよくあるツールの落とし穴を交えながら解説します[1]Project Management Institute, Inc., A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition(日本語版), 第2部 … Continue reading。
PMBOK第8版における「コミュニケーションの監視」の概要
PMBOK第8版において、「コミュニケーションの監視」とは、プロジェクトおよびそのステークホルダーの情報ニーズが確実に満たされているかを確認・監督するプロセスと定義されています。プロジェクトの開始から終了にいたるまで、継続的に実施されます。
プロセスの目的と本質
このプロセスの最大の目的は、計画した「最適な情報の流れ(情報フロー)」が常に維持・担保されることです。
ここで非常に重要なのは、PMBOKが求めているのは「計画通りに報告書を送った(送信した)か」という実績を追うことではない、という点です。
「ステークホルダーが本当にその情報を必要とし、正しく理解し、それに基づいた適切な意思決定や行動ができているか」という、実質的な対話の効果に焦点を当てて監督することが本質的なアプローチになります。
「ステークホルダー・エンゲージメントの監視」との違い
似たようなプロセスに「ステークホルダー・エンゲージメントの監視」がありますが、何が違うのでしょうか。
- エンゲージメントの監視: ステークホルダー自身の「プロジェクトに対する関与度や協力的な姿勢」が上手く保たれているかを監視します。
- コミュニケーションの監視: ステークホルダーたちとの「コミュニケーションの仕組みや情報の経路」が上手く機能しているかを監視します。
つまり、コミュニケーションの監視は「メッセージを届けるためのパイプ(仕組み)」が詰まったり漏れたりしていないかをメンテナンスする作業と言えます。
プロセスのインプット・ツール・アウトプット(ITTO)
プロジェクトのコミュニケーションが機能しているかを評価し、改善していくために、PMBOKの日本語公式版では以下のITTO(インプット、ツールと技法、アウトプット)が定義されています。
インプット(前提となる情報・データ)
監視を始めるために、まずは現状の計画や実際に配られた情報の記録を確認します。
- プロジェクトマネジメント計画書(資源マネジメント計画書、コミュニケーション・マネジメント計画書、ステークホルダー・エンゲージメント計画書)
- プロジェクト文書(課題ログ、教訓登録簿、プロジェクト伝達事項[実際に配布・発信された情報実績])
- 作業パフォーマンス・データ(どのような情報が、いつ、誰に、どのような手段で送られたかという実際のデータ)
- 組織体の環境要因(EEF) / 組織のプロセス資産(OPA)
ツールと技法(監視・評価するための手段)
集めた情報をもとに、コミュニケーションが適切に行われているかを以下の手段で評価します。
- 専門家の判断
- プロジェクトマネジメント情報システム(PMIS):情報の発信状況、開封状況、ドキュメントの更新履歴などをシステム的に追跡します。
- データ表現(ステークホルダー関与度評価マトリックス):コミュニケーションの変化が、関係者の「関与度(支持・中立・抵抗など)」にどう影響を与えているかを定性的にアセスメントします。
- 人間関係とチームに関するスキル(観察/対話):ステークホルダーの反応や現場の雰囲気を直に観察し、情報不足による不満や誤解が生じていないか、生の声(フィードバック)を収集します。
- 会議:進捗会議や個別のレビューを通じて、コミュニケーションの適正度を直接確認します。
アウトプット(監視した結果生まれるもの)
評価の結果、必要に応じて計画や文書をアップデートします。
- 作業パフォーマンス情報:コミュニケーション活動が情報ニーズをどの程度満たせているか(および改善点)を分析・評価した結果。
- 変更要求:計画したコミュニケーションが機能しておらず、配布方法や頻度、使用ツールの変更・追加が必要と判断された場合の公式な申請。
- プロジェクトマネジメント計画書更新版(コミュニケーション・マネジメント計画書、ステークホルダー・エンゲージメント計画書の改訂)
- プロジェクト文書更新版(コミュニケーション不足から生じた新たな課題を「課題ログ」へ登録するなど)
「伝える」と「理解される」の間に潜む大きな乖離
プロジェクトマネージャーが陥りがちな最大の罠は、ITTOのインプットにもある「プロジェクト伝達事項(メッセージの送信実績)」をもって、「コミュニケーションが完了した」と満足してしまうことです。
PMBOKでも指摘されている通り、「伝えること(Transmit)」と「理解されること(Understand)」の間には、常に大きな乖離が発生するリスクがあります。
プロジェクト環境には、不慣れなテクノロジー、文化的背景の違い、関心の欠如、感情的な状態など、多くの「ノイズ(障壁)」が潜んでいるためです。
注意点:「確認中」は誰が確認しているのか?という落とし穴

「伝える」と「理解される」の乖離について、実際のプロジェクト管理ツール(PMIS)の運用を例に考えてみましょう。
たとえば、タスク管理ツールでチケットを振り分け、あるタスクのステータスが「確認中」になっていたとします。
PMは「ツール上で『確認中』になっているから、状況は全員に伝わっているはずだ」と考えがちですが、実はこの「確認中」が示す意味がチーム内で統一されていないと、重大なコミュニケーションの齟齬に繋がります。
- Aさんの認識: 「作業が終わって、依頼元(発注者やPM)にチェックしてもらっている期間」
- Bさんの認識: 「作業者自身が、次の作業に進むための仕様を確認している期間」
同じ「確認中」というステータスを見ているのに、誰のボール(責任)になっているかの認識が完全にズレています。これでは、お互いに「相手が動いてくれるはず」と待ちの姿勢になり、タスクが完全にストップしてしまいます。
このように、コミュニケーションの方法を策定した後で実際に運用してみると、「ルール通りにツールを使っているのに、コミュニケーションがうまくいかない(理解されていない)」ということは本当によく起こるのです。
実践ステップ:観察と対話で「生の声」を拾い上げる

では、こうした「伝わっているつもり」の状況を防ぎ、コミュニケーションの仕組みを改善するにはどうすればよいのでしょうか。
そこで活躍するのが、ツールと技法にある「人間関係とチームに関するスキル(観察/対話)」と、それに基づく「変更要求」です。
現場の観察と対話(フィードバックの収集)
システム上の「開封済み」や「ステータス更新」といったログだけを見るのではなく、実際のミーティングでの反応、発言のニュアンス、チームの雰囲気を直に観察します。「先日のタスクのステータスの意味、迷いませんでしたか?」と直接対話することで、情報不足やルールの曖昧さによる不満をすくい上げます。
変更要求(ルールのテーラリング)
「情報が正しく伝わっていない(伝えることと理解されることのギャップが埋まらない)」と判断した場合、そのまま放置してはいけません。
伝達メッセージの明確さ、ツールの使用ルール、会議の頻度などをタイムリーに修正する「変更要求」を出します。
先ほどの例であれば、「『確認中(依頼元)』と『確認中(作業者)』でステータスを分けましょう」とルールをアップデート(計画書の更新)するイメージです。
まとめ:ベストな方法はプロジェクトごとに変化する
「これを導入しておけばコミュニケーションは絶対に完璧になる」という、すべてのプロジェクトで使える万能なツールやベストプラクティスは存在しません。プロジェクトのメンバーや環境が変われば、最適な情報の届け方も変わるからです。
「コミュニケーションの監視」とは、一度決めたルールに固執することではなく、運用しながら観察と対話を繰り返し、どのようなコミュニケーションの方法が最適なのかを泥臭く模索し、改善し続けることです。
「言ったはずなのに」「ツールに書いたのに」という言葉がチーム内で出始めたら、それはコミュニケーションの仕組みを見直すサインです。ぜひツールから一度顔を上げ、チームメンバーとの対話を通じて、「伝わる仕組み」へとアップデートしていきましょう。
注
| ↑1 | Project Management Institute, Inc., A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition(日本語版), 第2部 2.5.2.7(261頁、図2-39)、第5章「ツールと技法」(301-303頁、327頁など)より要約。 |
|---|

