先に結論画面の項目ではなく業務上の意味を対応させ、失敗時の担当と復旧方法まで要件に含めます。
連携の目的と正本を決める
顧客の二重入力を減らす、受注を会計へ渡すなど、減らしたい作業を一つずつ書きます。『すべて同期』では変更の責任が曖昧になります。
顧客名、住所、金額、状態ごとに正本を決めます。同じ項目を両側から更新できる場合は、競合時の優先や確認手順を責任者と決めます。
ID・項目・時刻を対応させる
名称だけで結ばず、変わらない外部IDと内部IDの対応を保存します。税区分、単位、状態コード、空欄の意味を項目ごとに確認します。
リアルタイム、数分ごと、夜間一括のどれが必要かを業務期限から決めます。日付境界、タイムゾーン、締め後更新もテストします。
認証と利用範囲を絞る
APIキーや秘密情報をコード、Git、通常メールへ残さず、環境変数や秘密管理へ分けます。読取だけでよい連携へ削除権限を与えません。
開発、試験、本番の認証情報を分け、有効期限、更新担当、停止手順を記録します。外部保守終了時に無効化できる一覧を持ちます。
失敗・再送・保守責任を決める
相手停止、通信切れ、形式変更、件数制限、一部失敗を想定し、再送してよい処理と人の確認が必要な処理を分けます。
誰が最初に気付き、どのログを見て、どちらへ問い合わせるかを決めます。相手仕様変更の確認、試験、公開、監視の費用と担当も連携要件です。
相談前にそろえるもの
- 連携目的・正本
- ID・項目・状態対応
- 実行時刻・締め
- 最小権限・秘密管理
- 失敗・再送・保守担当
全部そろっていなくても構いません。分かる範囲を確認し、業務ルールや金額に関わる部分は担当者と一緒に決めます。