ストーリー
田
田中VPoE
VSMで組織の課題を可視化できた。次に重要なのは「誰を巻き込むか」だ
あなた
改善に関係するチームのリーダーを集めればいいんじゃないですか？
あ
田
田中VPoE
それだけでは足りない。組織横断の改善には、直接関わる人だけでなく、間接的に影響を受ける人、意思決定権を持つ人、リソースを配分する人…多くのステークホルダーがいる。そして、それぞれ立場も利害も異なる
あなた
全員の合意を得るのは大変そうですね
あ
田
田中VPoE
全員の合意は不要だ。重要なのは、各ステークホルダーの影響力と利害関係を分析し、適切な巻き込み戦略を立てることだ。それがステークホルダーマッピングだ
ステークホルダー分析の基本
ステークホルダーの4分類
影響力（Power）と関心度（Interest）の2軸でステークホルダーを分類します。
高い関心度
│
Aゾーン: │ Bゾーン:
満足させ続ける │ 緊密に連携する
（経営層の一部）│ （CTO、対象チームリーダー）
│
低い影響力 ────────┼──────── 高い影響力
│
Cゾーン: │ Dゾーン:
最小限の対応 │ 常に情報提供する
（無関係な部門）│ （人事部、経理部）
│
低い関心度| ゾーン | 影響力 | 関心度 | 戦略 |
|---|---|---|---|
| A | 低 | 高 | 情報共有し、味方として巻き込む |
| B | 高 | 高 | 最重要。緊密に連携し、意思決定に参加してもらう |
| C | 低 | 低 | 最小限の対応。必要時のみ情報提供 |
| D | 高 | 低 | 定期的に情報提供し、不意の反対を防ぐ |
ステークホルダーマップの作成
Step 1: ステークホルダーを洗い出す
組織横断改善における典型的なステークホルダー:
| カテゴリ | ステークホルダー | 役割 |
|---|---|---|
| 意思決定者 | CTO / VPoE / 部門長 | 投資判断、リソース配分 |
| 推進者 | 改善リーダー、テックリード | 計画策定、実行推進 |
| 実行者 | 各チームのエンジニア | 改善施策の実装 |
| 影響を受ける人 | 他部門のメンバー | プロセス変更の影響を受ける |
| 支援者 | 人事、経理、法務 | 制度面、予算面の支援 |
| 外部 | ベンダー、顧客 | 外部への影響 |
Step 2: 各ステークホルダーの利害を分析する
ステークホルダー利害分析テンプレート:
┌─────────────────────────────────────────────┐
│ ステークホルダー: CTO 鈴木 │
├─────────────────────────────────────────────┤
│ 立場: 技術戦略の最終意思決定者 │
│ 関心事: 開発生産性、技術的競争力、コスト │
│ 改善から得られる利益: 開発速度向上、品質改善 │
│ 改善によるリスク: 短期的な開発停滞、移行コスト │
│ 現在の態度: やや前向きだが慎重 │
│ 影響力: 極めて高い │
│ 必要なアクション: ROIを定量的に示す │
└─────────────────────────────────────────────┘Step 3: 利害関係マトリクスを作成する
| ステークホルダー | 改善によるメリット | 改善によるデメリット | 現在の態度 | 望ましい態度 |
|---|---|---|---|---|
| CTO | 開発速度30%向上 | 短期的な投資コスト | やや前向き | 強力な支援者 |
| 開発チームリーダーA | チームの生産性向上 | プロセス変更の負荷 | 前向き | 推進者 |
| 開発チームリーダーB | チームの生産性向上 | 既存ワークフローの変更 | 懐疑的 | 中立以上 |
| QAマネージャー | テスト効率化 | 役割の変化への不安 | 不安 | 協力的 |
| インフラリーダー | 運用負荷の軽減 | 新ツール習得コスト | 中立 | 協力的 |
| 経営企画 | 開発コスト削減 | なし | 無関心 | 情報を得ている |
RACI チャート
組織横断改善において、誰が何の責任を持つかを明確にするRACIチャートを作成します。
| 役割 | 意味 | 説明 |
|---|---|---|
| Responsible | 実行責任 | 実際にタスクを実行する人 |
| Accountable | 説明責任 | 最終的な意思決定と承認を行う人 |
| Consulted | 相談先 | 実行前に意見を求められる人 |
| Informed | 報告先 | 実行後に結果を報告される人 |
RACI チャートの例
| 活動 | 改善リーダー | CTO | 開発リーダーA | QAマネージャー | インフラリーダー |
|---|---|---|---|---|---|
| 改善計画策定 | R | A | C | C | C |
| パイロット実施 | R | I | R | C | C |
| ツール選定 | R | A | C | C | R |
| プロセス変更 | R | A | R | R | R |
| 効果測定 | R | I | C | C | C |
| 全社展開判断 | C | A | C | C | C |
「RACIチャートで最も重要なのは、Accountableが各活動に必ず1人だけいること。2人いると意思決定が曖昧になる。0人だと誰も決定しない」 — 田中VPoE
ステークホルダーエンゲージメント戦略
エンゲージメントレベル
| レベル | 説明 | 対応方法 |
|---|---|---|
| 反対 | 改善に積極的に反対している | 個別面談で懸念を聞き、対応策を示す |
| 抵抗 | 消極的に抵抗している（協力しない） | メリットを具体的に説明し、小さな成功体験を見せる |
| 中立 | 関心がない | 改善が自分にもたらす影響を説明する |
| 支持 | 改善に前向き | 推進者として巻き込む |
| リード | 改善を主導したい | 責任と権限を与える |
コミュニケーション計画
| ステークホルダー | 頻度 | 手段 | 内容 |
|---|---|---|---|
| CTO（Bゾーン） | 隔週 | 1on1 | 進捗、成果、リスク、意思決定事項 |
| 対象チームリーダー（Bゾーン） | 週次 | 定例会議 | 詳細進捗、課題共有、合意形成 |
| 経営企画（Dゾーン） | 月次 | レポート | サマリーと効果指標 |
| 関連チームメンバー（Aゾーン） | 隔週 | Slack/メール | 進捗報告、フィードバック収集 |
まとめ
| ポイント | 内容 |
|---|---|
| ステークホルダー分類 | 影響力×関心度の4ゾーンで分類し、ゾーンごとに戦略を変える |
| 利害分析 | 各ステークホルダーのメリット・デメリット・態度を把握する |
| RACI | 責任と役割を明確化し、意思決定の曖昧さを排除する |
| エンゲージメント | 反対→抵抗→中立→支持→リードのレベルを引き上げる |
チェックリスト
- ステークホルダーの4分類（影響力×関心度）を理解した
- ステークホルダー利害分析の方法を把握した
- RACIチャートの作り方と注意点を理解した
- エンゲージメントレベルとコミュニケーション計画を理解した
次のステップへ
次は演習です。ここまで学んだ問題分析、バリューストリームマッピング、ステークホルダーマッピングを使って、実際の組織シナリオの課題を可視化しましょう。
推定読了時間: 30分