「小さく始めましょう」と念を押したはずのDXプロジェクトが、いつの間にかキング・コング級に巨大化して破綻する――。そんな話を聞いたことはありませんか？例えば、FA（ファクトリーオートメーション）界の雄・ファナックは、自社IoTプラットフォーム(Field system)や富士通・NTTコミュニケーションズとの合弁会社で製造業向けDXを推進しましたが、利用は伸び悩み、合弁会社はわずか4年でひっそり解散してしまいました。また、ある自動車部品メーカーでは数億円を投じた生産管理システム刷新が現場にまったく定着せず、結局古い紙の管理と併用する羽目になっています。こうなると、外から見れば「だから最初から地道に進めろと言ったのに…」という気分ですが、中にいると当事者は別の事情が見えているものです。今回は「いつの間にか巨大化して死んだDX」というお題で、実在の失敗事例と専門家指摘をもとに、なぜこうなったのかを構造的に解説してみましょう。
Contents
よくある失敗パターン
DXプロジェクトが尻すぼみになるケースには、いくつか共通のパターンがあります。ここでは典型的な失敗パターンを挙げ、現場で何が起きていたかを解説します。
パターン1: スコープが肥大化して頓挫する
「まさかこんなに大きくなるとは…」というスコープクリープのパターンです。本来は生産ラインの一部改善などスモールスタートのはずが、いつの間にか対象範囲が拡大し、予算と開発量が膨れ上がります。ある製造業メーカーでは当初６ヶ月の予定だったDX計画が要件追加の連続で２年以上に延長され、費用はなんと3倍に膨れ上がってしまいました。別の中堅製造業では、生産管理システム更新のプロジェクトが当初予算の3倍、期間も2倍以上に膨れ上がった末に頓挫しました。原因は、「ついでにあれもこれも」を繰り返した結果、当初の“お試し”レベルの想定を大きく超えてしまったことです。後から社外の目で見ると、「何もここまで盛り込む必要があったのか」と突っ込みたくなる過剰投資ぶりですが、社内では「あれもやったほうがいい」「こっちも改善すれば効果が上がる」とどんどん盛り上がってしまうのです。
パターン2: 現場無視のトップダウン導入
経営判断で一気にシステムを入れ替えたものの、現場の使い勝手が無視されて頓挫するパターンです。例えば、ある製造業B社では経営陣の号令で生産管理システムを刷新しましたが、現場の作業フローをほとんど確認せずに導入を進めたため操作が複雑になり、現場社員は旧システムと紙を二重に使い続ける事態に…結局、新システムは形骸化してしまいました。現場で「これは使えない」と判断されると、導入効果は一気に吹き飛びます。他にも前述の自動車部品メーカーなどでは、新システムを入れたにもかかわらず、現場は本音では紙管理を続行。結局DXツールは装飾のような存在に終わってしまいました。これはつまり、「うちの現場はこうだからダメだ」といった温度差が問題になる例です。
パターン3: 人材・リソース不足で計画倒れ
最先端技術を導入しても、それを使いこなせる人材や運用体制がなければ宝の持ち腐れになります。DX推進担当に専門のITエンジニアが一人もいないせいで、計画が途中で停滞した事例すら報告されています。要するに、技術選定や開発を外部に丸投げし、社内にナレッジが残っていない。問題が発生しても解決できずプロジェクトが凍結、なんて悲劇が起きてしまいます。また、IoTセンサーでデータを取集しても、そのデータを解析できる人材がいなければ「データの墓場」になるだけです。実際、ある精密機器メーカーは生産ラインにIoTを導入しましたが、収集したデータを分析できる人手がおらず、結局そのデータは活用されずに埋もれてしまいました。新しいツールを導入するだけでは不十分で、それを駆使する人が不可欠なのです。
パターン4: ROI（投資対効果）を見誤った過剰投資
投資した分のリターンが得られないと分かった途端、プロジェクトは一気に縮小・凍結されます。導入コストに見合う効果が出る前に、機能をむやみに詰め込んだり短期間で効果を求めすぎたりして、費用だけが膨らむケースは少なくありません。例えばある企業では、導入に多額の投資をしたもののROIが期待を下回り、経営が見切りをつけてプロジェクト継続を断念しました。さらに、パッケージソフトを機能過剰にカスタマイズするとアップデートごとに保守コストがかかります。富士通の調査では、導入システムの約40%の機能が実際には使われておらず無駄になっているとも言われています。投資前に効果をシミュレーションし、必要最低限の機能だけで段階導入するなど、ROI重視の堅実な進め方が欠かせません。
なぜ失敗に気づけなかったのか
では、当事者はなぜここまで杜撰なプロジェクトに気づけなかったのでしょうか。実は多くの組織には「見えない盲点」があります。まず組織構造や文化です。欧米のDX成功事例では、現場を巻き込むボトムアップ型の推進が重要視されますが、日本企業ではトップダウンで号令をかける例が多く、現場の声が埋もれがちです。実際、米IBMの調査では、成功した企業の83%は現場巻き込み型のプロジェクト体制をとっており、これに対し凡庸な組織では多くが経営命令型でした。さらに、多くの企業では短期的な業績数値が評価基準になっており、中長期のDXプロジェクトは評価がされません。つまり「目に見える売上が上がらないなら不要」といった空気が根強く、誰もがどこかでプロジェクト継続に疑問を抱えていても口に出せないのです。
また、心理的な抵抗も大きな壁です。新しい仕組みによって長年培ってきた自分の仕事の価値が変わってしまうのでは、という変化への恐れが現場に広がります。ある調査では企業の67%が「組織文化・心理的抵抗」をDX推進の障壁に挙げています。加えて、日本企業には「失敗は恥」という完璧主義や年功序列型組織の風土が根付いています。経営トップも往々にして「DXをやっている自分」を示したがりますが、現場で失敗の芽が出ても誰も責任を取らないし、「とにかく進めれば何とかなる」と先送りしてしまう傾向があります。外野からは「議論している暇があったら即止めればいいのに」と見えますが、当事者は「もうここまで来たら引けない」と誤ったコミットメントに縛られているのです。
もしやり直せるなら
では、もしあのプロジェクトをやり直せるなら、現実的にどこを改めればいいでしょうか。まずはやはり段階的な導入です。マラソンでいきなり全力疾走すれば倒れますから、大規模導入ではなく一ラインや一部門から小さく始め、成功体験を積むことが重要です。例えばIT整備士協会も指摘するように、ソニーは部門ごとに小規模プロジェクトを立ち上げて成功事例を共有し、抵抗感を和らげました。同様にコマツでは現場作業員自ら業務課題を可視化し、デジタルツールを使って改善提案を増やす取り組みが功を奏しています。次に組織体制です。成功企業の70%以上は部門横断のプロジェクトチームを組んでいたことがわかっています。社内のサイロを壊して現場×管理部門×IT部門の壁をなくし、意思決定プロセスをスリム化すれば、問題発生時にも迅速に対応できます。また経営層も座っているだけでなく現場に足を運び、DXの意義と具体的ビジョンを自ら示すことが重要です。
さらに、評価と訓練も見直しましょう。DXは短期的な結果を求めすぎると失敗します。社内の評価制度を中長期的な成果や挑戦を評価するものに変え、少々リスクを取っても評価される文化に転換すること。併せて、全社員へのデジタルリテラシー教育を充実させ、技術に対する心理的な壁を下げることも有効です。必要なら外部パートナーの知見を借り、手探りでは時間ばかり消費せずに済むようにします。最後に成果をしっかり見える化する仕組みを作り、KPIに基づいて改善を繰り返します。要は「ムダな機能を盛り込まない」「無理に短期成果を求めない」「現場が実際に使えるシステムに絞る」といった原則に立ち返れば、理想論すぎず現実的な着地が見えてきます。
まとめ
DXの失敗から学べる最大の教訓は、「DXそのものが目的ではなく、本来の業務や組織を変えるプロセスである」ということです。今回のような巨大プロジェクトの破綻例を振り返ると、技術よりも人・目的・段取りがいかに重要かがわかります。「小さく始めるはずが大きく失敗したDX」は笑い話に聞こえるかもしれませんが（笑）、そこには必ず改善ポイントが隠れています。たとえば、当初は象を動かそうとして詰んでしまったとしても、ニワトリサイズの試みから始めれば次は動くかもしれません。失敗は悔しいですが、それを生かせば次回は必ず手堅い成功に近づきます。ともあれ、巨大なDXプロジェクトが死んだ後の職場はちょっとした笑い話になるもの。笑えるうちに「次はどうすべきか？」を考え、学びに変えていきましょう。
コメント