mcpField
C
change-management-plan

change-management-plan

github.com/mohitagw15856生産性1.5k46 回インストール5 日前に更新
リポジトリ

change-management-plan について

組織の取り組みに向けた、構造化されたチェンジマネジメント計画を作成するスキルです。スポンサーや担当者が、関係者の分析、コミュニケーションと研修、抵抗への対応、稼働後の定着状況を計画できます。

主な機能

  1. 01変革と関係者の分析
  2. 02影響評価
  3. 03コミュニケーション計画
  4. 04研修と抵抗への対応計画
  5. 05定着指標とマイルストーン

活用シーン

  1. 01システムや業務プロセスの導入計画
  2. 02組織変更を伝える管理職の準備
  3. 03変更の稼働後に定着状況を追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill change-management-plan

インストール後、Claude Code で/change-management-planを入力して読み込まれたか確認します。

詳細

変更管理計画スキル

変更管理計画を構造化して作成します。多くの変革施策が失敗するのは、変化そのものが間違っているからではなく、人々がその変化についていけるように支援されていないからです。

必須入力

提供された情報をもとに作成してください。以下の情報に不足があっても、完全な出力を作成してください。不足している項目には、妥当な仮定を (仮定、要確認) と記し、最後に仮定を列挙してください。中核となるテーマ自体が欠けている(書くべき内容が何もない)場合に限り、最初に質問してください。

  • 変更内容(何が変わり、現状はどうなっているか?)
  • 規模(影響を受けるのは何人で、何チーム/拠点か?)
  • スケジュール(変更の開始日はいつか?移行期間はどれくらいか?)
  • スポンサー(上級管理職レベルで説明責任を担うのは誰か?)
  • 主な懸念事項(定着に対する最大のリスクは何か?)
  • 変更に失敗した場合の影響(定着率が低い場合、どのような結果になるか?)

出力構成


変更管理計画:[変更名]

変更スポンサー:[責任を担う経営幹部] 変更マネージャー:[実行責任者] 開始日:[日付] 影響を受ける対象者:[N人、Nチーム/拠点]


1. 変更の概要

変更前(現状):[現在の状況を具体的に記述] 変更後(将来の状態):[何が変わるのかを具体的に記述] 変更の理由:[率直な説明。変更の本当の理由を理解すると、人々はより早く受け入れます] 変わらないこと:[変わらない点を明示すると、不安を軽減できます]


2. ステークホルダー分析

ステークホルダーグループ規模影響度現在の受け止め方必要としていること
[グループ][N]高/中/低支持/中立/反対[具体的な懸念やニーズ]

早期に働きかけるべき主要な影響力のある人々: [非公式なリーダー、信頼されている人々、協力を得られる早期採用者を挙げてください。また、直接対応が必要な反対者も挙げてください。]


3. 影響評価

領域影響深刻度必要な対応
日々のワークフロー[日常業務で何が変わるか]高/中/低[トレーニング/サポート/再設計]
システムまたはツール[影響を受けるツール]
役割と責任[役割の変更]
プロセス[プロセスの変更]
指標と目標[KPIの変更]

4. コミュニケーション計画

中核メッセージ:[全員が理解し、覚えておくべき1文の要約]

対象者メッセージの重点チャネルタイミング担当者
全スタッフ[変更の理由+予想されること]全体会議/メール[T-6週間]スポンサー
マネージャー[チームを支援する方法]マネージャー向け説明会[T-5週間]変更マネージャー
直接影響を受けるチーム[各チームにとって具体的に何が変わるか]チーム会議[T-4週間]ラインマネージャー
[その他のグループ][対象に合わせたメッセージ]

コミュニケーションの原則:

  • 十分すぎるほど伝える — メッセージを自分のものとして理解するには、7回聞く必要があります
  • トップダウンの発表だけでなく、マネージャーを通じて情報を伝える
  • フィードバック窓口を設ける — 回答されない質問は噂になります

5. トレーニングとサポート計画

対象者トレーニングの種類タイミング時間実施方法担当者
[グループ][例:システムの実地トレーニング][T-2週間][2時間][対面/オンライン][担当者]

開始時のサポート:

  • [初日に利用できるサポート(ヘルプデスク、現場での支援担当者、推進役など)]
  • [最初の30日間に問題が発生した場合のエスカレーション経路]

6. 抵抗への対応

想定される抵抗の要因:

懸念誰が抱いているか根本原因対応
[例:「業務量が増える」][中間管理職][自律性の喪失][対処するための具体的なアクション]

抵抗への対応の原則:

  • 懸念を真摯に受け止めます。抵抗を退けると、抵抗が強まります
  • 可能であれば、抵抗する人を設計に巻き込みます。支持者へと変えることができます
  • 真摯に対応すべき懸念と、現状維持を望む気持ちを区別します。後者は解決するのではなく、管理します

7. 導入指標

指標基準値目標測定時点担当者
[システム利用率][0%][80%][本番稼働から30日後][担当者]
[プロセス遵守率][X%][Y%][60日後][担当者]
[スタッフの自信度スコア][アンケートスコア][目標][90日後][担当者]

導入のマイルストーン:

  • D+7:[初回確認 — 初期の問題を特定]
  • D+30:[初回の導入状況レビュー]
  • D+90:[導入の定着を確認、または是正計画を開始]

品質チェック

  • 「変わらないこと」を明確に説明している
  • ステークホルダー分析に、支持者だけでなく抵抗する人も含めている
  • コミュニケーション計画で、トップダウンだけでなく管理職を通じて情報を展開している
  • トレーニングを本番稼働前に実施するよう計画している(稼働後ではない)
  • 導入指標に測定日と担当者が設定されている
  • 抵抗への対応に具体策がある(「もっとコミュニケーションする」だけではない)

アンチパターン

  • コミュニケーションを一度きりの告知として扱わないでください。メッセージが浸透するには、何度も伝える必要があります。繰り返し接点を持つ計画を立ててください
  • 現場の管理職を巻き込まずに、変更管理を単独の担当者に任せないでください。管理職は情報を展開する最も効果的な経路であり、各チームへの説明前に事前共有を受ける必要があります
  • 本番稼働後にトレーニングを予定しないでください。使用する当日に新しいシステムを学ぶ人は、以前のプロセスに戻ってしまいます
  • ステークホルダー分析で抵抗する人を無視しないでください。明確に働きかけられていない抵抗者は、特に非公式なリーダーの場合、導入を妨げます
  • 導入状況を本番稼働時だけで測定しないでください。本当の試金石は、新しさが薄れた90日後に導入が定着しているかどうかです

例となるトリガーフレーズ

  • 「[取り組み]の変更管理計画を作成してください」
  • 「[チーム/組織]向けの[システム変更]の展開を計画するのを手伝ってください」
  • 「[変更]のコミュニケーション計画とトレーニング計画を作成してください」
  • 「[変更]への抵抗にどう対応すればよいですか?」

コメント