DX社会の落とし穴、企業の基幹システム開発やリプレースの相次ぐ“失敗”…裁判例から見える失敗の本質

　デジタルトランスフォーメーション（DX）の流れの中で、多くの企業が一大プロジェクトとして始めた基幹システムの開発やリプレースがここに来て失敗する事例が増えている。全国農業協同組合中央会（JA全中）は2025年3月、全国の農協で活用予定であった業務管理システムの開発の頓挫により200億円規模の損失が発生する見込みであると報じられた 。 江崎グリコでは24年4月、基幹システム切り替え後にシステム障害が発生し、一部の冷蔵食品の出荷に影響が生じた。

（BrianAJackson/gettyimages）

　こうしたシステム開発の失敗は、飲食業や小売業、製造業と様々な業界で起きている。また、失敗の原因を巡ってユーザー側とベンダー側とでトラブルも相次ぎ、裁判に発展することが少なくない。近時では、物流大手の日本通運が基幹システムの開発失敗を巡り、約124億9100万円の損害賠償を求めて開発ベンダーのアクセンチュアを訴えたことが報じられた。

　DXの中心である基幹システムの開発やリプレースにはユーザー企業および開発ベンダーといった多数の人間が関わることに加え、作業工程も長期間にわたることから、失敗に至る要因も複雑多岐に渡る。また、数十億円から数百億円の巨額の費用が掛かる。失敗の原因を巡るトラブルを当事者間の話し合いで解決することは容易ではない。

　本稿では、DXの失敗や法的紛争を少しでも減らすべく、過去の裁判例を基にシステム開発の失敗に至った原因や傾向を紹介する。

文化シヤッター対IBM

　一つの裁判例として挙げられるのが、総合建材メーカーの文化シヤッターが基幹システム開発の失敗の原因を巡って、開発ベンダーである日本IBMに対して約27億円の損害賠償請求をしたものである。17年11月に訴訟が提起され、25年１月に最高裁判所が日本IBMに損害賠償金約20億円の支払いを命じる判決を確定させた。

　文化シヤッターは20年以上利用していた「販売管理システム」の刷新を日本IBMに依頼。日本IBMの提案により、米Salesforce（セールスフォース）が提供するプラットフォームを利用することとなった。同プラットフォームでは、画面のデザインワークフロー、レポート機能といった基幹システムの機能が標準部品として用意されており、開発コストや開発期間を削減でき、保守も容易となるメリットがあった。

　ところが、実際の開発では、プラットフォームに備わっている標準部品はほとんど用いずにカスタム開発が多用された。判決では、プラットフォームを利用した開発なのに当該プラットフォームにあらかじめ備わる標準部品はほとんど用いずにカスタム開発を多用した点でIBMが開発手法を誤った、と指摘されている。

システム開発の工程

　大型のシステム開発プロジェクトで用いられるウォーターフォール型の手法においては、「要件定義」 → 「基本設計」 → 「詳細設計」 → 「開発」 → 「テスト」といった多段階に工程（フェーズ）が分かれている。最初に近い段階を「上流工程」といい、完成に近づく段階を「下流工程」とも表現する。

　要件定義フェーズでは、ベンダーがユーザーのニーズをヒアリングし、どんな機能が必要かを明確化する。住宅の建築で例えると、建築士が施主との打ち合わせを実施して、「どんな家に住みたいか？」「予算は？」「部屋数は？」「庭や駐車場は必要か？」といった希望を整理する段階である。

　基本設計のフェーズでは、大枠のシステム構成、画面遷移、主要機能の仕様を決める。住宅の建築で例えると、建築士が「LDKは1階に配置」「子供部屋は2階」「トイレは各階に」など、建物の大枠の間取りを決め、基本設計図・平面図を作成する段階である。