「DXに予算をかけたが、来年は減らされそうだ」

DX推進担当者から、こんな相談を受けることが増えました。
頑張ってツールを入れた。業務改善も進めた。なのに、経営層からは「で、何が変わったの?」と聞かれる。

現場の実感としては、確かに変わっている。
でも、それが 経営の言葉 で説明できていない。

こんな声をよく聞きます。

  • 「便利になった」「現場が助かっている」では予算が通らない
  • 成果報告のたびに、利用率やログイン数だけを並べてしまう
  • 「で、いくら儲かったの?」に答えられない

これは DXの成果が出ていない わけではありません。
多くの場合、成果の翻訳に失敗している だけです。

この記事では、なぜDXの成果は経営に伝わりにくいのか、構造を整理しつつ、最初に変えるべき報告の作り方まで落とし込みます。


「現場が便利になりました」では予算は通らない

まず、現場の感覚と経営の関心は、想像以上にズレています。

現場の感覚はこうです。

  • 処理時間が短くなった
  • ミスが減った
  • 残業が減った
  • ストレスが減った

これ自体は、間違いなく成果です。
でも、経営層がこの報告を受けたときに考えるのは、シンプルにこの2つです。

  • 「で、いくら儲かったの?」
  • 「で、人を減らせるの?」

冷たく聞こえるかもしれません。
ただ、経営層は 投資の意思決定 をする立場なので、これは当然の問いです。

👉 DXの成果は「業務改善の言葉」ではなく「経営の言葉」で出さないと、評価されない

処理時間が30分短くなった、というのは現場の言葉です。
これを「年間で○○時間の削減」「人件費換算で○○円」「その時間で○○本の新規提案を作れた」まで翻訳できるかどうかが、勝負どころです。


予算が止まる会社の報告書、よくある3パターン

支援先で見てきた中で、予算が止まる会社の報告書には、ある特徴があります。

1. KPIが「使用」止まりになっている

  • 月間ログイン数
  • 利用ユーザー数
  • 機能の利用率

これ、全部「使われているかどうか」の指標です。
経営層からすると「で、それが何の役に立ってるの?」で終わります。

使われていることはスタート地点であって、ゴールではありません。
使われた結果、何が変わったかまで出して、初めて成果報告になります。

2. 定性的な言葉が多すぎる

  • 「業務効率が向上しました」
  • 「現場の満足度が上がりました」
  • 「コミュニケーションが活性化しました」

向上した、上がった、活性化した。
どれくらい? が出ていない時点で、経営層は判断できません。
「主観で言ってるだけ」と受け取られます。

3. 効果が単年度で完結している

「今期、○○時間削減できました」
「今期、○○件のミスが防げました」

これも悪くないんですが、経営層が知りたいのは 継続性 です。
来年も同じ効果が出るのか。むしろ拡大するのか。それとも今年限りなのか。
時間軸を含めて語らないと、来年の投資判断にはつながりません


原因は「報告の目的」を勘違いしていること

なぜ報告書がこうなってしまうのか。
理由はシンプルで、報告の目的を「進捗共有」だと思っているからです。

進捗共有なら、ログイン数や利用率でいい。
でも、予算を続けるための報告は 進捗共有ではなく、投資判断のための材料提供 です。

👉 DXの報告は「やったこと」ではなく「経営の意思決定に必要な情報」を出す

経営層が次年度の予算を決めるときに必要なのは、

  • このDX投資は、いくら回収できたか
  • 続けたら、来年いくら回収できるか
  • やめたら、何を失うか

この3つです。
これに答えられる報告になっていれば、予算は止まりません。
逆に、これに答えられないと、どんなに頑張っていても予算は止まります。


「経営の言葉」に翻訳する4ステップ

現場の成果を経営に伝えるとき、進む会社は次の4ステップを踏んでいます。

  • 事実を数字で押さえる(処理時間、件数、エラー率など)
  • それを金額に換算する(人件費・売上機会・コスト削減)
  • 継続性を示す(来年も同じ、もしくは拡大できる根拠)
  • やらなかった場合の損失を出す(DXを止めるリスク)

1つ目(事実を数字で押さえる)は、最低限の前提です。
「だいたい速くなった」では話になりません。Before/Afterで数字を出します。
ここは現場の協力が必要なので、最初のツール導入時から計測の仕掛けを入れておくのがコツです。

2つ目(金額に換算する)が、現場が一番苦手な工程です。
「処理時間が月50時間削減」だけだと弱い。「人件費換算で月○○円」「年間○○円のコスト削減」まで持っていきます。
ここで重要なのは、会社の単価表(時給換算など)に揃えること。バラバラの計算根拠だと、報告のたびに数字の正当性で揉めます。

3つ目(継続性を示す)は、来年の予算を取りに行くための布石です。
「今期○○円削減できた。来期も同じ効果は維持できる」「さらに別部署に横展開すれば、○○円積み増せる」。
今期だけの成果は、来期の予算根拠にならないので、ここを言語化しておきます。

4つ目(やらなかった場合の損失)は、意外と忘れられがちです。
「DXを止めたら、削減できていた○○円の効果がなくなる」「競合に対する優位性が消える」。
継続のロジックは、続けるメリットより、やめるリスクのほうが効くことが多いです。

「成果が出ていない」のではなく「翻訳されていない」だけ

現場でDXを頑張っている人ほど、報告で苦労します。
理由は、現場目線で語りすぎるからです。

現場では、確実に変化が起きています。
処理が速くなった、ミスが減った、現場の雰囲気が変わった。これは事実です。

でも、そのまま報告すると、経営層には「で、何?」で終わります。
事実を否定されているわけではなく、判断材料として足りていないだけです。

👉 経営に伝わらないのは、成果が小さいからではなく、言語が違うから

英語の論文を日本人に渡しても伝わらないのと同じです。
内容は同じでも、相手の言語に翻訳する工程を挟まないと、評価には繋がりません。


まとめ:報告の質が、来年の予算を決める

DXの予算が止まる会社は、必ずしもDXが失敗しているわけではありません。
成果は出ているのに、それを翻訳できていないケースがほとんどです。

👉 DXの推進は、半分は実行、半分は翻訳

現場の成果を金額に換算する。
継続性で語る。
やめた場合の損失で語る。

この3点を意識するだけで、報告の通り方はだいぶ変わります。
逆に、ここを軽視したまま「現場のために頑張ってます」を言い続けると、予算は静かに削られていきます。


もし「これ、うちも同じだな」と思ったら

今回書いたような、

  • DXは進めているが、経営層の評価が上がらない
  • 成果報告のたびに「で、何が変わったの?」と聞かれる
  • 来年の予算が削られそうで、不安がある

こういった DXの成果報告・KPI設計・経営層への提言の整理 の相談も受けています。

報告書の書き直しだけでも、予算の通り方は変わります。
相談では、現場の数字を経営の言葉に翻訳する工程を、一緒に組み立てることが多いです。

そのため、

  • 効果計測の指標設計(経営に伝わるKPI)
  • 金額換算の根拠づくりと報告フォーマットの整備
  • 継続性とリスクを含めた次年度提言の構成

といったところから、相談役・実行アシストとして関わっています。

無理に大規模な分析や複雑なダッシュボードを押し付けるような提案はしませんので、気になったら気軽に声をかけてもらえればと思います。

「来月から全社で導入します」

新しいツールや業務フローを入れるとき、こう宣言できる会社は、決断力があると思います。
中途半端にやるくらいなら一気にやったほうがいい、という発想自体は間違っていません。

ただ、現場ではこんなことが起きがちです。

  • 初日からシステムが詰まって、業務が止まる
  • 問い合わせが情シスに殺到して、誰も応対しきれない
  • 「前のやり方に戻していいですか」が部署ごとに発生する

これは ツールが悪い のではなく、多くの場合 展開の設計 が原因です。
全社一斉は、見た目はスピード感がありますが、失敗の被害も全社一斉になります。

この記事では、なぜ一斉展開が崩壊しやすいのかを構造で整理し、最初に選ぶべき展開単位の話まで落とし込みます。


一斉展開は「速い」ように見えて、実は遅い

まず誤解されやすい点から整理します。

一斉展開は、計画書上では最短ルートに見えます。
「3か月で全社にロールアウト」「4月から全部署で利用開始」。スケジュールがきれいに引けます。

でも実際の現場では、こう動きます。

  • 初週: トラブル対応で推進側が手一杯になる
  • 2〜3週目: 各部署から「使い方が分からない」が連鎖する
  • 1か月後: 「とりあえず前のやり方に戻した」部署が出る
  • 3か月後: 「ツールはあるが、使われていない」状態になる

スケジュール通りに「展開」は終わっています。
ただ、定着していない。これが一斉展開の典型的な落とし方です。

👉 「展開した」と「使われている」は別の話

見た目の進捗は出ます。
でも、組織として新しいやり方に乗り換えられていないので、結局その後にもう一度プロジェクトをやり直すことになります。


崩壊する会社に共通する3つの兆候

一斉展開がうまくいかない会社には、だいたい共通の兆候があります。

1つ目: パイロット運用を飛ばしている

「うちは小さい会社だから、いきなり全社でいい」と判断するケースです。
規模に関係なく、新しい仕組みは 想定外 が必ず出ます。
パイロットなしでいきなり全社に乗せると、その想定外が 全部署で同時に発生します。

2つ目: 推進側のキャパが見えていない

展開のときに必要なのは、ツールを配ることではなく、質問に答える人の数です。
1人の情シスに、500人分の質問が飛んできたらどうなるか。当然さばけません。
さばけないと、現場は「使えないツール」と判断します。実際にはツールではなく、サポート体制が足りなかっただけですが、現場にはそう見えません。

3つ目: 戻れる道を用意していない

これが地味に重要で、「ダメだったら戻す」プランがない一斉展開は、ほぼ崩壊します。
なぜなら、トラブルが起きたときに「戻す」判断ができず、現場が勝手にバラバラと戻し始めるからです。
結果、ツールも前のやり方も中途半端に並走する、最悪の状態になります。


原因は「経営判断としての爽快感」を優先していること

なぜ一斉展開を選んでしまうのか。
理由はわりとシンプルです。

👉 段階展開は「やった感」が薄いから

経営層から見ると、「3か月かけて1部署から始めます」より「来月から全社」のほうが、決断力があるように見えます。
社内アナウンスも派手に打てます。
プレスリリースも書けます。

ただ、これは 経営判断としての爽快感 を優先しているだけで、現場のオペレーション設計とは別の話です。

現場のオペレーションは、地味なほうが安全です。

  • 1部署で2か月回す
  • 問題点を潰す
  • 隣の部署に広げる
  • また問題点を潰す
  • 3〜4部署目で、ほぼ型ができる

こうやって積み上げたほうが、結果的に半年後の「使われている率」は圧倒的に高くなります。
派手さと、定着率は反比例しやすいということです。


段階展開の設計、4つのポイント

じゃあ段階展開ならいいのかというと、これも設計次第です。
進む会社が押さえているのは、次の4つです。

  • 最初の部署をどこにするか(選定基準
  • どれくらいの期間で見るか(観察期間
  • 何が起きたら次に進むか(移行基準
  • 何が起きたら戻すか(撤退基準

1つ目(選定基準)は、「規模が小さい部署」「協力的な部署」だけで選ばないのがコツです。
むしろ、そのツールが一番効くはずの部署を最初に選ぶ。ここで効果が出れば、横展開の説得材料になります。

2つ目(観察期間)は、最低でも2〜3か月は欲しいです。
1週間や2週間だと、初期トラブルしか見えません。業務が1サイクル回って、月次処理まで終わるところまで見ないと、本当の運用課題は出てきません。

3つ目(移行基準)は、感覚で判断しないこと。
「利用率○%以上」「問い合わせ件数が週○件以下」「現場の満足度が○以上」など、数字で線を引いておくと、横展開のときに余計な政治が発生しません。

4つ目(撤退基準)は、最初に決めておくのがすべてです。
走り出してから「やっぱり戻そうか」と議論するのは、関係者にとって地獄です。
「こうなったら一旦止める」を最初に合意しておくだけで、リスクの取り方が変わります。


一斉展開が許される、数少ない条件

念のため書いておくと、一斉展開がダメと言いたいわけではありません。
次の条件が揃っているなら、一斉展開のほうが速いです。

  • 既存業務との置き換えが単純で、例外処理がほぼない
  • 全社員のITリテラシーが揃っている
  • サポート体制が圧倒的に厚い(外部ベンダー込みで人員確保済み)
  • 経営層が「初日のトラブルは織り込み済み」と覚悟している

中小企業でこの4つが揃うことは、正直あまりありません。
だからこそ、「段階展開がデフォルト」と考えたほうが事故が少ないです。


まとめ:派手な展開より、定着率で評価する

新しい仕組みを入れるときに本当に問うべきは、3か月後の 利用率 です。

👉 「全社に展開した」ではなく「全社で使われている」が成功条件

この評価軸さえブレなければ、選ぶべき展開方法は自然と決まります。
一斉展開の爽快感より、半年後に振り返って「ちゃんと使われているね」と言える設計のほうが、結果的に投資対効果は高いです。


もし「これ、うちも同じだな」と思ったら

今回書いたような、

  • 新しいツールを入れたが、現場が使いこなせていない
  • 展開直後にトラブルが連鎖して、推進側が疲弊した
  • 「全社一斉」で導入したものの、結局元のやり方に戻った部署がある

こういった DX展開の設計・パイロット運用の組み方・横展開の進め方 の相談も受けています。

ツール選びの前に、どの部署から、何を基準に広げるか を言語化すると、現場の負荷がだいぶ違います。
相談では、そこから一緒に分解していくことが多いです。

そのため、

  • パイロット部署の選定と移行基準の整理
  • サポート体制の設計とFAQの型づくり
  • 撤退基準を含めたリスク管理プランの作成

といったところから、相談役・実行アシストとして関わっています。

無理に大規模な変革を一気に押し付けるような提案はしませんので、気になったら気軽に声をかけてもらえればと思います。

「うちも業務効率化を進めています」

ここまで動いている会社は、姿勢として前向きだと思います。
ツールを入れたり、会議を減らしたり、ワークフローを見直したり。改善意欲がある会社ほど、こうした取り組みは早いです。

ただ、現場を見ていると、こんな声をよく聞きます。

  • 効率化したはずなのに、ベテランだけ忙しいまま
  • ツールを入れたのに、結局あの人に聞かないと分からない
  • 手順書を作ったが、実態は誰も見ていない

これは 効率化の失敗 というより、多くの場合 属人化を放置したまま効率化を始めた ことが原因です。
順番が逆だと、効率化は一部の人にしか効きません。

この記事では、属人化と効率化の関係を整理し、最初に戻すべき順序の話をまとめます。


効率化が効いているのは、実は一部の人だけ

業務効率化を進めると、全社的に楽になるイメージがあります。
でも実際には、効果が出るのは すでに業務を把握している人 に偏りがちです。

たとえば、経理のベテランが使っている独自のExcelをRPA化したとします。
処理は速くなる。ミスも減る。ここまでは成功に見えます。

でも、現場ではこんなことが起きます。

  • RPAが止まったとき、直せるのはベテラン本人だけ
  • 仕様の背景を知らない人が触ると、逆に壊す
  • 結局、ベテランに問い合わせが集中して、本人の負担が増える

つまり、効率化の恩恵を受けているのは、もともと業務が分かっていた人です。
それ以外の人にとっては、ブラックボックスが1個増えただけ。

👉 属人化を温存したまま自動化すると、属人化は「見えにくくなる」だけで、消えない

むしろ、ツールの中に業務知識が埋め込まれる分、後から解きほぐすのが難しくなるケースも多いです。


「手順書を作れば解決する」という誤解

属人化の話をすると、多くの会社でまず返ってくるのが次の言葉です。

「手順書を作らせています」

もちろん、手順書は重要です。
ただ、手順書単体では、属人化はほぼ解消しません。

現場でよく見る光景はこれです。

  • 手順書はある。でも最新じゃない
  • 手順書通りにやっても、例外処理が書かれていない
  • 結局、例外が出た瞬間に「あの人に聞く」に戻る

属人化の本体は、実は 手順 ではなく 判断 の方にあります。
「この取引先は例外対応」「この金額を超えたら上長確認」「この時期だけ別フロー」。
こういう 判断のロジック が、一人の頭の中にしか残っていない状態が属人化です。

手順書に書けるのは、だいたい順調に進んだときの流れだけ。
判断の分岐と、その判断基準が言語化されていないと、手順書は飾りになります。


原因は「効率化の前にやることを飛ばしている」

属人化が残ったまま効率化に進んでしまう会社の共通点は、シンプルです。

👉 業務の棚卸しをせずに、ツール選定から入っている

効率化のプロジェクトは、多くの場合こう始まります。

  • 他社事例でRPAが効いたらしい
  • SaaSの営業からいい提案があった
  • 役員が「AI使って何かできないか」と言い出した

このとき、「どの業務が、誰に、どう依存しているか」を見える化する工程は、ほぼ飛ばされます。
なぜなら、地味で時間がかかるからです。

でも、この棚卸しがないまま効率化を始めると、次のどちらかになります。

  • 簡単な業務だけ自動化される(本当に効かせたい業務は属人化で手が出せない)
  • ベテランの業務をそのまま自動化する(結果、ベテラン依存が強化される)

どちらも「効率化っぽい何か」は起きます。
でも、組織としての強さは上がらないことが多いです。


効率化の前にやるべき3つ

属人化を放置したまま進めないために、効率化の前に最低限押さえたいのは次の3つです。

  • 業務の棚卸し(誰が、何を、どのくらいやっているか)
  • 判断ロジックの見える化(何を基準に、どう決めているか)
  • 代替可能性の確認(他の人が引き継げる状態になっているか)

1つ目(業務の棚卸し)は、組織図ではなく 業務量の実態 を見る作業です。
「この業務は月に何件で、何時間かかっているのか」「誰が何割を担っているか」を、ざっくりでいいので可視化します。

細かい時間計測までは不要です。
感覚値でいいので、誰にどれだけ集中しているかが見えるだけで、次の議論が変わります。

2つ目(判断ロジックの見える化)は、手順書の一歩先です。
「この条件のときはA」「この金額を超えたらB」「この顧客だけ例外でC」を書き出していきます。

やってみると分かりますが、ベテランは 自分が判断基準を持っていること自体を忘れている ことが多いです。
「これは感覚です」「これは経験です」と言いながら、実は一定のロジックで判断しています。
それを引き出す工程が、属人化解消の本体です。

3つ目(代替可能性の確認)は、形式的なチェックではなく、実際に代わりの人にやらせてみるのが早いです。
1日でいいので、ベテラン以外の人にその業務を担当させてみる。
どこで詰まるか、何を質問してくるかが、属人化が残っている場所のシグナルです。


効率化は「標準化できた業務」から

属人化と効率化の関係を、ひとことで言うとこうなります。

👉 効率化できるのは、標準化できた業務だけ

逆に言うと、標準化されていない業務を効率化しようとすると、属人化が固定化される
ここは何度でも強調しておきたい点です。

進む会社は、この順番を守っています。

  1. 業務を棚卸しする(見える化)
  2. 判断ロジックを言語化する(標準化)
  3. 代替可能な状態にする(脱属人化)
  4. そのうえで効率化・自動化する

1〜3をすっ飛ばして4から入ると、「速いけど誰も触れない業務」が増えます。
短期的な効果は出ますが、組織の持続性は弱くなります。

私が支援に入るときも、ツール選定の前に、この1〜3を一緒に整理することが多いです。
ここが揃うと、効率化の手段は意外とシンプルに決まります。


「ベテランを休ませる」ことが、実は一番の効率化

最後に、属人化を抱えた組織によく伝えていることがあります。

👉 ベテランに1週間休んでもらうと、属人化の場所がすぐ見える

計画有休でもいい、研修参加でもいい、出張でもいい。
ベテランを現場から1週間外してみると、止まる業務と止まらない業務が、くっきり分かれます。

止まった業務こそ、本当に効率化(正確には 標準化)が必要な場所です。
止まらなかった業務は、実はツールを入れなくてもそこそこ回っていた業務です。

この観察をせずに、現場の声だけで効率化対象を決めると、たいてい順番を間違えます。


まとめ:順番を変えるだけで、効率化は効き始める

効率化は、ツール選定やベンダー選びの話に見えがちです。
でも本質は、業務を見える化して、判断ロジックを組織の財産にする話です。

👉 効率化の前に、標準化。標準化の前に、棚卸し

この順番さえ守れれば、少人数の会社でも効率化は機能します。
順番を間違えると、立派なツールと、属人化したベテランだけが残ります。


もし「これ、うちも同じだな」と思ったら

今回書いたような、

  • ツールを入れたのに一部の人しか使えていない
  • 手順書を整備したのに結局「あの人頼み」が続く
  • 効率化を進めるほどベテランの負担が増えている

こういった 属人化の整理・業務の棚卸し・標準化の順序づくり の相談も受けています。

ツールや自動化の前に、誰が何をどう判断しているか を言語化すると、効率化の効きどころが見えてきます。
相談では、そこから一緒に分解していくことが多いです。

そのため、

  • 業務棚卸し(誰に何が集中しているかの見える化)
  • 判断ロジックの言語化と標準化
  • 代替可能性の確認と引き継ぎ設計

といったところから、相談役・実行アシストとして関わっています。

無理に大規模な業務改革を押し付けるような提案はしませんので、気になったら気軽に声をかけてもらえればと思います。

「DXはベンダーに任せています」

ここまで言える会社は、むしろ前向きだと思います。
外部の知見を借りるのは、中小企業にとって合理的な選択肢のひとつです。

ただ、現場の実感としては、次のようなズレが起きがちです。

  • 会議は増えたのに、社内の意思決定が進まない
  • 資料は厚くなるのに、業務の回り方が変わらない
  • 「ベンダー待ち」が常態化して、自分たちの課題感が薄れる

これは 外注が悪い のではなく、多くの場合 丸投げの設計 が原因です。
DXは「納品物を買う」だけでは完結しにくい領域だからです。

この記事では、形骸化しやすい構造と、最初に戻すべき分担の話を整理します。


外注は悪くない。丸投げが悪い

まずはっきり書いておきます。
ベンダーを使うこと自体は、失敗の原因ではありません。

むしろ、要件整理や実装、運用設計の一部を外部に頼むのは、よくあるやり方です。
問題になりやすいのは、境界がこうなっているときです。

  • 「とにかく任せた」結果、何を決めるべきかが社内に残っていない
  • ベンダーが出す案を、そのまま通すしかない(判断軸が社内にない)
  • 現場が「彼らの仕事」として距離を置いてしまう

この状態は、悪意がなくても起きます。
社内は本業で忙しい。DXは専門的で手が出しにくい。だから任せる、は自然な心理です。

👉 任せることと、放っておくことは別

「任せる」とは、責任の所在まで渡すという意味ではありません。
少なくともDXでは、何を達成したいか何を社内が握るか は、発注側に残り続けます。


形骸化すると、現場はこう見える

形骸化が進むと、現場から見える景色はだいたい似てきます。

会議体は立ち上がるのに、結論は「ベンダー側の検討待ち」で止まる。
社内は「資料が増えた」「用語が増えた」だけで、自分たちの仕事の進め方が変わった実感が薄い。

さらに進むと、現場はこう感じ始めます。

  • DXは“上のプロジェクト”で、自分のKPIではない
  • 意見を言っても、要件に落ちない
  • 結局、新しい仕事が増えただけでは?

ここまで来ると、推進側は必死でも、組織としての学習が起きにくいです。
学習が起きないと、次の改善も積み上がりません。

私が支援でまず見るのは、成果物の定義より前に 意思決定のログ です。
「誰が、何を、いつ決めたか」が追えないと、丸投げに見えてしまいます。


原因は「分担設計」が抜けていること

止まり方の根っこは、シンプルに言うと 分担設計 の不足です。

ベンダーは、契約された範囲で最善を尽くします。
一方で、DXは現場の運用・例外処理・部署間の調整まで含むことが多いです。

つまり、社内に残すべきは次のような領域です。

  • 何をもって成功とするか(成功条件)
  • 何を優先し、何を後回しにするか(トレードオフの決断)
  • 現場が実際に守れる運用か(受入れと現実化)

ここが社内にないまま「提案書が厚くなる」方向に進むと、形は整うのに中身が入らない状態になりやすいです。

👉 外部は“実行の加速”であって、意思決定の代替ではない

この線引きが曖昧なままだと、ベンダーは提案を増やしがちです。
増やすのは悪ではないのですが、社内の決裁が追いつかないと、プロジェクトは重くなるだけです。


進む会社が、最初に決めている3つ

丸投げを避けて前に進める会社は、最初に次の3つを固めています。

  • 目的と成功条件(何ができたら一段落か)
  • 社内の最終決裁者(誰がトレードオフを決めるか)
  • 受入れ基準と、週次のすり合わせ(現場が持てる形に落とす頻度)

目的と成功条件がないと、議論が「より良い一般論」に寄ります。
DXは一般論より、自社の優先順位が重要です。

最終決裁者が不在だと、ベンダーが出した選択肢に対して、社内で答えが返せません。
「持ち帰ります」が増えるほど、プロジェクトは遅れます。

受入れと週次がないと、完成物が出た瞬間に初めて問題が見つかります。
そこで大きな手戻りが出ると、関係者の疲労が一気に増えます。

この3つは、壮大なガバナンス整備からでなくてよいです。
A4で1枚ずつでも、言葉として揃っているだけで進み方が変わります。


外部は「腕」だけで選ばない方がいい

ベンダー選定でよく見えるのが、実績・規模・価格中心の比較です。
もちろん重要です。

ただ、DXが形骸化しやすい会社ほど、もう一つ欲しい視点があります。

「問いを返してくれるか」 です。

社内の前提が曖昧なときに、黙って作り込む相手だと、後で噛み合わなくなります。
逆に、早い段階で 前提の穴 を突いてくれる相手の方が、結果的にコストが安いことが多いです。

私は支援でも、最初に「誰が何を決めるか」を一緒に整理することが多いです。
ここが固まると、ベンダーとの会話の質が上がります。


まとめ:進めるのは、結局「社内の決裁」

DXは、ツールや開発だけの話に見えがちです。
でも本質は、業務の優先順位と責任分界を更新する話です。

だから最後に戻るのは、いつも社内です。

👉 外部は伴走者。舵は社内が握る

この前提が揃うと、外注は強い武器になります。
揃わないままだと、立派な資料と疲弊だけが残りやすいです。


もし「これ、うちも同じだな」と思ったら

今回書いたような、

  • ベンダー任せで社内の意思決定が止まっている
  • 要件が膨らみ続けて終わりが見えない
  • 成果物の受入基準が曖昧で手戻りが続く

こういった DXの進め方・発注側の分担設計・ベンダー連携の整理 の相談も受けています。

理想の提案書より先に、誰が何を決めるか を言語化すると、会議の空気が変わることが多いです。
相談では、そこから一緒に分解していくことが多いです。

そのため、

  • 成功条件と決裁者の明確化
  • 週次でのすり合わせと受入れの型づくり
  • 要件の優先順位付け(やらないことの決定)

といったところから、相談役・実行アシストとして関わっています。

無理に内製化へ振り返すような提案はしませんので、気になったら気軽に声をかけてもらえればと思います。

「DX推進担当を任命しました」

ここまでできている会社は多いです。
ただ、現場の実感としては「結局、何も変わっていない」というケースが少なくありません。

中小企業に限らず、DX推進の話題は増えました。
一方で、担当を置いた“宣言”まで行って、実行の設計が追いついていないパターンも同じくらい見かけます。

経営側から見ると「人を置いたから動くはず」ですが、現場はそう単純ではありません。
DXはツール導入だけではなく、業務の優先順位・裁量・会議体まで含む話だからです。

この記事では、なぜ止まりやすいのかを構造で整理し、最初に整えるべきポイントまで落とし込みます。


担当はいるのに、プロジェクトが動かない

DX推進担当がいるのに進まないとき、現場ではだいたい次のようなことが起きています。

  • 各部署の協力が得られない
  • 意思決定が上に上がらない
  • 改善案が「検討中」で止まる

たとえば「業務改善の打ち合わせ」が週次であるのに、結論が出ない。
出たように見えても「他部署の調整が必要」「予算の確認が必要」「社長決裁」と次の壁が連鎖する。

担当者本人は動いているのに、組織としての“前に進む約束”がない状態です。

ここで誤解されやすいのは、「担当者の能力不足」に原因を求めがちな点です。
もちろんスキルは関係します。ただ、多くの場合はスキル以前に、役割と権限の設計が曖昧なまま走り出していることが大きいです。

👉 人を置いただけで、進む仕組みがない

「DXをやる人がいる」ことと、「DXが前に進む仕組みがある」ことは別です。
前者だけ整っていると、担当者はいずれ疲弊します。


原因は「担当者」ではなく「権限設計」

止まる会社の共通点は、シンプルに言うと次の一点に集約されます。

👉 担当者に「期待」だけが乗っていて、権限がない

期待は高い。
でも、次のような“決められなさ”が残っていることが多いです。

  • 改善対象を選ぶ権限がない
  • 関係部署へ依頼する根拠がない(公式な優先順位がない)
  • 優先順位を決める会議体がない(決まっても覆る)

この状態だと、担当者は「お願い業」になります。
お願いは短期では通っても、継続的な改善には向きません。なぜなら、他部署の本業はDXではないからです。

また、権限がないままKPIだけが増えると、担当者は窮屈になります。
「やれ」と言われるが「決められない」。このギャップは、離職や身内化(担当者だけが詳しい)にもつながりやすいです。

だから私は現場で、まず 何を決められる人なのか を言語化するところから入ります。
ここが曖昧なままツール選定やベンダー比較に進むと、議論が空転しやすいです。


最初に決めるべき3つ

DX推進担当を「機能する状態」にするには、最低限この3つが必要です。

  • 何を決めてよいか(担当の決裁範囲)
  • 誰が最終決定するか(承認ルート)
  • いつ進捗を確認するか(定例レビュー)

1つ目(決裁範囲)は、「担当者が独断で壊す」ためではなく、迷いを減らすための設計です。
小さくてよいので、たとえば「このカテゴリの業務改善案は担当が一次決定し、横展開だけ役員承認」など、線を引けます。

2つ目(承認ルート)は、遅さよりも 見える化 が重要です。
「誰がいつまでに何を決めるか」が曖昧だと、検討が長引きます。検討は悪くないですが、検討の終わり方がないと前に進みません。

3つ目(定例レビュー)は、進捗管理というより 意思決定のリズム を作るための仕組みです。
月1回でもよいので、「止まっている理由」を上げて潰す場所があると、組織の学習速度が上がります。

この3点があるだけで、「担当者の頑張り依存」から抜けやすくなります。
頑張りは必要ですが、頼り切りの設計は続きません


1人目は「スキル」より「接続力」

最初のDX推進担当に必要なのは、ツール知識だけではありません。
むしろ中小企業では、次の力が先に問われます。

現場の困りごとを拾って、経営の意思決定につなげる 接続力(翻訳力)です。

現場の言葉は「忙しい」「今は無理」「リスクが」になりがちです。
経営の言葉は「投資対効果」「優先度」「いつまでに」になりがちです。

この両方を往復できて、同じ論点を別の言葉で説明できる人がいると、会議の質が変わります。
逆に、片方に寄りすぎると「現場の不満の聞き手」か「理想論の担当」になりやすいです。

だからこそ、役職名をつけるより先に、「どことどこをつなぐ役割か」を定義しておく必要があります。

接続力は、セミナーで一発で身につくものではありません。
ただ、会議の型・資料の型・意思決定の型を先に用意すると、誰が担当でも再現性が上がります。


DX推進担当は“肩書き”ではなく“仕組み”

DXで差が出るのは、担当者の能力差より、仕組みの有無です。

👉 置くことより、動ける設計を先に作る

肩書きは、組織にとっては分かりやすいシグナルです。
でも読者のみなさんもご存じの通り、肩書きだけでは業務は回りません

少人数の会社ほど、個人の体力で回そうとしがちです。
ただ、DXは短期決戦ではなく、途中で本業が忙しくなることも多いテーマです。
だからこそ、忙しくても最低限回るラインを先に決めた方が、結果的に早いです。

私が支援で意識しているのは、壮大なDX宣言より、「今四半期は何を1つ終えるか」 を組織で握れる状態にすることです。

ここができると、少人数の会社でも前進できます。


もし「これ、うちも同じだな」と思ったら

今回書いたような、

  • DX推進担当を置いたのに現場が動いていない
  • 改善の決裁ルートや優先順位が曖昧で止まる
  • 「検討中」のままプロジェクトが進まない

こういった DX推進の役割設計・会議体・進め方の整理 の相談も受けています。

担当者の問題ではなく、権限と意思決定の流れを先に整えると、少人数でも前に進みやすくなります。
相談では、理想論より 「今週何を決めると動くか」 を一緒に分解することが多いです。

そのため、

  • 担当者の決裁範囲と承認ルートの整理
  • 月次レビューなどの進捗確認の型づくり
  • 最初の着手テーマの絞り込み

といったところから、相談役・実行アシストとして関わっています。

無理に人を増やしたり、大きな組織変更を押し付けるような提案はしませんので、気になったら気軽に声をかけてもらえればと思います。

DXやIT化を進めようとしたとき、

「とりあえずツールを入れる」という判断をする会社は少なくありません。

 

ただ、この進め方は

かなり高い確率で失敗します。

 


 

とにかくツールを入れていった

 

ある会社では、業務改善のために

  • CRM(顧客管理)

  • タスク管理ツール

  • チャットツール

  • ワークフローシステム

を次々と導入していきました。

 

それぞれのツール自体は優秀で、

導入判断も間違っていないように見えます。

 

👉 「デジタル化すれば良くなるはず」

という発想です。

 


 

でも、現場はどんどん疲弊していった

 

実際に起きたのは、こういう状態でした。

  • 同じ情報を複数のツールに入力

  • データの所在が分からない

  • どれが正しい情報か判断できない

 

さらに、

 

  • ツールごとに操作方法が違う

  • 確認の手間が増える

  • 結局、Excelでまとめ直す

 

👉 「効率化のはずが、作業が増えている」状態

 

現場からは、

 

  • 「ツール増えただけで楽になっていない」

  • 「前の方がシンプルだった」

 

という声が出始めました。

 


 

原因は「ツール単位」で考えていたこと

 

この失敗の原因はシンプルです。

 

👉 業務ではなく、ツール単位で考えていたこと

 

本来は、

 

  • 情報はどこで発生し

  • どこを通って

  • どこで使われるのか

 

という「流れ」で考える必要があります。

 

しかしこのケースでは、

 

👉 「このツール便利そう」→導入

 

が繰り返されていました。

 


 

支援で再始動したときにやったこと

 

外部支援で最初に行ったのは、

 

👉 ツールを増やすことではなく、減らすことでした。

 

具体的には、

 

  • 各ツールの役割を整理

  • 重複している機能の洗い出し

  • データの流れを一本化

 

その上で、

 

  • 入力は1箇所に集約

  • 他ツールは連携前提に

  • 不要なツールは停止

 


 

結果、「ツール活用」から「仕組み」に変わった

 

改善後は、

 

  • 入力作業は減少

  • 情報の所在が明確に

  • 確認作業が大幅に削減

 

👉 「ツールを使っている状態」から

「仕組みとして回っている状態」へ変化

 


 

ツールは増やせばいいわけではない

 

DXで重要なのは、

 

👉 「何を入れるか」ではなく「どうつなぐか」

 

です。

 

ツール単体ではなく、

業務全体の流れで設計すること

 

ここを外すと、

どれだけ良いツールを入れても効果は出ません。

 


 

もし「これ、うちも同じだな」と思ったら

 

今回書いたような、

 

  • ツールが増えすぎて整理できていない

  • 同じ情報を何度も入力している

  • デジタル化したのに、むしろ手間が増えている

 

こういった ツール乱立・運用の整理 の相談も受けています。

 

ツールの良し悪しではなく、

どうつなぐか・どう流すかで結果は大きく変わります。

 

そのため、

 

  • ツールの役割整理

  • データの流れの設計

  • 不要なものの切り分け

 

といったところから、

相談役・実行アシストとして関わっています。

 

無理にツールを増やす提案はしませんので、

気になったら気軽に声をかけてもらえればと思います。

DXやIT化を進めようとしたとき、

最初にやるのが業務の棚卸しです。

 

ここでよくあるのが、

「優先順位の付け方」を間違えてしまうことです。

 

一見もっともらしく見える判断が、

実はかなり危険な方向に進んでいるケースがあります。

 


 

「1日2000分削減できます」は本当に正しいのか

 

例えばこんな話です。

 

ある業務を棚卸しした結果、

 

  • 1回5分の作業

  • それが1日4回

    1人あたり20分/日

 

社員が100人いれば、

 

  • 20分 × 100人 = 2000分/日

  • 約33時間分

 

これを時給1,500円で換算すると、

 

  • 約5万円/日

  • 年間ではかなりの金額になる

 

なので、

 

「この作業をツールで効率化すれば元が取れる」

 

こういう判断をしたくなります。

 


 

この考え方が危険な理由

 

このロジック、

一見正しそうですが、重要な前提が抜けています。

 

それは、

 

👉 その2000分は「まとまった時間ではない」

という点です。

 


 

分散した時間は、価値に変わらない

 

実際に起きているのは、

 

  • 5分の作業

  • それが1日4回

  • それが100人に分散している

 

という状態です。

 

つまり、

 

👉 33時間のまとまった時間があるわけではない

 

ということです。

 


 

短くしても「消えない業務」になる

 

仮にこの5分の作業をツールで効率化して、

1〜2分に短縮できたとします。

 

ただし、

 

  • タスク自体は残る

  • 1日4回発生する

  • 都度、手を止める必要がある

 

つまり、

 

👉 業務の存在は消えていない

 

という状態です。

 


 

では、その「浮いた時間」で何ができるのか

 

ここも重要なポイントです。

 

5分が1分になったとして、

1回あたり4分浮きます。

 

ただしその4分は、

 

  • 別の業務との間に挟まれている

  • まとまった時間ではない

  • 集中して何かに使える時間ではない

 

結果として、

 

👉 新しい価値を生む時間にはならない

 

ことがほとんどです。

 


 

つまり何が起きているか

 

このようなケースでは、

 

  • 人件費はほぼ変わらない

  • 生産性も大きくは変わらない

  • 追加の売上も生まれない

 

一方で、

 

  • ツールの導入コスト

  • 運用変更の負担

  • 現場の学習コスト

 

は確実に発生します。

 

👉 結果として「効率化したはずなのに得していない」状態になる

 


 

では、何を基準に判断すべきか

 

ここまでの話から分かるのは、

 

👉 「時間の量」ではなく「時間の質」を見る必要がある

ということです。

 

例えば、

 

  • 業務そのものを消せるか

  • 人の手を完全に外せるか

  • 業務の流れ全体を短縮できるか

  • ボトルネックになっている部分か

 

このあたりが重要な判断軸になります。

 


 

DXは「足し算」ではなく「再設計」

 

よくある間違いは、

 

👉 「細かい時間を足し算して判断する」こと

 

ですが、実際に必要なのは、

 

👉 業務の流れそのものを見直すことです。

 

DXは、

 

時間削減の積み上げではなく、流れの再設計

 

ここを外すと、

どれだけツールを入れても効果は出ません。

 


 

ただし、この判断は意外と難しい

 

ここまで読むと、

 

「じゃあ何を対象にすればいいのか?」

と感じると思います。

 

実際、この判断はかなり難しく、

 

  • 現場の感覚だけではズレやすい

  • 時給換算に引っ張られやすい

  • 部分最適に寄りやすい

 

という特徴があります。

 


 

もし「これ、うちも同じだな」と思ったら

 

今回書いたような、

 

  • 業務棚卸しをしたが、優先順位に自信がない

  • 時間削減のロジックで判断してしまっている

  • ツール導入の効果が本当に出るか不安

 

こういった DXの対象選定・優先順位付け の相談も受けています。

 

どの業務を削るべきか、どこに投資すべきかは、

個別の業務構造によって変わる部分が大きいです。

 

そのため、

 

  • 現状の整理

  • 業務のつながりの把握

  • 優先順位の設計

 

といったところから、

相談役・実行アシストとして関わっています。

 

無理にツール導入を進めることはしませんので、

気になったら気軽に声をかけてもらえればと思います。

DXやIT化がうまくいかない会社には、

いくつか共通した特徴があります。

 

その中でも特に多いのが、

「判断基準そのものがズレている」というケースです。

 

ツールの選び方や技術の問題ではなく、

何を基準に意思決定しているかの問題です。

 


 

「時間削減=正義」になっている

 

よくあるのが、

 

  • この作業は1日○分かかっている

  • 人数分で掛けると○時間になる

  • だから削減すべき

 

という判断です。

 

一見合理的ですが、

これは前回の記事でも触れた通り、

 

👉 分散した時間を足し算しているだけ

 

という状態になりがちです。

 

結果として、

 

  • 削減しても実態はあまり変わらない

  • 新しい価値も生まれない

  • コストだけ増える

 

という失敗につながります。

 


 

「できること」から始めてしまう

 

もう一つ多いのが、

 

👉 「できそうなところ」から着手するパターンです。

 

例えば、

 

  • Excelで自動化できそう

  • RPAが使えそう

  • ツールを入れればすぐできそう

 

こういった理由で対象を決めてしまう。

 

これは一見スムーズに見えますが、

 

  • 本当に重要な業務ではない

  • 全体への影響が小さい

  • 部分最適で終わる

 

というケースが非常に多いです。

 


 

「現場の感覚」だけで決めている

 

現場の意見を聞くこと自体は重要です。

 

ただし、

 

  • ここが大変です

  • ここを楽にしたいです

 

という声だけで判断してしまうと、

 

👉 全体としての最適化にはつながらない

 

ことが多いです。

 

現場は「目の前の負担」を基準に考えますが、

DXは「全体の流れ」を基準に考える必要があります。

 


 

「ツール導入」がゴールになっている

 

これも非常によくあります。

 

  • ツールを導入した

  • 自動化できた

  • システム化した

 

ここで満足してしまうケースです。

 

ただ実際には、

 

  • 使われていない

  • 運用が定着していない

  • 結局元のやり方に戻っている

 

ということが起きます。

 

👉 導入=成功ではない

 

ここを誤ると、

DXは形だけのものになります。

 


 

本来見るべき判断基準

 

では何を基準に考えるべきか。

 

ポイントはシンプルです。

 

👉 「どこを変えると全体が変わるか」

 

具体的には、

 

  • 業務の流れを止めている部分か

  • 人の判断がボトルネックになっているか

  • 前後の業務に影響が広がるか

  • 完全に削減・置き換えできるか

 

このような観点で見る必要があります。

 


 

DXは「部分改善」ではなく「構造の変更」

 

DXは、

 

  • 早くする

  • 楽にする

 

だけでは不十分です。

 

👉 業務の構造そのものをどう変えるか

 

ここまで踏み込まないと、

効果は限定的になります。

 


 

もし「これ、うちも同じだな」と思ったら

 

今回書いたような、

 

  • 何を基準にDXを進めればいいか分からない

  • 時間削減のロジックで判断してしまっている

  • ツールは入れたが、効果に手応えがない

 

こういった DXの判断基準・進め方の整理 の相談も受けています。

 

どこを変えるべきか、何を優先すべきかは、

業務全体の構造を見ないと判断が難しい部分です。

 

そのため、

 

  • 現状の整理

  • 業務のつながりの把握

  • 優先順位の設計

 

といったところから、

相談役・実行アシストとして関わっています。

 

無理にツール導入を進めることはしませんので、

気になったら気軽に声をかけてもらえればと思います。

【全部内製、全部外注はどちらも極端】

 

IT化やDXでよくある悩みが、

どこまで内製でやるべきか、どこから外注するか

という点です。

 

結論から言うと、

どちらかに振り切る必要はありません。

 


 

【内製に向いている領域とは】

 

例えば、

  • 日々入力するデータ

  • 業務ルールが頻繁に変わる部分

  • 「ちょっと直したい」が多い作業

 

こういったものは、

内製の方が向いています。

 

理由はシンプルで、

現場が一番分かっているからです。

 


 

【外注に向いている領域とは】

 

一方で、

  • 業務全体の整理

  • データの流れの設計

  • ツール同士のつなぎ方

 

こういった部分は、

外部の視点が入った方がうまくいくことが多いです。

 

内部だけで考えると、

  • 今のやり方が前提になる

  • 無駄に気づきにくい

 

という傾向があります。

 


 

【外部は「作る人」より「整理する人」】

 

外注というと、

「システムを作ってもらう」イメージが強いですが、

実際に価値が出やすいのは、

 

  • 業務を分解する

  • つながりを整理する

  • どこを自分たちでやるか決める

 

という 整理役 としての関与です。

 


 

【もし切り分けで迷っていたら】

 

  • 内製と外注の境界が分からない

  • 丸投げになりそうで不安

  • まず何を整理すべきか知りたい

 

こういった 切り分けの相談 も受けています。

 

作業をお願いする前段階として、

考え方や設計を一緒に整理する

という関わり方もしています。

 

【「DX担当を置けば解決する」は危険】

 

業務改善やIT化が進まないと、

「DX担当を1人置こうか」という話が出がちです。

 

ただ、

これはかなりよくある失敗パターンでもあります。

 

【DXは「1人で進める仕事」ではない】

 

例えばDX担当としてBさんを採用したとします。

 

Bさんは、

  • 業務を聞きに行く

  • 現場に改善案を出す

  • システムを検討する

 

という役割を担います。

 

ただ現実には、

 

  • 現場は忙しくて話を聞く時間がない

  • 「今まで通りでいい」と抵抗が出る

  • 調整役がBさん1人になる

 

結果として、

Bさんが孤立してしまうケースが多いです。

 


 

【別の属人化が生まれる】

 

さらに問題なのは、

 

  • DXの内容をBさんしか把握していない

  • 判断が全部Bさん経由になる

  • 「Bさんに聞かないと分からない」状態になる

 

つまり、

DX担当という新しい属人化が生まれます。

 


 

【コストと役割の現実】

 

DX担当を雇うと、

  • 人件費は毎月固定で発生する

  • 効率化が一段落すると、役割が曖昧になる

 

「改善フェーズでは必要だが、

運用フェーズでは余る」

 

これは、実際によくある話です。

 

昨今はIT自体が非常にシンプルになってきているため、

ちゃんと全体像やマニュアルを整理していけば、

DX完了後は新規採用したメンバーをリリースするということもよくあります。

 

このようなことをするためには、業務委託や外注が選択肢にあがります。

 


 

【まず考えるべきは「進め方」】

 

だからこそ、

DX担当を置く前に考えるべきなのは、

 

  • 誰が意思決定するのか

  • 現場をどう巻き込むのか

  • 段階的にどう進めるのか

 

という 進め方そのもの です。

 


 

【もし悩んでいたら】

  • DX担当を雇うべきか迷っている

  • 外部に頼るべきか判断できない

  • 進め方に不安がある

 

こういった 検討段階の相談 も受けています。

 

採用ありきではなく、

一番無理のない進め方を整理する

という立場で関わっています。

 

もちろん、私が外注先として貴社のIT活用を支えていくことも可能です!