Claude Codeでステークホルダー一覧とRACI自動生成｜新任PMの関係者設計実装レシピ

新任PMが最初につまずくのは、計画でも見積でもなく、**「誰に話を通すべきか」**です。決裁者を取り違える、キーマンを見落とす、承認順序を間違える——これだけで案件の初動が2〜3週間遅れます。

「ステークホルダー設計はベテランPMの暗黙知」と言われがちですが、形式的に分解するとほとんどがパターン化できます。本当に効くのは、Skillに組織図と案件スコープを読ませ、ステークホルダー候補とRACI表を自動ドラフトすることです。

この記事では、Claude Codeで関係者設計の初動を半自動化する実装を、現場で動かせる粒度で解説します。

なぜステークホルダー設計は属人的なのか

新任PMがステークホルダー設計でつまずくのは、能力ではなく構造的な問題です。

組織図が頭に入っていない：誰が何の決裁権を持つか分からない
隠れキーマンを見落とす：肩書では分からない実務責任者を捉えられない
RACI表を作っても使われない：作成して終わり、運用に乗らない

Claude Codeは、Skillに組織図YAMLと案件スコープを読ませ、関係者候補とRACI表をドラフトすることで、ベテランPMが頭の中でやっていることを再現可能な形にできます。

Claude Codeを「関係者設計支援器」にする全体像

必要な要素は次の3つです。

組織図YAML：docs/org/structure.yaml に役職・部門・決裁範囲を構造化
ステークホルダー設計Skill：案件スコープから関係者候補とRACIを生成
CLAUDE.mdステークホルダー運用ルール：自社の決裁ルール、隠れキーマンを拾う観点を明記

これが揃うと、新任PMでも案件キックオフ前に「関係者リスト」と「RACI叩き台」が手元に揃います。

ステップ1：組織図をYAML化する

docs/org/structure.yaml を整備します。社外秘なので運用は慎重に。

divisions:
  - name: "情報システム本部"
    head: "本部長X"
    decision_scope:
      - "システム投資の最終決裁（5000万以上）"
      - "全社ITポリシー策定"
    departments:
      - name: "基盤運用部"
        head: "部長A"
        functions: ["インフラ", "セキュリティ", "認証基盤"]
        decision_scope:
          - "本番環境の構成変更承認"
      - name: "業務システム部"
        head: "部長B"
        functions: ["会計", "販売", "在庫"]
        decision_scope:
          - "業務システム要件の最終確定"
hidden_keyperson_hints:
  - "認証基盤に関わる案件は基盤運用部の主任Cに必ず初動で相談する"
  - "会計連携は経理部のシステム担当主任Dの了解が事実上必須"

hidden_keyperson_hints がベテランPMの暗黙知を構造化する場所です。肩書では分からない実務責任者をここに集約します。

ステップ2：ステークホルダー設計Skillを作る

.claude/skills/stakeholder-raci/SKILL.md を用意します。

---
name: stakeholder-raci
description: 案件スコープと docs/org/structure.yaml を参照し、ステークホルダー候補とRACI表のドラフトを tmp/stakeholders/{project-id}.md に出力する
disable-model-invocation: true
allowed-tools: Read, Write
---

# ステークホルダー・RACI設計Skill

## 入力
- `tmp/stakeholders/{project-id}-scope.md`：案件スコープ要約

## 処理
1. スコープから案件のドメイン（システム種別・対象部門）を特定
2. structure.yamlから関連する部門と役職を抽出
3. hidden_keyperson_hintsを参照し、隠れキーマンを追加候補に
4. 案件の主要アクティビティ（要件定義/設計/承認/受入/運用引継）×ステークホルダーで RACI マトリクスを作成
5. 各ステークホルダーに次のメタを付与
   - role: スポンサー/承認者/協力者/被影響者
   - decision_scope_overlap: 案件と決裁範囲の重なり
6. PMが追加検討すべき論点を末尾に列挙

## 出力フォーマット
- ファイル：`tmp/stakeholders/{project-id}.md`
- 章立て：①関係者一覧（役割別） ②RACI表 ③隠れキーマン候補（理由付き） ④PMが追加検討すべき論点 ⑤PM判断欄（**空欄**）

## 厳守
- 個人名・連絡先を勝手に推測しない（structure.yamlに無い人は「要確認」と表記）
- decision_scope外のステークホルダーをR/A（Responsible/Accountable）に割り当てない
- ⑤PM判断欄をAIが埋めない

「個人名を推測しない」が安全装置。組織図にない人をAIが補完すると誤情報の温床になります。

ステップ3：CLAUDE.mdにステークホルダー運用ルールを書く

## ステークホルダー・RACI運用ルール

### 自社の決裁ルール
- 5000万以上の投資：情報システム本部長
- 1000万以上：部長級
- 500万以下：課長級
- システム本番環境変更：基盤運用部長の承認必須

### 隠れキーマンを拾う観点
- 認証・セキュリティ案件：基盤運用部の実務担当主任を必ず初動で確認
- 会計連携案件：経理部のシステム担当主任の了解を取る
- 全社展開案件：労組・人事との初期相談を欠かさない

### RACI割当のルール
- A（Accountable）は1人だけ。複数立てない
- R（Responsible）は実行者ベースで割当（PMはAになる）
- C（Consulted）は意思決定前に意見を聞く必要がある人
- I（Informed）は決定後に通知する人

### AIに任せないこと
- 個人名の特定（必ずPMが組織図確認）
- A（Accountable）の最終確定（事業文脈が必要）

CLAUDE.mdに「決裁ルール」と「隠れキーマンを拾う観点」を書くことで、新任PMでもベテランの判断軸を学べる構造にします。

ステップ4：実際の運用フロー

新規案件のキックオフ準備フローは次の通りです。

キックオフ2週間前：PMが tmp/stakeholders/PROJ-2026-scope.md にスコープを書く
キックオフ1.5週間前：/stakeholder-raci PROJ-2026 を実行 → 関係者リストとRACI叩き台が出る
キックオフ1週間前：上長レビュー、隠れキーマンの妥当性確認、関係者への根回し開始
キックオフ当日：RACI確定版を関係者全員に共有、合意を得る

新任PMでも、関係者設計の初動を1週間で終えられるようになります。

期待効果と運用上の注意点

導入チームから報告される効果は3点です。

新任PMの立ち上げが早くなる：暗黙知が形式化され、ベテランの判断軸を学べる
関係者の取りこぼしが減る：隠れキーマンHintsが効く
RACI表が運用される：作成プロセスが軽くなり、案件ごとに必ず作るようになる

落とし穴は3つ。

structure.yamlの更新を怠らない：組織変更のたびに更新しないと精度が落ちる
個人名を勝手に補完させない：Skill側で「要確認」と表記する設計を徹底
A（Accountable）を複数立てない：意思決定の所在が不明確になる

まとめ

ステークホルダー設計の属人化は組織図の暗黙知化が原因
structure.yamlとhidden_keyperson_hintsで暗黙知を形式化できる
AIには関係者候補とRACI叩き台の生成までを任せ、最終確定はPMが行う
新任PMでも初動でベテラン判断軸に乗せられる仕組みが、組織の機動力を底上げする

ここまでで「動くステークホルダー設計支援器」は手に入ります。実務でこれを“合意形成の運用”に育てるには、ステークホルダー戦略、政治的力学の読み解き、合意プロセス設計といった上位設計が必要です。

IPJ-106『ステークホルダー設計』と PJM-102『新任PMの立ち上げ』を組み合わせると、本記事のSkillをベースに、関係者設計と立ち上げ初動を体系で学べます。新任PMが最短で「動ける関係者設計」に到達するための導線です。