チェンジマネジメントとは｜DXでの役割・ADKARと組織変革、定着の確認点

チェンジマネジメントは、業務やシステムを変える際に、影響を受ける人が新しい仕事の進め方を理解し、実行し、継続できるよう支える取り組みです。説明会を開くことや、反対意見を減らすことだけでは完結しません。本記事では、DXでの役割、ADKARと組織変革の方法の違い、現場の懸念への対応、定着を確かめる指標と運用を整理します。確認表や業務例は、本記事からの提案です。

チェンジマネジメントとは：DXの目標と、仕事を変える人をつなぐ

DXでは、システムが予定どおり稼働しても、業務上の成果が出るまでに別の課題が残る場合があります。担当者が入力できない、承認者の責任が決まっていない、例外を処理できない、といった問題です。チェンジマネジメントでは、誰の仕事がどう変わるのか、そのために何を説明し、どんな支援や業務上の調整が必要かを考えます。開発の完了、利用開始、品質を保った継続利用、経営上の成果を分けて確認します。

IBMの中国語の変革管理の解説も、移行中の人とシステムへの支援、変更範囲と関係者の把握、現場からの意見を取り入れることを説明しています。自社では、実際に仕事をする人に加え、承認する人、前後工程で情報を受け取る人、問い合わせや障害対応を担う人まで対象を広げて確認します。役職の一覧だけで対象者を決めず、日常の処理と例外がどこを通るかをたどる方法があります。

「DXの70%」は、いつ、何を測った数字か

BCGが2021年6月に公表した分析は、支援先70社と経営幹部への調査825回答を基にした895社を対象としています。目標達成や価値、持続的な変革などを評価し、30%が目標を達成または超過して持続的変革を実現したと分類しました。残る70%には、一部の価値を生みながら目標未達となった44%も含まれます。70%を「何の価値もない全面的な失敗」、2026年の全企業の実績、従業員の抵抗が原因となった割合へ置き換えることはできません。

自社の計画でも、「失敗」の意味を先に決めます。利用されなかったのか、利用されたが品質が足りなかったのか、効果はあったが費用や期限の目標に届かなかったのかで、取るべき対応は異なります。現場の声を、経営層が決めた施策へ賛成しているかどうかだけで評価せず、目標や設計の前提を修正する情報として扱います。導入の速さと、業務を続けられる状態の両方を確認します。

予算と日程には、周知、練習環境、教材、問い合わせ、二重運用、手順の改訂、引継ぎも含めて見積もります。共通の予算比率や月数を置く前に、対象の役割、拠点、勤務時間、業務の頻度と変更の大きさを調べます。現場の負担を減らす計画であっても、移行中には一時的な追加作業が生じます。担当者が通常業務と変更対応の両方を担えるか、既存業務を何から減らすかも責任者が判断します。

ADKARと組織変革の方法は、対象と使い道を分けて理解する

ProsciのADKAR公式説明は、ADKARを個人の変化を扱うモデルと位置付けています。認識、参加する意欲、知識、実行する能力、継続の支えという五つの要素から、どこに支援が必要かを考えます。全社DXを五段階で管理する工程表や、人事評価の点数表とは区別します。モデル名を採用しただけで、成果や特定の成功率が保証されるわけではありません。

ADKARの要素	支援を考える問いの例	本記事が提案する確認方法
Awareness：認識	なぜ、どの仕事を変えるのか	目的と対象、新旧の違い、未決定の事項を共有する
Desire：意欲	参加にどんな懸念や条件があるか	期待する利点と負担、役割への影響を聞き取る
Knowledge：知識	何をどう行うか分かるか	役割ごとの手順と、問い合わせ先を用意する
Ability：実行する能力	実際の条件で処理できるか	権限、時間、データを確保して通常・例外処理を試す
Reinforcement：継続の支え	担当交代後も続けられるか	振り返り、手順の更新と運用担当への引継ぎを行う

表の問いと確認方法は、公式の認定教材や採点基準の転載ではなく、本記事の業務への当てはめです。操作を知っていても、繁忙時に練習できなかったり、本番の参照権限がなかったりすれば実行できません。その状態を意欲不足と決めつけないことが大切です。また、対象業務や担当が変われば、説明や支援を再び必要とする場合があります。一度の研修で全員が同じ状態になったとは扱いません。

組織の進め方は、個人の変化を支える体制と結び付ける

Prosciの組織変革のプロセス解説は、準備、変革の管理、成果の維持という三つの段階を、個人のADKARとは別の枠組みとして説明しています。準備では目指す成果と影響を受ける人、実施方法を定め、実行中は計画・確認・調整を行い、維持では成果の確認と責任の引継ぎを扱います。自社の体制では、経営判断、対象業務の責任、開発・運用、教育・問い合わせの担当が、それぞれ何を決めるかを対応させます。

Kotterの現行公式説明は、従来の直線的な8ステップから、2014年の『Accelerate』や2021年の『CHANGE』で示す8 Acceleratorsへの発展を説明しています。方向の共有、推進する人の連携、障害の除去、短期の成果、継続と定着などを扱っています。旧来の八段階の説明と現在の枠組みを混在させず、参照する版と用途を明示します。いずれの方法でも、自社で誰を支援し、誰が調整し、何を確かめるかを具体化する作業が必要です。

現場の「抵抗」は、懸念と実行条件を確かめて支援へ変える

利用が進まない時には、変更理由への疑問、仕事や評価への不安、手順の不明点、時間や権限の不足、設計そのものの問題を分けて聞き取ります。「抵抗する人」を探して分類することを目的にしません。たとえば二重入力への指摘は、業務を良くする設計情報となる可能性があります。一方、希望をすべて採用できるわけでもありません。採否を決める責任者が、確認した事実、制約、判断理由、代わりの対応を説明します。

確認する状態の例	調べること	支援・修正の例
目的や対象が伝わっていない	どの説明が届き、何が不明か	役割ごとに仕事の変更点と理由を説明する
入力や確認の負担が増える	重複作業、承認待ち、他部署への転記	不要作業の廃止、入力・連携と責任分担を直す
手順は理解したが処理できない	権限、端末、時間、利用データと例外	実際の条件で練習し、詰まる箇所を修正する
試行中は使えたが継続しない	担当交代、問い合わせ、旧手順との併存	運用責任、手順更新と引継ぎを明確にする

説明は、経営者による全体の目的と、業務責任者による具体的な仕事の変更をつなげます。何が決まっていて、何が調整中かを区分し、回答できない点は担当と回答予定を記録します。発信の回数を増やすだけでなく、交代勤務や休職・異動、拠点差などで情報を受け取れない人への届け方も考えます。質問への回答が設計変更につながった場合は、教材や手順の参照版も更新します。

練習では、説明を聞けたかに加え、対象の仕事を完了できるかを確認します。通常の入力だけでなく、データ不足、承認者の不在、差戻し、重複、障害時などを扱います。誰が支援し、どの問題を開発へ戻し、何を暫定手順で処理するかを決めます。試行に協力した熟練者だけが扱える状態であれば、他の担当や拠点へ広げる前に、教材・画面・問い合わせ体制を修正します。

AIを組み込む場合は、生成した候補と確定した内容、提案と実行を分ける練習も必要です。出力を確認する根拠、不明・誤りがある時の保留、承認者、手作業へ戻す条件、外部システムへ反映されたかの照合を決めます。AIが人の仕事や不安を完全に理解すると扱わず、会話や利用記録だけで本人の心理状態、能力、反対の理由を確定しません。個別の人事・労務上の判断が必要な事項は、責任を持つ担当へつなぎます。

周知・練習・問い合わせ・移行作業は、開発日程と別の付録にせず計画へ組み込みます。業務の前提や依存、次へ進む条件を整理する際は、DXロードマップの作り方と、移行・定着の確認点も参考になります。練習が終わる前に旧手順を止める、運用担当が決まる前に支援を終了する、といった順序の食い違いを確認します。現場から得た情報で前提が変われば、日程や対象範囲も見直します。

現場の負担や個人への支援を考える際は、業務を変えるための支援と、健康に関する個別の対応を区分します。従業員ウェルビーイングと、職場改善・健康情報の確認点では、ストレスチェックの個人結果と集団分析、情報の目的・権限、AIと専門家の役割を整理しています。個人の変化を捉える枠組みを、診断や治療、心理状態の採点へ転用せず、適切な担当へつなぐ際の参考になります。

画面や通知から新しい手順を使いやすくする際は、組織として必要な権限・時間・支援の整備と、選ぶ環境の設計を分けて考えます。ナッジ・行動デザインとEAST、効果検証の確認点では、行動を妨げる条件、初期設定を変更できる経路、表示の根拠、比較する指標と取消し・副次的影響を整理しています。利用率だけで定着や本人の利益を判断せず、説明と選択の透明性、運用後の見直しを確かめる際の参考になります。

定着は利用・品質・負担・成果を分け、運用の責任まで確認する

定着を判断する指標は、研修の出席率やログイン人数だけにしません。対象業務をどれだけ新しい方法で行い、その結果が確認基準を満たしたか、作業と確認の負担、利用者や顧客への成果がどう変わったかを組み合わせます。指標ごとに対象、期間、分子と分母、除外条件、取得元、確認担当を定めます。未実施、測定できなかったもの、対象外を同じゼロへまとめないようにします。

計算だけを示す架空例として、ある期間の対象処理が100件、新しい方法で実施したものが80件、そのうち確認基準を満たしたものが60件だったとします。実施割合は80÷100＝80%、実施分の基準達成割合は60÷80＝75%、対象全体で実施し基準も満たした割合は60÷100＝60%です。三つは分母が異なります。未実施20件の理由は別途確認し、すべてを利用者の反対や能力不足へ分類しません。この例は実績、推奨目標、成功を判定する共通基準ではありません。

測定する観点の例	確認項目	読み違いを防ぐ確認
支援が届いたか	対象への説明、練習、問い合わせ対応	参加と理解・実行を分ける
仕事で使われたか	対象処理に対する実施件数	対象外、欠測、未実施理由を分ける
品質と負担	手戻り、例外、確認時間、問い合わせ	他工程へ移った作業も含める
業務上の成果	回答待ち、顧客への影響、費用など	比較条件、他の変更と二重計上を確かめる

導入前後の比較では、件数、難易度、季節、担当構成や同時に行った施策の違いを記録します。利用率と成果が同時に改善しても、それだけで変革管理の因果効果とは決めません。確認作業を増やして品質を保った場合は、その工数も含めます。空いた時間の金額換算と、実際に支出が減ったことは区分し、複数施策で同じ効果を重ねて数えないようにします。改善が見えない場合も、計画の修正や対象の限定、停止を判断できる記録にします。

引継ぎでは、運用責任者、問い合わせ先、手順と教材の正本、権限の管理、障害・例外対応、指標の取得と見直しを確認します。担当が変わっても必要な情報へアクセスできるか、未解決の問題を誰が引き受けるかを明確にします。支援終了を日付だけで決めず、合意した条件と未完了事項を照合します。見直す頻度は業務の周期とリスクに合わせ、制度や提供条件、担当や対象が変わった時にも確認します。

renueのFDE支援では、現場ヒアリングと要件整理から設計・実装・運用、KPI設計と成果レビューを相談できます。たとえば新しい手順で使う確認・承認画面、既存データとの連携、例外時の処理、運用担当への引継ぎを具体化する範囲です。既存ツールとの連携は、API、権限、データ形式とセキュリティ条件を確認して決めます。組織変革の成功率、特定方法論の認定研修、人事・労務の判断、共通の期間や費用を一律に保証するものではありません。現在の業務、利用中のシステム、困っている処理と関係者を整理して持ち寄ると、支援の対象を検討しやすくなります。