PMBOKでは、コミュニケーションマネジメントとリスクマネジメントは、それぞれ独立した知識エリアとして整理されています。
しかし、実際のプロジェクトでは、この2つは密接に関係しています。
私がこれまで経験してきたプロジェクトを振り返ると、炎上したプロジェクトには共通点がありました。
「問題が起きたこと」ではなく、「問題が起きる前に必要なコミュニケーションが行われなかったこと」です。
「もっと早く相談してほしかった」と思ったことはありませんか？
プロジェクトマネージャであれば、一度はこのように感じたことがあるのではないでしょうか。
- 遅れそうなら早く言ってほしかった。
- 分からないなら相談してほしかった。
- 他チームへ影響するなら事前に共有してほしかった。
一方で、メンバーにも言い分があります。
- もう少し自分で調べようと思った。
- PMが忙しそうだった。
- まだ何とかなると思った。
どちらも間違っているわけではありません。
問題は、「相談するタイミング」が個人の判断に委ねられていることです。
「30分悩んだら相談」は本当に仕組みと言えるのか？
よく聞くルールに、
「30分悩んだら相談しましょう。」
というものがあります。
一見すると良いルールに思えますが、本当にこれで相談は確実に行われるでしょうか。
実際には、次のような心理が働きます。
- まだ調べれば解決できるかもしれない。
- もう少し頑張ってみよう。
- 忙しそうだから後で相談しよう。
つまり、最終的には本人の判断になります。
これはルールではありますが、必ず相談が行われる仕組みではありません。
相談ではなく「問題の前兆」をトリガーにする
では、どうすれば相談を仕組み化できるのでしょうか。
私がたどり着いた考え方は、「相談」そのものをトリガーにするのではなく、「問題の前兆」をトリガーにすることです。
例えば、次のような状態です。
- タスクの更新が止まっている。
- レビュー指摘が急増している。
- 承認待ちが長期間続いている。
これらはまだ問題ではありません。
しかし、将来問題になる可能性を示す前兆です。
PMBOKでは、このような前兆を監視し、必要な対応を行う活動はリスクマネジメントの「リスクの監視」に位置付けられています。
つまり、
- 前兆を検知することはリスクマネジメント
- 検知した結果として相談や調整を行うことはコミュニケーションマネジメント
という関係になります。
2つの知識エリアは一本の流れでつながっている
実務では、コミュニケーションとリスク管理は別々には動きません。
実際には、次のような流れで進んでいます。
- プロジェクトの状態を監視する。
- 問題の前兆を検知する。
- 関係者へ相談・共有する。
- 必要な意思決定を行う。
- 問題を未然に防ぐ。
つまり、
リスクマネジメントが「気付く仕組み」を作り、コミュニケーションマネジメントが「動く仕組み」を作る。
この2つが組み合わなければ、問題を未然に防ぐことはできません。
PMの仕事は「問題を管理すること」ではない
私は、ここでPMの役割を少し捉え直す必要があると考えています。
PMの仕事は、
「問題が起きたら対応すること」
だけではありません。
本当に重要なのは、問題が起きる前に前兆を検知し、適切なコミュニケーションが自然と始まる仕組みを設計することです。
例えば、次のようなルールを設計します。
- レビュー指摘件数が一定数を超えたら設計レビューを実施する。
- 承認待ちが一定期間を超えたら関係者で調整する。
- タスクが長期間更新されなければ状況確認を行う。
このように、「前兆」と「コミュニケーション」を結び付けて設計することで、PMが毎回「何か困っていない？」と聞かなくても、プロジェクトは自然と問題を未然に防ぐ方向へ動き始めます。
まとめ
コミュニケーションマネジメントとリスクマネジメントは、PMBOKでは別々の知識エリアです。
しかし、実務では切り離して考えることはできません。
- リスクマネジメントは、問題の前兆を検知するための仕組み
- コミュニケーションマネジメントは、前兆に対して必要な対話や意思決定を行うための仕組み
私は、この2つを一本の流れとして設計することが、プロジェクトマネージャの重要な役割の一つだと考えています。
次回は、この考え方をさらに発展させ、「相談してください」と言わなくても自然と助けを求められる仕組みについて考えていきます。
これはCTAサンプルです。
内容を編集するか削除してください。
