ステークホルダーが多い案件で使う合意ルート図の作り方と運用ポイント

ステークホルダーが多い案件でなぜ混乱が起きるのか

ステークホルダーが多い案件では、プロジェクトの難しさは技術だけで決まりません。むしろ、誰にどう説明し、誰の理解を得て、どの順番で承認や相談を進めるかが曖昧なことによって、混乱が起きるケースが非常に多くあります。

たとえば、現場部門、利用部門、情報システム部門、セキュリティ部門、法務、経営層、ベンダーなど、多くの関係者がいる案件では、それぞれの立場や関心事が異なります。現場は使いやすさを重視し、情報システム部門は運用性を重視し、法務は契約や規約の整合性を見ます。経営層は投資対効果や全社方針との整合を気にします。

このとき怖いのは、「関係者一覧はあるが、どう合意形成するかは決まっていない」状態です。
誰が決裁者なのかは分かっていても、その前に誰へ説明し、誰の懸念を先に潰し、どの会議体に上げれば通りやすいかが整理されていないと、次のような問題が起こります。

• 重要な人への説明が後手に回る
• 一度合意したと思った内容が後から覆る
• 会議に出ていなかった人から差し戻される
• 承認者に上げる前の根回し不足で却下される
• 同じ説明を何度も別々の相手に行うことになる

つまり、案件が進まない原因は「合意が取れていないこと」そのものだけではなく、合意に至る道筋が見えていないことにあります。
そこで有効なのが、“合意ルート図”です。

合意ルート図とは何か

合意ルート図とは、案件において「誰に、どの順番で、何を目的に説明・相談・確認・承認していくか」を見える化した図のことです。

似たものにステークホルダー一覧やRACIがありますが、合意ルート図はそれらとは少し役割が異なります。

ステークホルダー一覧は、関係者を洗い出すためのものです。
RACIは、作業や意思決定に対する役割分担を整理するためのものです。
一方で合意ルート図は、合意形成の流れそのものを整理するためのものです。

たとえば、以下のようなことを明確にします。

• 最終承認者は誰か
• 承認前に説明しておくべき人は誰か
• 先に懸念を潰すべき部門はどこか
• どの会議体で報告・審議するか
• どのタイミングでベンダーを交えるか
• どの論点を誰に確認するか

これにより、プロジェクトマネージャーやリーダーは「次に誰へ何を持っていくべきか」が明確になります。関係者の多い案件ほど、場当たり的な説明ではなく、順序立てた合意形成が重要です。

合意ルート図の目的は、単に図を作ることではありません。目的は、合意形成の抜け漏れと手戻りを減らすことです。
そのため、見栄えよりも、実際に動ける内容になっていることが大切です。

合意ルート図を作る前に整理すべきこと

合意ルート図は、いきなり図を書き始めると失敗しやすいです。先に整理すべきポイントがあります。

何について合意を取るのかを明確にする

まず最初に、「今回の合意対象は何か」を明確にします。
なぜなら、合意の対象によって関係者もルートも変わるからです。

たとえば、以下はそれぞれ関係者が変わります。

• プロジェクトの立ち上げ承認
• 要件確定
• 予算追加
• スケジュール変更
• 本番リリース判断
• 外部委託契約の締結
• 運用移管の承認

合意ルート図は、プロジェクト全体で1枚あれば十分とは限りません。大きな案件では、「立ち上げ用」「要件確定用」「リリース判定用」など、テーマ別に分けた方が使いやすいこともあります。

関係者を役割で分類する

次に、関係者を名前ベースではなく役割ベースで整理します。
人名だけで整理すると、異動や体制変更するごとに見直す必要が出てきます。

分類例としては以下のようなものがあります。

• 最終決裁者
• 実質承認者
• 事前相談が必要な相手
• 意見影響力が強い相手
• 実務レビュー担当
• 情報共有だけでよい相手
• 外部関係者

ここで重要なのは、肩書だけで判断しないことです。正式な決裁者ではなくても、実質的に意見が強く、事前に納得してもらわないと前へ進まない人物がいることは珍しくありません。
合意ルート図は組織図ではなく、案件を通すための実態図として作る必要があります。

各関係者の関心事を把握する

誰に説明するかだけでなく、その人が何を気にするかも整理します。
同じ資料を全員に見せても、見る観点が異なることがあるためです。

たとえば、

• 経営層：費用対効果、リスク、対外影響
• 利用部門：業務影響、使い勝手、教育負荷
• 情報システム部門：運用保守、障害対応、既存システムとの整合
• セキュリティ部門：権限管理、ログ、脆弱性対策
• 法務：契約条件、規約、責任分界点

この関心事が分かっていると、誰に何を先に説明すべきかが見えてきます。

合意ルート図の作り方

ここから、実際の作り方を順番に説明します。

最終ゴールを置く

最初に、図の右端または上端に「最終的に誰の何の承認が必要か」を置きます。
ここが曖昧だと、途中ルートも定まりません。例を記載します。

• 事業部長の要件承認
• 情報システム責任者の導入承認
• 経営会議での投資承認
• 本番移行判定会でのGo判断

つまり、合意ルート図は終点から考えるのが基本です。

その承認に必要な事前説明先を洗い出す

次に、その最終承認が通るために、事前に納得しておくべき相手を洗い出します。
ここで考えるべきは、単なる参加者ではなく「承認に影響する人」です。

たとえば経営会議に上げる前に、

• 主管部門長の了承
• 情報システム部門の見解取得
• セキュリティ審査通過
• 概算費用の確認
• ベンダー見積条件の整理

などが必要になるかもしれません。

順番を決める

洗い出しができたら、次は順番を決めます。
この順番が合意ルート図の最重要ポイントです。

順番を決めるときの考え方は次の通りです。

• 後から覆りやすい重大論点を先に潰す
• 反対されやすい部門には早めに相談する
• 承認者に上げる前に、実務レビューを終える
• 会議体の開催タイミングに合わせる
• 説明相手ごとに必要資料を変える

たとえば、経営層に先に説明したくなることがありますが、現場やシステム部門の論点整理が終わっていないと、そこで宿題だらけになり逆に遅くなります。
多くの場合は、実務論点の整理 → 影響部門とのすり合わせ → 管理職承認 → 上位会議体の順が安定します。

線に意味を持たせる

図にする際は、ただ矢印でつなぐだけでなく、線に意味を持たせると実務で使いやすくなります。

たとえば、

• 実線：承認
• 点線：事前相談
• 赤線：必須レビュー
• 色分け：部門別
• 矢印横の注記：確認論点

といった形です。

「説明した方がよい」相手と「ここを通さないと進めない」相手が同じ見え方だと、図が役に立ちません。

1人1人ではなく会議体も書く

関係者が多い案件では、個人だけでなく会議体を書くことが重要です。
実際の承認やレビューは、個人面談より会議体で行われることが多いからです。

例

• 部門定例会
• プロジェクト推進会議
• セキュリティ審査会
• 投資審議会
• リリース判定会

これを入れておくと、いつ何を持ち込むかの実務計画にもつながります。

合意ルート図に入れるべき項目

合意ルート図はシンプルでよいですが、最低限入れたい項目があります。

相手の名称

部署名、役割名、会議体名を明記します。人名だけにしない方が運用しやすいです。

関与の目的

その相手に何を求めるのかを書きます。
例：承認、相談、レビュー、情報共有、判断材料提供。

主な確認論点

その相手が何を見るのかを短く添えます。
例：業務影響、運用負荷、予算妥当性、契約条件。

タイミング

いつ確認するかも重要です。
例：要件定義完了前、見積取得後、リリース1か月前。

成果物

何を持って説明するかを決めておくと、実行しやすくなります。
例：要件一覧、費用対効果資料、リスク一覧、運用設計書。

このあたりまで入ると、単なる関係図ではなく、動かせる管理ツールになります。

合意ルート図を実務で運用するときのポイント

図は作って終わりではありません。運用してこそ意味があります。

まず大事なのは、合意ルート図をスケジュールと連動させることです。
どれだけよい図でも、確認のタイミングが工程表に入っていなければ実行されません。主要な説明・レビュー・承認のポイントは、マスタースケジュールや直近計画に落とし込みます。

次に、論点ごとに説明順を変えることです。
すべてを同じルートで流す必要はありません。たとえば、予算変更は管理職ライン中心、運用設計は情報システム部門中心、業務変更は利用部門中心になることがあります。案件全体で1枚、論点別で補足数枚という持ち方も有効です。

また、反対意見や懸念を記録しておくことも重要です。
合意形成で怖いのは、表面上は了承されたのに、後で「そんな話は聞いていない」「前提が違う」と言われることです。そのため、説明時の懸念、宿題、条件付き了承の内容を残しておくと、後のトラブルを防ぎやすくなります。

さらに、体制変更に合わせて更新することも忘れてはいけません。
組織変更、異動、会議体変更があれば、合意ルートはすぐ古くなります。重要案件ほど、定期的に見直した方が安全です。

よくある失敗パターン

合意ルート図は便利ですが、作り方を間違えると逆効果です。よくある失敗を押さえておきましょう。

1つ目は、関係者を並べただけで順番がないことです。
これでは一覧表と変わらず、次に何をすべきか分かりません。

2つ目は、正式権限だけを見て実質影響者を外してしまうことです。
現場キーマンや部門補佐役など、実質的に止める力を持つ人を見落とすと、後で止まりやすくなります。

3つ目は、全員に同じ資料を出すことです。
相手ごとに知りたいことが違うため、資料や説明の切り口は調整した方が通りやすくなります。

4つ目は、一度作ったら更新しないことです。
案件のフェーズが変われば、合意すべきテーマも相手も変わります。

5つ目は、図が複雑すぎて誰も使えないことです。
情報を盛り込みすぎると、読むだけで疲れる図になります。まずは主要ルートをシンプルに描き、必要なら補足資料で詳細化する方がよいです。

初学者向けの簡単な作成手順

初めて作る場合は、次の手順で十分です。

まず、「今回通したいことは何か」を1つ決める。
次に、「最終的に誰がOKと言えば進むか」を書く。
その後、「その人がOKを出す前に納得していてほしい人」を洗い出す。
さらに、「順番を間違えると揉めそうな相手」を前に置く。
最後に、「各相手に何を確認するか」を一言ずつ書く。

このレベルでも、頭の中だけで進めるよりずっとやりやすくなります。
特に、関係者が5人を超える案件では、図にした方が抜け漏れに気づきやすくなります。

まとめ

ステークホルダーが多い案件では、誰が関係者かを把握するだけでは不十分です。重要なのは、どの順番で、誰に、何を確認しながら合意を積み上げるかを見える化することです。

そのために有効なのが合意ルート図です。
合意ルート図を作ることで、承認の前に誰へ相談すべきか、どの論点をどこで潰すべきか、どの会議体にいつ上げるべきかが整理され、説明漏れや差し戻し、不要な手戻りを減らせます。

作成時のポイントは、最終承認から逆算すること、関係者を役割と影響力で整理すること、順番に意味を持たせること、そして運用できる粒度でシンプルに作ることです。

ステークホルダーが多い案件ほど、プロジェクトを前へ進める力は資料の美しさではなく、合意形成の設計にあります。
案件が複雑であるほど、まずは「誰にどう通すか」を図にしてみるところから始めると、プロジェクト運営はかなり安定しやすくなります。