ステークホルダーとは？関係者の洗い出し方と関わり方を具体例で解説

ステークホルダーとは、仕事やプロジェクトに影響を与える、または影響を受ける人・組織です。日本語では「利害関係者」と訳されます。担当者や上司だけでなく、成果物を使う人、変更の影響を受ける部署なども含まれます。

関係者を思いついた順に並べるだけでは、誰にどう関わってもらうべきか分かりません。「何に関係するか」「何を確認・相談・共有するか」「いつ、誰が連絡するか」まで整理して、初めて次の行動を決められます。

この記事では、社内向け業務マニュアルを新しい部署運用へ切り替える小規模プロジェクトを一つの架空事例として使います。登場する人・部署・手順・日程はすべて説明用の設定です。関係者2人のメモを、実際に使える簡易ステークホルダー整理表へ変えていきましょう。

ステークホルダーとは

「利害」は金銭的な損得だけを指しません。手順変更で作業が増える、利用する情報が変わる、承認の責任を持つ、公開に必要な権限を持つ、といった関係もあります。

プロジェクトに参加している人だけに限定しないことがポイントです。会議に出ていなくても、その仕事の結果によって自分の業務が変わる人は、確認すべき関係者になり得ます。PMI公開のステークホルダー分析論文でも、プロジェクトへの参加者と、実行・完了によって影響を受ける人や組織を扱っています。

企業経営の文脈では株主や地域社会なども対象になりますが、本記事では、目の前の仕事を進めるために必要な関係者を整理します。

ステークホルダーの具体例

誰がステークホルダーになるかは案件によって変わります。この一覧の全員を入れる必要はありません。また、上司が必ず承認者とは限らないため、実際の権限を確認します。

今回の架空例は社内手順と社内の公開場所を切り替える仕事です。顧客への提供内容や外注先への依頼、届出は変えない設定なので、社外関係者は対象に含めません。実際の案件では、この前提を確認してから判断してください。

ステークホルダーを洗い出す意味

目的は、仕事を進める途中で必要になる確認や調整を、先に見つけることです。たとえば次の見落としがあると、完成後に手戻りが起きる可能性があります。

• 課長に見せればよいと思っていたが、別の承認者が必要だった。
• 実際の利用者に確かめず、現場では使えない手順を書いてしまった。
• 他部署への受け渡しが変わるのに、その部署へ伝えていなかった。
• 公開直前に、利用者の閲覧権限がないと分かった。

ただし、関係者を増やすほどよいわけではありません。関係のない人まで確認先にすると、待ち時間や調整が増えます。「今回の何に関係するか」を説明できる相手を挙げ、必要な関わりを分けます。

ステークホルダーの洗い出し方

名前を思い出す前に、仕事と成果物から考えると、普段話す相手以外も見つけやすくなります。

1. 仕事・成果物・変更内容を確認する。今回は何を作り、何を変えるのかを書きます。架空例なら「受付手順のマニュアルを新運用へ更新し、部署内サイトで公開する」です。範囲が曖昧なら、先に仕事のスコープの決め方で対象・対象外をそろえます。
2. 実際に作業する人を挙げる。原稿を作る人だけでなく、掲載・設定など別作業の担当も確認します。
3. 判断・承認する人を挙げる。内容を確認する人と、切替を承認できる人を分けます。職位だけで決めません。
4. 成果物を使う人を挙げる。新手順で仕事をする人に加え、使い方や勤務条件の違う利用者がいないか見ます。
5. 変更の影響を受ける人を挙げる。前後の工程、他部署との受け渡し、問い合わせ対応をたどります。
6. 必要な情報・権限・資源を持つ人を確認する。業務知識、システムの設定権限、作業時間など、担当者だけでは用意できないものから探します。
7. 社外の関係者が必要か確認する。顧客への案内、取引条件、外注作業、届出などが変わらないか確かめます。
8. 抜けと重複を見直す。現行マニュアルの確認先、承認経路、配布先と照合し、利用者や上司に「この変更で困る人、事前確認が必要な人はほかにいますか」と聞きます。

同じ人が複数の立場を持つ場合は、名前を重ねるより、関係する内容を一行にまとめます。逆に「利用部門」の一行で異なる使い方を隠してしまうなら、必要な単位へ分けます。

架空例：関係者2人からステークホルダーを洗い出す

最初のメモでは、作成担当者と課長だけ

架空の案件では、作成担当者が原稿を直し、課長が最終承認する予定でした。最初の関係者メモは「作成担当者」「課長」の2人だけです。

しかし、この2人だけでは、現場で新手順を使えるか、他部署への受け渡しが合うか、公開場所を閲覧できるかが分かりません。

不足する視点から、確認先を追加する

内容確認者は業務知識のある別の担当者、承認者は課長という設定です。現場利用者の代表も部署内の全利用者に含まれますが、事前確認と切替通知では目的が違うため、表では分けます。通知の際は二重に送らないよう宛先をそろえます。

関連部署には完成後に知らせるだけでは足りません。受け渡し条件が変わるため、原稿を固める前に相談し、決定後にも共有する必要があります。

関係者と関わり方を、一つの整理表にする

この表なら、作成担当者は着手時に課長とシステム管理者へ相談し、手順案の段階で関連部署へ連絡すると分かります。小規模案件なので連絡窓口を作成担当者へまとめましたが、実務では本人の時間と権限を確かめて分担します。

表に書いた相手と、依頼内容・対応可能な時期を確認してから予定へ組み込みます。名前を記入しただけで、協力や承認が得られたことにはなりません。

誰にどの程度関わってもらうか

関係者全員を、すべての会議へ呼ぶ必要はありません。関わり方は人の重要度を一列に並べるものではなく、その場で必要な行動に合わせて決めます。

• 一緒に判断する：複数部署で条件を合わせる必要があるとき、関係する判断者が論点を確認する。
• 事前に相談する：案を固める前に専門知識や実行上の制約を聞く。
• 内容を確認してもらう：対象と確認観点を指定し、指摘・回答を受け取る。
• 決定後に共有する：変更点や対応開始日など、相手の行動に必要な情報を知らせる。
• 必要なときだけ連絡する：例外や条件変更が起きた場合の連絡先と、その条件を決めておく。

同じ人でも段階によって関わり方は変わります。架空例の課長は着手時には相談先、切替前には承認者です。承認が必要な相手に通知を送るだけでは、必要な手続きは終わりません。

ステークホルダー整理とRACIの違い

本記事の表は、全作業の責任分担を確定するものではありません。関係者を洗い出した後、作業ごとの担当や判断先を明確にする必要があるなら、RACI表の作り方とR・Aの違いへ進みます。関係者を見つける段階でR/A/C/Iだけを埋めようとすると、まだ挙げていない利用者や影響先を見落とすことがあります。

影響力と関心度で整理する方法

関係者の要望、仕事への影響、必要な関わりを調べることを、ステークホルダー分析と呼びます。分析の観点の一つが、影響力と関心度です。

• 影響力：判断・承認、資源や権限、専門知識などを通じて、この仕事の進め方や結果を変えられる度合い。
• 関心度：この仕事の内容や結果に、どの程度注意や関心を向けているか。

PMI公開のステークホルダー管理論文では、影響力と関心度を組み合わせて関わりを考える方法が紹介されています。高い・低いの組み合わせによる四つの区分は、連絡の頻度や詳しさを考える補助になります。

ただし、四つの区分から対応を自動で決めることはできません。架空例の課長はマニュアルの細部への関心が低くても、最終承認が必要です。現場利用者は決定権が小さくても、手順変更の影響を強く受けるため、意見を確かめる必要があります。システム管理者には、専門知識と設定権限の確認が欠かせません。

「相手が仕事を動かす力」と「相手が仕事から受ける影響」は別です。必要な承認、法的要求、専門知識、受ける負担も見てください。関心が低いように見える場合も、単に変更を知らない可能性があります。本人への確認なしに「無関心だから連絡不要」と決めないようにします。

分析だけで対立が解消したり、合意が得られたりするわけではありません。確認した条件や要望をもとに、調整と判断が必要です。

ステークホルダーごとに何を確認するか

相手を一人選び、次の五つを具体化します。

1. 何に関係する人か：役職名だけでなく「新マニュアルの閲覧権限」のように対象を書く。
2. 何を確認したいか：「確認お願いします」ではなく、答えてほしい問いを書く。
3. いつ関わってもらうか：相談する工程と、必要なら回答希望日を決める。
4. 相談・確認・共有のどれが必要か：助言が欲しいのか、正誤を確かめたいのか、知っておいてほしいのかを分ける。承認が必要なら明記する。
5. 誰が連絡するか：依頼と回答の回収、表の更新を担う窓口を決める。

架空例のシステム管理者には、作成担当者から次のように相談します。

受付手順のマニュアルを新運用へ切り替えます。着手前の相談です。部署内サイトの掲載場所と、全利用者が閲覧できる権限を確認したいです。旧版を残す場合の表示方法も含め、初稿作成前に実施方法を決められるか教えてください。

相談の結果、権限設定の可否がまだ分からなければ、表の該当欄へ「権限設定は未確認。作成担当者が管理者へ再確認」と残し、双方で次の確認日を決めます。未回答を「問題なし」や「承認済み」へ置き換えません。

受け渡し条件を会議で相談するなら、関連部署の窓口と必要な判断者へ論点を伝えます。議題の作り方は会議アジェンダの作り方で整理できます。窓口では解決できない権限や部署間の対立が分かった場合は、エスカレーションの考え方に沿って、判断できる相手へ必要な情報を渡します。

ステークホルダーが多すぎるときの整理

人数を減らす前に、「意思決定に必要」「実務上の確認が必要」「変更の影響を受ける」「情報共有が必要」という関与の種類を分けます。一人が複数に該当して構いません。

架空例では、利用者全員に初稿の会議へ出てもらう代わりに、利用者代表へ試用を依頼します。ただし、代表と異なる手順や勤務条件の利用者がいれば、その違いも確認します。代表の意見を全員の合意として扱いません。

全利用者には承認後の切替通知を送り、質問先を添えます。関連部署は窓口を置いても、その窓口が部署全体を判断できるとは限りません。必要な確認先・判断者へ届くかを確かめます。

目的は、必要な関わりを明確にして、確認漏れと不要な拘束を減らすことです。連絡先をまとめても、正式な承認や必要な確認を省かないでください。

ステークホルダー管理でよくある失敗

ステークホルダー管理は、一覧を保存するだけでなく、必要なやり取りを実施し、変更に合わせて見直すことです。

架空例でも、途中で掲載場所が社外サービスへ変わるなら、当初のシステム管理者への相談だけで足りるか見直します。新たな利用条件や社外との関係が生じないかを確認し、必要な相手を追加します。

コピー用の簡易ステークホルダー整理表

次の表を文書などへコピーして使ってください。本記事の簡易様式であり、すべての案件に共通する必須書式ではありません。

1. 表の上へ「今回の仕事・成果物・変更内容」を一文で書く。
2. 関係者を挙げ、一人ずつ残りの四つの欄を埋める。必要なら行を追加する。
3. 確認したい問いや未確認事項を「必要な関わり・確認内容」欄へ書く。
4. 抜けを利用者・上司などに確かめ、依頼内容と時期を相手と合わせる。
5. 連絡・回答に合わせて更新する。不要な相手を残していないかも見る。

承認者や連絡先が分からない場合は、名前を推測せず「承認者未確認。作成担当者が課長へ確認」のように書きます。確認する工程・希望日も決め、その行を解決するまで未確認として残してください。

表の完成は、全員の合意や作業完了を意味しません。「次に誰へ何を依頼するかが分かる」状態をまず作り、実際の回答と決定を反映していきます。

まとめ

まず、今持っている仕事について、「作る人・決める人・使う人・影響を受ける人」をそれぞれ1人以上挙げてみてください。同じ人が複数に当てはまっても構いません。該当する人がいるか分からない観点は、未確認として確認先を決めます。

そのうち一人を選び、「何を聞くか・いつ聞くか・誰が連絡するか」を表へ書きます。残りの関係者にも同じ整理を行い、抜けを確かめれば、思いついた名前のメモを、仕事を進めるための一枚へ変えられます。