mcpField
C
change-management

change-management

github.com/borgheiその他1.0k96 回インストール1 週間前に更新
リポジトリ

change-management について

業務プロセスの変更、組織再編、戦略転換、文化変革の計画を支援するスキルです。ADKAR を軸に、コミュニケーション、抵抗の診断、変革疲れへの対応、定着度の測定を扱います。

主な機能

  1. 01変革の種類に応じた実施計画
  2. 02ADKAR による抵抗の診断
  3. 03コミュニケーションの順序と頻度の計画
  4. 04変革疲れの把握と対応
  5. 05定着度と実施状況の測定

活用シーン

  1. 01新しいプロセスやツール移行の展開
  2. 02組織再編に伴う従業員向け連絡の計画
  3. 03停滞した変革や従業員の抵抗の診断
  4. 04新しい働き方の定着度の評価

インストール

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

$npx skills add https://github.com/borghei/claude-skills --skill change-management

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

scripts/
adoption_tracker.py
change_readiness_assessor.py
communication_planner.py

詳細

変更管理プレイブック

ほとんどの変更は、設計ではなく実装の段階で失敗します。このスキルでは、プロセスの小さな調整から大規模な戦略転換まで、組織の変更を混乱を最小限に抑え、最大限の定着を実現しながら展開するための包括的なフレームワークを提供します。

キーワード

変更管理、ADKAR、組織変更、組織再編、プロセス変更、ツール移行、戦略転換、変化への抵抗、変化疲れ、変更に関するコミュニケーション、ステークホルダー管理、定着、コンプライアンス、変更の展開、移行


まず確認すること

生成する前に、以下の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

  • 変更の種類(プロセス、組織/組織再編、戦略転換、文化)— プレイブック、タイムライン、ADKAR のどの段階が最も難しいかを決めます
  • 何が変わるのか、そしてその正直なビジネス上の理由 — 理由はすべてのコミュニケーションの基盤です。これがなければ、展開は恣意的に見え、抵抗を生みます
  • 誰がどのような影響を受けるか(直接影響を受ける人と、より広い組織)— コミュニケーションの順序と、対象者に伝える順番を決めます
  • すでに進行中のほかの変更がいくつあるか — 3 件以上の変更が進行中で、十分に定着していない場合は、さらに変更を追加する前に、変更疲れへの対処を計画に含める必要があります

停止ルール:出力に最も影響する 2~3 項目だけを質問してください。ユーザーが「そのまま下書きして」と言った場合は、作業を進め、成果物の冒頭に前提を記載してください。


変更の種類の選択

START: Change is needed
  |
  v
[What type of change?]
  |
  +-- Process Change (new tools, workflows)
  |     Timeline: 4-8 weeks
  |     Hardest phase: Ability
  |     See: Process Change Playbook
  |
  +-- Org Change (reorg, new leader, team restructure)
  |     Timeline: 3-6 months
  |     Hardest phase: Desire
  |     See: Org Change Playbook
  |
  +-- Strategy Pivot (new direction, killed products)
  |     Timeline: 3-12 months
  |     Hardest phase: Awareness
  |     See: Strategy Pivot Playbook
  |
  +-- Culture Change (values refresh, behavior expectations)
        Timeline: 12-24 months
        Hardest phase: Reinforcement
        See: Culture Change Playbook

コアモデル:ADKAR(スタートアップ向けに調整)

概要
段階内容失敗の兆候
Awareness(認識)人々が変更の理由を理解している「なぜなのか、誰も教えてくれなかった」
Desire(欲求)人々が参加したいと思っている(または少なくとも抵抗していない)「理解はしたが、賛成できない」
Knowledge(知識)人々が新しい方法で作業する方法を知っている「やりたいが、方法がわからない」
Ability(能力)人々に変更のための時間、ツール、サポートがある「方法はわかるが、まだ実行できない」
Reinforcement(定着)変更が新たな標準として定着している「試したが、以前のやり方に戻ってしまった」
ADKAR 診断

変更がうまく進まない場合は、どの段階に問題があるかを特定してください。

兆候問題のある段階対応策
「なぜこれをするのですか?」Awareness(認識)データを用いて変更の理由を再度伝える
「これは悪い考えです」Desire(欲求)懸念に対処し、方法の検討に参加してもらう
「これをどうやればいいかわかりません」Knowledge(知識)トレーニング、ドキュメント、オフィスアワー
「いつも古いやり方に戻ってしまいます」Ability(能力)練習時間を設け、作業負荷を減らし、サポートする
「始めたが、やめてしまった」Reinforcement(定着)測定、成果の称賛、古いやり方の廃止
ADKAR 導入タイムライン
週段階主な活動
-4Awareness(認識)の準備ステークホルダーを特定し、コミュニケーションの草案を作成する
-2Awareness(認識)の開始CEO/リーダーが変更の理由を説明する動画
-1Desire(欲求)の醸成懸念を話し合う場を設け、不安に対処し、方法の検討に参加してもらう
0Knowledge(知識)+本番開始トレーニング、ドキュメント、開始
1-2Ability(能力)のサポートオフィスアワー、ヘルプデスク、負荷の軽減
3-4Ability(能力)+初期の Reinforcement(定着)定着状況の確認、成果の共有、フィードバック
6-8Reinforcement(定着)の本格化古いやり方を廃止し、定着状況を測定して、成果を称える

抵抗のパターンと対応策

抵抗の診断マトリクス
パターン発言内容示唆されること対応
声に出して反対する「これはうまくいきません」認識または信頼性のギャップ根拠を示し、懸念を受け止める
タイミングへの疑問「なぜ今なのですか?」認識のギャップ緊急性と先延ばしのコストを説明する
プロセスへの不満「相談してもらえませんでした」欲求のギャップその点を受け止め、今から進め方に参加してもらう
能力を理由にする「時間がありません」能力のギャップ負担を減らすか、スケジュールを延長する
過去の事例を持ち出す「以前も試しました」信頼のギャップ今回は何が違うのかを明確にする
表立った反応のない不遵守[言葉で反対はしないが、変化もしない]どの段階にも該当する可能性がある1 対 1 で話し、原因を診断する
表面的な遵守[形式上は実行するが、妨害する]深刻な欲求のギャップ本当の懸念について率直に話し合う
抵抗への対応を決めるフローチャート
START: Resistance detected
  |
  v
[Is it vocal or silent?]
  |
  +-- VOCAL --> Good. They care enough to push back.
  |              |
  |              v
  |            [Is the concern valid?]
  |              |
  |              +-- YES --> Modify the change. Resistance is information.
  |              +-- NO  --> Address with data and empathy. Do not dismiss.
  |
  +-- SILENT --> Dangerous. Could be any ADKAR phase.
                 |
                 v
               [1:1 conversation with specific questions]
                 "What concerns you about this change?"
                 "What would need to be true for this to work for you?"
                 "What support would help?"
抵抗への最悪の対応

「変化に抵抗する人もいるものです。」

これは、抵抗をシグナルではなく、性格上の欠点として扱っています。抵抗のパターンはすべて、ADKAR のどの段階に問題があるかを示す情報です。対応する前に原因を診断してください。


変化のコミュニケーションフレームワーク

コミュニケーションの順序
対象者順序チャネル内容
リーダーシップチーム1 番目対面/ビデオ会議全体の背景と展開における各自の役割
直接影響を受ける従業員2 番目マネージャーとの 1 対 1、または少人数グループ個人への影響と利用可能なサポート
全従業員3 番目全社ミーティング、または文書と Q&A理由+内容+スケジュール+FAQ
社外のステークホルダー4 番目(該当する場合)適切なチャネル知る必要のある情報のみ
コミュニケーションテンプレート(CEO/リーダーによる告知)
Structure:
  1. What is changing (1-2 sentences, direct)
  2. Why it is changing (the business reason -- honest)
  3. What this means for you (practical impact)
  4. What is NOT changing (stability anchor)
  5. Timeline (specific dates)
  6. How to ask questions (channel, person, office hours)
  7. What happens next (first concrete step)
変化の種類別コミュニケーション頻度
変化の種類事前告知開始日1 週目1 か月目3 か月目
プロセスリードに事前連絡全社メールFAQ の公開定着状況の確認旧方式の廃止
組織影響を受ける人と 1 対 1 で話す同期ミーティングFAQ+マネージャーとの 1 対 1振り返り健全性の確認
戦略リーダーシップの認識合わせQ&A 付き全社ミーティングチーム単位で「これは何を意味するのか」を説明リソースの裏付け最初のマイルストーン
文化意見の収集ストーリー形式の告知行動の指針評価への反映継続的に実施

変化疲れ

疲れの兆候の検出
兆候深刻度対応
告知中にあきれた様子を見せる初期変化のペースを認め、以前の変化の成果を示す
変化に関するセッションへの出席率が低い中程度出席を任意にする一方、成果を可視化する
形式上はすぐに遵守するが、実際の定着は遅い深刻重要でない変化を一時停止する
「また始まった」という発言深刻変化の一覧を監査し、安定性について伝える
完全な無関心重大変化を凍結し、信頼を再構築する
疲れを防ぐルール
ルール実施方法
始めたことを完了する前の変化が定着する前に新しい変化を始めない
大きな変化は一度に 1 つ重要な変化の間隔を 2〜3 か月空ける
変わらない点を告知する変わらないことを明確に伝える
成果を示す次の変化を始める前に、以前の変化で達成したことを公開する
変化の予算組織の注意力を有限のリソースとして扱う
変化の一覧

新しい変化を始める前に、進行中のすべての変化を一覧にします。

変化段階開始日定着率一時停止できるか
新しい CRM の展開能力2 週間前60%いいえ
エンジニアリング部門の再編欲求1 か月前40%はい
価値観の見直し強化3 か月前75%いいえ

ルール:進行中の変化が 3 件以上あり、定着率が 70% 未満の場合は、別の変化を追加しないでください。


プレイブック 1:プロセスの変更

期間:4-8 週間 | 最も難しいフェーズ:能力

週アクティビティ担当者
-2変更の理由と本番稼働日を発表変更スポンサー
-1トレーニングセッションを提供変更チーム
0本番稼働+サポート担当者を配置変更チーム
2導入状況を確認:利用している人、利用していない人変更チーム
4フィードバックを収集+成果を公表変更スポンサー
8旧システムを廃止IT+変更チーム

プレイブック 2:組織の変更

期間:3-6 か月 | 最も難しいフェーズ:意欲

タイミングアクティビティ担当者
0 日目変更の理由とともに発表 -- 同期形式で、対面が望ましいCEO/リーダー
1 日目影響を最も受ける人と、各自のマネージャーが 1 対 1 で面談マネージャー
1 週目誠実な回答を盛り込んだ FAQ を公開人事+変更チーム
2-4 週目新体制を稼働(遅らせないこと)全リーダー
2 か月目初回の振り返り変更チーム
3-6 か月目定期的な状況確認人事

リーダーの退任について伝えること:共有できることは正直に伝えてください。「理由は共有できません」と言うだけでなく、チームにとって何を意味するのか、伝えられることを必ず伝えてください。


プレイブック 3:戦略の転換

期間:3-12 か月 | 最も難しいフェーズ:認識

タイミングアクティビティ担当者
発表前リーダーシップの足並みをそろえる(全員が同じ認識を持つこと)CEO
0 日目まず社内で発表(報道機関より先に従業員へ)CEO
1 週目チーム単位で「自分たちにとって何を意味するのか」を話し合うチームリーダー
2 週目リソースの再配分を発表CFO+COO
1 か月目新たな方向性における最初のマイルストーンが見える該当するリーダー
継続中新たな方向性の進捗を定期的に報告CEO

転換を失敗させるもの:古い方針に同じ水準の資金を投入したまま、新しい方向性を発表することです。リソースを移さなければ、転換は本物ではありません。


プレイブック 4:文化の変更

期間:12-24 か月 | 最も難しいフェーズ:定着

フェーズアクティビティ期間
意見収集代表的なメンバーに変更の定義への参加を呼びかける1-2 か月目
発表観察された行動を盛り込んだ、ストーリーを軸にした発表2 か月目
定着の基盤づくり文化の変更ごとに、観察可能な行動を定義する2-3 か月目
手本を示すリーダーシップチームがまず新しい行動を目に見える形で実践する3 か月目以降
統合新しい行動を人事評価に取り入れる次回の評価サイクル
称賛新しい行動が見られたときに公に認める継続中

導入状況の測定

導入と遵守の違い
観点遵守導入
行動見られているときに実行するより良い方法だから実行する
継続期間監視が緩むと元に戻る監視がなくても継続する
姿勢消極的前向き、または意欲的
動機の源外部からの圧力内面的な信念

導入を生み出すのは定着の取り組みだけです。遵守は強制の結果です。導入を目指してください。

導入指標
指標測定方法目標
利用率新しいプロセス/ツールを積極的に利用している人の割合8 週目までに > 80%
元に戻る割合古いやり方に戻る人の割合< 10%
満足度アンケート:「新しいやり方のほうが良いですか?」60% 超が同意
速度旧方式と新方式でタスクを完了するまでの時間4 週目までに新方式のほうが速い
サポートへの問い合わせヘルプの問い合わせ件数週ごとに減少

注意すべき兆候

  • 金曜日の午後に変更を発表する――週末の間、不満がくすぶります
  • 「これは最終決定です。質問は受け付けません」という伝え方――水面下での抵抗を生みます
  • 公開されたFAQや、安心して質問できる手段がない――懸念が解消されません
  • 稼働開始から6週間たっても旧システムが稼働している――変更が実現していません
  • 全員に求める変更をリーダーが免除される――信頼性が損なわれます
  • 定着度を測定していない――稼働開始を成功と見なしています
  • 複数の大規模な変更を同時に進めている――変革疲れは避けられません
  • 変更後の振り返りがない――フィードバックのループが欠けています
  • 担当者を明確にしないまま変更を発表する――成功に責任を負う人がいません

経営幹部との連携

次の場合...変更管理が連携する相手...目的...
プロセス変更COO(coo-advisor)発表前に新しいプロセスを設計する
組織再編CHRO + CEO人への影響評価とコミュニケーション
戦略の転換CEO(ceo-advisor)整合性の確保とストーリーの構築
文化の変革Culture Architect(culture-architect)価値観を行動に落とし込む
ツールの移行CTO(cto-advisor)技術的な展開計画
オペレーティングシステムの変更Company OS(company-os)新しいリズムと定例の設定
変更後の整合性Strategic Alignment(strategic-alignment)変更後の展開状況を確認する

成果物

リクエスト提供物
「変更の展開を計画して」タイムラインと担当者を含むADKARベースの変更計画
「組織再編を実施します」コミュニケーション計画を含む組織変更プレイブック
「[変更]への抵抗に対処して」抵抗の診断と対象を絞った対応策
「変革疲れが起きていますか?」変更の一覧、変革疲れの評価、推奨事項
「[変更]のコミュニケーション計画」テンプレートを含む段階的なコミュニケーション計画
「[変更]の定着度を測定して」目標値を含む定着度指標ダッシュボード

ツールリファレンス

change_readiness_assessor.py

ADKARモデルを用いて組織の準備状況を評価し、抵抗のパターンを特定し、変革疲れを測定して、介入計画を作成します。

# Run with demo data
python scripts/change_readiness_assessor.py

# Specify change type
python scripts/change_readiness_assessor.py --type org

# From JSON assessment data
python scripts/change_readiness_assessor.py --input assessment.json

# JSON output
python scripts/change_readiness_assessor.py --json
adoption_tracker.py

利用率、旧方式への回帰率、満足度、サポートへの問い合わせを追跡し、実際の定着と表面的な順守を見分けます。

# Run with demo data
python scripts/adoption_tracker.py

# From JSON with weekly data
python scripts/adoption_tracker.py --input adoption_data.json

# JSON output
python scripts/adoption_tracker.py --json
communication_planner.py

対象者に合わせて順序立てたコミュニケーション計画を、テンプレート、チャネルの推奨事項、タイミングとともに作成します。

# Generate for process change
python scripts/communication_planner.py --type process --name "New CRM Rollout" --date 2026-04-15

# Generate for org change
python scripts/communication_planner.py --type org --name "Engineering Restructure"

# From JSON
python scripts/communication_planner.py --input comm_plan.json

# JSON output
python scripts/communication_planner.py --type strategy --json

トラブルシューティング

問題考えられる原因対処法
利用率は高いが満足度が低い定着ではなく順守――強制されているため使っている満足度を左右する要因を調査します。強制だけに頼らず、ツールやプロセス自体を改善します
定着率が60~70%で頭打ちになる残りの30%に、対処されていないADKARの課題(多くの場合は能力)がある定着していない人を分類し、個別に診断して、対象を絞ったサポートを提供します
稼働開始から数週間で変更が元に戻る定着の段階が省かれている。旧システムにも引き続きアクセスできる旧システムへのアクセスを削除し、新しい行動を測定して認め、業績評価に組み込みます
リーダーが変更を免除される「自分の言うとおりにしろ、ただし自分は別」というパターンリーダーは率先して、目に見える形で実践しなければなりません。例外は認めません。これは信頼性を損なう最大の要因です
複数の変更を進めており、どれもうまくいっていない変革疲れ――組織の注意力が尽きている実施中の変更を一覧にし、重要度の低いものを一時停止して、大規模な変更の間隔を2~3か月空けます
コミュニケーション計画があるのに懸念が続いている一方的な周知のみで、フィードバックの窓口がなかった質疑応答の場、担当者、匿名のフィードバック窓口を設けます

成功基準

  • 本番稼働前にADKAR準備度スコアが70/100を超えていること(change_readiness_assessor.pyで測定)
  • 本番稼働から8週間以内に導入率が80%を超えていること(コンプライアンスだけでなく、実際の利用状況)
  • 8週目までに再移行率が10%を下回っていること(システム利用データで測定)
  • 8週目までに、満足度調査で「新しい方法のほうがよい」という意見への賛同が60%以上であること
  • 2週目以降、サポート依頼が週ごとに減少していること(定着フェーズで解決が進んでいること)
  • 金曜日の午後に変更を告知しないこと(コミュニケーションログのタイムスタンプで測定)
  • 変更後90日以内に振り返りを実施し、学んだ教訓を文書化すること

対象範囲と制限事項

対象範囲:ADKARに基づく準備度評価、抵抗の診断と対応、変革疲れの測定、コミュニケーションの計画と順序付け、導入状況の追跡、プロセス/組織/戦略/文化の変革に関するプレイブック。

対象範囲外:特定ツールの移行作業(CRM、ERPの設定)、人員削減に関する法令遵守、労働組合との交渉、労働法、個人向けのコーチングやセラピー。

制限事項:ADKARスコアは評価への入力に基づくため、客観的な測定ではなく認識を反映します。導入状況トラッカーでは、ほとんどの指標について手動でデータを収集する必要があります。コミュニケーションプランナーはテンプレートを提供しますが、企業固有の政治的力学は考慮できません。変革疲れの評価は傾向を示すものであり、実際の組織の対応力は企業文化によって異なります。


統合ポイント

スキル統合
coo-advisor発表前のプロセス変更の設計、業務上の準備状況
chro-advisor人材への影響評価、組織再編に向けたコミュニケーションの順序付け
ceo-advisor戦略転換の説明との整合、主要なコミュニケーターとしてのCEO
culture-architect文化変革のプレイブック、価値観から行動への落とし込み
company-os新しいOSの展開にADKARモデルを適用、会議のリズムの変更
chief-of-staff変更管理に関する質問の振り分け、部門横断的な連携の調整
strategic-alignment変更後の目標のカスケードを確認し、新しい方向性がOKRに反映されていることを検証

コメント