ステークホルダーマップを使った発表では、誰が判断に影響を与えられるのか、誰が影響を受けるのか、プロジェクトを進める前にどの対話が必要なのかを示します。名前を並べるだけでは足りません。軸を定義し、重要な役割をその位置に置く理由を説明し、最後に取り組む行動を絞ります。
Presentiでテキストからプレゼンを作る前に、こうした判断を整理してください。AIは説明の構成を助けられますが、人の権限、態度、関心の度合いを創作させてはいけません。以下では架空のサービス導入を例に、不確実な点を隠さずに話し合えるマップを作ります。
軸を選ぶ前に、何を判断するのかを定める
あるサービスチームが、新しい顧客依頼フォームを試験導入しようとしているとします。今回の判断は、1チームで2週間の試行を実施するかどうかです。マップはこの判断のためのもので、組織内の全員を恒久的に順位づけするものではありません。
会議の目的に合う場合に、権限と関心のマップを使います。この例の権限は、試行を承認、停止、または実質的に変更できる力です。関心は、この変更に関わる必要性や動機を指します。役職が高いというだけでは、どちらの位置も決まりません。
Mindtoolsのステークホルダー分析ガイドは、関係者を特定し、権限と関心のマトリクスで優先順位を考え、懸念を理解する流れを説明しています。出発点として便利ですが、発表には配置の根拠と、正式な権限が小さくても影響を受ける人の声を聞く方法が必要です。
関心を、影響の大きさに無言で置き換えてはいけません。顧客はプロジェクトを知らなくても大きな影響を受けることがあります。役員が関心を持っていても、試行を承認する本人とは限りません。影響が判断の中心なら、別途影響を記すか、軸名を明示した影響ベースのマップを使ってください。
役割と根拠からマップを作る
四つの領域を描く前に、短い作業表を作ります。確認済みの責任と、相手の態度についての推測を分けるためです。次の役割と状況は架空のものです。
| 役割 | 配置に関わる根拠 | 初期の配置 | 確認・実施すべきこと |
|---|---|---|---|
| サービス部門責任者 | 試行に使う時間を承認し、依頼対応に責任を持つ | 権限が大きく、関心も高い | 判断基準と試行の中止条件を合意する |
| セキュリティ審査担当 | 試行前に入力項目の変更を求められる | 権限は大きい。関心は要確認 | 予定する項目を確認し、承認手続きを把握する |
| 現場チーム | フォームを使って例外対応も行うが、試行の承認権限はない | 正式な権限は小さく、関心は高い | 難しい依頼をたどり、フォームが使えなくなる条件を記録する |
| 顧客側の代表者 | 分かりにくい依頼や情報不足の依頼の例を提供できる | 正式な権限は小さく、関心は高い | 顧客が実際に遭遇する状況を試行で扱えるか確かめる |
| 支出承認者 | 試行に追加支出が必要なら承認を求められる | 条件付きで権限が大きく、現在の関心は低い | 承認不要と決めつける前に、支出に関する条件を確認する |
| 関連部署 | 試行から依頼が回ってくる可能性があるが、その影響は不明 | 配置未定 | 引き継ぎの流れを確かめてから配置する |
広い範囲の聞き手に個人名が不要なら、役割名で示します。詳細な連絡先一覧は別に管理してください。公開資料や広く共有する発表に、実名の同僚についての非公式な評価まで載せる必要はほとんどありません。
四つの領域を、人への決めつけにしない
サービス部門責任者は、権限も関心も高い側に置きます。現場チームと顧客側の代表者は、権限が小さく関心が高い側です。支出承認者は権限の大きい側に置き、支出条件によって必要になることを注記します。セキュリティ審査担当の関心は把握したことにせず、関心軸上の不確実さを示す印を付けます。
権限も関心も低い領域が空でも構いません。すべての領域を埋めるために架空の関係者を加えたり、見た目の均衡のために実在する役割を移動したりしないでください。根拠のない対称な図より、空白のほうが正確に伝わります。
関連部署は、マップの横に「未確定」として置きます。理由は、引き継ぎへの影響がまだ分からないからです。次の対話で、想定と大きく違う位置だと分かるかもしれません。こうした不足情報を見えるようにすることも、マップの役割です。
マップと根拠の説明を分ける
図中は短いラベルにし、長い説明は脇へ置きます。六つの役割にそれぞれ段落が必要なら、一枚でマップと一覧台帳の両方を担おうとしている状態です。番号付きの印と近くの注記を使えば、議論のある配置も読みやすく示せます。
「確認済み」と「不確実」を色だけで区別しないでください。輪郭だけの印、凡例付きの疑問符、「未確認」の文字などを使います。評価が適切で根拠もある場合を除き、赤と緑で「妨害者」「支持者」と分類するのは避けましょう。要件への異論は、プロジェクトそのものへの反対とは限りません。
3枚の流れでマップを説明する
多くの場合、聞き手に必要なのは情報過多の一枚ではなく、短い説明の流れです。この試行なら、次の3枚で考え方を示せます。
- 判断と対象範囲。「1チームで新フォームの試行を実施できるかを決める」と示します。期間、影響する業務、未完了の承認を記し、権限と関心をそれぞれ一文で定義します。
- マップと二つの未確定事項。同じ軸で各役割を示します。すべての印を読み上げるより、セキュリティ審査担当の関心が不明な点と、関連部署への引き継ぎが未確定な点に注目します。
- 判断前に必要な対話。不足している事実、それを確認する役割、結果によって何が変わるかを絞って示します。
口頭では、たとえばこう説明できます。「現場チームには正式な承認権限があまりありませんが、現場の例外事例によって試行の実用性が決まります。責任者に承認を求める前に、その事例を一緒に確認する必要があります。セキュリティ審査は別の承認条件で、担当者にどこまで関わってもらうかは、まだ合意できていません。」
四領域の一般論を読むより、配置が次の判断にどう関わるかが伝わります。正式な権限が小さいことは、新しい手順を使う人を無視する理由にならないことも明確になります。
配置への異論には、根拠を尋ねる
支出承認者を別の領域に置くべきだという意見が出たら、その役割が実際に何を決められ、どの条件で権限が生じるのかを尋ねます。試行の承認経路を変える支出基準が見つかるかもしれません。注記と位置は一緒に更新してください。説明を変えずに点だけを動かすと、判断の理由が失われます。
関心も変化します。最初は短い報告だけで十分だった部署も、試行で流入する仕事量が変われば深く関わる必要が出ます。判断日と、マップを見直すきっかけになる出来事を示しましょう。組織の永久的な事実として掲げないことが大切です。
マップを次の対話につなげる
マップから、少数の具体的な行動を導きます。この架空の試行なら、サービスのリーダーが現場との手順確認を設定し、フォーム担当者がセキュリティ審査を確認し、試行の調整役が関連部署との引き継ぎを確かめます。それぞれが、特定の不確実さを解消する行動です。
関係性と必要な対応が分かったら、ステークホルダーとのコミュニケーション計画でメッセージ、連絡手段、必要な返答を定めます。細かな日程表はマップと分けましょう。マップは誰に判断が依存するかを示し、コミュニケーション計画は対話を組み立てるものです。
最初の発表案には、次のような依頼文を使えます。
架空の2週間の依頼フォーム試行について、ステークホルダーマップを3枚で説明してください。1枚目は判断事項と範囲です。権限は試行の承認・停止・実質的な変更ができる力、関心はこの変更に関わる必要性や動機と定義します。2枚目では、サービス部門責任者、現場チーム、顧客側の代表者、条件付きの支出承認を配置します。セキュリティ審査担当の関心は未確認です。関連部署は引き継ぎが分かるまで図の外に未確定として残してください。3枚目は承認前に必要な対話です。態度、個人名、承認状況、聞き取り結果を創作せず、マップを初期仮説として扱ってください。
できた下書きは役割表と照合します。不明な位置が確定したラベルに変わっていないか、条件付きの承認が無条件の権限になっていないかを確認してください。混み合う場合は役割名を小さくするのではなく、根拠の説明を補足スライドへ分けます。
会議の最後には、何が変わったかを整理します。承認経路が確認できた、新たに影響を受ける集団が見つかった、まだ答えが必要な問いが残った、といった変化が、ステークホルダーマップから得られる成果です。
