このユニットの結論
大規模なプロジェクトでは、「体制図に載っている人」だけが関係者ではありません。
影響を受ける人・決める人・作る人・支える人を洗い出し、「誰が、何に、どれだけ影響するか」を地図にして初めて、伝える相手と決めてもらう相手が決まります。地図にない人は、あとで必ず現れます。
1. 何の話か
このユニットは、プロジェクトの関係者（ステークホルダー）をどう洗い出し、どう整理するかの話です。
関係者とは、プロジェクトの結果に影響を受ける人、プロジェクトの進め方に影響を与えられる人のことです。経営層、業務部門、情報システム部門、ベンダー、監査、取引先、そして最後に画面を使う人まで含みます。
2. なぜ必要か
関係者を洗い出さずに進めると、
- 要件を聞いていない部門が、稼働の直前に「それでは業務が回らない」と言ってくる
- 決めてもらうべき人に話が届いておらず、決めたつもりのことが覆る
- 影響を受ける取引先への連絡が抜け、切替の日に混乱する
ということが起きます。約120人規模のプロジェクトでは、関係者は社内外に数百人に及びます。記憶では管理できません。
3. このユニットで分かること
- 関係者をどう洗い出すか
- 「影響の大きさ」と「関心の強さ」で関係者をどう分けるか
- 分けた結果を、体制図と役割分担にどうつなげるか
4. 関係者を洗い出す 4 つの入口
一般的には、次の 4 つの入口から洗い出します。
| 入口 | 例（一般的な例） | 見落としやすい人 |
|---|---|---|
| 結果に影響を受ける | 業務部門の担当者、取引先、顧客 | 月に 1 回しか使わない部門、派遣・委託の担当者 |
| 進め方に影響を与える | 経営層、投資を承認する人、監査 | 法務・内部統制の担当、労働組合 |
| 作る・運ぶ | ベンダー、情報システム部門、運用の担当 | 保守が終わる旧システムのベンダー |
| 間接的につながる | 連携する他システムの持ち主、外部サービスの提供元 | データを受け取っている子会社や関連会社 |
洗い出しは一度で終わりません。要件定義・設計・移行の各段階で「新しく現れた関係者はいないか」を問い直します。
5. 影響と関心の 2 軸で分ける
洗い出した関係者を、影響の大きさ（その人の判断や協力が、プロジェクトをどれだけ左右するか）と関心の強さ（その人がプロジェクトにどれだけ注意を向けているか）の 2 軸で 4 つに分けます。
- 影響大・関心強：一緒に決める相手。定期的に会い、判断に加わってもらう
- 影響大・関心弱：満足させておく相手。重要な節目で報告し、驚かせない
- 影響小・関心強：知らせ続ける相手。情報を届け、意見を聞く
- 影響小・関心弱：見ておく相手。変化がないかだけ確かめる
分け方は固定ではありません。移行が近づけば、業務部門の関心は急に強くなります。地図は定期的に描き直します。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の関係者に関する記載
- アステリア側の名前が確定している人物は 13 人：P-001 佐伯 隆志 — CFO／プロジェクトスポンサー、P-002 高瀬 真理 — CIO／IT統括責任者、P-003 西村 俊介 — プログラムマネージャー、P-004 田辺 彩 — PMOリーダー、P-005 藤本 遥 — 経理業務リーダー、P-006 川村 美咲 — プロジェクト管理業務リーダー、P-007 松本 健太 — 営業・契約業務リーダー、P-008 黒田 健 — システムアーキテクト、P-009 橋本 奈緒 — データ移行リーダー、P-010 宮田 直人 — テスト・品質管理リーダー、P-011 山下 恵 — 本番移行・運用リーダー、P-012 石井 稔 — セキュリティ責任者、P-013 木村 亮 — AIガバナンス責任者
- ベンダー側の PM は 3 人：P-A01 井上 健一 — Vendor A PM、P-B01 吉田 圭介 — Vendor B PM、P-C01 大森 裕 — Vendor C PM
- Vendor は 4 社（Vendor D のPM は記録なし）。約120人規模のプロジェクト、マルチベンダー
正本に名前があるのは 16 人だけです。約120人のメンバー、業務部門の担当者、取引先、監査など、ほかの関係者の名前・人数・関心は記録がありません。記録なし 16 人が「影響と関心」のどこに位置するかも記録がありません。記録なし
6. THINK — 「体制図に載っている人で足りる」
プロジェクトの初期に、PMO のメンバーが次のように言いました。
「関係者は体制図に載っている人たちです。それ以外の人に話を聞く時間はありません。」
問題
この進め方で、要件定義を始めてよいでしょうか。
判断例を開く
判断
体制図は「作る側の組織」です。影響を受ける人の全体ではありません。
確認すること:
- 新しいシステムの結果（画面、帳票、データ）を受け取る部門をすべて挙げたか
- 連携する他システムの持ち主と、外部サービスの提供元を挙げたか
- 承認や監査の立場で関わる人（投資、内部統制、法務）を挙げたか
- 旧システムを止めることで影響を受ける人を挙げたか
- 挙げた人を「影響と関心」で分け、会う頻度を決めたか
体制図の外の関係者に話を聞く時間は、あとで要件が覆る時間より短くて済みます。
7. よくある失敗
- 作る側の体制図をそのまま関係者一覧にし、影響を受ける側が抜ける
- 一度洗い出したきり更新せず、移行の直前に「聞いていない」部門が現れる
- 関心の弱い経営層を「忙しいから」と報告から外し、節目で驚かせる
- 関係者の数が多すぎて全員に同じ頻度で会おうとし、誰にも十分に会えない
8. 成果物との接続
- PRG-003 プロジェクト体制図：作る側の組織と報告の線。関係者の地図のうち「作る・運ぶ」の部分
- PRG-004 役割・責任分担表：決める人・実行する人・相談を受ける人・知らされる人を、仕事ごとに決める
関係者の地図は体制図より広く、役割分担表は地図のうち「決める・実行する」の部分を細かくしたものです。
9. AI WORKFLOW — 洗い出しの抜けを探させる
AIは、業務フローや要件の一覧から「この業務に関わる部門・外部」の候補を挙げ、関係者一覧との差を探す下書きに役立ちます。
指示例:
「次の業務フローの説明を読み、登場する部門・役割・外部の相手を漏れなく挙げてください。次に、添付の関係者一覧と突き合わせ、一覧にない部門・役割・相手を示してください。重要度や対応方針は判断しないでください。」
10. REVIEW — AIの候補を確認する
- AIが挙げた部門・役割が、業務フローに実際に登場しているか
- 一覧にない候補について、本当に関わるかを業務部門に確かめたか
- AIに渡した業務フローに、個人名や顧客名が含まれていないか
11. 人間が判断すること
- 誰を「一緒に決める相手」にするか
- 影響が大きい関係者に、いつ・何を報告するか
- 洗い出しをどの段階で描き直すか
12. 判断演習
あなたの職場で、ある業務システムを入れ替えると想像してください。
「結果に影響を受ける」「進め方に影響を与える」「作る・運ぶ」「間接的につながる」の 4 つの入口から、関係者を合計 10 以上挙げてください。そのうち、普段のプロジェクトで忘れられやすいと思うものに印を付け、理由を書いてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
関係者は体制図より広い。影響と関心の 2 軸で分け、会う頻度と伝える内容を変える。地図は節目ごとに描き直す。