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

「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道場.

新しいシステムや製品を開発するとき、このように考えることがあります。

そんなときに活用されるのがプロトタイプです。

プロトタイプは、完成品をいきなり作るのではなく、一部の機能や見た目などを試作品として作り、要求や仕様を確認するためのものです。

特に、顧客やユーザーが完成品を具体的にイメージできていない場合、プロトタイプを実際に見てもらうことで、認識のずれを早い段階で発見できます。

プロジェクトマネジメントにおいては、プロトタイプを「不確実性を減らすための手段」として考えると分かりやすいでしょう。

一言でいうと

プロトタイプとは、完成前の試作品を作り、要求・仕様・操作性などを確認するためのものです。

例えば、新しいWebサービスを開発するとします。

いきなりすべての機能を開発するのではなく、まず画面だけを簡単に作って、

• この画面でよいか
• ボタンの配置は分かりやすいか
• ユーザーが迷わず操作できるか
• 顧客が想定していたものと合っているか

などを確認します。

このような試作品がプロトタイプです。

プロトタイプを作る目的

要求を具体化する

プロジェクトの初期段階では、顧客やユーザー自身も「本当に何が欲しいのか」を明確に説明できないことがあります。

文章だけで「このようなシステムが欲しい」と説明しても、完成したものを見たら「思っていたものと違う」ということがあります。

そこでプロトタイプを作ります。

実際に画面や製品のイメージを見ることで、要求を具体化しやすくなります。

「何が欲しいのかを話し合う」のではなく、「実際に見ながら話し合う」ことができるようになるわけです。

認識のずれを発見する

プロジェクトでは、顧客と開発チームの間で認識がずれることがあります。

例えば、顧客が「検索画面が欲しい」と要求したとします。

開発チームは一般的な検索画面を想定して開発を進めるかもしれません。

しかし、顧客が本当に求めていたのは、検索結果を一覧で比較できる画面だったかもしれません。

プロトタイプを見せれば、このような違いを早い段階で発見できます。

問題を早期に発見する

完成してから問題を発見すると、修正に大きなコストがかかる場合があります。

一方、開発初期にプロトタイプで問題を発見できれば、比較的容易に修正できます。

つまりプロトタイプには、手戻りを減らすという役割があります。

ユーザーの反応を確認する

プロトタイプをユーザーに触ってもらうことで、実際の使いやすさを確認することもできます。

開発チームが「使いやすい」と考えていても、実際のユーザーにとっては操作しにくい場合があります。

早い段階でユーザーの意見を取り入れることで、完成後の大幅な修正を防ぎやすくなります。

プロトタイプの種類

プロトタイプには、作り込む程度や目的によってさまざまな種類があります。

低忠実度プロトタイプ

低忠実度プロトタイプは、細部まで作り込まず、簡単な形で作るプロトタイプです。

例えば、紙に画面を書いたものや、簡単なワイヤーフレームなどがあります。

目的は、完成品を再現することではありません。

「どのようなものを作るのか」を早く確認することが目的です。

そのため、短時間で作成でき、変更もしやすいというメリットがあります。

高忠実度プロトタイプ

高忠実度プロトタイプは、実際の製品やシステムに近い形で作るプロトタイプです。

例えば、実際にクリックして画面遷移を確認できるWebサイトの試作品などがあります。

実際の利用イメージを確認しやすい一方、作成には時間やコストがかかります。

使い捨て型プロトタイプ

使い捨て型プロトタイプは、要求や仕様を確認するために一時的に作り、確認が終わったら破棄するタイプです。

目的は完成品を作ることではなく、分からないことを明らかにすることです。

例えば、技術的に実現可能かどうかを確認するために簡単なプログラムを作るケースなどがあります。

進化型プロトタイプ

進化型プロトタイプは、最初に作ったプロトタイプを改良しながら、徐々に実際のシステムへ近づけていく方法です。

要求が変化しやすいプロジェクトや、最初から詳細な要求を定義することが難しいプロジェクトなどで活用できます。

プロトタイプを作る流れ

1．確認したいことを決める

まず、何を確認するためにプロトタイプを作るのかを明確にします。

例えば、

• 要求が正しいか確認したい
• 画面の使いやすさを確認したい
• 技術的に実現可能か確認したい
• ユーザーの反応を確認したい

などです。

ここを明確にしないと、プロトタイプを必要以上に作り込んでしまいます。

2．必要最低限のプロトタイプを作る

次に、確認したいことに必要な範囲だけを作ります。

例えば、画面のレイアウトを確認したいだけなら、裏側のシステムまで完成させる必要はありません。

「確認するために必要な最小限のものを作る」ことがポイントです。

3．関係者に確認してもらう

作成したプロトタイプを顧客やユーザー、プロジェクトメンバーなどに確認してもらいます。

このとき、単に「どうですか？」と聞くのではなく、

• 想定していた操作ができるか
• 分かりにくいところはないか
• 必要な機能が不足していないか
• 想定していた業務を実現できるか

など、確認したいポイントを明確にすると効果的です。

4．フィードバックを反映する

プロトタイプを確認してもらった結果、要求や仕様の修正が必要になることがあります。

その場合は、フィードバックを整理してプロトタイプを修正します。

必要であれば、この確認と修正を何度か繰り返します。

5．本開発につなげる

プロトタイプによって要求や仕様についての理解が深まったら、その結果を本開発へ反映します。

重要なのは、プロトタイプで得られた知見をプロジェクト計画や要求事項に反映することです。

プロトタイプのメリット

認識合わせがしやすい

文章だけでは伝わりにくい内容も、実物に近いものを見れば理解しやすくなります。

特に顧客と開発チームの認識合わせに有効です。

手戻りを減らせる

開発の初期段階で問題を発見できれば、完成後に大幅な修正を行う必要がなくなる可能性があります。

要求の漏れを発見できる

実際の画面や操作を確認することで、「この機能も必要だった」「このケースも考える必要がある」といった要求漏れを発見できます。

ユーザーの意見を取り入れやすい

完成品を待つのではなく、開発の途中でユーザーからフィードバックを得ることができます。

プロトタイプのデメリット

作成に時間とコストがかかる

プロトタイプを作るためには、当然ながら時間や人員が必要です。

確認したいこと以上に作り込んでしまうと、本開発のスケジュールに影響する可能性があります。

プロトタイプが完成品だと誤解される

プロトタイプの見た目が完成品に近い場合、顧客やユーザーが「もう完成している」と誤解することがあります。

そのため、プロトタイプで実現している範囲と、実際の製品で実現する範囲を明確に伝えることが重要です。

プロトタイプを作ること自体が目的になる

プロトタイプを何度も修正しているうちに、必要以上に作り込んでしまうことがあります。

プロトタイプの目的は、完成品を作ることではありません。

不確実な部分を確認し、意思決定に必要な情報を得ることが目的です。

プロトタイプとPoCの違い

プロトタイプと似た言葉にPoCがあります。

どちらも本格的な開発の前に試すという点では共通していますが、目的が異なります。

ただし、実際のプロジェクトでは両者が組み合わされることもあります。

プロトタイプとMVPの違い

MVP（Minimum Viable Product）もプロトタイプと混同されやすい言葉です。

プロトタイプは、基本的に検証や確認を目的とした試作品です。

一方、MVPは、最小限の機能を持った実際にユーザーへ提供できる製品を作り、市場やユーザーから学ぶことを目的とします。

つまり、プロトタイプは「作って確認するもの」、MVPは「最小限の製品として提供して学ぶもの」と考えると分かりやすいでしょう。

プロトタイプとアジャイル

プロトタイプは、アジャイルな開発とも相性が良い考え方です。

アジャイルでは、最初からすべてを詳細に決めるのではなく、短いサイクルで開発・確認・改善を繰り返します。

プロトタイプを活用することで、早い段階でユーザーや顧客からフィードバックを得ることができます。

そのフィードバックを次の開発に反映することで、

作る → 確認する → 学ぶ → 改善する

というサイクルを回すことができます。

プロトタイプを使うべきプロジェクト

すべてのプロジェクトでプロトタイプが必要なわけではありません。

特に有効なのは、次のようなプロジェクトです。

• 要求がまだ曖昧なプロジェクト
• ユーザーのニーズが分かりにくいプロジェクト
• 新しい製品やサービスを開発するプロジェクト
• 画面や操作性が重要なシステム開発
• 技術的な不確実性が高いプロジェクト
• 顧客との認識合わせが難しいプロジェクト

逆に、要求や仕様が明確で、既存の仕組みをそのまま利用できるプロジェクトなどでは、プロトタイプを作るメリットが小さい場合もあります。

プロトタイプを作るときの注意点

目的を明確にする

「とりあえずプロトタイプを作ろう」ではなく、何を確認したいのかを明確にします。

目的が明確なら、必要な範囲だけを作ることができます。

作り込みすぎない

プロトタイプは完成品ではありません。

必要以上に作り込むと、時間やコストを浪費する可能性があります。

「何を確認できれば十分なのか」を考えることが重要です。

プロトタイプの位置付けを共有する

プロトタイプを顧客に見せる場合には、「これは試作品であり、完成品ではない」ということを明確にします。

プロトタイプで実現している機能と、本開発で実現する機能を区別しておくことも重要です。

フィードバックを記録する

プロトタイプを確認した結果、さまざまな意見が出てくることがあります。

それらを記録し、要求や課題、変更事項として適切に管理します。

単に「意見を聞いて終わり」にしないことが重要です。

プロジェクトマネージャにとってのプロトタイプ

プロジェクトマネージャがプロトタイプを活用するときに重要なのは、プロトタイプそのものを作ることではありません。

「何が分からないのか」を明らかにし、その不確実性を減らすためにプロトタイプを使うことです。

例えば、

「顧客がどのような画面を求めているか分からない」

のであれば、画面のプロトタイプを作ります。

「この技術で実現できるか分からない」

のであれば、PoCなどの技術検証を行います。

つまり、問題や不確実性に応じて、プロトタイプを使うか、PoCを行うか、別の方法で確認するかを判断します。

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

プロトタイプについては、完成品を作るための前段階として、要求や仕様などを確認するための試作品と理解しておきましょう。

特に重要なのは、

• 要求を具体化する
• 認識のずれを早期に発見する
• ユーザーのフィードバックを得る
• 手戻りを減らす
• 不確実性を減らす
• 必要以上に作り込まない

という点です。

また、PoCやMVPとの違いを整理しておくと、より理解しやすくなります。

PM道場のワンポイント

プロトタイプは「完成品の練習」ではなく、「分からないことを明らかにするための道具」です。

プロジェクトでは、分からないことを抱えたまま本開発を始めてしまうと、後から大きな手戻りが発生することがあります。

例えば、顧客が「使いやすい画面にしてほしい」と言ったとします。

この「使いやすい」という言葉だけを信じて開発を進めるのではなく、簡単なプロトタイプを作って実際に見てもらいます。

すると、

「検索条件はもっと上にしてほしい」

「このボタンは必要ない」

「検索結果は一覧ではなくカード形式がいい」

など、具体的な意見が出てくるかもしれません。

これらの意見を本開発の後半で聞くより、開発前や初期段階で聞いたほうが、修正のコストは小さくなります。

その意味で、プロトタイプは「早く失敗するための仕組み」とも考えられます。

完成してから「違いました」と分かるより、完成する前に「違う」と分かったほうがいい。

プロジェクトマネージャは、こうした早期の確認によって手戻りを減らすという視点でプロトタイプを活用するとよいでしょう。

関連用語

• PoC
• MVP
• アジャイル
• スクラム
• ユーザーストーリー
• プロダクトバックログ
• 要求事項
• スコープ
• 変更管理
• ステークホルダーエンゲージメント
• 意思決定
• 継続的改善

まとめ

プロトタイプとは、完成前の試作品を作り、要求・仕様・操作性などを確認するためのものです。

プロトタイプを活用することで、

• 要求を具体化できる
• 認識のずれを早期に発見できる
• ユーザーからフィードバックを得られる
• 要求漏れを発見できる
• 完成後の手戻りを減らせる

といったメリットがあります。

一方で、プロトタイプを作り込むほど時間やコストも増えるため、何を確認するために作るのかを明確にすることが重要です。

また、PoCは主に技術やアイデアの実現可能性を検証するもの、MVPは最小限の製品を実際のユーザーに提供して学ぶものという違いがあります。

プロジェクトマネジメントにおいて、プロトタイプは単なる試作品ではありません。

「分からないことを早い段階で確認し、不確実性や手戻りを減らすための道具」です。

プロジェクトの不確実性が高いときには、「このまま進めて大丈夫か？」を確認する手段として、プロトタイプの活用を検討してみましょう。

関連記事

• PoCとは？
• MVPとは？
• アジャイルとは？
• スクラムとは？
• ユーザーストーリーとは？
• プロダクトバックログとは？
• 要求事項とは？
• スコープとは？
• 変更管理とは？
• ステークホルダーエンゲージメントとは？
• 意思決定とは？
• 継続的改善とは？

よくある質問（FAQ）

Q. プロトタイプとは何ですか？

A. 完成前の試作品を作り、要求、仕様、操作性、デザインなどを確認するためのものです。本開発に入る前に不確実な部分を確認するために利用されます。

Q. プロトタイプを作る目的は何ですか？

A. 要求を具体化したり、顧客やユーザーとの認識のずれを発見したり、早い段階で問題を見つけたりすることが主な目的です。

Q. プロトタイプとPoCの違いは何ですか？

A. プロトタイプは要求や仕様、操作性などを確認する目的で使われることが多く、PoCは新しい技術やアイデアが技術的に実現可能かを検証することが主な目的です。

Q. プロトタイプとMVPの違いは何ですか？

A. プロトタイプは検証や確認のための試作品であるのに対し、MVPは最小限の機能を持った製品を実際のユーザーに提供し、ユーザーから学ぶことを目的とします。

Q. プロトタイプは必ず作る必要がありますか？

A. 必ずしも必要ではありません。要求が明確で不確実性が低いプロジェクトでは、プロトタイプを作るメリットが小さい場合もあります。確認すべき不確実性が大きい場合に活用すると効果的です。

Q. プロトタイプはどこまで作り込めばよいですか？

A. 「何を確認したいのか」を判断基準にします。確認に必要な最低限の範囲にとどめ、完成品と同じレベルまで作り込む必要はありません。

The post プロトタイプとは？目的・種類・作り方をわかりやすく解説 first appeared on PM道場.

「複数のベンダーから適切な提案を受けるには、何を伝えればよいのだろう。」

このような場面で作成されるのがRFP（Request for Proposal：提案依頼書）です。

RFPは、発注者がベンダーへプロジェクトの目的や要件を伝え、最適な提案を受けるための重要な文書です。

この記事では、RFPの意味や目的、記載内容、実務での活用方法について解説します。

一言でいうと

RFPとは、「発注者がベンダーに対して、プロジェクトの目的や要件を提示し、提案を依頼するための文書」です。

RFPとは

RFP（Request for Proposal）は、日本語では「提案依頼書」と呼ばれます。

システム開発やインフラ構築などを外部へ委託する際に、発注者がベンダーへ配布します。

ベンダーはRFPをもとに、実現方法や体制、スケジュール、費用などを提案します。

発注者は複数の提案を比較し、最適なベンダーを選定します。

RFPが重要な理由

RFPが曖昧だと、ベンダーごとに異なる前提で提案が作成されます。

その結果、提案内容や見積金額を公平に比較できなくなります。

例えば、次のような問題が発生します。

• 必要な機能が提案に含まれていない
• ベンダーごとに前提条件が異なる
• 見積金額を比較できない
• 契約後に「認識が違った」となる

RFPで要件や期待を明確にすることで、こうしたトラブルを防ぐことができます。

RFPの主な記載内容

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

重要なのは、「どのように作るか」を指定することではなく、「何を実現したいのか」を明確に伝えることです。

RFI・RFP・RFQの違い

一般的には、「RFIで情報収集 → RFPで提案依頼 → RFQで正式な見積取得」という流れで進められます。

PMBOK®︎との関係

PMBOK®︎では、RFPは調達マネジメントで活用される代表的な調達文書の一つです。

プロジェクトで外部調達を行う際には、RFPを活用してベンダーへ提案を依頼し、その内容を評価して契約先を決定します。

RFPは、調達先の選定だけでなく、発注者とベンダーの認識を合わせる役割も担っています。

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

例えば、基幹システムを刷新するプロジェクトを考えます。

企業は複数のベンダーへRFPを配布し、次のような内容を提案してもらいます。

• システム構成
• 導入スケジュール
• プロジェクト体制
• 概算費用
• 導入実績

各社の提案内容を比較した結果、自社に最も適したベンダーを選定しました。

このように、RFPは公平なベンダー選定を行うための重要な資料として活用されます。

よくある勘違い

RFPは見積依頼書ではない

RFPは価格だけを確認するための文書ではありません。

実現方法や体制、スケジュールなどを含めた総合的な提案を依頼する文書です。

詳細設計書ではない

RFPはシステムの詳細設計を記載する文書ではありません。

発注者が実現したい業務や目的を伝え、ベンダーから最適な方法を提案してもらうことが目的です。

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

IPAのプロジェクトマネージャ試験では、外部調達やベンダー選定に関する問題が出題されることがあります。

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

• RFPへどのような要件を記載したか
• どのような基準で提案を評価したか
• ベンダー選定で重視したポイント
• 選定後の認識合わせをどのように行ったか

「RFPを作成した」だけではなく、「公平な提案比較ができるように必要な情報を整理した」と説明できることが評価につながります。

PM道場のワンポイント

RFPは、「ベンダーへ依頼する文書」ではなく、「良い提案を引き出すための文書」です。

要件が曖昧なRFPでは、ベンダーも適切な提案ができません。

一方で、目的や期待する成果が明確なRFPであれば、ベンダーはその実現方法を工夫して提案できます。

優れたプロジェクトマネージャは、「どう作るか」ではなく、「何を実現したいか」を明確に伝えています。

関連用語

• 調達マネジメント
• ベンダー
• 契約
• 要求事項
• スコープ
• ステークホルダー
• RFI
• RFQ

まとめ

RFPとは、発注者がベンダーへプロジェクトの目的や要件を伝え、最適な提案を依頼するための文書です。

重要なのは、価格だけではなく、提案内容や体制、実現方法まで含めて比較できるようにすることです。

プロジェクトマネージャにとって、RFPは外部調達を成功させるための重要な文書と言えるでしょう。

関連記事

• 調達マネジメントとは？
• 要求事項とは？
• スコープとは？
• ステークホルダーとは？
• 契約とは？
• ベンダーマネジメントとは？

よくある質問（FAQ）

Q. RFPとは何ですか？

A. 発注者がベンダーへプロジェクトの目的や要件を提示し、実現方法や体制などの提案を依頼するための文書です。

Q. RFIやRFQとの違いは何ですか？

A. RFIは情報収集、RFPは提案依頼、RFQは見積依頼を目的とした文書です。

Q. RFPで最も重要なことは何ですか？

A. 「どのように作るか」ではなく、「何を実現したいか」を明確に伝え、ベンダーが適切な提案を行えるようにすることです。

The post RFP（提案依頼書）とは？ベンダー選定で重要な役割を果たす文書を解説 first appeared on PM道場.

「重要な変更を説明したつもりだったが、後から反対されてしまった。」

このような問題の多くは、ステークホルダーとの関わり方が十分ではないことが原因です。

そこで重要になるのがステークホルダーエンゲージメント（Stakeholder Engagement）です。

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

一言でいうと

ステークホルダーエンゲージメントとは、「プロジェクトに関わる人々の理解・協力・支援を得ながら、プロジェクトを成功へ導くための活動」です。

ステークホルダーエンゲージメントとは

ステークホルダーエンゲージメントとは、プロジェクトに影響を与える人、または影響を受ける人と継続的にコミュニケーションを取り、適切な関係を築きながらプロジェクトを進めることです。

対象となるステークホルダーには、次のような人々が含まれます。

• 顧客
• スポンサー
• プロジェクトメンバー
• 利用部門
• 協力会社・ベンダー
• 経営層

PMBOK®︎では、ステークホルダーエンゲージメントは独立した知識エリアとして扱われており、プロジェクト成功に欠かせないマネジメント活動とされています。

ステークホルダーエンゲージメントが重要な理由

どれだけ優れた計画を立てても、関係者の理解や協力が得られなければプロジェクトは成功しません。

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

• 利用部門が新システムの導入に消極的である
• スポンサーへ十分な報告が行われていない
• 顧客が仕様変更を理解していない
• 他部署との調整不足で作業が遅れる

このような問題を防ぐためには、必要な情報を適切なタイミングで共有し、信頼関係を築くことが重要です。

ステークホルダーエンゲージメントの進め方

1. ステークホルダーを特定する

まず、プロジェクトに関係する人や組織を洗い出します。

影響力や関心度も整理しておくと、その後の対応を考えやすくなります。

2. 期待や関心事項を把握する

それぞれのステークホルダーが何を期待し、何を懸念しているのかを確認します。

立場によって重視するポイントは異なります。

3. コミュニケーション方法を決める

誰に、何を、いつ、どのような方法で共有するかを決めます。

定例会議、メール、チャット、報告書など、相手に応じた方法を選択することが重要です。

4. 継続的に関係を維持する

ステークホルダーエンゲージメントは、一度説明して終わりではありません。

プロジェクトの状況に応じて継続的に情報共有し、必要に応じて対応を見直します。

ステークホルダーエンゲージメントとステークホルダーマネジメントの違い

PMBOK®︎第7版では、「管理する」という考え方よりも、「関係者と協働しながら価値を生み出す」という考え方がより重視されています。

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

例えば、新しい業務システムを導入するプロジェクトを考えます。

利用部門は現在の業務に慣れているため、新システムへの移行に不安を感じています。

そこでプロジェクトマネージャは、定期的な説明会やデモを実施し、利用者の意見を取り入れながら改善を進めました。

その結果、利用部門の理解と協力を得られ、スムーズにシステムを導入することができました。

このように、関係者との信頼関係を築きながらプロジェクトを進めることが、ステークホルダーエンゲージメントです。

よくある勘違い

情報を伝えるだけでは十分ではない

一方的に報告するだけでは、エンゲージメントとは言えません。

相手の意見や不安を聞き、双方向のコミュニケーションを行うことが重要です。

全員に同じ対応をする必要はない

影響力や関心度はステークホルダーごとに異なります。

そのため、重要な関係者にはより丁寧な説明やコミュニケーションが必要になります。

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

IPAのプロジェクトマネージャ試験では、関係者との調整や信頼関係の構築について頻繁に出題されます。

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

• 重要なステークホルダーをどのように特定したか
• 期待や懸念をどのように把握したか
• どのようなコミュニケーションを実施したか
• その結果、どのような効果が得られたか

「報告した」だけではなく、「関係者の理解と協力を得るために継続的なコミュニケーションを行った」と説明できることが評価につながります。

PM道場のワンポイント

プロジェクトマネージャの仕事は、プロジェクトを管理することだけではありません。人との関係を築くことも重要な仕事です。

計画書が完璧でも、関係者が協力してくれなければプロジェクトは成功しません。

逆に、多少の問題が発生しても、日頃から信頼関係を築いていれば、多くの人が協力してくれます。

優れたプロジェクトマネージャは、成果物だけではなく、人とのつながりも大切にしています。

関連用語

• ステークホルダー
• コミュニケーションマネジメント
• コミュニケーションマネジメント計画書
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• スポンサー

まとめ

ステークホルダーエンゲージメントとは、プロジェクトに関わる人々の理解・協力・支援を得ながら、プロジェクトを成功へ導くための活動です。

重要なのは、情報を伝えることではなく、相手の期待や不安を理解し、継続的なコミュニケーションを通じて信頼関係を築くことです。

プロジェクトマネージャにとって、ステークホルダーエンゲージメントはプロジェクト成功を支える重要なマネジメント活動と言えるでしょう。

関連記事

• ステークホルダーとは？
• コミュニケーションマネジメントとは？
• コミュニケーションマネジメント計画書とは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？

よくある質問（FAQ）

Q. ステークホルダーエンゲージメントとは何ですか？

A. プロジェクトに関わる人々の理解・協力・支援を得ながら、信頼関係を築いてプロジェクトを成功へ導く活動です。

Q. ステークホルダーマネジメントとの違いは何ですか？

A. ステークホルダーマネジメントは関係者全体を管理する考え方、ステークホルダーエンゲージメントは関係者と積極的に関わり、協力を引き出す考え方です。

Q. ステークホルダーエンゲージメントで重要なことは何ですか？

A. 相手に応じたコミュニケーションを継続し、期待や懸念を理解しながら信頼関係を築くことです。

The post ステークホルダーエンゲージメントとは？関係者の協力を引き出すためのマネジメントを解説 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道場.

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

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

この仕組みづくりをコミュニケーションマネジメント（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に必要なのはコミュニケーション能力ではなく、コミュニケーションを設計する力」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし私は、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

しかし、

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

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

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

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

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

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

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

すると、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PMBOK®には、

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

とは書かれていません。

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

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

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

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

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

おわりに

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

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

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

理由は簡単です。

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

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

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

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

あなたへの問いかけ

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

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

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

しかし、「関係者のこと」とだけ理解していると、実際のプロジェクトで重要なポイントを見落としてしまうことがあります。

この記事では、ステークホルダーの意味や具体例、なぜ重要なのか、実務でどのように関わるのかまで、初心者にもわかりやすく解説します。

一言でいうと

ステークホルダーとは、「プロジェクトに影響を与える、またはプロジェクトから影響を受ける人や組織」のことです。

ステークホルダーとは

ステークホルダー（Stakeholder）は、単なる「プロジェクトメンバー」ではありません。

プロジェクトに直接参加していなくても、プロジェクトの結果によって利益や不利益を受ける人や組織もステークホルダーに含まれます。

PMBOK®では、ステークホルダーを特定し、それぞれの期待や影響力を把握しながら関係を築くことが、プロジェクト成功の重要な要素とされています。

ステークホルダーには誰が含まれる？

プロジェクトによって異なりますが、代表的なステークホルダーには次のような人たちがいます。

• スポンサー
• 顧客
• 利用者（エンドユーザー）
• プロジェクトマネージャ（PM）
• プロジェクトメンバー
• 経営層
• 他部門
• 協力会社・ベンダー
• 運用・保守部門
• 行政機関や監査部門（プロジェクトによる）

「この人はプロジェクトに関係ない」と思っていても、後から大きな影響を与えるケースは少なくありません。

なぜステークホルダー管理が重要なのか

プロジェクトが失敗する原因は、技術的な問題だけではありません。

「関係者との認識のズレ」や「期待値の違い」が原因でトラブルになるケースも多くあります。

例えば、顧客は「使いやすさ」を重視している一方で、経営層は「コスト削減」を重視していることがあります。

それぞれの期待を理解せずにプロジェクトを進めると、成果物が完成しても「期待していたものと違う」と評価される可能性があります。

そのため、ステークホルダーの期待や関心事を把握し、適切にコミュニケーションを取ることが重要です。

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

例えば、新しい販売管理システムを導入するプロジェクトでは、次のようなステークホルダーが存在します。

• 営業部：使いやすいシステムを期待している
• 経営層：投資に見合う効果を期待している
• 情報システム部：運用しやすいシステムを求めている
• ベンダー：契約どおりに開発を進めたい

同じプロジェクトでも、それぞれ立場や目的が異なります。

プロジェクトマネージャは、それぞれの期待を理解し、バランスを取りながらプロジェクトを進める必要があります。

ステークホルダーマネジメントとは

ステークホルダーマネジメントとは、ステークホルダーとの関係を計画的に管理する活動です。

主な活動には次のようなものがあります。

• ステークホルダーを洗い出す
• 影響力や関心度を分析する
• 期待を把握する
• コミュニケーション方法を決める
• 定期的に情報共有を行う
• 期待値の変化に応じて対応を見直す

単に情報を伝えるだけではなく、「どのような情報を、誰に、いつ、どのように伝えるか」を設計することが重要です。

よくある勘違い

ステークホルダーは顧客だけではない

顧客だけでなく、経営層、利用者、運用部門、協力会社など、プロジェクトに影響を与えるすべての人や組織が対象になります。

一度洗い出せば終わりではない

プロジェクトの途中で新しい関係者が増えたり、影響力が変化したりすることがあります。

そのため、ステークホルダーは継続的に見直すことが重要です。

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

IPAのプロジェクトマネージャ試験では、ステークホルダーとの合意形成や利害調整は頻出テーマです。

午後Ⅱ論文では、「どのような関係者がいて、それぞれの期待をどのように調整したか」を具体的に説明できることが重要です。

また、PMBOK®では「ステークホルダー・パフォーマンスドメイン」が設けられており、ステークホルダーとの関係構築がプロジェクト成功に直結するとされています。

PM道場のワンポイント

ステークホルダーを管理するとは、「人を管理すること」ではありません。本当に管理すべきなのは、「期待値」です。プロジェクトで「そんな話は聞いていない」「思っていたものと違う」といったトラブルが起きるのは、多くの場合、期待値の認識がそろっていないことが原因です。

そのため、優れたプロジェクトマネージャは、人を動かそうとするのではなく、期待値をそろえるためのコミュニケーションを設計しています。

関連用語

• プロジェクト
• プロジェクトマネージャ（PM）
• スポンサー
• コミュニケーションマネジメント
• ステークホルダーエンゲージメント
• RACI
• ガバナンス
• プロジェクト憲章

まとめ

ステークホルダーとは、プロジェクトに影響を与える、または影響を受ける人や組織のことです。

プロジェクトを成功させるためには、関係者を把握するだけでなく、それぞれの期待や関心を理解し、適切なコミュニケーションを取ることが重要です。

ステークホルダーマネジメントは、人を管理することではなく、「期待値をマネジメントすること」と考えると、本質が理解しやすくなります。

関連記事

• プロジェクトとは？
• プロジェクトマネジメントとは？
• スポンサーとは？
• コミュニケーションマネジメントとは？

よくある質問（FAQ）

Q. ステークホルダーとは簡単にいうと何ですか？

A. プロジェクトに影響を与える、またはプロジェクトから影響を受ける人や組織のことです。

Q. ステークホルダーは顧客だけですか？

A. いいえ。スポンサー、経営層、プロジェクトメンバー、利用者、ベンダー、運用部門などもステークホルダーに含まれます。

Q. ステークホルダーマネジメントで最も重要なことは何ですか？

A. 関係者ごとの期待や関心を理解し、適切なタイミング・方法でコミュニケーションを行い、認識をそろえることです。

The post ステークホルダーとは？意味や具体例を初心者向けにわかりやすく解説 first appeared on PM道場.

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

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

特に重要なのは「効果的に関与させる＝エンゲージメント」。

ステークホルダーに効果的にどのように関与させるかを論理的に説明しましょう。

結論：ステークホルダーは影響力とQCDを関連付ける

評価されるポイントはシンプルです。

• QCD（品質・コスト・納期）で説明できているか
• ステークホルダーの影響力を踏まえているか
• コミュニケーションに根拠があるか

つまり、
「誰が・どの程度・QCDに影響するか」を書ければ強いです

設問ア：プロジェクトは“定量情報”で説明する

以下2点について説明します。 設問イ以降の論述にあたり、前提となる情報を説明する必要があります。 わかりやすく、定量的に説明することを意識しましょう。

• ①システム開発プロジェクトの概要と目的
• ②主要ステークホルダが目標の達成に与える影響

① プロジェクト概要と目的はQCDを定量的に

プロジェクトの概要と目的について説明しますが、具体的に定量的に説明しましょう。QCDの観点で説明すると良いです。この後、ステークホルダが目標の達成に与える影響について説明することになるので、この時点で定量的に説明できると納得感を与えられる論述ができます。

必ずQCDで定量化します。

例：

• 品質：障害件数を30％削減
• コスト：予算1,000万円以内
• 納期：6か月以内にリリース

② ステークホルダの影響がQCDにどのように影響を与えるかが重要

主要なステークホルダーが目標に与える影響を述べます。まず、主要なステークホルダーが誰なのか、プロジェクトにどのように関与するのか（関心度、影響力）をわかりやすく説明しましょう。いわゆるステークホルダー登録簿にまとめる内容です。

• 誰か（例：営業部長、利用部門）
• 関心度（高・中・低）
• 影響力（強・中・弱）

さらにどのように目標に影響を与えるのかを具体的、定量的に示しましょう。特にQCDに対する影響を論じられると良いです。プロジェクトマネージャはプロジェクト成功に向けて、QCDをマネジメントする必要があるからです。

QCDにどう影響するかを書くことが重要。

• 営業部長：納期短縮要求 → スケジュール圧迫
• 利用部門：品質重視 → テスト工数増加

設問イ：期待のズレは“QCDの差分”で示す

計画段階における以下3点について説明します。

• ①確認したステークホルダの過大な期待や相反する期待の内容
• ②それらによって目標の達成が妨げられる恐れがあると判断した理由
• ③目標の達成が妨げられないように積極的に行ったコミュニケーション

① 過大・相反する期待はQCDの観点で定量的に

ステークホルダの過大な期待や相反する期待の内容について、設問アで説明した目標と比較して論じましょう。特にステークホルダの期待がどのようにQCDに影響を与えられるか定量的に数字で比較して説明できると良いです。

例：

• 目標：6か月
• 営業：3か月を要求

差分：3か月（＝納期リスク）

② 妨げになると判断した理由は関与度に関連させる

目標の達成が妨げられる恐れがあると判断した理由について論じます。ステークホルダがプロジェクトにどのように関与するのか（関心度、影響力）に関連させて説明しましょう。例えば影響力が大きければ、それだけ目標の達成が妨げられる可能性が大きくなります。

例：営業部長は

• 影響力が強い
• 意思決定権を持つ
• 現場に指示できる

営業部長は最終決裁者であり、要求がそのまま計画に反映される可能性がある。

③ 実施したコミュニケーションはステークホルダーの特性に合わせる

目標の達成が妨げられないように積極的に行ったコミュニケーションでは、ステークホルダーの特性を根拠に論じましょう。対面を望むステークホルダであれば対面、文章で残すことを望むステークホルダであればメールなど、活用したツールも合わせて説明できると良いです。この辺りは、ステークホルダエンゲージメント計画で検討するところ。どのように効果的にプロジェクトに参加してもらうか。プロジェクトマネージャだけでなくプロジェクトメンバーにも適切なコミュニケーションを取ってもらえるように計画することが重要です。

ポイントは「相手に合わせる」です。ステークホルダーを効果的に関与させるためにどうすればよいかを説明できると良いです。

例：

• 対面重視 → 会議・説明会
• 記録重視 → メール・資料共有

ポイント：

• なぜその手段を選んだか
• 実施頻度（週1回など）
• 使用ツール（Teams、メールなど）

設問ウ：不一致は“原因の深掘り”で差がつく

実行段階における以下2点について説明します。

• ①実行段階において生じた認識の不一致とその原因
• ②認識の不一致を解決するために積極的に行ったコミュニケーション

① 認識の不一致と原因は深堀りする

具体的に不一致の内容を説明しましょう。その原因もなぜなぜ分析をした内容を説明できると良いです。つまり、直接的原因だけでなく、そのさらに深い要因まで分析した内容を説明しましょう。

例：

• 不一致：テスト完了の定義が違う
• 原因：定義が文書化されていない
• 原因：部門ごとに基準が異なる
• 原因：初期合意が不十分

② 解決のためのコミュニケーションは具体的に

コミュニケーションの内容として、どのようなコミュニケーションを行ったのか、なぜそのコミュニケーションにしたのか、コミュニケーションを行った結果はどうだったのかを説明しましょう。

ここでもステークホルダーを効果的に関与させるための施策を説明しましょう

ポイント：

• 何をしたか
• なぜそれを選んだか
• 結果どうなったか

例：

• 定義を文書化しレビュー実施
• 認識統一が必要と判断
• 全関係者で合意形成できた

ステークホルダーエンゲージメントの本質

関係者を巻き込んで成功させることが重要です。

• 相手の期待を理解する
• 影響力を見極める
• 適切な方法で関与させる

チーム全体でコミュニケーションを取る設計が重要です。

まとめ

• 設問ア：QCDで定量的に書く
• 設問イ：期待のズレを数値で示す
• 設問ウ：原因は深掘りする

ステークホルダーマネジメントでは「ステークホルダーをどのように効果的に関与させるか」を語ることが重要です。

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

新入社員2年目、幹部報告に向けた資料作成で、私は何度も同じ修正を繰り返していました。

課長に直され、部長にひっくり返される。
完成したと思ったら、また振り出しに戻る。

結果的に評価は良かったものの、振り返ると明らかに“無駄な努力”が多かったと感じます。

原因はシンプルでした。
ステークホルダーマネジメントができていなかったことです。

結論｜ステークホルダーを整理しないと必ず手戻りが発生する

関係者を整理せずに進めると、必ず意見の衝突で詰みます。

なぜなら、

• 立場によって求めるものが違う
• 権限によって意見の重さが違う
• 関与度によって口出しの頻度が違う

私はこれを理解せず、全員の意見をそのまま受け取ってしまいました。

その結果、
「誰の意見を優先するか」が決められず、地獄のループに突入しました。

地獄の始まり｜課長と部長の意見が真逆だった話

問題が発生したのはレビュー工程です。

流れはこうでした。

• 指導員 → OK
• 課長 → 修正
• 部長 → さらに修正（しかも真逆）

例えばこんな感じです。

• 課長：「もっと現場寄りで具体的に」
• 部長：「いや、抽象化して全体最適を見せろ」

両方を満たすのは不可能

それでも私は、
「どちらも正しい」と思い込み、両方を反映しようとしました。

すると、
修正 → 否定
修正 → また否定

最悪の場合、「最初の状態に戻る」こともありました。

気づけば、何度も徹夜。

でもこれは、努力不足ではなくやり方の問題でした。

さらにカオス｜“みんなの意見”を聞いた結果

追い打ちをかけたのがリハーサルです。

同じ部署のメンバーから、次々と意見が出ます。

• ここ分かりにくい
• もっとこうした方がいい
• この表現は微妙

一見ありがたいですが、問題はここからです。

• 課長 → 賛成
• 部長 → 反対

意思決定者がブレる状態になっていました。

この時の私は、

• 全ての意見を取り入れようとする
• 優先順位をつけられない

という完全な迷子状態でした。

本当の原因｜ステークホルダーを理解していなかった

問題は「誰の意見を聞くか」を決めていなかったことです。

当時のステークホルダーを整理すると以下の通りです。

関係者の整理

• 指導員
  関与度：大 / 権限：中 / 関心：大
• 課長
  関与度：中 / 権限：中 / 関心：中
• 部長
  関与度：小 / 権限：大 / 関心：小
• 部署メンバー
  関与度：小 / 権限：小 / 関心：小
• 幹部
  関与度：小 / 権限：大 / 関心：小

こうすれば良かった｜正しい立ち回り

優先順位の設計

• 指導員：軸として相談
• 課長：事前に方向性を握る
• 部長：最終アウトプットを意識
• 他メンバー：参考程度

具体的な動き

• 課長と部長の方向性を事前にすり合わせ
• どちらを優先するか明確にする
• 全員の意見を採用しない

権限が強い人の期待を先に満たすことが重要です。

それでも得られたもの｜評価は高かった理由

最終的に幹部からは、
「理路整然としていて良い」
という評価をもらえました。

ただしこれは、

• 運良く整っただけ
• 効率的だったわけではない

と感じています。

新入社員に伝えたいこと

• 誰が意思決定者かを把握する
• 誰の意見を優先するか決める
• 全員を満足させようとしない

これだけで、無駄な徹夜はなくなります。

まとめ

ステークホルダーマネジメントは難しい理論ではありません。

• 誰が重要か
• 何を求めているか

これを整理するだけです。

仕事の最初に「人」を整理するクセをつけること。
これが一番の近道です。

The post ステークホルダーマネジメントの話 first appeared on PM道場.