ステークホルダーとのコミュニケーション計画を説明する資料では、誰に参加してもらうか、その人が何を理解・判断する必要があるか、返答を受けて仕事をどう変えるかを示します。「全員に毎週メールを送る」は配信予定であって、それだけでは十分な計画ではありません。
次に必要な重要な判断から始め、その影響を受ける人を洗い出します。伝える内容と返答を扱う担当者が決まったら、Presentiでコミュニケーション計画をスライドにすることができます。実務用の関係者一覧は資料と分けて管理します。個人の連絡先や機微な所見を含む場合は、特に区別が必要です。
連絡手段より先に、必要な対話を選ぶ
Association for Project Managementのステークホルダーとのコミュニケーションに関する解説（英語）では、相手と好む連絡方法を理解し、反応やプロジェクトの変化に合わせて方法を見直すことが勧められています。実務では、メール、ワークショップ、ダッシュボードを選ぶ前に、その相手が対話から何を得る必要があるかを考えます。
目的は3つに分けられます。情報共有は何が変わったかを伝えること。意見を求める相談は、選択肢をまだ変えられる段階で考えを聞くこと。判断の依頼は、権限を持つ人に選択や承認を求めることです。1つの連絡が複数の目的を持つ場合もありますが、期待する返答は明確にします。
例えば、開始日を確定した後に送るメールは、その日に働く人への相談にはなりません。その人たちの予定が計画を変え得るなら、決定する前に話す必要があります。
具体的なプロジェクトの判断を軸に構成する
社内のサービス申請業務を変更する架空のプロジェクトを考えます。翌月、1つの部門で新しいプロセスを試験運用するか判断する必要があります。スポンサーが知りたいのは範囲と必要な人員・時間です。サービスデスクには、実行可能な振り分けとサポート体制が必要です。対象部門の社員は、日常の申請がどう処理されるかを理解する必要があります。
同じ判断について、相手ごとに疑問が違います。全員に同じ進捗率を見せても、誰も適切に返答できないかもしれません。計画では、各グループに示す根拠と、その反応を決定権者へ届ける方法を説明します。
組織図を使った役割の整理（英語）は正式な役割を知る助けになりますが、誰が変更の影響を受けるかまでは分かりません。最初の窓口に、対象利用者、支援担当、連携チームの抜けがないか尋ねます。組織上の役職が低いからといって、関与の必要性も低いとは限りません。
返答の扱いまで含む一覧表を作る
| 相手 | 解決したい問い | 対話とタイミング | 返答を扱う担当 |
|---|---|---|---|
| プロジェクトスポンサー | 試験運用の範囲と必要なリソースを認められるか | 運用上の懸念を整理した後、範囲を確定する前に判断材料を説明する | プロジェクトリーダーが決定と条件を記録する |
| サービスデスク | 試験運用中に申請を振り分け、サポートできるか | 試験運用の判断前に、サンプル案件で業務フローを確認する | サービス責任者がサポートと振り分けの疑問に対応する |
| 試験運用部門の社員 | 必要な情報を失わず、日常的な申請を完了できるか | プロセスをまだ変更できるうちに、少人数で手順を試す | 業務分析担当者が問題を記録し、対応案を返す |
| データ責任者 | 必須項目とアクセスの取り決めは適切か | サンプルデータを使う前に、対象を絞って確認する | データ責任者が要件を確認するか、未解決事項を示す |
表には個人名ではなく役割を使っています。必要であれば、社内の実務版に確認済みの連絡先を追加します。スライドには今の判断に関係する相手だけを載せ、完全な連絡先一覧は別資料に置くと読みやすくなります。
すべての行が「毎週」ではない点にも注目してください。判断の節目に必要な対話、出来事の後に必要な連絡、定期的に行う方がよい共有があります。頻度は予定表を複製する都合ではなく、情報の必要性に合わせます。
何を返してほしいかが分かる言葉で伝える
試験運用部門の社員への、次の2つの案内を比べてみます。
曖昧な案内：「新しい申請プロセスを確認して、意見を送ってください。」
具体的な案内：「木曜日の手順確認では、皆さんのチームでよく使う3種類の申請を試してください。説明や必須情報が実際の仕事に合わない箇所を教えてください。試験運用の範囲を確定する前に、各問題への対応をお返しします。」
後者には、作業、欲しい根拠、返答をどう扱うかが含まれます。一方で、すべての提案を採用するとは約束していません。相談とは、判断に意見を反映できる実質的な経路を用意することです。自動的な拒否権や、必ず一致するという保証とは違います。
スポンサーには別の言い方をします。「現在のサポート体制では2種類の申請に対応できます。3種類目には追加の支援体制が必要です。試験運用の範囲を減らすか、追加体制に予算を付けるか判断してください。」これは相談で得た情報に基づく判断依頼であり、利用者向けの手順確認を繰り返すものではありません。
意見が対立した後の動きを示す
想定外の申請が既定の選択肢に収まらないため、社員が自由記述欄の維持を求めたとします。一方、サービスデスクは自由な文章だけでは振り分けがばらつくと懸念しています。計画はこの対立を早期に見えるようにするためのもので、どちらかを「抵抗勢力」と決めつけるためのものではありません。
業務分析担当者は、匿名化したサンプル申請2件を合同の確認会に持ち込めます。必須の分類と任意の説明欄を組み合わせる案を検討し、振り分けと利用者の事情説明の両方が機能するか試せます。これは例としての選択肢であり、どのサービスにも正しい設計だという主張ではありません。
| 意見の記録項目 | 記入例 |
|---|---|
| 観察した問題 | サンプル申請2件が提案した分類に収まらない |
| 影響を受ける作業 | 社員は例外事情を説明する必要があり、サポートには振り分け用の分類が必要 |
| 次の行動 | 匿名化した例を確認し、分類と説明欄を組み合わせた案を試す |
| 担当と判断時点 | 業務分析担当者が、試験運用の範囲を決める前にテスト結果を提示する |
| 参加者への返答 | 選んだ案と、残る制限を説明する |
チームの権限では解決できない場合は、判断する人に選択の利点と不利益を示します。会議を開いたというだけで、未解決の懸念を緑色の「問題なし」に変えてはいけません。
対話が仕事に役立ったかを確認する
出席数、メール開封数、配信数は、情報が届いた範囲を示すことはできます。しかし、変更を理解したか、実際に意見を返す機会があったかは証明しません。この例では、必要な相手が参加したか、重要な問題ごとに担当がいるか、結果の説明が参加者に届いたかを見ます。
手順確認の後、次の行動を本人の言葉で説明してもらったり、サンプル作業を行ってもらったりできます。複数の人が同じ説明を誤解するなら、説明文と伝え方を直します。根拠もなく、その誤解を相手の姿勢の問題にしないでください。
影響を受ける部門が増えた、試験運用の範囲が変わった、判断日が動いたといった変化があれば計画を見直します。固定の週次連絡では、肝心な時点に必要な対話がなかったことは補えません。
6枚で計画を説明する
- 判断の背景：変更内容、次の判断、影響を受ける業務。
- 関係者の範囲：参加する役割、欠けている声、洗い出した方法。
- コミュニケーション一覧：目的、時期、連絡手段、返答を扱う担当。
- 2つの伝え方の例：意見を求める相談と、判断依頼の違い。
- 意見への対応経路：1つの問題で、記録、解決、上位への判断依頼、返答を示す。
- 必要な合意：担当者と次の対話を確認し、未解決事項を見えるまま残す。
最も重要な判断から説明します。聞き手がラベルの根拠を確かめたり異議を示したりできない、複雑な影響度・関心度の図を冒頭に置くのは避けましょう。非公開の計画には役立つこともありますが、共有資料では、参加者が行動に移せる作業と対話に集中します。
合意した一覧からプレゼンの下書きを作る
PresentiのPaste Textに一覧表と判断についての短い説明を入力します。デモ用の説明文を使う前に、個人の連絡先や非公開の評価を取り除きます。
社内サービス申請の試験運用を例に、6枚のステークホルダー・コミュニケーション計画資料を作成してください。スポンサー、サービスデスク、試験運用部門の社員、データ責任者を含めてください。情報共有、意見を求める相談、判断依頼を区別してください。誰が意見を受け取り、誰が解決でき、いつ参加者へ結果を返すかを示してください。自由記述と振り分けの例は、未解決の設計上の問いとして使ってください。関係者の態度、承認、アンケート結果、プロジェクト成果を作り上げないでください。
下書きでは、前提が事実にすり替わっていないかを確認します。完成した資料は、次の対話を手配しやすく、その目的を説明しやすいものであるべきです。
