ブログ/記事一覧/特許庁55億円、京都市117億円、大阪府警は撤退。日本の大規模システム移行はなぜ失敗するのか
japan-system-migration-failure-pattern-cover

特許庁55億円、京都市117億円、大阪府警は撤退。日本の大規模システム移行はなぜ失敗するのか

特許庁55億円、京都市117億円、大阪府警はベンダー撤退。日本の大規模システム移行はなぜ同じパターンで失敗するのか。共通する構造的な原因を分析し、全銀システム刷新への教訓を考える。

コラム
kkm-horikawa

kkm

Backend Engineer / AWS / Django

2026.03.238 min6 views

特許庁、55億円と8年を燃やした

2004年、特許庁は基幹系システムの全面刷新に着手しました。完成予定は2010年。結果、2012年に開発中止。投じた約55億円は「無駄だった」と会計検査院に認定されました。

何が起きたのか。入札で落札したのは東芝ソリューション。3社の中で技術評価点は最低でしたが、入札価格が予定価格の約6割だったことが決め手で受注が決まりました。

プロジェクト管理の支援にはアクセンチュアが入りました。しかし、元内閣官房GPMO補佐官の萩本順三氏が振り返っているように、特許庁側に「業務のシステム化に明るい人材」がほとんどいなかった。開発方針は入札後に何度も変更され、基本設計が完了しないまま2年以上が過ぎました。

技術評価が最低の業者に任せ、発注者側に技術が分かる人間がおらず、外部のコンサルも状況を制御できなかった。55億円と8年という数字は、この構造が生んだ結果です。

京都市、117億円を投じて2度延期した末に中断

京都市は、NEC製メインフレームで約30年稼働していた基幹系システムのオープン化を目指していました。総額117億円を投じたプロジェクトです。

当初は2017年に順次稼働する予定でしたが、直前の2016年11月に1回目の延期。ベンダーを切り替えて2020年の稼働を目指しましたが、2019年12月に2度目の延期を発表。稼働時期は「未定」になりました。

そして2020年、門川市長が一部機能を除いてプロジェクトの中断を発表しました。中断の理由は、国が進める自治体システムの標準化方針が決まり、完成してもまた作り直す必要が出てきたからです。117億円のうち100億円近くが無駄になる可能性があるとされました。

開発を請け負ったシステムズとの間では訴訟にも発展しています。バッチ処理のマイグレーション(移行)がうまくいかなかったことを巡り、京都市とベンダーが互いを提訴しました。

大阪府警、ベンダーが「できません」と撤退した

大阪府警は50年以上メインフレームで運用していた人事系システムの移行を進めていました。競争入札で選ばれたのは電算システム。予定価格の約6割で落札しました。

特許庁と同じパターンです。

新システムの本稼働は2025年10月の予定でしたが、稼働5カ月前の2025年5月にベンダーが「仕様書通りの履行ができない」と契約解除を申し出ました。開発の遅延を重ねた末の撤退です。

大阪府警は今、50年前のシステムを使い続けながら移行計画を立て直している状態です。

みずほ銀行、10年ごとに止まる呪い

みずほ銀行のシステム障害の歴史は、日本のIT史そのものです。

何が起きたか影響
2002年発足初日に大障害。
3行統合のシステム再編成に失敗
口座振替250万件遅延
二重引き落とし3万件
2011年東日本大震災の義援金振込が
古い勘定系に集中
ATM停止、振込遅延が
10日間続く
2021年新勘定系MINORI稼働後
12カ月で11回のシステム障害
ATMにカード吸い込み
金融庁が業務改善命令

2019年に完成した新勘定系「MINORI」には約4,000億円が投じられたとされています。19年がかりのプロジェクトでした。それでも2021年に11回止まった。

みずほの問題は、旧第一勧業・旧富士・旧日本興業の3行がそれぞれ異なるシステムを持ち込み、「誰も全体を把握していない」状態が続いたことにあります。技術の問題というより、組織の問題です。

なぜ同じパターンで失敗するのか

これらの事例を並べると、同じ構造が繰り返されていることが分かります。

共通原因特許庁京都市大阪府警みずほ
安値入札予定価格の6割
技術点最低
予定価格の6割
発注者にIT人材
がいない
要件定義の甘さ
・方針ブレ
入札後に
何度も方針変更
2度延期
ベンダー切替
仕様通りの
履行が不能
3行の要件が
統合できない
メインフレーム
/COBOLの壁
NEC製MF
30年稼働
50年稼働複数ベンダーの
MFが混在

4つの事例すべてに「発注者側にITが分かる人材がいない」が共通しています。技術を理解していない人間が技術的な意思決定をすると、要件は曖昧になり、方針はブレ、ベンダーの言うことを検証できなくなる。逆に、ベンダーの側も発注者が分かっていないことを前提に提案するので、認識のズレが雪だるま式に膨らんでいきます。

「安い業者に頼む」ことそのものが悪いわけではありません。問題は、安い理由を技術的に検証できる人間が発注者側にいないことです。予定価格の6割で出してきた業者の提案書を読んで「この工数で本当にできるのか」と疑問を持てる人がいない。だから技術評価点が最低でも価格だけで決まってしまう。

そして、これは発注者だけの問題ではありません。受注側の体制にも同じ構造があるのです。

ベンダー側で顧客との窓口にビジネスサイドやコンサル的な立場の人間が立つこと自体は、悪いことではありません。問題は、その窓口と同等の権限を持つ位置に、技術を本当に理解している人間がいるかどうかです。ここで言う「理解」とは、教科書やフレームワークの知識ではなく、予定するアーキテクチャの実際の挙動や制約を肌で分かっているという意味です。

年次や社内ポジションに関係なく、「この設計で本当に動くのか」を判断できる技術者が、意思決定の場に同席していなければ、営業が約束したことを技術が実現できない、という事態が起きます。大阪府警のケースでベンダーが「仕様通りの履行ができない」と撤退したのは、まさにこの構造の帰結です。

発注者にIT人材がいない。受注者は営業が主導する。間に立つコンサルは教科書の知識で管理しようとする。この三者の中に、技術的な現実を見ている人間が誰もいない。これが、日本の大規模システム移行が繰り返し失敗する最も根深い構造です。

もうひとつ、現場で繰り返し見る光景があります。基盤設計がまずいと、その上に乗せる機能がまともに組めない。そして、組めなかった責任は機能実装側に押し付けられます。基盤を設計した人間はプロジェクトの序盤だけ関わって去り、残された開発者が汚い基盤の上で格闘する。

逆に言えば、基盤さえしっかりした構造で組まれていれば、その上の機能は自然と拡張性もメンテナンス性も備わります。大した技術的難度を要求されずに組める。大規模システムの成否は、基盤設計を「誰がやるか」でほぼ決まるのです。特許庁も京都市も大阪府警も、この「誰が基盤を設計するか」の時点で躓いています。

現場のエンジニアは気づいている。でも声を上げない理由がある

「でも、現場のエンジニアは気づいていたんじゃないか?」と思うかもしれません。気づいていることは多いです。このアーキテクチャではスケールに限界がある、この基盤構成では破綻する。現場の技術者はそれを分かっている。

しかし、日本のソフトウェアエンジニアは、良くも悪くも「決まった仕様通りに作る」文化の中にいます。自分の責任範囲にきっちりしている。上位権限を持つ人間が決定したアーキテクチャには従う。それが間違っていると分かっていても。

これは怠慢ではありません。むしろ合理的な判断です。権限を与えられていないのに進言して、プロジェクトの方針を覆そうとすれば、チームの関係が壊れる。訴訟リスクもある。仲間のことを考えれば、権限の範囲内で最善を尽くすのが現実的な選択です。

だからこそ、技術者に「権限を与える」ことが決定的に重要なのです。そもそもソフトウェアエンジニアは、毎日のコードの中で「誰にどの権限を与えるか」「システムの構造をどう設計するか」を考え続けている職種です。権限と構造の設計にどこよりもうるさい人間たちが、自分たちの組織ではその権限を与えられていない。笑えない話ですが、これがこの業界の現実です。

「技術的に問題があれば声を上げてくれ」という雰囲気だけでは足りません。意思決定の場に同席させ、ビジネスサイドと同等の発言権を明示的に与える。そうすれば、技術者は技術者としてのプライドと責任から、進言します。権限なしに声を上げることと、権限を持って判断することは、まったく別の行為です。

50年動いたシステムほど移行が難しい理由

メインフレームのシステムは「動いているから触らない」という文化の中で何十年も使われてきました。その結果、以下のような状態になっています。

  • ドキュメントが残っていない。仕様書があっても実装と乖離しており、「動いているコード自体が仕様書」になっている。
  • 当時の開発者がいない。COBOLを書ける技術者は年々減少しており、システムの挙動を理解している人間が引退・転職している。
  • 暗黙の業務ルールが埋まっている。数十年分の例外処理や業務ルールがコードの中に埋め込まれており、移行先でそれを再現しようにも、なぜそうなっているか誰も分からない。

しかし「動かし続ける」という選択肢も消えつつあります。富士通はメインフレームの製造・販売を2030年度に終了し、保守も2035年度で打ち切ると発表しています。66年のメインフレーム開発の歴史が終わります。

富士通メインフレームを使っている組織は、好むと好まざるとにかかわらず、2035年までに移行を完了させなければなりません。大阪府警も、全銀システムも、この期限の中にいます。

国が進める自治体システムの標準化も、2025年12月末時点で全体の25.9%が遅延しています。遅延するシステムが1つでもある自治体は935団体と、全体の半数を超えました。「移行」という作業が、日本中で同時に止まりかけている状態です。

全銀システムの刷新は、同じ轍を踏まないか

全銀システムは2030年に新たな決済システムの稼動を目指しています。年間3,600兆円を処理するインフラの刷新は、上で並べた事例とは桁が違います。失敗した場合の影響も桁違いです。

ただ、過去の失敗から学んだ形跡はあります。

  • 1. 段階移行。2023年の障害を受けて、全面一括移行から段階移行に方針転換。新旧システムを1カ月並行稼働させ、問題があれば切り戻せるようにしています。
  • 2. 「置き換え」と「新設」の分離。2028年の第8次システムは現行の「置き換え」、2030年の新決済システムは完全な「新設」。2つを分けることで、リスクを分散しています。
  • 3. 構築是非の判断を先送りにしていない。2026年度中に「本当に構築するかどうか」を判断するフェーズを設けています。見切り発車ではない。

一方で、懸念も残ります。特許庁は入札で失敗し、京都市は途中で国の方針が変わって無駄になり、大阪府警はベンダーに逃げられました。全銀システムの刷新は、同じ構造的な罠にかからない保証はどこにもありません。

特に「発注者側にITが分かる人材がいるか」という問題は、金融業界でも根深いものがあります。みずほの19年間の苦闘は、技術の問題ではなく、技術を理解した上で意思決定できる人間がどこにいるか、という問題でした。

全銀ネットのスタディグループには、メガバンク、地銀、フィンテック協会、ガートナー、弁護士、金融庁、日本銀行のメンバーが名を連ねています。技術を分かっている人間が意思決定の場にいるかどうか。過去の失敗事例が教えているのは、ここが最も重要な分岐点だということです。

日本の大規模システム移行は、何百億円を投じても「技術を知らない人間が技術的な意思決定をする」という構造が変わらない限り、同じことが繰り返されます。全銀システムの刷新が、この構造を超えられるかどうか。2026年度中の構築是非判断が、最初のリトマス試験紙になるはずです。

参照元