中堅企業で情報システム部門のリーダーを務める方にとって、基幹システムの刷新は避けて通れない重要なミッションです。しかし、このような大規模プロジェクトには多くの落とし穴が潜んでいます。
2025年5月12日の日経コンピューターに掲載された、マルヨシセンターの基幹システム刷新失敗事例は、まさにそうしたリスクを浮き彫りにしています。同社は最終的に2億2990万円もの損害賠償を求める事態に発展しました。
この記事では、この事例を詳しく分析し、中堅企業の情報システム部門のリーダーが今後、基幹システム刷新を担当することになったら、どんな点に気をつけて、計画を立てて、実行していくべきかを考察してみたいと思います。
マルヨシセンターは新基幹システムの開発失敗を巡ってソフテックを提訴した。システム刷新で業務効率化や法改正対応を狙ったが、プロジェクトは難航。システムは完成せず、別のITベンダーへの開発委託も余儀なくされた。最終的に支払いの返還請求権を含め、計2億2990万円の損害賠償を求めた。だが原因と責任を巡っては双方で見解が大きく異なり、真っ向から対立している。
プロジェクトの概要の整理
目的
- マルヨシセンターは2015年に老朽化した基幹システムの刷新を企画。2017年4月リリースを計画。
- 小売り業務（購買・受注・在庫管理等）機能の刷新、業務効率化、法改正への対応を目指す
- 小売業向けERP（企業資源計画システム）の「RealFit」を導入する
計画と経緯
- 2015年に企画・計画
- 2016年5月にソフテックを選定
- 2016年7月に消費税対応を目指した
- ⇒作業の遅れと消費税延期を踏まえリスケ
- 2016年12月にリスケ案策定
- STEP1：2018年2月末リリース
- STEP2：2018年9月リリース
- 全店展開：2018年9月リリース
- 消費税対応：2019年10月リリース
- リスケ後にも、ずるずると遅延が発生
真の争点は何だったのか
日経コンピューターの記事では主な争点として、ASTERIAWarp（システム間でデータを連携するためのツール）導入の位置づけが論点になっていますが、スケジュールが遅れた原因は製品ではなく、もう1つの争点「マッピング作業の遅延」だと思います。
マッピング作業とは：既存システムのデータ項目と新システムのデータ項目を対応づけ、どの項目がどの項目と連携し、どんな変換が必要かを整理する作業のことです。
製品決定が作業に影響を与えるのは、詳細設計工程、そして主には実装工程からだからです。ASTERIAWarpであろうとAnyTran（これも同じくデータ連携ツール）であろうと、製品が決まっていない状態であろうとも、設計に大きくは影響を与えません。
設計は、小売り業務システム（RetailFit）の各テーブルのデータ項目と、連携先のシステムのデータ項目のマッピングを行う作業です。どの項目がどの項目と対応していて、どんな変換が必要かをまとめるものです。これは、製品は関係なく、論理的な世界でできる作業です。
既存システムの「見えない問題」
ベンダー側は以下の2点を遅延理由として主張しているように見えます。
- 急にASTERIAになったから
- マルヨシセンターからの他システムインターフェース仕様のインプットが遅れたから
1点目については、前述のとおり遅れの原因とは言いづらいでしょう。
2点目については、ベンダー側の主張として理解できます。
ベンダーは既存システム仕様に詳しいわけではないので、どのような他システムとインターフェースしていて、そのインターフェースがどのような意味を持ち、どのような項目をやりとりしているのか、こういういった内容は、わからないわけです。
マルヨシセンターの主張の「マッピングの精度が悪い」というのは、ベンダー側にインプットを十分に渡していなければ仕方がない部分があると思いますので、主張としては弱そうに見えます。
筆者の経験から推測される真の問題
マルヨシセンター側にも他システムインターフェースの仕様がわかるドキュメントはなく、そして仕様に詳しい人もいない、またはかなり少なかったのではないかと推測されます。
中堅企業でよく見られる課題：
- 古いシステムの仕様書が残っていない、メンテナンスされていない
- 当時の担当者が異動や退職で残っていない
このため、プロジェクト開始当初から、他システムインターフェースの設計はリスク含みだったのではないかと考察できます。
失敗を防ぐ2つの対策
では、どうこの事態の発生をプロジェクトマネジメントとして防げたでしょうか。今後、中堅企業で、同様の案件を推進される立場の方向けのアイデアとしてまとめておきたいと思います。
争点にも入っていますが、システム連携開発（163本）はRFPに入っていたので、プロジェクト計画段階では作業として認識されていたと思います。
しかし、前述のとおり、古いシステム、特に他システムインターフェースはコアな機能ではなく、あとで付け足し、付け足しで開発することが多い機能なので、仕様書が残っていない、ということがよくあります。
経験則にはなってしまいますが、こういうリスクを検知できたとしたら、そのリスクを踏まえた、段取りにするというのがセオリーかと思います。
具体的には、フェーズごとに以下のような取り組みをするとよいと思います。
対策1：事前調査でPoCを実施、インターフェース見直し
基幹システム刷新は、企画構想/調査フェーズでスコープを定めるだけでなく、リスクを踏まえた「進め方」も一定程度整理しておく必要があります。
大企業のERP導入プロジェクトでは、FittoStandard（FtS：業務をパッケージソフトの標準機能に合わせる手法）というのが主流になっていますが、具体的にFtSってどういうことなのか、このあたりをすり合わせておかないと、いざFit&Gap分析（パッケージの標準機能と現行業務の差分を洗い出す作業）が始まっても、アドオン開発・カスタマイズの嵐になりかねません。
同様に、今回のケースでもあったように、インターフェースもどう進めるのかを整理しておくとよいでしょう。インプットとなるドキュメントがないのであれば、現行機能を紐解くしかないので、それにどのくらい時間がかかるのか、どういうアウトプットを作るのかなどを、PoC（ProofofConcept：ここでは技術的検証を指す）的に実施しておくとよいと思います。
例えば、データソースの多さから大中小と3種類くらいにわけて、それぞれで現行機能紐解き、再設計を行うのに、誰がどう関わり、どのくらいの工数が必要かを整理しておくのです。
また、インターフェースそのものの見直しも、調査フェーズでやっておくと良いでしょう。163本というのは見直した後かもしれませんが、一般的に、既存のインターフェース、つまりファイルは、システム構成の刷新と共に不要となるものも多いです。本数が減れば、開発コストもリスクも減るので、見直しはしておいて損はありません。
対策2：リスクを織り込んだ計画立案
上記のように主要なタスクやリスキーなタスクについて進め方を整理したうえで、例えば以下のようなプロジェクト計画にするとよいでしょう。
- スケジュール
- インターフェースのようにリスクの高い設計作業はスケジュール的に期間を十分に設ける
- 同様にテストもテスト期間を長くとる、新旧比較検証を入れるなどの対策を織り込む
- 体制/役割分担
- 発注者側の情シス担当者の専任を配置する（調査や検討に専念してもらう）
- インプットがない前提で、ベンダーも現行仕様調査を分担して行う
まとめ
今回のマルヨシセンター案件から学べる重要な教訓をまとめると、以下の2点に集約されます：
1.中堅企業特有のリスクへの対策
- 既存システムの仕様書不備
- 詳しい担当者の不在
- システム間連携の複雑さ
これらは多くの中堅企業で共通する課題であり、プロジェクト計画段階で十分に考慮する必要があります。
2.事前準備の徹底と実際的な計画立案
RFP（提案依頼書：ベンダーに対して提案を求める際の仕様書）での役割・責任範囲の明確化、リスクを踏まえたプロジェクト計画の策定など、基本的だが重要な準備作業を発注側が主導することで、多くのリスクをコントロールできます。
基幹システム刷新は企業の根幹に関わるミッションクリティカルなプロジェクトです。だからこそ、事前準備・事前調査を徹底し、それに基づく綿密な計画立案が成功の鍵となるのです。
補足：製品決定と品質・変更管理について
ASTERIAWarpの導入についても争点にあがっていたので、一応、こちらもあるべき論を補足でまとめておきたいと思います。
これも段取りの問題が大きいと思います。プロジェクト計画の中で以下のようなことを決めておくと良いと思います。
製品選定の段取りを決めておく
- 要件定義フェーズの終りの方、または基本設計フェーズで、これまで定義した機能要件・非機能要件をもとにして、インフラアーキテクチャ図（インフラ構成図）を作成します
- アーキ図の中で、製品が決まっていない構成要素があれば、機能要件・非機能要件を基にして製品選定・評価を行います
レビュー・承認プロセスを決めておく（品質管理）
- 利用サービス・製品一覧をまとめます。またインフラアーキテクチャ図にも反映します。
- 成果物として発注側にレビュー、承認をしてもらいます
変更管理対象と開始タイミングを決めておく（変更管理）
- インフラアーキテクチャ図も、成果物として承認済みだとしたら、どのタイミングから変更管理を始めるのかをプロジェクト計画で決めておく
作業プロセスや品質管理、変更管理の方針・ルールがプロジェクト計画上定まっていると、今回のASTERIAWarpのようなことは起きにくいのではないかと思います。
