DXがうまくいかない会社には、ある共通点があります。それは、現場への説明が後回しになることです。
ここで言う説明とは、次のようなことではありません。
- 操作説明
- 研修
- マニュアル
本来説明すべきなのは現場へ「なぜ変えるのか」です。
この説明が省略されたDXは、これまでの経験から言えますが「ほぼ例外なく」途中で止まります。なぜなら、DXはツール導入ではなく業務の前提を変える行為だから。
DXが始まるときの典型的な流れ
多くの会社で、DXは次のように始まります。
- 経営がDXの必要性を感じる
- IT部門や担当者が調査する
- ベンダーと導入検討が進む
- ツールやシステムが決まる
- 現場に説明する
この順番は、一見合理的ですし、私の記憶では40年前から同じ流れを使っています。
しかしこの流れで注意してほしいのは、「現場への説明が最後である」ということ。言い換えると「現場は何もかもが決まってから最後に説明される存在である」ということになります。
もし自分が現場の人間だったとすると、どのように感じるでしょうか？また、
- なぜ変えるのか（今のままでも良いと思うけど）
- 何を目指しているのか（現場とは関係なさそうだし）
- 自分の仕事がどう変わるのか（たぶん変わらんか手間が増えるだけ）
を理解する前に「新しいツール」「新しいシステム」がやってきますから、経営やIT部門や担当者とはズレが生まれたままになってしまいます。
なぜ現場説明が省略されるのか
DXで現場説明が省略される理由は、経営やIT部門や担当者の単なる怠慢ではありません。むしろ多くの場合、誰も悪意なく自然とそうなります。
自然とそうなる主な理由は3つあります。
① 経営は「目的を共有したつもり」になっている
経営側は
- 業界の変化
- 人手不足
- 効率化
などを背景にDXを決めます。
しかしその認識は、現場まで共有されていないことが多いものです。そのため、経営にとってのDXは「会社の未来の話」ですが、現場にとってのDXは「明日の仕事の話」のままなので、視点の違いが説明不足を生う要因になります。
② DXがITプロジェクトになる
DXの議論が普通に進むと、どこの会社でも話題は次第にこう変わります。
- システム仕様
- 機能
- データ連携
- 導入スケジュール
DXの目的である業務を改革することよりも、ITツールやシステムの話に軸が移る。
そのためこの段階で、
- 業務の意味
- 現場判断
- 例外処理
本来なら業務改革で無視できない話が意図せずして後回しになります。
③ 現場が「使う側」になってしまう
DXプロジェクトでは、現場はしばしば「ツールを使う側」として見られます。
しかし現実には、
- 業務を回しているのは現場
- 判断しているのも現場
ということは、現場は利用者ではなくDXの主体です。
この視点を誤ると、プロジェクトの前提が崩れます。
説明がないDXで現場に起きること
現場への説明がないDXでは、だいたい同じことが起きます。
現場では「仕事が増えた」と感じる
DXの目的が共有されないと、現場はこう感じます。
「入力が増えただけ」「手間が増えただけ」「チェックされることが増えただけ」
効率化のためのツールでも、目的が分からなければ単なる面倒で手間が増えただけの作業になります。
旧運用が残る
新しいツールやシステムが導入されても、
- 以前のExcel
- 手書きメモ
- 個人管理
まず無くなりません。残ります。
これは現場の抵抗ではなく、業務を止めないための現場判断です。何でも間でも旧運用を無くすという流れは考えもの。きちんと整理して判断することが大切です。
二重運用が発生する
最終的には
- 新ツールやシステム
- 旧運用
が同時に存在します。
こうしてDXは「現場負担を増やす仕組み」になってしまいます。
どうして誰も悪くないのに失敗するのか
DX失敗の記事ではよく、
- 経営が悪い
- 現場が抵抗する
- ベンダーが悪い
こうした説明や話が出てきます。ネットで見かけるIT関係の話題でも、同じような結論になっていると思います。
しかし実際、現場では、
- 経営は真剣
- 現場も協力的
- ベンダーも誠実
というケースがほとんど。私自身もこれまで現場で色々と見てきましたが、それぞれの人たちが出来ることを精一杯やっておられました。
でもですよ、残念ながらそれでも失敗します。その理由は単純です。
現場へ説明を行う存在がいないからです。
DXプロジェクトには
- システム設計
- スケジュール
- 予算
こうしたことを決定する存在はあります。
しかし、認識を揃える役割（説明する存在）が不在になっていること、本当に多いです。
これが、DXが止まる最大の理由です。
本来DXで説明すべき3つのこと
DXを進めるとき、現場に説明すべきことは3つあります。
① なぜ変えるのか
DXの背景です。
例えば
- 人手不足
- 情報の分断
- 将来の事業維持
他にもあると思いますが、例としてはこんなところでしょう。
ここが共有されないと、DXは現場からすると「押し付け」に見えます。
② 何が変わるのか
現場が最も知りたいのはここです。自分たちの仕事に関わってきますから。
- 作業手順
- 判断方法
- 情報の流れ
主にこういう部分が気になります。
これを説明せずにツールやシステムを入れると、混乱が起きます。当たり前ですね。
③ 何は変わらないのか
意外に重要なのがこれです。
DXでは「変わること」だけではなく「変わらないこと」も正確に伝える（説明する）必要があります。例えば、
- 現場判断は残す
- 顧客対応は変えない
こうした説明があると、現場の不安は大きく減ります。
DXはツールやシステムではなく認識設計で決まる
DXは
- AI
- クラウド
- SaaS
こうした技術を使うことのように語られますし、語られています。
しかし実際にDXのプロジェクトを止めるのは、こうした技術の選び方を間違えたからではありません。
止めるのは「認識のズレ」が残ったままになっていることです。
- 経営の目的
- 現場の理解
- 業務の実態
この3つが揃わなければ、どんなに有名なツールや人気のあるクラウドシステムでも定着しません。
DXの前に必要なのは「整理」です
DXが失敗する理由は、
- 技術不足でも
- ITリテラシーの低さでもなく
会社に存在する役割同士の認識の整理不足です。整理不足だからこそ、知らない間に現場説明を省略してしまい、DXが途中で止まるのです。
なぜならDXはツールやシステム導入ではなく、業務の前提を変える行為だから（ここを間違えてはいけません）。
もし今、
- DXを検討している
- あるいは途中で止まりかけている
のであれば、ツールやシステムをどうにかしようとする前に、業務と判断の整理が必要です。ツールやシステムはその後でも遅くありません。