新しい基幹システムの導入。営業プロセスのデジタル化。データ基盤の構築。組織再編。AI活用プロジェクト。── いま、あなたの組織では、いくつの変革プロジェクトが同時に進行しているだろうか。
ある企業の変革推進室長は、月曜の朝にこうつぶやいた。「先週はCRM研修のフォロー。今週はワークフローシステムの切り替え対応。来週からデータ入力の標準化が始まる。現場に『また変わるのか』と聞かれるたびに、正直、自分も同じことを思っている」。DXの号令のもと、多くの企業が複数の変革を同時並行で走らせている。経営層から見れば、どのプロジェクトも戦略上不可欠だ。しかし、現場から見える景色はまったく異なる。変革の波が途切れることなく押し寄せ、現場は息をつく暇がない。この光景に、覚えはないだろうか。
この状態が続くと、組織に何が起きるか。変革疲れ（Change Fatigue）である。
Gartnerの調査によれば、2016年時点で組織変革に対して「受け入れる意思がある」と回答した従業員は74%だったのに対し、2022年にはわずか38%にまで低下した (Gartner, 2022)。変革の量が増えるほど、変革への受容力が半減している。変革疲れは個人の気力の問題ではない。組織が処理できる変革の総量を超えたとき、構造的に発生する現象だ。あなたの組織で、直近の変革プロジェクトに対する現場の参加率や研修後の行動変容率を確認してみてほしい。同じ傾向が見えるはずだ。
以前のInsight「なぜ変革の70%は失敗するのか」で論じた失敗の構造的要因の中に、変革疲れは明示的に含まれていなかった。しかし、変革の70%が期待した成果を達成できない背景には、この「静かに蝕む疲弊」が深く関与している。
変革疲れはどこから来るのか
「変革の総量」という視点の欠如
多くの組織では、個々のプロジェクトの計画は精緻に設計されている。スコープ、スケジュール、リソース、リスク。しかし、組織全体として「いま、どれだけの変革を同時に抱えているか」を俯瞰する視点が決定的に欠けている。
プロジェクトAはIT部門が主管し、プロジェクトBは営業本部が推進し、プロジェクトCは経営企画が統括している。それぞれのプロジェクトは独立して承認され、独立してリソースが配分されている。しかし、変革の影響を受けるのは同じ現場の同じ人々だ。営業部門の田中さんは、CRMの切り替えと組織再編とデータ入力ルールの変更を、同時に受け止めなければならない。もし、ある部門の同じ役割に対して複数の変革が同時に進行しているなら、それはすでに飽和の兆候と見てよい。
Prosciは、組織が同時に処理できる変革の量には限界があるとし、この限界を変革の飽和（Change Saturation）と呼んでいる (Prosci, 2023)。飽和点を超えると、個々のプロジェクトがどれほど優れた計画を持っていても、現場の受容力が追いつかず、すべてのプロジェクトの成功確率が連鎖的に低下する。飽和を防ぐには、組織がいまどれだけの変革を吸収できるかという変革吸収力（Change Capacity）を把握する必要がある。Change Saturationが「限界を超えた状態」を指すのに対し、Change Capacityは「限界そのものの大きさ」を表す。後者を測定し、前者に至る前に手を打つ ── それが変革ポートフォリオ管理の核心だ。
Jカーブの「多重衝突」
以前のInsight「変革の『谷』を乗り越える5つのレバー」で論じたとおり、変革プロジェクトにはJカーブの谷が必ず訪れる。一つの谷であれば、スポンサーシップとQuick Winで乗り越えられる。しかし、複数のJカーブが重なったとき、何が起きるか。
プロジェクトAの谷から這い上がりかけたところに、プロジェクトBの谷が始まる。Bの混乱がまだ収まらないうちに、Cの導入が始まる。現場にとっては、谷から谷へと落ち続ける感覚だ。一つの変革で得られるはずの上昇 ── パフォーマンスの回復と成長 ── を実感する前に、次の変革が覆いかぶさる。
この多重衝突は、個々のプロジェクトの問題ではなく、ポートフォリオレベルの設計の問題だ。各プロジェクトのタイミング、対象部門、影響の深さを俯瞰し、Jカーブが同一の組織単位で同時に発生しないよう調整する。この調整機能が欠けている組織が、変革疲れの罠にはまる。
変革疲れは、個々のプロジェクトの品質とは無関係に発生し得る。問題は個別の変革の設計ではなく、変革の「総量」と「重なり」のマネジメントの不在にある。
変革疲れが組織にもたらすもの
「静かな撤退」── 抵抗よりも深刻な反応
変革疲れの最も危険な兆候は、声高な抵抗ではない。ここでは、この現象を静かな撤退（Quiet Withdrawal）と呼びたい。
抵抗は少なくとも関心の表れだ。「このやり方は間違っている」と声を上げる人は、変革に向き合っている。しかし、変革疲れが蓄積した組織では、人々はもはや反対すらしない。研修には出席するが、学んだことを実行しない。新しいシステムにログインするが、最低限の入力しかしない。変革に関するアンケートには「概ね賛成」と回答するが、行動は何も変わっていない。先行指標を見逃してはならない ── パルスサーベイの微減傾向、プロジェクト関連の問い合わせ件数の減少、研修後アンケートの自由記述欄が空白になる兆し。声なき離脱は、数字の「微かな変化」に現れる。
Gartnerの調査では、変革疲れを経験している従業員は、組織に留まる意向が最大で3分の1にまで低下することが報告されている (Gartner, 2022)。変革疲れは離職リスクにも直結する。しかも、最初に離れていくのは、変革に最も積極的だった人材 ── チェンジエージェントやアーリーアダプター ── であることが少なくない。変革の推進力そのものが組織から流出していく。
スポンサーシップの「帯域幅」問題
以前のInsight「『スポンサー不在』がプロジェクトを殺す」で論じたとおり、スポンサーの積極的かつ可視的な関与は変革成功の最大予測因子だ。しかし、一人のスポンサーが同時に深く関与できるプロジェクトの数には限界がある。
CxOの時間とエネルギーは有限だ。5つの変革プロジェクトのスポンサーを兼務している経営者が、そのすべてでABCモデル ── Active participation、Building coalition、Communicating directly ── を実行することは物理的に不可能だ。結果として、各プロジェクトへのスポンサーシップは薄く広がり、どのプロジェクトも「名前だけのスポンサー」状態に陥る。
変革疲れの組織では、スポンサー自身もまた疲弊している。この構造を見落としたまま「スポンサーの関与を強化せよ」と求めても、解決にはならない。必要なのは、スポンサーの帯域幅に見合った変革ポートフォリオの設計だ。あるいは、メインスポンサーが全体方針を示し、個別プロジェクトの実行支援を委任されたシニアリーダーが担うというスポンサーシップの階層化も一つの選択肢になる。
変革の「交通整理」を設計する
変革ポートフォリオの可視化
以前のInsight「PMOは『管理者』から『伴走者』へ」で論じた価値実現型PMOの重要な機能の一つが、ここで浮上する。組織全体の変革負荷を可視化し、交通整理する機能だ。
具体的には、以下の3つの軸で変革ポートフォリオを可視化する。
第一に、影響マップの作成。すべての進行中・計画中の変革プロジェクトを洗い出し、影響を受ける部門・役割を特定する。同じ部門に複数の変革が集中していないか、特定の役割（たとえば現場マネージャー）に過度な負荷がかかっていないかを可視化する。この作業は、データで変革の「地図」を描く行為だ。
第二に、タイミングの調整。Jカーブの谷が同一部門で同時に発生しないよう、プロジェクトの開始時期やロールアウトの順序を調整する。プロジェクトAのGo Liveから定着までの90日間は、同じ部門へのプロジェクトBの展開を控える。この「変革のバッファ」を計画段階で組み込むことが、変革疲れの予防策になる。
第三に、変革吸収力（Change Capacity）のモニタリング。サーベイやパルスチェックを通じて、組織の各部門が現在どの程度の変革負荷を感じているかを定期的に測定する。数値が閾値を超えた部門には、新たな変革の展開を延期するか、追加のサポートを投入する。勘と経験ではなくデータで、組織の変革吸収力を語る。これがandChangeの基本スタンスだ。
「捨てる」という経営判断
変革ポートフォリオの最適化において最も難しいのは、「やらない」を決めることだ。
経営層にとって、承認済みのプロジェクトを延期・縮小・中止することは、自らの判断の撤回に映る。しかし、組織の変革吸収力を超えた状態ですべてのプロジェクトを同時に走らせれば、5つすべてが60%の完成度で頓挫するリスクがある。3つに絞って確実に定着させるほうが、組織全体の変革成果は大きい。 判断の軸は「戦略的重要度」と「現場への負荷」の2つだ。戦略的重要度が高く、現場負荷が相対的に低いものから着手し、負荷が高いものは既存プロジェクトの定着を待ってから展開する。
McKinseyの調査でも、変革の優先順位付けと資源の集中が成功率を高めることが示されている (McKinsey, 2021)。変革の「量」を競うのではなく、変革の「質」と「定着」を重視する。これは経営の意思決定であり、PMOや現場だけでは下せない判断だ。スポンサーが自らの帯域幅を冷静に評価し、「いま本当に同時にやるべきか」を問い直す。その問いかけ自体が、変革疲れへの最初の処方箋になる。
すべてを同時に変えようとする組織は、結局何も変えられない。変革の「量」を管理することは、変革の「質」を守ることに他ならない。
実務への示唆
変革疲れへの対処は、個人のレジリエンス強化ではなく、組織の設計の問題として扱うべきだ。そして、変革ポートフォリオの管理は「新たな管理コスト」ではない。すでに発生している変革疲れの隠れコスト ── 離職、生産性低下、プロジェクト遅延 ── を可視化し、削減するための投資だ。
第一に、CDO・CIO・変革推進室は「変革影響マップ」を作成し、経営会議に報告する。 進行中のすべてのプロジェクトを一枚のマップに集約し、各部門が受けている変革の総量を可視化する。最初の一歩は、既存のプロジェクト一覧に「影響を受ける部門」と「影響の深さ（業務プロセスの変更度合い）」の2列を加えること。このマップが存在するだけで、「また新しいプロジェクトを始めるのか」という現場の声に、データで応えられるようになる。
第二に、PMO（またはXMO）は、プロジェクト承認プロセスに「変革負荷アセスメント」を組み込む。 新規プロジェクトの承認時に、対象部門の現在の変革負荷を評価し、追加のプロジェクトが許容範囲内かを判定するステップを設ける。具体的には、既存の起案書テンプレートに「対象部門が現在受けている他の変革プロジェクト」を記載する欄を追加するところから始められる。プロジェクト単体のROI評価だけでなく、ポートフォリオ全体への影響を審査する仕組みだ。
第三に、経営層は四半期に一度「変革ポートフォリオレビュー」を実施する。 個別プロジェクトの進捗レビューではなく、組織全体の変革の量と質を俯瞰する場を設ける。まずは次の経営会議で「現在進行中の変革プロジェクトは全部でいくつあるか」という問いを投げかけることが出発点になる。延期すべきプロジェクト、統合すべきプロジェクト、追加リソースが必要なプロジェクトを経営判断として仕分ける。この場で「やらない」を決められるかどうかが、変革疲れを防ぐ組織と、変革疲れに蝕まれる組織の分岐点になる。
まとめ ── 変革の量を制する者が、変革の質を制す
変革疲れは、組織が「変わろうとしすぎた」結果ではない。変革の総量と重なりを管理しなかった結果だ。
一つひとつの変革プロジェクトは、それ単体では正しい取り組みかもしれない。しかし、正しいプロジェクトが10個同時に走れば、組織は麻痺する。個々のJカーブは設計で越えられるが、5つのJカーブが同時に押し寄せれば、設計だけでは対処できない。必要なのは、プロジェクトレベルのマネジメントではなく、ポートフォリオレベルでの変革負荷のマネジメントだ。
テクノロジーだけでは、組織は変わらない。そして、変革の量を増やすだけでも、組織は変わらない。データで変革の総量を可視化し、チェンジマネジメントで組織の吸収力を見極め、定着するまで一つひとつの変革に寄り添う。「すべてを一度に」ではなく、「確実に、一つずつ」。冒頭の変革推進室長が、月曜の朝に「今週はこの一つに集中できる」と思えたとき ── その組織は、変革疲れの罠を抜け出している。