システム連携でデータ不整合が起きた時、最初に見るべき4つの点
システム連携でエラーが起きると、最初に見直されるのはファイル形式や項目定義です。
CSVの桁数が合わない。必須項目が空になっている。日付形式が違う。受け側に存在しないコードが入っている。実際に、こうした原因で連携が止まり、仕様を修正する必要が生じることは少なくありません。
ただ、項目定義だけを見て修正しても、別のタイミングで同じ種類の問題が起きることがあります。
システム間で渡しているのは、単なる値ではありません。業務の中で入力され、承認され、更新され、次の処理へ渡される情報です。連携先の形式を整えても、データが作られる条件、確定する時点、参照するマスタ、処理の順番が合っていなければ、不整合は残ります。
ここでは、システム連携でデータ不整合が起きたときに、技術側と業務側で整理したい4つの点をまとめます。
1. そのデータは、どこで作られているか
連携先に届いたデータだけを見ても、原因が見えないことがあります。
たとえば、基幹システムへ渡す金額が想定と違っていた場合、連携処理そのものではなく、前段の業務システムで入力された値や、その後の処理で変更された条件に原因があるかもしれません。
見るべきなのは、項目名だけではありません。
どの画面、処理、バッチで値が作られるか
入力した人と、値を確定させる人が同じか
後から修正される可能性があるか
別の処理によって上書きされることがあるか
データの出所をたどらず、受け側だけを修正すると、別の処理で同じ値が作られたときに、同じ問題が起こります。
連携仕様書に送信元システムが記載されていても、それだけでは十分ではありません。送信元の中で、どの業務処理がその値を作っているのかまで見ておく必要があります。
2. その値は、いつ確定するのか
データが存在していることと、業務上確定していることは同じではありません。
入力時点では仮の値であり、承認、締め処理、マスタ更新の後に確定する場合があります。連携処理がその前に動けば、技術的には正常にデータを渡していても、業務として使えない値が連携されます。
たとえば、次のようなずれです。
申請は入力されているが、承認が終わっていない
金額は計算されているが、締め処理前で変更される可能性がある
新しいコードは登録済みだが、関連システムへの反映が終わっていない
修正処理の途中で、連携処理だけが先に実行される
連携タイミングを「毎日何時」と決めるだけでは、こうした条件を拾えません。
どの処理が終われば送ってよいのか。未確定の値を送った場合は後から更新するのか。差分だけを送るのか。再送時に二重計上や重複登録が起きないか。
業務上の確定条件と、システム上の実行条件を分けて整理すると、エラーとして表に出る問題だけでなく、静かに積み上がるデータのずれも見つけやすくなります。
3. どのマスタを正としているか
データ不整合の原因として見落とされやすいのが、マスタの違いです。
システムAとシステムBで同じコードを使っていても、名称、意味、有効期間、利用できる部門まで一致しているとは限りません。片方では有効なコードでも、もう片方では廃止済みということもあります。
基幹システムと周辺システムの間では、次のような問題が起こります。
部門コードは同じだが、組織変更後の扱いが異なる
商品コードは存在するが、連携先では利用停止になっている
取引先コードは一致しているが、属性情報が更新されていない
変換表はあるが、更新の担当者や更新時期が決まっていない
連携エラーが起きたとき、「コードがない」とだけ扱えば、その場では処理を通せるかもしれません。
ただ、その前に整理したいのは、どのシステムがマスタを管理するのか、他のシステムへいつ反映するのか、例外が出たときに誰が更新を判断するのかです。
主となるマスタと反映の責任が曖昧なまま連携を続けると、エラーのたびに個別修正が増えます。やがて、どの値を基準にすべきかを説明できなくなります。
4. 処理がどの順番で動いているか
正しいデータがそろっていても、処理順が違うだけで不整合は起こります。
上流システムでデータを作る。マスタを更新する。変換処理を行う。連携ファイルを作る。受け側で取り込む。その後、集計や後続業務が動く。
この順番のどこかが前後すれば、処理は止まらなくても、期待していない結果になることがあります。
見るべきなのは、ジョブの開始時刻だけではありません。
先行処理の完了を、次の処理がどう判定しているか
途中で失敗した場合、どこから再実行するか
再送したとき、同じデータを二重に取り込まないか
処理が遅れた場合、後続業務はどこまで待てるか
異常を検知したとき、誰が最初に動くか
ここまで整理すると、連携設計と運用時の対応範囲がつながります。
データ連携は、正常時だけ動けばよいわけではありません。遅延、再実行、差分反映、マスタ未反映、業務処理のやり直しといった例外が起きたときに、どこまで戻り、何を見て、誰が判断するかまで決めておく必要があります。
不整合を直す前に、原因を置く場所を決める
システム連携の障害対応では、早く復旧させる必要があります。
一方で、連携先の項目を修正した、データを手で補正した、再実行して処理が通った、という対応だけを重ねると、次の担当者は原因を追えなくなります。
原因は、入力処理にあるのか。マスタ管理にあるのか。連携条件にあるのか。処理順にあるのか。業務運用にあるのか。
まず、どこで問題が生まれたのかを整理する。そのうえで、改修が必要なものと、運用上の見方や手順を整えれば防げるものを分けます。
この順番がないと、システム連携は「エラーが出たら直す仕事」になっていきます。
システム連携の原因整理や運用設計を見直したい方へ
連携仕様はあるものの、エラーが起きるたびにデータ補正や再実行で対応している。
送信元・受信先・マスタ管理のどこに原因があるのか切り分けにくい。
複数システムや複数ベンダーが関わり、障害時に誰が何を確認するか曖昧になっている。
連携後の運用まで含めて、データの流れと確認事項を整理したい。
ディーシステムでは、基幹システムと周辺システムの連携において、要件整理、データの作成元や確定条件の整理、I/F設計、テスト、本番移行後の運用整理まで支援しています。
