なぜDXプロジェクトは、あれほど立派に失敗するのか
DXプロジェクトが失敗した、という話は、いまや珍しくありません。
むしろ多くの企業で、何らかの「やったけれど変わらなかった」経験が蓄積しています。
SaaSを導入した。データ基盤を作った。業務改革の会議も重ねた。説明資料も整っていた。ベンダーも優秀に見えた。にもかかわらず、数年後に残るのは、増えた画面、増えた会議、増えた入力項目と、減らない手作業だけ――。そうした話は、いまや多くの会社にとって他人事ではありません。
なぜ、こういうことが起きるのでしょうか。
原因はいくつもありますが、非常に多いのは、「変える」と言いながら、実際には現行業務をそのまま保存しようとしていることです。
これは一見、丁寧な進め方に見えます。
現場を大切にする。例外事情を尊重する。既存ルールを丁寧に吸収する。反発を避ける。どれも正しそうです。実際、その場その場では摩擦を減らします。ですが、ここに落とし穴があります。
すべての例外を救い、すべての既存運用を保存し、すべての部門都合を吸収しようとすると、システムは最終的に現行業務の複雑さを丁寧に写し取る装置になります。
そのとき、プロジェクトは進んでいるように見えて、実は会社の複雑さをデジタル化しているだけです。
こうして出来上がるのは、標準化ではありません。
「以前と同じことを、別の画面で、より多く入力しながら行う世界」です。
当然、変革の実感は生まれません。
現場から見れば、仕事が減るどころか、準備と確認が増えたように映ります。
管理部門から見れば、例外処理は相変わらず残り、むしろシステムの都合に合わせた追加作業が増えます。
営業から見れば、顧客対応は相変わらず属人的で、数字だけ厳しく見られるようになります。
結果として、プロジェクト終了後に残るのは、「また上が何かやった」という疲労感だけです。
もう一つ大きな原因は、システム導入が目的化しやすいことです。
本来、システムは業務や組織の変化を支える手段であるはずです。ところが現実には、システム導入そのものが成果として扱われることが少なくありません。稟議が通る、プロジェクトが立ち上がる、ベンダーが決まる、リリース日が来る。そこまで来ると、関係者はかなりのエネルギーを使っています。だから無意識のうちに、「ここまでやったのだから前進した」と思いたくなるのです。
ですが会社が本当に変わるのは、導入した瞬間ではありません。
導入したあとに、仕事の総量、判断の速さ、例外の扱い、人の役割が変わったときです。
さらに厄介なのは、DXプロジェクトには立派な言葉が集まりやすいことです。
データドリブン、全社最適、業務高度化、経営の可視化、生産性向上。どれも間違っていません。ですが、こうした言葉は、具体に降りてこないままでも“正しい感じ”をまとえてしまいます。
その結果、会社は「正しい言葉に包まれた曖昧なプロジェクト」を長く続けることができます。
本当は、どの業務をなくすのか、どの入力をやめるのか、どの例外を切るのか、誰の仕事を変えるのか、といった不都合な論点に踏み込まない限り、変革は始まりません。
ですが、その不都合な論点を避けたままでも、会議は何度もできます。資料もきれいに作れます。だからDXは、ときどき立派に失敗するのです。
ここで重要なのは、失敗の責任をベンダーやコンサルだけに押しつけないことです。
もちろん、提案だけで終わる外部プレイヤーにも問題はあります。ですが多くの場合、企業側もまた、「できるだけ今のままで」「でも変わったように見せたい」という矛盾した期待をプロジェクトに乗せています。
現場は仕事を変えたくない。管理部門は例外を残したい。営業は顧客対応を守りたい。経営は大きな混乱を避けたい。そうして全員の希望を少しずつ救おうとすると、最終的には誰の仕事も減らない設計になりやすいです。
では、どうすればよいのでしょうか。
ここで大事になるのが、現行を忠実に再現することと、本当に必要な価値だけを残すことは違うと理解することです。
すべての例外には理由があります。ですが、理由があることと、残す価値があることは同じではありません。
同じように、長年続いている業務には歴史があります。ですが、歴史があることと、未来にも必要であることは同じではありません。
DXを成功させる会社は、現行業務をよく理解しています。
しかし、その理解の使い方が違います。
彼らは現行業務を忠実に守るために理解するのではなく、どこが価値で、どこが惰性で、どこが単なる受け渡し作業なのかを見抜くために理解するのです。
つまり、As-Is分析の目的は再現ではなく、選別です。
そして、ここから先の時代はさらに厳しくなります。
SaaSだけではなく、API連携や生成AIが前提に入ってくると、これまで人が担ってきた「つなぎ」の仕事が一気に縮みます。
入力を転記する。会議資料をまとめる。問い合わせに一次回答する。データを探して説明用に整える。そうした仕事は、これまでDXプロジェクトの周辺に“当然あるもの”として存在してきました。ですがAIの前では、それらの多くが本質ではなく、システムや部門の断絶を人間が埋めていただけだと見えてきます。
だから、DX失敗の話は、過去の笑い話ではありません。
そこには次の時代への重要なヒントがあります。
つまり、失敗したプロジェクトの多くは、業務を変えられなかったのではなく、業務を変える覚悟のないまま、システムだけで変革を起こそうとしたのです。
本当に必要なのは、立派な構想や大きな投資より先に、
何を残し、何を捨て、何を標準に寄せるのかを決めることです。
その決断を避けたままでは、どれだけSaaSを重ねても、どれだけDXという言葉を使っても、会社は変わりません。
変わらない会社には、たいてい理由があります。
そしてその理由は、能力不足よりも、たいていはやさしさと遠慮と先送りの積み重ねです。
だからこそ、次に必要なのは、もっと立派な構想ではありません。
今度こそ、本当に何かをやめることです。