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

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

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

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

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

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

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

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

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

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

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

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

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

私もそうでした。

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

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

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

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

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

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

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

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

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

これだけです。

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

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

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

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

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

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

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

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

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

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

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

以前

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

現在

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私はまず、

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

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

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

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

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

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

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

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

と思ってしまうのです。

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

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

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

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

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

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

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

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

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

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

おわりに

新人の頃の私は、

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

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

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

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

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

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

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

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

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

あなたへの問いかけ

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

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

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

「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」

という考え方について書きました。

では、そのコミュニケーションは、いつ設計すればよいのでしょうか。

私の答えは、プロジェクト開始時のキックオフミーティングです。

キックオフミーティングというと、次のような「説明会」のイメージを持っている方も多いでしょう。

• プロジェクトの目的を説明する
• スケジュールを共有する
• 体制を説明する

もちろん、それらも大切です。

しかし、人見知りだった私にとって、キックオフミーティングの一番の目的は違いました。

「初対面」を終わらせること。

これが、私にとってのキックオフミーティングの本当の価値でした。

人見知りにとって一番難しいのは「最初の一言」

私は昔から人見知りでした。

特に苦手だったのは、初対面の人との会話です。

プロジェクトが始まると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 「何を話せばいいんだろう。」
• 「今話しかけても迷惑ではないかな。」

そんなことばかり考えてしまい、自分から話しかけることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

しかし、その「そのうち」は、決まってトラブルが起きたときでした。

キックオフをやらないと、プロジェクトは「いつの間にか」始まってしまう

ある時、キックオフミーティングを実施しなかったプロジェクトがありました。

気付けば、それぞれが作業を始め、プロジェクトは静かにスタートしていました。

しかし、そのプロジェクトではチームマネジメントがうまくいきませんでした。

プロジェクトメンバーは、

• 何のためにこのプロジェクトをやるのか
• どれほど重要なプロジェクトなのか

を十分に理解できていませんでした。

そのため、当事者意識も生まれにくく、PMである私が後から一人ひとりとコミュニケーションを取り、プロジェクトへの意識を高めていく必要がありました。

人見知りの私にとって、それは非常に大きな負担でした。

今振り返ると、問題はコミュニケーション能力ではありません。

プロジェクトのスタートを設計できていなかったのです。

キックオフは「説明会」ではなく「チームを作る場」

それ以来、私は必ずキックオフミーティングを実施するようになりました。

ただし、目的は説明ではありません。

私が一番大切にしているのは、

「このプロジェクトを成功させるチームを作ること」です。

そのために、必ず次のことを伝えています。

• このプロジェクトの目的
• なぜ今このプロジェクトが必要なのか
• ステークホルダーが期待していること
• 会社として期待していること
• PMとして、このプロジェクトにかける思い

スケジュールや体制は資料を見れば分かります。

しかし、

「このプロジェクトは重要なんだ。」

という熱意は、PM自身の言葉でしか伝えられません。

私は、この時間がプロジェクトメンバーの当事者意識を育てるのだと思っています。

不安を話してもらう時間が、未来のリスクを減らす

キックオフでは、もう一つ必ず行っていることがあります。

一人ひとりに、不安なことを話してもらうことです。

プロジェクトの規模によって時間は調整しますが、できる限り全員に話してもらいます。

すると、

• この技術は経験がありません
• スケジュールが少し心配です
• 他案件との兼務があります

など、さまざまな声が聞こえてきます。

これは単なる自己紹介ではありません。

私はこの時間を、リスクを見つける時間だと思っています。

さらに、この時間にはもう一つ大きな意味があります。

全員が一度は発言することで、

「話してもいい場なんだ。」

という空気が生まれます。

この最初の一言が、その後の相談のしやすさにつながっていくのです。

最初の30分が、その後数か月のコミュニケーションを変える

キックオフが終わると、不思議なくらいコミュニケーションが楽になります。

• チャットを送る
• 電話を掛ける
• 相談する

どれも心理的なハードルが下がるのです。

特に電話では、その効果を強く感じます。

相手は、私の顔を思い出しながら話してくれている。

私も、「一度話した相手だから」という安心感があります。

トラブルが起きたときも、

「すぐ連絡してください。」

と言えば、すぐに対応してくれることが増えました。

私はこれを、キックオフで築いた信頼関係のおかげだと考えています。

PMBOK®には「キックオフをやりましょう」とは書かれていない

PMBOK®には、

「必ずキックオフミーティングを実施しましょう。」

とは書かれていません。

しかし、コミュニケーション・マネジメントでは、必要な情報を必要な人へ適切なタイミングで届けることが重要だとされています。

また、ステークホルダー・エンゲージメントでは、ステークホルダーとの良好な関係を構築し、維持することが求められます。

私は、この考え方を実践する最初の機会がキックオフミーティングだと考えています。

単なる説明会ではありません。

チームを作り、信頼関係を築き、コミュニケーションを始めるための最初のイベントなのです。

おわりに

私は今でも人見知りです。

初対面の人と話すことが得意になったわけではありません。

それでも、キックオフミーティングを大切にするようになってから、コミュニケーションに対する苦手意識は大きく減りました。

理由は簡単です。

自分を変えたのではなく、コミュニケーションが生まれる環境を設計したからです。

キックオフミーティングは、プロジェクト開始の儀式ではありません。

チームが同じ方向を向き、安心して相談できる関係を作るための第一歩です。

だから私は、人見知りのPMほどキックオフミーティングを大切にしてほしいと思っています。

あなたへの問いかけ

あなたのプロジェクトのキックオフミーティングは、「説明会」で終わっていませんか。

それとも、チームを作るための最初のコミュニケーション設計になっているでしょうか。

プロジェクトマネージャについて学ぶと、必ずと言っていいほど耳にする言葉です。

そのため、「話すのが得意な人」「誰とでもすぐに打ち解けられる人」がPMに向いていると思われがちです。

しかし、PMBOK®を読むと少し違った景色が見えてきます。

PMBOK®では、コミュニケーション・マネジメントについて、「必要な情報を、必要な人へ、適切なタイミングで届けるための計画・実行・監視」を重視しています。

一方で、「社交的になりましょう」「話し上手になりましょう」とは書かれていません。

私はこの違いに救われました。

なぜなら、私は人見知りだったからです。

私は「コミュニケーション能力を身に付けなければPMは務まらない」と思っていました。

しかし10年以上PMとして仕事を続ける中で気付いたのは、PMに本当に必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力だったということです。

私が一番苦手だったのは「初対面の人」と話すこと

人見知りにもさまざまなタイプがありますが、私が特に苦手だったのは初対面の人との会話でした。

プロジェクトが立ち上がると、多くのメンバーやステークホルダーとは初めて仕事をします。

本来であれば、自分から積極的に声を掛けて関係を築いた方が良いのでしょう。

しかし私は、

• 何と話しかければいいんだろう。
• 今話しかけても迷惑ではないかな。

そんなことばかり考えてしまい、自分から声を掛けることができませんでした。

「そのうち話す機会があるだろう。」

そう思って先延ばしにしていたのです。

ところが、その「話す機会」は決まってトラブルが起きたときでした。

トラブルのときに初めて話すのでは遅い

問題が発生すると、PMは多くの人と連携しながら状況を整理し、対応方針を決めなければなりません。

しかし、お互いに十分な関係性ができていない状態では、

• 相談しづらい
• 本音を引き出しにくい
• お願いもしづらい

という状況になります。

私は何度も、

「もっと早く話しておけば良かった。」

と後悔しました。

当時は「コミュニケーション能力が足りないからだ」と思っていましたが、今振り返ると違います。

コミュニケーションが生まれる場を設計できていなかったのです。

私を変えたのは「キックオフミーティング」だった

転機になったのは、キックオフミーティングの目的を変えたことでした。

以前の私は、キックオフはプロジェクトの目的やスケジュールを説明する場だと考えていました。

しかし今は違います。

私にとってキックオフの最大の目的は、

「最初のコミュニケーションを設計すること」

です。

自己紹介をする。

挨拶をする。

顔と名前を一致させる。

ほんの数分の会話でも構いません。

一度でも会話していると、その後のコミュニケーションは驚くほど楽になります。

チャットを送る心理的なハードルが下がります。

電話を掛けるときも、

「相手は自分の顔を思い出しながら話してくれている。」

そんな安心感があります。

私は社交的になったわけではありません。

社交的でなくても話せる環境を作っただけだったのです。

振り返ってみると、私は無意識のうちに「コミュニケーション・マネジメント計画」を見直していたのだと思います。

「誰と、いつ、どのようにコミュニケーションを取るか」を計画することは、情報共有だけではありません。

コミュニケーションが自然に生まれるきっかけを設計することでもあるのです。

PMBOK®の「テーラリング」を、自分自身にも適用してみた

PMBOK®では、プロジェクトの特性に合わせてプロセスや手法を調整することをテーラリングと呼びます。

私はこの考え方を、プロジェクトだけでなく自分自身にも当てはめるようになりました。

以前は、

• もっと話せるようになろう。
• 人見知りを克服しよう。

と考えていました。

しかし、それでは長続きしませんでした。

そこで発想を変えました。

「人見知りでも成果を出せるプロジェクト運営を設計しよう。」

そう考えるようになったのです。

キックオフを実施する。

定例会を設ける。

レビューの場を作る。

相談しやすいルールを決める。

これらはプロジェクトを管理するためだけではありません。

自分の苦手を補うための仕組みでもありました。

PMは「人を変える」のではなく、「行動しやすい環境」を設計する

この考え方は、プロジェクトメンバーにも当てはまります。

PMは、

「もっと相談してください。」

「もっと報告してください。」

と言うだけでは十分ではありません。

相談しやすいタイミングを決める。

報告する基準を決める。

定例会や1on1を設ける。

つまり、行動しやすい環境を設計することが重要です。

これは、PMBOK®のステークホルダー・エンゲージメントの考え方にも通じます。

ステークホルダーを動かすために必要なのは、「相手の性格を変えること」ではありません。

相手が行動しやすい環境を整えることです。

そして、この考え方は自分自身にも使えます。

人見知りという性格を変えようとするのではなく、

人見知りでも行動できる環境を設計する。

その方が、ずっと現実的で、再現性があります。

私が考えるPMのコミュニケーション能力

私は昔、コミュニケーション能力とは、

• 話すのが上手なこと
• 誰とでも仲良くなれること

だと思っていました。

しかし、今は違います。

私にとってPMのコミュニケーション能力とは、

「必要な情報が、必要な人へ、必要なタイミングで届く状態を設計する力」

です。

話すことが目的ではありません。

プロジェクトを前に進めることが目的です。

だからこそ、PMに必要なのは社交性ではなく、

必要なコミュニケーションが自然に生まれる仕組みを作る力なのだと思います。

おわりに

私は今でも人見知りです。

初対面の人と話すことが得意になったわけではありません。

それでもPMとして仕事を続けられているのは、自分を変えたからではありません。

自分に合った環境を設計するようになったからです。

これは、プロジェクトマネジャという仕事の本質にも通じています。

PMは、プロジェクトを成功へ導くために、計画を立て、仕組みを作り、人が動きやすい環境を整えます。

それなら、自分自身に対しても同じことができるはずです。

苦手なことを無理に克服しようとするのではなく、

苦手でも成果を出せる環境を設計する。

私は、それこそがプロジェクトマネジメントの考え方を、自分自身に活かすことなのだと思っています。

あなたへの問いかけ

あなたは、苦手なことに出会ったとき、自分を変えようとしていませんか。

それとも、苦手でも成果を出せる環境を設計しようとしていますか。

プロジェクトマネジメントは、プロジェクトを管理するための知識だけではありません。

自分自身をマネジメントするための考え方でもあるのではないでしょうか。

まずは一つだけ、環境を変えてみる

もしあなたが私と同じように人見知りで悩んでいるなら、性格を変えようとする必要はありません。

まずは一つだけ、コミュニケーションが自然に生まれる仕組みを作ってみてください。

例えば、キックオフで必ず全員と自己紹介をする、定例会を設ける、1on1の時間を確保するなど、小さな工夫で十分です。

自分を変えることは難しくても、環境を変えることはできます。

その小さな仕組みが、プロジェクトだけでなく、あなた自身をきっと助けてくれるはずです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

① 時間

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

例

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

② 数量

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

例

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

③ 状態

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

例

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

④ 変化

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

例

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

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

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

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

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

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

というルールです。

つまり、

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

を設計することです。

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

まとめ

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

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

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

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

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

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

おわりに

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

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

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

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

プロジェクトのキックオフで、この言葉を伝えたことがあるPMは多いのではないでしょうか。

私も以前は、この一言で十分だと思っていました。

しかし、実際のプロジェクトでは、次のような場面が何度もありました。

• 「実は昨日から困っていました。」
• 「もう少し自分で調べようと思っていました。」
• 「忙しそうだったので声を掛けられませんでした。」

つまり、「相談してください」と伝えるだけでは、相談は仕組み化できていなかったのです。

「相談する」は人に依存している

例えば、

「30分悩んだら相談しましょう。」

というルールがあります。

良いルールですが、本当に30分で相談するでしょうか。

実際には、多くの人が次のように考えます。

• 「もう少し頑張れば解決できそう。」
• 「あと10分だけ調べよう。」
• 「PMが忙しそうだから後で相談しよう。」

つまり、相談するかどうかは最後は本人の判断です。

どれだけルールを決めても、「相談する」という行動は、人の心理に依存しています。

「相談」を仕組み化するのは難しい

ここで考え方を変えてみます。

私たちは、「相談を仕組み化したい」と考えがちです。

しかし、本当に仕組み化したいのは相談なのでしょうか。

相談という行動は、次のような人間の感情に大きく左右されます。

• 遠慮
• 責任感
• 自信
• 心理的安全性

つまり、相談そのものを完全に仕組み化することは難しいのです。

仕組み化するべきなのは「助けを求めるシグナル」

では、何を仕組み化すればよいのでしょうか。

私は、「助けが必要であることを知らせるシグナル」を標準化することだと考えています。

例えば、進捗報告に次のような項目を設けます。

• □ 予定どおり
• □ 遅延
• □ 判断に迷っている
• □ 支援が必要

ここでは、「相談してください」とは言っていません。

メンバーは、「支援が必要です」というシグナルを出すだけです。

PMの役割も変わる

この考え方になると、PMの役割も変わります。

従来は、メンバーが相談に来るのを待っていました。

しかし、シグナルが出たらPMの方から声を掛けます。

つまり、

相談を待つのではなく、対話を始める。

これがPMの役割になります。

Pull型からPush型へ

従来の相談は、次のような「Pull型」のコミュニケーションでした。

困る
↓
相談する
↓
PMが対応する

しかし、シグナルを標準化すると、次のような「Push型」へ変わります。

支援が必要というシグナル
↓
PMが気付く
↓
PMが声を掛ける
↓
一緒に解決する

これなら、「相談しづらい」という心理的ハードルを下げることができます。

シグナルは特別な仕組みではない

実は、多くのプロジェクトでは、すでにシグナルを出す仕組みがあります。

• チケットのステータスを「Blocked」に変更する。
• 進捗報告で「支援が必要」を選択する。
• 朝会で「今日の懸念事項」を一言共有する。
• 課題管理表へ登録する。

これらはすべて、「助けが必要です」というシグナルです。

重要なのは、このシグナルが誰でも同じ意味で理解できるように標準化されていることです。

「相談してください」から卒業する

「困ったら相談してください。」

この言葉自体は間違っていません。

しかし、それだけでは相談するかどうかはメンバーに委ねられています。

PMが本当に設計すべきなのは、相談という行動ではなく、助けが必要であることを誰でも迷わず表現できる仕組みです。

シグナルが標準化されれば、PMはそのシグナルを見逃さずに対話を始めることができます。

これが、人に依存しすぎないコミュニケーションマネジメントの第一歩なのではないでしょうか。

まとめ

プロジェクトでは、「相談してください」という言葉よりも、「助けが必要だと分かる仕組み」を設計することの方が重要なのかもしれません。

皆さんのプロジェクトには、助けを求めるシグナルは設計されていますか？

それとも、相談するかどうかをメンバー一人ひとりの判断に委ねているでしょうか。

しかし、実際のプロジェクトでは、この2つは密接に関係しています。

私がこれまで経験してきたプロジェクトを振り返ると、炎上したプロジェクトには共通点がありました。

「問題が起きたこと」ではなく、「問題が起きる前に必要なコミュニケーションが行われなかったこと」です。

「もっと早く相談してほしかった」と思ったことはありませんか？

プロジェクトマネージャであれば、一度はこのように感じたことがあるのではないでしょうか。

• 遅れそうなら早く言ってほしかった。
• 分からないなら相談してほしかった。
• 他チームへ影響するなら事前に共有してほしかった。

一方で、メンバーにも言い分があります。

• もう少し自分で調べようと思った。
• PMが忙しそうだった。
• まだ何とかなると思った。

どちらも間違っているわけではありません。

問題は、「相談するタイミング」が個人の判断に委ねられていることです。

「30分悩んだら相談」は本当に仕組みと言えるのか？

よく聞くルールに、

「30分悩んだら相談しましょう。」

というものがあります。

一見すると良いルールに思えますが、本当にこれで相談は確実に行われるでしょうか。

実際には、次のような心理が働きます。

• まだ調べれば解決できるかもしれない。
• もう少し頑張ってみよう。
• 忙しそうだから後で相談しよう。

つまり、最終的には本人の判断になります。

これはルールではありますが、必ず相談が行われる仕組みではありません。

相談ではなく「問題の前兆」をトリガーにする

では、どうすれば相談を仕組み化できるのでしょうか。

私がたどり着いた考え方は、「相談」そのものをトリガーにするのではなく、「問題の前兆」をトリガーにすることです。

例えば、次のような状態です。

• タスクの更新が止まっている。
• レビュー指摘が急増している。
• 承認待ちが長期間続いている。

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

しかし、将来問題になる可能性を示す前兆です。

PMBOK®では、このような前兆を監視し、必要な対応を行う活動はリスクマネジメントの「リスクの監視」に位置付けられています。

つまり、

• 前兆を検知することはリスクマネジメント
• 検知した結果として相談や調整を行うことはコミュニケーションマネジメント

という関係になります。

2つの知識エリアは一本の流れでつながっている

実務では、コミュニケーションとリスク管理は別々には動きません。

実際には、次のような流れで進んでいます。

1. プロジェクトの状態を監視する。
2. 問題の前兆を検知する。
3. 関係者へ相談・共有する。
4. 必要な意思決定を行う。
5. 問題を未然に防ぐ。

つまり、

リスクマネジメントが「気付く仕組み」を作り、コミュニケーションマネジメントが「動く仕組み」を作る。

この2つが組み合わなければ、問題を未然に防ぐことはできません。

PMの仕事は「問題を管理すること」ではない

私は、ここでPMの役割を少し捉え直す必要があると考えています。

PMの仕事は、

「問題が起きたら対応すること」

だけではありません。

本当に重要なのは、問題が起きる前に前兆を検知し、適切なコミュニケーションが自然と始まる仕組みを設計することです。

例えば、次のようなルールを設計します。

• レビュー指摘件数が一定数を超えたら設計レビューを実施する。
• 承認待ちが一定期間を超えたら関係者で調整する。
• タスクが長期間更新されなければ状況確認を行う。

このように、「前兆」と「コミュニケーション」を結び付けて設計することで、PMが毎回「何か困っていない？」と聞かなくても、プロジェクトは自然と問題を未然に防ぐ方向へ動き始めます。

まとめ

コミュニケーションマネジメントとリスクマネジメントは、PMBOK®では別々の知識エリアです。

しかし、実務では切り離して考えることはできません。

• リスクマネジメントは、問題の前兆を検知するための仕組み
• コミュニケーションマネジメントは、前兆に対して必要な対話や意思決定を行うための仕組み

私は、この2つを一本の流れとして設計することが、プロジェクトマネージャの重要な役割の一つだと考えています。

次回は、この考え方をさらに発展させ、「相談してください」と言わなくても自然と助けを求められる仕組みについて考えていきます。

プロジェクトマネージャについて調べると、必ずと言っていいほど目にする言葉です。

そのたびに私は思っていました。

「それなら、自分はPMに向いていない。」

私は昔から人見知りでした。

• 初対面の人と話すのが苦手
• 自分から声を掛けるのも苦手
• 雑談も得意ではない

プロジェクトマネージャになってからは、その苦手意識がさらに強くなりました。

• 毎日のようにプロジェクトメンバーへ声を掛ける
• ステークホルダーと調整する
• お客様へ報告する

「今日も誰かと話さなければならない。」

そんなことを考えるだけで、気持ちが重くなる日もありました。

それでも私は10年以上、PMとして仕事を続けることができました。

その理由は、コミュニケーション能力が高くなったからではありません。

コミュニケーションを「仕組み」で考えるようになったからです。

人見知りにもいろいろなタイプがある

一口に「人見知り」と言っても、その原因はさまざまです。

例えば、次のようなタイプがあります。

• 初対面だと緊張して話せない人
• 雑談が苦手な人
• 相手に気を遣いすぎる人
• 自分の意見に自信が持てない人
• 十分に整理できるまで話せない人

私は、この中でも「慎重すぎるタイプ」と「相手に気を遣いすぎるタイプ」でした。

いつも頭の中では、こんなことを考えていました。

• ちゃんと整理してから話そう
• 解決策まで考えてから相談しよう
• 忙しそうだから後で声を掛けよう

そうしているうちに、時間だけが過ぎていきました。

一番苦しかったのは、問題を抱え込んでしまうこと

今振り返ると、一番の問題は雑談が苦手だったことではありません。

問題が起きたときに、

「もう少し調べてから報告しよう。」

と思ってしまうことでした。

原因が分からないまま報告すると、

• 「なんでそんな状態で相談するの？」と思われるのではないか
• 質問に答えられなかったらどうしよう

そんな不安から、報告を後回しにしてしまうことが何度もありました。

しかし、PMとして経験を積むうちに、一つ気付いたことがあります。

プロジェクトでは、完成した情報より、早い情報の方が価値がある。

原因が分からなくても、

「納期に影響するかもしれません。」

この一言だけで、周りは動き始めることができます。

逆に、原因も対策も分かった頃には、打てる手が少なくなっていることもあります。

PMの仕事は、一人で問題を解決することではありません。

問題を見える化し、チームで解決することです。

私を助けてくれたのは、「コミュニケーション能力」ではなく「仕組み」だった

人見知りの私が頼ったのは、自分の性格を変えることではありませんでした。

代わりに考えたのは、コミュニケーションが自然に生まれる仕組みを作ることです。

例えば、次のような仕組みです。

• プロジェクト開始時には必ずキックオフミーティングを実施する
• 毎週決まった時間に定例会を行う
• 1on1を定期的に実施する
• 課題管理表を使って状況を見える化する
• 議事録を残し、決定事項を共有する

こうした仕組みがあると、

「話しかけたいから話す。」

ではなく、

「プロジェクト運営に必要だから話す。」

という状態になります。

人見知りにとって、この違いはとても大きいものです。

特にキックオフミーティングは重要でした。

一度でも顔を合わせることで、その後のチャットや相談の心理的ハードルは大きく下がります。

人見知りだからこそ、PMに向いている部分もある

人見知りだからPMに向いていない。

私はずっとそう思っていました。

でも今は違います。

人見知りだからこそ、次のような力が自然と身に付きました。

• 会議をしっかり準備する
• 相手の話をよく聞く
• 小さな変化に気付く
• コミュニケーションを仕組みとして設計する

もちろん、苦手なことは今でもあります。

それでも、PMに必要なのは社交性ではありません。

必要なのは、プロジェクトが前に進むように、人・情報・意思決定をつなぐことです。

コミュニケーションは、そのための手段に過ぎません。

まとめ

人見知りだからといって、PMを諦める必要はありません。

ただし、一人で頑張り続けることは危険です。

人見知りのPMほど、問題を抱え込みやすく、相談を後回しにしてしまう傾向があります。

だからこそ必要なのは、「もっと話せるようになること」ではありません。

話さなければならない状況を、自然につくる仕組みです。

私は、人見知りだったからこそ、コミュニケーションを「才能」ではなく「設計するもの」と考えるようになりました。

そして今では、それこそがプロジェクトマネージャに最も必要な能力の一つだと感じています。

あなたはどう思いますか？

あなたは、「コミュニケーション能力」と聞くと、どんな力を思い浮かべますか？

「話すのが上手な人」でしょうか。

それとも、「プロジェクトが前に進む仕組みをつくれる人」でしょうか。

人見知りという特性を、弱みではなく設計力へ変える視点が、あなた自身のプロジェクト運営のヒントになれば幸いです。

「私ばっかり家のこと考えてる気がする。」

夫婦でこんな会話になったことはありませんか？

実は、この二人の言葉は、どちらも間違っていないのかもしれません。

なぜなら、多くの家庭では「見えている家事」しか比較していないからです。

洗濯をする。
料理を作る。
掃除機をかける。

こうした家事は、誰がやったのか分かります。

でも、その裏側には、誰にも見えない仕事がたくさんあります。

私はプロジェクトマネジャーとして仕事をしています。

プロジェクトマネジメントでは、実際に作業をする人だけではありません。

• 準備する人
• 確認する人
• 問題が起きないように考える人

こうした役割も、とても重要だと考えます。

家庭も、実は同じなのです。

家事は「やること」より「考えること」の方が多い

例えば、保育園へ子どもを送り出す朝。

朝やっていることだけを見ると、次のような作業に見えるかもしれません。

• 着替えさせる
• 朝ごはんを食べさせる
• 保育園へ送る

でも、その裏では前日から多くのことを考えています。

• 明日はプールの日だったかな？
• タオルは乾いている？
• 着替えは足りている？
• オムツは補充した？
• 連絡帳を書いた？
• 明日は雨だからレインコートが必要かな？

そして朝になると、さらに確認が続きます。

• 水筒のお茶は入れた？
• ハンカチは持った？
• 今日の薬は入れた？
• 保育園からのお知らせに返事を書いた？

これらは「家事」として数えられることはほとんどありません。

でも、誰かがやらなければ家庭は回りません。

「買い物」はスーパーへ行くことではない

例えば、「牛乳買ってきたよ。」

もちろん助かります。

でも、その前には次のような仕事があります。

• 牛乳が少なくなっていることに気付く
• 今週の献立を考える
• ヨーグルトもなくなりそうだと思い出す
• 洗剤も残り少なかったことを思い出す
• 仕事帰りに寄れるスーパーを考える

買い物から帰った後にも仕事は続きます。

• 冷蔵庫へしまう
• 古い食材から使えるように並べる
• 次に必要なものを考える

つまり「買い物」という家事の裏側には、気付く・覚える・考える・計画する・整理するという仕事があります。

子どもの成長も、誰かが管理している

家庭では、次のようなことも誰かが管理しています。

• 靴が小さくなってきた
• 子ども服を買い替えなきゃ
• 来月は予防接種だった
• 保育園の提出書類の期限が近い
• オムツはそろそろサイズアップかな

これらは「今日やる家事」ではありません。

でも、家庭が止まらないようにするためには欠かせない仕事です。

「気付く人」が、見えないコストを払っている

家庭では、「気付いた人がやればいい。」という言葉をよく聞きます。

でも、このルールには落とし穴があります。

それは、「気付く人」が固定化してしまうことです。

• トイレットペーパーがなくなりそう
• 子どもの靴が小さくなった
• 保育園の提出期限が近い
• 牛乳を買わないと

こうしたことに気付き続ける人は、常に頭の中で家庭を管理しています。

だから、「家事をやった時間」だけでは負担は測れません。

家事の本当のコストは「時間」だけではない

プロジェクトマネジメントでは、コストはお金だけではありません。

時間や人の労力はもちろん、考え続けることもコストとして考えます。

家庭も同じです。

料理を30分した人と、30分かけて献立を考え、冷蔵庫を確認し、買い物を計画した人。

どちらも家庭には必要な仕事です。

でも、後者は目に見えません。

だから、「俺も30分やったよ。」と「私ばっかり負担が大きい。」が同時に成立してしまうのです。

どちらかが間違っているのではありません。

見えているコストしか比較していないからです。

見えないコストが見えるだけで、家庭は少し変わる

家事分担というと、「何をやるか」に目が向きがちです。

でも、本当に大切なのは、「誰が考え続けているか」なのかもしれません。

作業だけではなく、

• 準備すること
• 確認すること
• 思い出すこと
• 気付くこと

これらも立派な家事です。

その存在を知るだけでも、「ありがとう。」と言える場面はきっと増えるはずです。

あなたの家庭では、どうですか？

あなたの家庭では、誰が「見えないコスト」を負担しているでしょうか。

そして、その負担は、お互いに見えていますか。

家事は、目に見える作業だけではありません。

家庭が毎日当たり前に回るように、誰かが考え、準備し、確認し続けています。

もしかすると、家事を分担することよりも先に、「見えないコスト」をお互いに知ること。

それが、家庭をもっとラクにする第一歩なのかもしれません。

「えっ？聞いてないよ。」

夫婦の会話で、一度は聞いたことがあるやり取りではないでしょうか。

伝えたつもり。

聞いていないつもり。

どちらかが嘘をついているわけではありません。

それでも、お互いに少しイライラする。

そして最後には、

「なんでちゃんと伝えてくれないの？」
「いや、ちゃんと言ったよ。」

という不毛なやり取りになってしまいます。

私はプロジェクトマネジメントの仕事をしていますが、この場面を見るたびに思うことがあります。

これは、コミュニケーション不足ではありません。

コミュニケーションの「設計」が不足しているのです。

「伝えた」と「伝わった」は違う

仕事でも家庭でも、

「言ったから伝わった」

とは限りません。

例えば、仕事中に口頭で重要な依頼をされても、忙しければ忘れてしまうことがあります。

だから会社では、

• メールを送る
• チャットに残す
• 会議の議事録を書く

など、「忘れない仕組み」を作っています。

でも家庭では、

料理中に、

「明日これお願いね。」

子どもの世話をしながら、

「そういえば提出物あるから。」

寝る前に、

「週末は実家に行くからね。」

こんなふうに、思いついたタイミングで伝えることが多くありませんか。

これでは、忘れてしまうのも無理はありません。

家庭には「暗黙のルール」が多すぎる

家庭では、

「言わなくても分かるよね。」

「普通こうするよね。」

そんな「暗黙のルール」がたくさんあります。

でも、「普通」は人によって違います。

例えば、

「洗濯をする」

という一つの家事でも、

• 洗うことまでを指す人
• 干すところまでと思う人
• 畳んでしまうまでが終わりだと思う人

人によって認識は違います。

だから、

「ちゃんとやったよ。」

「いや、終わってないよ。」

という会話が生まれます。

お互いが悪いのではありません。

最初から「終わり」の認識が違っていたのです。

「察して」は最も難しいコミュニケーション

家庭では、

「最近疲れてるんだよね。」

という言葉が出ることがあります。

言った本人は、

• 少し家事を代わってほしい
• 話を聞いてほしい

そんな気持ちを伝えたいのかもしれません。

でも、受け取る側には、

「そうなんだ。大丈夫？」

くらいにしか伝わらないこともあります。

期待していた反応が返ってこない。

すると、

「分かってくれない。」

となってしまう。

実は、

「察してほしい」というコミュニケーションは、とても難易度が高いのです。

家庭にも「定例会議」があっていい

仕事では、毎週、進捗を確認する会議があります。

それは会議をすることが目的ではありません。

認識をそろえるためです。

家庭も同じではないでしょうか。

例えば週に10分だけでも、

• 来週の予定
• 子どもの行事
• 困っていること
• 家事の負担

を話す時間を作る。

それだけで、

「聞いてない。」

「知らなかった。」

は大きく減ります。

「ありがとう」は最高のコミュニケーション

家庭では、

やって当たり前。

気づいて当たり前。

そんな空気になりがちです。

でも、

「ありがとう。」

「助かったよ。」

この一言があるだけで、また頑張ろうと思えることがあります。

仕事でも、評価されない職場は少しずつ活気を失います。

家庭も同じです。

感謝は、相手を褒めるためだけではありません。

「あなたの頑張りを見ていますよ。」というメッセージなのです。

家庭は、小さなチーム

私は最近、家庭は小さなチームだと思うようになりました。

チームだからこそ、大切なのは、たくさん話すことではありません。

同じ方向を向いていることです。

必要なことを、必要なタイミングで共有し、

困ったときは相談し、

「ありがとう」を忘れない。

そんな小さな積み重ねが、家庭というチームを支えているのだと思います。

だから私は、コミュニケーションとは、

「話す技術」ではなく、
「認識をそろえる技術」なのだと考えています。

あなたの家庭では、どうですか？

家庭では、仕事のように会議室で打ち合わせをすることもなければ、議事録を残すこともありません。

だからこそ、

「言った」
「聞いてない」

「分かってくれていると思った」
「そんなつもりじゃなかった」

というすれ違いが起きやすいのかもしれません。

でも、その原因は「コミュニケーション不足」ではなく、お互いの認識をそろえる仕組みがないことなのではないでしょうか。

あなたの家庭では、

「言った」「聞いてない」で終わってしまうことはありませんか？

また、その原因は本当に「伝え方」の問題でしょうか。

それとも、お互いの期待や認識を共有する時間が足りていないだけかもしれません。

夫は良かれと思って言っています。

疲れているのも分かっている。
少しでも助けになればと思っている。

でも、その言葉を聞いた妻は、

「いや、“手伝う”じゃないんだよ……」

と、なぜかモヤっとする。

一方で夫は思います。

• 「ちゃんと気を遣ってるのに」
• 「手伝おうとしてるのに」
• 「なんで不機嫌になるんだ……？」

このすれ違いは、子育て家庭ではかなり「あるある」ではないでしょうか。

そして厄介なのは、どちらも悪気がないことです。

夫はサボろうとしているわけではありません。
妻も責めたいわけではありません。

なのに、なぜか家庭の空気が悪くなる。

実はこれ、単なる「家事分担」の問題ではありません。

もっと根深い、「家庭運営の構造」の問題なのです。

家事には「作業」と「管理」がある

例えば、夫がこう言います。

「洗濯やっといたよ！」

とても助かります。

でもその裏で、妻はこう考えているかもしれません。

• 子供服のサイズは足りていたっけ？
• 明日の保育園の準備はどうする？
• タオルは乾いている？
• オムツの残りが少なかったな
• 連絡帳をまだ書いていない

つまり家庭には、

「手を動かす作業」

だけではなく、

「抜け漏れが起きないように考え続ける管理」

が存在しています。

そして、この「管理」がとても重いのです。

本当に疲れるのは「ずっと考えていること」

子育て中は、脳内のタスクが常に開きっぱなしです。

• 牛乳がなくなりそう
• 保育園の提出物はいつだっけ？
• 次の予防接種を予約しないと
• 子供服はサイズアウトしていない？
• 明日は雨だから着替えを追加した方がいいかも

気づけば頭の中は、家庭運営のタスク管理でいっぱいになります。

しかも厄介なのは、この負荷が外から見えないことです。

洗濯したことは見えます。

掃除したことも見えます。

でも、

「常に考え続けていること」

は見えません。

だから、

「俺、結構やってるよ？」

と、

「私ばっかり考えてる……」

が同時に成立してしまうのです。

「手伝う」という言葉の正体

ここで冒頭の言葉に戻ります。

「何か手伝おうか？」

この言葉は、無意識のうちに、
「メイン担当はあなた」
という前提を含みやすい言葉です。

つまり、

• 何をやるべきか決める人
• 優先順位を考える人
• 抜け漏れを防ぐ人

が固定化されます。

夫は「作業」を手伝っている。
でも妻は、「家庭全体の管理」をしている。

この構造になると、管理側は休めません。

なぜなら、

「考えること」

が終わらないからです。

会社ならすぐ分かる

これは仕事で考えると分かりやすいです。

例えば部下が毎回、

• 「次、何やればいいですか？」
• 「他にありますか？」
• 「終わりました！」

と言ってくる。

もちろん助かります。

でも上司は、

• 次のタスクを決める
• 優先順位を整理する
• 抜け漏れを確認する

という仕事を、ずっと続ける必要があります。

つまり、「実作業」より「管理」の方が疲れることがあるのです。

家庭でも同じです。

「気づいた人がやる」は危険

家庭でよくあるルールです。

「気づいた人がやればいいよね」

一見すると平和に見えます。

でも実際には、

「気づく人」が固定化します。

例えば、

• トイレットペーパーの補充
• 子供服のサイズ確認
• 保育園の提出物
• 食材の在庫管理

こうしたことに常に気づく人がいるのです。

つまり、

「気づいた人がやる」は、
「気づき続ける人が背負う」
になりやすいのです。

家庭に必要なのは「手伝い」ではなく「担当」

ここで大切なのが、

「手伝う」から「担当を持つ」へ変わることです。

例えば、

• 保育園準備担当
• 洗剤管理担当
• ゴミ出し管理担当

のように、

「自分で気づき、自分で管理する領域」
を持ちます。

すると、

• 指示待ちが減る
• 管理負荷が分散する
• 精神的負担が軽くなる

という効果が期待できます。

ただし、完璧を目指さない

ここはとても大切です。

家庭は会社ではありません。

厳密に役割を管理しすぎると、逆に苦しくなります。

大切なのは、

「どちらが悪いか」ではなく、

「どうすれば家庭がラクに回るか」

を考えることです。

家庭は、超高難易度のチーム運営

最近よく思います。

家庭は、実はものすごく難しいチーム運営です。

しかも、

• 24時間稼働
• 正解がない
• 感情がある
• 子供という予測不能な要素がある

かなりの高難易度プロジェクトです。

だからこそ必要なのは、

「頑張り続けること」

ではなく、

「無理なく続けられる仕組み」

なのかもしれません。

そして、「何か手伝おうか？」という何気ない一言には、
そんな家庭運営の難しさが詰まっているように感じます。