DXが進まない本当の理由
DXが進まない理由として、経営層からは「現場の意識が低い」、現場からは「上が現実を知らない」という説明が出てきます。どちらも部分的には当たっていますが、実際に手を動かし始めると、もっと具体的な壁に突き当たります。AIに渡せる形のデータが、社内に存在しないという壁です。
ここでいうデータは、売上表や在庫数のような数字だけではありません。「この取引先は締め日が特殊なので前倒しで処理する」「この機械は雨の日に調子が悪くなるので設定を変える」といった、日々の判断の中身も含みます。これらは多くの職場で、誰かの頭の中にしか存在していません。
ルールを整備しても、意識を高めても、この状態は変わりません。必要なのは規則ではなく記録です。この章では、その記録をどの粒度で、どう作るかを扱います。
必要なのは「AIが読み込める形」の記録
「うちは手順書がある」という会社は多いです。しかし実際に見てみると、次のような状態であることがよくあります。
- PDFで配布されているが、中身は画像として貼られたスキャンで、文字として読み取れない
- 3年前に作られ、以後の運用変更が反映されていない
- 「担当者の指示に従う」「適宜判断する」という記述で、実際の判断基準が書かれていない
- 個人のPCやメールの添付ファイルとして散在し、どれが最新かわからない
AIに渡せる形とは、単にデジタル化されているという意味ではありません。文字として読み取れて、最新版が一意に決まり、判断の基準まで書かれている状態です。この3条件のうちどれか一つでも欠けると、AIは使えるようになりません。
逆に言えば、この作業はAIのためだけの投資ではありません。人の引き継ぎにもそのまま効きます。DXの初期投資を正当化しにくいと感じるなら、「新人の教育期間が短くなる」という効果で説明したほうが通ることも多いです。
管理職レベルの情報では、まったく足りない
ここが最も誤解されている点です。業務を記録しようとするとき、多くの場合は管理職や業務リーダーに説明を求めます。しかしその説明は、必要な粒度に対してはるかに粗いのです。
管理職が語るのは「受注を確認して、在庫を引き当てて、出荷指示を出す」という流れです。これは業務のあらすじであって、業務そのものではありません。実際にその作業をしている人が持っている情報は、こういう水準です。
- 受注データのうち、この列が空欄のときは電話で確認する(空欄のまま流すと出荷ミスになる)
- この取引先だけ、システムの数量欄に箱数ではなく個数を入れる慣習になっている
- 15時を過ぎた分は翌日扱いになるが、この2社は例外で当日に通す
- 在庫が1個だけ残っているときは、表示上あっても取り置きの可能性があるので確認する
必要なのは、この一挙手一投足のレベルです。アルバイトが初日に迷うすべての場面が、記録されるべき対象です。管理職レベルの説明でAIを組み込もうとすると、例外処理が一切考慮されていない仕組みができ、現場が「使えない」と判断して終わります。
ヒアリングだけでは抜け漏れが出る
では現場の担当者に聞けばよいのかというと、それも十分ではありません。聞き取りだけでは構造的に漏れる情報があります。
- 本人が意識していない判断 ― 毎日やっていることは、手順として自覚されていません。「特に何も考えずにやっています」という答えの中に、実は複数の判断が入っています。
- 例外が思い出されない ― 月に1回起きる例外は、聞かれた場面では出てきません。ところが業務を止めるのはその例外です。
- 説明できない身体的な判断 ― 音や手触りで判断している作業は、言葉になりません。
これを埋める方法は、聞き取りに観察と記録を足すことです。担当者の隣に座って作業を見る、画面操作を録画する、1か月分の例外対応をその都度メモしてもらう。手間はかかりますが、ここを省略した記録は必ず穴だらけになります。
三月二日、朝凪精機のカスタマーサポート課長の村瀬は、経営企画部の瀬尾に窓口の仕事を説明していました。その途中で村瀬は「図面を見ないと答えられないのは、たまにあるくらいだけどね」と言いました。瀬尾はその場で一月の受付台帳を開き、設計や工場へ確認を回した印のある行を数えました。2,400件あまりのうち290件、12%、8件に1件です。村瀬自身が「そんなにあったの」と驚きました。毎日さばいている本人には、それが「たまに」に聞こえていたのです。聞き取りだけで仕組みを作っていたら、この1割強は手順から抜けたまま稼働し、想定外の問い合わせとして次々に現れていたはずです。「たまに」という言葉が出たら、その場で件数を数える約束をしておくだけでも、この種の失敗はかなり防げます。
この場面は物語之巻 第3話「PoCは成功した」に出てきます。
口伝と暗黙知を言葉にする
記録の中でいちばん価値が高く、いちばん失われやすいのが「ちょっとしたコツ」です。
これらは業務効率の差を生んでいるにもかかわらず、手順書には載りません。理由は単純で、正式な手順ではないからです。しかし現場では確実に使われており、その人がいなくなると業務が回らなくなる原因もここにあります。
言語化のコツは、失敗の記録から入ることです。「どうすればうまくいくか」を聞くと出てきませんが、「過去にどんな失敗があったか」「新人がよくやる間違いは何か」を聞くと具体的に出てきます。失敗の裏側には必ず、それを避けるための判断があります。
データが多い業務ほど、実はやりやすい
ここに一つ逆説があります。一見大変そうな大量業務のほうが、DXはやりやすいのです。
1日100件の応対記録が1年分あれば36,500件です。この規模があれば、頻出パターンが統計的に見えます。例外がどれくらいの割合で起きるかも数えられます。効果測定も、処理時間の平均で比較できます。
反対に、少人数のチームが担っている専門性の高い業務は、記録の量が足りません。月に数件しか発生しない判断は、パターンとして抽出できません。しかもその業務は属人化しているため、記録を作る作業自体を、その本人にしか頼めません。
「簡単な業務から始めましょう」という進め方は、しばしばこの逆説を踏みます。作業内容が単純に見える業務は、たいてい少人数で回している属人的な業務です。着手すべきは件数が多い業務で、作業の単純さではありません。件数を先に数えてから対象を決めてください。なお「スモールスタート」が検証の先送りに使われる型は裏之巻 第5章「PoC止まりの罠」で扱います。
その工程は、そもそも必要か
データ化に着手する直前に、もう一段手前の問いが必要です。効果が出ないAI導入の最頻の形は、精度不足ではなくやらなくてよかった工程に丁寧にAIを当ててしまうことです。
次の4つは、消せる可能性が高い工程です。
- 転記 ― 同じ値を2か所以上に人が入力している。書き出しの設定を1つ足せば済むことが多く、AIは不要です。
- 確認のための確認 ― 前の工程で確認済みの内容を、次の工程でもう一度見ている。
- 待ちの発生 ― 承認を待つ時間が、作業そのものの時間より長い。
- 使われない出力 ― 作っている資料の宛先が言えない。止めてみて誰からも指摘が来なければ、廃止できます。
順序は消す → まとめる → 順番を変える → それでも残る工程にAIを当てるです。この順序を守ると、AIに任せる範囲が小さくなり、精度の要件も費用も下がります。
データ化を進める実践ステップ
順序を間違えると手戻りが大きい領域なので、進め方を型として置いておきます。
- 対象業務を件数で選ぶ ― 月間の発生件数を数え、多い順に並べます。ここで作業の難易度は考えません。
- 現状の記録の在り処を棚卸しする ― どこに何があり、最新版がどれかを一覧にします。この段階で「正の文書」を1つに決めます。
- 観察で埋める ― 担当者の作業を1日通して見て、手順書に無い判断をすべて書き出します。
- 例外を数える ― 1か月、例外が起きた回数と内容を記録します。割合が見えると、自動化の範囲を決められます。
- 小さく作って現場で回す ― 全部を作らず、頻出パターンだけを対象に動かします。例外は人が処理する前提で始めます。
- 記録を更新する仕組みを決める ― 運用が変わったときに誰が記録を直すのかを決めます。ここを決めないと、半年で元の状態に戻ります。
現場を巻き込むために
最後に、作業の性質上避けられない問題に触れます。業務を細かく記録する作業は、現場から見ると監視されているように感じられます。「効率が悪いところを探されている」「自動化されて仕事がなくなる」という受け取り方は、自然な反応です。
ここで効くのは、目的と使い道を先に具体的に示すことです。「引き継ぎの負担を減らす」「休みを取りやすくする」「問い合わせ対応を減らす」といった、記録した本人に返ってくる効果を明示します。あわせて、記録の目的が個人の評価ではないことを、運用ルールとして書いておきます。
この構図は、経営層と現場の認識のずれと同じ根を持っています。第6章で、逆側から扱います。