新しいシステムを入れるときには、エラーはつきものです。何もないところにシステムを入れるのであれば、その構成を考えることに注力します。しかし、これが入れ替えになると、さらに前回のシステムとの整合性を考える必要があります。ここに難儀します。
最近、物流のシステム障害が発生して、出荷停止になっているケースがあります。
2024年4月3日(水)、基幹システムを切り替えた際に発生したシステム障害により、乳製品・洋生菓子・果汁・清涼飲料などの「チルド食品」（冷蔵品）につきまして、…(中略)…物流センターでの出荷に関するデータ不整合等が発生したほか、想定していた受注に対して処理が間に合わず、出荷の停止を判断しました
江崎グリコ株式会社『当社基幹システム障害に伴う「チルド食品」（冷蔵品）の一時出荷再停止に関するお詫び』(2024年04月19日)
一般の方から見れば、「それくらいうまくやるべき」とお叱りを受けるかもしれません。しかし、このデータ不整合はやっかいなのです。一般的な原因や責任をまとめて考察してみます。
データ不整合とは
物流システム障害における「データ不整合」とは、システム間でのデータの一致しない状態を指します。上記例のように、システムを入れ替えた際によく見られる現象です。 新旧のシステム間でデータフォーマットや管理の方法が異なることから起こります。
具体的な原因として以下が考えられます。
- システム間の互換性の問題：新しいシステムと旧システムとの間でデータの形式や扱いが異なるため、データが正確に移行されない。
- データ移行のミス：データの移行プロセスでのミス（データの欠落、誤入力など）。
- プログラミングのエラー：新システムの設計や実装において、データベースやアプリケーションのコーディングミス。
- テストの不足：新システム導入前の十分なテストを行わなかった結果、データ不整合が発見されずに運用に移行する。
まとめるとあっさりしているかもしれません。しかし、互換性の問題ひとつとっても、それほど簡単ではありません。例えば、旧システムにおいて、A「メモ欄」に納品変更後の数量を書いていた人がいるとします。新しいシステムでは、変更後の数量を記載できるB「変更後数量欄」を用意しているとすると、一部の人のデータだけは、A→Bという移行が発生します。
内部・外部の担当者は、誠心誠意がんばりますが、こういったイレギュラーな属人的なデータベースの使い方を見て、青色吐息になることがあります。
責任の所在
プロジェクトを管理するチーム、システムを開発・導入したIT部門、外部のシステムインテグレーターなど、複数関わっている人がいます。
プログラムのエラーであれば、システム開発部門か外部のSIerが強く関係します。
データ関連であると、外部よりは内部よりになるのかなと経験上考えます。一時的にデータベースの整理を内部の営業担当者や業務担当者に依頼をして、データ移行までに備えているはずです。外部に切り離す場合でも、そのデータを元にデータ移行をSIerにお願いする形です。
職責としてデータ整理を任されれば外部担当は行いますが、そのデータが本当に正しいかどうかは、旧データベースを使っていた担当者本人でないと分からない場合があります。データベースを移行した際には、整合性が分からないところは、私はいちいち担当者本人に確認をしてからデータを整理して、移行の前後を調整していました。
これが外部の担当者になると、離れすぎていて確認ができなかったり難しかったりします。
再度整理すれば、システム上の動作不具合の場合には、システム開発や外部のSIerの責任になりそうです。しかし、データ整理上の要因は、担当者や内部の担当者に責任がある可能性が高いです。実務上はこのような考えです。
ただし、法的には、会社間におけるプロジェクトの契約上でどうなっているかが、最終の責任の判断の分かれ目になります。
裁判例
オーダーメイド品について、双方の責任を認めた事例
システム開発者の義務
東京地裁平成16年3月10日判決（東京土建国保事件。判例タイムズ1211号129頁）では、外部のシステム開発者が、「注文者である原告国保のシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下、これらの義務を「プロジェクトマネージメント義務」という。）を負っていた」とされています。
発注者側の義務
同事案で、発注者側として「本件電算システム開発契約は、いわゆるオーダーメイドのシステム開発契約であるところ、…原告国保は、本件電算システムの開発過程において、資料等の提供その他本件電算システム開発のために必要な協力を被告から求められた場合、これに応じて必要な協力を行うべき契約上の義務（以下「協力義務」という。）を負っていたというべきである。」とあります。
最終的に
「原告国保は、懸案事項の解決を遅延し、開発作業の遅れの一因を作ったものであるが、被告も、開発作業の遅れの一因を作るなど、システム開発受託者として行うべき役割を怠った点があり、それらの内容、程度等前記認定の一切の事情を斟酌すれば、被告に生じた損害について６割の過失相殺（類推適用）をするのが相当である」と、判断しています。
双方に責任があるという内容です。オーダーメイドのシステムである点も、判断に影響しています。
パッケージソフトを使った事例
東京地裁平成28年4月28日判決（SAP社製ソフトウェアを使用したERPシステム開発事件・TIS対トクヤマ事件。判例時報2313号29頁）では、
- 「注文者である原告の本件システム開発へのかかわりなどについても、適切に配慮し、パッケージソフトを使用したERPシステム構築プロジェクトについては初めての経験であって専門的知識を有しない原告において開発作業を阻害する要因が発生していることが窺われる場合には、そのような事態が本格化しないように予防し、本格化してしまった場合にはその対応策を積極的に提示する義務を負っていた」
- 「原告がシステム機能の追加や変更の要求等をした場合、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすときには原告に対して適時にその利害得失等を具体的に説明し、要求の撤回、追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負っていた」
とされています。先程の判例とは異なり開発者側の責任に重きを置いています。
データ移行の遅延責任は開発者側にあるとした事例
東京地裁平成28年11月30日判決（ジャパンスチールグループ対アイロベックス事件）では、「被告(開発者側)は、本件請負契約に基づくデータの移行業務として、本件旧システム上のデータを本件新システムに単に移行させることにとどまらず、移行したデータにより本件新システムを稼働させる債務を負担していたものと認めるのが相当であり、本件においては、データ移行に当たり、データ不整合を是正・解消すべき義務を負うものというべきである。」と判断されています。
ユーザーである発注者側の協力責任を認めつつも「原告(ユーザー)は、被告から求められる態様で協力をするということを超えて、自ら積極的に被告が必要とする情報をあらかじめ網羅的に提供するという態様で協力をすべき義務まで負うものではないというべきである。」として、必要な範囲で責任を履行していたと判断されています。
小括
最初に挙げた事例がどれに該当するかは、契約や事実の詳細を見ないと判断できないものです。しかし、データ移行を伴うシステムの刷新にはこれだけのリスクの可能性や、双方ががんばっていてもうまくいかない可能性が存在しています。
「データ不整合」というシンプルな言葉で片付けられていますが、システム刷新は多くの問題が起こる可能性があります。自社であれ、アドバイスする第三者に対してであれ、システム刷新については、慎重に行う必要があることはアドバイスできる点でしょう。
【編集後記】
久々に名探偵コナンを見ましたが、新一と蘭はすでに付き合っていたのですね。見逃していました。
【運動記録】
ストレッチ○
【子育て日記(息子6歳10ヶ月、息子3歳3ヶ月)】
子どもとお買い物へ。小学校の用品で追加したいものがあったので、いくつか買い込んできました。子連れの買い物は、大変なところもありますが、意見を聞きながら一緒に選べるので、楽しいです。