ひまわり❄️雪組

なぜ「DX・システム刷新」は、現場にとって使いにくいシステムになってしまうのか

「DX」「業務改革」「システム刷新」――。

ここ数年、企業のシステム開発では、こうした言葉を頻繁に耳にするようになりました。

特に上場企業やそのグループ会社では、古くなった基幹システムをクラウドへ移行し、最新のWebシステムへ刷新するプロジェクトが次々と立ち上がっています。

ところが、実際に現場で長年システムを使ってきた人からすると、どうにも腑に落ちないことがあります。

「これ、本当に今より良くなるんですか？」

むしろ、今まで普通にできていた仕事が複雑になったり、処理が遅くなったり、現場の手間が増えたりするケースすらあります。

今回は、こうした「炎上するシステム刷新プロジェクト」の背景にある、企業IT業界の構造的な問題について考えてみます。

■ 同じプロジェクトに関わっていても、見ているものが違う

システム刷新には、実に多くの立場の人が関わります。

エンドユーザー
事業会社
親会社
コンサルティング会社
大手システムベンダー
下請け・協力会社
現行システムを長年保守してきた担当者

問題は、これらの人たちが同じものを見て仕事をしているわけではないことです。

例えば現場のユーザーが気にしているのは、

今までできていた仕事ができるか
処理が速いか
入力の手間が増えないか
例外的なケースにも対応できるか
日々の業務が止まらないか

といったことです。

一方で、経営側からすれば、

クラウド化できたか
DXになっているか
標準化できたか
グループ会社として統一できたか
新しいシステム基盤になったか

といった観点が重要になります。

そしてコンサル会社やベンダーには、さらに別の評価軸があります。

「契約した範囲の成果物を納められるか」

ここに、最初の大きなズレが生まれます。

■ 「良いシステム」の定義が人によって違う

例えば、現場の人にとって「良いシステム」とは、

「仕事が楽になるシステム」

かもしれません。

しかし、プロジェクト側からすると、

「要件定義書に書かれた要件を満たしているシステム」

かもしれません。

経営側からすると、

「クラウド化され、DXという説明ができるシステム」

かもしれません。

この3つは、似ているようで全く違います。

極端な話、

「現場の作業量は増えたけれど、クラウド化はできました」

というシステムでも、プロジェクトとしては「成功」と説明できてしまう可能性があります。

■ 現行を知っているベテランほど、置いていかれる皮肉

さらに不思議なのが、長年その業務や現行システムに携わってきたベテランが、刷新プロジェクトで必ずしも強い立場になるとは限らないことです。

本来なら、誰よりも業務を知っています。

「この処理は、なぜこうなっているのか」

「この項目は、実は後工程でこう使われている」

「この例外処理がないと、月末に業務が止まる」

こうした知識は、長年現場にいた人だからこそ持っています。

ところが、刷新プロジェクトになると、

「古いシステムの考え方」

「現行踏襲」

「レガシーな業務」

といった扱いを受けることがあります。

その結果、現行を深く知っている人の知識が、刷新の障害として扱われてしまうことがあります。

これは非常にもったいないことです。

現行システムに問題があることと、現行システムが持っている業務知識に価値がないことは、全く別の話だからです。

■ 「DXだから良くなる」は、本当にそうなのか

そして、もう一つ気になるのが「DX」という言葉です。

クラウドにする。

Webシステムにする。

データを一元化する。

最新のデータベースを使う。

APIでシステムを連携する。

これらは技術的な手段です。

しかし、

「新しい技術を使うこと」と「業務が良くなること」は同じではありません。

例えば、現行システムではボタン一つで帳票を出せていたとします。

ところが新システムでは、複数のデータベースをまたいでデータを連携し、処理が完了するまで5分待たなければならない。

もし本当にそんな仕様になったとしたら、現場からすれば、

「それ、DXになったんですか？」

という話になります。

■ 「帳票を出すのに5分」という世界

例えば、ある担当者が日々の業務で帳票を出すとします。

現行では、

「条件を指定してボタンを押す → 数十秒で帳票が出る」

だったものが、新システムでは、

「データ連携を開始 → 複数DB間でデータ連携 → 処理待ち → 帳票生成」

となり、結果として5分かかる。

これが一日に1回ならまだしも、何度も繰り返す業務だったらどうでしょうか。

担当者が10回帳票を出せば、それだけで50分です。

年間で考えれば、かなりの時間になります。

しかも、これは「システム障害」ではありません。

仕様どおりに動いている正常なシステムなのかもしれません。

ここが怖いところです。

■ その帳票、Excelで作った方が早くないですか？

こうなると、現場から出てくるのが、

「だったらExcelで作った方が早くない？」

という声です。

これは決して笑い話ではありません。

もちろん、Excelにはデータ管理やセキュリティ、属人化などの問題があります。

だからこそ、何でもExcelに戻せばいいという話ではありません。

しかし、

「新システムを導入した結果、Excelで手作業した方が早い」

という状態になっているのであれば、少なくとも業務設計やシステム設計について、一度立ち止まって考える必要があります。

極端なことを言えば、

「手書きした方が早い」

というレベルまで行けば、もはや技術導入の目的そのものを問い直す必要があります。

■ なぜ、そんなシステムが生まれてしまうのか

ここには、企業システム開発特有の構造があります。

① 経営層と現場の距離

経営層は「システムを刷新する」という意思決定をします。

しかし、毎日そのシステムを何百回も操作するわけではありません。

そのため、現場が感じる「1回あたり数十秒の遅さ」や「入力項目が1つ増えた」といった問題が、経営判断では見えにくくなります。

② コンサル会社と現場の距離

プロジェクトの途中からコンサル会社が入ってくることもあります。

コンサル側は、短期間で業務を理解し、要件を整理し、資料を作成しなければなりません。

しかし、10年、20年かけて蓄積された現場の暗黙知を、数か月のヒアリングだけで完全に理解するのは簡単ではありません。

③ ベンダーと現場の評価軸

ベンダー側では、納期、予算、契約範囲、成果物、品質などが重要になります。

現場が、

「この機能、使いにくいです」

と言っても、

「要件としては満たしています」

となることがあります。

ここにも大きなズレがあります。

④ 下請け構造

さらに大規模なプロジェクトでは、元請け、一次請け、二次請け……と会社が何層にも分かれることがあります。

現場の業務を理解している人と、意思決定をしている人の間に、何人もの人間が入ります。

その結果、

「現場では困る」

という情報が上に伝わるまでに、少しずつ意味が変わってしまうことがあります。

■ 「要件を満たしている」と「仕事ができる」は違う

システム刷新で特に注意したいのが、この問題です。

例えば要件定義書に、

「帳票を出力できること」

と書いてあったとします。

新システムで帳票が出力できれば、要件は満たしたことになります。

しかし、

「帳票が出るまで5分かかる」

「操作手順が10個必要」

「以前は自動だった処理を手動で補完する必要がある」

という状態なら、現場にとっては大きな問題です。

つまり、

機能要件を満たすことと、業務を成立させることは別物

なのです。

■ 本当の意味での「刷新」とは何なのか

システム刷新だからといって、古いものを全部捨てればいいわけではありません。

逆に、現行システムをそのままコピーすればいいわけでもありません。

重要なのは、

「現行業務の何が必要で、何が不要なのか」を見極めること

です。

現行システムに古い部分があるなら、新しくする。

無駄な業務があるなら、なくす。

二重入力があるなら、統合する。

しかし、

「なぜこのデータが存在するのか」

「なぜこの処理が必要なのか」

「この処理をなくしたら、誰が困るのか」

を理解せずに、単純に新しい仕組みに置き換えてはいけません。

■ 現場の「それ、おかしくないですか？」を無視してはいけない

大規模プロジェクトでは、どうしても資料、会議、進捗率、課題管理表、テスト項目などが中心になります。

しかし、最終的にシステムを使うのは人間です。

その人間が、

「今までできたことができなくなった」

「処理が遅くなった」

「操作が増えた」

「Excelでやった方が早い」

と言っているのであれば、その声には耳を傾ける必要があります。

それは単なる「現場のわがまま」ではありません。

長年業務を回してきた人たちが持っている、非常に重要な業務知識だからです。

■ 「DX」という言葉に惑わされないために

DXという言葉には、どうしても「新しい」「先進的」「クラウド」「AI」「データ活用」といったイメージが付きまといます。

しかし、企業にとって本当に重要なのは、最新技術を導入したという事実そのものではありません。

その結果、仕事がどう変わったのか。

ここを見る必要があります。

処理時間が短くなったのか。

入力作業が減ったのか。

ミスが減ったのか。

担当者が判断に集中できるようになったのか。

顧客へのサービスが良くなったのか。

それとも、

「クラウドになりました」

「Webシステムになりました」

「新しいデータベースになりました」

というだけなのか。

ここは冷静に区別する必要があります。

■ 炎上プロジェクトは「技術」だけの問題ではない

システム開発が炎上すると、

「技術力が足りなかった」

「ベンダーの能力が低かった」

「現場が協力しなかった」

など、誰か一人に原因を求めたくなります。

しかし、実際にはもっと構造的な問題であることがあります。

それぞれの立場が、それぞれの評価軸でプロジェクトを見ている。

そして、その評価軸を統合する役割が不十分なまま、プロジェクトだけが前へ進んでしまう。

これが大きな問題になります。

現場は「仕事が回るか」を見ている。

経営は「経営戦略に合っているか」を見る。

コンサルは「改革の方向性」を見る。

ベンダーは「システムとして実装できるか」を見る。

下請けは「与えられた作業をどう完了させるか」を見る。

どれも、それ自体は間違いではありません。

問題は、それらを最後に一つの「使える業務システム」にまとめる視点が失われることです。

■ 「新しくなったのに、仕事は悪くなった」という悲劇

システム刷新の本来の目的は、システムを新しくすることではありません。

企業の業務をより良くすることです。

だからこそ、

「古いシステムだからダメ」

「クラウドだから良い」

「Webだから先進的」

という単純な話ではありません。

古いシステムでも、業務を正確かつ高速に支えているのであれば、そこには長年かけて蓄積された価値があります。

新しいシステムにするのであれば、その価値を理解した上で、より良い形へ進化させる必要があります。

■ 最後に

企業のシステム刷新は、決して「古いシステムを新しいシステムに置き換えるだけ」の仕事ではありません。

そこには、

経営

現場

コンサルティング

ベンダー

下請け

それぞれの思惑と評価軸があります。

そして、その間にあるズレが大きくなればなるほど、

「立派な資料はあるのに、現場では使えない」

「最新のクラウドシステムなのに、以前より仕事が遅い」

「DXしたはずなのに、Excel作業が増えた」

という、本末転倒な状況が生まれます。

もしかすると、企業システムの世界で本当に難しいのは、プログラムを書くことではないのかもしれません。

「会社として何を実現したいのか」と「現場では実際に何が必要なのか」を、最後までつなぎ続けること。

そこに、システム刷新の最大の難しさがあるのだと思います。

そして現場から出てくる、

「それ、今より不便になってませんか？」

という素朴な疑問こそ、巨大なプロジェクトの中で失ってはいけない視点なのではないでしょうか。