【まとめ】日本のシステム移行はなぜ失敗するのか。事例と共通パターン

この記事の使い方

大規模システム移行の失敗事例一覧

まず全体像を示します。以下は、この記事で取り上げる事例の一覧です。

以下、各事例の詳細を見ていきます。

発注者主導の移行が失敗したケース

特許庁 — 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年前のシステムを使い続けながら移行計画を立て直している状態です。詳細は「大阪府警、50年動いたシステムの移行に失敗」で書いています。

民間企業の大規模移行失敗

江崎グリコ — SAP移行で7ヶ月出荷停止

2024年4月3日、江崎グリコはSAP社の「SAP S/4HANA」への基幹システム移行を実行しました。物流、販売、会計を一元管理する大規模ERPの刷新です。投資予定額は342億円。プロジェクトは2019年12月に開始されていました。

移行直後からデータ不整合が発生。4月14日にはプッチンプリンやカフェオーレなどほぼ全ての冷蔵品が出荷停止になりました。物流センターでの業務が処理に追いつかなくなったのです。全面復旧まで約7ヶ月を要しました。

業績への影響は甚大で、売上高ベースで150億円、営業利益ベースで36億円の損失。純利益は前年比36.8%減となりました。

指摘されているのは、グリコにCIO（最高情報責任者）が不在だったことです。IT投資342億円のプロジェクトを、技術を統括する役員なしに進めていた。開発はデロイトトーマツコンサルティングが担当していましたが、発注者側に技術的な判断ができる人間がいなければ、ベンダーの提案を検証できません。特許庁と構造的に同じ問題です。

みずほ銀行 — 4,000億円かけても止まる

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

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

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

「リニューアル初日に落ちる」パターン

2026年3月、立て続けに3つのサービスがリニューアル初日に障害を起こしました。上の事例とは性質が異なります。数年がかりの大規模移行ではなく、リニューアルの「切り替え当日」に問題が発生するパターンです。

ハローワーク — 3日止めて初日ダウン

2026年3月、ハローワークのWebサイトがリニューアルのために3日間サービスを完全停止しました。そして再開した初日に大規模障害が発生。求人検索も求職申し込みもできない状態が続きました。

詳細は「ハローワークのサイトがリニューアル初日にダウン」と「ハローワークのサイトはなぜ重いのか、外部から調べてみた」で書いています。外部から見えるフロントエンドの構成にも課題がありました。

進研ゼミ — 10年ぶり刷新で初日障害

ベネッセの「チャレンジタッチ」が10年ぶりのリニューアルを実施。初日から接続障害が発生し、子どもたちが学習できない状態に。教育サービスにとって「使いたいときに使えない」は致命的です。

詳細は「進研ゼミ『チャレンジタッチ』が10年ぶりのリニューアル初日につながらない」で書いています。

TOHOシネマズ — 新会員システム初日ダウン

TOHOシネマズの新会員サービス「TOHO-ONE」が初日にダウンしました。会員登録もポイント利用もできない状態が続き、映画館の窓口にも混乱が波及しました。

詳細は「TOHOシネマズ『TOHO-ONE』が初日にダウンした」で書いています。

日本全体で起きている「移行の渋滞」

個別のプロジェクトだけでなく、日本全体でシステム移行が同時多発的に進行しています。そして、同時多発的に詰まっています。

自治体システム標準化 — 5,000システムが遅延

デジタル庁が進める自治体システム標準化は、全国1,788の自治体が使う基幹システムを統一する国家プロジェクトです。対象は住民記録、税務、福祉など20業務。基金として約7,000億円が確保されています。

しかし、2025年12月末時点で対象3万4,592システムのうち5,009システム（14.5%）が期限超過。遅延するシステムが1つでもある自治体は935団体と、全体の半数を超えました。

遅延の主な理由は、移行に必要なシステムエンジニアの確保が想定以上に困難だったこと。富士通は約300自治体に対し、期限内の完了が間に合わないと通達しています。ベンダーの側も手が回っていない状態です。

富士通メインフレーム撤退 — 2035年の崖

富士通はメインフレームの製造・販売を2030年度に終了し、保守も2035年度で打ち切ると発表しています。1964年の「FACOM 230シリーズ」以来、66年のメインフレーム開発の歴史が終わります。

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

自治体標準化の遅延と富士通撤退が同時に進行していることで、日本全体で「移行できるエンジニアが足りない」状態が起きています。

全銀システム — 3,600兆円インフラの刷新

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

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

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

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

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

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

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

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

グリコの事例が象徴的です。IT投資342億円のプロジェクトに、CIOがいなかった。デロイトが開発を担当していましたが、発注者側に「この設計で本当にうちの物流を回せるのか」と判断できる技術者がいなければ、ベンダーの提案を検証する手段がありません。

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

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

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

大規模システムの成否は基盤設計で決まる

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

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

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

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

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

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

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

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

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

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

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

しかし「動かし続ける」という選択肢も消えつつあります。富士通のメインフレーム撤退は前述の通りです。自治体システム標準化も、2025年12月末時点で全体の25.9%が遅延しています。遅延するシステムが1つでもある自治体は935団体と、全体の半数を超えました。「移行」という作業が、日本中で同時に止まりかけている状態です。

よくある質問