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

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

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

一言でいうと

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

合意形成とは

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

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

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

合意形成が重要な理由

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

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

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

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

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

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

合意形成の進め方

1. 関係者を明確にする

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

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

2. 情報を共有する

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

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

3. 意見を整理する

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

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

4. 意思決定を行う

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

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

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

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

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

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

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

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

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

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

よくある勘違い

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

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

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

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

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

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

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

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

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

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

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

PM道場のワンポイント

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

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

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

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

関連用語

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

まとめ

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

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

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

関連記事

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

よくある質問（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道場.

「何かあれば早めに共有してください。」

プロジェクトではよく聞く言葉です。

しかし実際には、「何をもって困ったと言えるのか」は人によって判断が異なります。

あるメンバーは30分で相談します。

一方で、あるメンバーは3日間悩み続けます。

これでは、相談するタイミングは個人の判断に依存してしまいます。

そこで重要になるのが、「問題が起きる前兆」を設計することです。

前兆はプロジェクトによって違う

前回の記事では、助けを求めるシグナルを標準化する重要性について紹介しました。

しかし、「何をシグナルにするのか」はプロジェクトによって大きく異なります。

つまり、すべてのプロジェクトに共通する前兆は存在しません。

PMは、そのプロジェクトで何が問題の前兆になるのかを考え、設計する必要があります。

ウォーターフォール型のシステム開発で見られる前兆

例えば、ウォーターフォール型のシステム開発では、次のような前兆があります。

• レビュー指摘件数が急に増えた
• 同じ仕様への質問が繰り返される
• WBSは完了しているのにレビューが終わらない
• タスクの更新が止まっている

これらは、まだ問題ではありません。

しかし、後になって品質問題や納期遅延につながる可能性があります。

EPCプロジェクトで見られる前兆

私が多く経験してきたEPCプロジェクトでは、少し違う前兆があります。

• 他部署からの回答が返ってこない
• 承認待ちが長期間続く
• 設計変更依頼が増えてきた
• 資材納期が変更になった

どれも、その時点では問題になっていません。

しかし放置すると、工程全体へ影響します。

だからこそ、この段階で関係者が集まり、相談や調整を始める必要があります。

アジャイル開発でも前兆は存在する

アジャイル開発では毎日コミュニケーションがあります。

それでも、問題の前兆は存在します。

• 同じタスクが何日も「進行中」のまま
• デイリースクラムで毎日同じ内容を話している
• レビュー待ちが増えている
• ベロシティが急に落ちた

このような変化は、チームが何かにつまずいているサインかもしれません。

前兆には共通する4つの型がある

プロジェクトによって前兆は異なります。

しかし整理してみると、大きく4つの型に分類できると私は考えています。

① 時間

一定期間、状態が変わらないことです。

例

• 承認待ちが3日以上続く
• タスク更新が止まっている
• 回答待ちが長期化している

② 数量

件数や量が急に変化することです。

例

• レビュー指摘件数
• 不具合件数
• 設計変更件数

③ 状態

本来あるべき状態から外れていることです。

例

• レビュー未実施
• Blocked状態
• テスト未着手

④ 変化

普段とは違う変化が起きることです。

例

• 質問が急に増える
• 会議への参加者が減る
• 進捗が急に悪化する

PMが本当に設計するべきもの

ここまで考えると、PMの役割は問題が起きた後に対応することではありません。

また、メンバーへ「早めに相談してください」とお願いすることでもありません。

本当に設計するべきなのは、

「この前兆が現れたら、相談・レビュー・調整を始める。」

というルールです。

つまり、

前兆 → コミュニケーション

を設計することです。

これが、人に依存しないコミュニケーションマネジメントにつながります。

まとめ

相談のタイミングを人に任せると、どうしても遅れが発生します。

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

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

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

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

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

おわりに

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

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

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

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

The post プロジェクトによって「相談のタイミング」は違う。だからPMは「前兆」を設計する。 first appeared on PM道場.

夫は良かれと思って言っています。

疲れているのも分かっている。
少しでも助けになればと思っている。

でも、その言葉を聞いた妻は、

「いや、“手伝う”じゃないんだよ……」

と、なぜかモヤっとする。

一方で夫は思います。

• 「ちゃんと気を遣ってるのに」
• 「手伝おうとしてるのに」
• 「なんで不機嫌になるんだ……？」

このすれ違いは、子育て家庭ではかなり「あるある」ではないでしょうか。

そして厄介なのは、どちらも悪気がないことです。

夫はサボろうとしているわけではありません。
妻も責めたいわけではありません。

なのに、なぜか家庭の空気が悪くなる。

実はこれ、単なる「家事分担」の問題ではありません。

もっと根深い、「家庭運営の構造」の問題なのです。

家事には「作業」と「管理」がある

例えば、夫がこう言います。

「洗濯やっといたよ！」

とても助かります。

でもその裏で、妻はこう考えているかもしれません。

• 子供服のサイズは足りていたっけ？
• 明日の保育園の準備はどうする？
• タオルは乾いている？
• オムツの残りが少なかったな
• 連絡帳をまだ書いていない

つまり家庭には、

「手を動かす作業」

だけではなく、

「抜け漏れが起きないように考え続ける管理」

が存在しています。

そして、この「管理」がとても重いのです。

本当に疲れるのは「ずっと考えていること」

子育て中は、脳内のタスクが常に開きっぱなしです。

• 牛乳がなくなりそう
• 保育園の提出物はいつだっけ？
• 次の予防接種を予約しないと
• 子供服はサイズアウトしていない？
• 明日は雨だから着替えを追加した方がいいかも

気づけば頭の中は、家庭運営のタスク管理でいっぱいになります。

しかも厄介なのは、この負荷が外から見えないことです。

洗濯したことは見えます。

掃除したことも見えます。

でも、

「常に考え続けていること」

は見えません。

だから、

「俺、結構やってるよ？」

と、

「私ばっかり考えてる……」

が同時に成立してしまうのです。

「手伝う」という言葉の正体

ここで冒頭の言葉に戻ります。

「何か手伝おうか？」

この言葉は、無意識のうちに、
「メイン担当はあなた」
という前提を含みやすい言葉です。

つまり、

• 何をやるべきか決める人
• 優先順位を考える人
• 抜け漏れを防ぐ人

が固定化されます。

夫は「作業」を手伝っている。
でも妻は、「家庭全体の管理」をしている。

この構造になると、管理側は休めません。

なぜなら、

「考えること」

が終わらないからです。

会社ならすぐ分かる

これは仕事で考えると分かりやすいです。

例えば部下が毎回、

• 「次、何やればいいですか？」
• 「他にありますか？」
• 「終わりました！」

と言ってくる。

もちろん助かります。

でも上司は、

• 次のタスクを決める
• 優先順位を整理する
• 抜け漏れを確認する

という仕事を、ずっと続ける必要があります。

つまり、「実作業」より「管理」の方が疲れることがあるのです。

家庭でも同じです。

「気づいた人がやる」は危険

家庭でよくあるルールです。

「気づいた人がやればいいよね」

一見すると平和に見えます。

でも実際には、

「気づく人」が固定化します。

例えば、

• トイレットペーパーの補充
• 子供服のサイズ確認
• 保育園の提出物
• 食材の在庫管理

こうしたことに常に気づく人がいるのです。

つまり、

「気づいた人がやる」は、
「気づき続ける人が背負う」
になりやすいのです。

家庭に必要なのは「手伝い」ではなく「担当」

ここで大切なのが、

「手伝う」から「担当を持つ」へ変わることです。

例えば、

• 保育園準備担当
• 洗剤管理担当
• ゴミ出し管理担当

のように、

「自分で気づき、自分で管理する領域」
を持ちます。

すると、

• 指示待ちが減る
• 管理負荷が分散する
• 精神的負担が軽くなる

という効果が期待できます。

ただし、完璧を目指さない

ここはとても大切です。

家庭は会社ではありません。

厳密に役割を管理しすぎると、逆に苦しくなります。

大切なのは、

「どちらが悪いか」ではなく、

「どうすれば家庭がラクに回るか」

を考えることです。

家庭は、超高難易度のチーム運営

最近よく思います。

家庭は、実はものすごく難しいチーム運営です。

しかも、

• 24時間稼働
• 正解がない
• 感情がある
• 子供という予測不能な要素がある

かなりの高難易度プロジェクトです。

だからこそ必要なのは、

「頑張り続けること」

ではなく、

「無理なく続けられる仕組み」

なのかもしれません。

そして、「何か手伝おうか？」という何気ない一言には、
そんな家庭運営の難しさが詰まっているように感じます。

The post “手伝おうか？”が家庭を苦しくする理由 first appeared on PM道場.