現職もそうだが、DXが失敗する会社には、共通する“構造”がある。
……のではないか？
断言はしない。
でも、何度も同じ光景を見ると、そう思わざるを得ない。
私は中堅製造業で、
経営企画とITの間に立つような役割を担っている。
インフラ、セキュリティ、ツール導入、業務整理、会議設計。
気づけば、経営と現場とITの“翻訳”をする立場にいた。
その位置にいると、
会議の空気の揺らぎや、議論のズレが、妙によく見える。
今日は、犯人探しではなく、
その“構造”を書いてみたい。
※固有名詞は出さない。
※特定の個人を批判する意図もない。
※しかし、内容は実録である。
ツールは選ぶ。でも、設計はしない。
まず、よく起きることがある。
ツールの比較が始まる。
ベンダーが来る。
見積もりが出る。
機能一覧が並ぶ。
だが、そのとき決まっていないものがある。
- 誰が最終的に決めるのか
- 導入後の運用責任は誰が持つのか
- 例外やトラブル時の判断基準は何か
これが曖昧なまま進む。
そして導入後、揉める。
「ツールが悪い」と言われる。
「現場が使わない」と言われる。
「ITの説明不足だ」と言われる。
でも、それは本当にツールの問題だろうか。
設計されていなかっただけではないか。
“攻め”と“守り”を同時に議論すると、議論は壊れる。
会議では、こんな話が同時に出る。
- 売上を伸ばしたい
- 業務効率を上げたい
- セキュリティを強化したい
- 事故は絶対に避けたい
- 予算は限られている
全部正しい。
だが、ここで混ざる。
**攻めのIT（成長のための投資）**と
**守りのIT（絶滅を避けるための設計）**が。
攻めはROIで評価できる。
守りは「起きなかった事故」でしか評価できない。
評価軸が違う。
それを同じテーブルで同時に扱うと、議論は壊れる。
そして最後に、誰かが悪者になる。
レイヤーが混ざると、論点は移動する。
もう一つ、よく起きる現象がある。
レイヤーの混在だ。
- 経営レイヤー（何を目指すか）
- 業務レイヤー（どう回すか）
- システムレイヤー（何で支えるか）
- インフラレイヤー（どう守るか・繋ぐか）
本来は分けて考えるべき話が、
一つの会議で混ざる。
ネットワークの話をしていたはずなのに、
いつの間にか業務改革の話になり、
最後は「誰がやるの？」で止まる。
議論が進まないのは、能力の問題ではない。
構造の問題だ。
“正しいデータ”が複数存在する会社
現場のExcel。
部門の共有フォルダ。
業務ツール。
基幹システム。
それぞれに“正”がある。
すると起きる。
- 二重入力
- マスタ差異
- 数字が合わない
- 「どれが正しい？」という議論
ここで必要なのは、新しいツールではない。
**“正の定義”と“決める人”**だ。
私が呼んでいるもの ― EA-lite
私はこれを、壮大なEnterprise Architectureではなく、
あえてEA-liteと呼んでいる。
EA-liteとは、
事故るポイントを潰すための、最小限の構造設計
具体的には、
- 誰が決めるか
- 何のレイヤーの話をしているか
- どれが“正”か
- 例外はどう処理するか
これだけを、まず確実に決める。
これがあると、ツール選定は後からついてくる。
これがないと、どんな優れたシステムでも炎上する。
犯人は人ではない。
ここまで書いて思う。
DXが失敗するのは、
ツールが悪いからだろうか。
人が無能だからだろうか。
そうではなく、
失敗する構造が放置されている
……のではないか。
私は、犯人探しをしたいわけではない。
構造を設計したいだけだ。
※次回は、この「レイヤー分解」と「意思決定設計」が、
実は“育成”や“教育”にもそのまま効く、という話を書いてみたい。
