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

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

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

一言でいうと

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

合意形成とは

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

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

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

合意形成が重要な理由

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

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

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

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

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

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

合意形成の進め方

1. 関係者を明確にする

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

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

2. 情報を共有する

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

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

3. 意見を整理する

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

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

4. 意思決定を行う

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

関連用語

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

まとめ

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

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

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

関連記事

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

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

一言でいうと

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

ネゴシエーションとは

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例えば、

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

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

関連用語

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

まとめ

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

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

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

関連記事

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

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

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

一言でいうと

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

ファシリテーションとは

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

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

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

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

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

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

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

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

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

目的を最初に共有する

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

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

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

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

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

議論を整理する

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

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

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

関連用語

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

まとめ

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

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

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

関連記事

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

一言でいうと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

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

関連用語

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

まとめ

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

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

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

関連記事

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

よくある質問（FAQ）

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

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

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

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

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

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

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

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

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

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

一言でいうと

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

関連用語

• コミュニケーションマネジメント計画書
• ステークホルダー
• エスカレーション
• キックオフミーティング
• 報告
• 課題（Issue）
• リスク（Risk）
• ステークホルダーエンゲージメント

まとめ

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

プロジェクト成功の鍵は、コミュニケーション量ではなく、情報共有の質にあります。

情報共有を個人の能力に任せるのではなく、チーム全体が迷わず行動できる仕組みを作ることが、優れたプロジェクトマネージャの重要な役割です。

関連記事

• ステークホルダーとは？
• エスカレーションとは？
• キックオフミーティングとは？
• リスクマネジメントとは？
• 課題（Issue）とは？
• ステークホルダーエンゲージメントとは？

よくある質問（FAQ）

Q. コミュニケーションマネジメントとは何ですか？

A. プロジェクトで必要な情報を、適切な相手へ、適切な方法・タイミングで共有する仕組みを計画・運用する活動です。

Q. コミュニケーションマネジメント計画書には何を書きますか？

A. 共有する情報、共有先、共有頻度、共有方法、責任者など、情報共有のルールを記載します。

Q. コミュニケーション能力が高くないとプロジェクトマネージャは務まりませんか？

A. いいえ。重要なのは話術ではなく、情報共有を仕組みとして設計・運用する力です。

プロジェクトの現場では、このように問題を抱え込んでしまうケースがあります。

しかし、問題への対応が遅れるほど、プロジェクトへの影響は大きくなる可能性があります。

そこで重要になるのがエスカレーション（Escalation）です。

この記事では、エスカレーションの意味や目的、適切なタイミング、プロジェクトマネージャが実践すべきポイントについて解説します。

一言でいうと

エスカレーションとは、「自分や現在のチームだけでは解決できない問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動」です。

エスカレーションとは

エスカレーションとは、問題やリスク、判断が必要な事項を、上位者や関係する意思決定者へ引き上げることです。

プロジェクトでは、プロジェクトマネージャだけでは判断できない問題が発生することがあります。

例えば、

• 予算追加が必要になる
• 納期変更の判断が必要になる
• 組織間の調整が必要になる
• 重要なリスクが顕在化する

このような場合、適切なタイミングでエスカレーションを行うことで、迅速な意思決定につなげることができます。

エスカレーションが重要な理由

プロジェクトでは、問題そのものよりも「発見後の対応の遅れ」が大きな影響を与えることがあります。

例えば、以下のようなケースです。

• 小さな遅延を報告せず、後から重大な遅延になる
• 品質問題を抱え込み、リリース直前に発覚する
• 判断待ちの事項が放置され、作業が停止する

早い段階でエスカレーションすることで、選択できる対応策が増えます。

つまり、エスカレーションは「問題が大きくなってから助けを求める行為」ではなく、「問題を大きくしないための予防的な行動」です。

エスカレーションするべきタイミング

エスカレーションの判断で重要なのは、「解決策が決まってから報告する」のではなく、「問題だと認識した段階で共有する」ことです。

例えば、以下のような状況ではエスカレーションを検討します。

• プロジェクト目標へ影響する可能性がある
• 自分の権限では判断できない
• 複数チームに影響する
• 期限までに解決できない可能性がある
• 追加予算や人員が必要になる

エスカレーションで重要な報告内容

エスカレーションでは、単に「問題があります」と伝えるだけでは十分ではありません。

最低限、以下の内容を整理して共有します。

原因分析や対策案が完成していなくても、まず状況を共有することが重要です。

エスカレーションと報告の違い

エスカレーションは単なる報告ではなく、問題解決のために適切な人へ判断をつなぐ活動です。

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

例えば、システム開発プロジェクトで、重要な機能の開発が遅れる可能性が判明したとします。

プロジェクトマネージャが一人で原因分析や対策検討を続けると、対応が遅れる可能性があります。

そこで、以下のようにエスカレーションします。

• 現在判明している事実を共有する
• 納期影響の可能性を伝える
• 原因分析中であることを説明する
• 必要な支援や判断を依頼する

この段階では、完璧な解決策を提示する必要はありません。

重要なのは、問題を早期に共有し、組織として対応できる状態を作ることです。

よくある勘違い

エスカレーションは失敗報告ではない

エスカレーションを「問題を起こしたことを認める行為」と考えてしまうことがあります。

しかし、実際にはプロジェクトを成功させるためのマネジメント活動です。

原因分析が終わるまで待つ必要はない

原因分析や対策検討には時間がかかります。

その間に問題の影響が広がる可能性があります。

まず事実を共有し、その後詳細分析を進めることも重要な判断です。

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

IPAのプロジェクトマネージャ試験では、問題発生時の対応や関係者調整が重要なテーマになります。

論文では、以下のような観点が評価されます。

• 問題をどのタイミングで認識したか
• 誰へどのように共有したか
• 必要な判断や支援をどのように得たか
• その結果、プロジェクトをどう改善したか

優れたPMは、問題を隠すのではなく、適切なタイミングで組織の力を活用します。

PM道場のワンポイント

エスカレーションで大切なのは、「解決してから報告する」ことではなく、「問題だと思った時点で共有する」ことです。

プロジェクトマネージャは、すべての問題を一人で解決する役割ではありません。

必要な人へ情報を届け、適切な判断を引き出すことも重要な役割です。

特に、コミュニケーションが苦手なPMほど、「原因を整理してから伝えなければならない」と考えがちです。

しかし、早期共有によって、より多くの選択肢を持って対応できます。

優れたプロジェクトマネージャは、エスカレーションによって問題解決のスピードを高めています。

関連用語

• リスク（Risk）
• 課題（Issue）
• 問題管理
• 意思決定
• ステークホルダー
• コミュニケーションマネジメント
• 報告
• プロジェクトスポンサー

まとめ

エスカレーションとは、自分やチームだけでは解決できない問題や判断事項を、適切な相手へ共有し、支援や判断を得る活動です。

重要なのは、問題が大きくなってから行うのではなく、影響が広がる前に実施することです。

プロジェクトマネージャに求められるのは、すべての問題を一人で解決する力ではありません。

組織の力を活用し、プロジェクトを成功へ導くための判断を行う力です。

関連記事

• リスク（Risk）とは？
• 課題（Issue）とは？
• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• プロジェクトスポンサーとは？

よくある質問（FAQ）

Q. エスカレーションとは何ですか？

A. 解決が難しい問題や判断事項を、適切な権限を持つ人へ共有し、支援や判断を求める活動です。

Q. エスカレーションはいつ行うべきですか？

A. 問題の影響が広がる可能性があると判断した時点で、早めに実施することが重要です。

Q. 原因分析や対策案がなくてもエスカレーションしてよいですか？

A. はい。まず事実や影響を共有し、必要な支援を得ることが重要です。

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

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

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

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

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

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

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

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

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

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

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

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

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

私もそうでした。

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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