双日、日本通運、三井住友信託銀行――いずれも日本を代表する大企業ですが、ここ数年、この3社に共通している出来事があります。それが「基幹システム刷新プロジェクトでの100億円超の損失」です。日経クロステックが上場企業の有価証券報告書を分析したところ、少なくとも5社がシステム開発の見直しなどで100億円を超える損失を計上しており、その一社である双日は2023年3月期に109億4400万円の減損損失を計上していたことが明らかになりました。X (formerly Twitter)+1
同じく、日本通運は新たな国際航空貨物向けの基幹システム開発が頓挫し、154億円の減損損失を計上したうえで、開発ベンダーであるアクセンチュアを相手取り約125億円の損害賠償を求めて提訴する事態に発展しています。コトラ+2ITmedia+2 三井住友信託銀行もまた、大規模な基幹システム刷新の見直しに伴い、100億円規模の損失を計上した企業として報じられています。Yahoo!
なぜ、これほどの大企業が、ここまでの損失を出してしまうのでしょうか。本記事では、それぞれの企業がどのようなシステム刷新を目指していたのか、何が起きたのか、どこに共通する構造的な問題があるのか、そして今後企業はどう向き合うべきなのかを、国内外の情報や専門家の解説をもとに整理します。
目次
日本の「基幹システム刷新」で100億円超の損失が続発しているのか
まず押さえておきたいのは、これらの案件が「レアケース」ではなく、構造的な問題の表面化だという点です。日経クロステックによると、過去5年間の有価証券報告書などを分析した結果、少なくとも5社が基幹システム開発の見直しなどによって100億円超の損失を計上していることが明らかになりました。その代表例として挙げられているのが、双日、日本通運、三井住友信託銀行です。X (formerly Twitter)+1
背景には、「2025年の崖」「2027年問題」と呼ばれるレガシーシステム更新の波があります。特にSAP ERP 6.0のサポート終了がきっかけとなり、2015年前後から基幹システム刷新の必要性が叫ばれ、サポート期限が2027年末に延長された今も、根本的な問題は解決されないまま先送りされていると指摘されています。natic.sojitz-ti.com+1
つまり今回の3社のケースは、単なる「一社のプロジェクト失敗」ではなく、日本企業全体が直面しているレガシー刷新の難しさとリスクを象徴する事例だと言えます。
双日：109億円超の減損に終わった基幹システム刷新
システムの目的と構想
総合商社の双日は、グローバルに展開する多様な事業を支えるため、ITインフラや基幹システムの強化を経営戦略の柱の一つに掲げてきました。同社の統合報告書では、DX戦略として「Digital-in-All」を掲げ、ITインフラ・基幹システムの刷新やセキュリティ強化、グループ会社支援を推進していることが説明されています。商社のリーダー+1
狙いは、グローバルでバラバラだった業務やデータを統合し、経営管理やリスク管理を高度化すること。老朽化したシステムを刷新し、ERPなどの統合基盤に置き換えることで、決算の早期化やグローバルな資産管理の高度化も目指していました。Amazon Web Services, Inc.+1
顛末：109億4400万円の減損
しかし、こうした構想とは裏腹に、双日は2023年3月期決算で109億4400万円の減損損失を計上していたことが後に報じられます。日経クロステックの分析によると、この減損は基幹システム刷新プロジェクトの見直しに伴い資産価値を見直した結果だとされています。X (formerly Twitter)+1
詳細な内訳やプロジェクトの中止・縮小の判断プロセスは開示資料からは読み取りにくいものの、少なくとも「投入した投資の相当部分が回収不能」と判断されるほど、当初の計画から乖離してしまったことは確かです。
原因と構造的な問題
双日そのものが詳細な反省点を公表しているわけではありませんが、同社グループのIT中核会社である双日テックイノベーションが公開しているERPコラムなどを読むと、大規模基幹システム刷新で日本企業が陥りやすい罠が語られています。natic.sojitz-ti.com+1
レガシーシステムと新しいクラウドERPを「ツギハギ」でつなぎ、全部は変えられないからと部分的な置き換えにとどめる構成。現場業務に合わせた個別仕様を残しすぎた結果、業務プロセスの標準化も進まず、ERPのメリットも出にくい状態。IT人材不足を理由にベンダー丸投げで進めた結果、自社側の要件整理や全体設計が甘くなり、プロジェクトが膨張していく――。
双日の減損は、こうした「日本型ERP刷新のリスク」が一気に表面化した事例として捉えられます。
双日の今後
双日はその後もDX戦略の中で「デジタル基盤を築く」ことを掲げ続けており、ITインフラ・基幹システムの整備をグループ戦略の土台と位置づけています。商社のリーダー 減損は痛手でしたが、ここで得た教訓を踏まえ、フェーズ分割や業務標準化を重視した現実的な刷新ロードマップに切り替えていると見るのが自然でしょう。
日本通運：基幹システム訴訟に発展したNXグループの大規模プロジェクト
国際航空貨物向け「新・国際航空貨物基幹システム」
物流大手の日本通運（現・NIPPON EXPRESSホールディングス）は、国際航空貨物事業のグローバル共通基盤を構築するため、「新・国際航空貨物基幹システム」の開発プロジェクトを進めていました。目的は、世界各地の拠点でバラバラに運用されていたシステムを統合し、国際貨物の情報をリアルタイムに把握できるようにすることです。ITmedia+1
開発の実務はアクセンチュアに委託され、2020年前後から本格化していましたが、プロジェクトは次第に暗礁に乗り上げていきます。
顛末：開発断念、154億円の減損、約125億円の訴訟
報道や専門家の解説によると、2020年6月時点でアクセンチュアから「プログラムの品質不良によりテストが遅延している」との報告がなされ、その後も結合テスト段階で多数の不具合が発見されました。最終的には415件を超える不具合が指摘され、修正しても新たな問題が出てくる状態が続いたといいます。コトラ+1
こうした事態を受け、日本通運は2023年1月にシステム開発の断念を決定。これに伴い、2022年度決算で154億円の減損損失を計上することになりました。そのうえで、開発費用の増加と開発期間の延長による損害を理由に、2023年7月にはアクセンチュアを相手取り、約124〜125億円の損害賠償を求めて東京地裁に提訴しています。コトラ+2ITmedia+2
争点：品質か、検収か、それとも要件定義か
この訴訟を巡っては、「プログラム品質の問題」だけでなく、「検収条件の特殊さ」や「要件定義の不十分さ」が争点だと指摘されています。ITmediaやnoteなどで解説されているように、日本通運側はアクセンチュアの成果物が品質基準を満たしていないと主張する一方、アクセンチュア側は「特殊な検収方法が新たな不具合指摘を生み続けた」と反論していると報じられています。ITmedia+2note（ノート）+2
根本的な問題は、巨大で複雑なグローバル基幹システムを一気に作り上げようとしたにもかかわらず、要件定義やテストの設計、双方の役割分担やリスク分担が十分に詰め切れていなかった点にあります。
日本通運の今後と教訓
NXグループの統合報告書を見ると、基幹システム投資については「投資効果やキャッシュフロー回収見込みを長期的観点から検討する」としながらも、経済動向や顧客動向によっては減損リスクがあることを認めています。IR Bank 今回の案件は、その典型例です。
教訓として浮かび上がるのは、
・グローバル共通基盤という巨大なスコープを一度に実現しようとしないこと
・要件定義と検収条件を契約段階で徹底的に詰めること
・品質管理とテストプロセスを双方で透明に共有し、早期に手戻りを検知すること
といった、ITプロジェクトの基本に尽きる話です。
三井住友信託銀行：金融インフラを支える勘定系刷新の難しさ
銀行にとっての「勘定系システム」とは何か
三井住友信託銀行は、銀行業務と信託・資産運用業務を併せ持つ大手金融機関であり、その中心にあるのが「勘定系システム」です。勘定系は預金や融資、為替などの取引データをリアルタイムに処理する心臓部であり、長年にわたりCOBOLなどで書かれたレガシーな大規模システムが稼働し続けてきました。SMTG+2smtss.jp+2
行内外の求人情報やプロジェクト紹介を見ると、同行では国内外の勘定系システム更改プロジェクトや、海外との共通基盤構築プロジェクトを進めていることがわかります。doda+2マイナビスカウティング+2 それだけ規模も重要度も高い刷新計画であることは間違いありません。
報じられた「100億円超の損失」と見直し
日経クロステックの分析では、三井住友信託銀行もまた基幹システム刷新の見直しに関連して100億円規模の損失を計上した企業の一つとして挙げられています。Yahoo! 個別案件の詳細は一般にはほとんど明らかになっていませんが、銀行システムの性質を考えると、勘定系や周辺の情報系を含めた大規模な再構築プロジェクトの一部または全部を見直し、資産の減損を迫られたと考えるのが自然です。
銀行の勘定系刷新は「システムを止めてはいけない」「セキュリティとコンプライアンス要件が極めて厳しい」「少しのミスが即お金の誤計上につながる」という条件のもとで行われます。そのため、計画の遅延やコスト超過が見えてきた段階で、一度立ち止まって投資を見直す判断をせざるを得なかったのでしょう。
金融機関の今後の方向性
三井住友信託グループの統合報告書などを見ると、大規模障害や災害によるシステムへの影響を最小化し、早期復旧を図るための投資を重視していることが示されています。SMTG+2三井住友信託銀行+2 これからの勘定系刷新では、「一気に全部作り替える」のではなく、「段階的な更改」と「堅牢なインフラ・運用基盤の整備」を組み合わせる方向にシフトしていくと考えられます。
3社に共通する「構造的な失敗パターン」
ここまで見てきたように、3社の事情はそれぞれ異なりますが、いくつか共通する構造的な失敗パターンが見えてきます。
第一に、レガシーシステムの複雑さと歴史の長さです。多くの日本企業では、数十年にわたり個別要件を積み上げてきた結果、「その会社専用の超カスタムシステム」が出来上がっています。これを一気にERPに乗り換えようとすると、業務プロセスも含めて全面的な見直しが必要になりますが、現場の抵抗やリソース不足から中途半端な「ツギハギ構成」になりがちです。双日テックイノベーションのコラムでも、レガシーとERPを混在させた新基幹システム構築には大きなリスクがあると警鐘が鳴らされています。natic.sojitz-ti.com+1
第二に、ベンダー丸投げ体質とIT人材不足です。ERPやクラウドを導入する際、本来であれば自社側で業務要件を整理し、「何を標準に合わせ、何を捨てるか」を決めたうえでベンダーに発注すべきところを、DXの掛け声のもとでトップダウンにプロジェクトだけが走り始め、IT部門は人手不足のままベンダー依存を深めてしまうケースが多く見られます。natic.sojitz-ti.com+1
第三に、スコープとリスクのコントロール不足です。日本通運の訴訟のように、グローバル共通基盤という巨大なスコープを一度に実現しようとすれば、要件定義やテストの難易度は跳ね上がります。本来であれば、段階的なロールアウトやプロトタイプによる検証を重ねるべきところを、「一発でフル機能」を狙った結果、品質問題や検収条件を巡るトラブルが一気に噴出してしまいました。コトラ+2ITmedia+2
今後、企業はどう基幹システム刷新に向き合うべきか
では、これから基幹システム刷新に取り組む企業はどうすれば同じ轍を踏まずに済むのでしょうか。
一つ目のポイントは、「全部作り替える」を前提にしないことです。SAP ERPや国産ERP、クラウドERPを問わず、最近の議論では「フルスクラッチ刷新」ではなく、「段階的リニューアル」と「レガシーの延命・モダナイズ」を組み合わせたロードマップが現実解とされています。natic.sojitz-ti.com+1
二つ目は、業務標準化と経営のコミットメントです。どんなに高性能なERPを導入しても、「うちの部署だけは従来どおりで」と個別要件を積み上げてしまえば、結局は旧来の複雑さが再現されるだけです。双日が人材戦略やDX戦略とセットで基幹システムを位置づけているように、業務プロセスを標準化し、それを守る覚悟を経営が示せるかどうかが成否を分けます。商社のリーダー+1
三つ目は、契約とガバナンスの見直しです。日本通運とアクセンチュアの訴訟は、「大規模システム開発契約のあり方」を社会に投げかけるケースとなりました。要件定義、テスト計画、検収条件、リスク分担、変更管理――こうした項目を発注側・受注側の双方が腹落ちするまで詰めたうえで、段階ごとに成果物を検証していくアプローチが不可欠です。ITmedia+2マジセミ+2
最後に、IT部門の役割を「ベンダー窓口」から「事業戦略のパートナー」に引き上げることも重要です。三井住友信託銀行の求人情報を見ると、IT業務推進部ではシステム企画やプロジェクトマネジメント、業務プロセス改善を担う人材を積極的に採用しており、グループ内システム会社と一体となって取り組む体制を整えつつあることがわかります。doda+2type女性の転職エージェント+2 こうした「内製力＋パートナー活用」のバランスが取れた体制こそが、今後の大規模刷新プロジェクトの前提条件になっていくでしょう。
まとめ
双日、日本通運、三井住友信託銀行という3社の事例は、単に「失敗したプロジェクトの記録」ではありません。2025年・2027年問題に象徴されるレガシー刷新の波の中で、多くの日本企業が抱える構造的な課題が、100億円超の損失という形で一気に表に出てきた象徴的な出来事です。
基幹システム刷新は、もはや「IT部門だけの話」ではありません。業務プロセスの標準化、人材戦略、投資判断、契約とガバナンス、そして企業文化そのものをどう変えていくかという、経営レベルのテーマです。今回の3社のケースから学べる教訓を自社の文脈に引き寄せ、「どこまでをいつ刷新するのか」「何をあきらめ、何を守るのか」を現実的に議論することが、次の100億円損失を防ぐ第一歩になるはずなのですが・・・
ひとりごと
現実は、そんなに簡単な問題ではない。
ここまで書いてきたのは、理想論、そして参考にした記事のうわべだけの話
実際には、社内関係者のワガママな要求、経営者のシステムの理解度（サラリーマン社長ならコスト優先）、日本の開発会社の「マニュアルしか知らないプロジェクトマネージメント」
それに
公的には、「システム重視」と言いながら社内システム部門の権限の低さ
レガシーシステムの刷新は、レガシーシステムに捕らわれている限り何も解決しない。
そんなゴミは捨ててしまえ というのが何十年もシステム構築に携わってきたことで学んだことである。
JALがシステム刷新に成功したように 完成されたシステムに丸乗りして システムに業務を合わせる。
それしか解決方法はない。
そうでなければ、どこかの銀行のように莫大なカネと時間をつぎ込んで、できあがったものは、すでに時代遅れになっている。
もうひとつ これは、理想なのですが
プロジェクトマネージャーに全権を与え、一人の天才エンジニアとそれを支える秀才エンジニアを揃えたチームを編成することである。
理想を言えば 火消し専門の手練れなエンジニアがいれ完璧です。
結局、人がすべて コスト優先にすると失敗するということです。
最期に
ゼネコンのような分業体制と多重下請けでシステム構築などを続けてきたことで日本のIT産業が遅れてしまったことを知ってほしい。