過去に別チームがオフショア開発で作らせたシステム間のデータ連携機能が、全く使い物にならなかったことがありました。
最終的には私が作り直すことになったのですが、その原因を振り返ると、発注側・受注側の双方がデータ連携の勘所を理解していなかった点に尽きます。
データ連携の四大要件
私が考える重要な点が４つあります。これを今日から勝手に四大要件と呼ぶことにします。
データ量
最重要項目です。これが変わるとその他の項目も大きく影響します。
データ出力側・受信側が最終的にどれくらいのデータ量(件数/容量)を扱うかを見積もることが重要です。
たとえば1日あたり1000件と100万件では、設計の前提がまったく異なります。
量が少ない分には大した問題は起こりません。量が多いと難度は大きく上がります。
出力形式や通信方法など、設計のあらゆる部分がデータ量に依存します。ゆえに最重要項目です。
連携頻度
1回／日で済むなら夜間バッチで十分です。
しかし「ほぼリアルタイム」のような要件になると、非同期処理、キューイング、再送設計などが必要になってきます。
全件か差分か
全件連携はシンプルですが、データ量が多いと処理負荷やネットワーク負荷が問題になります。
そのため、更新があったデータのみを差分で連携する設計が現実的です。
削除データの反映方法
出力元で削除されたデータは、通常そのままでは受信側に反映されません。
これを補うには、次のような手段が考えられます：
- 削除フラグを用意し、それを出力する
- 削除専用のデータを別ファイル・別イベントで送信する
- 丸ごと再構築（ただしデータ量が少ない場合に限る）
削除の反映方法は、設計の初期段階で決めておくべき重要な論点です。
まとめ
データ連携の設計には、単なる仕様書やAPI定義では見落とされがちな論点が多くあります。
特に今回紹介した「データ量・頻度・差分・削除対応」の四点は、実装の成否を左右する重要ポイントです。
自分が発注側・受注側のどちらであっても、これらを意識することでトラブルを未然に防ぎ、より堅牢なデータ連携を実現できるでしょう。