第1章：無謬性の文化とコストセンターの芽生え — IT部門の「業」の原点

野村です。このシリーズは、私の過去を振り返る貴重な一時となっています。

DXを阻む情シス部門の「業（ごう）」は、今から半世紀前、1970年代にその根を深く張りました。この時代は、一見華々しくもありながら、後の停滞を決定づける「無謬性の文化（絶対に失敗しないこと）」が、企業のIT部門に強く刻み込まれた時期です。

1. 「電算室」の栄光と「経営の奇跡」

1970年代の「電算室」は、社内で最もエリートで、未来志向の部門でした。彼らの仕事は単なる計算ではなく、巨額の投資を要するメインフレーム（大型汎用機）を駆使し、手作業では不可能だった企業の基幹業務（会計、在庫、給与など）を自動化するという、まさに「経営の奇跡」を実現することでした。

IT部門は「コンピュータを動かす魔術師」として、組織から高い敬意と期待を払われていました。

• 成功の裏側での至上命令: この「経営の奇跡」が、情シスの最大の重荷へと変わります。システムがひとたび停止すれば、会社の心臓が止まることを意味したため、電算室の成功はそのまま、「システムは絶対に停止させてはならない」という、極めて厳しい至上命令（絶対的な品質要求）へと昇華しました。実際問題、金融は言うまでも無く、電力会社の料金計算や請求書発行業務など、日本文化では、絶対に止める事は許されないものだったでしょう。

2. ウォーターフォールと「完璧主義の幻想」

この「絶対に失敗してはならない」という精神的な重荷を、技術的、そしてマネジメント的な手法で裏付けたのが、この頃に確立・導入が進んだウォーターフォール（WF）開発モデルです。

WFは「完璧な初期設計」があれば、その後の実装も「完璧な結果」を導けるという「完璧主義の幻想」を情シスに植え付けました（ただ私はそれを観ていないので、おそらくそうだろう、という推測です）。これは、当時のビジネススクールで支配的だった「徹底的な分析と計画があれば、誰がやっても同じ結果が得られる」という経営思想とも合致していました。

ここで特筆すべきは、WFの起源とされるウィンストン・W・ロイスの1970年（どうでもいいことですが、私が産まれた年）の論文が、実は厳格な線形モデルの危険性を指摘し、フィードバックループやプロトタイプ作成といった反復的な改善を強く推奨していた点です[^1]。しかし、日本の産業界やマネジメント層に普及したのは、ロイスが「欠陥がある」とした、フィードバックのない線形モデルの図表でした。この「真意が欠落したWF」が、日本の「無謬性の文化」と結びつき、より強固なプロセスとして定着してしまったのです。このあたりは、弊社のPMP試験対策講座などでも度々説明しています。

• 認識論的な誤謬（ごびゅう）: 「一度決めたスコープが絶対であり、変更はあり得ない」というWFの前提は、認識論的に誤っていました。現実のビジネス環境は常に変化し、要件も知識も進化するのが常です。WFは、この現実の不確実性を無視し、システム開発において「知の進化」や「変化の受容」を構造的に拒否することを情シスに強制しました。
• 後の業への影響: この幻想は、「一度決めた設計は絶対に正しい」「変更は悪である」という信念を、技術的なプロセスとして情シスに強制しました。後のアジャイル開発が求める「試行錯誤」や「仕様変更への柔軟な対応」を、WFという手法が構造的に拒否するための根拠を、情シスはここに得てしまったのです。

3. 「コストセンター」の芽生えと職人文化の呪縛

安定稼働は、成功の証であると同時に、部門の価値を徐々に削り取りました。システムが動き続けるにつれ、その存在は「あって当然」となり、IT部門の努力はルーチンワーク化・オペレーション化していきました。

• 価値の透明化と転落: 初期には**「経営を左右する」とまで言われた計算機への投資でしたが、安定稼働という「成功」が続くにつれて、その巨額な費用は収益に直結しない「固定費」として計上され始めました。IT部門は、「経営戦略の中枢」という期待の頂点から、「削減すべき固定コスト」という評価へと急速に転落**し、コストセンターとしての宿命を背負い始めました。
• 職人文化の深化: メインフレームや特定のプログラミング言語（COBOLなど）に関する知識は、ごく少数の技術者に集中しました。この「特定の知識を持つ英雄的な職人」がシステムを維持するという構造は、属人性の美学を生み出しました。彼らにとって、過去の知識こそが組織内での唯一の権威となりました。

4. 次の世代へ引き継がれた「重荷」

この時代の情シス部門は、「コストセンター」という経営的な評価と、「絶対に失敗できない」という精神的な重荷の二つを同時に背負い込みました。

彼らにとって、過去のシステム（仕組み）を捨てることは、安定性という最大の美徳を放棄することであり、ひいては職人としての自分の存在意義を揺るがすことにつながりました。この時点で、IT部門は変化を嫌う自己防衛的な体制を無意識のうちに作り上げてしまったのです。

この構造が、私の生まれた年に確立したという事実は、日本のIT部門が「業」を背負わされることが、もはや宿命的なものであることを示しています。

この重荷は、1980年代の技術革新の波の中で、さらに決定的な「構造的病理」へと進化していきます。

参考文献

[^1]: Winston W. Royce, “Managing the Development of Large Software Systems,” (1970). (論文全文：https://www.praxisframework.org/files/royce1970.pdf) 論文内で線形モデルの欠陥と、反復的な改善の必要性が指摘されている点については、Martin FowlerやPragTobのブログなどで詳細に考察されています。