現場DXが進まない理由は、ツールでも現場でもなく「設計」にある

「システムは入れた。でも、現場が使わない。」

これは、tugiloが現場でいちばん多く聞く相談です。

高いお金をかけた。研修もした。それでも、数週間で元に戻る。日報アプリは開かれなくなり、管理表はまた紙に戻る。

このとき、原因を「現場のやる気」や「ITリテラシー」に置くと、話はそこで止まります。そして、次に買うのはたいてい、もっと高機能な別のツールです。

現場DXが進まない理由は、ツールでも現場でもありません。多くの場合、原因は「設計」にあります。

「現場DXが進まない」とき、現場で実際に起きていること

まず、責任の話をする前に、現場で何が起きているかを見ます。

tugiloが繰り返し見てきたのは、こういう光景です。

• 入力する項目が、現場の作業の順番と合っていない。
• 一つ入力するのに、画面を三つ移動しないといけない。
• 「これは誰が入れるのか」が決まっていない項目が残っている。
• 入れても、そのデータが自分の仕事に返ってこない。

どれも、小さな不便です。けれど、小さな不便は現場のリズムを少しずつ削ります。そして、いちばん速くて確実な方法——紙とExcel——に、現場は静かに戻っていきます。

現場が紙に戻るのは、怠けているからではありません。紙のほうが、いまの設計より速いからです。

ここが出発点です。現象は「使わない」ですが、理由は「使えない設計になっている」ことのほうが多い。

よくある説明「現場のITリテラシーが低い」を、いちど疑う

DXが止まると、いちばん出てきやすい説明が「現場のITリテラシーが低い」です。

この説明は、半分あたっていて、半分あぶないものです。

たしかに、慣れの差はあります。けれど、この説明には落とし穴があります。原因を人の能力に置いた瞬間、設計を見直す手が止まるからです。

考えてみてください。同じ人たちが、スマホでは複雑なアプリを普通に使っています。乗り換え案内も、キャッシュレス決済も、写真の共有も。

つまり、問題は「デジタルが使えない」ことではありません。「その業務システムが、現場の使い方に合っていない」ことです。

リテラシーのせいにすると、次の一手は「もっと研修する」になります。設計のせいだと気づくと、次の一手は「使う人と一緒に作り直す」になります。打ち手が変わります。

本当の理由は、使う人が「設計」に入っていないこと

では、なぜ現場に合わない設計になるのか。

多くの場合、DXの計画が、経営層や本社、外部ベンダーだけで進んでいるからです。毎日そのシステムを使う現場の作業者や班長が、設計の段階にいません。

使う人が設計に関わっていないシステムは、ほぼ確実に定着しません。これは、能力の問題ではなく、順番の問題です。作る前に何を決めるかについては、作る前に決めることで、システムの8割は決まるでも扱っています。

具体的には、次のどれかが抜けています。

• 誰の、どの判断を楽にするのかが決まっていない。
• その判断に、本当に必要な項目だけに絞られていない。
• 入力した人に、メリットが返る導線がない。
• 例外が起きたとき、誰が決めるのかが設計に含まれていない。

システムは、業務の「作業」だけを写し取りがちです。けれど現場が本当に困っているのは、作業ではなく「判断」の部分です。どれを優先するか。誰に確認するか。例外をどう扱うか。ここが設計から抜けると、システムは現場の隣にいるのに、仕事を助けてくれません。

人を責めると、設計が見えなくなる

ここで、tugiloがいちばん大事にしている考え方に触れます。

人を責めず、設計に期待する。

「現場が使わない」と言うとき、私たちは無意識に、使わない人を責めています。責める相手は、現場のこともあれば、ベンダーのことも、選んだ自分のこともあります。

けれど、誰かを責めると、原因がその人の中にあることになります。すると、設計に手を入れる理由がなくなります。犯人が決まった瞬間に、改善が終わってしまうのです。

責めるのをやめると、見え方が変わります。「なぜこの人は、この設計だと使えないのか」と問える。すると、直せる場所が見えてきます。項目を減らす。入力の順番を変える。判断の持ち主を決める。どれも、人ではなく設計への打ち手です。

これは甘さではありません。責任を、直せる場所に置き直すということです。人は変えにくいですが、設計は変えられます。だから、設計に期待するほうが、現場は前に進みます。

誤解しないでほしいのは、「誰も悪くない」と言っているのではない、ということです。悪者探しをやめるのと、原因から目をそらすのは、まったく別のことです。人を責めないのは、優しさのためではありません。責めても何も直らないからこそ、直せる場所である設計に、力を集める——それが、現場をいちばん速く前に進める方法だからです。

現場は、設計が自分たちの味方だと分かると、驚くほど協力してくれます。逆に、責められていると感じると、どんなに良いツールでも、心を閉じます。DXが定着するかどうかは、機能の差ではなく、この空気の差で決まることが多いのです。

最初に決めるのは、ツールではなく「誰のどの判断を、どう楽にするか」

では、何から始めればいいのか。

答えは、ツール選びの前にあります。最初に決めるのは、「現場の誰の、どの判断を、どう楽にするか」です。

順番を逆にしないでください。ツールを先に決めると、そのツールに現場を合わせることになります。判断を先に決めると、その判断を助けるツールを選べます。

たとえば、次のように具体化します。

• 対象：どの現場の、誰か（例：施工現場の班長）。
• 判断：その人が毎日迷っていること（例：今日どの段取りを優先するか）。
• 楽にする形：その判断に必要な情報だけを、その人の作業の流れの中に置く。

ここまで決まって、はじめてツールの話になります。ツールは、この判断を助けられるかどうかで選びます。機能の多さでは選びません。

「現場が悪いのか、設計が悪いのか」を切り分ける5つのチェック

責めるのをやめても、どこを直せばいいか分からない、という声があります。そこで、現場と設計を切り分けるための問いを用意します。次の5つのうち、一つでも「はい」があれば、それは人ではなく設計の問題です。

1. 入力の順番は、現場の作業の順番と同じか。 違うなら、現場は毎回、頭の中で並べ替えている。
2. 一つの記録に、画面移動は何回必要か。 三回を超えると、忙しい日は飛ばされる。
3. 「この項目は誰が入れるか」が全項目で決まっているか。 空いていると、結局、誰も入れない。
4. 入力した人に、その日のうちに何か返ってくるか。 返らない入力は、作業ではなく我慢になる。
5. 例外が起きたとき、誰が決めるかが決まっているか。 決まっていないと、現場は判断を止め、システムも止まる。

このチェックは、能力を測るものではありません。設計に、直せる穴が残っていないかを測るものです。穴が見つかったら、それは悪い知らせではなく、直せる場所が見つかったという良い知らせです。

効率化したのに、誰かがしわ寄せを受けていないか

もう一つ、見落とされやすい原因があります。効率化そのものが、別の場所に負荷を移していることです。

たとえば、現場の入力を減らすために、集計を事務が手作業で肩代わりしている。あるいは、一人の「詳しい人」が、みんなの分の入力を陰で直している。全体では速くなったように見えて、どこかで誰かが静かに無理をしている。この負荷の移動は、AIツールを増やすほど現場が疲れる理由でも起きます。

効率化を、無条件に良いものとして扱わないでください。効率化には、必ず「楽になった人」と「負荷が移った人」がいます。 その移り先を見ないまま進めると、しわ寄せを受けた人から、仕組みは静かに崩れます。

だから、設計のときにこう問います。「この効率化で、誰が楽になり、誰に負荷が移るのか」。移り先が特定の一人なら、そこは設計をやり直すサインです。負荷を消したのではなく、隠しただけかもしれません。

現場DXを止めないための、最初の3つの問い

最後に、現場に持ち帰れる形にまとめます。DXを始める前、あるいは止まったときに、次の3つを問い直してください。

1. このシステムは、現場の「誰の、どの判断」を楽にするのか。 作業ではなく判断で答えられるか。
2. 使う人は、設計に入っているか。 入っていないなら、まずそこから。
3. 入れた人に、メリットは返るか。 返らない入力は、必ず止まる。

この3つに答えられれば、ツールが何であっても、導入は止まりにくくなります。答えられないままツールを増やしても、現場はまた、静かに紙へ戻ります。

現場DXが進まない理由は、ツールでも現場でもありません。設計です。そして設計は、人を責めない人にしか、直せません。