前回の記事では、キックオフミーティングは「最初のコミュニケーションを設計する場」であるという考え方について書きました。
しかし、プロジェクトではもう一つ設計しなければならないコミュニケーションがあります。
それがエスカレーションです。
私は人見知りだったこともあり、問題が起きてもすぐに相談することができませんでした。
- 「原因を整理してから報告しよう。」
- 「対策を考えてから相談しよう。」
- 「相手が納得できるように説明できる状態にしてから伝えよう。」
そう思っているうちに時間だけが過ぎ、気付けば問題が大きくなってしまうことが何度もありました。
当時の私は、「もっとコミュニケーション能力があればすぐに相談できたのに」と考えていました。
しかし今振り返ると、問題は性格ではありませんでした。
エスカレーションの仕組みを設計できていなかったのです。
人見知りほど「準備してから相談しよう」としてしまう
プロジェクトで問題が発生したとき、多くの人はすぐに相談できます。
一方、人見知りの人は違います。
- 「原因を調べてから。」
- 「対策を考えてから。」
- 「質問されたら答えられるようにしてから。」
そんなふうに、相談する前の準備に時間をかけてしまいます。
私もそうでした。
原因分析を行い、対策案を考え、相手が納得できる説明を用意してから報告しようとしていました。
しかし、その間にも時間は過ぎていきます。
プロジェクトでは、問題そのものよりも、問題への対応が遅れることの方が大きなリスクになる場合があります。
準備をしているつもりが、結果として問題を大きくしてしまっていたのです。
実は、原因より「速報」の方が価値がある
PMとして経験を積む中で、私の考え方は大きく変わりました。
今は、問題だと思った時点でエスカレーションするようにしています。
そのときに伝えることは、とてもシンプルです。
「問題だと思ったので、まずは報告します。まだ原因分析や対策案はできていません。」
これだけです。
以前の私なら、「そんな状態で報告してはいけない」と考えていたでしょう。
しかし実際には、この伝え方の方がずっと良い結果につながりました。
なぜなら、自分だけが問題だと思っていただけというケースが意外と多かったからです。
私にとっては重大な問題でも、上司や顧客からすると、
- 「それなら問題ありません。」
- 「そのまま進めて大丈夫です。」
と言われることも少なくありませんでした。
もし一人で抱え込んでいたら、必要のない不安を抱えたまま時間を使っていたことになります。
エスカレーションは、問題を報告するだけではありません。
自分一人の不安を、チームで確認するためのコミュニケーションでもあるのです。
エスカレーションは「原因」を共有するものではなく、「不安」を共有するもの
私は、エスカレーションの考え方を次のように変えました。
以前
「原因が分かったら報告する。」
現在
「問題だと思ったら報告する。」
原因分析や対策案は、その後にチームで考えれば十分です。
プロジェクトは、一人で解決するものではありません。
チームで解決するものです。
だからこそ、エスカレーションで最初に共有すべきなのは、
「私はここに不安を感じています。」
という事実なのだと思います。
エスカレーションにも「設計」が必要
PMBOK®®︎では、コミュニケーションは計画し、管理するものとされています。
私は、エスカレーションも同じだと考えています。
「問題があれば相談してください。」
これだけでは、人によって判断が変わってしまいます。
だから私は、プロジェクトの規模に応じてエスカレーションの基準を決めるようにしていました。
小規模なプロジェクトの場合
ルールはとてもシンプルです。
「問題だと思った時点で相談してください。」
必要なのは次の2つだけです。
- 何が起きたのか
- 何を問題だと感じているのか
原因や対策は、一緒に考えます。
大規模なプロジェクトの場合
関係者が多くなるため、PMだけで全てを管理することは難しくなります。
そのため、課題管理表に必要な情報を記録し、その登録を連絡してもらう運用にしていました。
こうすることで、情報が漏れず、対応状況もチーム全体で共有できます。
もちろん、これが唯一の正解ではありません。
プロジェクトの規模や特性に応じて運用を変えることが大切です。
私はこれも、PMBOK®®︎でいうテーラリングの考え方だと捉えています。
PMの最初の反応が、チームの文化を作る
エスカレーションしやすいチームには、一つ共通点があります。
それは、PMの最初の反応です。
私はまず、
「報告してくれてありがとう。」
と伝えるようにしています。
それだけで、相手は
「報告して良かった。」
と思えます。
逆に、
- 嫌そうな表情をする
- ため息をつく
- 責めるような質問をする
こうした反応をしてしまうと、次から相手は相談をためらうようになります。
私は人見知りだったからこそ、この影響を強く感じました。
相手の表情から「嫌だな」という感情を読み取ってしまうと、
「次はもう少し整理してから相談しよう。」
と思ってしまうのです。
その結果、エスカレーションは遅れます。
だからこそ、PMは問題の内容よりも先に、
相談しやすい空気を作れているかを意識する必要があります。
PMBOK®®︎でも重要なのは「早く見える化すること」
PMBOK®®︎では、リスクや課題は継続的に監視し、必要に応じて関係者へ共有することが重要だとされています。
私は、この考え方はエスカレーションにも当てはまると思っています。
大切なのは、完璧な情報を持ってから報告することではありません。
問題を早く見える化し、チームで対応を考えられる状態を作ることです。
エスカレーションとは、責任を手放すことではありません。
問題をチーム全体で管理できる状態へ変えることなのです。
おわりに
新人の頃の私は、
「原因が分かるまで相談してはいけない。」
そう思い込んでいました。
しかし今なら、当時の自分にこう伝えます。
「まずは問題だと思ったことだけ伝えよう。」
原因は、そのあとみんなで考えればいい。
プロジェクトマネジャは、一人で戦う仕事ではありません。
チームでプロジェクトを成功へ導く仕事です。
だからこそ、エスカレーションは問題を報告するための仕組みではなく、
一人で抱え込んでいた不安を、チーム全体の課題へ変えるための仕組みなのだと思います。
あなたへの問いかけ
あなたのプロジェクトでは、エスカレーションしやすい仕組みが設計されていますか。
そして、もし誰かが勇気を出して相談してきたとき、あなたは最初にどんな言葉を掛けるでしょうか。
その最初の一言が、チームのコミュニケーション文化を作るのかもしれません。
私は令和5年度 IPAプロジェクトマネージャ試験に合格しました。
実際に合格した経験をもとに、勉強方法やおすすめ参考書、最難関といわれる午後Ⅱ論文の対策方法を詳しく解説しています。
「これから勉強を始めたい」「効率よく合格したい」という方は、ぜひこちらの記事もご覧ください。
