変革と二つの思考ツール

数年前に変革のマネジメント（チェンジマネジメント=Change Management）について50を超えるツールを学ぶワークショップに参加しました。
あまりに数が多かったので流石に全部は覚えていませんけれど。

日々の仕事の中では50全てを使って変革に取り組むということはあり得ませんが、ツールの特性を理解した上で、選択的に使用することはあります。
また、すぐに使うことはなくとも、いくつかのツールの学び直しをすることで使う機会を思いつくなんてこともありますし、変革とはそもそもなんだろうという哲学的な問いを向き合うようなことにもなりますので、たまに学び直し（リフレッシュ・トレーニング）しています。

先月に数年ぶりに学び直したのですが、改めて気づいたことや、今も使えるなと思った有効な思考ツールについて、学びの振り返りのために整理してみます。

変革の三つのパターン

「変革のマネジメント（チェンジ・マネジメント）」という言葉が世の中一般的に聞かれるようになったのは、20世紀の終わり頃（1990年代）でしょうか。BPR（Business Process Re-engineering）という言葉が流行し、ITを活用して仕事の仕方を抜本的に変えてゆくあたりから、変革のマネジメントは常態化してきているようになったと思います。

さらに、VUCAという言葉が出てきたり、加速的に変化をしてゆく世の中で、いかにすばやく変化して時流についてゆくかは組織のスキルになってきているのではないかなと私は思います。

そして、変革の種類というか性質も単なるプロセス変更ではないものも含まれるようになってきています。近年の変革でよくあるパターンは三つあります。

まず、わかりやすいのが組織変更（Organizational Change）でしょう。
これは組織の解体や統合のことで、M＆Aなどで二つの会社が一つになるような場合や、業績不振部門を無くしたりする場合です。
人員整理だけでなく、その場に残る人たちの間の変化への不安をどのように解消してゆくのかが非常に大切になってきます。

組織変更というのはそうそう頻繁には起きないかもしれませんけれど、システムやプロセスの新規導入（New Implementation）はテクノロジーの進歩の激しい昨今では日常的に起きている変革なのではないでしょうか。
こちらは、古いものに慣れている人たちに新しい行動をとってもらうための働きかけ、抵抗へのマネジメントが必要になってきますね。

また、ツールの導入のように目に見える何かを導入する場合と違う静かな変革（Incremental Adjustment）というパターンもあります。
これは組織の中の習慣の変更のようなもので、ある日を境にプロセスが変わるというのではなく、徐々に変化を作ってゆくようなやり方になります。

これは、例えばRTO（Return to Office）のプロジェクトで、在宅勤務に慣れた人たちにいかにしてオフィスに戻ってきてもらうか。少しずつ働き方の変更を行いながら、その効果を見て次の一手を打ってゆくような変革のアプローチです。
2年前に私が取り組んでいた事例を以下のnoteに書かせていただいています。

変革のパターンがどうであれ、重要なのはどのようにコミュニケーションを取ってゆくかであり、それこそが変革のマネジメントの核心でしょう。
ここから先では、そのコミュニケーションを取って行く上で有効な二つの思考ツールをご紹介します。

Problem Definition（問題の定義）

変革に向かって進む上では、現状の問題を明確にすることが重要になってきます。しかし、得てして「問題」というのはごちゃごちゃしててわかりにくくなってしまっているものです。
そこで、明確に定義された「問題」を作るための思考ツールとしてProblem Definitionがあります。

「問題」はしばしば「不満」や「痛み」として表されます。そしてそこから、原因や解決策、あるいは言い訳によって覆われしまい、真の問題が何であるのかが分からなくなると、表面的な理解や対応をしてしまうことになります。

そもそも「問題」とはシンプルに理想の状態と現状との間の差のことを指しており、まずそれを考える事が必要です。
しかし、これをいきなり最初からやるのは難しいかもしれません。

そこで出てくる考え方や意見を以下の4つの「真の問題ではないもの」に振り分けてゆきます。
4つとは、症状（Symptoms）、原因（Causes）、解決策（Solutions）、非難（Blame）です。

例えば、業務ソフトウェアを使う際に操作が煩雑で作業に時間がかかって残業が増えてしまっているようなケースでは、
症状は、残業が増えている
原因は、業務ソフトの操作が複雑
解決策は、使いやすいソフトへの変更
非難は、あのソフトは酷いものだった
なのでしょうけれど、これは真の問題と言えるでしょうか？

真の問題はおそらく「業務効率が悪い」ところにあります。
それが問題だとしたら、理想的な状況は業務効率が良い状態、それを定義します。例えばそれは工数（プロセスのステップ）という数字で表されるかもしれません。現状の工数が20以上あるとしたらそれを一桁まで持っていければシンプルで効率の良い業務になるでしょう。それが理想の状態です。

このように定義されると、単にソフトウェアを変更するだけという話にとどまらず、そのソフトウェアを使う業務プロセス自体を変更してゆくという話になってきますし、ソフトウェアの問題のせいにして関われなかった人たちもアイディアを出しやすくなるでしょうし、自分ごととして変革に参画ができます。

このツールの良いところは、出てくる不満などの意見を漏れなく振り分けることで、真の問題を覆い隠してしまうものをの除去し、真の問題を炙り出せるところにあります。

Backward imaging（逆イメージング）

変革を推進してゆく上で、成し遂げた先に自分たちがどのようになっているのかの明確なイメージ、あるいはビジョンを持つことをよくやりますね。

しかしイメージと言っても夢のように漠然としたものではあまり効果的ではありません。より精緻な状況の描写が必要となってきます。それは具体的には「変革が成し遂げられた時の行動」の描写です。

先ほどの業務効率改善の例で考えてみると、ある業務の工数が一桁でサクッと済むようになった未来において、人々はどのような行動をしているか、のストーリーです。
言い方変えるなら、「うまくいった状態において、どんな状況が見え、どんな会話が聞こえ、どんな事が感じられるのか」…です。

例えばそれは、まとまった時間を取って顰めっ面で仕事をしているような状況ではなく、仕事仲間との会話を楽しみながらリラックスして業務を行い、定時には「お疲れ様！」と声をかけて帰っている状況かもしれません。

このくらいイメージがはっきりしてくると、「よし、そうなるようにするにはどうしようか」という話し合いができるようになります。言葉を変えるとそのストーリーに参加しようという人を作る事ができるという事です。

Backward Imagingの強力さはこれだけではありません。
最終的なゴールの状況だけでなく、それ以前のマイルストーン的な状況におけるイメージを同じ方法でいくつも作ってゆくことで、変革にとって重要な「小さな成功（small success）」を定義する事ができ、それを一つ一つクリアすることで変革の成功が確信される状態を作る事ができます。

さらには、ストーリーの中の行動ですでにできることから始めてしまうという方法を取ることもできます。
変革の三つのパターンの中では、静かな変化（Incremental Change）のアプローチになります。行動を習慣化し、それが最終的には大きな変化につながります。

思考ツールの使い方

はじめに書かせていただいたように、変革のマネジメント（チェンジ・マネジメント）の核心はコミュニケーション戦略です。
でも誰かが一人でコミュニケーション戦略を作って、それを関係者や社員に伝えるようなアプローチでは必ずしもうまくいきません。

ご紹介した思考ツールも一人で使うものではなく、みんなで一緒に考えるために使うのが正しい使い方です。
症状や批判を皆んなから聞き出しながら「何が本当の問題なんだろうね」と一緒に考える、思考の方向を一つに絞り込むためにProblem Definitionを設定したり、目指す姿をみんなで思い描くためにBackward Imagingを手法として使ったり。

そうやって変革を遂行する人、巻き込まれてゆく人の間にコンセンサスを作り、前向きに取り組んでゆくためには、このような事をちゃんと話し合う場が大切であり、その場におけるファシリテーターはこれらのツールを使いこなして皆の意志を一つにしてゆく事が求められます。

---

変革のマネジメントのためのツール、まだまだ沢山あります。
昔のおもちゃ箱を開くような気分で、時々ご紹介できたらいいなと思っています。