プロジェクトの現場では、このように問題を抱え込んでしまうケースがあります。

しかし、問題への対応が遅れるほど、プロジェクトへの影響は大きくなる可能性があります。

そこで重要になるのがエスカレーション（Escalation）です。

この記事では、エスカレーションの意味や目的、適切なタイミング、プロジェクトマネージャが実践すべきポイントについて解説します。

一言でいうと

エスカレーションとは、「自分や現在のチームだけでは解決できない問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動」です。

エスカレーションとは

エスカレーションとは、問題やリスク、判断が必要な事項を、上位者や関係する意思決定者へ引き上げることです。

プロジェクトでは、プロジェクトマネージャだけでは判断できない問題が発生することがあります。

例えば、

• 予算追加が必要になる
• 納期変更の判断が必要になる
• 組織間の調整が必要になる
• 重要なリスクが顕在化する

このような場合、適切なタイミングでエスカレーションを行うことで、迅速な意思決定につなげることができます。

エスカレーションが重要な理由

プロジェクトでは、問題そのものよりも「発見後の対応の遅れ」が大きな影響を与えることがあります。

例えば、以下のようなケースです。

• 小さな遅延を報告せず、後から重大な遅延になる
• 品質問題を抱え込み、リリース直前に発覚する
• 判断待ちの事項が放置され、作業が停止する

早い段階でエスカレーションすることで、選択できる対応策が増えます。

つまり、エスカレーションは「問題が大きくなってから助けを求める行為」ではなく、「問題を大きくしないための予防的な行動」です。

エスカレーションするべきタイミング

エスカレーションの判断で重要なのは、「解決策が決まってから報告する」のではなく、「問題だと認識した段階で共有する」ことです。

例えば、以下のような状況ではエスカレーションを検討します。

• プロジェクト目標へ影響する可能性がある
• 自分の権限では判断できない
• 複数チームに影響する
• 期限までに解決できない可能性がある
• 追加予算や人員が必要になる

エスカレーションで重要な報告内容

エスカレーションでは、単に「問題があります」と伝えるだけでは十分ではありません。

最低限、以下の内容を整理して共有します。

原因分析や対策案が完成していなくても、まず状況を共有することが重要です。

エスカレーションと報告の違い

エスカレーションは単なる報告ではなく、問題解決のために適切な人へ判断をつなぐ活動です。

実務ではこんな場面で活用される

例えば、システム開発プロジェクトで、重要な機能の開発が遅れる可能性が判明したとします。

プロジェクトマネージャが一人で原因分析や対策検討を続けると、対応が遅れる可能性があります。

そこで、以下のようにエスカレーションします。

• 現在判明している事実を共有する
• 納期影響の可能性を伝える
• 原因分析中であることを説明する
• 必要な支援や判断を依頼する

この段階では、完璧な解決策を提示する必要はありません。

重要なのは、問題を早期に共有し、組織として対応できる状態を作ることです。

よくある勘違い

エスカレーションは失敗報告ではない

エスカレーションを「問題を起こしたことを認める行為」と考えてしまうことがあります。

しかし、実際にはプロジェクトを成功させるためのマネジメント活動です。

原因分析が終わるまで待つ必要はない

原因分析や対策検討には時間がかかります。

その間に問題の影響が広がる可能性があります。

まず事実を共有し、その後詳細分析を進めることも重要な判断です。

プロジェクトマネージャ試験ではここが重要

IPAのプロジェクトマネージャ試験では、問題発生時の対応や関係者調整が重要なテーマになります。

論文では、以下のような観点が評価されます。

• 問題をどのタイミングで認識したか
• 誰へどのように共有したか
• 必要な判断や支援をどのように得たか
• その結果、プロジェクトをどう改善したか

優れたPMは、問題を隠すのではなく、適切なタイミングで組織の力を活用します。

PM道場のワンポイント

エスカレーションで大切なのは、「解決してから報告する」ことではなく、「問題だと思った時点で共有する」ことです。

プロジェクトマネージャは、すべての問題を一人で解決する役割ではありません。

必要な人へ情報を届け、適切な判断を引き出すことも重要な役割です。

特に、コミュニケーションが苦手なPMほど、「原因を整理してから伝えなければならない」と考えがちです。

しかし、早期共有によって、より多くの選択肢を持って対応できます。

優れたプロジェクトマネージャは、エスカレーションによって問題解決のスピードを高めています。

関連用語

• リスク（Risk）
• 課題（Issue）
• 問題管理
• 意思決定
• ステークホルダー
• コミュニケーションマネジメント
• 報告
• プロジェクトスポンサー

まとめ

エスカレーションとは、自分やチームだけでは解決できない問題や判断事項を、適切な相手へ共有し、支援や判断を得る活動です。

重要なのは、問題が大きくなってから行うのではなく、影響が広がる前に実施することです。

プロジェクトマネージャに求められるのは、すべての問題を一人で解決する力ではありません。

組織の力を活用し、プロジェクトを成功へ導くための判断を行う力です。

関連記事

• リスク（Risk）とは？
• 課題（Issue）とは？
• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• プロジェクトスポンサーとは？

よくある質問（FAQ）

Q. エスカレーションとは何ですか？

A. 解決が難しい問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動です。

Q. エスカレーションはいつ行うべきですか？

A. 問題の影響が広がる可能性があると判断した時点で、早めに実施することが重要です。

Q. 原因分析や対策案がなくてもエスカレーションしてよいですか？

A. はい。まず事実や影響を共有し、必要な支援を得ることが重要です。

The post エスカレーションとは？プロジェクトを成功に導くための問題共有の考え方を解説 first appeared on PM道場.

しかし、プロジェクトではもう一つ設計しなければならないコミュニケーションがあります。

それがエスカレーションです。

私は人見知りだったこともあり、問題が起きてもすぐに相談することができませんでした。

• 「原因を整理してから報告しよう。」
• 「対策を考えてから相談しよう。」
• 「相手が納得できるように説明できる状態にしてから伝えよう。」

そう思っているうちに時間だけが過ぎ、気付けば問題が大きくなってしまうことが何度もありました。

当時の私は、「もっとコミュニケーション能力があればすぐに相談できたのに」と考えていました。

しかし今振り返ると、問題は性格ではありませんでした。

エスカレーションの仕組みを設計できていなかったのです。

人見知りほど「準備してから相談しよう」としてしまう

プロジェクトで問題が発生したとき、多くの人はすぐに相談できます。

一方、人見知りの人は違います。

• 「原因を調べてから。」
• 「対策を考えてから。」
• 「質問されたら答えられるようにしてから。」

そんなふうに、相談する前の準備に時間をかけてしまいます。

私もそうでした。

原因分析を行い、対策案を考え、相手が納得できる説明を用意してから報告しようとしていました。

しかし、その間にも時間は過ぎていきます。

プロジェクトでは、問題そのものよりも、問題への対応が遅れることの方が大きなリスクになる場合があります。

準備をしているつもりが、結果として問題を大きくしてしまっていたのです。

実は、原因より「速報」の方が価値がある

PMとして経験を積む中で、私の考え方は大きく変わりました。

今は、問題だと思った時点でエスカレーションするようにしています。

そのときに伝えることは、とてもシンプルです。

「問題だと思ったので、まずは報告します。まだ原因分析や対策案はできていません。」

これだけです。

以前の私なら、「そんな状態で報告してはいけない」と考えていたでしょう。

しかし実際には、この伝え方の方がずっと良い結果につながりました。

なぜなら、自分だけが問題だと思っていただけというケースが意外と多かったからです。

私にとっては重大な問題でも、上司や顧客からすると、

• 「それなら問題ありません。」
• 「そのまま進めて大丈夫です。」

と言われることも少なくありませんでした。

もし一人で抱え込んでいたら、必要のない不安を抱えたまま時間を使っていたことになります。

エスカレーションは、問題を報告するだけではありません。

自分一人の不安を、チームで確認するためのコミュニケーションでもあるのです。

エスカレーションは「原因」を共有するものではなく、「不安」を共有するもの

私は、エスカレーションの考え方を次のように変えました。

以前

「原因が分かったら報告する。」

現在

「問題だと思ったら報告する。」

原因分析や対策案は、その後にチームで考えれば十分です。

プロジェクトは、一人で解決するものではありません。

チームで解決するものです。

だからこそ、エスカレーションで最初に共有すべきなのは、

「私はここに不安を感じています。」

という事実なのだと思います。

エスカレーションにも「設計」が必要

PMBOK®^®︎では、コミュニケーションは計画し、管理するものとされています。

私は、エスカレーションも同じだと考えています。

「問題があれば相談してください。」

これだけでは、人によって判断が変わってしまいます。

だから私は、プロジェクトの規模に応じてエスカレーションの基準を決めるようにしていました。

小規模なプロジェクトの場合

ルールはとてもシンプルです。

「問題だと思った時点で相談してください。」

必要なのは次の2つだけです。

• 何が起きたのか
• 何を問題だと感じているのか

原因や対策は、一緒に考えます。

大規模なプロジェクトの場合

関係者が多くなるため、PMだけで全てを管理することは難しくなります。

そのため、課題管理表に必要な情報を記録し、その登録を連絡してもらう運用にしていました。

こうすることで、情報が漏れず、対応状況もチーム全体で共有できます。

もちろん、これが唯一の正解ではありません。

プロジェクトの規模や特性に応じて運用を変えることが大切です。

私はこれも、PMBOK®^®︎でいうテーラリングの考え方だと捉えています。

PMの最初の反応が、チームの文化を作る

エスカレーションしやすいチームには、一つ共通点があります。

それは、PMの最初の反応です。

私はまず、

「報告してくれてありがとう。」

と伝えるようにしています。

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

• 嫌そうな表情をする
• ため息をつく
• 責めるような質問をする

こうした反応をしてしまうと、次から相手は相談をためらうようになります。

私は人見知りだったからこそ、この影響を強く感じました。

相手の表情から「嫌だな」という感情を読み取ってしまうと、

「次はもう少し整理してから相談しよう。」

と思ってしまうのです。

その結果、エスカレーションは遅れます。

だからこそ、PMは問題の内容よりも先に、

相談しやすい空気を作れているかを意識する必要があります。

PMBOK®^®︎でも重要なのは「早く見える化すること」

PMBOK®^®︎では、リスクや課題は継続的に監視し、必要に応じて関係者へ共有することが重要だとされています。

私は、この考え方はエスカレーションにも当てはまると思っています。

大切なのは、完璧な情報を持ってから報告することではありません。

問題を早く見える化し、チームで対応を考えられる状態を作ることです。

エスカレーションとは、責任を手放すことではありません。

問題をチーム全体で管理できる状態へ変えることなのです。

おわりに

新人の頃の私は、

「原因が分かるまで相談してはいけない。」

そう思い込んでいました。

しかし今なら、当時の自分にこう伝えます。

「まずは問題だと思ったことだけ伝えよう。」

原因は、そのあとみんなで考えればいい。

プロジェクトマネジャは、一人で戦う仕事ではありません。

チームでプロジェクトを成功へ導く仕事です。

だからこそ、エスカレーションは問題を報告するための仕組みではなく、

一人で抱え込んでいた不安を、チーム全体の課題へ変えるための仕組みなのだと思います。

あなたへの問いかけ

あなたのプロジェクトでは、エスカレーションしやすい仕組みが設計されていますか。

そして、もし誰かが勇気を出して相談してきたとき、あなたは最初にどんな言葉を掛けるでしょうか。

その最初の一言が、チームのコミュニケーション文化を作るのかもしれません。

The post 人見知りのPMが問題を抱え込まないためのエスカレーション設計 first appeared on PM道場.

「何かあれば早めに共有してください。」

プロジェクトではよく聞く言葉です。

しかし実際には、「何をもって困ったと言えるのか」は人によって判断が異なります。

あるメンバーは30分で相談します。

一方で、あるメンバーは3日間悩み続けます。

これでは、相談するタイミングは個人の判断に依存してしまいます。

そこで重要になるのが、「問題が起きる前兆」を設計することです。

前兆はプロジェクトによって違う

前回の記事では、助けを求めるシグナルを標準化する重要性について紹介しました。

しかし、「何をシグナルにするのか」はプロジェクトによって大きく異なります。

つまり、すべてのプロジェクトに共通する前兆は存在しません。

PMは、そのプロジェクトで何が問題の前兆になるのかを考え、設計する必要があります。

ウォーターフォール型のシステム開発で見られる前兆

例えば、ウォーターフォール型のシステム開発では、次のような前兆があります。

• レビュー指摘件数が急に増えた
• 同じ仕様への質問が繰り返される
• WBSは完了しているのにレビューが終わらない
• タスクの更新が止まっている

これらは、まだ問題ではありません。

しかし、後になって品質問題や納期遅延につながる可能性があります。

EPCプロジェクトで見られる前兆

私が多く経験してきたEPCプロジェクトでは、少し違う前兆があります。

• 他部署からの回答が返ってこない
• 承認待ちが長期間続く
• 設計変更依頼が増えてきた
• 資材納期が変更になった

どれも、その時点では問題になっていません。

しかし放置すると、工程全体へ影響します。

だからこそ、この段階で関係者が集まり、相談や調整を始める必要があります。

アジャイル開発でも前兆は存在する

アジャイル開発では毎日コミュニケーションがあります。

それでも、問題の前兆は存在します。

• 同じタスクが何日も「進行中」のまま
• デイリースクラムで毎日同じ内容を話している
• レビュー待ちが増えている
• ベロシティが急に落ちた

このような変化は、チームが何かにつまずいているサインかもしれません。

前兆には共通する4つの型がある

プロジェクトによって前兆は異なります。

しかし整理してみると、大きく4つの型に分類できると私は考えています。

① 時間

一定期間、状態が変わらないことです。

例

• 承認待ちが3日以上続く
• タスク更新が止まっている
• 回答待ちが長期化している

② 数量

件数や量が急に変化することです。

例

• レビュー指摘件数
• 不具合件数
• 設計変更件数

③ 状態

本来あるべき状態から外れていることです。

例

• レビュー未実施
• Blocked状態
• テスト未着手

④ 変化

普段とは違う変化が起きることです。

例

• 質問が急に増える
• 会議への参加者が減る
• 進捗が急に悪化する

PMが本当に設計するべきもの

ここまで考えると、PMの役割は問題が起きた後に対応することではありません。

また、メンバーへ「早めに相談してください」とお願いすることでもありません。

本当に設計するべきなのは、

「この前兆が現れたら、相談・レビュー・調整を始める。」

というルールです。

つまり、

前兆 → コミュニケーション

を設計することです。

これが、人に依存しないコミュニケーションマネジメントにつながります。

まとめ

相談のタイミングを人に任せると、どうしても遅れが発生します。

だからこそPMは、「何が問題の前兆なのか」を考え、その前兆が現れたら自然とコミュニケーションが始まる仕組みを設計する必要があります。

プロジェクトごとに前兆は異なります。

だからこそ、プロジェクト開始時には、

「このプロジェクトでは、何を前兆として監視するのか。」

をチームで話し合うことが、コミュニケーションマネジメントとリスクマネジメントをつなぐ第一歩になるのではないでしょうか。

おわりに

皆さんのプロジェクトでは、「問題」を管理できていますか。

それとも、「問題の前兆」を管理できていますか。

プロジェクトの成功を左右するのは、問題が起きた後の対応ではありません。

その前にどれだけ前兆に気付き、適切なコミュニケーションにつなげられるかが重要だと私は考えています。

The post プロジェクトによって「相談のタイミング」は違う。だからPMは「前兆」を設計する。 first appeared on PM道場.

そのため、

• 誰に情報を伝えるのか
• 何を伝えるのか
• いつ伝えるのか
• どのような方法で伝えるのか
• 問題が発生したとき、誰に報告するのか

といったことを事前に決めておくことが重要です。

これらのコミュニケーションの方針や方法を整理したものが、コミュニケーションマネジメント計画書です。

コミュニケーションマネジメント計画書は、単なる「連絡方法の一覧」ではありません。

プロジェクトに必要な情報を、必要な人へ、必要なタイミングで届けるための仕組みを設計するための文書です。

一言でいうと

コミュニケーションマネジメント計画書とは、プロジェクトにおける情報の「誰に・何を・いつ・どのように伝えるか」を定めた計画書です。

例えば、

• 週次の進捗報告は誰に行うのか
• 課題が発生した場合は誰に報告するのか
• チーム内の情報共有には何を使うのか
• 会議の議事録をどこに保管するのか
• 緊急時にはどのように連絡するのか

などをあらかじめ決めておきます。

これによって、「誰に報告すればよいのか分からない」「必要な情報が共有されていない」といったコミュニケーション上の問題を防ぎやすくなります。

コミュニケーションマネジメント計画書とは

プロジェクトでは、プロジェクトマネージャ、チームメンバー、顧客、スポンサー、経営層、外部ベンダーなど、多くのステークホルダーが関わります。

それぞれが必要としている情報は異なります。

例えば、プロジェクトマネージャは詳細な課題やリスクを把握する必要がありますが、経営層はプロジェクト全体の進捗や重要な問題を把握できればよい場合があります。

そのため、全員に同じ情報を同じ方法で伝えるのではなく、相手に応じてコミュニケーションを設計する必要があります。

コミュニケーションマネジメント計画書は、そのための基本的なルールを整理したものです。

なぜコミュニケーションマネジメント計画書が必要なのか

情報共有の漏れを防ぐ

プロジェクトで発生する問題の中には、「問題そのもの」ではなく、必要な情報が必要な人に伝わっていなかったことが原因となっているものがあります。

例えば、進捗が遅れているにもかかわらず、プロジェクトマネージャへの報告が遅れたとします。

その結果、対応が後手に回り、納期に間に合わなくなる可能性があります。

あらかじめ「どのような状況になったら誰に報告するか」を決めておけば、このような情報共有漏れを防ぎやすくなります。

コミュニケーション方法を標準化する

人によって情報共有の方法が違うと、プロジェクト内で混乱が生じます。

例えば、あるメンバーはメールで報告し、別のメンバーはチャットで報告し、別のメンバーは口頭で報告するといった状態です。

重要な情報がどこにあるのか分からなくなる可能性があります。

そこで、プロジェクトとして基本的な共有方法を決めておくことが重要です。

緊急時の連絡方法を明確にする

通常の進捗報告だけではなく、重大な問題や障害が発生した場合の連絡方法も重要です。

例えば、

• 通常の課題：週次会議で報告
• 重要な課題：当日中にプロジェクトマネージャへ報告
• 重大な障害：直ちに責任者へエスカレーション

というように、重要度に応じた連絡方法を決めておくことができます。

コミュニケーションマネジメント計画書に記載する内容

プロジェクトによって必要な内容は異なりますが、一般的には次のような項目を整理します。

すべてを細かく記載する必要があるわけではありません。

プロジェクトの規模や複雑さに応じて、必要なレベルまで詳細化することが重要です。

コミュニケーションマネジメント計画書の作り方

1．ステークホルダーを整理する

まず、プロジェクトに関係する人を整理します。

例えば、

• プロジェクトスポンサー
• プロジェクトマネージャ
• プロジェクトチーム
• 顧客
• ユーザー
• PMO
• 外部ベンダー

などです。

重要なのは、単純に名前を並べるだけではなく、それぞれがどのような情報を必要としているのかを考えることです。

2．必要な情報を整理する

次に、それぞれのステークホルダーが必要とする情報を整理します。

例えば、プロジェクトスポンサーには、

• 全体進捗
• 重要なリスク
• 重大な課題
• 予算状況

などが必要になるかもしれません。

一方、プロジェクトチームには、

• 作業状況
• 課題
• 変更事項
• 今後の予定

など、より具体的な情報が必要になります。

3．共有するタイミングを決める

情報を「いつ」共有するのかを決めます。

例えば、

• 毎日の進捗：デイリースクラム
• 週次進捗：週次進捗会議
• 月次報告：ステアリングコミッティ
• 重大な問題：発生時に即時報告

などです。

すべての情報を定期的に共有する必要はありません。

情報の性質に応じて、適切なタイミングを設定することが重要です。

4．共有方法を決める

次に、どのような方法で情報を共有するのかを決めます。

例えば、

• 定例会議
• メール
• チャット
• 進捗報告書
• ダッシュボード
• プロジェクト管理ツール

などがあります。

ここで重要なのは、共有方法を増やしすぎないことです。

情報共有の方法が多すぎると、「どこを見れば最新情報が分かるのか」が分からなくなってしまいます。

プロジェクトに必要な共有方法を整理し、できるだけシンプルな仕組みにすることが重要です。

5．エスカレーションルールを決める

通常の情報共有だけではなく、問題が発生した場合のエスカレーションルールも決めます。

例えば、

このように、どのような問題を、どのレベルで、誰に報告するのかをあらかじめ決めておくことで、問題を抱え込むことを防ぎやすくなります。

6．計画を関係者と合意する

コミュニケーションマネジメント計画書は、プロジェクトマネージャが一人で決めるものではありません。

必要な関係者と確認し、実際に運用できる内容になっているかを確認します。

特に、報告を受ける側が「その情報は必要ない」と考えていたり、報告する側の負担が大きすぎたりすると、計画どおりに運用できません。

実際に利用する人が無理なく運用できることが重要です。

コミュニケーションマネジメント計画書の例

例えば、システム開発プロジェクトであれば、次のような計画を作ることができます。

このように整理しておくことで、情報共有のルールをプロジェクトメンバー全員で共有できます。

プロジェクトの規模によって計画を変える

コミュニケーションマネジメント計画書は、プロジェクトの規模によって詳細度を変える必要があります。

例えば、5人程度の小規模なプロジェクトであれば、細かいコミュニケーション計画書を作成する必要がない場合もあります。

一方、数百人が関係する大規模プロジェクトでは、

• 組織ごとの情報共有方法
• 会議体
• 報告ルート
• 承認ルート
• エスカレーションルール
• 情報の保管場所

などを明確にする必要があります。

つまり、「計画書を作ること」そのものが目的ではなく、プロジェクトに必要なコミュニケーションを適切に設計することが目的です。

コミュニケーションマネジメント計画書を作るときの注意点

情報共有の方法を増やしすぎない

「情報共有が重要だから」といって、メール、チャット、会議、掲示板、複数の管理ツールなどを大量に使うと、かえって情報が分散します。

重要なのは、共有方法を必要最小限に整理することです。

全員にすべての情報を共有しない

すべての情報を全員に共有すると、情報量が多くなり、本当に重要な情報が埋もれてしまいます。

「誰が何を知る必要があるのか」を考えて、情報を適切な相手に届けることが重要です。

計画書を作って終わりにしない

プロジェクトが進むと、ステークホルダーやチーム構成、プロジェクトの状況が変わることがあります。

そのため、コミュニケーションマネジメント計画書も必要に応じて見直します。

報告しやすい仕組みにする

問題が発生したときに、「原因を完全に分析してから報告しよう」と考えてしまうと、報告が遅れる可能性があります。

重要なのは、問題だと思った時点で早めに報告できる仕組みを作ることです。

例えば、

「問題を認識した段階で一次報告する。原因分析や対策はその後に行う」

というルールを決めておくこともできます。

このような仕組みがあると、プロジェクトマネージャやメンバーが問題を抱え込むことを防ぎやすくなります。

コミュニケーションマネジメント計画書とステークホルダー

コミュニケーションマネジメント計画書を作成する際には、ステークホルダーごとに必要な情報が異なることを意識する必要があります。

例えば、

このように、ステークホルダーの関心や役割を踏まえてコミュニケーションを設計します。

コミュニケーションマネジメント計画書とエスカレーション

プロジェクトのコミュニケーションで特に重要なのがエスカレーションです。

エスカレーションとは、プロジェクトチームだけでは解決できない問題や、上位の判断が必要な事項を、適切な責任者へ報告・相談することです。

コミュニケーションマネジメント計画書にエスカレーションルールを含めることで、

• どのような状態になったら報告するのか
• 誰に報告するのか
• どの方法で報告するのか
• どの程度の緊急性で報告するのか

を明確にできます。

これにより、「誰にも相談せず、問題を抱えたまま時間が経過する」という状況を防ぎやすくなります。

プロジェクトマネージャ試験ではここが重要

コミュニケーションマネジメント計画書については、単に「情報共有の計画書」と覚えるだけではなく、誰に・何を・いつ・どのように伝えるのかを設計するものと理解しておきましょう。

特に重要なのは、

• ステークホルダーごとに必要な情報を整理する
• 情報共有の方法を決める
• 情報共有のタイミングを決める
• 情報の発信者を決める
• 情報の保管場所を決める
• エスカレーションルールを決める
• プロジェクトの規模に応じて詳細度を調整する

という点です。

また、コミュニケーションマネジメント計画書は、作成すること自体が目的ではありません。

プロジェクトに必要な情報が、必要な人に、必要なタイミングで届く状態を作ることが目的です。

PM道場のワンポイント

コミュニケーションマネジメント計画書は、「情報共有のルール」ではなく「情報共有の仕組み」を設計するためのものです。

プロジェクトで問題が起きたとき、原因を分析すると「情報共有が遅れていた」「必要な人に伝わっていなかった」というケースがあります。

しかし、これを単純に「もっとコミュニケーションを取ろう」としてしまうと、会議やメールが増えるだけになってしまいます。

重要なのは、

「誰が、どの情報を、いつまでに、誰へ伝えるのか」

を明確にすることです。

そして、もう一つ重要なのが、問題を早く報告できる仕組みです。

私は、問題を発見したときに、最初から原因分析や対策まで完成させて報告する必要はないと考えています。

「問題だと思いました。まず報告します。原因や対策はこれから分析します」

という一次報告ができる仕組みを作っておけば、問題を抱え込むことを防げます。

そのためには、コミュニケーションマネジメント計画書の中で、エスカレーションの基準とルートをあらかじめ決めておくことが有効です。

コミュニケーション能力が高い人に頼るのではなく、誰でも適切に情報共有できる仕組みを作る。

これが、プロジェクトマネージャがコミュニケーションマネジメント計画書を作る大きな意味の一つです。

関連用語

• コミュニケーションマネジメント
• ステークホルダーエンゲージメント
• ステークホルダー
• エスカレーション
• キックオフミーティング
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• リスク
• 課題
• デイリースクラム

まとめ

コミュニケーションマネジメント計画書とは、プロジェクトにおいて「誰に・何を・いつ・どのように伝えるのか」を定める計画書です。

その目的は、単純に情報共有のルールを作ることではありません。

必要な情報を、必要な人へ、必要なタイミングで届ける仕組みを作ることです。

作成するときは、

• ステークホルダーを整理する
• 必要な情報を整理する
• 共有するタイミングを決める
• 共有方法を決める
• 情報の保管場所を決める
• エスカレーションルールを決める

という流れで考えると分かりやすくなります。

また、プロジェクトの規模によって必要な詳細度は異なります。

小規模なプロジェクトであれば簡単なルールで十分な場合もありますし、大規模なプロジェクトでは組織ごとの報告ルートや会議体、エスカレーションルールなどを詳細に定める必要があります。

そして、コミュニケーションマネジメントで最も重要なのは、コミュニケーション能力の高い人に頼ることではなく、誰でも適切に情報を共有できる仕組みを作ることです。

特に、問題が発生したときに早期にエスカレーションできる仕組みを作っておくことは、プロジェクトのリスクを小さくするうえで非常に重要です。

「誰に、何を、いつ、どのように伝えるか」を事前に設計する。

これがコミュニケーションマネジメント計画書の基本です。

関連記事

• コミュニケーションマネジメントとは？
• ステークホルダーエンゲージメントとは？
• エスカレーションとは？
• キックオフミーティングとは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？
• 意思決定とは？
• リスクとは？
• 課題とは？
• デイリースクラムとは？

よくある質問（FAQ）

Q. コミュニケーションマネジメント計画書とは何ですか？

A. プロジェクトにおいて、誰に、何を、いつ、どのような方法で伝えるのかを整理した計画書です。必要な情報を必要な人へ届けるためのコミュニケーションの仕組みを設計します。

Q. コミュニケーションマネジメント計画書には何を書きますか？

A. 対象者、情報、目的、タイミング、頻度、共有方法、発信者、情報の保管場所、エスカレーションルールなどを記載します。ただし、プロジェクトの規模や特性に応じて必要な項目や詳細度を調整します。

Q. コミュニケーションマネジメント計画書は必ず作成する必要がありますか？

A. 重要なのは計画書という形式そのものではなく、プロジェクトに必要なコミュニケーションを適切に設計することです。小規模なプロジェクトでは簡単なルールで十分な場合もあります。

Q. コミュニケーションマネジメント計画書とコミュニケーションマネジメントの違いは何ですか？

A. コミュニケーションマネジメントは、プロジェクトにおける情報の生成、収集、配布、保管などを適切に管理する活動です。コミュニケーションマネジメント計画書は、その活動をどのように行うのかを計画・整理したものです。

Q. コミュニケーションマネジメント計画書にエスカレーションを含めるべきですか？

A. はい。問題が発生した場合に、誰へ、どのような基準で、どの方法で報告するのかをあらかじめ決めておくことで、問題の抱え込みや報告遅延を防ぎやすくなります。

Q. コミュニケーション方法は多いほど良いですか？

A. 必ずしもそうではありません。方法が増えすぎると情報が分散し、どこを確認すればよいのか分からなくなる可能性があります。プロジェクトに必要な方法を整理し、できるだけシンプルな仕組みにすることが重要です。

The post コミュニケーションマネジメント計画書とは？目的・記載内容・作り方をわかりやすく解説 first appeared on PM道場.