- 世界全体のIT支出は2005年以降3倍以上に増加したが、大規模ソフトウェアプロジェクトの成功率はほとんど改善していない
- カナダのPhoenix給与システム、英国のPost Office Horizon、米国やオーストラリアの福祉・行政システムなどで管理・組織・倫理の失敗が繰り返されている
- AIツールやコパイロットではこうした問題を解決できず、人間の想像力不足・非現実的な目標・リスク管理の失敗が依然として主因
- レガシーシステムの維持費がIT予算の70〜75%を占め、Agile・DevOpsの導入も組織的リーダーシップや文化変革なしでは失敗率が高い
- 繰り返される管理ミスと責任回避が社会的コストを拡大させており、透明性と倫理、人間中心のシステム設計が不可欠な課題として示されている
ソフトウェア失敗の持続的な問題
- この20年間でIT支出は1.7兆ドルから5.6兆ドルへ増加した一方、ソフトウェアの成功率は停滞したまま
- 失敗は国家、産業、組織形態を問わず発生
- 失敗による社会的・経済的コストは継続的に増加
- AIでは管理問題を解決できないという限界が明示されている
- 大規模プロジェクトの複雑な利害関係や政治的要因をAIが統制するのは難しい
- ITプロジェクトにはすでに非合理的な意思決定が多く、AIが学習できる事例も不足している
- 失敗の原因は人間の想像力不足、不明確な目標、複雑性管理の失敗、リスク統制の欠如など
- 何十年も同じ要因が繰り返され、「failure déjà vu」という現象が続いている
カナダ Phoenix給与システム
- 2016年に稼働した3億1,000万カナダドル規模のPhoenixシステムは、80,000件の給与ルールと105件の労組協約を統合しようとして失敗
- 予算削減のためテストやパイロット手順を縮小し、主要機能を削除するなど無理な進め方が行われた
- その結果、9年間で職員43万人のうち70%が給与エラーを経験
- 2025年3月時点で34万9,000件のエラーが未解決で、その半数以上が1年以上遅延
- 職員の自殺事例まで報告されている
- 総費用は51億カナダドル超に達し、会計検査院は「プロジェクト管理と監督における不可解な失敗」と評価
英国 Post Office Horizon システム
- 1999年に導入されたFujitsuのHorizon POSシステムは、内部エラーを隠蔽しながら3,500人の支店長を虚偽会計・詐欺容疑で起訴
- 技術・管理・法的・倫理的失敗が複合的に作用
- バグの多いミドルウェア、制御されないスコープ拡大、テスト不足、人員不備
- 経営陣は問題提起者に敵対的な態度を取り、証拠を隠し、組織的な隠蔽を試みた
- 2016年と2021年の置き換え試行も失敗し、現在もHorizonを使用中
- 新システムの予算は4億1,000万ポンド、2026年7月に決定予定
その他の主な失敗事例
- ミネソタ MNLARS: 2016年着手、2019年中止、費用1億ドル
- オーストラリア Modernising Business Registers: 4億8,000万豪ドルの予算が28億豪ドルに増加し、2022年に中止
- ルイジアナ州の車両登録システム: 50年物のメインフレームで障害が繰り返され、2025年に非常事態を宣言
- Jaguar Land Rover: 2025年のサイバー攻撃で1カ月以上にわたり世界の運用が停止、損失は12億〜19億ドル
- Lidl ERP: SAPベースの5億ユーロERPが失敗し、自社システムへ回帰（2017年）
- Boeing 737 Max: MCASの設計欠陥により346人が死亡、総費用は740億ドルと推定
- F-35 Block 4アップグレード: スケジュールが5年遅延し、費用は105億ドルから165億ドルへ上昇
失敗の経済的コスト
- 米国における2022年のソフトウェア失敗コストは1.81兆ドル、開発失敗は2,600億ドル
- 総額は**国防予算（7,780億ドル）**を上回る
- レガシーシステム維持費は年間5,200億ドルで、IT予算の70〜75%を占める
- 置き換えコストが高く失敗リスクも大きいため、更新が遅れる
- NTT DATA 2024年レポート: 80%の組織が老朽技術がイノベーションを妨げていると回答
- 経営陣の大半がレガシーインフラが市場対応を妨げていると認識
Agile・DevOpsの限界
- 反復的・漸進的な開発手法が広がっても失敗率は依然高い
- 一部レポートでは、Agileプロジェクトの失敗率65%、DevOpsは90%に達するとの指摘もある
- 成功導入にはリーダーシップ、組織規律、訓練、文化変革が必要
繰り返される管理ミスと学習不足
- ITプロジェクトの管理者はしばしば「自分たちのプロジェクトは違う」として過去の失敗の教訓を無視する
- カナダ政府は1995年の最初の給与システム失敗の教訓をPhoenixでも繰り返した
- 多くの失敗は革新的な試みというより平凡な管理ミスに起因する
- AIベースの行政システム失敗事例
- 米国のMiDAS失業給付システム、オーストラリアのCentrelink Robodebtは、誤ったアルゴリズムにより数十万人を不当に告発
- 政府は誤りの認定と補償に消極的な姿勢を取った
責任・倫理・透明性の必要性
- AIを内包したシステムの不透明な意思決定は、市民の権利侵害につながる懸念がある
- EUは**「アルゴリズムによる決定に対する説明を受ける権利」**を法的に保障
- 世界的に自動化システムの透明性と説明責任を人権として確立する必要性が提起されている
- ソフトウェア責任法や専門家免許制度の議論はあるが、実現可能性は低い
- 現実的な代替策は経営陣の誠実さ・懐疑的思考・倫理的判断の強化
- リスクを明確に認識し、ベンダーの誇張された約束を警戒する必要がある
- AIを含むすべてのITシステムに人間中心設計の原則を適用することが強調される
結論: 繰り返されたミスを止める時
- ソフトウェア開発は本質的に複雑で脆弱であり、小さなエラーが大きな結果につながる
- 成功するプロジェクトには十分な資源・リーダーシップ・説明責任が不可欠
- 利用者に及ぶ感情的・経済的被害まで考慮したコスト算定が必要
- 1968年の「ソフトウェア危機」以降、50年以上にわたり同じミスが繰り返されている
- 「新しいミスをしてください」
> 「誰でも過ちは犯すが、自分の過ちに固執するのは愚か者だけだ」 - ローマの雄弁家キケロ
5件のコメント
Hacker Newsの意見
記事の最後で示された解決策には物足りなさを感じた
私が考える本当の解決策は、小さく始めて実運用環境で検証することだ
たとえば全国規模の給与システムを作るなら、まず50人規模の小さな町でテストし、バグを潰してから徐々に大きな都市へ拡大すべきだ
小規模で問題を解決せずに一気に全国規模へ進むようなソフトウェア開発プロセスは存在しない
取引量が少ないため問題が起きても手作業で調整でき、PCI規制も回避できた
実店舗への展開前にこのようにテストしたおかげで、大きな事故もなく期限に間に合わせることができた
もし最初から顧客店舗に導入していたら、税計算の誤りや性能問題で大混乱になっていただろう
段階的拡張は技術的負債を積み上げ、最終的には誰もコードベースの中核に確信を持てず、リライト恐怖に陥る
WhatsAppのようにシンプルな製品でも、最初から大規模スケーラビリティを考慮したエンジニアリング設計が必要だ
小さく成功したシステムほど、こうした人が生まれやすく、ユーザーと開発者の双方の信頼を得て段階的に成長できる
大規模プロジェクトは失敗確率が高いので、予防原則(Precautionary Principle) に従って小さく始めるべきだ
どんなプロジェクトでも、この反復サイクルが基本だ
小さく始めて、モジュール化してから拡張せよということだ。Teslaのメガファクトリーの事例が印象的だった
技術史を研究して感じるのは、ハードウェア業界は過去の成功と失敗から学ぶが、ソフトウェア業界はそうではないということだ
ほとんどの開発者は過去のシステムを分解して学ばず、どの世代も同じ問題を繰り返し経験している
振り返りではいつも「次は開発者が何を変えるべきか」ばかりが問われ、管理職は何の責任も負わない
結局同じ問題が繰り返され、その負担は開発者に押し付けられる
過去の世代は問題をスタックの下層で解決していたが、今は上層でしか解決しようとしない
その結果、抽象化の塔が積み上がり、必要なリソースは増えるのに機能は大差ない
今やAIモデルの上にさらにもう1層のソフトウェアを積み上げる時代になっている
経験と性格の両方が重要で、低い自我と問題解決中心の思考が不可欠だ
たいていの人はプロジェクトの複雑さを過小評価している
私は大学院時代にTinyOSのソースコードを1週間読み込み、その構造を身につけたが、この経験は非常に役立った
見知らぬコードベースを素早く理解する能力はとても有用だ
新しい言語やフレームワークが周期的に登場すれば、企業は低賃金の新人を継続的に採用できる
こうした構造が、ソフトウェアが他の工学分野のように扱われない理由の一つだと思う
根本的には、これはプログラミングの問題ではなくマネジメントの無能の問題だ
ほとんどのプロジェクトではビジネス要件が明確に定義されず、すべて推測ベースで進められている
大規模な公共ITプロジェクトの失敗は、契約構造とインセンティブを見れば理解できる
実力よりも時間課金型コンサルティングに依存する構造が問題だ
成功するプロジェクトでは、技術より組織間のアラインメント(alignment) と 能力(competence) が核心になる
シリコンバレーの年齢差別こそ本当の問題だと思う
経験は軽視され、過去の教訓はまったく反映されない
ハードウェア業界は遺産を尊重しつつも革新を追求してきた
過去の失敗を学んだ人は新しい挑戦ができなくなる、という見方もある
ソフトウェアプロジェクトは結局、人間の失敗によって失敗する
完璧なプロセスやツールより重要なのは、動機と責任感のある人だ
法的な結果(Consequences) がなければ、人はきちんと仕事をしない
物理的な工事のように、各段階に独立した検証と責任を与えるべきだ
だから、ある程度のリスクを許容して進めるのが現実的だ
成功したプロジェクトは、感情知能とリーダーシップを持つ少数の人物のおかげだった
結局、ソフトウェアエンジニアリングは人の問題だ
しかし業界はいまだに責任回避と流行追従に陥っている
こうした問題はソフトウェアに限った話ではない
Auburn Dam, Columbia River Crossing, Big Dig のような大規模土木プロジェクトも予算超過で悪名高い
初期予算が非現実的だったなら、単に現実的なコストに修正されたにすぎない
だからこそ、小さなプロジェクトから段階的に拡張するアプローチが重要になる
私は開発者でもPMでもないが、大規模な成功事例に興味がある
病院で働いているので、ヘルスケア関連の成功事例だとなお良い
『The Phoenix Project』を読んでAgileとDevOpsの考え方を少し理解したが、実務に適用するのは難しい
小さなプロジェクトで成功の種をまきたい
Multicsの複雑さを反省し、Ken Thompsonが3週間でUnixを自ら書いたことが出発点だった
関連文 参照
Conway’s Law、キーパーソンリスク、明確なオーナーシップ、テスト文化なども不可欠だ
何よりも「ノー」と言う勇気が必要だ
healthcare.govのように、失敗後に改善された例もある
ITコミュニティを責める前に、企業の短期利益重視の文化を見るべきだ
セキュリティと安定性は常に予算削減の最優先対象だ
経営陣は失敗しても黄金のパラシュートで去り、責任だけが開発者に残る
政府も企業のずさんなセキュリティ事故を十分に処罰しない
結局、「AI、コンサル、外注で解決しよう」というシニカルな現実が繰り返される
AIに何兆ウォンも注ぎ込んでも状況は良くならず、むしろ悪化するだろう
すでに西側社会は不安定で、極右へ傾きつつある
次の危機は単なる金融崩壊ではなく、社会的崩壊につながるかもしれない
人類は危機ではなく、理解を通じた進歩へ進むべきだ
良いプロセスがあれば成果を、悪いプロセスがあれば問題を加速する
結局、方向は同じで、速度だけが速くなる
これほど長い間修正されていないのなら、開発技術や開発原則の問題ではなく、それを受け入れる運用側の問題ではないだろうか...
イギリス郵便局スキャンダルはドラマ化もされています。
いまだに被害者への補償が行われておらず、現在も進行中です。
最近の国内事例では、京畿信用保証財団の次世代電算システム構築の失敗事例が思い浮かびます。
https://v.daum.net/v/20251111165048155
ほかの国でも、非常に大規模なSIプロジェクトが進められているのでしょうか