DXが止まるのは技術のせいではない｜IT経営の4ステージで読み解く「学習と経営の役割」
こんにちは。 ライジングサン・システムコンサルティングの岩佐です。
前編では、DXが停滞しやすい背景を、IT経営の4ステージという切り口で整理しました。 本編ではその続きとして、IT経営ステージ2からステージ3へ進もうとする局面で、何が起きやすいのかを掘り下げます。
結論から言うと、DXが育つかどうかを分けるのは、作るシステムの大きさではありません。 DXプロジェクトを、学習しながら育てていける形で設計できているかどうかです。
本記事で扱うDXは、壮大なビジョンや最新テクノロジーの話ではなく、DXを前に進めるためのIT投資の進め方です。 そこで本記事では、DXを整理するフレームとして IT経営の4ステージ を使います。
IT経営の4ステージ
- ステージ1：個別最適（デジタル化・ツール導入）
- ステージ2：部分最適（部門単位で成果が出る）
- ステージ3：全社最適（部門横断でつなぐ）
- ステージ4：事業変革（競争力の源泉になる）
※IT経営についてより詳しく知りたい方は、前編をご参照ください。
1.DXの話は、なぜいつも戦略から始まるのか
DXという言葉が教科書的な文脈で語られるとき、その入口は戦略論になります。これは、DXプロジェクトを全社的な取り組みとして進めようとすれば、ごく自然な流れです。
戦略の話になると、人は無意識のうちに大きな絵を描き始めます。
もちろん、それは間違ったものではありません。むしろ、DXに本気で取り組もうとすればするほどビッグピクチャーを描きたくなるのは自然なことでしょう。
2.大きな戦略が、なぜ動かなくなるのか
ところが、こうして描かれた立派なDX戦略が、現場に降りてきた瞬間から、少しずつ動かなくなる。
計画は正しそうに見える。 やるべきことも整理されている。 投資額も、それなりに覚悟を持って決めている。
それでも、なぜか前に進まない。
2-1. 小さな成功体験が積めず、前に進んでいる実感を持ちにくい
理由のひとつは、大きなゴールであるがゆえに、今、何ができたのかが分かりにくいことにあります。 結果として、現場に前に進んでいる実感が残らず、小さな成功体験が積み上がりません。
2-2. 非連続的な変化により、最初の計画が無意味化してしまう
もうひとつは、変化のスピードです。 特に生成AIの実用化以降、テクノロジーの進化は非連続になり、数年前の前提があっさり覆ることも珍しくありません。
だからこそ、最初に描いた計画を忠実に実行するほど、ズレが大きくなってしまう。 そういう環境になっています。
3.だからこそ、戦略そのものも小さくはじめる
こうした背景を踏まえると、DXの現場でよく聞く次の言葉は、決して逃げではないことが分かります。
3-1. 小さく始めるとは、最初から完璧を求めないという意思決定
PoCやスモールスタート、MVPといった言葉が使われることもありますが、重要なのは手法ではありません。 本質は、最初から完璧を求めないという意思決定にあります。
そして、小さくすべきなのはシステムだけではありません。戦略そのものも、小さくはじめる必要があります。 最初に描く戦略は、完璧である必要はありません。むしろ重要なのは、次の3つです。
- 現実に触れながら修正できること
- 小さな成功や失敗から学べること
- 次の意思決定につながる材料が得られること
変化の激しい時代に、正しい戦略を一度で描くのは難しい。 であれば、最初から固定するのではなく、試しながら育てていく前提で戦略を設計するほうが現実的です。
3-2. ただ小さく始めるだけでは、DXは止まる
ただし、小さくはじめること自体は正しくても、進め方を間違えるとDXは簡単に止まってしまいます。
小さくはじめたDXが、なぜその先に進めなくなるのか。 育たないDXと育っていくDXの違いは、どこにあるのか。
ここから先で、その構造を整理していきます。
4.IT経営ステージ2で踏みがちな、3つの落とし穴
DXを小さくはじめると決めたとき、多くの企業が最初に取り組むのは、具体的なIT施策です。
業務効率化のツール導入、部門単位の業務システム、既存業務のデジタル化。IT経営ステージ2は、どうしてもこうした目に見える取り組みから始まります。
このとき議論されがちなのは、何をやるか（What）です。
しかし同じくらい重要なのが、どうやって進めるか（How）です。
Howを誤ると、DXは最初の一歩で止まります。
ここでは、IT経営ステージ2で特に起こりやすい3つの落とし穴を整理します。
4-1. 落とし穴① 一括請負契約
DXの初期フェーズでよく選ばれるのが、要件を固めて一括で発注する進め方です。
成果物、スケジュール、金額をあらかじめ決める。いかにも安全で管理しやすく見えます。
ただしこの形は、次の構造を生みやすい。
- 作る過程が見えにくく、判断の材料が残らない
- 想定とズレても、途中で修正しづらい
- 完成するまで、学びが社内に蓄積されない
結果として残るのはシステムだけで、DXに必要な学習結果としてのナレッジは社内に残りません。
4-2. 落とし穴② 多重下請け構造
一括請負とセットで起きやすいのが、多重下請け構造です。
発注元と実際に手を動かす人の距離が遠くなり、全体を理解する人が見えなくなっていきます。
この構造では、
- 業務理解が分断され、認識のズレが修正されにくい
- 問題が起きても原因が追えず、改善が回らない
といった状況が生まれがちです。
その結果、DXはブラックボックス化し、社内にはコントロールできないものとして残ります。
4-3. 落とし穴③ ウォーターフォール
最初に計画を固め、その計画どおりに最後まで進める。
ウォーターフォールは、要件が安定しているなら有効な場面もあります。
しかしIT経営ステージ2の現場は、
- 何が正解かが、まだ分かっていない
- やってみて初めて見える課題が多い
- 前提条件が途中で変わる
という状況がほとんどです。
それにもかかわらず計画どおりに進めることを優先すると、ズレに気づいても立ち止まれず、正しくないかもしれない道を走り切ることになります。
4-4. 3つに共通する問題：学べない構造
この3つに共通しているのは、失敗してもその失敗から学べない構造になっていることです。
そして最後に、こんな言葉だけが社内に残ります。
ITって、金がかかるばかりで、結局何の役にも立たないよね
これはITの問題ではありません。
学習と意思決定が社内に残らない進め方を選んでしまった、DXの問題です。
まずは、IT経営ステージ2を正しく踏み出すこと。
深掘りや属人化といった次の課題は、その先で初めて向き合うべきテーマなのです。
5.では、この3つの落とし穴を避けるにはどうすればいいのか
5-1. 避けるべきは手法ではなく、学習が残らない構造
ここまで読むと、こんな疑問が浮かぶかもしれません。
では、一括請負やウォーターフォールは、すべて避けるべきなのか？
答えは、必ずしもそうではありません。
問題は契約形態や開発手法そのものではなく、採用した結果、ユーザー企業側に学習が残るかどうかです。
たとえば一括請負であっても、ユーザー企業がプロジェクトを主体的にグリップし、意思決定の理由や設計の背景を理解できていれば、それはDXに必要な学習として成立します。
つまり、避けるべきなのは手法ではなく、学習と判断が社内に残らない構造です。
5-2. IT経営ステージ2で本当に必要な成果物
IT経営ステージ2で求めるべき成果は、必ずしも完成したシステムではありません。
むしろ重要なのは、次の意思決定につながる判断材料です。
- どこが分かっていて、どこが分からないのか
- どの仮説が正しく、どこがズレていたのか
- 次に、何を試すべきなのか
最初のDXは、業務をすべて変えるためのものではなく、変えるための学習と成功体験を積み重ねるプロセスだと捉えるほうが実態に近いでしょう。
5-3. 最初のDXは学習装置として設計する
この視点に立つと、IT経営ステージ2の進め方は少し違って見えてきます。
- 小さく試せること
- 途中で立ち止まり、修正できること
- なぜそう判断したのかが、言葉として残ること
これらが満たされていれば、採用する技術や手法は一つである必要はありません。
重要なのは、DXを一度きりの投資ではなく、学習し続けるための仕組みとして設計できているかどうかです。
この前提があって初めて、DXはIT経営ステージ3へ進む準備が整います。
6.IT経営ステージ3とは何か、そしてなぜ止まりやすいのか
IT経営ステージ3を、あえて端的に表現すると、全社最適です。
IT経営ステージ2が、個別業務や特定部門の改善だとすれば、
IT経営ステージ3は、その成果を前提にしながら、部門を越えて会社全体として最適な状態をつくろうとするフェーズです。
6-1. なぜIT経営ステージ3へ進む必要があるのか
ここで、あらためて問い直しておきたいことがあります。
そもそも、なぜDXはIT経営ステージ3へ進む必要があるのか？
その理由は、シンプルな一言で表現できます。
全体は、部分の総和以上である。
IT経営ステージ2では、業務システムA、B、Cのように、部門や業務ごとに改善が進み、それぞれに導入効果が生まれます。
しかし分断したままでは、得られる価値は結局、次の範囲にとどまります。
Aの効果 + Bの効果 + Cの効果
IT経営ステージ3が目指すのは、仕組みやデータを有機的につなぐことで、部分の総和を超える価値を引き出すことです。たとえば、
- 部門をまたいだ意思決定が速くなる
- 個別最適では見えなかった改善が可能になる
これこそが、DXをIT経営ステージ3へ進めることが、企業にとって意味を持つ理由です。
6-2. 補足：ステージ2に留まる判断もありうる
ここで、もう一つだけ補足しておきます。
もちろん、現時点でIT経営ステージ2に留まるのも立派な経営判断です。
ただ本記事は、IT経営ステージ3へ進みたい企業に向けて話を進めます。
7.IT経営ステージ3で踏みがちな、3つの落とし穴
IT経営ステージ3は全社最適を目指すフェーズです。
しかしその一方で、現場で成果を出してきたやり方や成功体験が、次のステージへの移行を難しくしてしまう場面も少なくありません。
ここでは、IT経営ステージ3で特に起こりやすい3つの落とし穴を整理します。
7-1. 落とし穴① 部分最適の深掘り
IT経営ステージ2で成果を出した業務やシステムは、どうしても注目を集めます。
ここまでうまくいったのだから、もっと作り込もう
この部門のやり方を、さらに洗練させよう
その判断自体は、間違っていません。
しかしその結果、改善の方向が特定業務の深掘りに偏り始めると、全社最適からは少しずつ距離が生まれます。
部門内では完成度が高まっている。
一方で、他部門とのつながりは後回しになる。
その結果、問題は「つながらない」ことだけでは済まなくなります。
ソフトウェアとしての柔軟性が、少しずつ失われていくのです。
特定業務に最適化された設計は、目の前では使いやすい一方で、他部門との接続や将来の変更を前提にしていません。
そのまま改善を積み重ねると構造は複雑になり、小さな変更にも大きなコストがかかるようになります。
こうして蓄積されるのが技術的負債です。
その結果として、ステージ2で成果を出した仕組みは、柔軟性を失った部分最適の集合体になってしまいます。
7-2. 落とし穴② 内製の属人化
7-2-1. 内製化は「学習」という意味で望ましい
IT経営ステージ3へ進もうとする企業の中には、すでにソフトウェアの内製化によって、IT経営ステージ2をうまく回してきた会社もあるはずです。
これは、ここまで繰り返し述べてきた「学習」という観点では、むしろ望ましい取り組みです。
現場に近い人材が改善し、意思決定の理由や設計の背景が社内に残る。スピードも出る。DXとして健全な兆候だと言えます。
7-2-2. ただしステージ3では「ボトルネック」に変わることがある
ただし、この内製が、IT経営ステージ3では弊害になることがあります。
ステージ3では部門を越えて全体をつなぐ必要があり、設計や運用の整合、利害調整、意思決定の枠組みが欠かせないからです。
つまり、ステージ2では武器だった取り組みが、ステージ3に入った瞬間にボトルネックに変わる。
これが、内製の属人化という落とし穴の正体です。
内製が次の状態になると、属人化は一気に進みます。
- 特定の個人に強く依存している
- 設計意図や判断理由が共有されていない
- その人がいないと、手を出せない
属人化した内製はスケールしません。
全社最適を実現するどころか、次のボトルネックになってしまいます。
7-2-3. エース離脱は「起きうる前提」で設計する
さらに深刻なのは、内製化を牽引してきたエースが、ある日いなくなる可能性があることです。
実際、私たちは「内製化を牽引してきたエースが抜けた途端に、DXが止まった」ケースを見てきました。
人材の少ない中小企業で、特定の人物に推進が集中するのは、ある意味で構造上避けにくい現象です。
問題は誰かが組織を去ることではありません。問題は、その人が去った瞬間にDXが止まってしまう構造にあります。
だからこそ、IT経営ステージ3では「エースがいること」を前提にするのではなく、人が入れ替わっても学習と意思決定が継続できる構造を持てているかが問われます。
7-2-4. 評価制度を変えられるのは経営層だけ
そして、ここにはもう一つの落とし穴があります。
事業会社の内製エンジニアは、どれだけ成果を出しても、技術力そのものが評価軸に乗りにくい。結果として、給与や処遇に反映されず、「このまま社内で頑張るより、開発会社に移った方が評価される」という判断が起きやすくなります。
これを止められるのは、現場ではありません。
内製人材の給与や処遇、評価制度を動かせるのは経営層だけです。
だからこそIT経営ステージ3では、内製化の推進そのものだけでなく、内製人材が報われ続ける仕組みまでを含めて設計する必要があります。
そうしなければ、優秀な人材が育つほど、組織は不安定になります。
7-3. 落とし穴③ 社内政治と意思決定の壁
IT経営ステージ3で、最も見えにくく、そして影響が大きいのが、社内政治と意思決定の問題です。
部門をまたぐデータ連携や業務変更には、必ず利害の調整が伴います。
そして、次の問いが必ず立ち上がります。
- どの部門が主導するのか
- 誰が最終的に決めるのか
- 既存ルールを変えてよいのか
これらに答えが出せないままでは、DXは前に進みません。
現場は動いている。技術的にも、できることは増えている。
それでも止まってしまうのは、意思決定のレイヤーに手が届いていないからです。
7-4. なぜこのフェーズは現場だけでは超えられないのか
IT経営ステージ3の落とし穴は、失敗したから起きる問題ではありません。
むしろ、ある程度うまくいったからこそ表面化する問題です。
だからこそ、このフェーズは現場の努力だけでは乗り越えられません。
DXを全社最適へと進めるために次に必要なのは、技術ではなく、意思決定そのものの変化です。
8.IT経営ステージ3を超えるために必要なこと
ここまで見てきたとおり、IT経営ステージ3で立ちはだかる課題は、技術の問題でも、現場の努力不足でもありません。
部分最適が深まり、内製が属人化し、部門間の調整が進まなくなる。
これらに共通しているのは、現場では決めきれない問いに直面しているという点です。
- どの業務を、優先的につなぐのか
- 部門間で発生する不利益を、誰が引き受けるのか
- 将来の柔軟性と、目先の効率をどうバランスさせるのか
これらは、現場の裁量や善意だけでは答えを出せません。
8-1. 必要なのは技術ではなく、意思決定の主体
IT経営ステージ3を超えるために必要なのは、新しい技術でも、より優秀なエンジニアでもありません。
意思決定の主体を、はっきりさせることです。
言い換えると、DXを全社最適のフェーズへ進められるのは、経営しかありません。
8-2. 経営の役割：トレードオフを引き受ける
ここで言う経営とは、単に予算を承認することではありません。
トレードオフを引き受ける意思決定者として関与することです。
- どこまで踏み込むのかを決める
- 部門間の壁を越える判断を下す
- 短期的な不満や混乱を引き受ける
「どこまで踏み込むのか」を決めるとは、システム化の範囲を決めるという意味ではありません。
投資・固定化・将来の自由度のトレードオフに向き合うことです。
- 何に、どこまでお金と時間をかけるのか
- 何を、どのレベルまで仕組みとして固定化するのか
- その結果、将来どんな身動きの取りにくさが生まれるのか
この身動きの取りにくさは、技術的負債、部門間の不公平感、運用負荷といった形で表面化します。
これらを理解したうえで、それでも踏み込むのか、あるいは、あえて踏み込まないのかを決める。
この判断は、現場の努力や善意だけでは成立しません。
トレードオフを引き受ける覚悟を持った、経営の意思決定が必要になります。
DXは、一度きりのプロジェクトではなく、問い直し続ける経営のプロセスです。
だからこそ、IT経営ステージ3を超えるために必要なのは、現場にもっと頑張ってもらうことではなく、経営がDXの当事者になることなのです。
8-3. 次のステージ（IT経営ステージ4）へつなぐ
この関与があって初めて、DXは次のステージ（IT経営ステージ4）──事業そのものを変えるフェーズへと進んでいきます。
9.まとめ
この記事では、DXプロジェクトを、多くの中小企業の企業文化にマッチする 「小さくはじめて大きく育てる」 という考え方で捉え直しました。
そして、そのアプローチでプロジェクトを進める際に起きやすい 落とし穴 と、そこから抜け出すための 解決策 を解説してきました。
DXを小さくはじめること自体は、正しい選択です。
ただし重要なのは、何を作るかではなく、学習と意思決定が社内に残る進め方になっているかどうかです。
IT経営ステージ2では、契約形態や手法よりも「学べる構造」をつくること。
そしてステージ3では、部分最適の深掘りや社内政治に加え、内製化が属人化し、エース離脱でDXが止まるリスクにも向き合う必要があります。特に事業会社では、技術力が評価に反映されにくく、人材が報われない構造が離脱を招きます。
だからこそ、評価制度まで含めて設計できる経営が当事者になることが、ステージ3を超える鍵になります。
