ITプロジェクト失敗の構造的原因：繰り返される管理的無知とその代償

• 要約概要:
  • 中核テーマ: ITプロジェクトの失敗は技術的難題ではなく、経営陣の「意図的な無知」と、過去の失敗事例から学ぶことを拒む傲慢さに起因する。
  • 主要数値: 過去20年間で世界のIT支出は3倍（5.6兆ドル）に増えたが成功率は横ばいで、レガシーシステムの保守だけに予算の75%が費やされている。
  • 中核事例: カナダのPhoenixシステムにおける全面的な管理不全と、英国のHorizon問題における非倫理的な隠蔽は、「失策（Blunder）」ではなく「行政上の悪（Administrative Evil）」である。

---

1. 序論：莫大な投資にもかかわらず改善しない失敗率

• 投資に対する効率性の停滞:
  • 2005年以降、世界全体のIT支出は1.7兆ドルから2025年時点で5.6兆ドルへと3倍以上に急増した。
  • しかし、巨額の費用を投じているにもかかわらず、ソフトウェアプロジェクトの成功率は過去20年間ではっきりした改善を見せていない。
• AIへの幻想への警戒:
  • 多くの経営陣はAIツールやコーディング支援ツール（Copilot）が大規模プロジェクトを成功に導くと期待しているが、筆者はこれに懐疑的である。
  • AIは、システムエンジニアリングの複雑さ、財務上のトレードオフ、そして何よりプロジェクト内の 「組織政治（Organizational Politics）」 を解決できない。
• 普遍的な失敗現象:
  • ソフトウェアの失敗は、国家、企業規模、営利・非営利を問わず無差別に発生しており、これは単なる技術的エラーではなく、「人間の想像力の欠如」と「非現実的な目標」に起因している。

2. 本論：失敗の類型と原因の詳細分析

2.1. 繰り返される「失策（Blunder）」と学習拒否

• 失敗と失策の区別:
  • 技術的限界に挑戦するなかで生じる「創造的破壊（Creative Destruction）」としての失敗は歓迎されるべきである。
  • しかし、ITの失敗の大半は、すでに何十年も文書化されてきた原因（リスク管理の欠如、複雑性の過小評価など）を繰り返す 「愚かな失策（Blunder）」 にすぎない。
• 経営陣の傲慢さ:
  • プロジェクト管理者は、自分たちのプロジェクトが「特殊で唯一無二だ」と主張し、過去の失敗事例やデータを無視する傾向がある。
  • これは単なる無知ではなく、危険信号をあえて見ようとしない 「意図的な無知（Willful Ignorance）」 である。
• レガシーシステムの罠:
  • 米国内の組織は、レガシーシステムの保守だけで年間5,200億ドル以上を支出しており、これはIT予算全体の70〜75%に達する。
  • 置き換え失敗への恐れから、システムが物理的に崩壊するか（例：ルイジアナ州車両局のメインフレーム）、費用対効果が完全に失われるまで近代化を先送りする。

2.2. 主な失敗事例の詳細と波及効果

• カナダのPhoenix給与システム:
  • 初期の誤判断: 既製ソリューション（PeopleSoft）を導入しながら、80,000件の給与ルールと105件の労使協約をカスタマイズしようとした。
  • 予算削減の代償: ベンダー提案予算の60%未満でプロジェクトを進めるため、主要な給与機能の削除、テスト縮小、必須のパイロットテスト省略を強行した。
  • 結果: 2016年の稼働直後に崩壊。従業員への給与誤支給により経済的苦痛を引き起こし（一部職員の自殺原因と指摘された）。
  • 費用: 当初予算は3.1億カナダドルだったが、復旧と解決にかかる費用は現在51億カナダドル（約36億米ドル）を超えている。
• 英国郵便局のHorizonスキャンダル:
  • 技術的欠陥: Fujitsuが提供したシステムのミドルウェアのバグにより、金銭不一致エラーが発生した。
  • 組織的隠蔽: 経営陣はソフトウェア欠陥を知りながらそれを隠蔽し、逆に3,500人の郵便局長を横領および窃盗の容疑で告発した。900人が有罪判決を受けて収監された。
  • 社会的コスト: 被害者の破産、離婚、収監、自殺が発生した。英国史上最悪のIT失敗であり、司法の不祥事として記録されている。

2.3. 自動化された意思決定と「行政上の悪」

• アルゴリズムの暴力性:
  • 米ミシガン州のMiDAS（失業給付不正受給摘発）とオーストラリアのRobodebt（福祉不正受給摘発）システムは、人間の監督なしにアルゴリズムのみに依存して判定を下した。
  • 何万人もの無実の市民を犯罪者扱いしたが、官僚たちはシステムの誤りが立証された後も補償を拒否したり、責任を回避したりした。
• AI導入の危険性:
  • このような「行政上の悪（Administrative Evil）」は、AIが公共インフラに深く関与するほど深刻化していく。
  • EUは「説明を求める権利」を導入したが、世界的に透明性とアルゴリズムに対する責任の所在の明確化が急務である。

3. 結論：解決策とITコミュニティの課題

• 方法論（Agile/DevOps）は万能鍵ではない:
  • Agileプロジェクトの失敗率が最大65%に達するとの報告があるように、方法論そのものが成功を保証するわけではない。一貫したリーダーシップと組織的規律がなければ、どんな新しい方法論も失敗する。
• 率直なリスク評価と倫理的責任:
  • プロジェクト開始前に、「何を知っていて、何を知らないのか」に関する率直なギャップ分析（Gap Analysis）を先行させるべきである。
  • 「人間中心AI（Human-centered AI）」 の概念をすべてのITプロジェクトへ拡張し、システム障害が最終利用者に及ぼす感情的・経済的被害を費用便益分析に含める必要がある。
• 経営陣の姿勢変化の促し:
  • ソフトウェアは本質的に脆弱（Fragile）で複雑である。経営陣は予算を握る権力者としてだけでなく、失敗時に責任を負う主体として、ソフトウェア開発を尊重し支援しなければならない。
  • 繰り返される誤りを止めることだけが、IT産業が「危機（Crisis）」から脱する唯一の道である。

[baeba]

Hacker Newsコメント反応の要約

1. 段階的デプロイとスケーリング戦略の欠如（Start Small）

• 「ビッグバン」方式の必然的失敗: 国家規模のプロジェクトを一度に展開するのは自殺行為だ。小さな単位（村→都市→国家）で順次検証しながら拡張する戦略が不可欠。
• 製品 vs システムの違い: WhatsAppのような単一製品と異なり、複雑なエンタープライズシステムは初期から巨大なスケールに耐える必要があるため、アプローチを変えるべきだ。
• 核心的な解決策: 「小さく作り、検証後に機能を追加せよ」という原則が無視されている。

2. 経営陣の無能と責任回避（Management Issues）

• 責任なき権力構造: プロジェクトが失敗すると開発者は残業で後始末する一方、意思決定権を持つ経営陣は責任を取らず、むしろボーナスを受け取るという矛盾した構造への批判。
• 技術理解の欠如: 技術的難易度を無視した非現実的なスケジュールの強要と、「悪い知らせ」を聞こうとしないトップダウン文化が問題解決を妨げている。
• 政治的な意思決定: 技術的適合性よりも、社内政治や外部ベンダーとの関係（リベートなど）によってソリューションが決まる傾向。

3. 制御不能な要件と複雑性（Complexity & Scope Creep）

• プロセス簡素化の先行欠如: フェニックス・プロジェクトの事例のように、8万件の給与ルールを整理しないままそのままシステム化しようとする試みが根本原因だ。混乱したオフラインプロセスは、混乱したデジタルシステムを生むだけだ。
• 頻繁な要件変更: プロジェクト進行中に、経営陣や顧客の気まぐれによって作業範囲が拡大するScope Creepが、プロジェクトを泥沼に陥れる。

4. 開発者文化と誤ったインセンティブ（Developer Culture）

• 履歴書主導開発（RDD）: プロジェクトの成功よりも、自身の転職に有利な最新流行の技術（フレームワーク）を無理に導入し、技術的負債を増大させる。
• 学習の断絶: 2〜3年周期の頻繁な転職（Job Hopping）文化によって、開発者が自分の書いたコードの長期的な失敗を目撃し、教訓を得る機会が断たれている。
• 再発明への執着: 検証済みの既存ソリューションを活用するよりも、自己実現のために最初からコードを書き直すという非効率な慣行。

5. ソフトウェア工学の特殊性（Engineering Nature）

• 物理的制約の不在: 建築やハードウェアと違って、ソフトウェアには物理的制約がないため無限の複雑性を許してしまい、これが制御不能な状態を招く。
• 過去から学ばないこと: 他の工学分野では失敗（例: 橋の崩落）を徹底的に分析して教訓を残すが、ソフトウェア業界では「今回は違う」として過去の失敗を繰り返す、いわば「YOLO」式の開発態度が見られる。