stakeholder-identification について
優先順位付けや働きかけの計画に先立ち、プロダクトチームが関係者を洗い出すための構造化スキルです。関係区分や資源・許可・決定権のタグに公平性の視点を加え、見落とされがちな集団と優先対象を明らかにします。
主な機能
- 01制約を設けない関係者の洗い出し
- 02協力者・対象者・影響者の分類
- 03資源・許可・決定権のタグ付け
- 04公平性の視点による影響確認
- 05優先対象と調査事項の整理
活用シーン
- 01製品施策の関係者マッピング
- 02リストから漏れた影響対象の発見
- 03優先順位付けや働きかけの準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ deanpeters/ product-manager-skills --skill stakeholder-identificationインストール後、Claude Code で/stakeholder-identificationを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
template.mdexamples/sample-industrial.mdsample.md詳細
ステークホルダーの特定
目的
誰かに関わる前に、すべてのステークホルダーを洗い出します。このスキルでは、スポンサーやユーザーのような明白な相手だけでなく、門番となる人々、影響を受けるコミュニティ、チームが見落としがちな声まで含めた、包括的で公平性を考慮したステークホルダーの一覧を作成します。
多くのプロダクトマネージャーが作るステークホルダー一覧は、5分で記憶を頼りに書かれたものです。そこには、経営幹部、プロダクトチームの同僚、声の大きいユーザーは確実に含まれます。一方で、組織内で意思決定に影響を与える力を持たないまま、プロダクトの結果を受け入れることになる、社会的に周縁化されたユーザーグループは確実に見落とされます。このスキルでは、より時間をかけて体系的にブレインストーミングを行い、その後のあらゆるエンゲージメントの判断の土台を築きます。
優先順位を決めるstakeholder-mappingの前、またステークホルダーごとの働きかけを計画するstakeholder-engagement-advisorの前に使います。まず特定する必要があります。名前を挙げていない人の優先順位は決められません。
入力
最適な入力: ステークホルダーを洗い出す対象となる取り組み、プロダクト、または意思決定。 あると役立つ入力: すでに挙げているステークホルダー(このスキルは抜けている人を見つけるためのものです)、組織の状況、影響を受けるコミュニティ。
スキルの呼び出しと一緒に渡された内容(スキル名に続くテキスト、貼り付けられたコンテキスト、または末尾に追加されたARGUMENTS:行など)は、すでに回答された情報として扱います。それを使い、該当する内容については質問し直さないでください。
何も用意していなくても大丈夫です。 このスキルでは、取り組みの内容と影響を受ける人を尋ねたうえで、公平性を考慮した洗い出しを行います。
呼び出し例: Identify stakeholders for migrating all customers to the new billing system by Q4.
重要な概念
協力者、対象者、影響者 — あなたの取り組みとの関係を明確にする3つのカテゴリーです。協力者は取り組みを積極的に支援し、対象者はその影響を受け、影響者は直接的な影響を受けずに意見や意思決定を左右します。ステークホルダーをこのように分類すると、誰を巻き込むべきか、誰に情報を伝えるべきか、誰を説得すべきかが明らかになります。これらはそれぞれ異なるエンゲージメントの役割です。
R/P/Dの印付け — 各ステークホルダーが、リソース(予算、人員、アクセス)、許可(進行の承認、規制上の認可)、または意思決定権限(最終決定権)の提供者であることを示します。これにより、単に関心があるだけの人と、取り組みに資金を出したり、阻止したり、承認したりできる人をすばやく見分けられます。1人のステークホルダーが複数の印を持つ場合もあります。
公平性の視点 — 見落とされがちなステークホルダー、すなわち社会的に周縁化されたユーザー集団、現場の従業員、下流のコミュニティ、プロダクトの結果を受け入れる一方で、その設計に影響を与える組織内の力を持たない人々を、意図的に一覧に加えます。この手順がなければ、チームは声が大きく、リソースに恵まれた人々に最適化し、声の小さい多数派の期待に応えられないプロダクトを作ってしまいます。
一次、二次、三次の影響 — 直接のユーザーから間接的に影響を受けるグループへと、プロダクトが波及させる影響をたどります。サポート担当者の業務を変える機能は(一次)、顧客がサービスをどう体験するかに影響し(二次)、それが会社の評判や解約率に影響します(三次)。この連鎖をたどることで、単一の階層だけで考えていては見つからないステークホルダーを洗い出せます。
偏見と前提への気づき — チームで明示的に確認します。私たちは誰を当然のように挙げたでしょうか。一覧にいないのは誰でしょうか。誰の視点を普遍的なものとして扱っているでしょうか。この手順では、見落としが要件の抜けにつながる前に、盲点を明らかにします。
特定と優先順位付け — どのような人が関係するかを見極めることと、誰を最も重視するかを決めることを分けるための規律です。このスキルの目標は、優先順位付けされた一覧ではなく、網羅的な一覧を作ることです。この2つの手順をまとめてしまうと、まだ理解していないステークホルダーをチームが早々に除外してしまいます。優先順位付けはstakeholder-mappingで行います。
適用
ステップ 1 — 絞り込まずにブレインストーミングする
この取り組みに関わりのある、個人、チーム、組織、コミュニティなど、潜在的なステークホルダーを自由にすばやく書き出します。自分で内容を取捨選択しないでください。関わる可能性がありそうな人は、関与が unlikely に思えても、すべて書き留めます。
グループで作業する場合は、共有する前に 4〜6 分間、各自で黙って書き出します。
ステップ 2 — カテゴリ分けする
各ステークホルダーを、次のカテゴリの 1 つ以上に分類します。
- 協力者 — この取り組みを積極的に支援している、または成功によって利益を得るのは誰ですか?
- 対象者 — 結果によって直接的、または間接的な影響を受けるのは誰ですか?
- 影響力を持つ人 — 直接の参加者ではなくても、意思決定、意見、導入に影響を与えるのは誰ですか?
注:1 人のステークホルダーが複数のカテゴリに該当することもあります。主要な影響力を持つ協力者のように、カテゴリが重なる相手は、関係構築の効果が最も大きい相手であることがよくあります。
ステップ 3 — R/P/D の印を付ける
各ステークホルダーについて、次の要素を提供するかどうかを記します。
- R — リソース(予算、人員、データ、アクセス)
- P — 許可(承認、法的許可、正式承認)
- D — 意思決定権(範囲、優先順位、または公開に関する最終決定権)
P または D を持つステークホルダーがリストにいない場合、後になって障害となる抜け漏れです。
ステップ 4 — 公平性の視点を取り入れる
リストについて、次の質問をします。
- このプロダクトによって、経済面、職業面、または日常生活において、大きな違いや影響を受けるのは誰ですか?
- デザインに影響を与える力がないまま、プロダクトのコストやリスクを負うのは誰ですか?
- 他の誰かが代弁していると思い込んだために、視点が欠けているのは誰ですか?
- 主なユーザーは誰ですか? 二次的なユーザーは誰ですか? 三次的な影響を受ける人は誰ですか?
公平性の視点から見つかった人を追加します。これらのステークホルダーは、ステークホルダー・マッピングの Q1(影響が大きく、権力が小さい)に該当する可能性が高く、特に声を届けることが重要な人たちです。
ステップ 5 — 偏りや思い込みに気づく
グループで、次の質問に明確に答えます。
- ステップ 1 では、誰の名前を真っ先に挙げましたか?
- 誰が抜けていますか? その理由は何ですか?
- 誰をステークホルダーとみなすかについて、どのような思い込みがありましたか?
回答を記録します。これらは調査計画と参加者募集の方針に反映されます。
ステップ 6 — 優先対象を絞り込む
リスト全体を見ながら、先に進む前に最も深く理解する必要があるステークホルダーを 2〜3 人特定します。通常、次のような人たちです。
- 賛同を得る必要がある、最も大きな権限を持つ意思決定者
- ニーズへの理解が最も不十分な、影響を最も強く受けるユーザー
- 障害となる可能性が最も高い人、または懐疑的な人
優先度の高い各ステークホルダーについて、名前、カテゴリ、R/P/D のタグ、および「この人から何を学ぶ必要があるか」を 1 行で記録します。これらの成果物は、stakeholder-mapping と stakeholder-engagement-advisor に直接反映されます。
例
状況: あるプロダクトチームが、手作業によるメールベースの依頼をセルフサービス型のポータルに置き換える、新しい受付ワークフローの検討を進めています。最初に挙がったステークホルダーは、オペレーション担当副社長、エンジニアリングリード、PMO ディレクター、エンタープライズ顧客です。
不十分なリスト(よくある初期案): このリストには、明らかな支援者と、この機能を最も強く求めた顧客層が含まれています。抜けているのは、現在すべての手作業による依頼を処理しているカスタマーサポート担当者(現行ワークフローの主要な日常ユーザー)、IT セキュリティチーム(P — データの取り扱いを承認する必要があります)、コンプライアンス責任者(P — 規制上の影響があります)、セルフサービス型ポータルを利用する技術スタッフがいない小規模事業者の顧客(影響は大きいものの、権限は小さい対象者)です。
公平性の観点を適用し、R/P/D の印を付けた後の、より良いリスト:
- オペレーション担当副社長(D、協力者) — 最終的なスコープ決定権者
- エンジニアリングリード(R、協力者) — 対応能力と技術的な実現可能性
- PMO ディレクター(P、影響力を持つ人) — プロセス変更の承認が必要
- エンタープライズ顧客(対象者) — 新しいポータルの主要ユーザー
- カスタマーサポート担当者(対象者、R) — 現在すべての受付を処理しており、意見を聞かなければ導入リスクが生じます
- IT セキュリティ(P) — データの取り扱いに承認が必要
- コンプライアンス責任者(P) — 規制上の審査
- 小規模事業者の顧客(対象者) — 影響の受け方が異なり、セルフサービス以外の方法が必要となる場合があります
2 つ目のリストを使うことで、要件、展開計画、成功の定義がそれぞれ異なる PRD が作成されます。
よくある落とし穴
最初のブレインストーミングを最終リストとして扱う。 最初の案では、ステークホルダーの 60%は確実に挙がりますが、目立ちにくい残りの 40%は体系的に見落とされます。分類と公平性の確認は、その抜けを埋めるためのものです。これらを省略すると、取り組みの目的が損なわれます。
個人ではなく、役割や組織単位を挙げる。 「エンジニアリング」はステークホルダーではありません。スプリントの対応能力を管理するエンジニアリングリードがステークホルダーです。曖昧なカテゴリ名では、実際に必要な話し合いの予定を組めません。
特定と優先順位付けを混同する。 実際の影響力や影響を理解する前に、ブレインストーミングの段階でステークホルダーを除外すると、影響は大きいものの権限は小さい人々の声が、気づかれないまま切り捨てられます。まずリストを完成させてから、ステークホルダーマッピングで優先順位を付けてください。
バイアスと前提の確認を省略する。 このステップを省略したチームは、網羅できていると確信しがちです。確認を行うチームは、十分なリソースを持つユーザーの代理人が全員を代表していると思い込んでいたことに気づきます。見落としを明示してください。
外部からの検証なしに、一人で進める。 一人で作成したステークホルダーマップには、その人自身の人脈と前提が反映されます。一人で進める場合は、バイアスチェックを使って自分の想定から抜けている人を特定し、その後、部門横断の同僚に確認してから次に進んでください。
リストを完成させても、次のステップを記録しない。 キャンバスを優先対象とアクションで締めくくるのには理由があります。「誰が、誰と、いつ話すか」が記されていない包括的なステークホルダーリストは、計画ではなく単なる文書です。
参考資料
- stakeholder-mapping — 次のステップ:Power × Interest グリッドと Impact × Power グリッドを使って、特定したステークホルダーに優先順位を付けます
- stakeholder-engagement-advisor — 優先対象を決めた後、ステークホルダーごとのエンゲージメントを計画します
- discovery-interview-prep — 特定したステークホルダーを、調査参加者の募集の基礎として活用します
- proto-persona — 優先度の高いユーザーステークホルダーを特定した後、仮説に基づくペルソナを作成します
- MITRE Innovation Toolkit — Stakeholder Identification Canvas
- MITRE Innovation Toolkit — Community Map