新たな負荷を生まない業務改善を考える

Chapter 1　よくできたDXほど、少し怖い

とある建設DXピッチに参加しました。「脱・属人化」「現場の「負」を仕組みで変える」。登壇企業各社とも現場の声を集め、非常によく研究されていると感じました。

• 情報を一元化する。
• 見積から請求、原価管理までつなぐ。
• 写真や進捗、指示を一か所に集める。
• AIで整理し、判断を支援する。

どれも筋が通っているし、課題の言語化もしっかりしている。実際、「これはいい」と思うものも多かった。

それでも、どこかに少し違和感が残りました。それは、機能が足りないからではない。

むしろ逆で、「機能がよくできているからこそ、その先に何が起きるのか」が気になった。

• 便利になったあと、誰が入力するのか。
• 誰が確認するのか。
• 誰に通知が集まるのか。
• 誰が判断するのか。

改善によって、別の場所に新しい負荷が生まれていないか。

Chapter 2　ツールは便利さと一緒に「新しい仕事」を連れてくる

新しいシステムを入れると、確かに仕事は減ります。ただし、同時に新しい仕事も生まれることが多い。

たとえば、

• 入力ルールを覚える。
• 通知を確認する。
• 情報を分類する。
• 新しい画面を見る。
• データを整える。
• 例外時の処理を決める。
• 使っていない人をフォローする。

そう、今までなかった管理作業が発生することもあります。そして、その新しい仕事は往々にして、特定の誰かに集まる。

それは現場監督かもしれない。事務担当かもしれない。ITに少し詳しい人かもしれない。「とりあえずあの人に聞けば大体」という人かもしれない。

結果として、「会社全体では効率化したように見えて、ある人だけが以前より忙しくなる」。

この状態では、長くは続かない。NDLが「定着」を重視する理由はここにあります。

Chapter 3　私たちが見るのは、「何が減ったか」だけではない

一般的なDXの成果は、以下のような項目で効果を測定し、評価します。

• 作業時間が何時間減ったか。
• 転記回数が減ったか。
• 処理スピードが上がったか。
• 数字がリアルタイムで見えるようになったか。

もちろん大事です。でもNDLは、それだけでは足りないと考えています。私たちはここを見ます。

• 誰の負荷が減ったか。
• 誰の負荷が増えたか。
• 新しい認知負荷が生まれていないか。
• 新しい管理負荷が生まれていないか。

たとえば、現場の入力は簡単になったが、管理者の確認項目が倍になった。紙はなくなったが、チャットとシステムとメールの三つを見るようになった。情報は一元化されたが、情報量が多すぎて探せなくなった。

こうしたことは普通に起こり得ます。だから、NDLの設計思想の一つに、「新たな負荷を生まない」を置く。

完全に負荷をゼロにはできない。でも、少なくとも、負荷を見えないところへ移すだけの改善はしない。

Chapter 4　NDLがやること、やらないこと

ここで、「NDLの境界線」をはっきり書いておきます。私たちがやるのは、

• 現場を見る。
• 今の業務がなぜその形になったかを聞く。
• 誰がどこで判断しているかを見る。
• 例外処理を見る。
• 負荷の偏りを見る。
• 現場の知恵を残す。
• 必要なら小さく試す。
• そして、仕組みに変えていいものと、人に残すべきものを分ける。

一方で、やらないこともあります。

• AIありきで考える。
• SaaSありきで考える。
• 属人化をすべて悪と決めつける。
• ベテランの知恵を何でもAIにコピーしようとする。
• 新しい入力や管理作業を当然のコストとして押しつける。
• 「導入した」で終わらせる。

特に、ナレッジを作る過程においては、「ベテランの勘をAIへコピーすること」が目的ではない。

私たちがやりたいのは、その判断をそのまま模倣することではなく、その判断が何によって生まれているのかを見極めることです。

再現可能なのか。本当に仕組みに渡すべきなのか。

そこを考えることです。

Chapter 5　なぜ、そこまで前に戻るのか

理由はシンプルです。

整理されていない業務に良いツールを入れても、整理されていないまま速くなるからです。

場合によっては、混乱が加速します。

• 入力項目が増える。
• 通知が増える。
• 管理者の確認が増える。
• 現場の反発が増える。

その結果、「せっかく導入したのに使われない」となる。

だからNDLは、導入前に一度立ち止まって考えます。

• 何に困っているのか。
• 誰が困っているのか。
• なぜ今のやり方になったのか。
• 何は残すべきなのか。
• 何は変えていいのか。
• そもそもAIやシステムが必要なのか。

ここを整理することを、私たちは「前捌き」と呼んでいます。

ただ最近、前捌きという言葉でも、まだ少し足りないのかもしれないと思い始めました。

Chapter 6　「上流」の、さらに上にあるもの

DXやシステム開発では、「上流」という言葉が使われます。

要件整理、業務設計、システム設計、PoC設計。

これらは確かに実装やデプロイの上流工程です。ただし、それらはすでに「何かを作る」「何かを導入する」流れの中にある。

私たちが見ているのは、そのさらに前です。

• なぜその仕事が今の形になったのか。
• なぜその会社ではそのExcelが残っているのか。
• なぜその人に判断が集まっているのか。
• なぜその作業をなくせないのか。

そして、そもそも何を変えるべきなのか。

そう考えると、私たちが見ている場所は、「上流」ではないのかもしれません。

流れが始まる前。その川が生まれる場所。

つまり、「水源」なのかもしれません。

そこで水の向きを間違えなければ、その後のDXやAI導入は、ずっと自然に流れやすくなる。逆に、水源が濁ったままなら、下流でどれだけ立派な仕組みを作っても、どこかで詰まる。

NDLがやりたいのは、システムを入れることそのものではなく、現場が無理なく流れ続ける状態をつくること。

そんなことを、今日の建設DXピッチを見ながら改めて考えました。

まとめ

• DXやAI導入で機能や効率が向上しても、その裏で特定の誰かの負荷が増えていることがある
• 便利になった分、入力ルールの習得や通知確認、例外処理といった「新しい仕事」が生まれ、特定の人に集中しやすい
• NDLは「何が減ったか」だけでなく、「誰の負荷が増えたか」「新しい認知・管理負荷が生まれていないか」を見て評価する
• ベテランの勘をそのままAIに移植するのではなく、その判断がどこから生まれているのかを見極めることを重視する
• 整理されていない業務にツールを入れても、整理されていないまま速くなるだけで、混乱が加速することがある
• NDLが向き合っているのは「上流」よりもさらに手前、業務や判断がその形になった理由という「水源」である

編集後記

この「水源」という言葉、実はこの記事を書く前に、別の場所で先に口から出ていました。

先日、東京商工会議所の交流会で、あるTEC企業さんと名刺交換をした際のことです。業務改善支援の話を少しすると、先方から「上流ですね」と言われました。

とっさに、「いや、上流よりもさらに上ですね。うーん、言わば水源です。」と返したところ、妙に納得していただけました。

自分でも気に入ってしまい、そのまま記事に持ってきました。

話せば、言葉は磨かれる。

---

関連するNDL語彙：[前捌きとは] [認知負荷とは] [ニューロデザインとは] [優しいDXとは]