「キックオフを終えてから別部署のキーマンが出てきて、要件が引っくり返った」。受託開発のPMをやっていれば、一度はこの種の地雷を踏んだことがあるのではないでしょうか。原因の多くは、立ち上げ初期にステークホルダーの整理が浅かったことです。
関係者を後から発見するたびに、合意は崩れ、スケジュールは伸び、メンバーの士気は削れていきます。逆に言えば、最初の1週間で関係者マップを描き切れているプロジェクトは、その後の意思決定が驚くほどスムーズに進みます。
本記事では、受託開発に特化した「発注者側・自社側・外部」の3層ステークホルダーマップと、関係者を巻き込む順序を決めるための5ステップを紹介します。新人〜若手PMが、案件立ち上げ初期にそのまま使えるテンプレートとして読んでください。
なぜ受託開発のステークホルダーは漏れるのか
受託開発の関係者整理が難しいのは、「契約上の窓口」と「意思決定の実体」がズレているからです。窓口担当者は契約書に書いてあるので必ず把握しますが、要件を承認する人、運用後に文句を言う人、社内ルールで止める人は契約書には載っていません。
関係者が漏れたまま走り出すと、典型的にはこんなことが起こります。
- 要件定義が終わったあとに情報システム部門の技術基準が出てきて、設計をやり直す
- ユーザー受入テストの直前に「事業部の役員レビューがまだ」と言われる
- 自社側で営業が握っている口頭約束を、PMが知らずに違反する
- 外部のSaaSベンダーや決済代行への確認が後手に回り、結合テストが止まる
これらに共通するのは、「最初に書いた関係者リストが、当事者目線で網羅されていなかった」という一点です。網羅性を担保するには、思いつきで書き出すのではなく、層で区切って探しに行く必要があります。
発注者側・自社側・外部の3層マップ
ステークホルダーマップには様々な型がありますが、受託開発では3層に区切るのが最も漏れにくい構造です。それぞれの層で「誰を、なぜ、いつ巻き込むか」を整理します。
3層の全体像
| 層 | 含まれる関係者 | このPMがやるべきこと |
|---|---|---|
| 発注者側 | 発注窓口、業務部門責任者、意思決定者、エンドユーザー、情報システム部門、監査・法務 | 要件・承認・受入のキーマンを早期に特定する |
| 自社側 | 営業、PMO・上長、開発リーダー、インフラ担当、品質保証、経理 | 内部の握りと体制・コストの整合を取る |
| 外部 | 再委託先、SaaS・パッケージベンダー、監修者、クライアントの取引先 | 契約と納期に影響する第三者を可視化する |
「発注者側」だけでも、契約上の窓口と意思決定者が別人であることは珍しくありません。「自社側」を軽視するPMも多いのですが、営業が顧客に握っている内容や、PMOが見ている損益ラインを把握していないと、PM単独の判断で炎上します。「外部」は忘れがちですが、SaaSの仕様変更1つでスケジュールが崩れる時代なので、必ず1層として独立させてください。
各層をさらに分解する観点
3層の中身を埋めるときは、次の観点で「不足していないか」を自問してください。
- 役割視点：要件を出す人、承認する人、使う人、運用する人、止める権限を持つ人
- 時間軸視点：要件定義時、開発中、受入時、運用開始後に登場する人
- 影響度視点：意思決定権あり、拒否権あり、影響度大の発言力あり
この3視点で抜け漏れチェックをすると、「営業部長は要件には出てこないけれど、検収時に必ず巻き込む必要がある」といった時間差で出てくるキーマンを捕捉できます。これだけでも、後半の手戻りはかなり減ります。
なお、3層マップを描いたら必ず「要件定義の合意形成に必要な人」だけ抜き出した別ビューを作っておきましょう。要件定義の伝達経路が曖昧だと、結局「誰のレビューを通せば確定なのか」が決まらず迷走します。要件定義の伝わらなさそのものに悩んでいる方は、なぜあなたの要件定義はエンジニアに伝わらないのか？元エンジニアPMが明かす5つの根本原因と処方箋 も参照すると、関係者整理と要件伝達がつながって理解できます。
3層マップを単体で描けるようになると、案件立ち上げの精度は一段上がります。さらにケース演習で「巻き込み判断」を体に染み込ませたい方には、IPJ-106 ステークホルダーマネジメント実践 を覗いてみてください。
巻き込み順序を決める5ステップ
マップを描いただけでは関係者管理は機能しません。「誰から、いつ、どの粒度で接触するか」を順序立てて決めることで、初めて巻き込み力になります。受託開発の現場で再現性のある5つのステップを紹介します。
ステップ1. 意思決定の経路を1本だけ確定させる
最初に、「最終承認者は誰で、その手前のレビュー経路はどう流れるのか」を1本に絞って書き出します。窓口担当者→業務部門責任者→事業部役員→稟議、のように直線で書くのがコツです。直線が描けないなら、まだ関係者ヒアリングが足りていません。
ステップ2. 影響度と関与度でランク付けする
3層マップに載せた全員を、プロジェクトを止める力である「影響度」と、実務に関わる頻度である「関与度」の2軸でランク付けします。影響度・関与度ともに高い人がコアステークホルダー、影響度だけ高い人は監査・法務・役員などのゲート型、関与度だけ高い人はエンドユーザー側の現場担当者です。それぞれで接触頻度を変える必要があります。
ステップ3. 「断られたら困る順」に接触する
接触順序は、断られたら最も影響が大きい人から順に並べます。一般的には、意思決定者→業務部門責任者→情報システム部門→自社営業やPMO→開発リーダー→外部ベンダー、という流れになります。受託開発でありがちなのは、開発リーダーや外部ベンダーから先に握ってしまい、後から発注者側の上位レイヤーに引っくり返されるパターンです。順序を逆にしないでください。
ステップ4. 1週間で「初回接触」を全員済ませる
立ち上げ1週間以内に、コアステークホルダー全員と一度は顔を合わせることを目標にします。ここでの目的は要件確認ではなく、「あなたを認識しています」と伝え、相手から「このPMには言っておきたいことがある」を引き出すことです。1週間を超えると、別ルートで情報が流れ始め、後から修正が効かなくなります。
ステップ5. 週次レビューでマップを更新する
ステークホルダーマップは常に変化するものです。プロジェクトが進むにつれて、検収担当が変わったり、運用部門の責任者が新たに登場したりします。週次の進捗会議で5分だけ「マップに変化がないか」を確認する時間を設けてください。これを習慣化するだけで、後半フェーズの「実は…」を激減させられます。
なお、進捗会議そのものが形骸化していると、マップ更新も機能しません。定例の運用に課題を感じているなら、進捗管理が形骸化する受託PMへ｜定例で詰まらない3ステップ実行フロー もあわせて読むと、関係者管理と進捗管理の両方がうまく回るようになります。
立ち上げ1週間で描き切るためのチェックリスト
ここまでの内容を、立ち上げ初日から1週間で実行するチェックリストとして並べておきます。新しい案件に入った日、このリストを上から潰してください。
- 【初日】契約書・提案書・営業引き継ぎ資料から、登場する関係者を全員洗い出す
- 【2日目】3層マップ（発注者側・自社側・外部）に分類し、役割・時間軸・影響度の3視点で抜け漏れ確認
- 【3日目】意思決定経路を1本に確定し、コアステークホルダーを5〜8名に絞る
- 【4〜5日目】影響度の高い順に初回接触を完了させ、相手の懸念事項をメモに残す
- 【6〜7日目】マップとメモを上長・営業・開発リーダーにレビューしてもらい、見落としを潰す
このリストを完了できれば、案件立ち上げの第一関門は突破です。あとは週次でマップを更新し続けるだけで、関係者起因の手戻りは大幅に減らせます。
迷ったらこの講座から始める
ステークホルダーマップの描き方そのものをケース演習で身につけたい方は、IPJ-106 ステークホルダーマネジメント実践 からはじめてください。本記事で示した3層マップと巻き込み順序を、複数の受託開発ケースに当てはめて練習できる構成になっています。
案件立ち上げの全体像を体系的に学び直したい方には、PJM-102 案件立ち上げの進め方 が最短ルートです。ステークホルダー整理だけでなく、契約・スコープ・体制・スケジュールを立ち上げ1週間で揃える型を、PMが実務で使う順番のまま学べます。
新人PMほど「関係者整理は経験で覚えるもの」と思いがちですが、型を持っている人ほど早く自走できるのが現場の真実です。次の案件立ち上げで、3層マップと5ステップを試してみてください。