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

「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経験5年の人よりもPMとして強そうに感じるかもしれません。

確かに、PMとして長く仕事をしてきたことは、それだけで一つの強みです。

さまざまなプロジェクトを経験し、さまざまな問題に向き合ってきた可能性があります。

しかし、私はPM経験年数だけでは、その人のPM戦闘力を判断できないと考えています。

なぜなら、同じ「PM経験10年」でも、経験してきたプロジェクトの難しさや、そこから何を学んできたかによって、PMとしての強さは大きく変わるからです。

PM戦闘力を高めるために重要なのは、単純な経験年数ではありません。

どのような経験をしたのか。

そして、その経験から何を学び、次のプロジェクトで何を変えたのか。

今回は、PM経験の「質」について考えてみます。

PM経験年数は重要。でも、それだけでは足りない

まず、誤解のないようにしておきたいのですが、私は「PM経験年数なんて意味がない」と考えているわけではありません。

むしろ、経験年数はPM戦闘力を考えるうえで重要な土台です。

1年目のPMと10年目のPMでは、経験してきたことに大きな差があるでしょう。

ただし、

経験年数＝PM戦闘力

ではありません。

重要なのは、

経験をどのようにPMとしての能力に変えてきたか

です。

同じ10年間でも、毎回似たようなプロジェクトを、同じような方法で進めてきた人と、異なる環境・難易度のプロジェクトに挑戦し、そこで得た教訓を次のプロジェクトに活かしてきた人では、経験の価値は変わります。

だから私は、

PM経験年数は「経験の量」を表す一つの指標であって、経験の質まで表しているわけではない

と考えています。

PM経験の「質」は何で決まるのか？

では、どのようなプロジェクトを経験すると、PMとしての経験値が高まるのでしょうか。

私自身の経験から考えると、特に重要なのは次の5つです。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

もちろん、これだけが全てではありません。

しかし、こうした条件が複雑になるほど、PMにはより高度なマネジメントが求められます。

① ステークホルダーが難しい

私が経験値が高いと感じるプロジェクトの中でも、特に重要なのがステークホルダーの難しさです。

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

• 初めて取引する顧客
• 自社に対して良い印象を持っていない顧客
• 要求が非常に多い顧客
• 意思決定者が複数いる
• 顧客と自社で利害が一致していない
• 社内でもプロジェクトに対する考え方が異なる

プロジェクトマネジメントは、計画を作って、その通りに進めれば終わる仕事ではありません。

人が関わる以上、認識の違いや期待値の違いが生まれます。

ステークホルダーが難しくなるほど、PMに求められる能力も増えていきます。

• コミュニケーション
• 交渉
• 期待値のコントロール
• 合意形成

そのため、難しいステークホルダーとのプロジェクトを経験することは、PMの戦闘力を高める大きな経験になると考えています。

② メンバーが多い

メンバーが増えると、単純に管理する人数が増えるだけではありません。

例えば、10人のメンバーを一つのチームとして管理するのではなく、複数のチームに分ける必要が出てくるとします。

すると、次のような新しいマネジメントが必要になります。

• チーム間の認識合わせ
• チーム間の依存関係
• チーム間の優先順位
• チーム間のコンフリクト
• 情報共有

人数が増えることで、

「一人ひとりとコミュニケーションを取ればいい」

というマネジメントから、

「チームという単位をマネジメントする」

という段階に変わっていきます。

これもPMとして重要な経験です。

③ 技術的な難しさ

技術的に難しいプロジェクトも、PMにとって貴重な経験になります。

• そもそも技術的に成功する可能性が低い
• やってみなければ結果が分からない
• 前例がない

このようなプロジェクトでは、単純に「計画通りに進める」だけでは対応できません。

例えば、

「もし技術的に実現できなかったらどうするのか？」

というところまで考えておく必要があります。

場合によっては、失敗した場合の代替案や関係者への説明方法まで、事前に準備しておく必要があるでしょう。

つまり、技術的な難しさが増えるほど、

不確実性をマネジメントする力

が求められます。

こうした経験は、次のプロジェクトでリスクを考えるときにも活きてきます。

④ メンバーの質

メンバーの経験やスキルも、プロジェクトの難易度を大きく左右します。

例えば、経験豊富なメンバーが揃っているプロジェクトであれば、PMが細かく指示を出さなくても、それぞれが自律的に動けるかもしれません。

一方、若手メンバーが多いプロジェクトでは、そうはいきません。

プロジェクトを進めるだけではなく、

メンバーを育成すること

も必要になります。

• 何をすべきなのか
• なぜそれをするのか
• どういう観点で仕事をしてほしいのか

こうしたことを伝えながら、プロジェクトそのものも前に進めなければなりません。

これは、単なるタスク管理とは違うPM経験です。

⑤ ベンダーが多い

複数のベンダーが関わるプロジェクトも、PMにとって難易度が上がります。

ベンダーごとの管理だけならまだしも、複数のベンダーが関係すると、

ベンダー同士をどう連携させるか

という問題が出てきます。

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

• A社の作業が終わらないとB社が作業できない
• A社とB社で責任範囲の認識が違う
• ベンダー間で優先順位が異なる
• 問題が発生したときに責任の所在が曖昧になる

ここではベンダーマネジメントだけではなく、ベンダー間の調整も必要になります。

これもPMとして重要な経験になります。

重要なのは「難しいプロジェクトを経験した数」だけではない

ここまで読むと、

「では、とにかく難しいプロジェクトをたくさん経験すればいいのか？」

と思うかもしれません。

私は、それも少し違うと考えています。

もちろん、さまざまな状況のプロジェクトを経験したほうが、PMとしての引き出しは増えます。

しかし、同じようなプロジェクトでも、経験から教訓を得て、より良いマネジメントができるようになれば、経験値は上がります。

例えば、前回のプロジェクトで、

「メンバーへの指示がうまく伝わらなかった」

という問題が起きたとします。

その原因を分析し、

「メンバーがプロジェクトマネジメントの意図を理解していなかった」

と分かった。

そこで次のプロジェクトでは、

「なぜこの指示をするのか」

まで説明するようにした。

これだけでも、同じような規模のプロジェクトを経験しているにもかかわらず、PMとしての能力は変わっています。

つまり、

経験の質は、プロジェクトそのものの難しさだけで決まるわけではありません。

経験から何を得たか。

これも、経験の質を決める重要な要素です。

失敗は、失敗のまま終わらせなければ戦闘力になる

私は、失敗した経験もPM戦闘力を高める重要な材料になると考えています。

例えば、次のような経験です。

• スケジュールが遅れた
• 顧客との認識が合わなかった
• メンバーへの指示が伝わらなかった
• リスクへの対応が遅れた
• ベンダーとの調整に失敗した

こうした経験は、決して無駄ではありません。

ただし、

「失敗した」という事実だけでは、PM戦闘力にはなりません。

重要なのは、その後です。

• なぜ失敗したのか？
• 原因を分析する
• 次はどうすれば防げるのか？
• 対策を考える
• 次のプロジェクトで実際に対策する
• その結果を確認する

こうして初めて、失敗が「教訓」に変わります。

私は、

失敗を失敗のまま終わらせなければ、その経験は戦闘力になる

と考えています。

私自身の経験：若手メンバーとのプロジェクト

ここで、私自身の経験を紹介します。

ある小規模なプロジェクトで、私以外のメンバーは入社3年以内の若手が2人。

そこに50代の営業担当者が1人。

そして、顧客は要望が多く、プロジェクトを失敗させると厳しいクレームにつながる可能性がある顧客でした。

人数だけを考えれば、それほど大きなプロジェクトではありません。

しかし、PMとしては簡単なプロジェクトではありませんでした。

特に課題だったのが、若手メンバーとどのようにプロジェクトを進めるかでした。

そこで私は、プロジェクトのマネジメント方法を一から伝えることにしました。

そして、キックオフミーティングでは、

「このプロジェクトでは、メンバーとしてこういうことを意識してほしい」

ということを伝えました。

単に「これをやってください」と指示するのではありません。

なぜ自分がその指示をしているのか。

プロジェクトマネジメントの観点から、なぜその行動が必要なのか。

そこまで理解してもらおうとしました。

なぜ、そこまでやったのか？

実は、これは前のプロジェクトから得た教訓でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していませんでした。

そのため、私が出した指示の意図がうまく伝わらず、結果として納期遅延を起こしてしまいました。

そこで私は、

「次のプロジェクトでは、メンバーに指示を出すだけではなく、プロジェクトマネジメントそのものを理解してもらおう」

と考えました。

これが、次のプロジェクトでの行動につながりました。

そして、そのプロジェクトでは、前回の教訓を活かしてプロジェクトを進めることができました。

これこそが「経験が戦闘力になる」ということ

この経験から、私はPMにとって重要なのは、

「何年PMをやったか」ではない

と改めて感じました。

もちろん、経験年数は重要です。

しかし、

前のプロジェクトで何が起きたのか。

↓

なぜ起きたのか。

↓

次はどうするのか。

↓

実際に次のプロジェクトで行動を変える。

このサイクルを回すことが重要です。

前のプロジェクトでの失敗が、次のプロジェクトでの成功につながった。

そして、その成功体験が、さらに次のプロジェクトで使える。

こうして経験が積み重なっていきます。

経験とスキルは相互に作用する

親記事では、PM戦闘力を、

（経験 × スキル × 適用力）＋（資格＋実績）

と考えました。

ここでいう「経験」と「スキル」は、一方通行ではありません。

経験 → スキル

という流れもあれば、

スキル → 経験

という流れもあります。

プロジェクトを経験することで、

「こういうときには、こう対応すればいい」

というスキルが身につく。

一方で、すでに持っているスキルを使うことで、

「このプロジェクトでは、ここが問題になりそうだ」

と気づくこともあります。

つまり、

経験とスキルは、お互いを高め合う関係

なのです。

ただし、ここでも重要なのは、自分で考えることです。

経験しただけ。

研修を受けただけ。

資格を取っただけ。

これでは十分ではありません。

経験から考える。

考えたことをスキルに変える。

スキルを次のプロジェクトで使う。

その結果を振り返る。

また次のプロジェクトで活用する。

この循環を自分自身で作る必要があります。

「経験年数」ではなく「経験をどう変えたか」を考える

PMとして経験を積んでいると、いつの間にか、

「PM歴○年」

という数字を自分の強さの指標にしてしまうことがあります。

しかし、PM戦闘力を高めるうえで重要なのは、単純な年数ではありません。

• どんなプロジェクトを経験したのか
• どんな難しさに直面したのか
• 何に失敗したのか
• 何を教訓にしたのか
• 次のプロジェクトで何を変えたのか

そして、

その経験を、次のプロジェクトで再現できる能力に変えられたのか。

ここまで考えて、初めて「経験」がPM戦闘力につながるのだと思います。

まとめ：経験を積むだけではなく、経験を戦闘力に変える

PM経験年数は、PM戦闘力を考えるうえで重要な土台です。

しかし、

PM経験10年＝PM戦闘力10

のように単純に考えることはできません。

経験の質によって、得られるものは大きく変わります。

特に、次のような要素が複雑になるほど、PMにはより高度なマネジメントが求められます。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

一方で、難しいプロジェクトだけが価値のある経験というわけでもありません。

同じようなプロジェクトであっても、

過去の教訓を活かして、前回より良いマネジメントができた

のであれば、それもPM戦闘力を高める重要な経験です。

そして、失敗も同じです。

失敗する → 原因を分析する → 対策を考える → 教訓にする → 次のプロジェクトで活かす

このサイクルを回すことで、失敗は戦闘力に変わります。

PMとして大切なのは、

経験年数を増やすことではなく、経験を戦闘力に変え続けること。

私はそう考えています。

あなたは、これまでのPM経験から、どんな教訓を得てきましたか？

そして、その教訓を次のプロジェクトで活かせているでしょうか。

経験を「年数」で終わらせず、「次のプロジェクトで使える力」に変えていく。

それが、PM戦闘力を高める一つの方法だと思います。

PM戦闘力シリーズ

PM戦闘力について、さらに詳しく知りたい方はこちらもどうぞ。

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM戦闘力を高めるPMスキルとは？重要な4つのスキル考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由 first appeared on PM道場.

「見積もりは経験だけで決めてもよいのだろうか。」

プロジェクトを成功させるためには、現実的なスケジュールや予算を計画することが重要です。

その土台となるのが見積もり（Estimate）です。

この記事では、見積もりの意味や目的、代表的な見積もり手法、PMBOK®︎との関係、実務で意識すべきポイントについて解説します。

一言でいうと

見積もりとは、「プロジェクトに必要な期間・コスト・工数・資源などを予測する活動」です。

見積もりとは

見積もりとは、プロジェクトを実施するために必要な工数、期間、コスト、資源などを予測することです。

プロジェクトの初期段階では情報が限られているため、見積もりはあくまで予測であり、プロジェクトが進むにつれて精度を高めていきます。

PMBOK®︎では、見積もりはスケジュールマネジメントやコストマネジメントなどの計画プロセスで重要な活動として位置付けられています。

見積もりが重要な理由

見積もりが不正確だと、その後に作成するスケジュールや予算、要員計画にも大きな影響を与えます。

例えば、次のような問題が発生する可能性があります。

• スケジュールが現実的ではない
• 予算不足になる
• 要員が不足する
• 納期遅延や品質低下につながる

適切な見積もりを行うことで、実現可能な計画を立てることができます。

代表的な見積もり手法

類推見積もり（Analogous Estimating）

過去の類似プロジェクトを参考に見積もる方法です。

短時間で実施できますが、過去の実績に大きく依存します。

パラメトリック見積もり（Parametric Estimating）

単価や生産性などの統計データを用いて算出する方法です。

例えば、「1画面あたり20時間」といった基準を利用します。

ボトムアップ見積もり（Bottom-Up Estimating）

WBSで分解した最小単位の作業ごとに見積もり、それらを積み上げる方法です。

時間はかかりますが、高い精度が期待できます。

三点見積もり（Three-Point Estimating）

楽観値・最頻値・悲観値の3つを用いて見積もる方法です。

不確実性を考慮した、より現実的な見積もりが可能になります。

見積もりの精度は段階的に高まる

プロジェクト初期は情報が少ないため、見積もりの精度は高くありません。

要件が明確になり、設計が進むにつれて精度は向上します。

そのため、見積もりは一度作成したら終わりではなく、必要に応じて見直すことが重要です。

見積もりと予算の違い

つまり、見積もりをもとに予算が作成されます。

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

例えば、新しいWebシステムを開発するプロジェクトを考えます。

プロジェクトマネージャは、まずWBSを作成し、各アクティビティの工数をボトムアップ見積もりで算出します。

さらに、過去のプロジェクト実績も参考にしながら見積もりを補正し、最終的な期間とコストを算出します。

その見積もりをもとに、スケジュールや予算を作成し、スポンサーの承認を得てプロジェクトを開始します。

よくある勘違い

見積もりは「約束」ではない

見積もりは、現時点で得られる情報をもとにした予測です。

要件変更や新たなリスクによって見積もりが変わることは珍しくありません。

経験だけで見積もるのは危険

経験は重要ですが、それだけでは精度に限界があります。

WBSや過去実績、統計データなどを活用し、客観的な根拠を持って見積もることが重要です。

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

IPAのプロジェクトマネージャ試験では、見積もり手法や見積もり精度に関する問題が出題されます。

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

• どの見積もり手法を採用したか
• 見積もりの根拠は何か
• 見積もり精度をどのように向上させたか
• 見積もり結果を計画へどのように反映したか

「経験で見積もった」だけではなく、「WBSや過去実績などを活用し、根拠のある見積もりを実施した」と説明できることが評価につながります。

PM道場のワンポイント

見積もりは、「未来を当てること」ではなく、「現時点で最も合理的な予測をすること」です。

プロジェクトでは、不確実性をゼロにすることはできません。

だからこそ、根拠を明確にし、不確実性も考慮した見積もりを行うことが重要です。

優れたプロジェクトマネージャは、「当たる見積もり」ではなく、「説明できる見積もり」を作成しています。

関連用語

• WBS
• 予算
• コストベースライン
• コストマネジメント
• スケジュールベースライン
• ローリングウェーブ計画法
• リスク分析
• アクティビティ

まとめ

見積もりとは、プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

見積もりの精度はプロジェクトの進行とともに高まり、その結果はスケジュールや予算の基礎となります。

プロジェクトマネージャにとって、根拠のある見積もりを行うことは、現実的な計画を立てるための重要なスキルと言えるでしょう。

関連記事

• WBSとは？
• 予算とは？
• コストベースラインとは？
• コストマネジメントとは？
• スケジュールベースラインとは？
• ローリングウェーブ計画法とは？

よくある質問（FAQ）

Q. 見積もりとは何ですか？

A. プロジェクトに必要な期間・コスト・工数・資源などを予測する活動です。

Q. PMBOK®︎で代表的な見積もり手法には何がありますか？

A. 類推見積もり、パラメトリック見積もり、ボトムアップ見積もり、三点見積もりなどがあります。

Q. 見積もりと予算の違いは何ですか？

A. 見積もりは必要な期間や費用を予測する活動であり、予算はその見積もりをもとに承認された資金計画です。

The post 見積もりとは？プロジェクト計画の精度を左右する重要なプロセスを解説 first appeared on PM道場.

「ベンダーとの認識違いで、スケジュール遅延が発生してしまった。」

プロジェクトでは、外部企業や協力会社と連携する場面が多くあります。

そのような状況で重要になるのがベンダーマネジメント（Vendor Management）です。

この記事では、ベンダーマネジメントの意味や目的、進め方、RFPとの関係、プロジェクトマネージャが意識すべきポイントについて解説します。

一言でいうと

ベンダーマネジメントとは、「外部の企業や協力会社と適切な関係を築き、契約内容や品質、進捗を管理しながらプロジェクト成功へ導く活動」です。

ベンダーマネジメントとは

ベンダーマネジメントとは、プロジェクトで利用する外部企業（ベンダー）を管理し、期待する成果を得るための活動です。

ベンダーとは、製品やサービス、開発作業などを提供する企業や組織を指します。

プロジェクトでは、自社のメンバーだけですべてを実施することは難しく、外部の専門企業へ業務を委託することがあります。

その際、単に作業を依頼するだけではなく、目的や期待値を共有し、協力関係を築くことが重要になります。

PMBOK®︎では、ベンダーマネジメントは調達マネジメントやステークホルダーエンゲージメントと関連する重要な活動として扱われています。

ベンダーマネジメントが重要な理由

外部企業へ作業を委託すると、プロジェクトマネージャは直接すべてを管理できるわけではありません。

そのため、適切な管理を行わないと、次のような問題が発生します。

• 成果物の品質が期待を下回る
• 納期遅延が発生する
• 契約範囲外の作業が増える
• 認識違いによる手戻りが発生する
• 問題発生時の対応が遅れる

ベンダーを「作業を任せる相手」ではなく、「プロジェクトを成功させるパートナー」と考えることが重要です。

ベンダーマネジメントの進め方

1. 期待事項を明確にする

契約前に、目的、成果物、品質基準、スケジュールなどを明確にします。

RFP（提案依頼書）を活用し、ベンダーへ期待する内容を伝えることも重要です。

2. 役割と責任範囲を明確にする

発注側とベンダー側の役割分担を明確にします。

例えば、次のような項目です。

• 成果物作成の責任者
• レビュー担当者
• 問題発生時の連絡先
• 承認プロセス

責任範囲が曖昧だと、「どちらが対応するのか分からない」という問題につながります。

3. 進捗と品質を確認する

定期的な進捗確認やレビューを実施します。

重要なのは、問題が発生してから確認するのではなく、早期に兆候を把握することです。

4. 問題発生時は協力して解決する

ベンダー側で問題が発生した場合、責任追及だけでは問題解決につながりません。

原因を確認し、プロジェクト全体として最適な対応策を検討します。

ベンダーマネジメントで管理する主な項目

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

例えば、システム開発プロジェクトで外部開発会社へ一部機能の開発を委託したとします。

プロジェクトマネージャは、契約した後も次のような管理を行います。

• 週次進捗会議の実施
• 成果物レビューの実施
• 課題一覧の共有
• 品質状況の確認
• 変更要求への対応調整

その結果、ベンダーと自社が同じ目標に向かって協力でき、プロジェクトを成功へ導くことができます。

よくある勘違い

ベンダーマネジメントは監視することではない

ベンダーを細かく監視し、指示するだけでは良い関係は築けません。

重要なのは、期待する成果を共有し、協力しながら問題を解決することです。

契約したら管理は不要ではない

契約はスタート地点です。

契約後も、進捗・品質・課題を継続的に確認し、必要に応じて調整する必要があります。

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

IPAのプロジェクトマネージャ試験では、外部委託や協力会社との調整に関する問題が出題されます。

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

• ベンダー選定時に何を評価したか
• 契約内容や役割分担をどのように明確化したか
• 進捗・品質をどのように管理したか
• 問題発生時にどのように協力して解決したか

「ベンダーへ依頼した」ではなく、「協力関係を構築し、プロジェクト成功に向けて管理した」と説明できることが評価につながります。

PM道場のワンポイント

ベンダーマネジメントで重要なのは、ベンダーを管理することではなく、同じゴールへ向かうパートナーシップを築くことです。

外部企業へ委託すると、「発注者」と「受注者」という関係になりがちです。

しかし、プロジェクト成功という目的は同じです。

優れたプロジェクトマネージャは、契約だけに頼るのではなく、日々のコミュニケーションによって信頼関係を構築しています。

良いベンダーマネジメントは、問題が起きた後の対応ではなく、問題が起きにくい関係づくりから始まります。

関連用語

• 調達マネジメント
• RFP
• 契約
• 要求事項
• ステークホルダーエンゲージメント
• コミュニケーションマネジメント
• 品質管理
• 変更要求

まとめ

ベンダーマネジメントとは、外部企業や協力会社と適切な関係を築き、契約内容や品質、進捗を管理しながらプロジェクト成功へ導く活動です。

重要なのは、単に作業を管理することではなく、ベンダーと協力して同じ目標へ向かうことです。

プロジェクトマネージャにとって、ベンダーマネジメントは外部リソースを最大限に活用するための重要なスキルと言えるでしょう。

関連記事

• RFPとは？
• 調達マネジメントとは？
• 契約とは？
• 要求事項とは？
• ステークホルダーエンゲージメントとは？
• 品質管理とは？

よくある質問（FAQ）

Q. ベンダーマネジメントとは何ですか？

A. 外部企業や協力会社と適切な関係を築き、品質・進捗・契約などを管理しながらプロジェクト成功へ導く活動です。

Q. ベンダーマネジメントで最も重要なことは何ですか？

A. ベンダーを単なる作業委託先ではなく、プロジェクト成功に向けたパートナーとして考え、協力関係を築くことです。

Q. RFPとベンダーマネジメントの関係は何ですか？

A. RFPはベンダー選定前に期待する内容を伝える文書であり、ベンダーマネジメントは選定後も含めて継続的に関係を管理する活動です。

The post ベンダーマネジメントとは？外部パートナーと協力してプロジェクトを成功へ導く管理方法を解説 first appeared on PM道場.

「もしシステム障害が発生した場合、誰が何をするのでしょうか？」

プロジェクトでは、事前にリスクを洗い出していても、実際に問題が発生する可能性があります。

そのような不測の事態に備え、あらかじめ対応方法を決めておく計画がコンティンジェンシープラン（Contingency Plan）です。

この記事では、コンティンジェンシープランの意味や目的、作成方法、リスク対応計画との違い、実務での活用方法について解説します。

一言でいうと

コンティンジェンシープランとは、「リスクが実際に発生した場合に備えて、あらかじめ決めておく対応計画」です。

コンティンジェンシープランとは

コンティンジェンシープランとは、特定のリスクが発生した場合に、どのような対応を行うかを事前に定めた計画です。

リスクマネジメントでは、リスクを完全になくすことはできません。

そのため、

• リスクが発生した場合に何をするか
• 誰が対応するか
• どのタイミングで対応を開始するか
• どのような判断が必要か

を事前に決めておきます。

PMBOK®︎では、リスク対応を計画する際に、リスクが発生した場合の対応策としてコンティンジェンシープランを準備します。

コンティンジェンシープランが重要な理由

問題が発生した後に対応方法を考えると、判断や対応が遅れる可能性があります。

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

• 担当者が不在になり、作業を引き継げない
• システム障害発生時に対応窓口が決まっていない
• 納期遅延が発生してから対応策を検討する

このような状況では、混乱が発生し、さらに大きな影響につながる可能性があります。

コンティンジェンシープランを準備しておくことで、発生時に迅速な対応が可能になります。

コンティンジェンシープランとリスク対応計画の違い

コンティンジェンシープランは、リスク対応計画の一部として扱われることがあります。

例えば、

リスク：重要メンバーが離脱する可能性がある

リスク対応：複数人が対応できるように知識共有を進める

コンティンジェンシープラン：離脱した場合は、予備メンバーを投入し、○日以内に引き継ぎを完了する

というように整理できます。

コンティンジェンシープランの作成方法

1. 対象となるリスクを選定する

すべてのリスクに対して詳細な計画を作成する必要はありません。

影響度が大きく、発生した場合に迅速な対応が必要なリスクを対象にします。

2. 発動条件（トリガー）を決める

コンティンジェンシープランでは、「いつ実行するか」を明確にすることが重要です。

この判断基準をリスクトリガー（Risk Trigger）と呼びます。

例：

• 予定日から3日以上遅延した場合
• 品質不良が一定数を超えた場合
• 主要メンバーが離脱した場合

3. 対応内容と担当者を決める

発生時の混乱を防ぐため、具体的な行動を決めます。

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

例えば、プロジェクトの主要メンバーが長期間参加できなくなるリスクを考えます。

事前に以下のようなコンティンジェンシープランを準備します。

• 副担当者を設定する
• 重要資料を共有フォルダへ保存する
• 定期的に知識共有を行う
• 離脱時は副担当者へ引き継ぐ
• 必要に応じて追加要員を依頼する

このように、発生後の行動を事前に決めることで、プロジェクトへの影響を抑えることができます。

よくある勘違い

コンティンジェンシープランは「悲観的な計画」ではない

コンティンジェンシープランを作成すると、「問題が起きる前提で考えている」と感じる人もいます。

しかし、目的は問題を予測して悲観することではありません。

不確実な状況でも、冷静に対応できる準備を整えることが目的です。

すべてのリスクに作成する必要はない

すべてのリスクへ詳細な計画を作成すると、管理負荷が大きくなります。

影響度や発生可能性を考慮し、重要なリスクに絞って作成することが重要です。

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

IPAのプロジェクトマネージャ試験では、リスク発生時の対応判断や危機管理が重要なテーマになります。

論文では、以下の観点を説明できることが重要です。

• どのようなリスクを想定したか
• なぜ事前に対応計画を準備したか
• どのような発動条件を設定したか
• 発生後にどのような対応を行ったか

単に「リスク対応を準備した」と書くのではなく、「発生時の混乱を防ぐために、事前に判断基準と行動を明確化した」と説明できることが重要です。

PM道場のワンポイント

コンティンジェンシープランは、問題が発生した時に慌てないための「未来への準備」です。

優れたプロジェクトマネージャは、問題が起きないようにするだけではなく、起きた場合にもプロジェクトを継続できる仕組みを作っています。

特に重要なのは、計画書を作成することではありません。

「誰が」「いつ」「どの条件で」「何をするか」を明確にしておくことです。

リスクをゼロにできないからこそ、発生後の対応力を高めることがプロジェクト成功につながります。

関連用語

• リスク（Risk）
• リスクマネジメント
• リスク対応
• リスク登録簿（Risk Register）
• リスクトリガー
• コンティンジェンシー予備
• 課題（Issue）
• エスカレーション

まとめ

コンティンジェンシープランとは、リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

重要なのは、問題発生後に慌てて対応するのではなく、あらかじめ判断基準や行動を明確にしておくことです。

プロジェクトマネージャには、不確実性をなくす力だけではなく、不確実性に備える力が求められます。

コンティンジェンシープランは、そのための重要なマネジメント手法です。

関連記事

• リスク（Risk）とは？
• リスクマネジメントとは？
• リスク分析とは？
• リスク対応とは？
• リスク登録簿（Risk Register）とは？
• エスカレーションとは？

よくある質問（FAQ）

Q. コンティンジェンシープランとは何ですか？

A. リスクが発生した場合に備えて、事前に対応方法を決めておく計画です。

Q. リスク対応計画との違いは何ですか？

A. リスク対応計画は対応方針を決めるもの、コンティンジェンシープランは発生時の具体的な行動を決めるものです。

Q. すべてのリスクにコンティンジェンシープランは必要ですか？

A. いいえ。影響度が大きく、発生時に迅速な対応が必要な重要リスクを対象に作成します。

The post コンティンジェンシープランとは？リスク発生時に備える対応計画を解説 first appeared on PM道場.

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

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

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

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

一言でいうと

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

エスカレーションとは

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

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

例えば、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

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

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

関連用語

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

まとめ

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

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

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

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

関連記事

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

よくある質問（FAQ）

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

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

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

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

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

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

The post エスカレーションとは？プロジェクトを成功に導くための問題共有の考え方を解説 first appeared on PM道場.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし私は、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし、

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

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

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

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

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

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

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

すると、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PMBOK®には、

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

とは書かれていません。

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

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

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

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

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

おわりに

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

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

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

理由は簡単です。

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

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

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

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

あなたへの問いかけ

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

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

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

役割や責任が曖昧なまま進めてしまうと、作業漏れや意思決定の遅れ、関係者間の認識違いにつながります。

こうした問題を防ぐためによく利用されるのが「RACI」です。

この記事では、RACIの意味や4つの役割、実務での活用方法、PMBOK®やプロジェクトマネージャ試験で重要なポイントまでわかりやすく解説します。

一言でいうと

RACIとは、「仕事ごとに役割と責任を明確にするための役割分担表（責任割当の考え方）」です。

RACIとは

RACIとは、各作業に対して「誰が実施し、誰が最終責任を持ち、誰に相談し、誰へ情報共有するか」を整理するフレームワークです。

一般的には、責任割当マトリックス（RAM：Responsibility Assignment Matrix）の形式で表現されます。

役割を明確にすることで、責任の重複や抜け漏れを防ぎ、スムーズなプロジェクト運営につながります。

RACIの4つの役割

RACIの具体例

例えば、「設計書レビュー」を行う場合、次のように整理できます。

このように整理することで、誰が何を担うのかが一目で分かります。

RACIを使うメリット

• 責任者が明確になる
• 意思決定がスムーズになる
• 作業漏れや責任の押し付け合いを防げる
• 関係者との認識を合わせやすい
• 新しいメンバーでも役割を理解しやすい

OBS・WBSとの関係

RACIは単独で作るものではありません。

通常は、WBSで整理した作業と、OBSで整理した組織や担当者を組み合わせて作成します。

つまり、

• WBS：「何をやるか」
• OBS：「誰が関わるか」
• RACI：「それぞれがどのような役割を担うか」

という関係になります。

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

例えば、顧客から要件変更の依頼があったとします。

RACIが整理されていれば、「変更内容を評価する担当者」「承認する責任者」「相談すべき関係部署」「結果を報告する相手」が明確になります。

その結果、「誰が判断するのか分からない」という状況を防ぐことができます。

よくある勘違い

ResponsibleとAccountableは同じではない

Responsibleは「作業を行う人」、Accountableは「最終責任を負う人」です。

小規模プロジェクトでは同じ人が兼ねることもありますが、大規模プロジェクトでは分けることが一般的です。

Accountableは複数人にしない

一つの作業に最終責任者が複数いると、責任の所在が曖昧になります。

そのため、原則としてAccountableは1人に設定します。

全員をConsultedにしない

相談相手が多すぎると、意思決定に時間がかかります。

本当に意見が必要な人だけをConsultedに設定することが重要です。

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

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

午後Ⅱ論文では、「役割をどのように整理し、責任の曖昧さを防いだか」を具体的に説明できると高い評価につながります。

PMBOK®でも、RACIは責任割当マトリックス（RAM）の代表例として紹介され、プロジェクトチームの役割と責任を明確にするための手法として活用されています。

PM道場のワンポイント

RACIは「役割を決める表」ではなく、「責任の曖昧さをなくすための仕組み」です。実務では、「担当は決まっているのに、誰も判断しない」という状況がよくあります。これは、Responsibleは決まっていても、Accountableが曖昧だからです。

逆に、「全員で相談して決めよう」とすると、誰も決断できず、プロジェクトは止まってしまいます。

優れたプロジェクトマネージャは、RACIを使って「誰が実施するか」だけでなく、「誰が最終的に決めるのか」まで明確にしています。

プロジェクトのスピードは、責任の明確さで決まると言っても過言ではありません。

関連用語

• RAM（責任割当マトリックス）
• OBS
• WBS
• ステークホルダー
• プロジェクトマネージャ
• ガバナンス
• コミュニケーションマネジメント
• 組織構造

まとめ

RACIとは、作業ごとに役割と責任を整理し、プロジェクトに関わるメンバーの責任範囲を明確にするためのフレームワークです。

Responsible・Accountable・Consulted・Informedを適切に設定することで、責任の曖昧さを防ぎ、スムーズな意思決定やコミュニケーションにつながります。

プロジェクトを円滑に進めるためには、「誰が作業するか」だけでなく、「誰が最終責任を持つか」を明確にすることが重要です。

関連記事

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

よくある質問（FAQ）

Q. RACIとは何ですか？

A. 作業ごとに「実施者」「最終責任者」「相談相手」「情報共有先」を明確にするための役割分担フレームワークです。

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

A. Responsibleは実際に作業を行う担当者、Accountableは最終的な責任を負い、承認や意思決定を行う責任者です。

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

A. WBSで整理した作業ごとに役割と責任を明確にしたい場面や、複数部署が関わるプロジェクトで責任範囲を整理したい場面で活用されます。

The post RACIとは？役割と責任を明確にするフレームワークを初心者向けにわかりやすく解説 first appeared on PM道場.

• 令和7年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

チームの育成について、どのように育成したのか、なぜその育成方法をとったのかを論理的に説明できると良いです。

設問ア｜プロジェクト目標と不健全な状態を具体的に説明する

設問アでは以下3点について論じます。

• ① システム開発プロジェクトの目標
• ② 目標の達成が危ぶまれると考えたメンバーやチームの想定された不健全な状態
• ③ その状態を引き起こすと考えた人間的側面での背景や事象

① システム開発プロジェクトの目標

ここで重要なのは、目標を定量的に示すことです。
設問ウにおいて、目標達成にどのような貢献をしたかの説明が求められるため、定量的に説明しておくことで、根拠のある分かりやすい説明ができます。

例えば以下のような内容です。

• 納期遵守率100%
• レビュー指摘件数20%削減
• 生産性15%向上
• 障害件数30%削減

② 不健全な状態

ここでは、具体的で分かりやすい説明を心がけると良いです。
実際にどのような状態だったのか、プロジェクトマネージャとしてどのように把握したのかを説明できると良いです。

例えば以下のような内容があります。

• メンバーからのエスカレーション
• 打合せで発言が少ない
• レビュー遅延が頻発している
• 成果物の品質低下
• 作業の押し付け合いが発生している

単に「雰囲気が悪かった」と書くのではなく、どのような事象から問題を把握したのかまで説明すると、説得力が増します。

③ 人間的側面での背景や事象

問題文にもあるように、背景としては、異なる慣習や価値観を持つメンバーや急なメンバー交代などがあります。

例えば以下のような背景です。

• グローバルプロジェクトで複数国のメンバーが参加していた
• 急な離任により引継ぎ不足が発生した
• 経験差が大きいチーム構成だった

また、事象としては以下のような内容があります。

• 協力する姿勢が見られない
• 一体感が不足している
• 士気が上がらないメンバーが多い
• 課題を共有しない

ここでは、技術面ではなく「人間関係」に焦点を当てることが重要です。

設問イ｜健全な状態と育成計画を論理的に説明する

設問イでは以下2点を論じます。

• ① 目指したメンバーやチームの健全な状態と、その状態を目指した理由
• ② 人間的側面に着目して作成したチームの育成計画（工夫したことを含める）

① 目指した健全な状態

健全な状態とはどのような状態なのかを具体的に説明します。
設問アで説明した不健全な状態と対になる状態を示せると良いです。

例えば以下のような状態です。

• メンバー同士が自主的に助け合う
• 会議で積極的に発言する
• 問題を早期共有する
• レビューを協力して実施する

また、なぜその状態を目指したのかも説明します。
ここでは、プロジェクト目標との関連を示すことが重要です。

例えば、「納期遵守率100%を達成するためには、課題の早期共有が必要だった」などのように説明できると、論理的な文章になります。

② 人間的側面に着目したチームの育成計画

人間的側面という言葉は難しく感じますが、ここでは以下のような内容を意識すると良いです。

• 協力
• 信頼関係
• 一体感
• 士気

つまり、チームとして目標達成を目指すための人間関係改善について説明できれば良いです。

信頼関係を築くための施策

• 1on1ミーティングを実施した
• 雑談時間を設けた
• 困りごとを相談しやすい雰囲気を作った

協力体制を作るための施策

• ペア作業を導入した
• レビューを相互実施にした
• 進捗共有会を毎日実施した

一体感を高めるための施策

• チーム目標を見える化した
• 成功事例を全員へ共有した
• 感謝を伝える場を設けた

士気向上の施策

• 小さな成功を積極的に称賛した
• 成果を定量的に共有した
• メンバーへ役割と責任を与えた

さらに、チームメンバーの自己組織化について説明できると良いです。

自己組織化とは、メンバーがプロジェクト目標達成のために、自律的に責任を持って行動することです。
また、チーム育成についても、メンバー自身が主体的に関わる状態を指します。

工夫としては以下のような内容があります。

• メンバーから責任者を選出した
• 育成計画をメンバーと一緒に作成した
• 改善活動をチーム主体で運営した

設問ウ｜育成計画の成果を定量的に説明する

設問ウでは以下2点について論じます。

• ① 育成計画を実行した過程で発生した問題と解決策
• ② 育成計画の実行結果がプロジェクト目標にどのように貢献したか

① 発生した問題と解決策

ここでは、育成中にどのような問題が発生したのかを具体的に説明します。

例えば以下のような問題です。

• 会議が形骸化した
• 一部メンバーしか発言しなかった
• 改善活動が継続しなかった

さらに、その問題がなぜ発生したのかも分析できると良いです。
ここで使いやすいのが「なぜなぜ分析」です。

なぜを繰り返すことで原因を深掘りでき、解決策の根拠を強くできます。

例えば以下のような流れです。

• なぜ発言しないのか → 発言しづらい雰囲気だった
• なぜ雰囲気が悪いのか → 否定的な意見が多かった
• なぜ否定的なのか → レビュー方針が統一されていなかった

そのうえで、具体的な解決策を書きます。

• 発言ルールを決めた
• レビュー観点を標準化した
• ファシリテータを配置した

さらに、解決策によってどのように改善したのかまで説明できると良いです。

② 育成計画がプロジェクト目標へ貢献した内容

ここでは、設問アで説明した定量的目標と比較して説明することが重要です。

例えば以下のように比較します。

• 改善前：納期遅延率30%
• 改善後：納期遵守率95%

• 改善前：レビュー指摘件数120件
• 改善後：レビュー指摘件数70件

不健全な状態のままだった場合と、健全な状態へ改善した場合を比較することで、育成の効果を論理的に説明できます。

まとめ

この問題では、単に「教育しました」と書くだけでは不十分です。
チームの状態をどのように把握し、なぜその状態になったのかを分析し、どのような育成を実施したのかを論理的に説明することが重要です。

特に以下3点を意識すると、説得力のある論述になります。

• 定量的に説明する
• 人間的側面を具体的に書く
• 改善前後を比較して成果を書く

午後Ⅱは「論理性」が重要です。
状態・原因・改善・成果の流れを意識して答案を作成しましょう。

The post IPAプロジェクトマネージャ試験 午後Ⅱ対策 ｜【令和7年度秋 問1】 first appeared on PM道場.