【新基幹システム訴訟から考える】“どこに繋ぐか”より“どう使われるか”が重要──マッピング作業を業務に活かす設計視点とは

基幹システムの刷新を巡る訴訟事例からは、技術的な問題よりも「設計と認識のズレ」がトラブルの根本にあることが浮き彫りになりました。とくにデータ連携のマッピング作業においては、「どこに繋ぐか」よりも「繋いだ先でそのデータがどう使われるか」を踏まえた設計が極めて重要です。

本コラムでは、マッピング設計における“業務活用視点”の重要性と、失敗を防ぐための考え方を解説します。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら

【記事要約】新基幹システム開発を巡る訴訟、マルヨシセンターがソフテックに2.3億円の賠償請求

マルヨシセンターは、老朽化した基幹システムの刷新を目的にソフテックへ開発を委託したが、作業の遅延や仕様不備により稼働に至らず、やむなく別のITベンダーへ委託。これを受けて、支払い済み金額や追加発注費用など計2億2990万円の損害賠償を求めてソフテックを提訴した。争点は、データ連携ツール「ASTERIA」の導入認識の食い違いや、マッピング作業遅延の責任所在。両社は高松地裁で争う見通し。

出典：日経コンピュータ「新基幹システムの開発が頓挫　ベンダーに2億2990万円の賠償請求」2025年5月12日

マッピング作業の目的は「つなぐ」ことではない

マッピング作業というと、送信元と受信先のデータ項目を機械的に対応づける作業だと考えられがちです。しかし、単に項目名を一致させるだけでは、システム間で“連携できたつもり”になってしまう危険があります。

重要なのは、受信先システムでそのデータがどう処理され、どのような業務に使われるのかという視点です。業務フローの中で有効に機能しなければ、連携されたデータであっても“使えないデータ”になってしまいます。

業務文脈を無視したマッピングのリスク

たとえば「在庫数」という項目一つを取っても、出荷済なのか予約分を含むのか、タイムラグがあるのかなど、業務上の定義が違えば連携の意味合いも変わってきます。こうした業務文脈を共有せずにデータを渡しても、連携先では判断に困る、または誤処理の原因となる可能性があります。

このようなミスは、仕様書の形式上は「正しく連携されている」ように見えてしまうため、検収段階まで表面化しないことが多く、発見が遅れるほど手戻りのコストも大きくなります。

マッピング設計は業務設計の一部として捉える

マッピング設計を単なるIT作業とせず、業務設計の延長線上として扱うことが必要です。つまり、「このデータを誰が、どの場面で、どう使うのか」「出力の形式や粒度は業務ニーズに合っているか」といった観点から逆算して設計を行うべきです。

開発の現場では、「APIがあるから連携は簡単」と考えてしまいがちですが、APIがデータを届ける手段でしかない以上、その先の“業務でどう活かされるか”の視点がなければ、連携の目的が機能しません。

設計フェーズで意識すべき具体的ポイント

マッピング作業を業務視点で進めるには、以下のような点を設計フェーズから意識しておくことが効果的です。

• 受信側システムの業務フローと画面仕様を確認する
• 各項目の定義を明文化し、関係者間で共有する
• データが利用されるタイミングや処理順を把握する
• 例外値や未入力時の取り扱いルールを明確にする
• 想定される利用パターンに応じてマッピングパターンを分岐させる

これらを事前に設計しておくことで、データ連携は“つながるだけ”でなく、“活きるデータ連携”へと変わります。

まとめ

マッピング作業は、システム同士を繋ぐだけの技術的な工程ではなく、連携先の業務に即して意味のあるデータを届けるための設計活動です。「どこに繋ぐか」ではなく、「そのデータがどう使われるか」という視点を持つことで、トラブルを防ぎ、業務に根ざしたシステム連携が実現できます。プロジェクト初期からこの意識を共有することが、開発成功の第一歩となるでしょう。

こうした業務視点に立ったマッピング設計を実現するには、技術だけでなく業務の流れや実際の利用シーンを深く理解し、設計に反映できる体制が欠かせません。フレシット株式会社では、要件定義の初期段階から事業担当者と丁寧に対話を重ね、業務に根ざしたシステム連携をゼロから設計するフルスクラッチ開発を行っています。業務で“本当に使える”連携を実現したいとお考えの方は、ぜひ一度ご相談ください。

＞＞フルスクラッチ（オーダーメイド）のシステム開発について詳細はこちら