「何か困ったら相談してください。」
プロジェクトのキックオフで、この言葉を伝えたことがあるPMは多いのではないでしょうか。
私も以前は、この一言で十分だと思っていました。
しかし、実際のプロジェクトでは、次のような場面が何度もありました。
- 「実は昨日から困っていました。」
- 「もう少し自分で調べようと思っていました。」
- 「忙しそうだったので声を掛けられませんでした。」
つまり、「相談してください」と伝えるだけでは、相談は仕組み化できていなかったのです。
「相談する」は人に依存している
例えば、
「30分悩んだら相談しましょう。」
というルールがあります。
良いルールですが、本当に30分で相談するでしょうか。
実際には、多くの人が次のように考えます。
- 「もう少し頑張れば解決できそう。」
- 「あと10分だけ調べよう。」
- 「PMが忙しそうだから後で相談しよう。」
つまり、相談するかどうかは最後は本人の判断です。
どれだけルールを決めても、「相談する」という行動は、人の心理に依存しています。
「相談」を仕組み化するのは難しい
ここで考え方を変えてみます。
私たちは、「相談を仕組み化したい」と考えがちです。
しかし、本当に仕組み化したいのは相談なのでしょうか。
相談という行動は、次のような人間の感情に大きく左右されます。
- 遠慮
- 責任感
- 自信
- 心理的安全性
つまり、相談そのものを完全に仕組み化することは難しいのです。
仕組み化するべきなのは「助けを求めるシグナル」
では、何を仕組み化すればよいのでしょうか。
私は、「助けが必要であることを知らせるシグナル」を標準化することだと考えています。
例えば、進捗報告に次のような項目を設けます。
- □ 予定どおり
- □ 遅延
- □ 判断に迷っている
- □ 支援が必要
ここでは、「相談してください」とは言っていません。
メンバーは、「支援が必要です」というシグナルを出すだけです。
PMの役割も変わる
この考え方になると、PMの役割も変わります。
従来は、メンバーが相談に来るのを待っていました。
しかし、シグナルが出たらPMの方から声を掛けます。
つまり、
相談を待つのではなく、対話を始める。
これがPMの役割になります。
Pull型からPush型へ
従来の相談は、次のような「Pull型」のコミュニケーションでした。
困る
↓
相談する
↓
PMが対応する
しかし、シグナルを標準化すると、次のような「Push型」へ変わります。
支援が必要というシグナル
↓
PMが気付く
↓
PMが声を掛ける
↓
一緒に解決する
これなら、「相談しづらい」という心理的ハードルを下げることができます。
シグナルは特別な仕組みではない
実は、多くのプロジェクトでは、すでにシグナルを出す仕組みがあります。
- チケットのステータスを「Blocked」に変更する。
- 進捗報告で「支援が必要」を選択する。
- 朝会で「今日の懸念事項」を一言共有する。
- 課題管理表へ登録する。
これらはすべて、「助けが必要です」というシグナルです。
重要なのは、このシグナルが誰でも同じ意味で理解できるように標準化されていることです。
「相談してください」から卒業する
「困ったら相談してください。」
この言葉自体は間違っていません。
しかし、それだけでは相談するかどうかはメンバーに委ねられています。
PMが本当に設計すべきなのは、相談という行動ではなく、助けが必要であることを誰でも迷わず表現できる仕組みです。
シグナルが標準化されれば、PMはそのシグナルを見逃さずに対話を始めることができます。
これが、人に依存しすぎないコミュニケーションマネジメントの第一歩なのではないでしょうか。
まとめ
プロジェクトでは、「相談してください」という言葉よりも、「助けが必要だと分かる仕組み」を設計することの方が重要なのかもしれません。
皆さんのプロジェクトには、助けを求めるシグナルは設計されていますか？
それとも、相談するかどうかをメンバー一人ひとりの判断に委ねているでしょうか。
これはCTAサンプルです。
内容を編集するか削除してください。
