Contents
エグゼクティブサマリー
「DX推進室（やデジタル部門）だけが頑張って、他部署は“見学席”」という構図は、国内外の実在事例を眺めると“珍しい事故”ではなく、わりと再現性の高い現象として見えてきます。例えば、短期間で終了判断に至ったコード決済「7pay」は、攻撃手口（リスト型アカウントハッキング）を踏まえても、追加認証（例：二要素認証）の検討不足や開発体制・システムリスク管理体制といった「組織側の穴」も公式に言及されています（2019年、企業発表）。
また、みずほ銀行の相次ぐシステム障害を調査した第三者委員会は、共通の機械的原因だけでは説明できない“人為的側面”として、危機対応の組織力・IT統制力・顧客目線の弱さ、さらにそれが改善されにくい企業風土を指摘しました（2021年、調査報告書要旨）。
海外でも、事業拡大とシステム刷新が絡んだ失敗は「デジタルの問題」に見せかけて、データ・現場運用・意思決定の分断が主因になりがちです。ターゲットのカナダ事業撤退（2015年、企業発表／SEC提出資料）はその代表例で、報道ではSAP運用やデータ品質に苦しむ現場描写も残っています。
本稿は、こうした一次資料・一次報道・学術／専門家の指摘を踏まえ、「DX推進室が孤立する構造」を“断罪”ではなく“解剖”します。ポイントは、孤立は努力不足ではなく、組織設計と評価設計の帰結になりやすいこと。だからこそ、やり直し案も精神論ではなく、地味に効く現実策に寄せます。
導入
DXの失敗談って、だいたい最初は景気がいいんですよね。「全社横断で！」「データドリブンで！」「来期からアジャイルで！（※アジャイル＝細かく作って早く改善、のはず）」みたいな、カタカナが増えるほど、なぜか会議室の空気だけは“進んでる感”が出る。
で、数か月後。現場の人はこう言う。
「それ、うちの業務に関係あります？」
DX推進室はこう言う。
「あります（あるはず）…！でも、協力が…！」
外野（＝私）がこう言う。
「“協力が必要です”って言うプロジェクト、協力が不要だった試しないよね」
ここで重要なのは、笑い話に見えるこのズレが、当事者の能力や熱量の問題というより、むしろ“構造の問題”として起きやすいことです。大企業の変革研究でも、デジタル変革は技術導入だけでなく組織・戦略とセットで進むものだ、という整理が繰り返し出てきます。
よくある失敗パターン
以下は「特定の会社の内部事情を断定」するのではなく、公開資料に残る実在事例の論点を材料に、現場で起きがちな風景として“再構成”したものです（あるある化している時点で、だいたい皆どこかで見てる）。
まずパターンの前に、主役紹介。
DX推進室は、たいてい善人です。真面目で、勉強熱心で、夜も遅い。資料はきれい。スライドの余白が適切。ここまでは完璧。
問題は、その“完璧さ”が、孤立の始まりになることがある点。
「推進室が社内の島になる」
イノベーション拠点やラボが失速する典型として、戦略と接続されない／本体と整合しない、という指摘が出ています（2019年、Harvard Business Reviewの論考）。
DX推進室も同じで、別棟・別予算・別言語・別の成功指標になった瞬間、社内で“島”として成立してしまう。
島の中では、ちゃんと前に進みます。プロトタイプも出ます。実証（PoC＝試し作り）も増えます。ベンダーさんも頑張る。会議も増える。すると島の住民はこう思う。
「進んでる。進んでるぞ、これは」
一方、本土（現場）はこう思う。
「それ、いつ“うちの仕事”になるの？」
結果、推進室は“成果物を抱えたまま”、次の成果物を作りに行きます。島が栄えるほど、本土との距離が伸びる。あの、悲しい観光地化。
「急いで出した“新サービス”が、ガバナンスの請求書を連れてくる」
急いでリリースしたい気持ち、分かります。DXって「遅い＝負け」っぽい空気があるので。でも、急ぎ方を間違えると、あとで“まとめて利息”を払うことになります。
例えば、セブン&アイ・ホールディングスのコード決済「7pay」は、サービス開始（2019年7月）後に不正アクセス問題が表面化し、同年9月末で廃止が決定されました（2019年、企業発表／一次報道）。
企業発表では、攻撃手口は「リスト型アカウントハッキングの可能性が高い」としつつも、犯行を防げなかった要因として、認証レベル（複数端末ログイン対策や二要素認証の検討不足）、開発体制、システムリスク管理体制の3点に言及しています（2019年、企業発表）。
ここ、外野から見ると分かりやすい。
「“DX＝速く出す”の勝負で、セキュリティと統制を“後で足す”前提にしちゃったのでは？」
でも内側にいると、こう見える。
「大規模グループで関係者が多い。調整が大変。期限もある。完璧は無理。まず出して改善しよう」
この「まず出して改善」が成立するには、改善する体制（権限・予算・責任）が最初から揃っている必要がある。揃っていないと、“まず出す”が“出しっぱなし”になります。7payの場合、提供継続が困難と判断された経緯も、一次報道にまとまっています。
「データ移行は“誰かがやる”と思うと、誰も勝てない」
DXの現場でよくある誤解があります。
アプリや画面の話をしているうちは、皆テンションが上がる。
データの話になった瞬間、皆テンションが下がる。
そして会議はこう締まる。
「データ整備は別途検討で」
別途検討、万能。私も好きです。逃げ足が速い。
ただ、データは“別途検討”にすると牙をむきます。ターゲットのカナダ事業撤退は、戦略・出店・サプライチェーンなど多因子ですが、企業側は2015年にカナダ事業中止を公表し、法的整理（CCAA）手続きに入ったことを明確にしています（2015年、企業プレスリリース／SEC提出資料）。
加えて、カナダの一次報道（元従業員らへの取材記事）では、SAPの扱いを“玉ねぎの皮むき”に例える現場の声や、データ品質を改善する仕組みを後追いで導入していった様子が描写されています（2016年、Canadian Business）。
ここで起きがちな“現場の風景”はこう。
推進室：「新しい基幹システムで可視化・最適化します！」
現場：「で、マスタ（商品情報）誰が直すの？」
推進室：「…各部門で…」
各部門：「…誰が…」
そして、誰も嫌な人はいないのに、データが嫌な顔をし始める。
ちなみに日本の文脈でも、既存システムが事業部最適を優先して複雑化し、全社最適のデータ利活用が難しくなる、という“構造の説明”が公的資料にあります（2018年、経産省DXレポート資料）。
これ、要は「部門ごとに頑張った結果、全社で詰む」問題です。頑張りが悪いんじゃない。頑張りの方向が分断されていただけ。
「“デジタル部門”がスケール調整に入るとき、だいたい本体との温度差が露出する」
海外のデジタル投資で象徴的なのが、GEの産業向けIoT／ソフトウェア戦略（Predix等）です。2017年の投資家向け説明の記録では、当時のCEOがデジタルへの投資は続けつつも、支出を約4億ドル削減すると述べています（2017年、投資家向けアップデートのトランスクリプト）。またReutersは、Predixの技術的問題やスケジュール遅れ、戦略の軌道修正を報じています（2017年、Reuters）。
この種の話がなぜ“DX推進室孤立”と相性がいいかというと、デジタル部門は「横展開できるプラットフォーム」を作りたがり、本体の事業部は「今期の受注と顧客」を見ているからです。
推進室：「共通基盤です。将来効きます」
事業部：「今、顧客が怒ってます」
どっちも正しい。でも、正しい者同士が会話の語彙と評価軸を共有していないと、最後に残るのは「頑張った記録」だけになります。
なぜ失敗に気づけなかったか
ここが本題です。「なぜそうなったか」を、外野の意地悪さでなく、構造として分解します。
大きく言えば、DX推進室が孤立する組織では、失敗が“見えにくくなる仕掛け”が最初から組み込まれています。
まず、失敗が見えないのは「問題が起きていないように見える」からです。経産省のDXレポート関連資料は、レガシー問題が潜在化しやすく、現状が動いている間は自覚しにくいこと、将来リスクは説明しにくく「誰も困っていない」ため先送りされやすいことを指摘しています（2018年、公的資料）。
この“誰も困ってない”は強い。組織の防御力を最大化します（変わらないための）。
次に、分断は制度で強化されます。多くの変革がコケる理由として、部門サイロ、リスク回避、顧客の単一視点を作れない、といった文化・組織面を挙げる調査結果があります（2017年、McKinseyのサーベイ論考）。
サイロがあると、DX推進室は“横串”のつもりでも、現場から見ると“斜め上から串を刺しに来た人”に映る。串は刺さるけど、刺さった先で焼けない。
さらに、評価制度が“孤立の報酬”を生むことがあります。
推進室の評価：PoC数、資料完成度、会議開催数（※言ってないだけで、だいたいこれ）
現場の評価：売上、コスト、事故ゼロ、監査対応
この状態で「全社を変えろ」は、競技ルールが違うスポーツを同じ得点板で採点するようなものです。誰が悪いというより、審判がいない。
加えて心理的な要因。
「今さら止められない」
「社長案件だし」
「反対すると“変革に消極的”扱いされる」
このへんは、どこの会社にもいる“空気の総務”が書類を回してくる。
そして実際に大きな事故が起きたときに、組織の弱点が露出します。みずほの第三者委員会報告は、危機事象に対応する組織力の弱さ（横・縦の連携不全）や、受動的姿勢、事前シミュレーション不足、システム部門との連携不足などを具体的に挙げています（2021年、調査報告書要旨）。
さらに行政側も、システムの安定稼働に必要なガバナンス態勢の整備などを含む業務改善を求めています（2021年、金融庁の行政対応）。
つまり、失敗に気づけないのは「能力が低いから」ではなく、
気づかないまま前に進める設計（予算・評価・分業・空気）ができているから、です。
もしやり直せるなら
理想論を言うのは簡単なので、ここは“現実的に効く地味な手当て”に寄せます。ポイントは、DX推進室を強化するより「孤立しない前提」を会社側が用意することです。
最初にやるべきは、DX推進室を“プロジェクト実行部隊”として増員することではなく、事業側に「これは自分の仕事だ」と言わせる設計を作ることです。イノベーション（新しい取り組み）が戦略と接続されないと失速する、という論点は繰り返し指摘されています（2019年、Harvard Business Review）。
なので、「推進室がやる」ではなく「事業がやる、推進室が伴走する」へ、言葉だけでなく予算と責任を移す。
次に、“成果”の定義を変える。PoCの数ではなく、採用（現場で使われたか）と運用（事故なく回ったか）で測る。7payの件は象徴的で、攻撃手口の想定と、それに耐える認証・リスク管理体制が揃わないと、スピード優先は後から重い請求書になる、という教訓を公開資料が示しています（2019年、企業発表）。
「作ったら勝ち」ではなく「使われ続けたら勝ち」。地味ですが、これが一番効きます。
そして、データと基幹は“後で”にしない。経産省資料は、既存システムの複雑化・ブラックボックス化や、事業部最適が全社最適のデータ利活用を阻む構図を示しています（2018年、公的資料）。
ターゲットのカナダ事業では、撤退という結果自体は企業発表で確定しており（2015年、企業プレスリリース）、報道ではSAPとデータ品質に関わる“泣ける現場話”が残りました（2016年、Canadian Business）。
ここから言える現実策は、「データ整備担当を“善意の持ち回り”にしない」こと。役割として固定し、期限と権限を与え、やらないと困る状態を先に作る。善意は枯れますが、役割は残ります。
最後に、危機対応の訓練を“イベント”にしない。みずほの第三者委員会が挙げたように、受動的姿勢や事前シミュレーション不足、部門連携不足は、事故のときにまとめて噴きます（2021年、調査報告書要旨）。
DXは新しい仕組みを入れるので、事故が起きる確率はゼロにはなりません。だからこそ、「事故が起きたときに誰が何を決めるか」を先に決める。これは根性論ではなく、運用設計です。
まとめ
DX推進室が孤立する話は、だいたい“熱量の裏切り”として語られます。
「推進室が暴走した」
「現場が抵抗した」
「経営が分かってない」
でも、一次資料・一次報道・公的報告に当たるほど、見えてくるのは別の顔です。
孤立は、個人の失策というより、分業・評価・ガバナンスが“そうなるように”組まれていた結果として起きやすい。だから、正しく直すなら、推進室に気合を入れるより、会社側が“孤立できない構造”を作る方が早い。
最後に、外野からの優しい皮肉をひとつ。
DX推進室が孤立している会社は、たいてい「人はいい」んですよ。皆、礼儀正しい。会議も丁寧。だからこそ言いにくい。
「それ、島の中だけで盛り上がってません？」
言いにくいことほど、早めに言ったほうが安い。DXの請求書って、いつも“後払いの利息付き”なので。
コメント