野村です。情報システム部門や情報システム子会社にDXを推進させる、という戦略がありますが、それは、とてつもなく大変なことなのです。無理だから諦めろというつもりも、情シス自体を変革しろというつもりもありません。ただ、共感的理解を示す必要はあると考えています。
1. DX停滞の核心：最大の障壁は社内にある
デジタルトランスフォーメーション（DX）の推進が、多くの日本企業で停滞しています。経営層は新たなクラウド技術やAIへの投資を促す一方で、現場では依然として「Excelマクロ依存」や「無意味なセキュリティポリシー」、参加人数のやたら多い開発会議・進捗会議、紙による押印や承認フロー、周囲からは悪意としてしか見做されない「PPAP」といった非効率な慣習（完全なムダ）が温存され続けています。
この停滞の最大のボトルネックは、多くの場合、外部環境や技術不足ではなく、ITを最も熟知しているはずの「情報システム部門（情シス）」の中に存在します。
情シスは、しばしば「変化を嫌う抵抗勢力」として見なされます。なぜ、ビジネスを変革すべきコア部門が、その変革を自ら阻害してしまうのでしょうか？
2. 抵抗の正体は「歴史に刻まれた業（ごう）」である
私たちが情シスの抵抗と呼ぶ現象は、単なる感情論や個人の保守性から来るものではありません。それは、1970年代の「電算室」誕生以来、日本のIT部門の歴史全体が積み上げてきた構造的な「業（ごう）」の現れです。
この「業」は、情シス部門の役割とマインドセットを、以下の3つの鎖で縛り付けてきました。
1. 「無謬性の文化」と失敗回避の呪縛
1970年代から続く「システムは絶対に止めてはならない」という至上命令は、情シスに「失敗への極度の恐怖」を植え付けました。この恐怖と、2000年代に再評価されたウォーターフォールモデルが結びつき、「責任を分担し、誰も決断しない」ための大規模な会議体を生み出しました。DXに必要な「小さな失敗を許容するアジャイルな試行錯誤」は、彼らにとって組織的な責任追及のリスクと同義であり、構造的に拒絶せざるを得ません。
2. 「技術の外だし」とアイデンティティの危機
1990年代に推進された情報子会社化とベンダーへの「丸投げ」により、情シスはシステムの核心的な知識（ブラックボックスの中身）と内製力を喪失しました。その結果、新しい技術を導入するたびに、「自分のスキルが不要になるのではないか」というキャリアの危機感と、「システムの全容を理解していない」という技術的な無力感に苛まれています。
3. 「コストセンター」の宿命と負債の押し付け
過去の経営判断（コスト削減）の結果であるレガシーシステムという負債の清算と維持を、情シスが担い続けています。予算と工数の大半が「過去の延命」に費やされ、「稼ぐ」ための未来への投資が不可能な状況が続いています。
3. 「業」と向き合う：抵抗勢力を変革の核へ
情シスが背負うこの「業」と向き合わない限り、企業がDXを推進しようとするたびに、情シスは「被害者としての自己防衛」として、最も強力な抵抗勢力となり続けます。
そもそも、これほどまでに構造的な負債と精神的な重荷を背負わされた部門に対し、「今からビジネスを変革しろ」というDXの旗を振ること自体が、どれほど酷な要求であるかを、私たちは認識しなければなりません。情シスは、過去の歴史によって背負わされた「業」と、現在の過大な期待という、二重の重圧に苛まれているのです。
だからこそ、必要なのは、情シスを糾弾することではなく、まず「共感的理解」を示すことです。彼らが守ってきた「絶対的な安定性への執着」や「大規模システム管理能力」という歴史的スキルを否定するのではなく、正しく肯定し、新たな価値に昇華させること。
それさえできれば、情シスは組織の足かせから「最も信頼できる変革の推進力」へと生まれ変わるでしょう。
次章以降、この歴史的な鎖がどのように形成され、いかにして現代の非効率（Excel、PPAP、アジャイル拒否）を生み出したのかを、具体的な年代ごとに掘り下げていきます