「ツールを導入して、なんとなくうまくいっている気がする」。この「なんとなく」で止まっているDXは多い。だが本当に定着したかどうかは、感覚ではなく数字で確認して初めて言える。

POINT 01なぜ「振り返り」が抜け落ちやすいのか

導入時は目標や期待値を掲げていても、運用が始まると日々の業務に追われ、振り返りの機会を持たないまま時間が過ぎていくことが多い。振り返らないまま放置すると、実は一部の人しか使っていなかった、旧来のやり方に戻ってしまっていた、ということに気づくのが遅れる。

実際、DXの成果は楽観できるものではない。ボストン・コンサルティング・グループ(BCG)が世界の企業を対象に行った調査では、デジタルトランスフォーメーションに取り組む企業のうち、期待した成果を得られたのは3割程度にとどまり、残りの7割は道半ばで失速していると報告されている。ツールを入れた”その先”を確認する仕組みがなければ、この数字に自社が加わってもおかしくない。

中小企業の場合、大企業のような専任のDX推進チームを置けないことも多く、導入後のフォローがどうしても手薄になりがちだ。だからこそ、簡単な数字を定期的に見るだけでも、この差を埋める効果がある。

定着の確認を数字で行う習慣があれば、うまくいっていない部分に早く気づき、手を打てる。ここまでのシリーズで見てきた「仕組みづくり」「言語化」「ツール選定」「使いたくなる仕組み」は、すべてこの最終確認のためにある。

振り返りが抜け落ちやすいのには理由がある。導入プロジェクトの多くは「ツールを入れること」自体がゴールとして設定され、稼働した時点でプロジェクトは”完了”扱いになりやすい。その後の数字を追う役割は誰の担当業務にも明確に組み込まれておらず、宙に浮いてしまう。だからこそ、振り返りのタイミングと担当者を、導入計画の段階であらかじめ決めておくことが欠かせない。

実際、ある製造業の現場では、日報作成ツールを導入して半年後に確認したところ、実際に毎日入力していたのは対象者の3割程度で、残りは相変わらず紙のメモや口頭で報告していたことが後になって判明した。半年間、誰も数字で確認していなかったために、この状態に気づくのが大きく遅れてしまった。

もし四半期に一度でも数字を確認していれば、入力率の低下にもっと早い段階で気づき、現場へのフォローや運用の見直しに動けたはずだ。振り返りの有無は、問題の”発見スピード”を大きく左右する。

POINT 02定着後に確認すべき3つの指標

指標は欲張って増やしすぎない方がいい。多すぎる指標は結局誰も見なくなる。ここでは、定着の実態を過不足なく映し出す3つに絞った。

では、具体的に何を数字で見ればいいのか。押さえるべき指標は次の3つだ。

1. 利用率：対象者のうち、実際に継続して使っているのは何割か。一部の人だけが使っている状態は、まだ定着とは言えない
2. 作業時間の変化：導入前と比べて、対象の業務にかかる時間はどう変わったか
3. 旧来のやり方への”揺り戻し”の有無：忙しくなったときに、以前のやり方に戻ってしまっていないか

例えば、対象者30人に配布したツールのうち、実際に継続して使っているのが8人だけだったとする。利用率はわずか27%に過ぎず、この状態を「定着した」と呼ぶのは難しい。逆に、9割近くが使い続けていれば、多少の使い勝手の不満があっても定着は進んでいると判断できる。

それぞれの指標は、大掛かりな仕組みがなくても確認できる。利用率はシステムのログイン履歴や操作ログから機械的に追えることが多い。作業時間の変化は、対象業務の前後で簡単なタイムログを取るだけで把握できる。揺り戻しの有無は、繁忙期に現場を実際に見て回るか、担当者に一言確認するだけでも十分な兆候がつかめる。

これらを定期的に確認する仕組み自体も、DXの一部だ。導入して終わりにせず、振り返る仕組みまで含めて設計しておく。

3つの指標の中でも、特に見落とされやすいのが”揺り戻し”だ。行動経済学ではこれに近い現象を現状維持バイアスと呼ぶ。経済学者ウィリアム・サミュエルソンとリチャード・ゼックハウザーが1988年に発表した研究では、人は変化によって得られる利益よりも、変化に伴う損失やリスクを重く感じ取り、結果として慣れ親しんだ状態にとどまろうとする傾向があることが示されている。例えば、勤怠管理をシステム化しても、繁忙期になると紙のタイムカードに手が伸びてしまう、というのはこの典型例だ。新しいやり方にまだ慣れていない段階では、多少の手間でも古いやり方の方が心理的に楽に感じられる。だからこそ揺り戻しの兆候は、導入直後だけでなく、繁忙期を一度越えたタイミングで改めて確認する価値がある。

まとめ：DXは、振り返って初めて完成する

DXの取り組みは、ツールを入れた瞬間ではなく、定着を確認できた時点で初めて成功したと言える。感覚で「うまくいっている」と判断せず、利用率や作業時間の変化を数字で確認する習慣を持ってほしい。

このシリーズを通して見てきたように、DXの定着は、仕組みづくりから始まり、言語化、ツール選定、現場目線の設計、そして振り返りまでの一連の流れで成り立っている。どこか一つを飛ばしても、定着は遠のいてしまう。

また、振り返りは一度きりで終わらせるべきものではない。四半期に一度など、あらかじめ頻度を決めて数字を確認し続けることで、DXは”入れて終わり”の単発施策から、継続的に成果を生み出す仕組みへと変わっていく。

担当者を決め、頻度を決め、指標を絞る。この3つさえ押さえておけば、DXの振り返りは大きな負担にはならない。

今回で「定着するDXロードマップ」シリーズは一区切りとなる。次にDXツールの導入を検討する際は、ここまでの流れを一つのチェックリストとして使ってほしい。

ツールを導入したのに、しばらくすると誰も使わなくなっている。よくある話だ。原因を「操作が難しいから」と考えがちだが、本当の原因は、現場にとって「使う理由」が明確になっていないことにある。

POINT 01なぜ「使いなさい」では定着しないのか

経営者や管理部門が「これからはこのツールを使ってください」と伝えるだけでは、現場は動かない。現場からすると、新しいツールを覚えることは、それ自体が負担であり、覚えた先に何のメリットがあるのかがわからなければ、わざわざ苦労して覚える理由がない。

定着している現場に共通しているのは、「使ったほうが自分にとって楽になる」という実感を、現場自身が持っていることだ。管理側の都合ではなく、現場側の得になる形で設計されているかどうかが、定着を分ける。

厄介なのは、この抵抗が表立って現れるとは限らないことだ。面と向かって反対はしなくても、入力を後回しにしたり、必要最低限の項目しか埋めなかったりと、現場が水面下でブレーキをかけるケースは珍しくない。管理側からは「一応使われている」ように見えるため、問題が発覚するまでに時間がかかる。

実はこの現象には心理学的な裏付けがある。心理学者ジャック・ブレームが1966年に提唱した心理的リアクタンス理論によれば、人は自分で選べる余地を制限されたと感じると、その行動自体に反対する理由がなくても、指示そのものに反発したくなる心理が働くという。「使いなさい」という一方的な号令は、現場から選ぶ自由を奪う指示として受け取られやすく、内容の是非とは別に反発や消極的な抵抗を生みやすい。この理論が示すのは、抵抗の原因が「ツールの中身」ではなく「伝え方」にある場合が多いということだ。同じ機能のツールでも、押しつけられたと感じるか、自分で選んだと感じるかで、現場の受け止め方は大きく変わる。

実際、ある卸売業の物流拠点では、在庫管理システムを導入した際に経営陣が使用を義務付けたにもかかわらず、現場では紙の台帳との併用が半年以上続いた。理由を尋ねると、「入力しても自分たちの作業は何も楽にならない」という声が大半だったという。

一方、別のある印刷会社では、同じ種類のシステムを導入する前に、現場のリーダーに先に触ってもらい、「どこが便利になるか」を自分の言葉で他のメンバーに説明してもらう機会を作った。押しつけではなく現場発の情報として伝わったことで、目立った反発は起きず、数か月のうちに入力が習慣として根づいたという。

2つの事例の違いは、ツールの性能でも研修の量でもない。「なぜ使うのか」を現場自身の言葉で説明できる状態を作れたかどうかだけだ。伝え方ひとつで、同じツールが「押しつけられたもの」にも「自分たちで選んだもの」にもなる。

号令の強さや操作研修の丁寧さを積み増しても、この抵抗感は解消しない。現場が動くかどうかを分けるのは、「使う理由」が現場自身に見えているかどうかだ。

POINT 02現場が使いたくなる仕組みの作り方

仕組みを「使いたくなる」ものに変えるには、精神論ではなく設計の技術がいる。行動デザインの研究で知られるスタンフォード大学のBJ・フォッグが提唱する行動モデルでは、人の行動は「動機」「能力」「きっかけ」の3つが揃って初めて起きるとされる。現場が使いたくなる仕組みとは、この3つを現場目線で満たす設計にほかならない。

1. 導入前に、現場の「面倒だと思っていること」を聞く：管理側が便利だと思うことと、現場が困っていることは、意外とずれている
2. 使った分だけ、現場の作業が減る設計にする：二重入力や、旧来のやり方と並行させる運用を避ける
3. 早い段階で小さな成功体験を共有する：「これで〇〇の時間が減った」という実感を、現場同士で共有できる場を作る

この3つは、それぞれ役割が異なる。現場の困りごとを聞くことは、何を解決すれば「やってみよう」という動機が生まれるかを知る作業であり、二重入力をなくす設計は、行動を阻む「能力」の壁を下げる作業だ。そして小さな成功体験の共有は、次の行動を後押しする「きっかけ」を作る作業にあたる。動機・能力・きっかけのどれか1つが欠けても、行動は続きにくい。

実際、ある建設資材の卸売会社では、見積作成システムの導入前に営業担当へのヒアリングを行い、「見積書の体裁を毎回作り直す手間」が最大の不満だと分かった。テンプレートを整備してその手間をなくしたところ、数週間のうちに「前より早く帰れるようになった」という声が現場から自発的に上がり始めたという。

経営学者カール・ワイクが1984年の論文で示した「スモールウィン」の考え方によれば、大きな成果を一気に狙うより、小さな達成を積み重ねて可視化するほうが、行動の変化を長続きさせやすいとされる。「これで入力の手間が減った」という小さな実感の共有は、まさにこのスモールウィンを現場の中に作る作業にあたる。

仕組みが定着するかどうかは、機能の高さではなく、現場にとっての「得」が見えているかどうかで決まる。

まとめ：定着は、現場目線の設計から生まれる

ツールを導入して終わりではなく、現場が「使ったほうが楽だ」と実感できて初めて、定着が始まる。管理側の都合だけで設計された仕組みは、どれだけ高機能でも使われなくなる。

「聞く」「作業を減らす」「小さな成功を共有する」という3つの動きは、どれか1つだけでは効果が薄い。現場の負担感を把握しないまま設計を変えても的外れになり、設計を変えても成功体験を共有する場がなければ実感は広がらない。3つが揃って初めて、現場にとっての「使う理由」が明確になる。

現場目線の設計は、導入時の一度きりの作業では終わらない。現場の状況や不満は時間とともに変わっていくため、「使う理由」が薄れていないかを定期的に振り返る姿勢も欠かせない。この考え方は、新しいツールの導入に限らず、業務ルールや評価制度を変える場面にも同じように当てはまる。

自社でツールを導入する際は、機能の比較だけでなく、「現場にとって使う理由が明確になっているか」を必ず確認してほしい。

「そろそろうちもDXしないといけないと思って。何かいいITツール、知りませんか」。DX推進の相談で、最初にこう聞かれることがよくある。気持ちはよく分かるが、この質問から入ってしまう会社ほど、後で高い買い物をして終わる。ツールを先に探すのは、症状だけ聞いて薬を出すようなものだ。本当は、その前にやるべきことがある。

POINT 01「ツールが欲しい」は、本当の課題ではないことが多い

お客さんが口にする課題は、たいてい顕在化した表面の部分でしかない。氷山でいえば、水面から出ている一角にすぎない。「ITツールがない」「うちはアナログだから」という悩みも同じで、掘ってみると水面下に別の課題が隠れていることが多い。

例えば、ある会社の経営者が「うちは紙とExcelだらけで非効率だから、便利なシステムを入れたい」と相談してきたとする。よく話を聞いていくと、実際に困っているのは”紙であること”自体ではなく、担当者ごとに違うExcelファイルで数字を管理していて、経営者が今月の受注状況をすぐに把握できないことだったりする。問題は「アナログかデジタルか」ではなく、「情報が1箇所に集まっていないこと」。ここを取り違えたまま高機能なツールを導入しても、担当者ごとの管理方法がバラバラなままシステムだけが増え、かえって二重入力の手間が増えて終わる。

なぜ「ツールが欲しい」に真っ先に飛びつくのか。心理学者アブラハム・マズローが指摘した「道具の法則」に近い現象だと考えると分かりやすい。ハンマーを手にした人には、目の前のものがすべて釘に見えてくる、という有名なたとえで知られる考え方だ。ITツールという便利な”ハンマー”が視界に入ると、課題の中身を確かめる前に、つい手を伸ばしたくなる。

表面の言葉と本当の課題を見分けるコツはシンプルだ。「ツール」や「システム」という単語を使わずに、今困っていることを説明できるかを自分に問うてみるといい。それができないうちは、まだ表面の言葉に留まっている可能性が高い。例えば「勤怠管理システムが欲しい」という相談なら、「今、誰の労働時間をどう集計できずに困っているのか」を聞き返してみるといい。答えがすぐ出てくるなら、それが本当の課題に近い。

POINT 02NG「良いツールを探す」→OK「今バラバラな情報を洗い出す」

言い換えると、こうなる。

• NG:「うちに合う、いいシステムを教えてください」
• OK:「今、どの情報が・誰の手元に・どんな形で散らばっているか、まず全部書き出してみましょう」

前者はいきなり手段(ツール)を決めにいっている。後者は、手段を選ぶ前に現状を可視化する段階だ。この順番を飛ばすと、選んだツールが実際の業務と噛み合わない、機能が過剰で使いこなせない、既存のExcel運用と結局二重管理になる、といった失敗が起きる。ツール選定は本来、情報の一元管理という”入り口”を設計したあとに来る、後工程の話でしかない。

実際のDX相談でも、営業支援ツール(SFA)を導入したのに、結局は現場がExcelの案件管理表を手放せず、同じ情報を二重に入力している、というケースをよく見る。原因はツールの性能不足ではなく、「情報をどこに集約するか」を決めないまま、先に便利そうなツールを選んでしまったことにある。結果として、ツールのライセンス費用と、Excel運用にかかる手間を、両方とも払い続けることになる。

だからこそ、次にやるべきことは「良いツールを探す」ことではなく、次に説明する「情報の洗い出し」になる。

POINT 03最初の一歩は、今ある情報を全部書き出すだけでいい

やることは大げさではない。次の順番で進める。

1. 洗い出し：今、業務に関わる情報(受注・在庫・顧客・勤怠など)が、それぞれ紙・Excel・個人のメモのどこにあるかを全部書き出す
2. 重複の発見：同じ情報を複数の場所に別々に入力していないか(担当者Aのシートと経理の台帳が同じ内容を別々に持っている、など)を確認する
3. 一元管理の場所を決める：全部を一気にシステム化しようとせず、まず”どこを情報のハブにするか”だけを決める

洗い出し自体は、ホワイトボードや1枚の紙で構わない。「受注情報は営業担当のExcel」「在庫は倉庫の手書き台帳」「顧客の連絡先は名刺管理アプリと個人のスマホの両方」というように、思いつく限り書き出していくと、同じ情報が複数の場所に散らばっている実態が自然と見えてくる。特別なスキルは要らない。現場を知っている担当者と、数字を見る経営者が、30分一緒に確認するだけで十分な精度で洗い出せる。

重複が見つかっても、その場で無理に統合しようとしなくていい。まずは「どちらを正とし、どちらを廃止するか」を決めるだけで十分だ。新しいルールを作るのは、情報のハブが決まったあとで構わない。

これだけで、必要なツールの姿がかなり絞り込める。デジタル化・AI導入補助金や県のDX補助金は、この後の導入費用を抑える手段として使えることがあるが、対象要件や補助率は制度・年度によって変わるため、活用できるかどうかは都度確認したほうがいい。補助金はあくまで導入のハードルを下げる道具であって、それを使うこと自体を目的にしないことが大事だ。

まとめ：ツールを選ぶ前に、情報の散らばりを見る

DXが失敗する会社は、たいてい「何を入れるか」から考え始める。うまくいく会社は、その前に「今、情報がどこに・どう散らばっているか」を見る。ツールは、本当の課題が見えたあとに選ぶもので、最初に選ぶものではない。まずは1時間だけ時間を取って、今使っている台帳やExcelを全部机に並べてみてほしい。そこから、本当にやるべきことが見えてくる。

ツール選びは、情報の全体像が見えて初めて意味を持つ作業になる。逆に、情報さえ整理されていれば、多少ツール選びで迷っても大きな失敗にはなりにくい。「ハンマーを一旦置いて、まず机の上に情報を並べてみる」。DX推進の最初の一歩は、実はそれだけでいい。

ツールを入れれば変わる。その発想が、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の本当の出発点になる。

「せっかく導入したのに、気づいたらまた紙とExcelに戻っていた」。DX推進の相談を受けていると、この話を本当によく聞く。原因を”社員のITリテラシー”や”やる気”のせいにしがちだが、たいていの場合、原因はツールの性能でも社員の意識でもなく、”入力しなくても業務が普通に回ってしまう”設計そのものにある。

POINT 01「少しずつ移行すればいい」が、実は一番危ない発想

新しいツールを入れるとき、多くの会社が「まずは一部の人から」「慣れている人から少しずつ」と考える。一見、現場に優しいやり方に見える。しかし実際はこれが一番定着を遠ざける。

理由は単純だ。同じ業務なのに「新ツールで入力する人」と「今まで通りのやり方で済ませる人」が混在する期間ができてしまう。旧来のやり方でも仕事が回ってしまう以上、新ツールを使わない人にとって、それは「自分はまだやらなくていい」という既成事実になる。一部がそれで回ってしまえば、業務全体としては新ツールがなくても成立してしまう。

実際にある建設業の会社では、以前クラウドツールを導入し、まずは一部のチームから使ってもらう形で移行を始めた。しかし、旧来のやり方(紙の伝票・電話・口頭確認)でも仕事自体は普通に進んでしまっていたため、使わないチームがいつまでも残った。新ツールへの入力は一部の人にとって「余分な一手間」でしかなく、忙しくなれば真っ先に省かれる。

人は”やった方がいい”では動かない。”やらないと困る”状態でしか動かない。これは怠慢ではなく、現場のリソースが有限である以上、当然の判断でもある。だからこそ、段階的な移行は「一部の人だけがやっている状態」のまま、結局定着せずに終わる。

行動経済学には”現状維持バイアス”という概念がある。経済学者のサミュエルソンとゼックハウザーが1988年の論文で示したもので、選択肢の一つが”今のまま”である限り、他の選択肢の方が客観的に優れていても、人は現状を選び続けやすいという考え方だ。DXツールの定着も構造は同じで、”今のやり方”という選択肢が残っている限り、新ツールの性能や利便性がどれだけ高くても、現場は現状維持を選んでしまう。段階的な移行が失敗しやすいのは、まさにこの”選べる状態”を長く残してしまうからだ。

POINT 02定着させる設計は、”入力しないと次に進めない”状態を先に作ること

性能の高いツールを選ぶより先にやるべきことがある。それは、旧来の抜け道を塞ぎ、新しいツールを通らないと業務が前に進まない状態を作ることだ。具体的には、次の3つを順番にやる。

1. 入力項目を業務に必要な最小限まで削る：あれもこれもと項目を増やすと、それだけで現場の負担になり敬遠される。最初は本当に必要なものだけに絞る。
2. 旧ルートを完全に塞ぐ：対象は1つの業務・1つの承認フローに絞ってよい。ただし、その範囲では「新ツールを通さないと次の工程に進めない」状態を全員に適用し、抜け道を一切残さない。対象を広げるのはそのあとでいい。
3. 導入後も伴走する：入れて終わりにせず、週次で「入力できているか」「詰まっている工程はないか」を一緒に見る期間を設ける。人に任せきりにしない。

NG例は「便利なので使ってください」と依頼して終わること。OK例は「この承認はシステムを通さないと発注が出せません」という状態を先に設計してから導入することだ。前者は”お願い”、後者は”仕組み”。この違いが、半年後に使われているかどうかを分ける。

実はこの発想自体は目新しいものではない。製造業の世界では”ポカヨケ”と呼ばれる考え方が近い。トヨタ生産方式の中で新郷重夫が体系化した仕組みで、作業者の注意力に頼るのではなく、間違った手順そのものを物理的に不可能にすることでミスを防ぐという発想だ。DX定着も本質は同じで、”入力を忘れないようにする”のではなく、”入力しない限り前に進めない”という構造を先に作ってしまう。精神論ではなく設計の話だと捉えると、何をすべきかが具体的になる。

POINT 03それを”会社の方針”として、トップダウンで進める

どれだけ良い仕組みを設計しても、それが”現場の工夫”のまま終われば定着しない。「新ツールを通さないと次の工程に進めない」という状態を作ることは、既存の業務ルールを変えることそのものだからだ。一部署や現場担当者の判断で決められる話ではない。

経営が「これはうちの会社の方針です」と明言し、上から現場に落とし込む必要がある。方針として示されたことは”お願い”ではなく”業務”になる。現場発のボトムアップの改善提案として始めてしまうと、いつまでも”やってもやらなくてもいい”扱いから抜け出せない。

ツールを使うことを”お願い”ではなく”業務”にできるかどうかは、結局のところ経営の意思決定にかかっている。小さく始めるとしても、「試しにやってみます」ではなく「これは会社として決めたことです」という位置づけで進めることが、結局は一番の近道になる。

組織変革の研究でも、同様の指摘がある。経営学者ジョン・コッターは、企業変革が失敗する典型的な原因の一つとして、経営陣による強力な推進体制(“ガイディング・コアリション”)の欠如を挙げている。現場の有志だけで進める変革は、抵抗にあった瞬間に失速しやすい。DXツールの定着も例外ではなく、”良いツールだから使ってほしい”という現場発のお願いのままでは、忙しい時期に真っ先に後回しにされる。経営が旗を振るかどうかが、それだけで生死を分ける。

まとめ：仕組みの設計と、会社の方針。この2つが揃って初めて定着する

DXが定着しない理由は、ツールが悪いからでも、社員のやる気がないからでもない。旧来のやり方でも業務が回ってしまう限り、新しいツールは省かれる。だから、伝えたいことは2つしかない。1つは、「入力しないと次に進めない」状態を仕組みとして先に作ること。もう1つは、それを現場任せにせず、経営が”会社の方針”としてトップダウンで決め、ツールを使うことを業務そのものに位置づけることだ。この2つが揃って初めて、ツールは”入れて終わり”ではなく、”定着”する。

どちらか一方だけでは足りない。仕組みだけあっても、それを”やらなくていい”と現場が判断できる状態が残っていれば形骸化するし、方針だけあっても、日々の業務の中で”入力しないと困る”という具体的な設計がなければ、方針は掛け声で終わる。ツールを選ぶ前に、この2つが自社に揃っているかを、まず確認したい。