工数削減型は普及しやすい、それでも定着しない場合がある
以前の記事で、内製DXには「管理精度型」と「工数削減型」があり、工数削減型は使う人自身にメリットがあるため自然に広まりやすいと書いた。この考えは変わっていない。作業が楽になるツールは、押し付けなくても使ってもらえることが多い。
しかし経験上、工数削減型であっても定着しないケースはある。機能は揃っている。操作も難しくない。使えば確かに楽になる。それでも現場に渡しても使われない。
この原因を「現場のITリテラシーが低い」「変化を嫌う体質」と片付けてしまうケースは多い。しかし自分の経験では、使われない原因のほとんどは、ツールの問題でも現場の問題でもなく、DX担当者と現場の間で十分に話す時間がなかったことにある。
当事者意識は説明会では生まれない
ツールを作り終えてから説明会を開く。操作方法を教えて、マニュアルを配る。「来月からこれを使ってください」と伝える。
このやり方で定着することもあるが、うまくいかないことのほうが多い。理由は単純で、現場の人にとってそのツールは「他人ごと」だからになる。自分が頼んだわけでもない、自分の困りごとから出発したわけでもないツールに対して、当事者意識を持てというほうが無理がある。
当事者意識は、操作説明では生まれない。作る前から話していて、自分の声が反映されていると感じたときに生まれる。
飲みに行く話ではない
コミュニケーションが大事だと言うと、「飲み会を増やせ」「雑談の機会を作れ」という話に聞こえるかもしれない。否定はしないが、ここで言いたいのはそういう話ではない。
必要なのは、業務時間の中に、使う人と話す時間が確保されていること。これだけになる。
「今の作業で一番面倒なのはどこですか」「この帳票はどういう流れで使っていますか」「こういう画面にしようと思っているんですが、どう思いますか」。こうした会話が、ツールを作り始める前と、作っている途中に、十分な回数行われているかどうか。
特別な仕掛けは何も要らない。話す。聞く。見せる。また話す。この繰り返しだけで、ツールの精度も定着率も大きく変わる。
DX担当者は「開発者」ではなく「通訳」
内製DX担当者の仕事は、コードを書くことだと思われがちになる。実際、経営者から見ても「ツールを作る人」として認識されていることが多い。
しかし現実には、DX担当者の仕事の中で最も時間をかけるべきなのは、現場の業務を理解するために人と話すことになる。
現場の人は自分の業務の困りごとを言語化できないことが多い。「なんとなく面倒」「昔からこうやっている」「Excelが重い気がする」。こうした曖昧な不満の裏に、本当の課題が隠れている。
DX担当者の仕事は、この曖昧な不満を聞き取って、システムで解決できる形に翻訳すること。つまり現場の言葉と技術の言葉の通訳になる。通訳するためには、まず現場の言葉を聞く時間が要る。
話す時間がなぜ確保されないか
これだけ単純なことが、実際にはできていない会社が多い。理由はいくつかある。
DX担当者が兼任で忙しい。 中小企業のDX担当者は情シスや総務との兼任であることが多い。日常の問い合わせ対応やPC管理に追われて、現場に出向いて話す時間がそもそも取れない。
「話している時間」が仕事に見えない。 コードを書いていれば成果物が見える。しかし現場で話を聞いている時間は、外から見ると仕事をしていないように見える。経営者がこの時間の価値を理解していないと、「早く作ってくれ」というプレッシャーになる。
現場も忙しい。 話を聞きに行きたくても、製造の現場は手が止められない。まとまった時間を取ってもらうのが難しい。
これらは構造的な問題であり、DX担当者の努力だけでは解決しにくい。以前の記事で、DXは1人では回らず経営者の協力が必要だと書いた。ここでも同じことが言える。経営者が「現場と話す時間」をDX担当者の仕事として認め、その時間を確保する環境を作る必要がある。
話すことで得られるもの
DX担当者が現場と話す時間を確保できると、ツールの定着率が上がるだけでなく、それ以上の効果が出てくる。
作るべきものが見える。 依頼ベースで動いていると「これをシステム化して」という要望に応えるだけになる。しかし現場と日常的に話していると、依頼にはならないが実は大きな非効率が見えてくる。以前の記事で「やめるべき業務を見つける」話を書いたが、やめるべき業務は依頼としては上がってこない。現場の日常を知っている人間だけが気づける。
信頼関係ができる。 新しいツールへの抵抗感は、変化への不安からくる。しかし「あの人が作るなら」「前にちゃんと話を聞いてくれた人だから」という信頼があると、ハードルは下がる。これは飲み会で得る信頼ではなく、仕事の中で「この人は自分たちの業務を理解している」と感じてもらえるかどうかの話になる。
手戻りが減る。 作り終えてから「思っていたのと違う」と言われるのが最も痛い。途中で見せて話していれば、方向修正は小さくて済む。開発効率の観点からも、話す時間への投資は回収できる。
技術力に加えて、もう一つ
内製DXの担当者に求められるスキルは何かと聞かれたら、プログラミングだと答える人が多いだろう。確かにコードが書けなければツールは作れないし、技術力は内製DXの土台になる。
このシリーズでは、内製エンジニアがAIを活用して社内ツールを高速開発するアプローチを勧めてきた。AIのおかげでコードを書く能力のハードルは大幅に下がっている。技術面の環境は確実に良くなっている。
ただし、技術力があればうまくいくかというと、それだけでは足りないことがある。現場に出向いて話を聞く時間を持っているかどうか。地味で泥臭い話だが、これが技術力と同じくらい成果に効いてくる。
AIがコードを書く力を補ってくれる時代だからこそ、AIには補えない部分——現場に行って、話を聞いて、業務を理解すること——の価値が相対的に上がっている。技術力を磨くことと、話す時間を確保すること。この両方が揃ったとき、内製DXは最も確実に成果を出せる。