「DXを進めよう。クラウドで引き継ぎをデジタル化すれば解決する」
業務改善部門の担当者は、そう言って打ち合わせの場に来た。
工場は24時間稼働、3交代シフト。
対面での引き継ぎができないため紙のノートを使っているが、
それだけでは足りず、休み中の社員に電話がかかってくる状態だという。
「デジタルやクラウドでなんとかできるはず」という言葉の奥に、
具体的な問題の分析はなかった。
こういう状況は、珍しくない。
業務改善部門やDX推進チームの中に、
特定のITシステムを入れれば自然と業務が改善されると信じて進める人は多い。
悪意はない。むしろ行動力がある。
ただ、問題が整理されていないままシステムを選ぶと、
費用と現場の負担だけが増えて業務はほとんど変わらない。
そこに違和感を覚えているなら、その感覚は正しい。
- DXで業務が変わらない最大の原因は、システムを入れる前に「問題の整理」が終わっていないこと
- 問題の整理に必要なのはIT知識や難しいフレームワークではなく、現場を観察して問題を書き出す行為だけ
- 問題が整理されると、必要なシステムの要件が自然に見えてくる——この順序を守るだけでDXの精度は大きく変わる
DXを進めようとした担当者が最初にやること
DXを推進しようとする担当者の多くが「まずシステムを探す」という行動をとる。しかしその前に「何の問題を解決したいか」という定義が抜けており、それが後の失敗を生む根本的な原因だ。
業務改善の担当者がDXを推進しようとするとき、多くの場合こういう流れで動く。
まず業務に課題を感じる。
「これは非効率だ、デジタルで解決できるはずだ」と判断する。
次にITツールやシステムを調べ始める。ベンダーに問い合わせる。
社内提案の材料を集める。
この動き方は自然だし、行動力があるともいえる。
ただ一つ、抜けているものがある。
「何の問題を解決したいか」が、まだ決まっていない。
蓄電池工場の業務改善担当者もそうだった。
最初の打ち合わせで僕に伝えてきたのは、
「DXで引き継ぎ問題を解決したい」「クラウドを使いたい」という方向感だけで、
具体的に引き継ぎの何が問題かは整理されていなかった。
本当はすぐにITサービスを紹介してもらい、
それを社内提案の材料にして業務改善を進めたかったのだと思う。
その動きは、決して珍しくない。
ただ、何の問題を解決したいかが決まっていない段階でシステムを探しても、
選んだシステムが課題に合っているかを判断できない。
それが「使われないシステム」と「現場の不満」を生む入口になる。
それでも変わらない——「デジタルにすれば解決する」が成り立たない理由
問題の原因が特定されていないままシステムを変えても業務は変わらない。「課題をデジタルの土台に乗せ替えただけ」になり、手段が変わるだけで構造は同じままだからだ。
僕はその担当者にこう聞いた。
「引き継ぎの具体的な内容は何ですか。なぜ紙のノートだけでは足りないんですか。電話では何を話しているんですか」
返ってきた答えはこうだった。
「紙のノートだけでは引き継ぎが不安で、なんとなくやっぱりしっかり話したんだと思います。みんなそうじゃないですか。メールだけでなくて直接会話したいこと、良くありますよね」
つまり、引き継ぎで何が足りないのか、電話で何を話しているのか、
担当者自身がまだ把握していなかった。
この状態でノートをクラウドに移行しても、どうなるか。
「デジタルのノートと電話で引き継ぐ」という構造は、何も変わらない。
僕はそのまま伝えた。
「それならこちらからの提案は新しい電話になります。ノートをデジタル化してクラウドにすることはできます。でもそれでは結局デジタルのノートと電話で引き継ぐという今の状況は何も変わらなくなります」
問題の原因が明らかになっていないままシステムを変えても、
「課題をデジタルの土台に乗せ替えただけ」で終わる。
製造業のDX現場でも、同じ構造の失敗は繰り返されている。
「情報入力の手間だけが増えて自分の仕事が楽になる実感がない」
「忙しいのに入力する余裕はない」
「今のやり方で困っていない」
これらはシステムを使わなくなった現場の声だ。どれも、問題が整理されていないままシステムが先行したときに起きる。システム導入が進まない会社に共通していた問題では、この「使われないシステム」が生まれる組織構造をさらに掘り下げている。
別の現場でも同じだった——「検索すれば解決する」が働かない理由
同じことは、技術の引き継ぎでも起きていた。あるプリンターメーカーで、「ベテランの知識をデジタルで検索できるようにすれば、若手への引き継ぎは解決する」という期待があった。
昔の製品は機械の構造が中心で、「この症状にはこの対処」という形で整理しやすかった。今は機械、電子、化学、ソフトウェアが絡み合い、不具合の原因がどこにあるのかは、キーワードで検索してもたどり着けない。しかも保守の対象は、数十年前の機種から最新の機種まで広がっている。
部長と何時間も話して見えてきたのは、1人の若手の頭に、ベテラン5人分の知識を入れようとしていたという構造だった。道具を入れても、この構造は変わらない。ずっと問題はあったが、それが何なのかが言葉になっていなかった。言葉になっていないものは、道具に載せても引き継げない。
このとき、道具を選ぶ前にやったのは次の整理だった。
- 内側の事情を表にする：技術の領域(機械・電子・化学や材料・ソフトウェア)と機種を縦横に並べ、どこに誰の知識があるかを書き込む
- 外側の事情を数字にする：採用と退職の見込み、問い合わせの件数と領域ごとの割合を並べる。「人手が足りない」ではなく、「3年後にこの領域の対応者が2人から0人になる」という形で捉える
- 手順ではなく理由を残す：「AならBする」だけでなく、「なぜAのときにBが効くのか」をベテランに語ってもらい、後から探せる形で残す
整理が済むと、「なんとなく危ない」という感覚が、「3年後に、この技術領域に具体的なリスクがある」という問題に変わった。道具の出番は、その後だった。属人化が生まれる背景は技術の属人化はなぜ起きる？に書いた。
DXの前にやること——問題の設計図を描く
DXの前にやることは「問題の設計図を描く」こと、つまり要件定義だ。製造業で設計図なしに材料を発注しないのと同じ論理で、解決すべき問題を先に明確にしてからシステムを選ぶ。
では、何から始めればいいのか。
答えはシンプルだ。製造の現場と同じ順序で考えればいい。
ものを作るとき、設計図なしに材料を発注する会社はない。
「何を作るか（要件）」を先に決め、それに合った材料と工程を選ぶ。
業務改善・DXも同じ構造だ。
「どの問題を、どのように解決するか」という設計図を先に描く。
これが要件定義と呼ばれる作業だが、ITの専門知識は必要ない。
「問題を整理して、必要な機能を決める」という行為そのものだ。
この順序を逆にすると——解決したい問題が何か分からないままシステムを選ぶ——
という状態になる。そこから先は、コストと混乱が増えていくだけだ。
蓄電池工場の担当者は、最初の打ち合わせで不服そうな顔をしていた。
すぐにサービスを紹介してもらえると思っていたところに、
「先に現場を調べてください」と返されたのだから、当然だと思う。
ただ、この手順を踏んだかどうかが、後の結果を大きく変える。
問題の設計図を描く3つのステップ
業務改善の設計図は「①現場を知る→②問題を書き出す→③要件を決める」の3ステップで描ける。IT知識も難しいフレームワークも不要で、「書き出す」という行為だけで足りる。
難しいフレームワークもIT知識も不要だ。
「書き出す」という行為だけで、業務改善の設計図は描ける。
ステップ1：現場の状況を知る
最初にやることは、現場を知ることだ。
現場を知る方法は2つある。
一つは現場の人にヒアリングすること。
もう一つは自分が現場に行って業務を観察することだ。
ヒアリングするとき、「どんな問題がありますか」という問いでは答えが抽象的になる。
「何を引き継いでいるか」「なぜ紙だけでは足りないか」「電話では何を話しているか」
という具体的な問いが必要だ。
現場が忙しくてヒアリングの時間が取れない場合は、観察するだけでもいい。
1日3時間現場を見れば、3日後には9時間分の生の様子がわかる。
言葉でなく行動から、問題が見えることがある。
蓄電池工場の場合、最初の打ち合わせでは引き継ぎの具体的な内容はわからなかった。
しかし2週間後、担当者が現場メンバーへのヒアリングを実施した結果、
役割ごとに引き継ぎ内容もノートが足りない理由もまったく異なることが判明した。
ステップ2：問題を書き出す
現場を知ったら、次は書き出す。
問題を「整理する」のではなく、「書き出す」から始める。
頭の中で整理しようとすると混乱する。まず全部を外に出すことが先だ。
書く形式は何でもいい。箇条書きでも付箋でもホワイトボードでも構わない。
「誰が・何の情報を・なぜ伝えられないか」を担当者ごとに列挙していく。
蓄電池工場のヒアリング結果を書き出すと、こうなった。
- 生産管理担当者：管理数値が複数あり、細かくノートには書ききれない
- 品質管理担当者：イラストが書けず、文字だけでは状況が伝えづらい
- 製造担当者：数週間にわたるスケジュール管理がノートでは難しい
- 班長：シフト希望の周知と提出状況の確認がノートだけでは難しい
- 課長：煩雑に書き込まれたノートから報告に必要な情報を拾えない
これが「担当者ごとに書き出された問題のリスト」だ。
この段階では、まだシステムを決めない。
書き出しただけで、問題の全体像がはっきり見えてくる。
ステップ3：課題を整理し、必要な要件を決める
問題のリストが揃ったら、それを解決するために「何ができるシステムが必要か」を整理する。
問いはシンプルだ。「この問題を解決するために、システムは何ができる必要があるか」。
蓄電池工場の場合、書き出した問題から要件が自然に見えてきた。
- 生産数の数値を管理できること
- 役割ごとの引き継ぎスペースがあること
- 写真や画像を貼り付けられること
- 周知とタスク管理ができること
- トピックをまとめて確認できること
これが要件定義の完成形だ。
「何ができるシステムが必要か」が具体的に決まっている状態で、
初めてベンダーに相談する段階に入れる。
ここまで来れば、複数のシステムを比較するときにも「自分たちの要件に合っているか」という基準で判断できる。
目的（要件）を先に決めることの重要性については、技術伝承の進め方5ステップ｜目的・範囲・承認・巻き込み・仕組み化でも詳しく触れている。参考にしてほしい。
まとめ——DXは「問題を整理する行為」から始まる
DXは魔法ではない。
問題が整理されていないままシステムを入れても、課題をデジタルの土台に乗せ替えただけで終わる。
費用は増え、現場の負担も増え、業務はほとんど変わらない。
逆に言えば、問題が整理されれば、IT知識がなくても「何が必要か」は自然に見えてくる。
蓄電池工場の担当者は、2週間という時間をかけて現場をヒアリングした。
その結果、役割ごとの課題が言語化され、必要なシステムの要件が揃った。
そこから先は、要件に合ったシステムを選ぶだけだった。
最初の一歩は、現場に行くことだけで良い。なお、「現場が紙を使い続ける本当の理由」を誰も把握していないまま議論が進む現場の実態は、オペレーターが紙を使う本当の理由を誰も知らなかったに詳しい。現場ヒアリングの重要性を改めて実感できるはずだ。