「顧客と開発チームの要求が対立している」

「A社とB社で責任の押し付け合いになっている」

プロジェクトを進めていると、このような対立が発生することがあります。

プロジェクトには、さまざまな立場や考え方を持った人が関わります。

そのため、意見や利害が完全に一致することはありません。

そこで重要になるのがコンフリクトマネジメントです。

コンフリクトマネジメントは、単純に「喧嘩を仲裁すること」ではありません。

対立している人たちの意見や背景を理解し、問題の原因を整理しながら、プロジェクトにとって適切な解決策を見つけていく活動です。

一言でいうと

コンフリクトマネジメントとは、プロジェクト内で発生する意見や利害の対立を適切に管理し、プロジェクトの成果につなげることです。

簡単に言えば、

「対立を放置せず、適切に扱って、より良い方向に導くこと」

です。

ここで重要なのは、コンフリクト＝悪いものとは限らないということです。

異なる意見がぶつかることで、それまで気づかなかった問題が見つかったり、より良いアイデアが生まれたりすることもあります。

そのため、PMには「対立をなくす」のではなく、対立を適切にマネジメントする力が求められます。

コンフリクトが起こる原因

プロジェクトでコンフリクトが起こる原因はさまざまです。

代表的なものとして、次のようなものがあります。

• プロジェクトの優先順位に対する認識の違い
• スケジュールに対する意見の違い
• リソースの取り合い
• 予算に対する考え方の違い
• 要求事項に対する認識の違い
• 役割や責任範囲の曖昧さ
• 技術的な意見の違い
• コミュニケーション不足
• 組織間の利害関係
• 個人の価値観や考え方の違い

例えば、顧客は「機能を増やしたい」と考えている一方、開発チームは「納期を守るためには機能を減らしたい」と考えているとします。

どちらも自分たちの立場から見ると正しい意見です。

このような場合、単純に「どちらが正しいか」を決めようとすると対立が激しくなる可能性があります。

そこで、プロジェクト全体の目的や制約を踏まえて、双方が納得できる解決策を探します。

コンフリクトは悪いものなのか？

コンフリクトという言葉には、どうしても「悪いもの」というイメージがあります。

しかし、すべてのコンフリクトが悪いわけではありません。

例えば、プロジェクトの設計方法について、2人のエンジニアが異なる意見を持っていたとします。

お互いが根拠を示して議論することで、両方の案よりも優れた第三の案が見つかるかもしれません。

このような建設的な対立は、プロジェクトにとってプラスになることがあります。

一方で、個人攻撃や感情的な対立に発展してしまうと、チームワークを壊し、プロジェクトに悪影響を与えます。

そのためPMには、

「対立をなくす」のではなく、「建設的な議論に変える」

という視点が重要です。

コンフリクトマネジメントの基本的な流れ

コンフリクトが発生した場合、まず感情的に解決しようとするのではなく、状況を整理することが重要です。

基本的には、次のような流れで考えるとよいでしょう。

1. コンフリクトの存在を把握する
2. 対立している論点を整理する
3. それぞれの意見や背景を確認する
4. プロジェクトの目的や制約を確認する
5. 解決策を検討する
6. 必要に応じて意思決定する
7. 合意した内容を共有する
8. その後の状況を確認する

特に重要なのは、「何について対立しているのか」を明確にすることです。

人間関係の問題に見えても、実際には役割分担が曖昧だったり、プロジェクトの優先順位が共有されていなかったりすることがあります。

まず「人」と「問題」を分ける

コンフリクトマネジメントで重要な考え方の一つが、人と問題を分けることです。

例えば、

「あの人はいつも無理な要求をしてくる」

と考えてしまうと、相手そのものを問題視してしまいます。

しかし、実際に解決すべきなのは、

「なぜその要求が必要なのか」

「プロジェクトのどの制約と衝突しているのか」

という問題かもしれません。

相手を責めるのではなく、何が問題なのかを切り分けることが重要です。

相手の立場を理解する

対立しているときは、自分の意見を理解してもらうことばかり考えてしまいがちです。

しかし、コンフリクトを解決するためには、まず相手がなぜその意見を持っているのかを理解することが重要です。

例えば、顧客が追加機能を要求している場合、単純に「要求が多い」と考えるのではなく、

「なぜその機能が必要なのか？」

を確認します。

もしかすると、その機能がないと業務上の重要な問題が解決できないのかもしれません。

背景を理解することで、別の解決策が見つかる可能性があります。

コンフリクトへの代表的な対応方法

コンフリクトへの対応には、さまざまな方法があります。

代表的な考え方として、次のようなものがあります。

協力・問題解決

双方の意見や要求を確認し、根本的な問題を解決する方法です。

「どちらが勝つか」ではなく、双方が納得できる解決策を探します。

例えば、納期と機能追加が対立している場合、機能を優先順位付けし、一部の機能を次のリリースに回すといった方法があります。

プロジェクトマネジメントでは、特に重要なアプローチです。

妥協

双方がある程度譲歩して、現実的な解決策を見つける方法です。

例えば、AチームとBチームが同じリソースを必要としている場合、それぞれが利用できる時間を分けるといった方法があります。

完全な解決ではなくても、双方が受け入れられるポイントを探します。

受容・適応

相手の要求を受け入れることで、コンフリクトを収束させる方法です。

プロジェクトへの影響が小さく、相手の要求を受け入れることが合理的な場合などに有効です。

回避

すぐに解決しようとせず、いったん距離を置いたり、問題を後回しにしたりする方法です。

例えば、感情的になっている状態で話し合いを続けても解決が難しい場合、いったん時間を置いてから再度話し合うことがあります。

ただし、単純に問題を放置することとは違います。

「今は解決するタイミングではない」と判断して戦略的に保留することが重要です。

強制・指示

PMなどの責任者が意思決定し、一方の案を採用する方法です。

緊急性が高く、すぐに意思決定しなければプロジェクトに大きな影響が出る場合などには必要になることがあります。

ただし、常にこの方法を使っていると、メンバーの納得感や主体性が低下する可能性があります。

どの方法を使えばよいのか？

重要なのは、「どの方法が一番優れている」と決めつけないことです。

状況によって適切な方法は変わります。

PMは、状況に応じて適切な方法を選択する必要があります。

コンフリクトマネジメントで重要なコミュニケーション

コンフリクトを解決するうえで、コミュニケーションは非常に重要です。

特に意識したいのが、相手の意見を否定する前に、相手の話を聞くことです。

例えば、

「それは無理です」

と最初から否定するのではなく、

「なぜその機能が必要なのか教えてください」

と質問してみます。

相手の背景を理解することで、対立しているように見えた意見が、実は同じ目的を目指していることに気づく場合があります。

コンフリクトマネジメントと合意形成

コンフリクトマネジメントと合意形成は密接に関係しています。

コンフリクトを解決するためには、最終的に関係者が納得できる方向性を決める必要があるからです。

ただし、合意形成とは「全員の意見を完全に一致させること」ではありません。

意見が異なっていても、

「この方針で進めることに納得する」

という状態を作ることが重要です。

そのため、PMにはコンフリクトマネジメントだけでなく、合意形成や意思決定のスキルも求められます。

コンフリクトマネジメントとファシリテーション

ファシリテーションも、コンフリクトマネジメントに役立つスキルです。

ファシリテーションとは、会議や議論を円滑に進め、参加者から意見を引き出しながら、議論を整理していくことです。

意見が対立している会議では、PMが一方の意見に肩入れするのではなく、

• 論点を整理する
• 双方の意見を確認する
• 共通している部分を見つける
• 相違点を明確にする
• 判断基準を整理する

ことで、建設的な議論に変えていくことができます。

コンフリクトマネジメントでよくある失敗

対立を避け続ける

「揉めたくない」という理由で対立を避け続けると、問題が大きくなることがあります。

小さな認識違いの段階で話し合っておけば解決できた問題が、後になって大きな問題になることもあります。

対立そのものを恐れるのではなく、必要な議論として向き合うことが重要です。

どちらが正しいかを決めようとする

コンフリクトでは、必ずしも「Aが正しい」「Bが間違っている」と決められるとは限りません。

双方に合理的な理由がある場合もあります。

そのため、個人の正しさを競うのではなく、プロジェクトの目的にとって何が最適かという視点で考えることが重要です。

感情的に対応する

対立が激しくなると、相手の言い方や態度に反応してしまうことがあります。

しかし、PMが感情的になると、さらに対立が激しくなる可能性があります。

事実と意見を分け、論点を整理して冷静に対応することが重要です。

表面的な問題だけを解決する

「とりあえず今回はA案で進めましょう」と決めても、根本原因が残っていれば、同じコンフリクトが再び発生する可能性があります。

なぜ対立が起きたのか、その背景まで確認することが重要です。

プロジェクトマネージャにとってのコンフリクトマネジメント

PMは、プロジェクトの中でさまざまな立場の人をつなぐ役割を担います。

そのため、コンフリクトが起きること自体は珍しいことではありません。

むしろ、

「コンフリクトが起こらないチーム」よりも、「コンフリクトが起きても建設的に解決できるチーム」

のほうが強いチームだと考えることもできます。

PMがすべての対立を自分で解決する必要もありません。

メンバー同士で解決できるのであれば、PMは必要以上に介入せず、必要なときに支援することも重要です。

一方、対立がプロジェクト全体に影響する場合には、PMが介入して論点を整理し、意思決定や合意形成を支援する必要があります。

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

コンフリクトマネジメントを学ぶときは、次の用語と関連付けて整理しておくとよいでしょう。

• リーダーシップ
• サーバントリーダーシップ
• コミュニケーションマネジメント
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• ステークホルダーエンゲージメント
• チームマネジメント
• チームビルディング

特に重要なのは、「対立を避けること」と「コンフリクトをマネジメントすること」は違うという点です。

意見の違いを適切に扱い、プロジェクトにとってより良い結果につなげることがコンフリクトマネジメントです。

PM道場のワンポイント

コンフリクトは、必ずしも悪いものではありません。

PMをしていると、意見の対立が起きるたびに、

「どうやって揉めないようにしようか」

と考えてしまうことがあります。

しかし、プロジェクトにはさまざまな専門家が参加しています。

全員が同じ意見になるほうが、むしろ不自然です。

重要なのは、意見の違いをなくすことではありません。

「なぜその意見なのか」をお互いに理解し、プロジェクトの目的に照らして最適な答えを探すことです。

私自身、PMとして仕事をする中で、意見が対立することは何度もありました。

そのときに意識したいのは、相手を説得することよりも、まず相手の背景を理解することです。

「なぜこの人はこの意見を持っているのか？」

と考えてみると、実は自分と目指しているものは同じで、重視しているポイントが違うだけということがあります。

そうであれば、「どちらが正しいか」を争う必要はありません。

お互いが大切にしているものを整理して、プロジェクトとしての最適解を探せばよいのです。

コンフリクトマネジメントは、対立を消すためのスキルではありません。

対立を、より良い意思決定につなげるためのPMの重要なスキルだと考えると、実務でも活用しやすくなります。

関連用語

• リーダーシップ
• サーバントリーダーシップ
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• コミュニケーションマネジメント
• ステークホルダーエンゲージメント
• チームマネジメント
• チームビルディング

まとめ

コンフリクトマネジメントとは、プロジェクト内で発生する意見や利害の対立を適切に管理し、プロジェクトの成果につなげることです。

プロジェクトでは、立場や専門性の違いから、さまざまなコンフリクトが発生します。

そのため、PMには、

• 対立している論点を整理する
• 相手の意見や背景を理解する
• プロジェクトの目的や制約を確認する
• 解決策を検討する
• 必要に応じて意思決定する
• 関係者の合意形成を支援する

といった対応が求められます。

また、コンフリクトは必ずしも悪いものではありません。

異なる意見をぶつけ合うことで、より良いアイデアや意思決定につながることもあります。

重要なのは、「対立をなくす」のではなく、「建設的な対立にする」ことです。

PMにとってコンフリクトマネジメントは、プロジェクトを円滑に進めるためだけではなく、異なる意見をプロジェクトの力に変えるための重要なスキルと言えるでしょう。

関連記事

• リーダーシップとは？
• サーバントリーダーシップとは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？
• 意思決定とは？
• コミュニケーションマネジメントとは？
• ステークホルダーエンゲージメントとは？
• チームマネジメントとは？

よくある質問（FAQ）

Q. コンフリクトマネジメントとは何ですか？

A. プロジェクト内で発生する意見や利害の対立を適切に管理し、プロジェクトの成果につなげることです。対立を単純になくすのではなく、建設的な議論に変えることが重要です。

Q. コンフリクトは悪いものですか？

A. 必ずしも悪いものではありません。異なる意見を議論することで、問題が明らかになったり、より良い解決策が生まれたりすることがあります。重要なのは、対立を適切にマネジメントすることです。

Q. コンフリクトが起きたらPMがすぐに仲裁すべきですか？

A. 必ずしもそうではありません。メンバー同士で解決できるのであれば、PMは必要以上に介入せず支援する方法もあります。一方、プロジェクト全体に影響する場合や、当事者だけでは解決できない場合には、PMが介入する必要があります。

Q. コンフリクトへの対応方法にはどのようなものがありますか？

A. 代表的な方法として、協力・問題解決、妥協、受容・適応、回避、強制・指示などがあります。どの方法が適切かは、問題の重要度、緊急度、関係者との関係性などによって変わります。

Q. コンフリクトマネジメントとネゴシエーションの違いは何ですか？

A. コンフリクトマネジメントは、プロジェクト内の対立を適切に管理するための幅広い活動です。ネゴシエーションは、その中で関係者が条件や意見を調整し、合意を目指すための具体的なコミュニケーション手法の一つです。

Q. コンフリクトマネジメントと合意形成は関係ありますか？

A. はい。対立を解決するためには、最終的に関係者が一定の方向性に納得して進める必要があるため、合意形成と密接に関係しています。

The post コンフリクトマネジメントとは？PMが知っておきたい対立の解決方法 first appeared on PM道場.

プロジェクトマネジメントについて学んでいると、このような言葉をよく耳にします。

しかし、リーダーシップとは具体的に何をすればよいのでしょうか。

「チームを引っ張ること」と考える人もいるかもしれません。

もちろん、それもリーダーシップの一つです。

一方で、プロジェクトでは、PMが常に先頭に立って指示を出すだけではうまくいかないこともあります。

メンバーの意見を引き出したり、障害を取り除いたり、メンバーが力を発揮できる環境を作ったりすることも、重要なリーダーシップです。

この記事では、プロジェクトマネジメントにおけるリーダーシップについて解説し、近年注目されているサーバントリーダーシップについても紹介します。

一言でいうと

リーダーシップとは、目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。

PMの仕事に置き換えると、

「プロジェクトの目的を示し、メンバーが同じ方向を向いて成果を出せるように導くこと」

と考えると分かりやすいでしょう。

ここで重要なのは、リーダーシップは「命令すること」ではないという点です。

メンバーに指示を出すことだけではなく、目的を共有し、信頼関係を築き、必要な支援を行いながら、チームとして成果を出せる状態を作ることもリーダーシップです。

リーダーシップの目的

リーダーシップの目的は、個人ではなくチームとして目標を達成することです。

プロジェクトでは、一人のPMだけで成果を出すことはできません。

開発、設計、営業、品質管理、顧客、ベンダーなど、さまざまな人が関わります。

そのため、PMには、異なる立場や専門性を持つ人たちを同じ目的に向けていくことが求められます。

PMにリーダーシップが必要な理由

プロジェクトには、通常の業務とは異なる特徴があります。

• 関係者が多い
• 目標や成果物が明確でない場合がある
• スケジュールに制約がある
• 予算に制約がある
• 問題やリスクが発生する
• メンバーがプロジェクト専任とは限らない
• 組織や会社をまたいで活動することがある

このような環境では、単純に「この作業をしてください」と指示するだけでは、チームを動かすことが難しい場合があります。

そこで重要になるのがリーダーシップです。

PMは、

「このプロジェクトは何を目指しているのか」

「なぜこのプロジェクトを行うのか」

を明確にし、メンバーが目的を理解して行動できる状態を作る必要があります。

PMに求められるリーダーシップ

プロジェクトマネージャに求められるリーダーシップには、さまざまな形があります。

方向性を示す

まず重要なのが、プロジェクトの方向性を示すことです。

プロジェクトでは、問題が発生したり、意見が対立したりすることがあります。

そのようなときに、PMが、

「このプロジェクトでは何を実現したいのか」

という軸を示すことで、チームが判断しやすくなります。

メンバーを動機づける

メンバーが「やらされている」と感じている状態では、高いパフォーマンスを発揮することは難しくなります。

そのため、プロジェクトの目的や仕事の意味を伝え、メンバーが主体的に動けるようにすることも重要です。

意思決定する

プロジェクトでは、すべての人の意見が一致するとは限りません。

意見が対立した場合には、PMが判断しなければならないこともあります。

必要な情報を集め、関係者の意見を聞いたうえで、プロジェクトとしての意思決定を行うこともリーダーシップです。

チームを支援する

PM自身がすべての作業を行うのではなく、メンバーが仕事を進められるように支援することも重要です。

例えば、

• 他部署との調整を行う
• 必要な情報を集める
• 意思決定を支援する
• 障害を取り除く
• 必要なリソースを確保する

といった活動があります。

リーダーシップとマネジメントの違い

リーダーシップとマネジメントは、似た言葉として使われることがあります。

しかし、完全に同じものではありません。

ただし、PMにとってはどちらか一方だけが必要なのではありません。

リーダーシップとマネジメントの両方が重要です。

例えば、

「プロジェクトを成功させるために何を目指すのか」を示すのがリーダーシップ。

「その目標を達成するために、どのような計画で進めるのか」を管理するのがマネジメント。

というように考えると分かりやすいでしょう。

サーバントリーダーシップとは？

サーバントリーダーシップとは、リーダーがメンバーを支援することを重視するリーダーシップの考え方です。

「サーバント（servant）」には「奉仕する人」という意味があります。

一般的なリーダー像では、

「リーダーが指示を出し、メンバーがそれに従う」

というイメージがあります。

一方、サーバントリーダーシップでは、

「メンバーが力を発揮できるように、リーダーが支援する」

という考え方を重視します。

例えば、PMがすべての問題を自分で解決するのではなく、メンバーが問題を解決できるように、必要な情報や環境を整えたり、障害を取り除いたりします。

サーバントリーダーシップの特徴

サーバントリーダーシップでは、次のような考え方が重要になります。

• メンバーの話をよく聞く
• メンバーの成長を支援する
• メンバーが働きやすい環境を作る
• チームの障害を取り除く
• 信頼関係を築く
• メンバーの自主性を尊重する
• チームとして成果を出すことを重視する

つまり、リーダー自身が目立つことよりも、チームが成果を出せる状態を作ることを重視します。

アジャイルとサーバントリーダーシップ

サーバントリーダーシップは、特にアジャイルやスクラムとの関連で語られることがあります。

スクラムマスターは、チームがスクラムを適切に実践できるよう支援し、チームが自律的に活動できる環境を整える役割を担います。

そのため、スクラムマスターの役割を理解するうえで、サーバントリーダーシップの考え方は参考になります。

例えば、チームで問題が発生したときに、スクラムマスターがすべての問題を解決するのではなく、

「チーム自身が問題を解決できるように支援する」

という考え方です。

これは、メンバーの自律性を高めることにもつながります。

サーバントリーダーシップは「何でもメンバーに任せる」ことではない

サーバントリーダーシップについて、

「メンバーに自由にやらせること」

と誤解することがあります。

しかし、単に何でも任せることとは違います。

リーダーは、必要な場面では方向性を示し、意思決定を行い、チームを支援する必要があります。

例えば、チーム内で解決できない問題が発生した場合、PMが「皆さんで何とかしてください」と放置するのはサーバントリーダーシップではありません。

PM自身が上位組織や他部署と調整し、チームが問題を解決できる環境を作ることが、サーバントリーダーシップにつながります。

つまり、

「任せる」のではなく「任せられるように支援する」

という考え方が重要です。

リーダーシップのスタイルは一つではない

リーダーシップには、さまざまなスタイルがあります。

例えば、

• 指示型
• 参加型
• 支援型
• コーチング型
• サーバントリーダーシップ

などがあります。

どのスタイルが常に正しいというわけではありません。

プロジェクトの状況、チームの成熟度、メンバーの経験、緊急度などによって、適切なリーダーシップは変わります。

例えば、重大な障害が発生し、今すぐ判断が必要な状況では、PMが明確に方向性を示す必要があります。

一方、経験豊富なメンバーが自律的に活動できている場合は、細かく指示するよりも、メンバーを支援するほうが効果的かもしれません。

状況に応じてリーダーシップのスタイルを使い分けることが重要です。

PMのリーダーシップで重要なコミュニケーション

リーダーシップを発揮するうえで、コミュニケーションは欠かせません。

特にPMは、

• プロジェクトの目的を伝える
• メンバーの意見を聞く
• 問題を共有する
• 意思決定の理由を説明する
• 関係者の認識を合わせる

といったコミュニケーションを行います。

「自分の考えを伝える」だけではなく、「相手の考えを理解する」ことも重要です。

特にサーバントリーダーシップでは、メンバーの声を聞くことが重要になります。

リーダーシップでよくある失敗

PMがすべての判断をする

PMがすべての判断を行ってしまうと、メンバーが自分で考えなくなってしまう可能性があります。

もちろん重要な意思決定はPMが行う必要がありますが、メンバーが判断できることまでPMが決める必要はありません。

可能な範囲でメンバーに判断を委ねることも重要です。

指示を出すことがリーダーシップだと考える

「これをやってください」と指示を出すだけでは、メンバーの主体性を引き出すことは難しい場合があります。

なぜその作業が必要なのか、プロジェクトとして何を目指しているのかを共有することが重要です。

メンバーに任せすぎる

逆に、「自主性を尊重する」という理由で、PMが何も関与しなくなることも問題です。

必要な場面では、PMが方向性を示したり、障害を取り除いたりする必要があります。

自分が一番頑張ればよいと考える

PMが誰よりも多くの仕事を抱えることが、良いリーダーシップとは限りません。

PM自身が頑張るよりも、チーム全体が力を発揮できる状態を作ることが重要です。

プロジェクトマネージャにとってのリーダーシップ

PMにとってのリーダーシップは、「メンバーの先頭に立って引っ張ること」だけではありません。

時には先頭に立ち、時には後ろから支え、時にはメンバーに考えてもらう。

プロジェクトの状況に応じて、役割を変えることが重要です。

例えば、プロジェクトの立ち上げ時には、PMがプロジェクトの目的や方向性を明確に示す必要があります。

一方で、チームが成熟してくれば、メンバーが主体的に判断できるように権限を渡していくことも重要になります。

このように、「自分がチームを動かす」のではなく、「チームが自律的に動ける状態を作る」という視点を持つことが、PMのリーダーシップを考えるうえで重要です。

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

リーダーシップについて学ぶときは、次の用語と関連付けて整理しておくとよいでしょう。

• サーバントリーダーシップ
• チームマネジメント
• チームビルディング
• コミュニケーション
• 動機づけ
• コンフリクトマネジメント
• 意思決定
• 合意形成
• ファシリテーション
• ステークホルダーエンゲージメント
• スクラムマスター
• アジャイル

特に、「指示するリーダー」と「支援するリーダー」の違いを理解しておくと、リーダーシップに関する問題を考えやすくなります。

PM道場のワンポイント

強いPMとは、自分が一番頑張るPMではなく、チームが力を発揮できる環境を作れるPMです。

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

「自分が判断しなければ」

「自分が解決しなければ」

と考えてしまうことがあります。

しかし、プロジェクトが大きくなればなるほど、PM一人ですべてを判断することはできません。

そこで重要になるのが、メンバーを信頼して任せることです。

ただし、単純に仕事を丸投げするのではありません。

「メンバーが自分で判断し、行動できるように必要な支援をする」

という考え方が重要です。

これが、サーバントリーダーシップの考え方にもつながります。

PMの役割は、必ずしも「一番前でチームを引っ張る人」ではありません。

プロジェクトの目的を示し、メンバーが力を発揮できる環境を作り、必要なときにはチームを支える。

そんなリーダーシップも、PMにとって非常に重要だと私は考えています。

関連用語

• サーバントリーダーシップ
• チームマネジメント
• チームビルディング
• コミュニケーションマネジメント
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• コンフリクトマネジメント
• ステークホルダーエンゲージメント
• スクラムマスター
• アジャイル

まとめ

リーダーシップとは、目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。

PMにとってのリーダーシップは、単純にメンバーへ指示を出すことではありません。

• プロジェクトの方向性を示す
• メンバーを動機づける
• 意思決定する
• メンバーの意見を聞く
• チームの障害を取り除く
• メンバーが力を発揮できる環境を作る

といったさまざまな活動が含まれます。

その中でも、サーバントリーダーシップは、リーダーがメンバーを支援し、メンバーが主体的に活動できる環境を作るという考え方です。

重要なのは、「メンバーに何をさせるか」ではなく、

「メンバーがどうすれば力を発揮できるか」

という視点を持つことです。

プロジェクトの状況によって、強く方向性を示すことが必要な場合もあれば、メンバーに任せて支援することが必要な場合もあります。

その状況に応じてリーダーシップのスタイルを使い分けることが、PMにとって重要なスキルです。

関連記事

• サーバントリーダーシップとは？
• チームマネジメントとは？
• チームビルディングとは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？
• 意思決定とは？
• ステークホルダーエンゲージメントとは？
• スクラムマスターとは？

よくある質問（FAQ）

Q. リーダーシップとは何ですか？

A. 目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。PMの場合は、プロジェクトの目的を共有し、チームとして成果を出せる状態を作ることが重要です。

Q. PMにリーダーシップは必要ですか？

A. 必要です。プロジェクトでは多くの関係者が関わるため、PMには方向性を示し、関係者をまとめ、必要な意思決定を行うことが求められます。

Q. リーダーシップとマネジメントの違いは何ですか？

A. リーダーシップは方向性を示し、人やチームを目標に向けて動かすことに重点があります。一方、マネジメントは計画、進捗、コスト、品質、リスクなどを管理し、目標達成に向けてプロジェクトを運営することに重点があります。PMには両方が必要です。

Q. サーバントリーダーシップとは何ですか？

A. リーダーがメンバーを支援し、メンバーが力を発揮できる環境を作ることを重視するリーダーシップの考え方です。メンバーの話を聞き、障害を取り除き、成長や自律的な活動を支援します。

Q. サーバントリーダーシップはメンバーにすべて任せることですか？

A. いいえ。何でも任せることではありません。メンバーが主体的に活動できるよう支援しながら、必要な場面ではリーダーが方向性を示したり、意思決定したりすることも重要です。

Q. サーバントリーダーシップはスクラムと関係がありますか？

A. はい。スクラムマスターの役割を理解するうえで、サーバントリーダーシップの考え方は参考になります。スクラムマスターは、チームが自律的に活動できるよう支援し、障害を取り除く役割を担います。

Q. PMは常にメンバーを引っ張る必要がありますか？

A. 必ずしもそうではありません。プロジェクトの状況やチームの成熟度によって、方向性を強く示すことが必要な場合もあれば、メンバーに権限を渡して支援するほうが効果的な場合もあります。状況に応じてリーダーシップのスタイルを使い分けることが重要です。

The post リーダーシップとは？PMに求められるリーダーシップとサーバントリーダーシップ first appeared on PM道場.

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

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

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

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

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

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

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

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

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

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

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

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

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

私もそうでした。

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

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

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

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

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

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

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

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

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

これだけです。

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

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

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

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

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

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

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

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

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

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

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

以前

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

現在

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

私はまず、

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

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

それだけで、相手は

「報告して良かった。」

と思えます。

逆に、

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

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

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

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

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

と思ってしまうのです。

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

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

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

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

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

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

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

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

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

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

おわりに

新人の頃の私は、

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

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

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

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

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

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

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

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

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

あなたへの問いかけ

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

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

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

The post 人見知りのPMが問題を抱え込まないためのエスカレーション設計 first appeared on PM道場.

そんなときに役立つのが「OBS（Organization Breakdown Structure）」です。

OBSは、プロジェクトに関わる組織や担当部署を整理し、作業と責任の関係を明確にするための重要なツールです。

この記事では、OBSの意味や目的、WBSとの違い、実務での活用方法までわかりやすく解説します。

一言でいうと

OBS（Organization Breakdown Structure）とは、「プロジェクトに関わる組織や担当者を階層的に整理した組織構成図」のことです。

OBSとは

OBSは「Organization Breakdown Structure」の略で、日本語では「組織分解構成図」と呼ばれます。

プロジェクトに関わる部門やチーム、担当者を階層的に整理し、「誰が何を担当するのか」を明確にするために利用されます。

WBSが「仕事」を分解するのに対し、OBSは「組織・人」を整理するものです。

なぜOBSが必要なのか

WBSだけでは、「何をやるか」は整理できますが、「誰がやるか」は分かりません。

その結果、担当が曖昧になったり、複数の部署が「相手がやると思っていた」という状況が発生したりします。

OBSを作成することで、責任範囲を明確にし、役割の重複や漏れを防ぐことができます。

OBSのイメージ

例えば、システム開発プロジェクトでは、次のように整理します。

• プロジェクトマネージャ
  • 要件定義チーム
  • 設計チーム
  • 開発チーム
  • テストチーム
• 品質保証部門
• 運用部門
• 顧客担当部門

このように、プロジェクトに関わる組織全体を見える化します。

WBSとの違い

つまり、WBSは「何をやるか」、OBSは「誰がやるか」を整理するものです。

WBSとOBSを組み合わせる

実務では、WBSとOBSを組み合わせて利用することが一般的です。

例えば、WBSの各作業に対してOBSの担当部署を割り当てることで、「どの部署が責任を持つのか」が一目で分かります。

さらに、この関係を表形式で整理したものが責任割当マトリックス（RAM：Responsibility Assignment Matrix）です。

RAMでは、RACIチャートなどを用いて役割や責任をより詳細に整理することもあります。

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

例えば、「テスト環境の準備」という作業がWBSにあったとします。

OBSがなければ、「インフラチームが担当するのか」「運用部門が担当するのか」が曖昧になるかもしれません。

OBSを作成しておけば、担当部署が明確になり、責任の押し付け合いや作業漏れを防ぐことができます。

よくある勘違い

OBSは組織図そのものではない

会社全体の組織図をそのまま使うのではなく、そのプロジェクトに関係する組織だけを整理することが重要です。

OBSだけではプロジェクトは管理できない

OBSは責任を整理するためのツールです。

作業内容やスケジュールを管理するには、WBSやガントチャートと組み合わせて活用する必要があります。

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

IPAのプロジェクトマネージャ試験では、「責任分担の明確化」「役割の定義」「組織間の調整」が重要なテーマとして出題されます。

午後Ⅱ論文では、「関係部署との役割分担をどのように整理したか」「責任を明確にするためにどのような工夫を行ったか」を説明できると評価につながります。

PMBOK®でも、OBSは責任割当マトリックス（RAM）を作成する際の基礎となる考え方です。

PM道場のワンポイント

WBSを作っただけでは、プロジェクトは動きません。実務でよくあるトラブルは、「この作業、誰がやるの？」という状態です。作業は決まっているのに担当者が決まっていない。

担当者はいるのに責任者が分からない。

こうした曖昧さが、進捗遅延や品質低下の原因になります。

優れたプロジェクトマネージャは、WBSで「仕事」を整理し、OBSで「責任」を整理します。

仕事と責任、この2つが結び付いて初めて、プロジェクトは前に進みます。

関連用語

• WBS
• RAM（責任割当マトリックス）
• RACIチャート
• プロジェクト組織
• ステークホルダー
• 役割と責任
• ガントチャート
• プロジェクトマネージャ

まとめ

OBSとは、プロジェクトに関わる組織や担当者を階層的に整理した組織構成図です。

WBSが「何をやるか」を整理するのに対し、OBSは「誰がやるか」を整理します。

両者を組み合わせることで、責任が明確になり、作業漏れや役割の重複を防ぐことができます。

プロジェクトを円滑に進めるためには、仕事だけでなく責任の見える化も欠かせません。

関連記事

• WBSとは？
• RACIチャートとは？
• ステークホルダーとは？
• プロジェクトマネージャとは？

よくある質問（FAQ）

Q. OBSとは何ですか？

A. プロジェクトに関わる組織や担当者を階層的に整理し、役割や責任を明確にするための組織構成図です。

Q. WBSとの違いは何ですか？

A. WBSは「何をやるか」を整理し、OBSは「誰がやるか」を整理します。両者を組み合わせることで、仕事と責任を明確にできます。

Q. OBSはどのような場面で使われますか？

A. 責任割当の明確化や、RAM（責任割当マトリックス）、RACIチャートを作成する際の基礎資料として活用されます。

The post OBSとは？WBSとの違いや役割を初心者向けにわかりやすく解説 first appeared on PM道場.