PMになったばかりの頃、私はそんなことを考えていました。

PMにはコミュニケーション能力が必要です。

プロジェクトメンバーと話し、ステークホルダーと調整し、時には多くの人の前で説明する必要があります。

人と話すことが苦手な自分には、向いていない仕事なのではないか。

そう思うこともありました。

しかし、PMとして10年以上仕事を続けてきた今、少し違った考えを持っています。

人見知りだからPMに向いていないわけではありません。

かといって、人見知りだからPMに向いているわけでもありません。

大切なのは、自分がどのような性質を持っているのかを理解し、その性質を補う方法を身につけることです。

私の場合、それが次のようなPMスタイルにつながっていきました。

• 準備する
• よく聞く
• 相手を観察する
• 仕組みを作る

この記事では、私が10年以上PMを続ける中で感じた「人見知りだからこそ身についたPMスタイル」について紹介します。

人見知りだからこそ、準備を意識するようになった

私は今でも、初対面の人と話すことが苦手です。

懇親会も得意ではありません。

突然話を振られることも苦手です。

これは10年以上PMを経験したからといって、完全になくなったわけではありません。

ただ、PMとして仕事をする以上、人とコミュニケーションを取らなければなりません。

そこで私は、自分の性質を変えるのではなく、自分の性質を補完する方法を考えるようになりました。

その一つが「準備」です。

会議の前に、次のようなことを考えておきます。

• 何を話すのか
• 何を確認するのか
• 相手からどんな質問が来るのか

初対面の人と話す必要があるなら、事前に相手の立場や役割を確認しておきます。

問題が起きたときには、以前のように完璧な原因分析や対策を準備してから報告するのではありません。

「問題だと思った時点で報告する」というルールを自分の中に作りました。

こうした工夫によって、人見知りという性質を補ってきました。

もちろん、社交的なPMでも準備はできます。

人見知りだから特別な能力を持っているわけではありません。

ただ、自分が人見知りだと理解しているからこそ、何を準備すれば自分が動きやすくなるのかを、より意識するようになったのだと思います。

「話す力」より「聞く力」がPMを助けてくれた

PMとして仕事をする中で、もう一つ自分の強みだと思うようになったものがあります。

それが、人の話を聞くことです。

私は、人前で話すことや初対面の人と会話することは得意ではありません。

一方で、相手の話を聞きながら、次のように考えることは比較的得意です。

• この人は何を伝えたいのだろう
• 本当に困っていることは何だろう

そして、相手の話を聞きながら質問することで、相手自身が気付いていなかったことに気付いてもらうこともあります。

これはPMにとって、非常に重要な能力だと感じています。

リスク検討の場で気付いた「自分の考えだけでは足りない」ということ

以前、リスクを検討する打ち合わせで印象に残っている出来事があります。

ある先輩PMが、事前に洗い出したリスクをプロジェクトメンバーに説明していました。

経験も豊富で、非常に社交的なPMでした。

そのため、自分の考えに自信を持ってプロジェクトを進めていました。

打ち合わせも終わりに近づいた頃、あるプロジェクトメンバーが、

「他にもリスクがあるのではないか。」

と発言しました。

ところが、その先輩PMは、その意見を十分に聞こうとはしませんでした。

結果として、その場では見逃されていたリスクを、そのメンバーの発言によって見つけることができました。

私はこの出来事を見て、

「PM自身が考えたことだけが正解ではない」

と強く感じました。

どれだけ経験があっても、どれだけ社交的でも、一人で考えられることには限界があります。

だからこそ、プロジェクトメンバーの意見を聞くことが重要なのです。

人見知りだった私は、もともと相手の話を聞くことを意識していました。

その経験が、PMとしての「聞く力」につながっていったのだと思います。

質問することで、相手自身に気付いてもらう

PMにとって、「聞く」とは、ただ黙って相手の話を聞くことではありません。

私は、適切な質問をすることも重要だと考えています。

例えば、次のような質問です。

• 「それはなぜ問題だと思いますか？」
• 「もしそのリスクが発生したら、何が一番困りますか？」
• 「他に影響を受ける人はいませんか？」
• 「今の話をもう少し詳しく教えてもらえますか？」

質問を重ねることで、相手自身が考えを整理できます。

そして、

「そうか。ここもリスクになるかもしれない。」

と、本人が自分で気付くことがあります。

PMが答えを教えるのではなく、質問によって相手を導く。

これは、私が人見知りであることをきっかけに身につけてきた、PMとしての一つのスタイルです。

人見知りだからこそ、相手を観察するようになった

もう一つ、PMとして意識していることがあります。

それは、相手によってコミュニケーションの方法を変えることです。

これはステークホルダーマネジメントにもつながります。

私はプロジェクトの中で、ステークホルダー登録簿などを活用しながら、次のようなことを考えていました。

• この人にはどのように連絡した方がよいか
• どのくらいの頻度で情報共有した方がよいか
• メールがよいのか、電話がよいのか

人によって、コミュニケーションの取り方は違います。

こちらが話しやすい方法ではなく、相手が受け取りやすい方法を考える。

これは、PMにとって重要な考え方だと思います。

先輩PMを「そのまま真似しない」という学び

私がPMとして成長してきた過程では、先輩PMから多くのことを学びました。

先輩のやり方を真似することもありました。

しかし、すべてをそのまま真似したわけではありません。

むしろ、

「このやり方は、この人だからできるのではないか。」

と考えることもありました。

例えば、非常に社交的な先輩PMなら、初対面の相手とも自然に雑談をします。

そして、いつの間にか信頼関係を作ってしまいます。

その方法をそのまま人見知りの自分が真似しても、うまくいかないことがあります。

そこで、

「自分だったらどうするか。」

と考えるようにしました。

• キックオフミーティングを設ける
• 会議の前に準備する
• 質問を用意する
• 定例会で話す機会を作る
• エスカレーションのルールを決める

こうして、自分に合った方法を少しずつ作ってきました。

人見知りを克服する必要はなかった

ここまでの話をすると、

「では、人見知りを克服したのですか？」

と思われるかもしれません。

答えは「いいえ」です。

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

初対面の人との会話も苦手です。

懇親会も苦手です。

突然人前で話すことも得意ではありません。

それでもPMを続けることはできました。

なぜなら、人見知りを克服することと、PMとして成果を出すことは別の話だからです。

必要なのは、自分を別人に変えることではありません。

自分の性質を理解し、その性質を補う方法を身につけることです。

PMには「絶対の正解」がない

PMとして10年以上仕事をしてきて、強く感じることがあります。

それは、

プロジェクトマネジメントには、これが絶対に正しいという方法はない

ということです。

プロジェクトによって、条件は変わります。

• 規模が違う
• メンバーが違う
• ステークホルダーが違う
• 組織が違う
• 目的が違う
• リスクが違う

だからこそ、同じ方法がすべてのプロジェクトで通用するわけではありません。

これは、自分自身についても同じです。

社交的なPMには、社交的なPMのやり方があります。

人見知りのPMには、人見知りのPMのやり方があります。

重要なのは、自分に合った方法を選ぶことです。

自分に合ったPMを作るために、知識と経験を増やす

ただし、

「自分に合った方法でやればいい。」

というだけでは不十分だと思います。

自分に合った方法を見つけるためには、知識と経験が必要だからです。

例えば、次のような知識を学びます。

• PMBOK®︎
• リスクマネジメント
• ステークホルダーマネジメント
• コミュニケーションマネジメント

そして、実際のプロジェクトで試してみます。

うまくいかなければ修正します。

先輩PMのやり方を見て、

• これは自分にも使える
• これは自分には合わない

と考えます。

こうした経験を積み重ねることで、少しずつ自分なりのPMスタイルができていきます。

まとめ：人見知りを克服するより、自分に合ったPMスタイルを作ろう

私は、PMになったばかりの頃、

「人見知りだからPMには向いていないのではないか。」

と思っていました。

しかし、10年以上PMを続けてきた今は、そうは思いません。

人見知りであることが、特別な強みだったわけではありません。

むしろ、自分が人見知りであることを理解していたからこそ、自分を補完する方法を考えるようになったのだと思います。

その結果、次のような自分なりのPMスタイルを作ることができました。

• 事前に準備する
• 相手の話をよく聞く
• 質問によって相手の考えを引き出す
• 相手に合わせてコミュニケーション方法を変える
• コミュニケーションを仕組み化する

だから、もし今、

「自分は人見知りだからPMに向いていない。」

と思っている人がいたら、私はこう伝えたいです。

無理に社交的になる必要はありません。

プロジェクトマネジメントには、絶対の正解はありません。

自分に合ったやり方を選んで、マネジメントしていけばいいのです。

そして、自分に合ったやり方を見つけるためには、知識と経験が必要です。

たくさん学んで、たくさん経験してください。

その中から、

「自分だったらどうするか」

を考えてみてください。

きっと、少しずつ自分に合ったPMのスタイルが見えてくるはずです。

あなたへの問いかけ

あなたは、自分の性格や得意・不得意を理解した上で、どのようなPMスタイルを作っていますか？

そして、今の自分に合っていないと感じるプロジェクトマネジメントのやり方はありませんか？

「正解を探す」のではなく、「自分に合ったやり方を作る」。

それも、プロジェクトマネジメントの一つの楽しさなのではないでしょうか。

The post 人見知りはPMに向いていない？10年続けて分かった本当の強み first appeared on PM道場.

プロジェクトでは、多くのステークホルダーが関わるため、意見や立場が異なることは珍しくありません。

そのような状況で、プロジェクトを前へ進めるために重要なのが合意形成（Consensus Building）です。

この記事では、合意形成の意味や目的、進め方、実務で意識したいポイントについて解説します。

一言でいうと

合意形成とは、「関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセス」です。

合意形成とは

合意形成とは、関係者同士が対話を重ね、共通の理解を持ちながら意思決定を行うことです。

プロジェクトでは、スコープやスケジュール、コスト、品質など、さまざまな場面で意思決定が必要になります。

PMBOK®︎では、ステークホルダーエンゲージメントやコミュニケーションマネジメントの中で、合意形成はプロジェクト成功のために欠かせない活動とされています。

合意形成が重要な理由

プロジェクトでは、正しい判断をすることだけでは十分ではありません。

関係者が決定内容を理解し、納得して行動できる状態を作ることが重要です。

例えば、次のようなケースがあります。

• 仕様変更を一部の関係者だけで決定してしまう
• スケジュール変更の理由が十分に共有されていない
• 役割分担について認識が一致していない

このような状態では、後から反対意見が出たり、作業の手戻りが発生したりする可能性があります。

そのため、プロジェクトでは意思決定だけでなく、合意形成のプロセスも重要になります。

合意形成の進め方

1. 関係者を明確にする

まず、誰の意見を確認する必要があるのかを整理します。

意思決定者だけでなく、影響を受ける関係者も把握することが重要です。

2. 情報を共有する

判断に必要な情報を関係者へ共有します。

情報量や認識に差があると、建設的な議論ができません。

3. 意見を整理する

賛成・反対だけではなく、それぞれの理由や懸念事項を整理します。

背景を理解することで、新しい解決策が見つかることもあります。

4. 意思決定を行う

議論を踏まえて、最終的な方針を決定します。

全員が完全に同じ意見になる必要はありませんが、決定内容を理解し、受け入れられる状態を目指します。

合意形成とネゴシエーションの違い

ネゴシエーションが合意形成の一部として行われることもありますが、合意形成はより広い概念です。

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

例えば、プロジェクト途中で顧客から新機能の追加要望があったとします。

プロジェクトマネージャは、開発チーム、顧客、スポンサーと話し合い、次のような点を整理します。

• 追加機能の必要性
• スケジュールへの影響
• 追加コストの有無
• 優先順位の変更が可能か

その結果、「一部機能は今回対応し、残りは次回リリースで対応する」という方針で関係者が合意しました。

このように、異なる立場の意見を調整しながら、プロジェクト全体として最適な方向を決めることが合意形成です。

よくある勘違い

全員が100％賛成する必要はない

合意形成は、多数決や全会一致とは異なります。

最終的な判断に全員が完全に賛成していなくても、決定理由を理解し、協力できる状態であれば合意形成は成立します。

時間をかければよいわけではない

議論を続けるだけでは、プロジェクトは前へ進みません。

必要な情報を整理したうえで、適切なタイミングで意思決定することもプロジェクトマネージャの重要な役割です。

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

IPAのプロジェクトマネージャ試験では、関係者との調整や意思決定のプロセスが頻繁に問われます。

午後試験では、次のような観点を説明できることが重要です。

• どのような関係者と調整したか
• 異なる意見をどのように整理したか
• 最終的な意思決定に至った理由
• 合意形成によって得られた効果

「承認を得た」だけではなく、「関係者の理解と納得を得ながら意思決定を進めた」と説明できることが評価につながります。

PM道場のワンポイント

合意形成とは、「全員を同じ意見にすること」ではなく、「全員が前を向いて行動できる状態を作ること」です。

プロジェクトでは、立場が違えば意見が違うのは当然です。

優れたプロジェクトマネージャは、誰かを説得することよりも、互いの考えを理解し、共通のゴールへ向かえる環境を作っています。

そのためには、十分なコミュニケーションとファシリテーション、そして適切なネゴシエーションが欠かせません。

関連用語

• ネゴシエーション
• ファシリテーション
• コミュニケーションマネジメント
• ステークホルダー
• ステークホルダーエンゲージメント
• 意思決定
• エスカレーション
• リーダーシップ

まとめ

合意形成とは、関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセスです。

重要なのは、全員を同じ意見にすることではなく、決定内容を理解し、協力して行動できる状態を作ることです。

プロジェクトマネージャにとって、合意形成はプロジェクトを円滑に進めるための重要なマネジメントスキルと言えるでしょう。

関連記事

• ネゴシエーションとは？
• ファシリテーションとは？
• コミュニケーションマネジメントとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？

よくある質問（FAQ）

Q. 合意形成とは何ですか？

A. 関係者が十分に話し合い、それぞれの立場を理解したうえで、プロジェクトとして進むべき方向を決定するプロセスです。

Q. 合意形成とネゴシエーションの違いは何ですか？

A. 合意形成は関係者全体の共通認識を作る活動であり、ネゴシエーションは利害が異なる相手と条件を調整する交渉活動です。

Q. 合意形成では全員が賛成する必要がありますか？

A. いいえ。全会一致である必要はありません。決定理由を理解し、協力して行動できる状態を作ることが重要です。

The post 合意形成とは？プロジェクトを円滑に進めるための意思決定プロセスを解説 first appeared on PM道場.

「限られた人員を複数のプロジェクトで取り合っている。」

プロジェクトでは、このように利害や意見が異なる場面が数多くあります。

そのような状況で、お互いが納得できる結論を導くために必要なのがネゴシエーション（Negotiation）です。

この記事では、ネゴシエーションの意味や目的、進め方、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ネゴシエーションとは、「利害や意見が異なる相手と話し合い、お互いが受け入れられる合意を目指す交渉活動」です。

ネゴシエーションとは

ネゴシエーションとは、相手と対立することではなく、双方にとって最適な解決策を見つけるための話し合いです。

プロジェクトでは、顧客、スポンサー、チームメンバー、他部署など、多くのステークホルダーと調整を行います。

PMBOK®︎でも、プロジェクトマネージャに必要な対人スキルの一つとして、ネゴシエーションが挙げられています。

プロジェクトマネージャは、自分の主張を押し通すのではなく、相手の立場や背景を理解しながら合意形成を進めることが求められます。

ネゴシエーションが重要な理由

プロジェクトでは、すべての関係者の要望をそのまま実現することはできません。

例えば、次のような場面があります。

• 納期を短縮してほしいという顧客の要望
• 予算を増やせないというスポンサーの判断
• 人員不足を訴える開発チーム
• 品質を優先したい品質保証部門

このような状況で一方的に要求を受け入れると、別の問題が発生します。

ネゴシエーションによって、それぞれの立場を理解しながら、現実的な解決策を見つけることが重要です。

ネゴシエーションの進め方

1. 相手の目的を理解する

まずは、自分の要求ではなく、相手が何を実現したいのかを理解します。

要求の背景を知ることで、新たな解決策が見つかることがあります。

2. 自分たちの制約を整理する

納期、コスト、品質、人員など、自分たちが譲れない条件を整理します。

何でも受け入れるのではなく、現実的な範囲を明確にしておくことが重要です。

3. 複数の選択肢を提示する

「できる・できない」の二択ではなく、複数の案を提示します。

例えば、

• 納期は変更しない代わりに機能を一部見直す
• 追加予算があれば短縮可能とする
• 優先順位を変更して段階的にリリースする

など、相手が選択できる余地を作ります。

4. 合意内容を明確にする

交渉がまとまったら、決定事項を文書化し、関係者全員で認識を合わせます。

曖昧なまま終わらせると、後から認識違いが発生する原因になります。

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

例えば、顧客から「予定より2週間早く納品してほしい」と依頼があったとします。

プロジェクトマネージャは、「できません」と断るのではなく、まず背景を確認します。

その結果、顧客はすべての機能ではなく、主要機能だけを先に利用したいことが分かりました。

そこで、主要機能を先行リリースし、残りは予定どおり開発する案を提案しました。

このように、相手の本当の目的を理解することで、お互いに納得できる解決策を見つけることができます。

よくある勘違い

ネゴシエーションは勝ち負けではない

交渉は相手に勝つことが目的ではありません。

双方が納得できる合意を目指すことが重要です。

譲歩することがネゴシエーションではない

相手の要求をすべて受け入れることは、良い交渉とは言えません。

プロジェクト全体の成功を考え、適切なバランスを取ることが重要です。

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

IPAのプロジェクトマネージャ試験では、関係者との調整や利害対立への対応が頻繁に出題されます。

午後試験では、次のような観点を説明できることが重要です。

• 相手の要求や背景をどのように把握したか
• どのような代替案を提示したか
• 双方が納得できる合意をどのように形成したか
• 交渉結果をどのようにプロジェクトへ反映したか

「要求を受け入れた」ではなく、「プロジェクト全体を考慮して最適な合意を形成した」と説明できることが評価につながります。

PM道場のワンポイント

ネゴシエーションで大切なのは、「自分の要求を通すこと」ではなく、「相手が本当に求めているものを理解すること」です。

プロジェクトでは、表面的な要求だけを見ると対立しているように見えることがあります。

しかし、その背景にある目的を理解すると、双方が納得できる解決策が見つかることも少なくありません。

優れたプロジェクトマネージャは、交渉を対立ではなく、価値を生み出すためのコミュニケーションと考えています。

関連用語

• ステークホルダー
• コミュニケーションマネジメント
• ファシリテーション
• エスカレーション
• 意思決定
• コンフリクトマネジメント
• リーダーシップ
• スポンサー

まとめ

ネゴシエーションとは、利害や意見が異なる相手と話し合い、お互いが納得できる合意を目指す交渉活動です。

重要なのは、自分の要求を押し通すことではなく、相手の目的や背景を理解し、複数の選択肢を提示しながら最適な解決策を見つけることです。

プロジェクトマネージャにとって、ネゴシエーションはプロジェクトを前進させるために欠かせないスキルと言えるでしょう。

関連記事

• コミュニケーションマネジメントとは？
• ファシリテーションとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？
• コンフリクトマネジメントとは？

よくある質問（FAQ）

Q. ネゴシエーションとは何ですか？

A. 利害や意見が異なる相手と話し合い、双方が受け入れられる合意を目指す交渉活動です。

Q. ネゴシエーションで最も重要なことは何ですか？

A. 相手の要求だけでなく、その背景にある目的や事情を理解し、お互いにとって最適な解決策を見つけることです。

Q. ファシリテーションとの違いは何ですか？

A. ファシリテーションは会議や議論を円滑に進める技術、ネゴシエーションは利害が異なる相手と合意形成を行うための交渉技術です。

The post ネゴシエーションとは？プロジェクトを前進させる交渉の考え方を解説 first appeared on PM道場.

「発言する人が限られ、結論が曖昧なまま会議が終わってしまう。」

プロジェクトでは、このような会議が少なくありません。

そこで重要になるのがファシリテーション（Facilitation）です。

ファシリテーションとは、会議や議論を円滑に進め、参加者全員が意見を出し合いながら、合意形成や意思決定へ導くための技術です。

この記事では、ファシリテーションの意味や目的、実践方法、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ファシリテーションとは、「参加者が建設的に議論し、納得感のある結論へ到達できるように会議を進行・支援する技術」です。

ファシリテーションとは

ファシリテーションとは、会議やワークショップなどで参加者同士のコミュニケーションを促進し、目的達成を支援する活動です。

プロジェクトマネージャは、自分の意見を押し通すのではなく、参加者から必要な情報や意見を引き出し、適切な意思決定ができる環境を作ることが求められます。

PMBOK®︎でも、ステークホルダーとの協働やコミュニケーションを円滑に進めるための重要なスキルとして位置付けられています。

ファシリテーションが重要な理由

プロジェクトでは、多様な立場や専門性を持つメンバーが参加します。

そのため、何も工夫せずに会議を進めると、次のような問題が発生します。

• 一部の人だけが発言する
• 議論が脱線する
• 結論が曖昧なまま終了する
• 決定事項や担当者が決まらない

ファシリテーションによって議論を整理し、参加者全員が目的を共有できるようにすることで、会議の質を高めることができます。

ファシリテーションで意識したいポイント

目的を最初に共有する

会議の冒頭で、「今日は何を決める会議なのか」を明確にします。

目的が曖昧なままでは、議論が脱線しやすくなります。

参加者全員が発言できる環境を作る

発言が偏らないように、意見が少ない参加者にも声を掛けます。

異なる立場の意見を引き出すことで、より良い意思決定につながります。

議論を整理する

話題が広がりすぎた場合は、論点を整理し、本来の目的へ戻します。

ホワイトボードや画面共有を活用し、議論を見える化することも効果的です。

結論とアクションを明確にする

会議の最後には、次の内容を確認します。

• 何が決まったか
• 誰が担当するか
• いつまでに実施するか

これにより、「話し合っただけ」で終わる会議を防ぐことができます。

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

例えば、システム開発プロジェクトで仕様変更について議論する会議を考えます。

営業部門は「顧客要望を優先したい」、開発チームは「納期への影響を抑えたい」と考えており、意見が対立しています。

ファシリテーターは、それぞれの意見を整理し、共通の目的を確認したうえで、実現可能な対応案を検討します。

このように、ファシリテーションは「誰が正しいか」を決めるのではなく、「どうすればプロジェクトにとって最適な結論になるか」を支援する役割を担います。

よくある勘違い

ファシリテーターは会議の主役ではない

ファシリテーターが多く話すことが良い会議ではありません。

参加者同士の対話を促し、必要な意見を引き出すことが役割です。

全員の意見を一致させることが目的ではない

全員が同じ考えになる必要はありません。

異なる意見を整理し、納得感のある意思決定へ導くことが重要です。

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

IPAのプロジェクトマネージャ試験では、会議運営や関係者調整、合意形成について問われることがあります。

午後試験では、次のような観点を説明できることが重要です。

• どのように議論を整理したか
• 対立する意見をどのように調整したか
• 参加者の理解をどのように促したか
• どのように合意形成へ導いたか

単に「会議を開催した」ではなく、「参加者全員が納得できる結論へ導いた」と説明できることが評価につながります。

PM道場のワンポイント

ファシリテーションとは、「上手に話す技術」ではなく、「参加者が話しやすい場を作る技術」です。

プロジェクトマネージャがすべての答えを持っている必要はありません。

むしろ、チームの知識や経験を引き出し、より良い結論へ導くことが重要です。

私は企業研修でも、「会議を成功させるのは、話す力ではなく、聞く力と整理する力です」とお伝えしています。

優れたプロジェクトマネージャは、自分が目立つのではなく、チームが成果を出せる環境を作っています。

関連用語

• コミュニケーションマネジメント
• キックオフミーティング
• ステークホルダー
• エスカレーション
• 意思決定
• レビュー
• ステークホルダーエンゲージメント
• リーダーシップ

まとめ

ファシリテーションとは、会議や議論を円滑に進め、参加者全員が納得できる結論へ導くための技術です。

重要なのは、自分が話すことではなく、参加者同士の対話を促し、議論を整理することです。

プロジェクトマネージャにとって、ファシリテーションはチームの力を最大限に引き出し、プロジェクトを成功へ導くための重要なスキルと言えるでしょう。

関連記事

• コミュニケーションマネジメントとは？
• キックオフミーティングとは？
• ステークホルダーとは？
• エスカレーションとは？
• リーダーシップとは？
• 意思決定とは？

よくある質問（FAQ）

Q. ファシリテーションとは何ですか？

A. 会議や議論を円滑に進め、参加者が建設的に意見を出し合い、納得感のある結論へ導くための技術です。

Q. ファシリテーターの役割は何ですか？

A. 議論を整理し、参加者全員が発言しやすい環境を作り、目的達成を支援することです。

Q. プロジェクトマネージャにファシリテーションスキルは必要ですか？

A. はい。プロジェクトでは関係者との合意形成や意思決定が不可欠であり、ファシリテーションはそのための重要なスキルです。

The post ファシリテーションとは？会議で合意形成を促進する進行技術を解説 first appeared on PM道場.

実は、キックオフミーティングは単なる説明会ではありません。

プロジェクト開始時に、チーム全員が同じ方向を向き、円滑にコミュニケーションできる環境を作るための重要な場です。

この記事では、キックオフミーティングの意味や目的、進め方、実務で意識したいポイントについて解説します。

一言でいうと

キックオフミーティングとは、「プロジェクト開始時に、目的・役割・進め方・コミュニケーション方法を共有し、チームの共通認識を作るための会議」です。

キックオフミーティングとは

キックオフミーティングとは、プロジェクト正式開始時に開催される最初の会議です。

プロジェクトの目的や背景、目標、体制、スケジュールを共有し、関係者全員が同じ方向を向いてスタートできる状態を作ります。

PMBOK®︎ではキックオフミーティングという名称のプロセスはありませんが、プロジェクト憲章やコミュニケーションマネジメント計画などを関係者へ共有し、共通認識を形成する重要な活動として位置付けられています。

キックオフミーティングが重要な理由

プロジェクト開始時に認識を合わせないまま作業を始めると、後から多くの問題が発生します。

例えば、次のようなケースがあります。

• プロジェクトの目的をメンバーごとに違って理解している
• 役割分担が曖昧で作業が重複する
• 報告方法が決まっておらず情報共有が漏れる
• 問題発生時のエスカレーション先が分からない

キックオフミーティングで最初にルールを共有することで、このようなトラブルを未然に防ぐことができます。

キックオフミーティングで共有する内容

一般的には、次のような内容を説明します。

重要なのは、一方的に説明することではなく、参加者全員が内容を理解し、疑問点を解消できることです。

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

例えば、新しいシステム開発プロジェクトが始まるとします。

キックオフミーティングでは、プロジェクト概要だけでなく、次のような内容も共有します。

• 毎朝の進捗確認方法
• 課題管理表の登録ルール
• リスクの報告方法
• エスカレーションの基準
• 成果物レビューの進め方

このように、プロジェクト開始時にコミュニケーションのルールを決めておくことで、その後の運営がスムーズになります。

よくある勘違い

キックオフミーティングは説明会ではない

資料を読み上げるだけでは、キックオフミーティングの目的は達成できません。

参加者がプロジェクトの目的や自分の役割を理解し、安心して動き始められる状態を作ることが重要です。

スケジュールだけを共有すればよいわけではない

スケジュールだけを説明しても、情報共有の方法や意思決定の流れが決まっていなければ、後から混乱が生じます。

コミュニケーション方法まで含めて設計することが重要です。

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

IPAのプロジェクトマネージャ試験では、プロジェクト開始時の体制づくりや関係者との合意形成が問われることがあります。

論文では、次のような観点を具体的に説明できることが重要です。

• どのような目的でキックオフミーティングを実施したか
• 何を共有したか
• コミュニケーションルールをどのように決めたか
• その結果、どのような効果が得られたか

単に「キックオフミーティングを開催した」ではなく、「プロジェクト運営の仕組みを設計した」と説明できることが評価につながります。

PM道場のワンポイント

キックオフミーティングは、説明会ではなく「最初のコミュニケーション設計」を行う場です。

プロジェクトマネージャは、最初からメンバー全員と良好な人間関係を築こうと頑張る必要はありません。

それよりも重要なのは、困ったときに誰へ相談するのか、どのように報告するのか、問題が起きたらどう動くのかというルールを最初に決めることです。

この仕組みがあることで、人見知りのプロジェクトマネージャでも安心してプロジェクトを運営できます。

優れたプロジェクトマネージャは、人に頼るのではなく、最初にコミュニケーションの仕組みを設計しています。

関連用語

• コミュニケーションマネジメント
• プロジェクト憲章
• ステークホルダー
• エスカレーション
• RACI
• プロジェクトマネージャ
• コミュニケーションマネジメント計画書
• ステークホルダーエンゲージメント

まとめ

キックオフミーティングとは、プロジェクト開始時に目的や役割だけでなく、コミュニケーションの進め方まで共有する重要な会議です。

プロジェクト成功のためには、説明資料を共有することではなく、チーム全員が同じルールで行動できる状態を作ることが重要です。

キックオフミーティングを「最初のコミュニケーション設計」と考えることで、その後のプロジェクト運営は大きく変わります。

関連記事

• コミュニケーションマネジメントとは？
• プロジェクト憲章とは？
• ステークホルダーとは？
• エスカレーションとは？
• RACIとは？
• プロジェクトマネージャとは？

よくある質問（FAQ）

Q. キックオフミーティングとは何ですか？

A. プロジェクト開始時に、目的・役割・進め方・コミュニケーション方法を共有し、チームの共通認識を作るための会議です。

Q. キックオフミーティングでは何を共有すればよいですか？

A. プロジェクトの目的、成果物、体制、スケジュール、役割、コミュニケーションルール、エスカレーション方法などを共有します。

Q. キックオフミーティングで最も重要なことは何ですか？

A. プロジェクトの説明だけではなく、情報共有や意思決定の仕組みを設計し、チーム全員が安心して動き始められる状態を作ることです。

The post キックオフミーティングとは？プロジェクト成功を左右する最初のコミュニケーション設計を解説 first appeared on PM道場.

プロジェクトでよく聞く言葉ですが、本当に重要なのはコミュニケーションの量ではありません。

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

この仕組みづくりをコミュニケーションマネジメント（Communications Management）と呼びます。

この記事では、コミュニケーションマネジメントの意味や目的、PMBOK®︎における考え方、実務で活用するポイントについて解説します。

一言でいうと

コミュニケーションマネジメントとは、「プロジェクトで必要な情報を、適切な相手へ、適切な方法・タイミングで届ける仕組みを設計・運用する活動」です。

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

コミュニケーションマネジメントとは、プロジェクトで必要となる情報の収集・作成・共有・保管・活用を計画し、実行・管理する活動です。

PMBOK®︎では、単に「会話を増やすこと」ではなく、情報共有の仕組みを設計することが重視されています。

例えば、次のようなことを決めます。

• 誰が誰へ情報を共有するのか
• 何を共有するのか
• いつ共有するのか
• どの手段で共有するのか
• 誰が承認するのか

これらを明確にすることで、情報共有漏れや認識のズレを防ぐことができます。

コミュニケーションマネジメントが重要な理由

プロジェクトの失敗原因として最も多いものの一つが、コミュニケーション不足ではなく、コミュニケーションの設計不足です。

例えば、次のような問題があります。

• 進捗報告の頻度が人によって異なる
• 重要な決定事項が一部のメンバーしか知らない
• 最新版ではない資料で作業してしまう
• 顧客への報告タイミングが遅れる

情報共有のルールが決まっていないと、小さな認識の違いが大きなトラブルにつながります。

そのため、プロジェクト開始時にコミュニケーションを設計しておくことが重要です。

PMBOK®︎におけるコミュニケーションマネジメント

PMBOK®︎では、コミュニケーションマネジメントは次のプロセスで構成されています。

計画・実行・改善を繰り返すことで、プロジェクト全体の情報共有品質を高めます。

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

コミュニケーションマネジメント計画書は、情報共有のルールをまとめた文書です。

一般的には次のような内容を記載します。

この計画書によって、「誰が何を共有するのか」が明確になります。

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

例えば、20名規模のシステム開発プロジェクトでは、毎日全員が自由に情報共有すると、必要な情報が埋もれてしまいます。

そこで、コミュニケーションマネジメントとして次のようなルールを決めます。

• 毎朝15分の進捗確認ミーティングを実施する
• 課題は課題管理表へ登録する
• リスクは週次会議で確認する
• 仕様変更はメールではなく変更管理会議で承認する
• スポンサーへは月次報告を実施する

このように情報共有を標準化することで、認識違いや伝達漏れを防ぐことができます。

よくある勘違い

コミュニケーション量を増やせばよいわけではない

会議やチャットを増やしても、必要な情報が適切な相手へ届かなければ意味がありません。

重要なのは、情報共有の目的と方法を設計することです。

コミュニケーション能力だけの問題ではない

「話すのが苦手だからPMに向いていない」と考える人もいます。

しかし、優れたプロジェクトマネージャに必要なのは話術ではありません。

情報共有の仕組みを設計する力です。

適切なルールや仕組みがあれば、個人のコミュニケーション能力に頼らなくても、プロジェクトは円滑に進められます。

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

IPAのプロジェクトマネージャ試験では、関係者との情報共有や調整方法が頻繁に問われます。

午後試験では、次の観点を具体的に説明できることが重要です。

• 誰へどのような情報を共有したか
• 共有方法を選択した理由
• 共有頻度をどのように決めたか
• 情報共有によってどのような効果があったか

単に「定例会議を実施した」と書くのではなく、「情報共有の仕組みを設計した」ことまで説明できると評価が高くなります。

PM道場のワンポイント

コミュニケーションマネジメントとは、「話し上手になること」ではなく、「情報共有を仕組み化すること」です。

私は企業研修でも、「PMに必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」とお伝えしています。

会議の目的、報告ルール、エスカレーション方法、情報共有ツールなどをあらかじめ決めておけば、チームは迷わず行動できます。

優れたプロジェクトマネージャは、人に頼るのではなく、仕組みによってコミュニケーションを円滑にしています。

関連用語

• コミュニケーションマネジメント計画書
• ステークホルダー
• エスカレーション
• キックオフミーティング
• 報告
• 課題（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道場.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし私は、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし、

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

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

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

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

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

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

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

すると、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PMBOK®には、

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

とは書かれていません。

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

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

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

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

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

おわりに

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

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

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

理由は簡単です。

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

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

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

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

あなたへの問いかけ

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

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

The post 人見知りのPMほどキックオフミーティングをやるべき理由 first appeared on PM道場.

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし私は、

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

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

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

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

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

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

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

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

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

という状況になります。

私は何度も、

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

と後悔しました。

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

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

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

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

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

しかし今は違います。

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

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

です。

自己紹介をする。

挨拶をする。

顔と名前を一致させる。

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

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

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

電話を掛けるときも、

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

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

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

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

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

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

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

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

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

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

以前は、

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

と考えていました。

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

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

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

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

キックオフを実施する。

定例会を設ける。

レビューの場を作る。

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

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

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

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

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

PMは、

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

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

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

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

報告する基準を決める。

定例会や1on1を設ける。

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

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

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

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

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

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

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

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

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

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

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

だと思っていました。

しかし、今は違います。

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

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

です。

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

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

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

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

おわりに

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

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

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

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

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

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

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

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

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

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

あなたへの問いかけ

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

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

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

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

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

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

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

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

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

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

The post PMに必要なのはコミュニケーション能力ではない。「コミュニケーションを設計する力」だった first appeared on PM道場.

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

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

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

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

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

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

例えば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PMの役割も変わる

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

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

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

つまり、

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

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

Pull型からPush型へ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

The post 「困ったら相談してください」では遅い。PMが設計すべきは「助けを求めるシグナル」だった first appeared on PM道場.