ツールを入れれば変わる。その発想が、DXを空振りにする。

「クラウドツールを入れたのに、Aさんが休むと業務が止まる。」この問題の犯人はツールではない。ツールを入れる前から存在していた「誰かの頭の中にある手順」がそのまま残っているだけだ。DXが定着しない本当の原因は、ツールの性能でも社員のITリテラシーでもなく、業務が言語化されていないことにある。

POINT 01“わかる人がいる”という状態が、なぜ危ういのか

中小企業では、長く働いているベテラン社員が「なんとなく」業務を回していることが多い。見積もりの出し方、請求書の確認フロー、得意先ごとの対応の微妙な差。全部が「Aさんに聞けば大丈夫」で動いている。

これは一見、問題なく見える。Aさんがいる間は業務が止まらないからだ。

だが、「わかる人がいること」と「誰でもできる仕組みがあること」は、まったく別のことだ。Aさんが急に休む、辞める、繁忙期に他の仕事が重なる。そのとき初めて気づく。「手順がどこにも書いていない」と。

属人業務の怖さは、崩れるまで崩れているとわからないところにある。

そして多くの会社が、この状態を打開しようとITツールを導入する。ここで順番を間違えると、二度手間になる。

経営学ではこの状態を「暗黙知」と呼ぶ。一橋大学名誉教授の野中郁次郎氏と竹内弘高氏は、共著『知識創造企業』の中で、個人の頭の中にある暗黙知を、誰もが理解できる言葉や図に変換する「表出化」というプロセスを、組織の知識創造の出発点として位置づけている。Aさんの頭の中にある手順は、この表出化がまだ済んでいない暗黙知そのものだ。Aさん本人には「当たり前」の判断でも、それが言葉になっていない限り、組織にとっては再現不可能な情報のまま止まり続ける。

しかも暗黙知は、本人が「特別なことをしている」という自覚を持ちにくい。だからこそ、周囲はもちろん本人でさえ、その業務がどれほど属人化しているかに気づかないまま、日々の業務が回ってしまう。組織として見れば、これは一人の社員の頭の中に、事業継続のリスクをまるごと預けている状態に等しい。

POINT 02ツールに乗せる「手順」がなければ、ツールは箱で終わる

ITツールはあくまで「決まった手順を効率よく回す入れ物」だ。手順そのものをつくる道具ではない。

たとえばクラウドの受注管理ツールを入れたとする。だが「受注したらどの情報を登録して、いつ誰に共有して、次のステップに移るのは何を確認してから」という手順が言語化されていなければ、ツールの使い方は人によってバラバラになる。入力項目が違う、更新のタイミングが違う。結果、ツールのデータが信用できなくなり、「結局Aさんに直接確認する」という状態に戻る。

これが「DXツールを入れたのに使われなくなる」パターンの実態だ。

ツールが悪いのではなく、ツールに乗せるべき手順の言語化が、先にできていないことが問題だ。

属人業務をITで解消しようとすると、結局「ツールを使いこなせる人」という新たな属人が生まれるだけになる。根本の構造は何も変わらない。

ここで厄介なのは、ツール自体は正常に動いているように見えることだ。ログイン率も入力件数も、表面上の数字は悪くない。だが中身を見ると、必須項目が空欄のまま登録されていたり、担当者ごとに違う書き方で入力されていたりする。「使われている」ことと「機能している」ことは、似ているようでまったく違う。

結果として、ツールの月額費用と、Aさんに確認する時間の両方を払い続けることになる。これが、ITツール導入において最も見落とされがちなコストだ。導入前の見積もりには、この二重コストはまず載っていない。

POINT 03言語化の手順は3段階で考える

では、どこから手をつければいいか。業務の言語化は、次の3段階で進めると整理しやすい。

1. 棚卸し：どの業務が属人化しているかを洗い出す。「これ、自分しか知らないな」という業務を全員に書き出してもらう。付箋でもスプレッドシートでも構わない。まず全体像を見える化することが目的だ。
2. 手順を言葉にする：棚卸しで出てきた業務を、「誰がやっても同じ結果になる手順書」として書き起こす。感覚やコツは「こういうときはこうする」と条件で書く。「だいたいこのくらい」という曖昧な表現は残さない。
3. 例外ルールを明文化する：「イレギュラーが起きたときにどうするか」まで書いて初めて手順書は完成する。例外対応は最も属人化しやすい部分だから、必ずここまで踏み込む。

この3段階が終わったとき、初めてITツールを選ぶ段階に入れる。手順書と照らして「どこを自動化できるか」「どこを管理画面で見えるようにするか」を考えると、ツール選びの精度が格段に上がる。

この順番には理由がある。棚卸しを飛ばしていきなり手順書を書き始めると、そもそも「どの業務を書くべきか」という対象の選定自体に漏れが出る。逆に、例外ルールを後回しにすると、手順書は「うまくいくときだけ」を前提にした机上の空論になり、結局は現場で使われなくなる。3つの段階を順番通りに踏むことが、実際に機能する手順書をつくる最短ルートだ。

また、棚卸しと手順の言語化は、本人一人に任せきりにしないほうがいい。周囲がヒアリングしながら書き起こすことで、本人が無意識に前提としている判断まで拾い上げやすくなる。

まとめ：ツールは仕組みの最後に乗る

DXを進めたい中小企業の経営者・管理部門に伝えたいのは一つだけだ。

ツールを入れる前に、「その業務を誰でも同じ手順で回せるか」を確認してほしい。できていないなら、言語化が先だ。ツールはその後に乗せる。

定着するDXとは、ツールを入れることではなく、「誰でも同じ結果を出せる仕組みをつくること」だ。ツールはその仕組みをより速く・正確に回すための道具に過ぎない。道具の前に仕組みがある。この順番を守るだけで、DXの空振りはなくなる。

土台を飛ばして、ツールという道具だけを先に選んでしまうと、どれだけ高機能なシステムを導入しても、結局は「Aさんに聞く」という属人業務に逆戻りする。遠回りに見えても、まず言葉にすることが、DXを本当の意味で定着させる最短の道だ。

ツール選定に時間をかける前に、まず一つの業務だけでいいので、手順を書き出してみてほしい。そこから見えてくる曖昧さこそが、DXの本当の出発点になる。