変革プロジェクトのキックオフで「今回はチェンジマネジメントに力を入れます」と話したら、情報システム部門の方から「では、変更諮問委員会（CAB）には誰が出ますか」と返ってきた。同じ言葉を使っていても、こうして話がかみ合わないことがあります。
同じ「チェンジマネジメント」という言葉が、IT運用の世界と組織変革の世界で、別の意味で使われています。2つは別物です。ただ、システム導入のような変革では、片方だけでは足りません。この記事では、2つを並べて違いを整理し、一緒に進めるときの手順も示します。
この記事で答える問い
- ITILの「変更管理」は、いま何と呼ばれ、何を目指しているのか
- 組織変革のチェンジマネジメントとは、どこが違うのか
- 一つのプロジェクトで両方を進めるとき、取り違えをどう防ぐのか
ITILの変更管理（ITIL 4ではチェンジイネーブルメント）は、ITサービスへの変更のリスクを評価し、承認し、スケジュールを管理して、変更を成功させる仕組みです。組織変革のチェンジマネジメントは、変化を人が受け入れ、新しいやり方で働き続ける状態までを扱います。日本語にするなら、前者は「変更管理」、後者は「変革管理」に近い言葉です。
なぜ同じ言葉で別のものを指すのか
同じ言葉で別のものを指すのは、英語の change management が、文脈によって2つの意味で使われているためです。
- IT運用の文脈：システムやサービスへの変更（設定変更、リリース、機器の入れ替えなど）を、事故なく実施するための管理。ITIL（IT Infrastructure Library、ITサービスマネジメントのベストプラクティス集）で体系化され、日本語では「変更管理」と訳されてきました
- 組織変革の文脈：制度や仕組みが変わるときに、人が理解し、納得し、新しいやり方を使い続けるまでを支える取り組み。Prosci社は、組織の変化の「人の側面」を扱う方法としてチェンジマネジメントを説明しています
どちらも英語では同じ change management です。日本語では、IT運用の文脈で長く「変更管理」と訳されてきたため、「チェンジ」と聞くと、まず「変更」を思い浮かべる方が少なくありません。一方、組織変革の文脈のチェンジは、仕組みの「変更」というより、人や組織の「変革」に近い意味です。同じ英単語をそのまま「変更」と訳すと、この違いが見えなくなります。組織変革のチェンジマネジメントそのものについては、チェンジマネジメントとは？組織変革を成功させる基本と進め方で詳しく解説しています。
ITILの「変更管理」はいま何と呼ばれているか
ITILの変更管理は、いまは「チェンジイネーブルメント（change enablement）」と呼ばれています。ここに至るまで、版ごとに名前と位置づけが変わってきました。
ITIL v3／2011年版：変更管理（Change management）
ITIL 2011年版では、変更管理はサービストランジション（新しいサービスや変更を本番環境に移す段階）のプロセスの一つでした。目的は、すべての変更のライフサイクルを管理し、ITサービスへの影響を最小限に抑えながら、有益な変更を実施できるようにすることとされています。
ITIL 4：チェンジコントロールから、チェンジイネーブルメントへ
2019年に公開されたITIL 4のファウンデーションでは、この領域は「change control」という名前のプラクティス（組織が仕事を進めるための資源のまとまり）になりました。その後、2020年に公開されたプラクティスガイドで「change enablement（チェンジイネーブルメント）」に改称されています。
チェンジイネーブルメントの目的は、リスクが適切に評価されていることを確かめ、変更の実施を承認し、変更スケジュールを管理することで、サービスや製品の変更の成功数を最大化することです。名前の変化には、変更を「統制する」ことより、事業の成果につながる変更を「実現させる」ことに重きを置く意図があると説明されています。
2026年に公開されたITIL（Version 5）でも、プラクティス名はチェンジイネーブルメントのままと紹介されています。
ITILの中では「変更」と「変革」が分かれてきた
ITIL v3のころ、ITILで change management と言えば、ITサービスへの変更を管理するプロセスのことでした。ITIL 4では、変更はチェンジイネーブルメントが扱い、それとは別に「組織のチェンジマネジメント（Organizational change management）」というプラクティスが置かれています。こちらの目的は、人の側面を扱うことで、組織の変化を円滑に実施し、長く続く効果を得ることです。
2つの線引きもはっきりしています。ITIL 4のプラクティスガイドでは、組織の変化のマネジメントはチェンジイネーブルメントの範囲外とされ、組織のチェンジマネジメントのガイドに委ねられています。チェンジイネーブルメントへの改称にも、人の変化を指す一般的な「チェンジマネジメント」との混同を避ける狙いがあったと説明されています。
組織のチェンジマネジメントのガイドは、さらに「変化」と「変革」を区別しています。変革は、信念や価値観の変化を伴う働き方の転換であり、変革に当たる場合は人に焦点を当てた手法が必要になる、という考え方です。
2026年のITIL（Version 5）でも、組織のチェンジマネジメントはチェンジイネーブルメントと別のプラクティスとして紹介されています。さらにVersion 5では、組織の大きな変革の進め方を扱う「ITIL Transformation」という出版物と研修モジュールが用意されました。こちらはプラクティスではなく、変革を統治し、実行し、学びながら進めるための指針とされています。ただし、ITIL（Version 5）は2026年に公開されたばかりのため、変更と変革の位置づけは今後さらに変わる可能性があります。最新の状況は公式情報で確認してください。
つまり、ITILの中では「ITサービスへの変更」と「組織と人の変革」が、名前の上でも別のものとして整理されてきました。ところが日本語では、どちらの change も「変更」と直訳されやすく、この区別が伝わりにくくなります。取り違えが起きやすいのは、そのためです。
変更管理は英語で何という？
ITILの「変更管理」に当たる英語は、版によって change management、change control、change enablement と変わってきました。海外の資料やツールの画面を読むときは、版の違いを頭に置いておくと迷いません。会議や資料でよく出てくる言葉の対応は、次のとおりです。
| 日本語 | 英語 | 使われる場面 |
|---|---|---|
| 変更管理 | change management | ITIL v3／2011年版のプロセス名。今も一般的な呼び方として残っている |
| 変更管理（ITIL 4初版） | change control | 2019年のITIL 4ファウンデーションでのプラクティス名 |
| チェンジイネーブルメント | change enablement | 2020年のプラクティスガイド以降の名前 |
| 変更要求 | request for change（RFC） | 変更を申請するときの書類や記録 |
| 変更諮問委員会 | change advisory board（CAB） | 変更を評価し、承認の判断を助ける会議体 |
| 組織のチェンジマネジメント（変革管理） | organizational change management | ITIL 4で、人の側面を扱う別のプラクティス |
英語で「change management」とだけ書かれていたら、まず前後の文脈を見ます。RFCやCABと一緒に出てくればIT運用の変更管理、研修や抵抗、定着と一緒に出てくれば組織の変革管理です。
ITILの変更管理では、変更を評価するときに確かめる問いが「7つのR」としてよく紹介されてきました。資料によって言い回しは少し違いますが、中身はおおむね次の7つです。
- Raised：誰が変更を求めたか
- Reason：なぜ変更が必要か
- Return：変更で何が得られるか
- Risks：どんなリスクがあるか
- Resources：何が必要か
- Responsible：誰が作り、試し、実施するか
- Relationship：ほかの変更とどう関係するか
7つのRは、システムの変更を安全に通すための問いです。ただ、読み比べると、人の側の問いが入っていないことに気づきます。「この変更で、誰の仕事がどう変わるか」は7つのどれにも入りません。そこを受け持つのが、組織の変革管理のほうです。
変更管理とチェンジマネジメントは何が違う？
一番の違いは、何を成功とみなすかです。変更管理はITサービスへの変更が障害なく実施されることを、チェンジマネジメントは人が新しいやり方で働き続けることを、それぞれゴールにしています。そのほかの観点でも、差ははっきりしています。
| 観点 | 変更管理（チェンジイネーブルメント） | チェンジマネジメント（組織の変革管理） |
|---|---|---|
| 目的 | ITサービスや製品への変更を成功させる | 変化を人が受け入れ、新しいやり方で働き続けるようにする |
| 対象 | システム、設定、機器、サービスなどへの変更 | 変化の影響を受ける人と組織 |
| 扱う単位 | 一件ごとの変更 | 変革の取り組み全体と、一人ひとりの移行 |
| 主な問い | この変更は安全か、いつ実施するか | 人は理由を理解し、使い続けているか |
| 主な道具 | リスクの評価、変更の承認（変更権限）、変更スケジュール | 影響の洗い出し、説明と対話、研修、相談先、定着の確認 |
| 成功の目安 | 変更が障害なく成功する | 実際の仕事で新しいやり方が使われている |
目的の違いを一言で言えば、変更管理は「変えたものが壊れないか」を見て、チェンジマネジメントは「変えたものを人が使うか」を見ます。
競合ではなく、同じプロジェクトで並走する
新しい業務システムを入れる場合を考えてみます。変更管理の側では、変更の申請、リスクの評価、承認を経て、本番に反映します。チェンジマネジメントの側では、誰の仕事がどう変わるかを洗い出し、変える理由を伝え、研修と相談先を用意し、使われ方を確かめます。
本番への反映日は、両方の予定がそろう日です。変更が成功しても、使われなければ変革は終わっていません。逆に、人の準備が整っていても、変更が失敗すれば業務が止まります。
現場ではこうつまずく
この言葉の取り違えには、私自身もつまずいたことがあります。
つまずき1：「変更管理」のイメージが先に立ち、変革管理が伝わらない
以前、ITを専門にしている方々と、チェンジマネジメントという用語の定義について話したことがあります。こちらは組織や人の変革のことを話しているつもりでしたが、相手の頭には変更管理のイメージが先に浮かんでいて、変革管理という考え方がなかなか伝わりませんでした。
つまずき2：相手の「チェンジ」を知らないまま説明していた
あとから、どうすればよかったかを考えました。行き着いたのは、相手が前提にしている変更管理、つまりそれを説明しているITILを、私自身が理解していなかったことです。ITILの変更管理が何を目的に、どこまでを扱うのかを知っていれば、「変更管理はここまで。チェンジマネジメントは、その変更を人が使い続けるところまで」と、対比で説明できたはずです。
相手の言葉を否定して自分の定義を押し通すより、相手の知っている概念を足がかりにしたほうが伝わります。この記事の比較表は、そのときの自分に足りなかったものを形にしたものです。
2つのチェンジの取り違えはどう防ぐ？
変更管理とチェンジマネジメントの取り違えは、会話の最初に意味を確かめ、文書と計画の中で二つを分けて扱えば防げます。一つのプロジェクトで両方を進めるときの手順は、次の5つです。
- 話し始めに、どちらの「チェンジ」かを確かめる：「今日のチェンジマネジメントは、ITの変更管理の話ですか、人と組織の変革の話ですか」と一言聞く
- 文書では書き分ける：「変更管理（ITIL）」「チェンジマネジメント（組織変革）」のように、かっこで文脈を添える
- 役割を2つとも置く：変更の承認と実施を担う人と、人の移行を担う人を、計画書で別々に決める
- 2つの予定を重ねる：変更スケジュールの反映日と、説明、研修、相談先の準備の時期を同じ表に並べる
- 成功を別々に測る：変更の成功（障害がないか）と、定着（使われているか）を、別の指標と時期で確かめる
AI活用のポイント：計画書の「チェンジ」を仕分ける
手元の計画書や議事録で「チェンジ」がどちらの意味で使われているかの仕分けは、生成AIに任せやすい作業です。試すときは、機密に当たる部分を消し、名前を置き換えた文章を使ってください。
次の文章に出てくる「チェンジ」「変更」「チェンジマネジメント」という言葉を、(A) ITサービスへの変更の管理（ITILの変更管理、チェンジイネーブルメント）(B) 組織の変化を人の側面から支える取り組み（組織のチェンジマネジメント）のどちらの意味かに分けて、表にしてください。どちらとも読める箇所は「要確認」とし、その理由を書いてください。文章：[計画書や議事録の一部を匿名化して貼り付け]
「要確認」になった箇所が、関係者の間で認識がずれやすい所です。AIの判定をそのまま正解とせず、書いた本人に意図を確かめてから書き分けます。
チェックリスト：2つのチェンジを取り違えていないか
- 計画書の「チェンジマネジメント」が、どちらの意味かを説明できる
- 変更の承認を担う人と、人の移行を担う人が、別々に決まっている
- 変更スケジュールと、説明・研修の予定が、同じ表で見られる
- 本番反映のあとに、使われ方を確かめる予定がある
- 情報システム部門と推進チームが、互いの用語を知っている
- 完了の条件に「使われているか」が含まれている
まとめ
変更管理とチェンジマネジメントは別物です。けれども、システムを入れて人の働き方を変える場面では、どちらか一方だけでは終わりません。
- ITILの変更管理は、ITIL 4ではチェンジイネーブルメントと呼ばれ、ITサービスへの変更を成功させることが目的
- 組織変革のチェンジマネジメントは、人が新しいやり方で働き続けるまでを扱う。ITIL 4でも別のプラクティスとして分けられている
- システム導入のような変革では、2つを書き分け、役割と予定をそろえて並走させる
組織変革のチェンジマネジメントの全体像と代表的なフレームワークは、チェンジマネジメントとは？組織変革を成功させる基本と進め方で、個人の移行を5つの要素で確かめる方法はADKARモデルとは？で解説しています。
仕組みの側と人の側のすれ違いは、AIのルールづくりでも起きます。AIマネジメントシステムの国際規格とチェンジマネジメントの関係は、ISO/IEC 42001を入れても現場が変わらないのはなぜ？で扱っています。
関連記事
参照情報
- Cabinet Office, ITIL Service Transition, 2011 edition, TSO, 2011
- AXELOS, ITIL Foundation: ITIL 4 Edition, TSO, 2019
- AXELOS, ITIL 4 Practice Guide: Change Enablement, 2020
- AXELOS, ITIL 4 Practice Guide: Organizational Change Management, 2020
- AXELOS, Reader’s manual: ITIL 4 Practice Guide, 2020
- PeopleCert, ITIL Transformation (Version 5), 2026（itil.comの紹介ページ）
- Amazon Web Services, Change Enablement in the Cloud（AWS Well-Architected ホワイトペーパー）
- Prosci, Prosci Methodology（prosci.com）
- Jeffrey M. Hiatt, ADKAR: A Model for Change in Business, Government and our Community, Prosci Learning Center Publications, 2006
