DXはなぜ歪むのか― 経営主導のはずの構想が、ITパートナと予算論理に引きずられる構造 ―

DXは、本来的には経営が「どのような企業に変わるか」を定義し、その実現手段としてITを位置づける営みです。

しかし、現実には、構想段階に参画するITパートナやコンサルの提案可能領域に影響されがちです。結果として、ERP刷新やAI導入といった“実行しやすいテーマ”に収束するケースが多いように見受けられます。

その背景には、技術ではなく「構想の主導権」と「予算獲得ロジック」という構造に問題があることが多いです。

---

本来DXは「経営が力点を決める活動」である

DXの出発点は、IT導入ではなく、「どのような競争力を獲得するか」を経営が定義することにあります。 しかしこの“当たり前の前提”が、しばしば曖昧になり、結果として、プロジェクトはシステム中心に再構成されてしまうことが多いのが実情です。

DXの本質は“構造の選択”である

DXの本質は、単なる効率化ではありません。むしろ、企業の構造そのものをどう変えるかという選択です。

例えば、次のような論点が大切になります：

• 意思決定は、どこで行うべきか
• どの業務境界をなくすべきか
• 顧客価値は、どのレイヤーで再定義されるべきか

これらはすべて「業務改善」ではなく「構造設計」の領域です。

DXの投資領域（3層構造）

DXの投資対象は、実務的には次の3層で整理できます。

本来は、このうちのどの層に戦略的に投資するかを経営が決定する必要があります。

しかし、現実には、Tier2やTier3に偏った投資が行われているように見えます。

DXは“IT選定”ではなく“構造設計”である

DXをIT導入の問題として捉えると、必ず歪みが生じます。

本来の順序は以下です：

1. 企業として変えるべき構造を定義する
2. 投資領域（Tier）を決める
3. 必要な技術・システムを選定する

しかし、実際のDXプロジェクトでは、この順序がしばしば逆転します。

---

しかし、現実のDX構想は「ITパートナ起点」で歪む

情報や経験の不足もあり、DXプロジェクトの構想検討をユーザ企業だけで進めることは、一般的に難しいです。そのため、ITパートナやコンサル会社の支援を求めることが多いと思います。しかし、結果として、本来あるべき議論から乖離してしまう例が多いように考えます。

大きな問題は「何を変えるべきか」ではなく、「何ができるか」をベースに議論が進んでしまうこと

この瞬間に、構想の主導権が実質的に移動します。

構想フェーズがすでに“提案可能領域”に制約されている

ITパートナやコンサル会社が提示できる領域は、彼らが提供できるソリューションの延長になりがちです。そういったソリューションであれば、知見が社内に蓄積されており、業務への貢献やシステム導入の難易度もよく分かっています。

そのため、ITパートナやコンサル会社からの提言は、再現性が高く、提案しやすい領域になります。更に言うと、ITパートナやコンサル会社の内部事情もあり、ITパートナやコンサル会社の次のビジネスになる方向に（彼らの提供できるソリューションが利用される方向に）、話が進みやすいです。

結果として、構想はこの枠内に収束していきます。

”説明可能なDX”がテンプレート化されている

また、こういった事例が蓄積されてくると、構想フェーズ完了時の説明資料も蓄積されていきますので、本当に効果が刈り取りできているかはともかく、とりあえずは、皆が納得するような説明ができてしまうようになります。

• 他社も、同じ枠組みでDXを進めている
• 同じようなDXのプロジェクトを、いくつも成功に導いてきた
• 〇〇のような効果を期待できる

そうして、本来は、ユーザ企業ごとに異なるべき収益構造改革や組織改革が、一定のテンプレートに集約されていきます。つまり、ユーザ企業のDXは、ITパートナやコンサル会社にとって「売れる形」に整理されていき、本質的な構造改革は後回しになっていきます。

---

予算獲得ロジックがさらに歪みを加速させる

DXの計画立案は、構造改革の戦略立案であると同時に、予算承認プロセスでもあります。そのため、「何が重要か」ではなく「何が通るか」が強い影響を持つことになります。

"必要なソリューション"ではなく、”説明しやすいソリューション”が選ばれやすい

DXにおいては、本来は、実現したい構造改革の姿が先にあり、それを可能にするためのソリューションが選ばれるべきです。しかし、多くの企業では、実現したい構造改革の姿が深掘りが浅いため、構造改革の姿→ソリューションという流れの説明が十分にできません。

そのため、構造改革に必要なソリューションではなく、説明しやすいソリューションが選ばれやすくなります。

いずれも、もっともらしい説明です。しかし、お気づきのように、ユーザ企業個別の深掘りはありません。実際には、もう少し個別業務の深掘りがされていることが多いですが、それでも構造改革というには浅いケースが少なくありません。それでも「他の企業がやっているから」ということで、承認されるプロジェクトがあるのが実情です。

投資ポートフォリオの偏り

その結果、多くのユーザ企業で、ERPなどの大きな投資が必要なソリューションか、AIのようにブームになっているソリューションに投資が偏りがちになります。

• ERP：　ITパートナやコンサル会社にとって、大きなビジネスになる
• AI：　ブームになっており、ITパートナやコンサル会社として提案しやすい

そのため、本来は構造改革のためのDXプロジェクトが、ERP導入プロジェクトやAI活用プロジェクトに矮小化されていくことになります。

そして、残念なことに、そういった変質に気づき、ユーザ企業内で声を挙げられる人も少ないのが実情です。多くのDXプロジェクトがIT部門任せとなる一方、IT部門は、DXを達成可能なプロジェクトにしなければいけません。そのため、構造改革プロジェクトという建付けよりも、実質的にはシステム導入プロジェクトに仕立てる方が安全だという心理が、無意識の間に働いているように思います。

---

DXは「IT投資最適化」に変質する

これまでお話してきたように、本来DXは経営構造の変革であるべきです。 しかし、実態としては、IT投資の組み合わせ最適化へと変質していくことが少なくありません。

DXがシステム導入プロジェクトの集合体になる

ERPやAIといった個別プロジェクトが並列に進み、それらの合計としてDXが語られるようになります。 しかも、全体構造の設計が欠落していることが多いです。

全体の大きな構造改革の姿が無い。もしくは、形だけのものとなっているからです。

多くのDXプロジェクトにおいては、構想フェーズの報告書で、部品としてのソリューションが列挙された後は、それぞれのソリューションごとのプロジェクトが走っていくようになります。

• ERP刷新プロジェクト
• SCP導入プロジェクト
• データ基盤導入プロジェクト
• データドリブン経営プロジェクト
• AI活用促進プロジェクト

それぞれにプロジェクトリーダが配置され、システムテスト等での合流ポイントを決めたのちは、ステアリングコミッティでの報告で一堂に介する以外は、基本的にはバラバラに運営されることが多いです。

カットオーバーが“成功”の定義になる

このように、いったんシステム導入プロジェクトに再定義されてしまうと、現場では、カットオーバー（稼働開始）が成功条件として扱われることになっていきます。

カットオーバーが目的になるため、その後の定量効果は十分にモニタされず、形骸化することも少なくありません。結果として、

「動いたから成功」

という評価構造が固定化されていきます。

---

本来あるべきDX構想のあり方

DXの本質を取り戻すためには、構想の出発点を完全に入れ替える必要があります。当たり前のことですが「ITから考える」のではなく、「変えるべき構造から考える」ことです。

まずは、“構造改革の姿”を明確にする

DXの目的は、トランスフォーメーションです。何をどのように構造改革するのかが、出発点であるべきです。

• 意思決定の所在や権限構造を、どう再設計するか
• 顧客との接点を、どう再配置するか
• 組織間・業務間の役割分担や境界を、どう再定義するか

これらの重大な経営方針に沿うように、IT投資は決定されていくべきです。しかし、ソリューション起点で語られていくことが多いのは、前述したとおりです。

では、どうするか。

IT部門主導から、業務部門主導へ

耳にタコができるほど、お聞きになったことがあると思いますが、業務部門主導でDXを考えることが重要です。

DXにおいては、目的は「トランスフォーメーション」であるものの、「デジタル」というワードが重く受け止められて、IT部門でないと対処できないと思われがちです。しかし、「デジタル」は手段でしかなく、大事なのは「トランスフォーメーション」の方です。そのため、業務部門が主導しなければいけない活動となります。

これまでお話してきたように、DX推進は、ユーザ企業単独では進めることができず、ITパートナやコンサル会社の支援が必要です。しかし、ITパートナやコンサル会社の参画は、ソリューションありきのDX計画になるリスクを生むことになります。

そういった際に、本来あるべき「トランスフォーメーション」を見失わないようにするためには、業務部門主導であることが欠かせません。

---

デジタル・トランスフォーメーションは、会社の構造改革を推進するための活動であるにも関わらず、業務部門の関りが限定的な場合は、驚くほど多いです。結果、IT部門主導のプロジェクトとなり、構造改革とは程遠い、単なるシステム導入プロジェクトに成り下がっているケースを、よく見かけます。

しかも、構造改革と銘打っているので、投資金額も大きいことが多いですが、ほとんど何も改革できずに終わっていることも、少なくありません。もちろん、曖昧な定性効果を集めて、成果があったことにしている場合がほとんどです。

どうしてそういった事態に陥ってしまうのか、本記事で説明させて頂いたような背景を理解頂き、真のトランスフォーメーションを達成して頂ければと思います。

最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。

ITプロジェクト研究会

---