形骸化するDX、原因はここにあった

シリーズ:DX導入の落とし穴

システムやツールは、導入した瞬間がゴールに見えます。

でも、本当に試されるのは導入した後です。せっかく作った運用フローが、いつの間にか誰もやらなくなる。そんな「形骸化」は、現場のやる気が低いから起きるのではありません。

はじめに

新しい運用を回し始めた直後は、みんな真面目に入力してくれます。ところが数週間経つと、抜けが増える。気づけば、決めたフロー通りに動いているのは自分だけ。

これは、私自身がやってしまった失敗です。

この記事では、前半で「良い運用フローを作ったはずなのに、なぜ形骸化したのか」という私の体験を正直に書きます。後半では、その反省から見えた「導入後に運用を回し続けるための落としどころ」を、これから運用を設計する方に向けて提案します。

「あるべき姿」だけを、追いかけていた

私が設計した運用フローは、理屈の上では正しいものでした。

必要な情報を漏れなく記録し、後工程で誰が見ても分かるようにする。データの品質を保つために、入力の手順もきちんと決める。「こうあるべきだ」という理想の形を、そのまま運用ルールに落とし込みました。

問題は、その「あるべき姿」だけを見ていたことです。

理想の形は描けても、それを毎日回す作業者の状況を、私は十分に見ていませんでした。あるべき姿と、現場が実際に割ける時間や労力。この二つの間にあるギャップを、埋める工夫をしないまま走り出してしまったのです。

今ならそう言えます。けれど当時は、正しい設計をすれば運用は回るはずだと信じていました。

手間を、換算していなかった

いちばんの落とし穴はここでした。運用を設計するとき、私は「この作業に何分かかるか」をきちんと数えていませんでした。

一つひとつの入力は、単体で見れば小さな手間です。数十秒かもしれません。でも、それが一日に何度も、何人分も積み重なる。運用全体で見たとき、現場にどれだけの負荷が乗るのか。その総量を、設計の段階で換算していなかったのです。

結果として、現場は静かにキャパオーバーになりました。

作業者は、本来の業務を抱えながら、新しい運用の手間を上乗せされました。無理が続けば、どこかが抜け落ちます。抜けたのは、優先度が下がった「新しい運用のほう」でした。

なぜ、誰もやらなくなったのか

形骸化の理由を、後から整理すると三つありました。

理由①:なぜこの作業が必要かを、作業者が理解していなかった

私は「あるべき姿」を頭の中では分かっていました。でも、それを作業者と十分に共有していませんでした。目的が伝わっていない作業は、忙しくなった瞬間に「とりあえず省いていいもの」に変わります。

理由②:作業者が、すでにキャパオーバーだった

新しい運用は、今ある仕事を減らしてはくれません。私が配ったフローは、既存の業務の上に、そのまま「追加」で乗るものでした。

作業者の一日は、もともと本来業務で埋まっています。そこへ新しい入力や確認の手間が上乗せされる。増えた分を吸収する余白は、どこにもありませんでした。

人は忙しくなると、優先度の低いものから手を離します。作業者にとっての最優先は、当然ながら本来業務です。後から降ってきた新しい運用は、どうしても後回しになる。そして繁忙のピークで、真っ先に省かれます。

これは、作業者の意識が低いからではありません。キャパの限界という、構造の問題です。同じ状況に置かれれば、誰でもそうなります。設計した私が、その限界を計算に入れていなかっただけでした。

理由③:運用設計の時点で、手間を換算していなかった

①と②の根っこにあるのが、これです。設計者である私が、負荷を数えていなかった。だから「これなら回る」という誤った前提で、フローを配ってしまいました。

理由が重なって、実際に起きたこと

こうした理由が重なった結果、運用は目に見えて崩れていきました。

在庫管理では、決めたはずの入力項目が飛ばされ始めました。何個使ったか。どの製造過程で使ったか。その記録が抜けていく。すると、システム上の在庫数が、現物とずれていきました。数字が信用できなくなれば、その在庫データはもう使えません。

日々つけるはずの製造完了報告も、まとめ入力に変わりました。本来は毎日入力するものが、週末や月末に、思い出しながら一気に打ち込む形になったのです。「日々記録する」という前提そのものが、静かに崩れていきました。

そして、余白のないところに手間だけが増えれば、残るのは不満です。「なぜこんな作業を増やされるのか」という気持ちが、静かに溜まっていきました。

現場のやる気の問題ではありませんでした。設計の問題でした。この違いは、シリーズ第1回で書いた「現場が抵抗するから失敗する、という誤解」とも地続きです。

では、これから運用を設計する人は、どうすればいいか

ここまでは私の失敗の話です。ここからは、その反省から見えた「導入後に形骸化させないための落としどころ」を提案として書きます。実体験そのものではなく、「こう設計すれば違ったはずだ」という提案として読んでください。

提案①:全部やろうとせず、効果のある上位20%に絞る

いちばん大事な発想の転換がこれです。

理想の運用には、たくさんの「やったほうがいいこと」が詰まっています。でも、そのすべてが同じ価値を持つわけではありません。効果の大半は、一部の重要な項目から生まれます。

だから、まず「効果がある上位20%」を見極めて、そこだけを確実に回す。残りは、いったん手放す勇気を持つ。これは『エッセンシャル思考』(グレッグ・マキューン)にも通じる考え方です。

何を残し、何を手放すか。その判断軸は、以前書いた「やる・やらない線引きガイド」の発想がそのまま使えます。

提案②:運用設計の段階で、手間を「換算」する

設計するとき、各作業に「何分かかるか」を必ず数字にします。

そのうえで、一日あたり・一人あたりの総量を出す。現場の余力と並べてみる。ここで「明らかに乗り切らない」と分かれば、それは設計を見直すサインです。

手間の換算は、地味ですが最強のブレーキです。走り出す前に気づければ、形骸化の多くは防げます。

提案③:「なぜ必要か」を、作業者と最初に共有する

目的を共有した作業は、忙しくても最後まで残ります。

「この入力があるから、後工程の誰々さんが助かる」「このデータがないと、次のシステム移行で困る」。そういう理由を、フローと一緒に渡します。理由の伝わった作業は、省略の対象になりにくいのです。

この「現場の言葉で、なぜを共有する」動き方は、「現場と推進側の溝」の記事で書いた歩み寄りとも重なります。

提案④:どうしても外せないなら、手間を極限まで下げる

上位20%に絞っても、まだ現場の負荷が重い作業が残ることがあります。

その場合は、作業自体をなくせないか、手間を極限まで下げられないかを考えます。入力を選択式にする、転記を自動化する、といった工夫です。RPA(UiPathなど)で、人がやっていた繰り返し作業を肩代わりさせるのも一つの手です。

手間を下げきってから現場に渡す。この順番を守るだけで、定着のしやすさは大きく変わります。

正直な限界

ここまで提案を書きましたが、正直に言えば、私はこれを当時できませんでした。

あるべき姿と現状のキャパ。その間の「落としどころ」を見つける作業は、簡単ではありません。理想を削るのは、設計者にとって痛みを伴います。「本当はここまでやりたいのに」という気持ちとの折り合いが要ります。

そして、上位20%に絞っても、手間を下げても、運用が完璧に回り続ける保証はありません。人も業務も変わっていくからです。

それでも、と思います。あるべき姿だけを掲げて現場の不満をためるより、落としどころを探し続けるほうが、運用は生き残ります。導入は始まりであって、ゴールではないからです。

あわせて読みたい ― シリーズ「DX導入の落とし穴」

おわりに